Bridging the Divide: A Story of Two Legacy Applications and One API

There is no doubt digital transformation is affecting how businesses operate online with cloud computing offering compelling benefits, from unprecedented flexibility in IT infrastructure use and consumption to significant cost savings. 

With the market diversifying into a myriad of cloud services across the entire range there is a big push towards changing traditional monolithic IT estates into a landscape of integrated building blocks comprising a multitude of specialised services. The traditional on-premise IT infrastructure gets more and more dissolved into a network of services in a hybrid cloud (on-premises and public cloud) and multi-cloud (procuring services from a multitude of public cloud providers) – frequently it is a mix of both. 

The challenge to IT architecture is thus how to align and integrate these services with the legacy estate that often still follows the monolithic approach to designing IT applications.  In this article, we will explore this challenge and look at how this can be addressed. There is nothing new about IT software and hardware ageing. 

What is new, however, is the increased need for resource efficiency while maintaining operational requirements and performance in an increasingly distributed environment. Customers and clients expect an individualised approach and experience across a multitude of devices and locations, inevitably creating a far more diverse usage and data generation pattern than ever before.  

To summarise, performance efficiency comprises the following aspects: 

1. Optimised usage of computing resources
2. Maintaining operations within required parameters
3. Maintain that efficiency across demand and technology evolution

In your digital transformation process, the strategy on how to address these requirements and respond with a modern IT infrastructure architecture that perfectly fits your needs becomes key. Inevitably, you will not only have to integrate external services into your IT portfolio, but you will also have to address the architecture of your own custom software applications and services, then decide how to evolve it to fit the modern era of cloud computing. 

Many Roads Lead to Rome, The Same is True for Digital Transformation

The first step is to define your individual Rome: the desired end state of your application. A cloud-native architecture may not be your end goal for a variety of reasons; there is no universal architecture that fits every business’s needs and models. In our experience, there are two key software engineering principles of well-performing and efficient IT applications: 

• Principle 1 – Writing Less Code is Often More
• Principle 2 – Standardise on Reusable Components

Writing Less Code is Often More

This might sound counter-intuitive but it is in fact, a key ingredient often forgotten. 

An example describes best what this means: Software development departments try to measure the productivity of their employees using KPIs. 

Since it is easily measurable, they often count and aggregate the lines of code written over a given period, e.g. a week or a month. However, this does not account for how these lines of code came to be: If, for example, you replace large chunks of self-written code with integrating a third-party library (often open-source) then all of a sudden your KPI drops (or reverses into negative if calculated as relative change) and your internal employee happiness team will be on your case. But all you did was improve performance and efficiency (given that you chose the right library to integrate) with less code you need to write and maintain yourself. The key takeaway here is that you do not need to reinvent the wheel when others already have solved the problem for you. 

Standardise on Reusable Components.

While this sounds similar to the previous point, it addresses the code and architecture you’ve chosen to maintain yourself. This entails reviewing the architecture and looking for elements that can be reused whether internally to the application, or across your applications. Often, this goes hand in hand with the decomposition of your IT software from tightly coupled to loosely coupled reusable components. The keywords here are API driven and MicroServices – (we discussed the latter already in one of our previous blog posts). 

API Driven Microservices: The Staple of a Modern Multi-Cloud Strategy

A classic example of an API driven IT architecture is that of user interfaces across many different access media. A classic three-tier design would feature a presentation layer, a business layer, and a persistence layer, connected using HTTP/HTML and SQL, respectively. 

In the modern times of Smartphone access to the Internet and hence your services, screen size is the most limiting factor when it comes to providing mobile access to your website. One approach would be to change your website layout to a mobile-first approach. This is what modern SEO is all about, certainly since Google and other large search engines access and assess your public services with a mobile-first assessment kit. But mobile-first gets you only so far and is often not suitable for scenarios where real interaction and data generation take place. Means of input are entirely different on a mobile phone from a classic desktop, therefore your approach to user interaction should be different, too. The solution supporting interactivity across access media is an API driven architecture:  

• Your website is designed as a mobile-first website that equally lays out well across a variety of access media such as desktops, tablets, and mobile phones. Design the website to partition it into areas designed for (mostly) consumption and (mostly) interaction.
• Shift as much as possible (but within reasonable boundaries) state management and data requests to the client, using modern JavaScript frameworks and asynchronous partial data requests instead of re-requesting entire pages.
• Design and deploy a native mobile app that is not trying to replicate the web browsing experience but makes use of the different set of interaction and input devices available on e.g. mobile phones.
• Integrate the various end-user access components (website, mobile app, etc.) with your business logic via a REST-based API exposed by the API facade. 
• In your API facade, route requests through HTTP path endpoints to deliver static content via direct pass-through to storage (or, for aggregated static content via serverless components) and interactive requests – particularly for modifying data – through routing these requests to container-based microservices.
• Further analyse your backend, particularly the business logic tier, for more potential in decomposing components into microservices. Connect these through a high-throughput messaging service using a sufficiently differentiated set of channels for efficient message routing, delivery and processing.

This comparatively simple change in architecture may seem to be overkill at first, but the loose coupling of smaller components directly builds the foundation for a more agile and responsive IT landscape. 

Here are the top four reasons why you should consider switching to an API-driven architecture: 

1. A workload decomposed into smaller components is much better suited to scale on the component level than a system with a monolithic architecture.
2. Scaling out individual components based on demand wastes next to no resources, whereas a monolithic workload scales all components whether they need to scale or not. This causes overprovisioning of resources needlessly increasing the TCO of your cloud estate.
3. Switching to an API-driven architecture allows for a far easier and effortless evolution of your code, as it reduces the level of impact at large constraining it to the component level.
4. Smaller workload components shielded by APIs allow for far easier introduction of third-party libraries that serve focused needs, instead of accepting compromises on libraries that are re-used across a monolithic workload.

There is a fine balance you need to maintain on the scope and aggressiveness of decomposing your workload into an API driven microservices architecture. The one undeniable benefit of a monolithic architecture with tight component integration is the speed of function/procedure calls. And the more you introduce APIs and indirection via loose coupling of components, the more your workload’s internal communication will rely on the comparatively slow network-based remote invocations.  While performance loss through network calls can be mitigated, it requires experience and expertise in distributed computing. 

Digital Craftsmen is ready to assist all businesses with designing and building a modern distributed, scaling, and performant cloud workload architecture. 

Email us at [email protected], call on 020 3745 7706 to book a FREE workshop with our solution architects by signing up here.  All our expert services and consultancy are fully verified by ISO27001 and Cyber Essentials Plus accreditations.