Why use microservices?
Autumn rain image via Shutterstock
Gartner projects that the worldwide public cloud services market will grow 16.5 percent by the end of this year. 451 Research found that 40 percent of companies surveyed are going to prioritize the mobilization of general business apps over the next two years. Trends like these have led developers to rapidly adopt microservices for building applications. As business needs change, forward-thinking companies are modifying, scaling and updating their apps continuously with the help of microservices.
This technology didn’t just come out of the blue; it’s an evolution and amalgamation of earlier ideas. As IDC analyst Al Hilwa has explained, “microservices is an architectural approach that draws on the long evolving experience in software engineering and system design, including the SOA (Services-oriented Architecture) efforts of the last two decades.”
Microservices’ core concept is simple: it’s easier to build and maintain some kinds of applications by breaking them down into smaller pieces that work together. In this way, each component is developed separately – the application is the sum of its parts. You have independent processes communicating with each other using language-agnostic protocols. This is a sharp contrast to the more traditional approach of building one, huge system all in one piece.
This component-based approach makes the development process easier, especially for large applications:
Saving time and money
Maintenance is easier and faster with microservices architecture. This saves developers’ time, thereby increasing efficiency and ultimately saving organizations money. What’s not to like about that? What’s more, microservices allow for faster evolution and upgrades – no need for massive codebase refactoring when adding new features.
With the typical monolithic development approach, the entire application had to be addressed as one large entity. If demand increased, the whole application would need to be multiplied to handle the load. That would mean multiplying the servers or virtual server instances that the application ran on. In microservices architecture, you only need to scale the app components impacted.
Testing is much easier with microservices than with monolithic applications for the simple reason that the test surface is smaller. Since each component of microservice architecture is more or less autonomous, developers can easily test those small components locally – no need to deploy them to a complex test environment. The smaller size also makes applications easier to deploy, and easier to monitor.
In short, developers face multiple, complex challenges every day, and microservices provide a way to simplify much of the work, leaving them more time to focus on more important matters.
Ease of repair
Applications are living entities, changing on a near-constant basis. With microservices, developers can fix just the broken component, without having to repair the entire system as a whole. Instead, you can just replace the faulty component, without any interruption to the end user. Of course, that may not always fix the root cause, but the priority should be placed on designing a system so that an end user doesn’t even notice the problem.
Cars essentially use a microservices type of approach. Think about when a car’s tail light goes out. Imagine if that also meant the entire car would need to be hauled in for repair. Not only would this be inconvenient, but it would also be time-consuming and costly. Fortunately, you can keep driving even with the broken taillight, and it’s simple to replace the non-working part. More importantly, though, the core service was not interrupted and there was likely little friction for the driver. This is a good analogy for how a microservices approach works in practice.
Making microservices work for you
Container technologies have become very popular in a short amount of time, and this new way to package, distribute and run software greatly compliments microservices. With the right tools, you can now create systems using microservice architecture, while keeping the operations and maintenance burden of your infrastructure minimal. Microservices and containers may not be synonymous, but they are a perfect match.
Using microservices does not necessarily constitute a search-and-destroy mission. Often, it does not make sense to refactor existing systems as long as they work reasonably well and provide the service you need reliably and with “good enough” performance. Transforming existing legacy system to microservices architecture might become a huge project. If you want to follow that road, it’s often smart to do it in parts; start by chopping off some functionality from your monolith and make them work as microservices serving your monolith. Like any solution, it’s a cost-benefit analysis, and this one can transform the way you package software.