Most CIOs recognize the need to be more agile in order to compete in a constantly changing environment. In financial services, the surge of startups and the threat of unconventional competition have driven IT organizations to establish development practices that allow their companies to quickly react to change. Despite this realization, technology leaders are often stymied by once-cutting-edge systems that are now relegated to the status of “legacy application.”
Vanguard is no stranger to this predicament. Forty years of success has left us with our fair share of older, monolithic applications – some of which I even worked on myself when I started my career at Vanguard 23 years ago. But, despite our best instincts, simply throwing away what we have and starting from scratch is almost never a practical option – especially when the system is fundamentally sound thanks to years of in-the-field testing and engineering.
Instead, Vanguard has begun a journey to break apart our monolithic legacy systems piece-by-piece by replacing them with microservices over time. With a microservices architecture, we remove the business logic and data logic from our applications and replace it with a set of re-usable modules of code that are built and deployed as independent entities. We then compliment this architecture by chunking out our user interfaces into modular purpose-built components.
This service-based approach to application architecture provides a variety of advantages over the jumble of code that defines a non-modular monolithic application. First, services reduce redundancy by making sure there is only one copy of application logic for a given capability – regardless of how many applications leverage that logic. In the long run, this leads to lower development costs and increases speed to market. Second, since these services are deployed independently and built in a resilient manner, outages in one area of an application are less likely to bring down an entire system. In some instances, several of our services can be down without our clients being aware of a loss in functionality thanks to the ability of our applications to automatically react to a service that isn’t available. Finally, services enable our applications to scale easier. The marriage of cloud and services means we can quickly spin up infrastructure to handle surges in the number of transactions we need to handle without needing to scale up an entire application.
Of course, while replacing monolithic legacy applications with microservices sounds appealing, how companies get there is where many fall flat. Our approach to migration borrows heavily from what Robert Martin, author of "Clean Code," calls the Boy Scout Rule: Leave the code cleaner than how you found it. For our engineers, this means replacing the parts of the monolith they touch with services anytime they make enhancements or introduce new functionality.
Like all rules, there are exceptions. Sometimes there are instances where it makes sense to create a service even if a project wasn’t planning on modifying the underlying codebase that the service will replace. Other times, we can’t justify the time, expense, or risk of creating a new service, but we don’t want our modern applications to rely on a mix of microservices and older legacy technology. In those situations, we might create temporary services with the expectation that they’ll be replaced with fully functional ones in the future. This abstracts away the complexities of dealing with a legacy application and makes it easier to replace those older systems down the road.
By enabling the applications in our portfolio to leverage a common pool of microservices, we’re enabling Vanguard to adopt the latest Lean development practices without incurring the risk or cost of a massive re-platforming.
