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 are the new paradigms and changes that you will face and prepare for that in advance. Books and articles can provide you with some knowledge but, when you get hands-on-code, the story changes.
When you start reading about the subject 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 dream about 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 before starting the new endeavor.
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. We believe those are easy because 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. On the other hand, pay special attention to the drawbacks that some other articles and books describe. Try to map those advantages and disadvantages to your case and then evaluate risks and benefits. And, if it’s worth it, prepare a smooth plan to integrate a microservices architecture into 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 topics 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 into the mud when you experience the problems and understand the solutions.
The practical way
Trying to provide a practical view on the topic, I’ve written a book that starts with the basics and goes through the way of setting up a microservices architecture:
- Start with a small monolith
- Analyze when and why you benefit from microservices
- Introduce the second service
- Connect them together using Event Driven patterns and REST APIs
- 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.
Do you want to know more? Watch this short video-introduction of the book: