There is a new AWS serverless stack on the rise that you should know about!
AWS has been increasing its serverless service offerings and has also begun providing serverless options for existing services.
Companies and individuals who are concerned about vendor lock-in have historically tried to avoid using serverless offerings from cloud providers to avoid being dependent on their unique offerings.
Historically the standard AWS serverless tech stack consisted of services that are difficult to reproduce with OpenSource technology like:
- Amazon API Gateway
- AWS Lambda
- Amazon DynamoDB
- AWS Step Functions
- Amazon S3
- etc.
However, there is a new stack that doesn’t have this problem. This new stack can simply be run anywhere and with various OpenSource technologies.
The New Stack
How would a technology stack have to look like to be deployed almost anywhere? First, it would have to be open-source. Second, it would have to be considered an industry standard to be viable for most businesses. However, whether it’s processor types, hypervisors, operating systems, programming languages, frameworks, and so on, our industry has loads of varying opinions about most things and proprietary technology is a very common business model. However, there are a few that are very, wide-spread.
- Docker for running applications
- SQL for databases
Yes, NoSQL is on the rise, but if you look at most of the application full-stack frameworks, across languages, most of them either support or even only support SQL databases:
- Spring/Spring Boot in the Java world
- .Net in C#
- Django in Python
- Rails in Ruby
- Laravel for PHP
- NestJS for JavaScript (ignoring NextJS because it doesn’t have built-in database integration)
Here is what changed
With AWS Lambda as the compute layer and DynamoDB as the database. Developers had a choice to make.
Lambda was often not a great fit for existing frameworks and you typically need an additional dependency to interact with DynamoDB.
So, either bend the framework to work with Lambda or stop using a framework and completely adapt to the AWS stack.
Sticking to the framework could often lead to longer processing times and thereby higher costs.
This has changed! Last year AWS released a very interesting new service called Amazon App Runner.
Amazon App Runner
This service is interesting because it follows a different paradigm. With the API Gateway and Lambda stack, the web and application server were moved into the cloud provider layer and the configuration moved out of the application code.
All of the frameworks listed above bring application servers and expose endpoints, which were already covered by API Gateway.
With App Runner, the application server and API layer are now the responsibility of the developer but App Runner covers routing, scaling, and networking.
This makes frameworks first class citizens, because providing an application server that can process requests is exactly what a framework is for.
Now with frameworks back in the picture, all we need is a real serverless SQL database.
Amazon Aurora DSQL
Currently, DSQL is still in beta, but in my opinion, it’s a game changer. Before DSQL if you wanted to run a SQL database in AWS, you had to also run a VPC, Subnets, Route Tables, Internet Gateway, Security Groups, NACLs, NAT Gateways, etc. Now while one could argue that you can set these up once via Infrastructure as Code and be done with it, I dislike this. The reason is that if I have to set up the network, then I’m suddenly responsible for network-level security.
Meaning if, even by accident I change some routing or security group settings and expose my database. It's on me and suddenly I have to consider whether a team of application developers will be willing and skilled enough to run this themselves.
DSQL is a truly serverless offering (unlike previous Aurora offerings) where AWS provides an endpoint for me to access the database and handles all other network and system-level security for me. Meaning that I don't have to create a VPC etc. to provision DSQL.
The New Mental Model
Just judging by the icons this new stack doesn’t seem all that different I admit.
1. You change your infra less
You have to write the IaC code for App Runner and DSQL once at the beginning of the project. When you need a new endpoint, you don’t have to touch the IaC. When you need a new table, you don’t have to touch the IaC. When you want to change your database schema, you don’t have to touch IaC. You only have to care about your infrastructure when you have to make changes to your core platform. This is great because it allows you to stay in your application context more and you don’t lose time by switching context.
2. You can test locally more easily
Your local testing setup is much simpler. Start Postgres and you’re done. Well almost, your connection locally is set up differently than in the cloud and you manage secrets differently, but calling a running endpoint that talks to a database doesn’t require complex config anymore.
3. Faster onboarding
Developers don’t need to understand much about AWS to be productive. 100 lines of IaC is digestible. Especially if you don’t need to change them that often. Several hundred lines of IaC can be daunting.
Trade-offs
Don’t trust anyone that doesn’t tell you about the trade-offs.
1. Container image hardening
While it is possible to let AWS provide the image, I predict that most users will bring their own docker image and thereby be responsible for the security.
2. API Gateway features not available
Rate limiting, API keys with usage plans, and Cognito Authorizer are probably my top 3 features that either the framework would have to provide or the developer would have to implement them.
3. Cost currently unclear
This is probably the biggest blocker at the moment. DSQL is in public beta but currently there is no information on pricing and how AWS will charge for DSQL. This could make this stack not viable for a lot of use cases but we will just have to wait and see.
I’m excited about this new serverless stack and the new mental model it comes with.
I feel like it would be a great fit for developers who are annoyed by Kubernetes' complexity or the amount of IaC they have to manage.
Finally, for teams trying to move away from microservices to moduliths (or modern monoliths), this is the most viable stack if you want to stay truly serverless.
The beautiful Cover Photo was taken by Kari Sheas and published on Unsplash
Top comments (0)