Escape legacy software with microservices architecture

Escape from a legacy monolithic software estate by adopting a microservice architecture

Many industries carry the burden of legacy software solutions which, although old and clunky, are still absolutely essential to daily operation. Furthermore, there are often multiple systems, written at various points in the past, in different programming technologies, and adopting different security mechanisms. Where systems are secured, users may need to remember multiple sets of credentials.

Although there may be aspirations at the highest levels to replace the legacy systems with a shiny new solution which “does it all”, the practicalities of doing so are incredibly challenging. Not least the avoidance of disruption to the primary purpose of the company: to manufacture goods.

This is where the adoption of a microservices architecture can help, as it allows “bite sized” subsets of the software estate to be replaced in an incremental fashion, with new services being introduced sequentially, over a manageable timescale. Staff can become comfortable with new services, each of which provides a small, de-coupled “portion” of functionality. The impact on the overall business will be significantly reduced, and the risk that would be posed by a “big bang” software solution replacement is mitigated.

This article describes how a microservices architecture and single sign-on can be leveraged to deliver a suite of interacting services, each of which “stands alone”, but together they form a cohesive “whole”.

New services can be added to the “ecosystem” over time, as a series of legacy software solutions are slowly (and carefully) substituted for modern replacements. The new microservice ecosystem will be accessed using the common set of credentials offered by single sign-on.

Single Sign-On

What is Single Sign-On?

In its most basic form, Single Sign-On (SSO) allows a user to enter their username and password once, and gain access to a range of systems called Service Providers which requires authentication and authorisation.

The system where the users enter their username and password is called the Identity Provider (IdP).

Websites, systems, and mobile applications, referred to as Service Providers, are first registered with the IdP for them to be able to send users to the IdP for authentication and additional authorisation.

Once a Service Provider has been registered with an IdP, a user can navigate to the Service Provider, where they will then be sent to the IdP to enter their username and password. They can also have the option to perform two- or three-factor authentication. After successful authentication (and optional consent to share details with the Service Provider), the user is then directed back to the Service Provider and given access to resources.

Secure Token Service 

An additional function of the IdP is to be able to issue secure tokens. This referred to as a Secure Token Service (STS). The purpose of using these Secure Tokens is to enable integration with a third-party Application Programming Interface (API) where authentication and authorisation is also required.

Adding an STS to an existing or new software system can ease the integration of third-party systems in the future. 

User Flow Example

Advantages of Single Sign-On

• User credentials are not revealed to multiple systems
• The user needs to remember only a single username and password
• It reduces the number of times a user needs to authenticate
• It allows separate systems to provide a more seamless user experience
• It simplifies authentication and authorisation in a microservice-based architecture

Considerations for Single Sign-On

Single Sign-On has many advantages, but consideration should be given to the following:

• The IdP needs to be properly protected and secured
• If the IdP is not available for any reason, users will not be able to authenticate with a range of Service Providers

Microservices

Building quality, robust and reliable software is no trivial task

The world of technology evolves at an extremely fast pace, particularly in recent years. Across various industries, many organisations are juggling the problem of managing with both digital transformation and legacy systems. This means that software companies like PDMS face the challenge of creating ever-evolving software systems that not only adapt and scale on-demand, but are easy to use and do not impact other parts of the software solution.

Monolith vs Microservices

The traditional yet still valid way of architecting a software solution is the 'monolith' style. This means that the entire software solution is made up of one system. It uses the same codebase and is maintained by a single team.

A single monolith serviced by one database that provides the complete software solution

An alternative and more modern way of software architecture is 'microservices'. This approach breaks up solutions into smaller, loosely-coupled components that can function independently of one another. These microservices then function together to form a complete software solution.

Multiple microservices and databases can work independently and when combined, they provide a complete software solution

A recent example of microservices being used at PDMS is our work with the Northern Powerhouse. We implemented multiple regional employability and skills portals to help those impacted by the pandemic to find opportunities in their local area. The solution utilised our SignedUp Skills portal which is made up of various microservices that work together to create a bigger ecosystem.

Advantages of microservices

There are many benefits to this approach:

• Technology from different vendors can be mixed and matched together
• New services can be introduced as the landscape changes
• Microservices can be scaled up or down independently as required
• Smaller cross-functional teams can work on microservices independently and without causing code conflicts
• A microservice that performs a common function can be utilised by multiple different software solutions
• There are small multiple code bases to maintain, test and release

Microservices combined with Single Sign-On

Both microservices and Single Sign-On architectures and development techniques have many individual advantages. However, when combined, they offer additional benefits to an organisation and allows the creation of 'Micro Applications'.

The concept of Micro Applications, or Micro Apps for short, is an extension of microservices, but with an added user interface which handles a focused set of user functionality. These Micro Apps are then assembled to form a combined set of functionalities which span multiple aspects of a business or organisation and creates a coherent and seamless user experience.

Single Sign-On is the technology which then allows a user to navigate between the Micro Apps while only being required to authenticate once.

The advantages of Micro Apps are very similar to those of microservices. One of the biggest benefits is that when the system is made up of multiple Micro Apps, if one of the Micro Apps is offline, users are still able to use the rest of the 'system'.

To compliment the user experience, Micro Apps share similar user interface designs and a common menu structure which allows the user to navigate to other Micro Apps which form part of the unified system.

In conclusion

Microservices architecture is just one of many different architectures that can be used to create software solutions and they do not necessarily replace the traditional monolith architecture. Both have a place and should be carefully considered when thinking about the present and future vision of the software solution.

To find out more about how you can escape your legacy software, visit our legacy system modernisation page