Meet Steve. Steve is responsible for a mission-critical application for a very large enterprise. He has a problem: It takes Steve and his team a very long time to make changes to this application and release it to production. Steve has been talking to vendors, consultants and peers about agile software development techniques and DevOps, but Steve and his team have assessed that his application does not lend itself to these approaches.
See, the system Steve looks after is called a monolith, which is a very confusing title since it was developed using the latest modular software development approaches when it was created, in the latter half of the 1990s and early 2000s. Steve and his team are constantly advised that they need to decompose their monolith into microservices. However, this advice only confuses Steve and his team even more, since the system was designed using a service oriented architecture (SOA) with the intent of ensuring that it was easier to maintain and scale.
Steve’s team fell into a very common trap associated with many SOA-based designs: The services were designed with deep dependencies, they share a common database and they are very coarse-grained. Indeed, the collections service, which is one of eight services in the system, handles every potential operation a collections agent might ever need. Modifying any operation within the collections service means the entire collections service must go through regression testing and production must enact a very cumbersome deployment strategy that requires a five-hour maintenance window.
Needless to say, Steve cannot keep up with the requested changes from the business with these constraints. Steve’s advisers have given him some good advice on organizing to develop faster, but he would only be applying Band-Aids faster. However, once the constraints identified above had been pointed out to Steve and his team, they better understood the challenge ahead of them.
Steve and team are going to have to redefine the data models so they support service independence, then extract subsets of functionality out of the large, intertwined services to deploy as within a well-defined business context—following the “do one thing well” mantra. They then can start to extricate the complex business logic trapped inside the enterprise service bus so it can be incorporated into the services at the edge.
Steve and his team realize that continuing to enhance the monolithic code base avoids the challenges of redevelopment but reduces the value of that codebase to the business. While there will be a cost of untangling the monolith, the cost of not doing so is lack of competitiveness, lack of agility, long wait times for new features, possible opportunity loss and continued investment in technical debt. Steve’s job will be to present the justification for this to the business based on these risks.
When the task is completed, Steve and team will be able to deploy new services and modify existing services within weeks. The costs related to development and testing will drop significantly and the finer-grained services will allow developers to address business needs more quickly.
We’ll check in with Steve and his team as they embark on this journey and deal with the challenges ahead.
