The Balance of Serverless Simplicity

Beware merchants of complexity, but don't settle!

A clash of worldviews has emerged in the last couple of years, brought to the surface by certain well-known companies leaving the cloud as well as some equally well-known teams announcing that they’ve saved a lot of money by embracing the monolith.

This conflict boils down to simplicity versus complexity. Critics argue that the cloud is overly complicated, designed for large enterprises. Just look at the myriad of AWS services—can anyone truly remember them all, let alone use them effectively? And microservices? They’re just as convoluted. Why not embrace the "Majestic Monolith," which is far easier to manage?

Having immersed myself in the cloud and championed Serverless for years, I don’t find myself especially sympathetic to these arguments. Yet, I can’t deny that they resonate with me on some level.

I don’t advocate for on-prem solutions; I genuinely believe Serverless is the way forward for most businesses. The cloud empowers us to focus on our core business logic while leveraging high-performance products and services that would be impossible to replicate on our own.

I also don’t think microservices are inherently bad. Throughout my career, I’ve supported teams in transitioning to microservices, as they help maintain order and cleanliness in our codebases.

Without exceptional discipline, monoliths can devolve into chaotic jungles. Microservices allow us to move quickly, with different teams owning distinct services without stepping on each other's toes.

And yet, there’s something undeniably appealing about the simplicity of tools like Kamal. With just a few lines of code, you can bypass much of the complexity and launch a production-ready application on your server of choice.

Let’s be honest: the cloud can be daunting. While I’ve greatly benefited from re:Invent talks and keynotes, many of them feel more like advanced computer science lectures. This complexity raises a question: aside from major enterprises like Amazon, who truly benefits from such an intricate array of services?

Startups need far less. The fundamental building blocks of Serverless—Lambda, Dynamo (or DSQL), AppSync, and EventBridge—can take you almost anywhere you need to go as a business.

This brings us to a middle ground.

There are builders and architects aiming to create scalable solutions—not monoliths, not on-prem, and not limited to small VPS setups. They may not have a large user base yet, but they’re designing for growth because they believe in their vision.

However, attending cloud events or consulting microservices experts often introduces layers of complexity and bureaucracy that can be overwhelming.

This middle space is for those who want to harness Serverless to build highly scalable microservices in the cloud—without breaking the bank or feeling inferior just because larger enterprises are tackling more complex challenges.

I refuse to settle, but I also don’t want to feel like I need a team of 500 engineers to bring my product to life.

The allure of Serverless has always been its ability to enable rapid, cost-effective scalability with a small team.

That’s the space I’m excited about!

I want to challenge myself to learn from the no-cloud, no-microservices community and I want to take their learnings into the world of cloud and microservices. I want to strip my world out of all complexity, and make building highly scalable products exciting, intuitive, and simple.

I’m excited about HTMX as a way to enable server-driven, truly fullstack development. No more rigid separation between the React experts and the backend-only folks. With HTMX, everyone can build fully functional applications without a phD in frontend development.

I find Hono absolutely delightful. What a great way to build simple, fast APIs that deploy just about anywhere. I think that the so-called best practice of one Lambda function per API endpoint has been overused and abused. You can have a single Hono-based Lambda handling a whole bunch of routes. It’s fine, and it’s plenty fast.

I’m thrilled about Amazon’s DSQL. I feel like a whole lot of complexity over the years has been forced on us as we tried to shoehorne all of our use cases into using DynamoDB. Frankly, we didn’t have a choice because relational database alternatives on AWS were never truly serverless. So we convinced ourselves that it was actually cool and properly serverless to pour hours into designing the perfect Single Table Design data modelling for our Dynamo tables. I’ve personally had enough of that. I’m looking forward to defaulting to a good old relational database unless something that screams “key-value” calls for the use of Dynamo.

There may other tools or technologies that I’m not yet aware of that can remove layers of complexity from our development lifecycle. I will be on the look for those moving forward.

No more blindly accepting what the enterprise thinks is right. Startups are different, and we don’t have to settle.