Have services become the new monoliths? A case for microservices

The goal of services -- be they RESTful, SOAP, web, cloud, data, and anything else -- is to break out vital pieces of the monolithic applications or systems that take up data center space. They are intended to both lighten and enlighten IT environments, abstracting away the heavy-duty plumbing and infrastructures that are in the systems underneath. For example, a large monolithic system built on Ruby may be too unwieldy, and better off broken down into services that can be accessed and reused as the business changes.

What happens when the service becomes a monolith in itself? What if it becomes difficult to make changes without having to ensure that all upstream and downstream dependencies are not broken, and that its myriad of consumers do not get cut off?

That's why the time may be ripe for a new breed of smaller microservices, which are touted as the next stage in agility. As time has progressed, many services have become unwieldy behemoths in their own right, writes Sam Newman in his new book, Building Microservices: Designing Fine-Grained Systems. "In practice many of us will have seen services grow well beyond the point of sanity," he adds. "Despite knowing that a smaller set of services would be easier to deal with than the huge monstrosity we currently have, we still plow on with growing the beast.Why?"

Newman says microservices should be part of the "seams" that form service boundaries. Of course, splitting up services into smaller microservices means adding many more moving parts into production. He provides these guidelines for splitting services:

Decide whether the current service counts as monolithic: "When you encounter business operations that currently occur within a single transaction,ask yourself if they really need to,"Newman writes. "Can they happen in different, local transactions,and rely on the concept of eventual consistency?"

Take an incremental approach to service splitting: "I would strongly advise you to chip away at [monolithic services]. An incremental approach will help you learn about microservices as you go, and will also limit the impact of getting something wrong."

Start with the main pain points: "Think about where you are going to get the most benefit from some part of your code base being separated, rather than just splitting things for the sake of it." For example, Newman illustrates, "perhaps we know that we have a load of changes coming up soon in how we manage inventory. If we split out the warehouse seam as a service now, we could change that service faster, as it is a separate autonomous unit."

Consider the security implications: A company, for example, may have all its sensitive information handled by finance-related code, Newman illustrates. "If we split this service out, we can provide additional protections to this individual service in terms of monitoring, protection of data at transit, and protection of data at rest."

Untangle tangled dependencies: Here's where packaged modeling tools can help, Newman says. "If you can view the various seams you have found as a directed a cyclical graph of dependencies, this can help you spot the seams that are likely going to be harder to disentangle." Beware the database he adds -- it's "often the mother of all tangled dependencies."

Of course, it's always about the business. Devoting time and effort to splitting services -- which may or may not be noticed by the business -- needs to be have a solid business case. Is the business going to be able to move on new opportunities faster because it can assemble or reassemble more fine-grained services? Or is it doing fine with the coarse-grained services now out there? That's the question that needs to be asked before anything is begun.

A complimentary copy of the chapter from Newman's book addressing this is available at the ThoughtWorks site.