Skip to main content

Architecture: Monoliths and Microservices

Insight Published on 11 December 2020

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.

Websites, systems, and mobile applications, referred to as Service Providers are first registered with the Identity Provider, for them to be able to send users to the Identity Provider for authentications and additional authorisation. Once a Service Provider has been registered with an Identity Provider, a user can navigate to the Service Provider, where they will then be sent to the Identity Provider to enter their username and password, and optionally perform 2 or 3 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 (STS) 

An additional function of the Identity Provider 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 a 3rd party API integration where authentication and authorisation is also required. Adding a Secure Token Service to an existing or new software system can ease the integration of 3rd party systems in the future


User Flow Example

Advantages of Single Sign-On

  • User credentials are not revealed to multiple systems
  • User needs to remember only a single username and password
  • Reduces number of times a user needs to authenticate
  • Allows separate systems to provide a more seamless user experience
  • Simplifies authentication and authorisation in a microservice based architecture


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 authentication with a range of Service Providers


Building quality, robust, and reliable software is no trivial task

The world of technology evolves at an extremely fast pace and many organisations are juggling the problem of dealing 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.

The traditional way, and 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, using code type 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 architecture software 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 provide a complete software solution.


A recent example of Microservices being used at PDMS is our work with the Northern Powerhouse where we implemented multiple regional employability and skills portals to help those impacted by Covid-19 find opportunities in their local area. The solution utilises our SignedUp Skills portal which, you guessed it, is made up of various Microservices that work together to create a bigger ecosystem.


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 very focused set of user functionality. These Micro Applications are then combined 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 Applications and is only required to authenticate once.

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

To compliment the User Experience, Micro Applications share similar user interface designs and a common menu structure which allows the user to navigate to other Micro Applications which forms part of the unified system.

Final thoughts

Microservices architecture is just one of many different architectures that can be used to create software solutions and does 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.