In today's fast-moving enterprises, speed of application deployment is everything. Things have to be turned around or adapted quickly. Interfaces need to be changed, or back-end systems behind interfaces go through upgrades or get replaced. There are lots of options -- APIs, cloud services, REST services -- but how to tap into them or stitch them together on a moment's notice?
The microservice approach is suited for instances in which developers or administrators want to retain the functionality and interfaces already established for a system, but need to tack on new functionality.
Service oriented architecture, in principle, was supposed to make underlying systems more responsive and adaptable to various changes in business demands and processes. However, SOA frameworks, especially those that involved complex middleware infrastructures, also served to be cumbersome in their own way.
That's why some industry observers are calling for a new form of service oriented architecture -- or what they are calling a microservices architecture, or MSA. PwC's Galen Gruman and Alan Morrison recently put together an overview of a shift to MSA, and how it helps service developers and providers adapt quicker to new realities.
So what are microservices, and is there anything new about them? It feels like deja vu all over again. Microservices are, in essence, finely grained services, deployed without middleware or brokers -- such as an enterprise service bus. There are shades of Jim Webber's "Guerrilla SOA," which he advocated a number of years back as a way to quickly build and deploy services for tactical quick hits. APIs and RESTful services also fit this mold. Gruman and Morrison suggest that MSA is all of these things, with an emphasis on taking a minimalist approach to services:
"MSA breaks an application into very small components that perform discrete functions, and no more. For example, a microservice could be an address-based or geolocation-based zip-code lookup, not a full mapping module. The fine-grained, stateless, self-contained nature of microservices creates decoupling between different parts of a code base and is what makes them easy to update, replace, remove, or augment. In MSA, you want simple parts with clean, messaging-style interfaces; the less elaborate the better. And you don’t want elaborate middleware, service buses, or other orchestration brokers, but rather simpler messaging systems such as Apache Kafka."
Such small, finely focused services are quick and easy to develop, understand, manage, and integrate, Gruman and Morrison state. "They do only what’s necessary, and they can be removed or ignored when no longer needed." MSA-enabled services tend to be built with "web-oriented languages such as Node.js that favor small components with direct interfaces, and in functional languages like Scala or the Clojure Lisp library," they add.
They are made for today's emerging API and REST-driven enterprise functions. Examples cited by Gruman and Morrison include changing a US zip-code lookup "to a UK postal-code lookup by changing or adding a microservice," or pulling data from "a NoSQL database like MongoDB at one stage of an application’s lifecycle and from a relational product like MySQL at another. In each case, you would change or add a service."
The microservice approach the authors advocate is suited for instances in which developers or administrators want to retain the functionality and interfaces already established for a system, but need to tack on new functionality. Of course, this type of architecture tends to be driven bottom-up, by developers and power users who need to rapidly reconfigure parts of an application for a new business requirement. It is very much an individual, local act -- "one developer, or a small team, independently produces a microservice," they point out.
As the authors note, MSA is but one tool among many available today. Along with standard SOA, REST, APIs and cloud. It is one more approach to dealing with IT configurations that may be very different within just a few months.