Insurance legacy systems | Georgina | 18 June 2021
With many insurers looking into long and short term plans for their digital transformation journeys, one of the biggest things to consider is the architecture that underpins your solution and needs. Monolithic and microservice architecture are different; and depending on your needs, there are pros and cons to both.
What’s monolithic architecture?
Monolithic architecture is an application that’s built as a singular entity. The client-side user interface and server-side applications are all hosted in one place within a ‘monolith’. (The database is hosted outside on a dedicated server).
Why do monoliths still exist?
The processes and functions that run within it all rely on each other to work – and once this behemoth is built (and is working) it’s not particularly easy to pick it apart. Many legacy systems are built in a monolithic-style manner. There is also a level of convenience to monolithic architecture. Having one (albeit huge) entity that does everything in one place has its benefits. These benefits include:
- Fewer security concerns compared to microservices – as there’s no need to connect different applications with each other, security measures for these connections don’t need to be created
- A convenient and simple solution for smaller internal teams to manage
- No requirement for microservice-specific talent. Managing microservices takes a lot of specialised expertise. Business value is unlikely to occur if you do not have the internal resources and knowledge to handle them. Monoliths take out that need.
- Speedy deployment/launch. Once the system is up and running, everything is simultaneously live
- Less latency compared to microservices. The individual connections between applications in microservices
What happens when monolithic architecture goes wrong?
When there is a breakdown within the architecture, the entire monolith must be taken ‘offline’ in order for the fix to be discovered and sorted. This can result in significant disruption to the entire system; especially if the fix in question isn’t a simple one. The risks are higher when something breaks, which will reflect on the cost. Due to the complex nature of monolithic architecture, the internal resource (talent) needs to know it back to front; which can be a challenge for new talent in the team.
What are microservices?
Microservices are different to monoliths. Microservices, as the name suggests, are where the applications are spread out across various computers and numerous APIs.
How are microservices different to monoliths?
Microservice architecture is a distributed system built up from multiple modules that communicate with one another through APIs. Each individual module/application can be scaled, updated and deployed separately. With monolithic architecture, the entire system is updated, scaled and deployed in one go. However, these individual connections need to be handled very carefully. Microservice architecture is only recommended for teams with a suitable amount of internal or third-party expertise; not only in the creation and deployment of the applications, but the maintenance and testing too.
What are the benefits of microservices over monoliths?
Microservices have various strengths, such as;
- Scalability is easier with microservice architecture. With microservices, you need only add to the service(s) you wish to expand. Monolithic architecture would need to be scaled as a whole, which can be more expensive and time-consuming (however there’s an argument that it’s more convenient). When throughput increases within microservice architecture, scaling horizontally makes the system cheaper
- They’re easier to update when needed
- The whole system doesn’t need to be taken down for changes/updates to be made
- Similarly, when there’s a bug, only the service needs to be taken down in order to apply a fix. With monoliths, the entire systems needs to be taken offline
- Microservices are easier to manage internally. The concept can be easier to apprehend compared to monoliths as each application works independently in a broken down fashion
- Reliability. When there are multiple nodes running on the application, if one falls, the other ones can take up the work
What insurers need for either monolith or microservice architecture
Insurers with monolithic architecture may be considering a change to microservices. This is not as easy as it sounds. If insurers wish to make this colossal change, that change must be made from the ground up – and it can take time. Things to consider are:
- An assessment of internal expertise (and the resources required to obtain further talent)
- An assessment of all existing systems – including a health check (looking for best practices, technical debt that’s accrued etc)
- Partnerships with integration experts in both monolithic and microservices architecture
- A long-term, agile plan to be established
- Excellent communication with these partners
There’s a lot to consider when choosing or changing your architecture. The primary recommendation we would make is to get in touch to explore planning out your systems.
