Microservice - Architectural Pattern Explained
Making decisions in system design is all about trade-offs, and microservice architectures give us lots of trade-offs to make ― Sam Newman
Microservices are a design that decouples solutions and supports smaller releases into production, however, with the flexibility comes increased complexity in release infrastructure. This blog helps the reader understand when you should and shouldn’t use microservices
Buzzwords
It seems to be a buzzword but like many others, it is often misunderstood. An example of this is DevOps — a few years ago a lot of people thought DevOps was about automation.
Let’s define what a microservice is and look at the typical components.
Why Microservices?
Many companies have large complex applications, leading to maintenance headaches which over time slow down a company’s ability to react quickly to change.
Typically, a new requirement would come in, it would get refined and development would start without looking at the bigger picture. Once Feature X is developed, it would have to be a big bang deploy, risking stability to other parts of the app.
Large releases which can impact many parts of the system have a higher risk than small targeted releases. I have been the guy at the end pressing the button with fingers crossed that it will all go smoothly. These are scenarios that microservices help to solve.
What are they then
When you write your application as a set of microservices, you’re writing multiple applications that work together. Each microservice has its own distinct responsibility and teams can develop them independently of other microservices.
You are technically writing micro applications to solve a specific business problem.
The only dependency between them is the communication. As microservices communicate with each other, make sure messages sent between them remain backwards compatible. This requires coordination, especially when different teams are responsible for different microservices.
The dependency between them is the communication.
Microservices do not have a defined size, although the idea should be to keep them as small as possible. A rule from the 1970s when software engineering was studied extensively was that good software is loosely coupled but highly cohesive.
Typical attributes of a Microservice
- Maintain their own state and lifecycle
- Incorruptible from other systems. Changing another system when deploying cannot break it. The biggest challenge is compatibility
- Small and target specific business operations
Advantages
- You can write, maintain, and deploy each microservice separately
- A microservices architecture should be easier to scale, as you can scale only the microservices that need to be scaled. No need to worry about the parts that do not scale
- It’s easier to rewrite application because they’re smaller and less coupled to other parts (once you have a good understanding)
Disadvantages
- Contrary to what many people will tell you, it’s harder to write than monoliths, more skill is needed to write a good microservice as all concerns need to be understood, logging for example
- Adds complexity to DevOps setup and release management because every microservice needs its own release management
Ideal for:
- Applications that need to scale
- Services that provide functionality to several other applications
- Applications that would become complex if combined into a large system
- Applications where clear boundaries can be established
Conclusion
Microservices decouple your applications and give great flexibility, allowing you to deploy only microservices which have changed. This flexibility comes at a cost because it’s harder to write microservices and you need an experienced DevOps teams to deploy and manage them.
Futher reading
Join the Capgemini Microsoft team, open roles here.
