The term microservices is quickly evolving from an esoteric topics discussed only among gearheads or "stackers" to an increasingly important enterprise issue. In simple terms, microservices is the decomposition of services and software into smaller and more portable components.

When we first explained it, the concept was taking root among software developers but not yet among enterprise IT administrators and system operators.

Now enterprise service providers and even vendors in the content management system (CMS) space such as Built.io appear to have appropriated the word, if not the concept. The value proposition of microservices is starting to take shape, with the promise of breaking down software platforms into components that are easier to host, simpler to manage and less expensive overall.

Microservices: The Next Evolution of Technology

“Microservices is about separation of concerns and enabling individual teams to focus on specific problems,” CoreOS CTO Brandon Philips told CMSWire.

Ted Burdett, who manages digital and mobile systems delivery for outdoor gear retailer REI, called microservices the next evolution of our push in technology “to create, deploy and maintain applications as cheaply as possible, and get features out to customers as quickly as possible.”

In a note to CMSWire, Burdett discussed his firm’s exodus away from EMC Documentum and Adobe CQ to a component-driven system. Parts of this system are incorporating the open source CMS platform Hippo and the open source search platform Elasticsearch

Searching for Adaptability and Agility

REI wanted adaptability and agility, and wasn’t getting it from the monolithic platforms on which it relied — in fact, said Burdett, if one team needed changes to make a new feature feasible, the need alone would put the rest of the organization at a standstill.

“The focus on customers delivering and demoing features as quickly and early as possible has been constrained by traditional data center infrastructure,” wrote Burdett.  “The shift to cloud technology from traditional infrastructure has also made very apparent the operational costs of servers. IT teams are focused on scaling applications to real-time traffic levels, in an attempt to reduce operating waste.”

As CA Technologies software architect Matt McLarty explained to us, “The fastest approach to having an optimal team size and a most efficient organization, [is that] you want to have these small teams of five to seven people with cross-functional responsibilities.  It’s just a lot harder to go to that type of organization when you’ve got this big monolith that everyone is dependent on.”

The Dreaded Supermarket Analogy

So microservices has become the latest incarnation of the kind of cultural phenomenon needed to facilitate technological evolution — the kind that’s necessary to bring about cultural shifts ... the sort that can lead to technological evolution. Et cetera.

Let’s unravel it a bit:

Today’s server-based applications, such as CMS, are hosted entirely on software-based virtual machines (VMs). The entire VM, including the operating system, is staged on a cloud platform within what Amazon or Azure calls an instance.

Those with the newest architecture are constructed using APIs — functions that communicate with browser-based clients individually. Imagine shopping at a supermarket but getting one grocery item at a time and walking back out to your car each time, and you’ll get the picture.

Now when a supermarket or any retail establishment gets popular, it adds space. If it gets really popular, it adds locations. But for an old-style monolithic application, increasing the number of instances — the equivalent of constructing a new facility each time — is the only option. And that becomes cost-prohibitive at a certain point.

Enter Service-Oriented Architecture

Software developers realized they didn’t need to put all these API functions in one place. So they moved to more of a service-oriented architecture (SOA), resurrecting an old idea. This way, you can host portions of an application in different places — on premises, on cloud platforms, maybe on modern, containerized infrastructure.

If we’re using the term microservices correctly, then we take the idea one step further: The ingredients of those API functions — most importantly, the way data is stored and accessed — are broken down into even smaller components. This way, a sophisticated management system called an orchestrator can optimize the way resources are consumed.

Imagine a supermarket that gets bigger by automatically adding checkout lanes, hiring more checkout associates, tiling and polishing the floor, and adjusting the thermostat, and you get the idea.

A People-and-Process Sort of Thing

“Previously, a Java or .NET Web app — although it may be a modularly-designed app — gets put together in one big hunk of code, and pushed to the server for deployment,” Forrester analyst Randy Heffner told CMSWire.

“So to redeploy anything within this application, you have to redeploy everything. What microservices does is break that out into many individual deployment units. Then we can deploy and change one small part at a time.”

The big problem is this: The move is an epic journey. While it opens up the nucleus of your enterprise applications to rapid change by your own developers, it requires one active agent that many enterprises haven’t had in a long while: their own developers.

Shifting Data Center Infrastructure

What’s more, truly adopting microservices means shifting some portion of the data center’s infrastructure onto a system capable of orchestrating and managing smaller software components. That means either adopting Docker or a containerization platform like it, somewhere inside the corporate firewall, or moving the microservice parts of the application, perhaps gradually, onto a cloud-based host outside of the corporate firewall.

“At the end of the day, what people are hoping to get out of microservices is an acceleration of deployment, and a focus from teams on solving particular problems.  It comes down to a people-and-process sort of thing,” Philips said.

In the second part of this series on microservices, we’ll talk more with Philips, who happens to be the architect of a leading containerization platform (option 1), as well as speak to the founder of a company that offers enterprises a way to adopt microservices gradually (option 2). And we’ll see if either option is more mature now than we first brought the whole subject up. CMSWire’s Dom Nicastro contributed to this series on microservices.

For More Information:

Title image by Dino Reichmuth