Mariano daily helps companies that wish to modernize their applications embracing µ-services & cloud
So here's the thing: you are an experienced developer thrilled by the opportunities of serverless architectures. You read books, watch any possible video courses but when it comes to starts building a real serverless solution you feel completely naked; like if you are missing something.
Over the years I have taught many developers and architects who had the same problem as you and all did one thing, apparently sensible but useless in practice. All of them focused (erroneously) on serverless, but serverless is just an execution model, things that matter are elsewhere.
Serverless is many things. It could be a serverless database, serverless storage, serverless runtime, and so on. It goes without saying that the latter represents the glue that binds any other serverless component together, so this is where we have to start.
In this scenario, we have mainly two options: serverless runtime based on containers (e.g. AWS Fargate) or serverless runtime based on functions (e.g. AWS Lambda or Azure Functions). Despite differences, they have one thing in common: to work at their best, the applications hosted should be made of many small services rather than a single monolithic one.
Microservices architectures are an architectural style that structures the application as a collection of small services. These services can communicate with each other so they can resolve a more complex business scenario.
When these microservices have to be deployed, we can do so using containers or, if we prefer, using functions.
Microservices is a design concept. Containers or functions are just deployments offers.
If you want to be successful in serverless adoption, you will first need solid microservices’ knowledge. Only in this way you can be prepared and avoid the common pitfalls of serverless adoption.
For this reason, I grouped together five books that every good serverless developer must read, and surprise, these books are mostly about microservices, rather than AWS, Azure, or serverless.
We said that microservices are a collection of small services. But does that means that microservices have to be small? How small they need to be?
To answer these questions properly, we need to understand the business capabilities and design accordingly and that's all this book is about.
The volume is full of information and insight that would worth reading at least twice. People usually tend to focus on chapters 5 and 6 where the author defines the concept of Entities, Value Objects, and Aggregates, commonly known even outside the DDD community today.
Even though these components are crucial I strongly suggest focusing attention on Ubiquitous Language and Bounded Contexts. These concepts are core to our needs because can help to answer the question: how small a microservice should be?
If you are new to microservices this is where you have to start. The book is generic enough and doesn't require any knowledge of a particular programming language, that's why I love it at first.
The first three chapters start with a great introduction about the software world and microservices, then the book is well divided into categories (one for each chapter): Integration, Deployments, Testing, and so on, which makes it handy to find and (re)read a concept in the future.
I fell in love with this book at the time because it explicitly talks about messages. The author invites the reader to avoid the temptation to design systems start thinking about services; rather he suggests starting from messages as their flow well describes the system behaviour.
This way of thinking allows us to feed two birds with one scone. First, it naturally drives you into event-driven applications. Second, it simplifies the design of your system (in this regard, I strongly suggest taking a look at Alberto Brandolini's Event Storming workshop).
Back to the book, as microservices completely change the way we think of data, Chapter 4 is essential, as you may discover a lot of things that will be useful when you are building serverless applications.
Same for Chapter 6 (i.e. Measurement) which talks about the limits of traditional monitoring when it comes to microservices and FaaS.
After a first introduction to the world of microservices, we can see in detail what are the industry best practices that we should adopt.
In addition to a ritual introduction, the book focuses on what are the decomposition strategies, or how to think in terms of microservices and here Domain-Driven Design and its teachings come useful.
Do you have a doubt about testing? Want to learn more about deployment strategies? Have you heard of patterns like circuit-breakers or saga but you don't know what they are for? Then this book is the most authoritative source in which to find the answers.
After four books of theory, we close the series with a practical book, a real hands-on tutorial.
The thing I like most about it is that, like for the Tao of Microservices, it too focuses on messages. It starts with these two hot topics - CQRS and Event Sourcing.
We often read posts about the benefits of serverless; as I’m a strong advocate for serverless adoption I like to share these posts. However, the problem with this type of post is the illusion of having a silver bullet in your gun. This is not true as silver bullets do not exist.
Serverless is a powerful weapon but you need to be trained or the recoil could hurt you. This post would like to prevent the problem.
Disclaimer: Commissions may be earned from some of the links above.
Create your free account to unlock your custom reading experience.