Cloud Native - To be or not to be

This is the first blog in a series that will discuss the technical challenges and opportunities inherent within the insurance industry. We’ll take a deeper look into some areas in which FINEOS is engaged to provide the leading global Life, Accident & Health core system to the insurance market while at the same time meeting the functional and regulatory needs of our customers. Our primary goal is to keep our configurable system modern by leveraging the technology advances that continue to evolve. Today’s blog focuses on what it means to be Cloud Native.

What is cloud native?

As the well renowned Cloud Architect, William Shakespeare, discoursed about cloud native – To be or not to be – can mean many things to many people.

At FINEOS, we think about Cloud Native all the time and how it spans a couple of dimensions that bridge the key components of any software development lifecycle. Any cogent lifecycle will traverse the key people dimension, the product you build, the patterns and tooling you apply and the processes which link all these things together and ensure repeatability and quality.

Since all problems can be solved in a 2*2 matrix, the figure below shows how FINEOS breaks down Cloud Native with a proviso that it engages the necessary guardrails of security and operation compliance – table stakes in the modern era and requiring obligatory discipline to deliver.

Cloud Native Architecture Explained

Agile Teams: This is a key ingredient of the people dimension and without this you can end up in a world of endless hand offs and silos. You will eventually get the work done and delivered, but a better way to think about delivering software is to use agile teams built with T shaped people. Agile teams come with a culture of collaboration – meaning you should see features flow left to right on your boards.

Containers: At FINEOS, we’ve declared our container answer is Docker at the tech level. The low overhead of creating and destroying containers combined with the high packing density in a single instance makes containers an ideal compute vehicle for deploying individual pieces of functionality or components.

APIs:  An architectural approach to developing any software is ensuring it is componentized and it comes with a clean API. A clean API caters for access via standardized methods. APIs typically expose business capabilities allowing the execution of same and providing a tidy upgrade path with no or limited upgrade path for end clients. Once you have APIs designed the next logical step is to move these to Microservices if you are not there already.

Automation and DevOps: Cycle time is by any rough gauge, a measure of your process speed. Rather assuming that having a process means you are efficient, best to think about it with a quantitative measure, which removes bias and allows a simple baseline from which you can drive improvement. Put it another way, I’d rather have my Engineering team talk about the cycle time to production than their actual vs estimate number – or worse still – the dreaded rigged game velocity and points consumed. Drive cycle time through increased levels of automation and you have a north star to follow.

So next time you hear someone bandying around the term cloud, stop to consider if they actually mean cloud-native – this is where the future lies.

If you’re interested in further discussion about our technical ecosystem, please reach out for further discussion, whether you are a customer, potential FINEOS employee or a lover of architecture.

You may also be interested in