Software development has seen significant changes in the last several years, including Agile and DevOps philosophies and the impact of the explosion of mobility and cloud-based services. The microservices movement is the latest change, born of the need to transform the way developers design and update applications.
This technology brings together previous engineering ideas into a new form. 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.”
For certain kinds of applications, so goes the thinking behind microservices, it’s easier to build and maintain them 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. When it comes to large applications in particular, this approach makes the process easier for myriad reasons.
The traditional development approach would require that the entire application 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.
Another benefit of microservices is that their test surface is smaller, so testing is far easier than with monolithic applications. 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 monitor. Microservices provide a way to simplify much of the work, leaving you more time to focus on more important matters.
Maintenance is faster and easier 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.
Pinpointing What’s Broken
Over time—and lately, that can be as little as a few days—applications evolve and changes need to be made. With microservices, developers can fix just the broken component without having to repair the entire system. 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.
For a glimpse into how a microservices approach works in practice, think about when a tail light on a car burns 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, cars essentially use a microservices type of approach. 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.
Container technologies are all the rage. 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.
Keep in mind that as long as existing systems function reasonably well and reliably provide the service you need, there’s no need to refactor them. Transforming existing legacy system to microservice 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.
The last few years have seen some profound change in the software development arena, and the microservices approach has been an important one. However, it isn’t intended as a total replacement of legacy systems. Microservices have their benefits, as discussed above, but every approach has its drawbacks. Developers will find that it’s possible and even sometimes preferable to use microservices and legacy systems in the same environment. It’s a brave, new, compartmentalized world.