Cloud Native Delivery: Microservices and API’s

Cloud Native Delivery: Microservices and APIs

In our last blog on this subject we looked at ICE’s journey to cloud native and briefly touched on our use of containerisation to achieve the best results. In this weeks’ blog we take a look at two more core facets of cloud native delivery and how we feel they are best used in Insurance applications such as the solutions offered by ICE InsureTech.

The first of these is microservices. Microservice based architectures are currently in vogue. They “deliver small, discrete, and individually deployable services”. Some of the key benefits of microservices are; the ability to independently deploy and scale functional components, theoretically enabling improved agility in release cycles, and the ability to combine best of breed components within a functional suite.

ICE has been architected from its inception to be assembled from thousands of services using a Service Oriented Architecture (SOA) approach on top of a single domain model. We believe it is prudent not to rush from SOA to a microservice architecture. There are potential negative performance and operational complexities of a microservice architecture that may not be suitable for all aspects of a transactional insurance solution. Our current mini/microservice strategy is to target functional components where independent scaling is a high priority, e.g. rating orchestration and enrichment, aggregator gateway, quote and buy, API etc. and where it may be required to swap a component for an alternative implementation (e.g. BPMN engine). This will allow us to deploy a topology best suited for a client and the environment demands.

The second area for consideration is API’s (Application Programming Interfaces). An API allows components to interact through clearly defined methods. In an insurance platform, it can be crucial to expose key services to third party systems and components that require access to core platform functionality. Examples of these services are Get Policy Details, Create Quote, Create FNOL, etc.

To ensure we have the capability to do this securely and swiftly, the ICE suite has a combination of Public, Open Business and Private APIs. Private APIs are for “internal use” only – they are not documented and liable to change without any notice. Public APIs, on the other hand, are documented and versioned. Both private and public APIs are secured with our security framework. Open Business APIs are used for integration with trusted partner systems, e.g. ICE or Third-Party Portals, Client ESB’s etc. These are secured at the protocol level and are not available to the general public.

Service based architectures and API’s are key facets in cloud native software development and ICE has used both principals from day one. By providing services and APIs, every component has the ability to integrate with other internal and external components to deliver an insurance suite, tailored to the requirements of a client. We have taken the stance to move aspects of the ICE platform to a microservices architecture, but we are only moving aspects with due consideration of the benefits and the limitations.

To find out more about our current technology platform, please visit our resources centre and download the latest white paper.

#ThereIsAnAlternative

More articles