The Motivation for Microservices
Separating the various components of a single application’s architecture carries a number of well-known advantages. For one, the components can be distributed among several members of a development team, which increases the ability to deliver the application more quickly. With well-defined interfaces between the components, developers and testers increase their focus and efficiency via a reduction in the scope of functionality with which they must work.
Componentization of applications also increases their robustness. Should one component fail, for instance, the remainder of the application can continue to function while the errant component is restarted. This generally has a very positive effect on the app’s user experience versus a full crash/reboot of a non-componentized application.
Another advantage is the opportunity to distribute the execution of the application’s components across multiple physical or virtual execution environments. Not only does this further increase resilience but it usually improves performance and scalability. Depending on what the app does and how the decomposition is done, it is possible to duplicate only particular components instead of the entire app to further improve efficiency.
Finally, microservices offer an opportunity that goes hand-in-hand with the goals of continuous delivery of software. They improve defect repair turnaround time and the ability to deliver rapid updates or new functionality by component replacements versus re-deploying an entire application.
Are Microservices a New Concept?
The overall concept upon which microservices are based is not fundamentally new. SOA, which shares many of the same characteristics and goals, has been in use for decades in one form or another. If you prefer, think of microservices as a refinement of SOA.
Microservices are typically produced on a smaller scale than SOA however. SOA is typically used to employ intercommunication between suites of large enterprise applications in an Enterprise Service Bus configuration, whereas microservices are more compact and utilize fast messaging for communication between themselves.
Microservices were developed to serve end users who increasingly demand that their apps and services be highly scalable, modular, responsive and adaptable than the typical SOA implementation. They are also more suited for today’s diverse mobile device environment to which wearables and IoT are quickly being added. Additionally, with microservices, new tools and techniques are being employed to deliver reduced development time and more resilient runtime operation.
Microservices Enabling Technologies
Besides a specialized approach to the fundamental concepts behind SOA, microservices projects typically utilize specific technological approaches including the preferred use of open source code and container technologies.
Small, component decompositions that enhance the ability to tweak apps on the fly makes dealing with licensed proprietary libraries impractical. Furthermore, due to the requirement that components carry their own API, sharing of components across applications becomes much easier, which would be negatively impacted within a backdrop of licensing issues.
Container technologies, such as Docker, are ideal tools for the microservices world. Containers essentially allow microservices to run as separate apps with their own allocations of CPU, memory and network resources independent of other microservices. Containers are not a requirement for microservice implementation, however, but they often improve portability across infrastructures.
More Than a Technology
It is important to bear in mind that microservices require more than just technology but a different development mindset too. The decomposition, for instance, of an application using microservices is more often based on business needs than architectural/technological concerns.
Rather than, say, dividing the app according to its UI, database and networking layers, it is a better, customer-oriented, approach to partition the app according to the functional requirements of the end user. Because of this characteristic and the small-size granularity of microservice development, their use often thrives in organizations using agile development methodologies and especially in DevOps environments.
Microservice development is not standardized, at least not yet. It is more accurate to call it an emerging architectural philosophy much as SOA was even before it acquired a name. They are changing the concept of what an application is. Microservice apps, which are more or less a framework for running the components that is built upon are a different animal than the single-block, monolithic apps of the past.
At the end of the day, the microservice concept simply makes creating robust, scalable and versatile applications easier. It also improves their resilience, testability and maintainability even post-delivery. The technique is particularly suited to continuous deployment processes that are required to compete in the fast-changing world of new devices and “things” coming online at an exponential pace.