Micro Focus is now part of OpenText. Learn more >

You are here

You are here

Is your application architecture prepared for microservices?

Ericka Chickowski Freelance writer
Bridge building

The ideal architecture to support small, incremental application improvements at speed—a goal of DevOps—is one that breaks the application into many loosely coupled components. Microservices allow for such changes, with minimal risk of creating cascading and rippling effects that spread throughout the system. But the average enterprise is burdened with a monolithic application architecture that's tightly coupled and difficult to untangle.

One option is to rebuild that application architecture around microservices. But if an organization waits until it can get its architecture optimized before starting out on its DevOps journey, it will never cross the starting line. So how do you get your architecture ready?

Not by mooning over that microservices ideal as a DevOps prerequisite. That puts the cart before the horse, warns Neal Ford, software architect for ThoughtWorks. While microservices can greatly aid DevOps patterns, they're far from a prerequisite. In fact, shooting for too much architectural change right out of the gate can doom any hope of transformative change.

"To say to the enterprise, 'Hey, throw everything you've got out and rearchitect it,' is just not feasible," says Theresa Lanowitz, founder and analyst at Voke. "It's not financially possible. It's not possible from a business perspective."

Instead of getting hung up on how a legacy architecture is hampering DevOps patterns, organizations should be looking for ways to use those patterns to slowly modernize that architecture. In short, the path to a more pristine architecture is through the same kinds of incremental change that DevOps promises to enact within the software itself.

That means baking architectural evolution directly into the DevOps maturation process. Here's what several experts in application architecture say it will take to do that.

Start by defining your DevOps endgame

Before you do anything on an architectural level, take a step back from the buzzwords and think strategically, Lanowitz advises.

You have to be able to define what you want to get to. That's with any application architecture," she says. "You have to be able to define what you want the endgame to be, what you want the end result to be."

In her mind, the ultimate business goals are to reduce the cost of rework, eliminate waste, and become as efficient as possible. More importantly, this needs to be done in a risk-tolerant manner, says Michael Nygard, vice president of customer solutions for Cognitect. This is why for many organizations these objectives are going to be best achieved by breaking up monolithic application architectures as much as possible. Work can scale, because it can be done concurrently on an application in isolation, with much less risk of system failure.

"If you take a traditional application architecture and just try to apply DevOps techniques to it, you’ll probably not succeed, because failure domains are large and hard to tolerate," Nygard says. "That is what motivates us to break up the monolith. The core aspect is that things are smaller and can be released independently."

Failure isolation is a big motivator for microservices to be that endgame, says Matt Stine, a software architect and senior product manager at Pivotal Software. He believes it's far more sustainable from the perspective of maintenance and knowledge transfer.

"Another reason why keeping microservices small and focused is important is because, as those things age, in many cases they are disposable, and you end up replacing them. But even if they live on for quite some time, a new person who comes in to try to work on the system will have much less to learn before they can actually start modifying it or supporting it than they would when you have the systems that have hundreds of thousands or millions of lines of code."

Double down on incrementalism

Keep that end goal in mind, but remember that "you can't do architecture in a two-week sprint," Lanowitz says.

If you're attracted to the DevOps ethos, then you're probably already on board with the philosophy of making swift, small changes to software. It's only logical to double-down on this kind of incrementalism when it comes to improving the architecture that supports the development process.

"You can start doing this incrementally and keep all of your stuff alive and running," says Ford. "People get too ambitious when they have a monolith, and they want to go all the way to microservices, which is not a good idea. When you pull apart a monolith, you can do that in different ways."

Splinter new work into microservices

But before you even start digging into the existing monolith, it may help to practice a microservices approach with add-ons first. Start small by adding new features. 

"Locate within your existing systems the capability that will most benefit from the ability to continuously deliver change," Stine says. "That’s where we’re going to draw a line in the sand and say, 'We will no longer add new functionally related to this particular capability to some existing monolithic.'"

"We’re going to take that new functionality and we’re going to put it in a microservice. When we do that, we’re going to have to figure out how to integrate those capabilities back into any existing systems that we have."

This will teach the organization about its existing integration capabilities and how system boundaries are defined. As he explains, boundaries do exist in monolithic systems; they're just ill-defined and hard to see. Splintering new work into microservices is an overall learning experience.

"It's much easier to learn these things building net new features than it is by trying to manipulate existing legacy features," he says.

From there, Stine says that an organization will need to add what he calls an "anti-corruption layer" to smooth the integration between the old world and the new.

"The purpose of that layer is to take this new module that we’ve created, that we’re trying to protect from being corrupted by the legacy architecture, and build this layer between the two that acts as a translator between the two systems," he says.

Chip away at the monolith

From there, you'll start to feel confident enough in the microservices mentality to turn toward legacy architecture.

"Then it’s time to start breaking pieces off of the legacy architecture and turning those into either new microservices or plugging those features into existing microservices," Stine says. "Hopefully, by that point, you have honed your skills sufficiently that you know where to look for boundaries, you know how to recreate or break boundaries, recombine boundaries, and you also know how to do this integration work quite well. Then you start iterating on breaking the monolith apart."

Ford recommends chipping away at the monolith with big chunks first. "If you’re taking a monolith and decomposing into services, start with a small number of larger services first," he says. "Trying to create teeny microservices will be very difficult. That’s better than a big bang. Don’t try to slice it into tiny pieces and try to get it to work."

Also keep in mind that there may be parts of the monolith where the risks outweigh the business benefits of untangling the coupling. After you have broken enough pieces off of the monolith, says Ford, you'll get to the point where the next piece that you see that’s logical to break off won't offer a clear return on investment. "What you often will end up with is some fragments of enterprise legacy applications that will live on for quite some time. Usually, it’s because they don’t need to change that much."

Now create your road map

However you decide to do it, just try to keep the progress focused. Start with the endgame in mind, and have a detailed plan to get there. Lanowitz recommends that enterprises create a road map just as a software vendor would when servicing customers.

"Enterprise organizations would do well to have a strategic road map to really focus on what they can implement and when, because it takes time to do a lot of these things," Lanowitz says.

Part of that plan needs to delineate how you will spread responsibilities. Unlike some incremental changes that can be affected by one or two key DevOps champions, architectural changes require a broad base of support, Nygard says.

"It's pretty hard and requires a lot of sustained effort and a lot of people supporting you," he says. "One man with a vision can’t get this to happen. You need to have a lot of people with the shared vision, and even then there will be many difficult problems to solve that require creativity."

Keep learning

Read more articles about: App Dev & TestingApp Dev