It’s often been said that digital transformation is not a destination, but a journey. In the past, that journey was fraught with complications and the risk of downtime as legacy systems were retired and replaced. Today, however, steering legacy systems into the digital age has been made simpler through the introduction of microservices and APIs. 

Microservices combined with APIs offer a lifeline for firms struggling to upgrade their core systems and services, bridging the divide between old and new; legacy and digital. Now, legacy systems – robust and hardy by design – can behave like digital counterparts, to innovate and evolve at scale and at speed. 

Good things come in loosely coupled packages
Microservices are an effective way for organizations to deliver features of a service in a compartmentalized and more manageable way. They break down monolithic applications into independent, loosely coupled constituents that can be delivered separately from one another and run using isolated containers. To understand why this is useful, it’s helpful to frame the challenges of maintaining legacy applications. 

RELATED CONTENT:
The next wave of API management
Communication between services key to realizing benefits

Firms that have been around for a long time have a long trail of technology that has been built upon and upgraded for many years. Legacy applications that make up the tech stack will have been built using a multitude of programming languages and software, some of which will now be unsupported and/or defunct. Often layers of complexity will have been added over the years as new languages and technologies emerged. The problem with replacing these applications is that they are, in most cases, tied to core business offerings. Replacing or upgrading them is time-consuming and costly, and potentially risks outages that might incur reputational and financial losses. 

Now, the technology framework exists to break down these applications into individual features that can be upgraded in isolation and without risk to the core service, making the journey to digital far more easily traversed. 

An architecture for continuous improvement 
A microservices architecture could be considered a subset of an SOA, but with better propensity to leverage today’s developments in cloud, PaaS and virtualization. But whereas, in a typical SOA architecture, a service is seen as a composition of other services (where a service represents a business capability), a microservice is self-contained, independent and cannot comprise other services. 

As such, there is no single point of failure, which is essential for firms for which uptime of services is crucial. Those dedicated to continuous improvement stand to gain much from breaking monolithic systems and applications down into microservices. Supporting services that augment the core offering are increasingly what sets one firm’s service or product apart from another. As is often said, it’s the little things that make a difference. But from a business point of view, the little things must not compromise the core offering. 

Many companies including Amazon, Best Buy, Uber, Spotify, Netflix, have benefited by microservice adoption in their platform strategy. The strategy helped them scale their business and improve their efficiency in product delivery. Netflix’s core offering, for example, is its on-demand content streaming service. But there are many other features that add to the overall experience of the service; the UI for movie selection, audio and subtitle options, ease of subscription, safety of personal and payment information, etc. Most of these are themselves microservices, or are made up of microservices. Should a feature need updating or removing, or the service require a new feature entirely, the modular nature of the architecture allows this to be done without risk to the core offering. Similarly, should a feature fail, the failure is localized and cannot bring down the service, ensuring maximum uptime and reliability; the ultimate goal of any service provider. 

Scaling to meet user demand
Whether servicing one or 100,000,000 subscribers, cloud service providers now let companies scale to meet the demand on their services. Cloud providers such as Microsoft Azure, AWS or Google cloud, for example, allows providers to speedily deploy thousands of servers and terabytes of storage within minutes, which is especially useful in times where usage is high. 

This is where microservices really deliver. The modularized architecture of microservices supports rapid build, deployment and scalability, and infrastructure automation has greatly reduced the complexity of managing the process. During surges in demand, such as those in gaming or streaming as the world faced ‘lockdown’ measures, it’s possible to dynamically spin up a database or a server to scale. Whilst this introduces more complexity, technology such as containers (platforms used to build, ship and run distributed applications, like Docker) and orchestration systems (that automate the deployment and scaling of containerized applications, like Kubernetes) simplifies the challenges through automation, to scale at speed and on-demand. 

Recently, services ranging from gaming platforms to Microsoft Teams have experienced vast surges in usage due to the Covid-19 pandemic, with very little impact on user experience. 

Organizations and services able to scale so readily benefit greatly from having been built in the cloud with modern technologies and programming languages. They don’t suffer the same legacy challenges as other firms and offer a window into what’s possible through microservices and APIs.

The breakdown broken down
When a legacy application is broken down into separate containerized microservices, each constituent of the original application can be divided into different business domains, which can themselves be scaled according to the demands on the services. 

Not only does the modular architecture enable scale by design, it also accommodates a mixed technology stack. This ensures that applications built with entirely different programming languages, software and frameworks can tie into the same interfaces and domains, yet come together when called by an API, resulting in a common business function. 

Take cross-border payments as an example. Every microservice involved in making the transfer possible, from account details to currency exchange, relies on an API, which is the standard communication channel for the action that must be performed by the payment provider, i.e. the business function. The modular orchestration layer provided by a microservices architecture allows each element necessary for the payment action to be activated by the API call. 

This highlights a key part of microservices orchestration, which is to identify the domain areas that will house the constituent parts of the legacy application. How can they be separated logically, yet unified in the customer-facing UI? 

When all’s said and done, the essential service and experience of customers must remain consistent. Simply put, the front end must not be compromised during transformation. Adopting a microservices approach is the most effective means of achieving the necessary change, with minimal disruption.