Microservices are likely to be at least as popular with executives and project leaders as they are with developers. This is one of the most unusual features of microservices because architectural enthusiasm is usually reserved for software development teams. The reason for this is that microservices better reflect the way many business leaders want to structure and execute their development teams and processes.
In other words, microservices are an architectural model that better facilitates a desired operating model. In a recent IBM survey of more than 1,200 developers and IT executives, 87% of microservices users agreed that adopting microservices is worth the expense and effort.
These are just some of the business benefits of
microservices.
Perhaps
the most important feature of
microservices is that, because the services are smaller and can be deployed independently, an act of Congress is no longer required to change a line of code or add a new feature to the application.
Microservices promise organizations an antidote to the gut frustrations associated with small changes that take large amounts of time. It doesn’t take a PhD in computer science to see or understand the value of an approach that best facilitates speed and agility.
But speed isn’t the only value of designing services this way. A common emerging organizational model is to bring cross-functional teams together around a business problem, service, or product. The microservices model fits perfectly with this trend because it allows an organization to create small, cross-functional teams around a service or collection of services and have them operate in an agile manner.
The loose coupling of microservices also creates a degree of fault isolation and better resiliency in applications. And the small size of the services, combined with their clear boundaries and communication patterns, makes it easier for new team members to understand the codebase and contribute to it quickly, a clear benefit in terms of speed and employee morale.
In
traditional n-tier architecture patterns, an application typically shares a common stack, with a large relational database supporting the entire application. This approach has several obvious drawbacks, the most significant of which is that each component of an application must share a common stack, data model, and database, even if there is a clear and better tool for the job for certain elements. It makes the architecture bad, and it’s frustrating for developers who are constantly aware that a better, more efficient way to build these components is available.
In contrast, in a microservices model, components are deployed independently and communicate through a combination of REST, event streaming, and message brokers, making it possible to optimize the stack of each individual service for that service. Technology changes all the time, and an application composed of multiple smaller services is much easier and less expensive to evolve with more desirable technology as it becomes available.
Precise scaling
With microservices, individual services can be deployed individually, but they can also be scaled individually. The resulting benefit is obvious: if done correctly, microservices require less infrastructure than monolithic applications because they allow precise scaling of only the components that require it, rather than the entire application in the case of monolithic applications.
There are also challenges, the
significant
benefits of microservices come with significant challenges. Moving from monolith to microservices means much more management complexity: many more services, created by many more teams, deployed in many more places. Problems in one service can cause, or be caused by, problems in other services. Log data (used for monitoring and troubleshooting) is bulkier and can be inconsistent across services. New versions can cause backward compatibility issues. Applications involve more network connections, which means more opportunities for latency and connectivity issues. A DevOps approach (as you’ll read below) can address many of these issues, but adopting DevOps has its own challenges.
However, these challenges do not prevent non-adopters from adopting microservices, or from deepening their microservices commitments. Recent IBM survey data reveals that 56% of current non-users are likely or very likely to adopt microservices in the next two years, and 78% of current microservices users will likely increase the time, money and effort they have invested in microservices.