Advantages of Microservices: How Far Should You Go in Your Microservices Journey?
by Chris Riley
Tech is filled with bold statements and concepts. Statements like Kube-native: the push to have 100% Kubernetes environments; the idea that you should move all and any application to containers; and, microservices: an architectural style that organizes services as a collection used by an application, ideally increasing efficiency and reliability. But then there is the reality. How far should you take your microservices journey?
The idea of breaking applications into smaller chunks to improve portability, deployability, and the development process is not new. Microservices bring one radical new element. And that is that microservices are not only application design patterns; they directly impact many other areas in the development process that preceding design patterns did not. They are:
- Culture: Yes, I said it. Everything that follows in this list, is not possible for an organization that doesn’t have a culture that learns from failures, without punishment; moves quickly; and embraces change.
- Team Structure: Microservice architecture is not only the segmentation of your application but also the segmentation of your development team. Smaller teams structured per service can be utilized. This allows functionality for individual services to be released independent of the broader application. This is a huge benefit. It also means that each microservice has an independent life cycle, and your delivery chain must support that. Organizations need to realize that when they move to microservices, they likely will be impacting their team structure as well.
- Infrastructure: Microservices are as much an application design pattern as a statement about your application infrastructure. This means that when organizations embrace microservices, each action on the application side during the implementation will result in an equal (but not opposite) reaction on the infrastructure side. Microservices will determine things like your instance sizes, DNS, high-availability, regions, etc. Also, in an ideal scenario, microservices will be immutable and stateless. That means they will generally have short lifespans and the infrastructure needs to support this.
- Site Reliability / Production: Microservices do not necessarily make supporting the application more difficult. But they do have an impact when incidents occur and there is more context needed to identify the cause of the issue. The context now needs to include details of affected services, and also the team needs to quickly know if the relationship of one service to another is the cause of the issue. This can be achieved through observability.
- Testing: New testing strategies need to be developed to make sure the move to microservices does not reduce your test coverage or diminish your application quality efforts. You are now testing the relationship between services in an asynchronous way. This could involve contract testing, application mocks, and service virtualization.
- Documentation: Documentation is dreaded by all. In the old days, documentation was a ‘set it and forget it’ sort of thing. In modern applications, documentation is dynamic. It should be automatically created via the tooling you use. And, in your scripted infrastructure, the scripts themselves are the documentation. With microservices, there is a new element that is documenting the relationship of the services. Building this is critical, but should not be a process of creating diagrams on a daily basis. It should be automated. The trend is to use what are called ‘contracts’ to document the structure and communication from services. And because services often interact with APIs versus instances directly, the API transactions are also a source of documentation.
- Stack: Some development languages and application backends are more conducive to microservices than others. The stack your application is built on could impact your transition to microservices. Additionally, backends do not tend to be containerized or turned into services because, by design, services tend to be small. However, there are a lot of mechanisms to use persistent storage, where the backend is not actually running on the service, but dynamically linked to it, and the service represents the business logic to the data. You still need to evaluate your application stack to know the pros and cons as it relates to a microservices architecture.
This list is not meant to discourage the use of microservices. For many, this is the exact list used to justify why to use microservices. Improved culture is critical to bringing DevOps principles into your organization. Small teams can actually increase collaboration and get functionality out the door faster. More portable infrastructure allows you to support your application across more regions, embracing multi-cloud and taking high-availability (HA) to a whole new level. In short: there are many advantages of microservices.
I did not include security on this list because once a good security model is set up, the implications of microservices on your attack service should not be any different than any other environment. What is different is that there are more moving parts, and knowing this in advance should allow a SecOps team to build a strategy that, once set up, is the same as if your application was running on a single server under someone's desk.