This content is part of the Essential Guide: Developers' guide to deploying microservices and containers
News Stay informed about the latest enterprise technology news and product updates.

Microservices' benefits are clear, but getting there may not be

As businesses see microservices' benefits begin to accrue, IT may find itself facing a new set of challenges regarding implementation and continuing management.

Microservices architecture -- the development methodology in which a large application or entire system is constructed as a collection of narrowly focused, modular services -- continues to grow in popularity. The technology is alluring in its premise of combining small, single-function modules to yield a comprehensive business system; therefore, it holds great appeal for developers. But achieving comprehensive microservices benefits may ultimately require heightened attention to track and manage a potentially large number of microservice modules, compared with just a few do-it-all monolithic apps.

Implementing a microservices architecture offers a profound advantage that goes well beyond agility in app development and deployment. It allows the core business to be proactive and transformative -- staying ahead of competitors -- or reactive, if necessary, to play catch-up.

"If you are not continually improving your application, then your business is falling behind the competition," said Jeff Kaplan, managing director of THINKstrategies Inc., a Wellesley, Mass., cloud consultancy. "By architecting a large application or system as a series of very small microservices, it becomes much easier to update specific aspects and innovate."

Bert Ertman, a fellow at Luminis in the Netherlands and a frequent lecturer on microservices, agreed, noting that containers and microservices leverage each other's advantages. "Whether you claim to do microservices or not, I think striving for a more modular application architecture enables many good things, in general." Containers, he said, can be used without doing microservices, and microservices can be used without container technologies, but they complement each other by combining agility with portability.

Microservices benefits are growing

Writing in his blog, the chief architect of information systems at the Central Bank of the Russian Federation, Maxim Smirnov, listed a dozen scenarios for realizing microservices benefits via API calls, including product ordering, catalog management, trouble ticketing, customer management, billing and inventory management. In a microservices architecture, each module performs one function and uses a defined interface to interoperate with other modules.

The growing range of possibilities would appear to benefit every phase of an enterprise, but that's not exactly the case in the view of Donnie Berkholz, research director for the development, DevOps and IT ops channel at 451 Research. In practice, microservices benefits may not be equally distributed throughout the organization, he said.

"Microservices is increasing the burden on the development and operations teams, while creating significant business benefits," Berkholz said. "More and more companies want to become software-defined businesses, but to get there, they're going to have to dump a lot of their existing processes and tools."

Talent gap strikes again

The inevitable problem in trying to reap container and microservices benefits is the lack of expertise within corporate IT and the inability to comprehend the value proposition compared with a virtual machine architecture.

For Jeremy Steinert, DevOps practice lead at cloud consultancy WSM International in St. Clair Shores, Mich., they are old issues applied to a new technology. "We've seen a substantial uptick in work from our clients regarding microservices and containers over the last several months, but even we are still learning to build apps with these technologies and how to best compartmentalize the many components for efficient operation," he said. Using the two together yields both portability and scalability. "We can have dozens of nodes online in just a few minutes, and we are not restricted to where they run," he said.

While a key microservices benefit is that prized business agility, achieving it comes at the cost of implementing a microservices framework, along with managing a portfolio that could encompass hundreds of microservices for each legacy monolithic application that is ultimately replaced. "Adoption of containers has jumped from 6% to 14% of enterprises in just the last 12 months, but pace of reconfiguration into a microservices architecture is considerably slower," Berkholz said.

For developers, microservices and containers are a good place to focus, Berkholz said. "It's the oldest and the newest technologies that do well in salary surveys," he said. On the new side, that means microservices, containers and data science. Conversely, he said, it is the thinning ranks of COBOL developers, through retirement and demise, which keeps salaries high at the other end.

Joel Shore is news writer for TechTarget's Business Applications and Architecture Media Group. Write to him at or follow @JshoreTT on Twitter.

Next Steps

Five tips for achieving microservices happiness

Is a microservices architecture right for mobile computing?

What IT needs to know about microservices

Learn more about the benefits of microservices to EA

Dig Deeper on Cloud application development

Join the conversation


Send me notifications when other members comment.

Please create a username to comment.

What obstacles is your organization facing in moving to a microservices architecture?
I think our biggest challenge has been that we are moving in that direction at the same time that we are migrating the apps and services to the cloud, so we’ve really complicated the matter by attempting two large efforts at the same time. Our second biggest challenge is updating the way that we think about testing when it comes to a microservice architecture.
Speaking of testers - it's a lack of technical skills for effective and efficient testing of microservices. Absence of the UI requires to give up "traditional" test cases and acquire mixed white box / black box testing approach using programming and tools.
Agreed that it's tough enough to migrate anything from a legacy architecture (and philosophy) to the cloud without changing anything. Simultaneously redesigning into hundreds or thousands of bite-size microservices makes for a daunting challenge. This isn't exactly a case for not changing more than one variable at a time, but it's certainly a reasonable approach. It's not that different from an NFL coach devising a game plan that gives a third-string quarterback the best possible chance of succeeding. You want everyone in IT — and the apps and systems — to succeed.
People often think that microservices remove a lot of complexity, but you’re really just putting the complexity somewhere else. Instead of the complexity being embedded within monolithic applications, it now comes in the form or managing a slew of smaller services, which creates a new set of challenges that must be solved.
While the article speaks of business benefits of microservices architecture I find that it's also a good way to approach the team scaling problem. Large teams are typically less effective. Large monolithic apps demand large teams. But if the product is split to a few sub-products, it helps to keep small efficient teams.
On one side of a balance scale, we might place a single one-pound weight, and on the other side place 16 one-ounce weights. The two are are in equilibrium, but there's a price to pay for keeping track of 16 items instead of just one. Conversely, if one of those 16 should go missing or awry, the other 15 might still be ok; not so if that big one-pounder goes south. Sure, this is a vast oversimplification in comparing to one giant monolithic program vs. a bunch of constituent microservices that total up to the same end computing result, but my point is that each model offers both advantages and disadvantages.