Radical Simplicity in Cloud Architecture
For a long time, both professionally with clients in my consulting work and in the AWS community, I've been evangelizing the "serverless" paradigm shift. To me, it's crystal clear that you should focus on building what differentiates your business, and not on managing infrastructure or solving problems that are already solved by others. The term "serverless" may have been watered down by marketing in recent years, but the core idea of utilizing managed services and focusing on business logic remains.
People argue about cold starts, vendor lock-in, or learning curves, and while they are valid concerns, I believe that the benefits of serverless far outweigh the drawbacks - especially when you consider the total cost of ownership over the lifetime of a project. But I'm not here to argue about these concerns today, I'm here to talk about something else.
Luc van Donkersgoed covers some of these concerns and others in my favorite blog post of all time here. Go ahead and read it but pinky promise you'll come back!
Today I want to talk about an aspect of serverless that I think is often overlooked: the developer experience and the unexpected use cases of "boring" technology that emerge when it's exposed in the form of a radically simple to consume and configure managed service.
Your personal production environment
Do you know how many lines of code or clicks in the console you need to set up a DynamoDB table? An S3 Bucket? A Lambda function?
The answer is about 2.
This sets up a service that will scale to virtually any load, without further configuration. Perhaps more importantly though, it also scales to 0, and you literally pay nothing when it's not being used.
People tend to focus on the scaling up part, not realizing what the scaling down part actually entails. It's not just about saving money, it's about the freedom to experiment and build things in a way that you wouldn't have otherwise.
Want to have a personal carbon-copy production environment? Sure, hit deploy and have it ready in 30 seconds and it will always be free.
When you merge code to main, you can be absolutely certain that it will work exactly the same in production as it did during development, because you've been testing in "production" all along.
Want to spin up an ephemeral environment on every pull request, run integration tests against it, and tear it down when the pull request is merged? Sure, it's literally a few lines of code and it will cost you nothing.
And once these resources are deployed, you will never have to worry about them again. They will scale up and down to meet demand, there is nothing to patch or maintain, and the availability and security of the services will be the responsibility of one of the most experienced and capable companies in running cloud infrastructure in the world - so that you can spend your time where it actually sets you apart.
Gone are the days of sharing a database in the development environments to keep cost down. Gone are the days tinkering with scaling groups and load balancers. Gone are the days of waking up in the middle of the night to patch a vulnerability.
When the log4net vulnerability was announced, I was working in the platform services team at a major automotive company running hundreds of workloads in AWS. Do you know what we did to patch it? Not a damn thing.
The same company at one point ran a superbowl ad and traffic was naturally expected to explode. Do you know what we did to prepare for it? Not a damn thing - we sat back to enjoy the show.
The idea that serverless compute is more expensive than traditional alternatives is less and less true the more you look at the full picture and lifecycle of your applications. Is there a break-even point where it becomes more cost-efficient to move away from it? Sure. But I'd argue that that point is way (way) higher than you'd think if you consider the total cost of ownership. That is, not only the compute layer itself, but also:
development environments and feedback loops
labor cost of maintenance, configuration management
overprovisioning to meet demand, or underprovisioning and risking business objectives, and the labor of finding the right balance
the opportunity cost of not spending time on what actually matters to the business
This isn't meant to be a blanket statement claiming that serverless is always cheaper. But it is cheaper in more cases than you might think at first glance. It's also not a binary choice. Employing a serverless-first strategy is wise, where you default to “more serverless” and move further back in the abstraction spectrum as needed, with parts of your application (or application landscape) being serverful where it's more fitting.
Unexpected Use Cases from Radically Simple Services
Traditionally, setting up a globally distributed, highly available database required intricate configurations: manual sharding, complex replication setups, and constant vigilance to maintain consistency across regions. This complexity often deterred teams from pursuing global distribution, limiting application performance and resilience.
Enter services like DSQL and DynamoDB Global Tables. With the latter as an example, you can select the regions where you need your data replicated, and DynamoDB handles the rest, eliminating the complexity and operational burden of deploying and managing multi-region replication. This means that updates performed on a replica table in one region are automatically replicated to the replica tables in other regions, ensuring low-latency access for users worldwide. By abstracting away traditional pain points, fully managed services make many problems that were previously very hard and costly to solve completely disappear.
And this pattern repeats itself across many other services and problem domains. Whether it's APIs with API Gateway, Cron jobs and scheduled tasks with EventBridge or workflow orchestration with StepFunctions - what once required dedicated infrastructure, maintenance, and tuning is now an API call away.
When you have managed services that are so simple to consume and configure, you start to see unexpected use cases for technology that you wouldn't have considered before.
My friend and colleague Elias Brange has two perfect examples of this.
The first one is covered in his blog post "Test Event-Driven Architectures with EventBridge and AppSync Events" where he explores the idea of using AppSync Events (a managed Websockets API) to test event-driven architectures end-to-end. Spinning up a websockets API as part of your test suite and streaming events through it to test your system's behavior is a brilliant idea, and it's a fantastic solution to a problem that's hard to solve with traditional tools.
The other one is about spinning up a Wiremock service as a Lambda Layer to mock external services during early development or as part of integration tests without the need to change any application code.
While it's obviously not a new idea to mock external services, the simplicity of setting up a Wiremock service in a few lines of code, deploying it as a "sidecar" to your dev stack, and not having to pay a dime for it is, honestly, a game changer.
If you talk to developers who've been working with serverless for a while, you'll find that it's not uncommon for many of them to have tricks like this up their sleeve.
Conclusion
When you really start to lean into the serverless paradigm shift, you realize that perhaps the biggest benefit isn't just avoiding infrastructure management or infinite scalability. It's the ability to focus entirely on solving business problems instead of wrangling things that "should just work. It may even unlock new ways of thinking about how you can use technology to solve problems that you wouldn't have considered before, and in, dare I say, the vast majority of cases, it will be cheaper in the long run.
Hi there, I'm Sebastian Bille! If you enjoyed this post or just want a constant feed of memes, AWS & serverless talk, and the occasional new blog post, make sure to follow me on 𝕏 at @TastefulElk or on LinkedIn 👋
Elva is a serverless-first consulting company that can help you transform or begin your AWS journey for the future