In the past, VMware IT built business applications with minimal viable features as fast as we could, like most IT shops. We used existing technology stacks and followed known business requirements. After the initial product was rolled out, we kept building the apps, adding thousands of lines of code for new features. As the codebase and usage increased, the application often started to crumble. It was then that we realized we had built a monolith, something FAST, but ultimately FRAGILE.
An example of this is the VMware Entitlement Management System, which was built as a monolith application. It provides four major features for the perpetual licensing business: License, Support, Entitlements, and User Access Control.
The application worked fine at first. But as the number of users increased, the data grew exponentially faster than the speed of light. New business functions were added. Soon the system started showing signs of wear and tear. Performance issues increased. The tight coupling with our ERP system impeded the speed of new feature development. This marked the end of the Entitlement monolith.
Deconstructing the Monolith
When you have a monolithic system like Entitlement Management and it’s a lifeline for your business operations, breaking up the system is very challenging. It’s like doing a major bypass surgery or an organ transplant. We had to find a solution that would give our large customers complete access to view and update their licensing information by eliminating performance and data visibility issues. But, because it’s business critical, we could not impact our production environment.
We started by analyzing the problem areas that customers had reported. Then we mapped the problem areas with the functions so we could start with the most impacted function first. This was an important step in the decomposition process. This seems contradictory, but past experience has taught us to pick the most impacted area first, and then move on to the next.
Our number one priority was to build an application that was independently deployable and operable. The design should be independent of the technology., so when business funcions/processes change, technology doesn’t become a limitation. Services should be provided via communications, not integrated into the application to give us future flexibility. This approach enables business functions to be decoupled. Services are easy to scale and deploy without affecting other functionality. We also wanted to use agile methodologies to enable a faster pace of development and code release.
Apart from the functions listed within the Entitlement domain, we looked at how each subdomain was interacting with other subdomains. Were there any dependencies? For example, we found that user permissions had crept into a subdomain. Carving out the bounded contexts for each of the subdomains from the Entitlement domain looked like this:
As depicted in the upper portion with solid blue line, the current single bounded context is called the Entitlement Context. It covers the four subdomains: License, Support, User Access Control, and Entitlement. Our future model was comprised of independent contexts for License, Support, and User Access Control. We wanted it to look like this:
We chose to use a domain-driven design. The Entitlement subdomain is basically a combination of License Entitlement and Support Entitlement. This was split into two separate subdomains, each within its own bounded context. In this way, bounded contexts became explicit and linguistic. The new contexts were more like conformist-type in the current model. They are visually represented below. We also needed an anticorruption layer on the License Entitlement Context; it was completely isolated from the upstream ERP system.
One of the most important parts of this domain-driven design was the strategic design. With the domain model and repository schema in place, we looked at various options for the technology components.
We leveraged the VMware IT Cloud-Native Platform heavily to onboard all our microservices. The platform uses Pivotal Cloud Foundry (PCF) for cloud-native services. PCF allows developers to focus on the application without worrying about operations. VMware Wavefront provides monitoring. VMware vRealize Log Insight collects information from PCF and acts as the log aggregator. (To read more about our cloud-native technology, read our blog.)
With the message queues, monitoring, and consumer microservices in place, we were now able to capture the relevant data for the License Entitlement subdomain. All current transactions publish the information to the messaging broker. Then consumer microservice subscribes to and applies the messages to the License Entitlement subdomain.
This newly developed services were deployed two weeks in advance in our production environment without any disruption to our business. We validated that all the transactions were properly populated in the subdomain repository. Following the subsequent deployment two weeks later, we ensured that all the read parts were enabled from the subdomain by new services deployed within PCF. These services have resulted in a 10X performance increase against a 6X load, compared to the previous 2X load.
Positive impact on Customer Experience with Cloud-Native
This project was a major step forward in moving from a monolithic system to one built on microservices. We built a completely independent licensing solution that decouples the systems dependencies. By leveraging a services approach, we resolved the data visibility and performance issues and ensured customers could easily access all of their licensing information in one place. Our vision of a completely independent License Entitlement domain will become reality when we move the write operations in the future.
VMware on VMware blogs are written by IT subject matter experts sharing stories about IT’s transformation journey using VMware products and services in a global production environment. Visit our portal to learn more or follow us on Twitter: @VMWonVMW.