Refactoring legacy O/BSS applications to microservices-based architecture

For digital native players, the strategy is quite straight forward since all the functional modules are developed from scratch as a microservice component. However, in the case of larger digital service providers (DSPs), the siloed, bulky, monolithic systems are not flexible enough to scale with changing customer needs. Telcos are now looking to embrace the concept of microservices as a new architectural framework to achieve business goals such as agility, flexibility, and to operationalize manifold digital business models.

Proposed five-step strategy for microservices rollout

The below infographic highlights the five mandatory selections for DSPs to consider before embarking on the microservices journey. Each stage has a proposed qualification checklist with key recommendations to navigate through the migration journey.


1. Decoupling the functional modules to achieve modularity

There are no best practice methodologies or set of standard procedures for selecting the functional modules for migrating to a microservices-based architecture. Decoupling monolithic application components mainly depends on various technical, business and operational needs. The below checklist assists in segregating modules into domain or sub-domain levels and helps DSPs to identify the best-suited modules for microservices within a legacy application.

  • Does the module handle a large volume of events/traffic?
  • Does the module require dynamic scaling during run time?
  • Does the module get frequently modified or enhanced?
  • Does the module get customized for different customers?
  • Is the module subject to frequent maintenance releases?
  • Is the module being developed by geographically distributed teams?
  • Does the module perform a similar function?
  • Does the module has limited interfaces with other modules?
  • Does the module perform a highly computationally intensive task?

If most of the answers to the above checklist are YES, then it’s the most suitable candidate to be migrated to microservices on priority.

2. Choosing a suitable development framework based on business requirement

There are multiple frameworks, which help in developing microservices and the most suitable framework is chosen based on the business requirement and features supported. It is also possible to use more than one framework seamlessly integrated for building microservices. Below checklist assists in narrowing down various options for selecting the most suitable framework for the development of microservice modules.

Checklist for choosing a development framework

  • Is there a need for ease of use and quick project building?
  • Does the application require a quick introduction of advanced/new features?
  • Does the application require most advanced RESTful support?
  • Does the team expect support from an open community?
  • Does the framework have a minimal size and occupy less memory?
  • Does the framework enable production-ready and fast deployment?
  • Is performance a key factor for the application?

Below is the list of recommended java-based microservices development frameworks and their key features.

Framework nameDescription
Drop Wizard
Quick project building, bootstrapping and fast-paced development
Spring BootProduction ready, fast development and feature complete framework (Spring portfolio)
RestletAdvanced RESTful support, powerful, steep learning curve and closed community
SparkTakes time to introduce advanced features, simple to use and runs fast
MS4JAvery fast start-up time, low memory footprint, high throughput, and low latency
PlayQuick project building, bootstrapping, easy to develop and not suitable for larger projects

3. Choosing the appropriate chassis framework for improved agility

Any generic chassis framework comprises of gateway services (API gateway, service router, circuit breaker, load balancer, and security) and operational services (service registry, service configuration, and service monitoring). The selection of an appropriate chassis framework requires trials and proof of concepts to identify the right one that best suits the application needs.

To better understand this, let’s analyze two of the leading chassis frameworks in the market, viz – Netflix OSS and WSO2 for improved agility and elasticity. Let’s consider a specific module from the legacy system as a sample to refactor into a microservices component. Develop the prototype of selected microservices module using the first combination – Spring boot development framework with the Netflix OSS chassis
framework. Compare the results with the same microservices module developed using the second combination – MS4J framework integrated with WSO2 chassis framework and choose the appropriate one.

However, the chassis framework alone does not guarantee the application’s performance or stability. It is also important to choose the right microservices design pattern to make the application fully functional with high performance, resilience and fault tolerance.

4. Choosing an optimized design pattern to fine tune the application’s performance

Microservices design patterns are the repeatable solution to a commonly occurring problem in software design. Design patterns act as a template for how to solve a problem that can be used in different situations. Based on individual application characteristics, scalability, migration strategy, performance, and deployment needs, DSPs should choose the most appropriate one.

The following list explains the most commonly used design patterns for migrating O/BSS legacy telco- related applications.

  • Aggregator pattern: When aggregation of data from multiple services is required, then it is recommended to use aggregator microservices design pattern. Examples such as self-care or customer care portals and billing applications are right candidates for aggregator pattern.
  • Proxy pattern: In a phased migration approach, a proxy microservices design pattern is leveraged to have both monolithic and microservices applications co-work seamlessly.
  • Branch pattern: Scenarios where a request is processed by a single and chained microservices to provide a consolidated response such as generating customer usage reports, branch microservices design pattern is used.
  • Event-driven microservices pattern: When asynchronous request handling is required, then an event-driven microservices pattern is used. The order management system is one such example.
  • Chained pattern: Whenever a single consolidated response is required after sequential processing, chained microservices pattern is used – VAS system is one such example.

The final step before the actual development of microservices is to set up a CI/CD pipeline.

Choosing a suitable continuous deployment framework

Microservices are highly cohesive independent services. An application may have built with hundreds or thousands of microservices and it is essential to have them work together in an orchestrated way.

Microservices-based architecture brings in a lot of agility, which makes adoption of DevOps culture easy. The final step before the complete development of microservices is to set up continuous integration and continuous deployment pipeline, which enables the below functionalities.

Having a robust continuous deployment framework will bring out the benefits such as:

  • Dynamic deployment of independent services without impacting co-existing service components
  • Reliability and seamless upgrade of various microservice versions
  • Ease of management and auto-scaling of services

Conclusion

Shifting to microservices-based architecture is an important step in the digital transformation journey. The migration approach discussed throughout this article is applicable to any DSP that has huge, legacy monolithic applications in place and prepare to switch to microservices.

This transformation will not only help operators to achieve agility, flexibility, and scalability but also derive granular insights, which can be leveraged to deliver superior customer experience and enable new business streams.

Authors:
Kalpana Angamuthu – Associate Director, NextGen Labs, Prodapt Solutions
Madalai Muthu Jacob – Senior Technical Lead – Delivery, Prodapt Solutions Mogan A.B. – Manager, Strategic Insights, Prodapt Solutions

Editor's Choice

Editor's Choice consists of the best articles written by third parties and selected by our editors. You can contact us at timothy.adler at stubbenedge.com