As a developer building your first app with a new technology, successfully deploying a working end-to-end solution can be highly satisfying. But before you get there, you need to learn the fundamentals of the tech.
To optimise your learning process, it seems wise to stick to the core technology and its out-of-the-box tools. If you wanted to build Ruby on Rails web apps, you would learn plain Ruby before learning Rails. If you wanted to build rich front-end experiences, you would skill up on pure React before looking at React-Router, Redux or Webpack. The cognitive burden of having to pick up supplemental tools and frameworks in parallel can be overwhelming. They will slow you down or even cause you to give up altogether.
And in most cases, I agree with this approach. However, if your goal is to build your first serverless web app using AWS Lambda and API Gateway, I make an exception.
Writing the Lambda function code is (generally) the easy part. But I see so many newbie serverless developers hit roadblock after roadblock as soon as it comes to configuration and deployment of the function and its connected services. Some people have even cited such stumbling blocks as a deal breaker for them adopting serverless. Most of these developers are using the AWS console or CLI with home-rolled configuration code to manage their functions and related resources.
The solution I almost always recommend is a simple one—use a serverless-focused deployment framework which has already solved these problems for you.
I would go so far as to say that there is no minimum level of complexity under which you shouldn't use a deployment framework. Even if you want to deploy a simple Hello World app, you should use a deployment framework to do it. You will jump through fewer hoops all while using the same mechanism you would to deploy a much more complex app with many moving parts.
💌 Want to learn more about building serverless web apps? Then subscribe to my weekly newsletter.
Pains that deployment frameworks ease
If you decide not to heed this advice and instead stick with the AWS Console or CLI to manage and deploy your serverless app, here is a taster of some issues you can expect to spend time resolving...
- Working out what IAM permissions you need to invoke your function and integrate it with triggering or downstream services
- Jumping through hoops to set up API Gateway with Lambda to act as a simple REST API
- Manually zipping your Lambda code and package dependencies
- Setting up dead letter queues (and requisite IAM permissions) for failed Lambda invocations
- Coming up with your approach for managing environment-specific configuration
- Debugging CORS issues when invoking your API Gateway
- Connecting your Lambda to a VPC
But by choosing to use a deployment framework instead, almost all these "just work" either by default or with minimal configuration.
What framework should I use?
I personally recommend the Serverless Framework (yes, it's somewhat confusing that it has the same name as the architectural concept). I've used it on many projects, find it very easy to understand and is extremely flexible with its plugin model. It has been around for several years and I believe is the most popular deployment framework used in the serverless community today. Safe to say that it's a solid choice for newbie serverless developers to make.
Another notable mention goes to AWS's own SAM (Serverless Application Model) framework. I won't go into the other options now but you can go here for a comparison of the most common frameworks in use.
Less friction = the "serverless way"
A common maxim of the serverless movement is that developers get to focus more on their application code by minimising the need for infrastructure management and scaling concerns.
Lambda removes the pain of managing servers and orchestrating complex container clusters to handle load. API Gateway takes away the need to worry about load balancing and throttling HTTP requests. AWS (and other cloud providers) have done a great job of providing such powerful service primitives to enable a serverless architecture.
But if developers still need to write a lot of plumbing code/config to wire these services together into an app and deploy them, then that's just unnecessary friction. I don't think we should rely on the cloud providers to give us a blueprint for tying together our apps. This should be the role of specialised frameworks which sit across all the services.
There will always be those who shun all tools of convenience in favour of a long slog to get something working while jumping through as many hoops as possible just to be able to say they know all the inner workings of the tech.
But for the rest of us who just want to get on with shipping apps to our users, we can use a deployment framework and look under-the-hood only when we absolutely need to.
💌 If you enjoyed this article, you can sign up to my weekly newsletter on building serverless web apps in AWS.
Originally published at winterwindsoftware.com.
Top comments (8)
You should check out Architect arc.codes
It is hands down, the fastest at serverless deployment.
Yes, Arc has been on my radar for a while now but haven't yet been able to carve out a few hours to check it out. On the face of it, it looks really nice.
Have you used Serverless framework also? If so, what does Arc do better for you?
I have tried Serverless framework and found it configuration heavy and really slow at provisioning and deploys.
The first time I heard about this, I wondered how they managed to do that, that sounded impossible ... no server? where do you connect to? Where is the site coming from?
When I researched this and saw that it's hosted on 3rd party server, I was confused on the naming to say the least ...
Indeed. And Amazon naming their 'serverless' technology 'Lambda' was a horrible piece of marketing speak.
Should have called it 'Hat'.
Idk, seems a lot more convoluted than installing Postgres, uwsgi, nginx, Django on an Ubuntu server. And if I don't like the defaults or Amazon pricing I have ways out.
Suppose you have a small subset of endpoints in your Django app, and periodically traffic spikes drastically. For instance ingesting events based around an unexpected event (some real world event that's unpredictable). This traffic is 10x to 50x your max threshold traffic and you don't know when it might happen. What would you do in this case? Vertically scale your server to 5 - 10 times it's need for a single instance that is idle 75% of the time or more. Fail your users while you are manually scaling up. Horizontally scaling the full app across multiple VMs.
In the case of a serverless platform, this single endpoint can sit idle not costing anything then automatically scaling to the size needed and auto scale down to zero when not needed. Sure autoscaling groups can help with that, but you'd have to scale the entire app if not split out in architecture. Multiple developers working independently can deploy different endpoints at will as opposed to merging and deploying the full app. I'm still a bit unsure of serverless in production for a full application in a small team, but there are instances where there is no better option.