Key Takeaways Microservices is an approach of breaking up software into services that are small and do one thing well. Key benefits of microservices: smaller, more productive teams, reduced risk of change, faster software delivery, lower risk to introduce new technologies, lower risks and costs of replacing systems, and reduced costs of migrating and operating […]
The microservices approach describes a way to build software that prescribes breaking an application into multiple, small, independent services, each tackling one major functionality. These services are independent with regards to technology, infrastructure and the team responsible. This means that they can each be built using different technology, deployed on separate infrastructure, and managed by separate teams, yet they all combine to make a single system. This also means each service can be changed and be delivered independently of the others. One classic example is Amazon’s product description page – it uses several microservices for the different sections, like related products and reviews.
Large software is often difficult and expensive to change, and it can be risky due to multiple dimensions of size-based complexity. For example, it is easy to get something wrong and introduce unintended problems. You may have to re-deploy the entire application for a single change no matter how small. That often means infrequent deployments that are much more risky and require significant overhead, and that contain a larger batch of changes that adds to the likelihood of unintended consequences in production. Microservices can help with these areas since an application is broken up into multiple, independent pieces that can be independently deployed. They can also be changed at much lower risk since they are very self-contained and contractual, and versioning measures are taken to ensure they are serving what’s expected to dependent services.
A microservices approach also lowers the risk of introducing new technologies. Different teams can use a different technology stack for the microservices they manage. It is easiest to introduce new technologies into small projects, and microservices by definition are a group of small projects that combine to make a larger system. Thus, using low-risk microservices to experiment with a new technology at your organization can be a key way to keep up with modernization. This also enables more productive teams. Each microservice is owned by a team – when projects are revolved around smaller services such as these, there can be smaller teams, which are often the most productive.
The cost and risk is also typically less for replacing microservice-based systems. You can more easily replace a system piece-by-piece. You can also do it when it is most strategic and you can use the technology most suitable for the job and team. You’re not locked into existing technology. You can also use a microservices approach to help reduce costs of migrating and operating in the cloud; if you follow an incremental approach which microservices facilitates – the migration pace is more efficient, the error rate is lower, and it’s easier to set up a cloud infrastructure to build upon.
There is indeed an overhead to all of this and trade-offs to consider. Microservices bring in more complexity. Often though, it’s better complexity. What does that mean? It requires an additional level of experience on development and ops teams, so the software architecture can be properly implemented with the supporting automation, testing and monitoring infrastructure. Developers must know the business domain well to create services that are broken up correctly. New attention needs to be paid to the challenges of distributed systems such when communication fails between services. These are largely challenges that are readily solvable and much easier as tooling gets better and better. The complexity you deal with in a very large, monolith (singular, non-microservices) system is often harder, and less natural and standard to deal with than the complexity with microservices.
There can also be the overhead of multiple technologies if you employ that as microservices allows. There can and often should be reasonable constraints in an organization so new technology can be experimented with in a reasonable way, and a healthy mix of technologies exist without there being a needlessly large number of different technology to know and manage.
Getting started is the most daunting part as there is initially a lot to do. Many experts say microservices are actually not even the best place to start with a new application. Microservices provide the most benefit when the system is large enough to justify the overhead. Beginning with a monolith then starting to slice off microservices as needed can be a good approach. Also, it’s easier to see how to break up the system into services once it is reasonably developed out.
Regardless, you should start small. Carve out a few microservices to create from an existing system or within a new system on a low-risk project. Allow your team time to adjust and learn the right level of microservice granularity. Have a training or hiring strategy, to ensure you get the experience and skills required. Be prepared to invest up front into building the supporting infrastructure, which often requires team learning and experience, and some up-front time. Be a champion and groom champions to help motivate and advise teams towards and through the transition, as it is no small change.
Many newer technologies are greatly reducing the overhead cost of moving to microservices. Many more projects can be considered for this approach than could be just a few years ago. It doesn’t only have to be for the biggest, most complex systems like those at Netflix. The benefits hit so many common pain points of so many software projects. Of course there are many success stories from companies like Uber, Yelp, SoundCloud, Amazon and Netflix; there are also success stories from smaller projects, whether they migrated a large monolith gradually towards microservices, or used a hybrid approach of using some microservices with some larger components. The microservices approach can be enabled at any organization that has adopted strong supporting approaches, such as domain-driven design, continuous delivery, infrastructure as code, and small autonomous teams. Microservices can also be a catalyst for an organization to get better at these effective software delivery practices. With some ramping up in an incremental and deliberate manner, and some investment from the top, microservices can be a key IT strategy that keeps your software delivery as fast or faster than everyone else.
In many ways, microservices can give organizations significantly more agility with business decisions. The software can respond faster to constant change that is inevitable in the business world and necessary for a competitive advantage. New technologies can be experimented with less risk, which is also critical for keeping pace with competitors. Ultimately, a successfully implemented microservices approach can speed up software delivery.
Building Microservices: Designing Fine-Grained Systems, Sam Newman
Microservices, Martin Fowler, https://martinfowler.com/articles/microservices.html
Microservices Resource Guide, Martin Fowler, https://martinfowler.com/microservices/
MonolithFirst, Martin Fowler, https://martinfowler.com/bliki/MonolithFirst.html