Serverless can be Monoliths, and it can be a great fit
|
There's a common misconception that serverless architectures must use microservices. That's not true! Most of my serverless architectures are monoliths. And no, you don't have to use "lambdaliths". While lambdaliths and monoliths are related, they are ultimately different concepts. What is a monolith anyway?I consider a system to be a monolith if it has:
A monolith API (judged by that it does everything) backed by a Lambdalith is a monolith. A Lambdalith with a Function URL is also a monolith. What about an API backed by multiple Lambda functions, one for each method? Yes, it's still a monolith. Everything is still in one codebase. Everything is still deployed in one deployment. The API is all-encompassing (it's an API that does it all), as in the previous two examples. All that is different is how your code is organized into Lambda functions. And the functions might even share the same deployment artefact. And what about an AppSync API backed by multiple Lambda functions and DynamoDB tables? Again, it's a monolith with a single codebase, single deployment, and an all-encompassing API. Why build monoliths?For small teams, monoliths simplify the development workflow and give you more agility.
It's simplicity personified. ScalabilityMonoliths are just as scalable as microservices. If you don't know how to scale a monolith, then you don't know how to scale microservices. Because it's the same pattern. For example, Supercell handled over 100 million daily active users on its most popular games with a monolith. It was a JAR file running on thousands of EC2 instances, communicating with a sharded MySQL database. Microservices do not help you scale an application. It helps you scale an organization, allowing hundreds or thousands of developers to work on the codebase simultaneously. In microservices, clearly defined boundaries are necessary so teams can have the autonomy required to achieve mastery and purpose. Wrap upConway's law states, "Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations." In a small team, where everyone communicates with everyone else, a monolith is a perfect fit. |
Master Serverless
Join 16K readers and level up you AWS game with just 5 mins a week.
A common challenge when building APIs is supporting multiple live versions without letting the system turn into an unmaintainable mess. You need to keep older versions running for existing clients, roll out new versions safely, and avoid breaking changes that might take down production. And you need to do all that without duplicating too much infrastructure or introducing spaghetti logic inside your code. There’s no official pattern for versioning APIs in API Gateway + Lambda. API Gateway...
I recently shared six event versioning strategies for event-driven architectures [1]. In response to this, Marty Pitt reached out and showed me how Orbital [2] and Taxi [3] use semantic tags to eliminate schema coupling in event-driven architectures and simplify the schema management. It's a novel way to manage schema evolution, and I want to share what I learnt with you. Problems with Schema Coupling In an event-driven architecture, event consumers are typically coupled to the schema of the...
Last week, we looked at 6 ways to version event schemas [1] and found the best solution is to avoid breaking changes and minimise the need for versioning. But how exactly do you do that? How can you prevent accidental breaking changes from creeping in? You can detect and stop breaking changes: At runtime, when the events are ingested; During development, when schema changes are made; Or a combination of both! Here are three approaches you should consider. 1. Consumer-Driven Contracts In...