Are microservices for real, or just the latest buzzword?

Perhaps a microservice architecture is what service oriented architecture was always meant to be. SOA's value proposition was about the ability to break applications down into lightweight, discrete services that are well-governed and available for reuse.

The service-oriented process always tended to be unwieldy, with questionable or hard-to-measure business benefits. Microservices, because they are more lightweight, promise far greater flexibility -- which translates to more flexibility for business users to make changes. Potentially, then, microservices represent the next stage in IT agility, building on what already has built in terms of service oriented architecture, REST services, web APIs, and cloud services. Or is it just a new buzzword?

There are two prevailing points of view on microservices:

• There's nothing new about them, and they're just the latest marketing hype; or
• they enable greater and more granular functionality than previous generations of services.

Maxine Giza at TechTarget's SearchSOA recently explored the ins and outs of microservices, and whether they do represent a new approach to enterprise architecture. Gartner's Anne Thomas is favorable to the concept, suggesting that microservices are about "applying service-oriented architecture principles at a small level of granularity." Pierre Fricke, director of product marketing for Red Hat JBoss Middleware, also interviewed by Giza, suggests that microservices can be thought of as "SOA getting lean, getting more agile than it was before."

ThoughtWorks' James Lewis and Martin Fowler provided a definition of microservices about a year ago. Their definition is as follows:

"The microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable by fully automated deployment machinery. There is a bare minimum of centralized management of these services, which may be written in different programming languages and use different data storage technologies."

So the big question is -- as it was with SOA -- what is the value of microservice architecture to the business, and will the business ultimately realize that value? There are some advantages microservices could bring to the table. Faster deployment of services is one, since they only engage extremely small chunks of applications, so they can be built and tested quickly -- "rather than in large monolithic globs," as Gary Oliffe, another Gartner analyst, explained in a recent post. The ability to quickly scale up these smaller chunks of applications into a larger configuration is another advantage.

InfoWorld's Eric Knorr suggests that microservices may be a way to reduce technical debt, long a sticking point with enterprise IT. "Microservices architecture potentially offers an easier way to pay down technical debt. Refactoring a big monolithic application can be the equivalent of a balloon payment. But if you break down application functionality into API-accessible microservices, each with a single purpose, you can pay your technical debt incrementally by refactoring services one by one."

Such is the value proposition with SOA. But the whole idea of a microservices architecture -- in which an enterprise landscape is built upon many well-orchestrated and standardized services -- may be much easier said than done. RedHat's Christian Posta, for one, says the whole concept of microservices is easier said than done in a typical enterprise environment, where there are multiple systems, multiple teams, and multiple layers of reporting. "At the end of the day, isolating 'services' or systems at the process level is still not really loose coupling or 'decoupled' systems," he says.

Oliffe also cautions that microservices has become a favored marketing buzzword as well, and "vendors will not miss the opportunity to 'microservices-wash' their tools and platforms to get your attention."

Still, Oliffe sees a lot of upside potential in the microservice architectural approach. Microservices will live within the "inner architecture" layer," away from the complexity of testing, deployment, and inter-service communication. These exist within the "outer architecture." This doesn't remove microservices from these requirements, but helps boost their portability, he says. That means greater flexibility for the business to employ technology to quickly shift strategies and respond to opportunities or challenges. "While not a panacea, I can see the potential for microservices to change the way we build, maintain and operate applications," Oliffe says. "When delivered with discipline they help applications become more evolvable, more portable, and more adaptive, particularly as organizations look to migrate application workloads to private or public cloud platforms."

The bottom line is microservice architecture is a new phase to the promise of SOA. But if there's any lesson learned from the SOA heyday, the business benefits need to be front and center.