I love serverless, but it got something dramatically wrong

This is a repost of a recent Twitter/X post:

Serverless too closely coupled the underlying cloud infrastructure with your app and business logic. This not only creates a bifurcation of business logic akin to Stored Procedures, but in many cases, ties the performance of your application to the architectural decisions you’ve baked into your app code.

Rather than deploying apps to environments designed to support them – maintained, monitored, and optimized by platform engineers, serverless requires “developers” to understand the impact of choosing one statically configured primitive over another.

This *is* hard. The expectation that any one person can understand the complexities and nuances of several AWS (or other cloud providers’) services, while also being a competent Java, Rust, Python, etc. developer is naive at best. What you don’t know you don’t know is MUCH worse than what you know you don’t know.

I interviewed a 22 yo kid one time that said he was an EXPERT at Microsoft SQL Server. When I asked how long he had been using it, he replied, “Almost a year!” 🤦‍♂️

This isn’t only an incredibly stupid thing to say, it’s extremely DANGEROUS! You’re just one misconfigured Retention Policy, public S3 bucket, or IAM “*” permission away from something very, very bad happening. And this is why Terraform dominates the market, because most devs probably SHOULD NOT be trusted to deploy whatever they want to the cloud.

Platform engineering has been around for quite some time now (despite the recent buzz), and that’s because organizations are trying to allow their developers to be more productive, but in a way that doesn’t compromise security, performance, and cost.

There are plenty of Infrastructure As Code (IaC) tools that shift these burdens onto the developer. Lots of them are very good for those developers looking to move towards cloud architect roles (which are definitely needed in modern organizations). But all of these tools presuppose that developers actually want this! Or perhaps, even more naively, assume that working developers that don’t spend all day on Twitter (or X) actually have the time to invest in learning new services and digesting the latest feature added to Lambda (and how it could impact/help their customers).

I will reiterate: I LOVE #SERVERLESS. I think that deploying applications using serverless technology when possible is the fastest way to build highly resilient, global scale, virtually management free solutions. But upskilling an organization to get to that point can take years, succeeding only after running hundreds of experiments and having suffered countless failures.

I believe that the vast majority of developers just want to write code, and more importantly, solve their users’ problems. But developers also need to be able to harness the power of the Public Cloud. In order to do this, a radically different approach is required.

This is why we built Ampt. Not because we’re trying to restrict developers, but because we’re trying to FREE them. If you’re curious what this is all about, be sure to join our Launch Day livestream on September 20, 2023.

Serverless Caching with Momento and MongoDB

A lot has changed in the 8 years since I started building serverless applications. What used to be a great tool for a limited set of use cases has turned into an extremely powerful ecosystem filled with products, services, and frameworks that not only negate nearly every objection, but allows developers to build native cloud applications very quickly. Recently there have been numerous investments in “serverless databases” to bring familiar RDBMS offerings to the growing number of serverless workloads. I’ve seen some very promising progress in this area, but for me, I’m still a big fan of using NoSQL solutions with my serverless applications.

Don’t get me wrong, I love the capabilities of MySQL and Postgres, but NoSQL databases have a combination of flexibility, scalability, and connection methods that highly complement a serverless approach. I have a lot of experience with Amazon DynamoDB and Cassandra, both excellent solutions for the right use cases, but I’ve always loved MongoDB and the flexibility of its query language. About a year ago, MongoDB made a serverless version of their MongoDB Atlas service generally available, which prompted me to take another look. I’ve been impressed so far, and I look forward to even more progress.

Even though MongoDB is widely appreciated for its flexibility and versatility, like any database system, when you scale up and usage increases, performance will likely take a hit. That’s where caching comes in. Traditionally, the problem with caching in serverless applications, at least in the AWS ecosystem, is that you had to both run your Lambda functions in a VPC (which limits access to the Internet without a Managed NAT Gateway) and you had to provision an ElastiCache cluster and manage it yourself. Then late last year, I discovered Momento, a serverless cache that was truly serverless. You only pay for what you use and it instantly scales to meet your workloads. Serverless had been missing a great caching solution, but now with Momento in hand, we can do some pretty amazing things without adding all that extra overhead.

In this post, let’s take a look at some of the benefits of adding a serverless cache like Momento in front of your MongoDB cluster, as well as some real world examples where caching can supercharge your serverless application backed by MongoDB.

Continue Reading…

Serverless take the wheel

More control is a good thing, right? I mean, who doesn’t want the ability to twist every knob and tweak every settings to your heart’s desire so that each minute detail of your infrastructure is artisanally handcrafted? I’ll tell you who: this guy! Why? Because I have neither the time, energy, nor expertise to even begin to understand the impact of most of those configuration changes. Not only that, but I likely don’t even have the information needed to understand which optimizations are required, let alone a way to prioritize them.

Continue Reading…

The side effect of increasing developer responsibility

It wasn’t that long ago that the vast majority of developers didn’t worry much about infrastructure. Sure, there were plenty of us configuring Linux servers and setting up the occasional MySQL database, but that certainly wasn’t the norm. For those that worked in larger organizations, your code was likely checked into perforce or subversion, and then magically ended up in production (some days, weeks, or even months later). For many, this is probably still how they ship code.

Continue Reading…

Not so serverless Neptune

Several years ago I wrote a post asking people to stop calling everything serverless. I even gave a keynote at Serverless Days Milan the following year pleading the same message. My contention was quite simple: “when everything’s serverless, nothing will be.”

Back then, “serverless” was still relatively new, and the possibilities were seemingly endless. Sure, there were a few people starting to mislabel things, and of course, haters were gonna hate, but for the most part, the argument was less about the nuances of the technology and more about the “nature” of serverless and the serverless-first mindset. But then something changed.

Continue Reading…

The cloud isn’t the issue, you’re just using it wrong

#Tech Twitter was all abuzz recently after DHH boldly proclaimed and explained why [37signals is] leaving the cloud. A lot of people cheered, some of us jeered, and everyone else just pitched web3 as an alternative solution. DHH’s success has earned him a giant platform and a tremendous amount of influence, and while I often disagree with him, it’s clear that many others do not. I spent quite a bit of time reading through all the retweets, reposts, comments, and hot takes, and I came to a fairly simple conclusion: these people are using the cloud wrong.

Continue Reading…

Getting abstractions wrong with AWS SAM Serverless Connectors

I was intrigued when I first saw the announcement of AWS SAM Serverless Connectors. I don’t use SAM very much (if at all anymore), so it wasn’t the hope of this being some sort of silver bullet for my occasional IAM frustrations that got my attention. Rather, it was another opportunity to learn how AWS is trying to abstract away their mostly self-imposed complexity problems. Unfortunately, I think they missed the mark on this.

Continue Reading…

Cloud Native versus Native Cloud apps

I’ve been spending a lot of time lately thinking about the next evolution of the cloud, and more importantly, what the developer experience looks like. A few years ago, I think that most of us in the serverless ecosystem thought that the path forward seemed quite clear. Serverless-first was obviously “the way.” Small, discrete, single-purpose functions interconnected through a series of planet-scale, self-upgrading, managed services with built-in redundancy was the holy grail of cloud development.

Of course there were some gotchas in there, and not every use case was a perfect fit, but over time we figured these would be addressed as the technology evolved. For the most part, that has come to pass. Even if AWS hasn’t quite yet solved some of these issues, other cloud providers and startups have certainly tried. But while serverless was slowly preparing to cross the chasm, another already widely accepted technology was gaining traction in the cloud: containers.

Continue Reading…