Breaking Monoliths

Breaking Monoliths by Kanika Sharma

Several months ago 1904labs was approached by a Client to help them with their migration of legacy systems into a distributed microservices architecture.

The Challenge

A telecommunications client needed to scale its individual applications and services independently and deliver to production faster to provide greater business value.

This large, multinational communications company was using a central, off-the-shelf Enterprise Service Bus (ESB) team to manage the interactions between more than ten different applications. This unwieldy monolith system eventually became unmanageable, with developers often waiting months before being able to communicate with other services within the organization. The main problem was that the central team was tasked with implementing the business logic of many different kinds of applications, and, as such, the business logic of each was difficult to scale. The client engaged 1904labs to help in the transition to a modular framework

Our Process

1904labs helped the client break up its monolith system into a more manageable distributed microservices architecture with “Smart endpoints and Dumb pipes”. To do this, we needed to help the client move away from in-memory function calls, the method invocations that a monolith typically exhibits, and move toward more RPC-based communication patterns.

Let’s take a look at the architectural changes that the application went through when transformed from Monolith to Microservices.

The legacy monolith system our client used had 12 different source system applications, similar to the SOA architecture represented above. In order for these applications to be queried, data had to be inserted into a database. However, these source applications had no mechanism to directly post their messages to the database, and would instead send their data through the central ESB via a series of REST endpoints. This process caused delays, mainly because data from a source application could not be made available to the UI and reporting dashboards due to the central team’s limited capacity to implement the changes from each source system. Business representatives had to rely on workarounds until the transformed data could be made available in new reports.
This graphic illustrates the complexities involved in integrating systems that rely heavily on one central entity.

Outcomes

Creating scalable, manageable infrastructure

By moving into the microservices world, our client is able to independently navigate infrastructure in a manageable way. The business logic of each service stays within its bounds and doesn’t need to be distributed to other teams or applications, and the underlying communication mechanisms between the smarter services now focus solely on transporting messages.
The services can now manage their own delivery, scaling, transformations and integrations by using only the services and applications that are most important for them. Also, they are now able to handle their own routing, service discovery, load balancing based on latency, response type, metrics, distributed tracing, retries and timeouts. Importantly, they are using CI/CD DevOps principles that provide the flexibility to release their business functionalities into production on a monthly basis as opposed to quarterly or semi-annually. This created crucial business value for our client.

Be careful though…

If integrations between the services are not managed the right way, this is what it leads to…

Integration Patterns come to the rescue to achieve the ideal interconnections between the mesh of microservices. At 1904labs, we understand the native complexities involved in the integration patterns, and we help our clients succeed in their transformation of inter-process and inter-service communication patterns as they begin the migration from Monolith to a more modern, distributed, scalable and maintainable architecture.

Results-at-a-Glance

  • Significantly reduced production ready time from 4-6 months to 1 month
  • Deliver value to business at a much faster pace due to shortened release cycle
  • Speed up Development cycle
  • More manageable, independently scalable and smarter services
  • Follow the Single Responsibility Principle (SRP) design pattern
  • Well defined and explicitly published interfaces
  • Communication mechanism only handles transportation and doesn’t get complicated with business logic and transformations
  • Continuous Integration and Continuous Delivery (CI/CD) with testing ensures repeatable high-quality deployments

Our Technologies

  • Backend – Java 8 using Spring Boot, RPC
  • Interface – REST over JSON using HTTP protocol
  • Security – Integration with Akana
  • Database – HBase
  • Testing – JUnit 5/Mockito
  • Build automation
    • Docker, Jenkins for CI/ CD
    • Rancher OS for Load Balancing API
    • Ambari
  • Cloud – Microsoft Azure
  • Client’s Platform – On-premise datacenter