Microservices are getting very popular these days. This type of software architecture has a lot of advantages like flexibility and ease at scale. Mapping them into small teams in an organization also gives a lot of efficiency in development.
However, going on the adventure of microservices knowing only the benefits is a wrong call: you need to know what you are facing and be prepared for that in advance. You can get a lot of knowledge from many books and articles on the Internet but, when you get hands-on-code, the story changes.
When you start reading about microservices you get more and more convinced that’s the way to go. If you’ve worked in software development in the past, you can’t do anything else but be delighted by how microservices will solve all your problems, you become a monolith-hater. Luckily, some of these books also offer a critical view and tell you what to consider when starting with microservices.
In any case, monolith-haters like me tend to just focus on the advantages and not on the pitfalls described on some of these sources. Or, even worse, we underestimate what we have in front of us: Service Discovery, Routing, Communication between microservices, Testing end to end, etc. Easy peasy, we’re experienced developers: it will be fun.
My recommendation is to be very critical with all these articles and books which only sell advantages of microservices, and to pay special attention to the drawbacks on the articles and books that describe them. Try to match those advantages and disadvantages to your case and then think: is it worth? And, if it is, prepare a smooth plan to integrate a microservices architecture in your project. Avoid embracing the hype and going microservices without thinking about the consequences.
Microservices from the Ivory Tower
When you buy a book about IT, it comes frequently with code examples to illustrate the concepts. However, the reading resources covering microservices are frequently written from a safe place, talking about them from an Architecture Ivory Tower from which you can explain everything with boxes, arrows and fancy words (CQRS, Netflix, Eureka, Zuul…).
It’s true that you need to understand all these concepts when you work with microservices: how to achieve loose coupling, how to make them discover each other, how to route from a centralized place, etc. Those are essential. The only problem is that if you haven’t worked with microservices yet (and that’s why you normally buy a book), how can you analyze the practical case and the problem you’re trying to solve with those tools or frameworks? It’s only when you get hands on code when you experience the problems and understand the solutions.
The practical way
Trying to provide a practical view on microservices, I’ve written a book that starts from the basics and goes through the way of setting up a microservices architecture:
- Start with a small monolith
- Analyze when and why you can benefit from microservices
- Introduce the second service
- Connect them together using Event Driven patterns
- Understand the tools: why do we need things like Service Discovery, Load Balancing, Routing, Circuit Breaker patterns…
- Include a good baseline of tests, and how you can do end to end tests with microservices easily (using Cucumber)
The book guides you from the Ivory Tower to the Cave, explaining the concepts and then illustrating them with a reference application that grows along the chapters. The microservices are written using Spring Boot and Java 8, and the tools provided by Spring to set up everything around them: Spring Cloud Netflix, Spring AMQP, etc.
If you’re interested in the book, you can find it on LeanPub and also on Amazon (hover your mouse to pick your local site). It’s now finished, but I’ll also add some extra concepts in the coming months to cover extra concepts.
You can find also a more detailed description on the book page on both platforms.