There is often the sense that going serverless means going microservices and event-driven architectures, too.

That's NOT TRUE!

They are related but ultimately separate design choices.

So much of software engineering is about making smart choices. Often, when I see teams struggle to adopt serverless, it's because they try to take on too many new ideas at once.

A marathon, not a sprint

I have seen many ambitious teams that want to modernise their application and go from on-premise monoliths to:

• Cloud-native: leverage fully managed services as much as possible. This serviceful approach to building systems is what being "serverless" means to me.
• Microservices: break down a large system into subsystems, each specialising in a different business domain. Allowing them to grow, scale and fail independently.
• Event-driven: create loosely coupled systems by allowing them to communicate asynchronously through shared events instead of synchronous API calls.

On top of that, migrating to DynamoDB is often thrown into the mix.

That is A LOT of moving parts, and it requires many different experiences and expertise to navigate successfully. Expertise that most of these teams do not have.

Learning to do all this while you're expected to deliver tangible results under a looming deadline is very risky.

It's like trying to learn to juggle flaming swords and ride a unicycle at the same time... while you're on a tightrope!

A more prudent approach is to take a slow and steady path towards your goal.

Limit the scope of change

Limit the number of big (and risky!) architectural changes in one go. One is best; two is plenty, and three is probably too much.

If you're switching compute (e.g. EC2 -> Lambda) and database (e.g. MySQL -> DynamoDB) paradigms, then don't add microservices or event-drivenness to the mix.

De-risk along the way

Look for opportunities to de-risk, such as running your existing web application as a Lambdalith. Tools like Lambda Web Adapter, Serverless Express and Chalice all support this pattern.

That way, you can enjoy the benefits of Lambda (e.g. scalability) without refactoring your entire application and adopting a new set of software development practices.

Start small

If your team is new to AWS and the serviceful mindset (i.e. prefer using a managed service over custom code), then start by introducing a low-risk service to your stack.

Changing a database requires a lot of work. Moving to Lambda impacts CI/CD and development workflow. So maybe you can start by introducing S3 for blob storage. Or perhaps replace a custom-built scheduling service with EventBridge Scheduler.

It's not about being "serverless"

Instead of thinking about "adopting serverless", it's better to focus on reaping the benefits of serverless with the least effort:

• Scalability. For example, if your application struggles with traffic bursts, then Lambda can be a good fit because it scales very quickly.

• Cost-efficiency. Pay-per-use pricing is great for systems with relatively low throughput.
• Security and compliance. If you have dealt with compliance checklists, my condolences... but you'd appreciate why serverless is gonna be a win for you here!
• Agility and focus. Spend less time managing infrastructure and more energy building what your customers want. Oh, and don't confuse "configuring AWS resources" with "managing infrastructure"; they are totally different things.

Serverless-First, not Serverless-Only

We say "serverless-first" because we want people to leverage serverless technologies where it makes sense.

Your business changes over time, and as your context changes, you should adapt accordingly.

As I discussed in my retrospective of the PrimeVideo article, your architecture should evolve with your business needs.

Being serverless is not the point. It's not a religion.

For me, the best thing about serverless technologies is that they help me deliver customer value faster. Like that time when I helped a client launch a new social network in weeks.

When it comes to adopting serverless technologies in your organization, you too, should focus on finding value. If a move is risky, then find ways to de-risk and take smaller steps instead.