openIDL platform provides a standardized data repository streamlining regulatory reporting and enabling the delivery of next-gen risk and insurance applications

San Francisco, Calif., April 12, 2021 – The Linux Foundation, the nonprofit organization enabling mass innovation through open source, and the American Association of Insurance Services (AAIS), today are announcing the launch of OpenIDL, the Open Insurance Data Link platform and project. The platform will reduce the cost of regulatory reporting for insurance carriers, provide a standardized data repository for analytics and a connection point for third parties to deliver new applications to members.

openIDL brings together some of the world’s largest insurance companies, including The Hanover and Selective Insurance Group, along with technology and service providers Chainyard, KatRisk and MOBI to advance a common distributed ledger platform for sharing information and business processes across the insurance ecosystem.

The first use case for the openIDL network is regulatory reporting in the Property and Casualty (P&C) insurance industry. Initially built with guidance from AAIS, a leading insurance advisory organization and statistical reporting agent, openIDL leverages the trust and integrity inherent in distributed ledger networks. The secure platform guarantees to regulators and other insurance industry participants that data is accurate and complete, implemented by a “P&C Reporting Working Group” within the openIDL network.

“From the very beginning, we recognized the enormous transformative potential for openIDL and distributed ledger technology,” said AAIS CEO Ed Kelly. “We are happy to work with the Linux Foundation to help affect meaningful, positive change for the insurance ecosystem.”

Insurance sectors beyond P&C are expected to be supported by openIDL in the coming months, and use cases will expand beyond regulatory. A “Flood Working Group” has already been assembled to develop use case catastrophe modeling in support of insurers and regulators. openIDL is also collaborating on joint software development activities, building upon Hyperledger Fabric, Hadoop, Node.js, MongoDB and other open technologies to implement a “harmonized data store,” enabling data privacy and accountable operations.

The combined packaging of this software is called an “openIDL Node,” approved and certified by developers working on this project, and every member of the network will be running that software in order to participate in the openIDL network. Additional joint software development for analytics and reporting are also included in the openIDL Linux Foundation network.

“We’re delighted to join openIDL with AAIS and the Linux Foundation. It is strategically important for Selective to be part of industry efforts to innovate our regulatory reporting and use distributed ledgers,” said Michael H. Lanza, executive vice president, general counsel & chief compliance officer of Selective Insurance Group, Inc.

openIDL is a Linux Foundation “Open Governance Network.” These networks comprise nodes run by many different organizations, bound by a shared distributed ledger that provides an industry utility platform for recording transactions and automating business processes. It leverages open source code and community governance for objective transparency and accountability among participants. The network and the node software are built using open source development practices and principles managed by the Linux Foundation in a manner that enterprises can trust.

“AAIS, and the insurance industry in general, are trailblazers in their contribution and collaboration to these technologies,” said Mike Dolan, senior vice president and general manager of Projects at the Linux Foundation. “Open governance networks like openIDL can now accelerate innovation and development of new product and service offerings for insurance providers and their customers. We’re excited to host this work.”

As an open source project, all software source code developed will be licensed under an OSI-approved open source license, and all interface specifications developed will be published under an open specification license. And all technical discussions between participants will take place publicly, further enhancing the ability to expand the network to include other participants. As with an openly accessible network, organizations can develop their own proprietary applications and infrastructure integrations.

Additional Members & Partner Statements

Chainyard

“Chainyard is pleased to join the OpenIDL initiative as an infrastructure member,” said Isaac Kunkel, Chainyard SVP Consulting Services. “Blockchain is a team sport and with the openIDL platform, companies, regulators and vendors are forming an ecosystem to collaborate on common issues for the betterment of the insurance industry. The entire industry will benefit through more accurate data and better decision making.”

KatRisk

“The openIDL platform will serve to increase access to state of the art catastrophe modelling data from KatRisk and others, serving to reduce the friction required to house and run said models. KatRisk expects all parties, from direct insurance entities to regulators, to see an increase in data quality, reliability and ease of access as catastrophe modelling output is effectively streamed across OpenIDL nodes to generate automated reports and add to or create internal business intelligence databases. If catastrophe models are about owning your own risk, then the OpenIDL platform is an effective tool to better understand and manage that risk,” said Brandon Katz, executive vice president, member, KatRisk.

MOBI

“The Mobility Open Blockchain Initiative (MOBI) is delighted to join with the Linux Foundation, AAIS, and insurance industry leaders in founding OpenIDL.  Data sharing and digital collaboration in business ecosystems via industry consortium ledgers like OpenIDL will drive competitive advantage for many years to come,” said Chris Ballinger, founder and CEO, MOBI.

For more information, please visit www.openidl.org

About the Linux Foundation

Founded in 2000, the Linux Foundation is supported by more than 1,000 members and is the world’s leading home for collaboration on open source software, open standards, open data, and open hardware. Linux Foundation’s projects are critical to the world’s infrastructure including Linux, Kubernetes, Node.js, and more. The Linux Foundation’s methodology focuses on leveraging best practices and addressing the needs of contributors, users and solution providers to create sustainable models for open collaboration. For more information, please visit us at linuxfoundation.org.

ABOUT AAIS

Established in 1936, AAIS serves the property casualty insurance industry as the modern, Member-based advisory organization. AAIS delivers custom advisory solutions, including best-in-class forms, rating information and data management capabilities for commercial lines, inland marine, farm & agriculture, commercial auto, personal auto, and homeowners insurers. Its consultative approach, unrivaled customer service and modern technical capabilities underscore a focused commitment to the success of its Members. For more information about AAIS, please visit www.AAISonline.com.

###

The Linux Foundation has registered trademarks and uses trademarks. For a list of trademarks of The Linux Foundation, please see its trademark usage page: www.linuxfoundation.org/trademark-usage. Linux is a registered trademark of Linus Torvalds.

Media Contact
Jennifer Cloer for Linux Foundation
503-867-2304
jennifer@storychangesculture.com

The post Linux Foundation Hosts Collaboration Among World’s Largest Insurance Companies appeared first on Linux Foundation.

By Ashley Davis

*This article was originally published at TheNewStack

Applications built on microservices can be scaled in multiple ways. We can scale them to support development by larger development teams and we can also scale them up for better performance. Our application can then have a higher capacity and can handle a larger workload.

Using microservices gives us granular control over the performance of our application. We can easily measure the performance of our microservices to find the ones that are performing poorly, are overworked, or are overloaded at times of peak demand. Figure 1 shows how we might use the Kubernetes dashboard to understand CPU and memory usage for our microservices.

Figure 1: Viewing CPU and memory usage for microservices in the Kubernetes dashboard

If we were using a monolith, however, we would have limited control over performance. We could vertically scale the monolith, but that’s basically it.

Horizontally scaling a monolith is much more difficult; and we simply can’t independently scale any of the “parts” of a monolith. This isn’t ideal, because it might only be a small part of the monolith that causes the performance problem. Yet, we would have to vertically scale the entire monolith to fix it. Vertically scaling a large monolith can be an expensive proposition.

Instead, with microservices, we have numerous options for scaling. For instance, we can independently fine-tune the performance of small parts of our system to eliminate bottlenecks and achieve the right mix of performance outcomes.

There are also many advanced ways we could tackle performance issues, but in this post, we’ll overview a handful of relatively simple techniques for scaling our microservices using Kubernetes:

1. Vertically scaling the entire cluster
2. Horizontally scaling the entire cluster
3. Horizontally scaling individual microservices
4. Elastically scaling the entire cluster
5. Elastically scaling individual microservices

Scaling often requires risky configuration changes to our cluster. For this reason, you shouldn’t try to make any of these changes directly to a production cluster that your customers or staff are depending on.

Instead, I would suggest that you create a new cluster and use blue-green deployment, or a similar deployment strategy, to buffer your users from risky changes to your infrastructure.

Vertically Scaling the Cluster

As we grow our application, we might come to a point where our cluster generally doesn’t have enough compute, memory or storage to run our application. As we add new microservices (or replicate existing microservices for redundancy), we will eventually max out the nodes in our cluster. (We can monitor this through our cloud vendor or the Kubernetes dashboard.)

At this point, we must increase the total amount of resources available to our cluster. When scaling microservices on a Kubernetes cluster, we can just as easily make use of either vertical or horizontal scaling. Figure 2 shows what vertical scaling looks like for Kubernetes.

Figure 2: Vertically scaling your cluster by increasing the size of the virtual machines (VMs)

We scale up our cluster by increasing the size of the virtual machines (VMs) in the node pool. In this example, we increased the size of three small-sized VMs so that we now have three large-sized VMs. We haven’t changed the number of VMs; we’ve just increased their size — scaling our VMs vertically.

Listing 1 is an extract from Terraform code that provisions a cluster on Azure; we change the vm_size field from Standard_B2ms to Standard_B4ms. This upgrades the size of each VM in our Kubernetes node pool. Instead of two CPUs, we now have four (one for each VM). As part of this change, memory and hard-drive for the VM also increase. If you are deploying to AWS or GCP, you can use this technique to vertically scale, but those cloud platforms offer different options for varying VM sizes.

We still only have a single VM in our cluster, but we have increased our VM’s size. In this example, scaling our cluster is as simple as a code change. This is the power of infrastructure-as-code, the technique where we store our infrastructure configuration as code and make changes to our infrastructure by committing code changes that trigger our continuous delivery (CD) pipeline

Listing 1: Vertically scaling the cluster with Terraform (an extract)

Horizontally Scaling the Cluster

In addition to vertically scaling our cluster, we can also scale it horizontally. Our VMs can remain the same size, but we simply add more VMs.

By adding more VMs to our cluster, we spread the load of our application across more computers. Figure 3 illustrates how we can take our cluster from three VMs up to six. The size of each VM remains the same, but we gain more computing power by having more VMs.

Figure 3: Horizontally scaling your cluster by increasing the number of VMs

Listing 2 shows an extract of Terraform code to add more VMs to our node pool. Back in listing 1, we had node_count set to 1, but here we have changed it to 6. Note that we reverted the vm_size field to the smaller size of Standard_B2ms. In this example, we increase the number of VMs, but not their size; although there is nothing stopping us from increasing both the number and the size of our VMs.

Generally, though, we might prefer horizontal scaling because it is less expensive than vertical scaling. That’s because using many smaller VMs is cheaper than using fewer but bigger and higher-priced VMs.

Listing 2: Horizontal scaling the cluster with Terraform (an extract)

Horizontally Scaling an Individual Microservice

Assuming our cluster is scaled to an adequate size to host all the microservices with good performance, what do we do when individual microservices become overloaded? (This can be monitored in the Kubernetes dashboard.)

Whenever a microservice becomes a performance bottleneck, we can horizontally scale it to distribute its load over multiple instances. This is shown in figure 4.

Figure 4: Horizontally scaling a microservice by replicating it

We are effectively giving more compute, memory and storage to this particular microservice so that it can handle a bigger workload.

Again, we can use code to make this change. We can do this by setting the replicas field in the specification for our Kubernetes deployment or pod as shown in listing 3.

Listing 3: Horizontally scaling a microservice with Terraform (an extract)

Not only can we scale individual microservices for performance, we can also horizontally scale our microservices for redundancy, creating a more fault-tolerant application. By having multiple instances, there are others available to pick up the load whenever any single instance fails. This allows the failed instance of a microservice to restart and begin working again.

Elastic Scaling for the Cluster

Moving into more advanced territory, we can now think about elastic scaling. This is a technique where we automatically and dynamically scale our cluster to meet varying levels of demand.

Whenever a demand is low, Kubernetes can automatically deallocate resources that aren’t needed. During high-demand periods, new resources are allocated to meet the increased workload. This generates substantial cost savings because, at any given moment, we only pay for the resources necessary to handle our application’s workload at that time.

We can use elastic scaling at the cluster level to automatically grow our clusters that are nearing their resource limits. Yet again, when using Terraform, this is just a code change. Listing 4 shows how we can enable the Kubernetes autoscaler and set the minimum and maximum size of our node pool.

Elastic scaling for the cluster works by default, but there are also many ways we can customize it. Search for “auto_scaler_profile” in the Terraform documentation to learn more.

Listing 4: Enabling elastic scaling for the cluster with Terraform (an extract)

Elastic Scaling for an Individual Microservice

We can also enable elastic scaling at the level of an individual microservice.

Listing 5 is a sample of Terraform code that gives microservices a “burstable” capability. The number of replicas for the microservice is expanded and contracted dynamically to meet the varying workload for the microservice (bursts of activity).

The scaling works by default, but can be customized to use other metrics. See the Terraform documentation to learn more. To learn more about pod auto-scaling in Kubernetes, see the Kubernetes docs.

Listing 5: Enabling elastic scaling for a microservice with Terraform

About the Book: Bootstrapping Microservices

You can learn about building applications with microservices with Bootstrapping Microservices.

Bootstrapping Microservices is a practical and project-based guide to building applications with microservices. It will take you all the way from building one single microservice all the way up to running a microservices application in production on Kubernetes, ending up with an automated continuous delivery pipeline and using infrastructure-as-code to push updates into production.

Other Kubernetes Resources

This post is an extract from Bootstrapping Microservices and has been a short overview of the ways we can scale microservices when running them on Kubernetes.

We specify the configuration for our infrastructure using Terraform. Creating and updating our infrastructure through code in this way is known as intrastructure-as-code, as a technique that turns working with infrastructure into a coding task and paved the way for the DevOps revolution.

To learn more about Kubernetes, please see the Kubernetes documentation and the free Introduction to Kubernetes training course.

To learn more about working with Kubernetes using Terraform, please see the Terraform documentation.

The post Scaling Microservices on Kubernetes appeared first on Linux Foundation – Training.