Why you can't escape microservices or their monolithic past

If you aren't using microservices yet, you soon will be, according to the data.

An O'Reilly survey this summer of architects, IT decision-makers, and other such IT pros found 77% had adopted microservices, with 29% saying they plan to build or convert more than half of their systems. And a report here shows similar adoption levels to O'Reilly—73%— with 63% of those not yet riding the train thinking about it.

Where are microservices being used? Red Hat points out microservices are an easier lift for new projects. That said, they are widely employed by 69% of users to re-architect legacy software systems. "Microservices offer value to users throughout their IT transformations - from updating a current portfolio to introducing brand new initiatives," Red Hat says. This data makes sense in context. But the true promise of microservices is the break down from monolithic applications into microservices.

O'Reilly reinforces the legacy modernization point in their report above, saying that "most" microservices projects are replacing "large, legacy, monolithic software systems. Those monoliths are themselves very complex, having evolved over decades."

The case for microservices is compelling. They are both a journey and a destination point. Microservices ease the way for architects to develop and plan their organization's cloud strategy, design the new systems and specify DevOps tools and technologies, and also implement the transition. In effect, microservices provide a blueprint for application modernization.

What about the shift back to monolith?

But, are people boarding the wrong train when it comes to microservices? 2020 will be remembered for many things, among them the germination of the idea that it is monolithic applications—not microservices—that are the cloud's future. Wait, what?

"You have to bring in the unpopular opinion, and let people comment on it," Google Cloud Platform staff developer advocate, Kelsey Hightower, told the GoTime podcast here. "Monoliths are the future." The crux of Hightower's thesis is simple: Driven by container technology's success, microservices have become a fashionable item to have and are being used in ways they really shouldn't. For example, they are used without being properly architected. How? Organizations are turning once-centralized monolithics into confusing, newly-distributed monoliths. As Hightower says in the podcast: "Most people say: 'Look, we lost all of our discipline in the monolith… now the codebase is so bad. You know what we should do? We're gonna break it up and somehow find the engineering discipline we never had in the first place.'"

Software Architecture for Developers author, Simon Brown, follows the argument through to its logical conclusion: "If people can't build monoliths properly, microservices won't help."

The problem is in the architecture

Microservices cleanly decouple applications if, and only if, the architecture avoids coupling. Since everything in the microservices world is an independent service, you should expect more transactions, communications, and dependencies. More services equal more resources, ergo more database transactions to manage. Not addressing the architecture puzzle early on will have ramifications for those who must implement your cloud strategy and modernize those legacy applications—the folks in DevOps will see testing, debugging, and deployment get a lot harder.

Alexandra Noonan, a software engineer for Segment, summarizes the problem that the growing complexity presented to her company's software delivery: Too many teams building and maintaining too many integrations. Rather than make Segment more agile, its software delivery slowed down. "We were falling from the microservices tree, hitting every branch on the way down. Instead of enabling us to move faster, the small team found themselves mired in exploding complexity. The essential benefits of this architecture became burdens. As our velocity plummeted, our defect rate exploded," Noonan says.

In the 2020 State of Microservices report, Thomas Boltze, CTO of Asto Digital, describes what could be called a kind of microservices religious zeal—people making services "super small" before putting in place the means to manage the resulting distributed transactions. "Before developing microservices-based software, you must think about the future and prepare for maintenance beforehand. Starting to care about debugging in the middle of the development process – when things finally 'go south' – is simply too late," Boltze says.

Where microservices work well

The challenge seen above is not inherent to microservices. As Red Hat outlines:

"Microservices architectures rely on DevOps practices, automation, CI/CD, and API-focused designs. They should also be organized around business capabilities and part of a larger decentralized governance and data management solution. We think microservices are pretty great, but they need good management and orchestration solutions."

Without management tools, the DevOps process becomes overwhelmed.

According to the chief technology officer of The Software House, Marek Gajda, one way out is to bring in an expert with experience who can instigate the kinds of policies and processes that restore order. "My pro-tip for you is: hire an experienced DevOps engineer at the very beginning of your microservice project. These [people] can do real magic when it comes to future-oriented thinking and planning out your whole system's architecture." But, he warns, "microservice architecture is not a cure for all of your software problems."

But perhaps there's another path the enterprising architect can pursue—a path that will prove more enriching and enlightening in terms of their own skills and understanding?

Walking the Netflix way

When it comes to microservices, Netflix is the kind of company everyone—whether they know it or not—wants to emulate.

Netflix cloud architect Adrian Cockcroft re-architected the media giant's existing, monolithic application into a service that's now capable of streaming digital content to millions of customers daily. Cockcroft says that success came not from dictating an architecture but rather "discovering and formalising" the patterns created by engineers.

If you can harness and channel an emerging pattern, you have a shot at producing a microservices architecture that's practical and sustainable because it's rooted in the thinking and working of those who must build and implement it.

Microservices still requires the discipline of software architecture design, but that design is informed by those in the DevOps-related roles.

When it comes to architecture, Cockcroft offers tips to further minimize complexity and streamline deployment and management. First, harmonize your applications and data by developing a set of practices and tools. What does this mean in the real world? Sure, specify a separate data store for each independent service, but build-in tools to guarantee clean and synchronized data.

Next, ensure the code for all those independent services is regularly maintained and operating and matching in maturity. That means making sure code neither slips behind on updates or support in a way that slows down or breaks your service mesh, nor demands radical updating before any updates can take place.

Finally, don't build "snowflake systems" into your architecture—in other words, a cluster or mesh of servers that your services depend on for special functions. This is the epitome of monolithic: It's a potential choke point in your performance, the chink in your resilience, and it'll place too many demands on DevOps' time to manage and maintain.

Putting the pieces back together again

The benefits of microservices are writ large, but they are not a panacea for all your enterprise application sniffles. Indeed, such is their inherent complexity that they may—unless they are implemented well—actually make life more challenging for your organization. But that's no different than the attempts at monoliths. Neither architecture offer an inherently sound approach to software systems.

The path to a successful microservices architecture lies not in following the fashion but in harnessing the working patterns of those who will have to implement your architecture. A measured and organic approach can help bring the order and processes needed to successfully run enterprise IT in the cloud using microservices, without losing control—and without returning to a monolithic past.