Insurity Uses Microservices to Provide Custom Solutions
Insurity Uses Microservices to Provide Custom Solutions
Smaller, more independent components enable clients to build custom and customizable implementations to meet their needs.
Join the DZone community and get the full member experience.Join For Free
How is Insurity using microservices?
We provide a suite of solutions to the insurance industry, including policy administration, claims, billing, and more. Insurance technology solutions are naturally comprised of many discrete components such as location services that indicate whether an address is in a flood zone and classification services that provide class codes for business types. This makes microservices a natural fit for our technology. We’ve been pursuing microservices by breaking larger components into smaller more independent components and bringing them together into an aggregate application. We’re in the process of providing granular functionality at an API level for clients.
What are the most important elements of microservices to Insurity?
Microservices fit with the direction we are moving toward in agile development. Breaking problem areas into small pieces of functionality allows us to be more agile and concurrent in our development and testing. We’re able to test independently and then put components together into a larger application. Microservices enable our customer to put together their applications in different ways for different states and different lines of business. We provide externally consumable pieces, so clients can use what they need.
Which programming languages, frameworks, and tools do you use to build out your microservices?
We’re a Microsoft shop so we use C#, ASP.NET, and ASP.NET Core. We use PowerShell and Jenkins for deployment. When building controllers, we use Swashbuckle to add annotations to our code and generate Swagger documentation and test harnesses.
How have microservices changed application development for Insurity?
This stretches across several areas of our business. We built service-oriented architecture (SOA) services for a while. Moving toward microservices is pushing us to build functionality as small but consumable artifacts. We must decide what size and how to package behaviors that are meaningful at the right level. We have a product owner liaison between the developer and consumer base to help developers figure out what level of a component to build. This has shifted our perspective on how to test. We’re doing more service level testing versus testing an integrated suite. We use automation tools to test inputs and outputs to services. Unit testing services use Swagger and we do larger regression tests at the service level.
How are you securing your microservices?
In the insurance domain security is a primary focus. We protect data rigorously and have Role and User-based security built in at the lowest level. We previously used SOAP standards such as WS-Security and WS-Trust. Now we’re using REST services with a token-based authorization system provided by our federated security manager. We’re also looking at OAuth and OpenID to smooth out integration from a system perspective.
What are a couple of use cases you’d like to highlight?
We recently built a service that provides tax and surcharge functionality. Traditionally, this is handled as a part of the large policy rating process. We extracted this functionality and turned it into an independent service that can be consumed by our rating system and customers alike. We’re also building services for customers to update policy entry data like locations or coverages.
What are the most common issues you faced building out your microservices?
A fundamental challenge is defining the size and shape of a service that is intrinsically consumable and usable. You want to create services that are neither too big nor too small. Too many granular services communicating too much can hinder performance and become difficult to maintain. On the other hand, if your services are too monolithic then they are not easily consumable and you are not meeting the long-term potential of microservices.
Do you have any concerns regarding the current state of microservices?
Microservices is a design technique to build functionality at a granular level. It’s not a concrete standard. Interoperability can be a problem if you don’t have rigorous design standards. To leverage the promise of a microservice strategy the broader technology industry needs to move in a direction where companies work together for a common goal.
What’s the future of microservices from your perspective?
Along with the move toward small services, we also started using Docker and Kubernetes to build and deploy componentized applications. These will continue to grow in adoption. They both fit well with the vision of microservices. Also, the move to low-and-no-code applications, where customers can take component pieces of applications and put them together in a very customized way to meet the need of an individual will become more critical.
What do developers need to keep in mind when working on microservices?
It is more important than ever to consider the broader use of the functions they are building. This requires a change in perspective. You are building a piece of functionality that can be part of an ecosystem. Think about treating behaviors as products in and of themselves. There are more rigorous testing requirements and deployment considerations when building a behavior.
What have I failed to ask that our reader needs to consider?
What kinds of partnerships can be made with the big cloud providers and what do they bring to the table for hosting and deploying microservices? Also, which API management products are best suited for a microservice-based strategy? At Insurity, we’re working to determine the solution that will best meet our needs.
Opinions expressed by DZone contributors are their own.