How Helvetia accelerates cloud-native modernization by 90% with MongoDB Atlas

INTRODUCTION

The path to cloud-native modernization

Founded in 1858, Helvetia is one of the largest Swiss insurance companies, serving over 7 million personal and corporate customers across Europe.

With its "Helvetia 20.25" strategy, the company aims to be the best partner for financial security and to set new standards for customer convenience and access. One aspect of achieving this goal is a multi-year transformation of its IT systems. Central to the transformation is unlocking multiple data silos constrained within core backend systems and federating them across cloud-native microservices running on Amazon Web Services (AWS). The Helvetia Container Platform provides the foundation for the company’s developers to build engaging new customer experiences while improving business agility and time to market.

The company chose MongoDB Atlas with unified database and application search to underpin the company’s Container Platform. Today, MongoDB Atlas powers over 30 different services with many more in development.

During its transformation journey, Helvetia migrated from Amazon DocumentDB to MongoDB Atlas, and is replacing Elasticsearch with MongoDB Atlas Search. The result: new application features are released 90%+ faster.

THEIR CHALLENGE

Technology limitations and application complexity

The Helvetia Container Platform is built around an event-driven architecture with Apache Kafka streaming all data changes to and from the core backend business systems. As shown in Figure 1, each development team creates its own data product that is exposed by APIs to consuming front-end services. By following a data mesh design pattern, each team is responsible for its own data products, governing and sharing them with new services that need to work across previously siloed customer and policy data.

One of the Container Platform’s key services provides the Helvetia sales teams with fast and reliable access to customer data. The service needs to deliver a single, 360-degree real time view across all customer touchpoints and insurance products. This includes policy details, quotations, account history, and customer service information, all exposed to users via fast and reliable full-text search.

From the outset of the project, it was clear to Helvetia’s solution architects that a document database would be a better technology choice than a traditional relational database.

As Hevetia’s Container Platform was running on AWS, the first version of the sales application was built on DocumentDB – Amazon’s emulation of the MongoDB document database. To provide application search, Elasticsearch was bolted on DocumentDB. However the Helvetia engineers found that DocumentDB lacked many of MongoDB’s sophisticated query and aggregation capabilities needed to support advanced application functionality. It also struggled with the scalability requirements of the application.

To address their database problems, the team decided to migrate from DocumentDB to MongoDB. However the integration with Elasticsearch was still complex and costly, requiring the database and search engine to be synchronized by a separate Kafka cluster.

While Elasticsearch was well regarded by the Helvetia team, its complex integration with the database was slowing down speed of innovation. It was failing to provide the most recent customer data, impacting user experience and customer satisfaction. By bolting Elasticsearch on to their MongoDB Atlas database, the Helvetia team had to grapple with:

1. Managing separate data synchronization pipelines. As shown in Figure 2, messages from the Kafka Streams topic were consumed by two separate targets – the MongoDB Atlas Database and Elasticsearch index. Whenever the application’s schema changed, Elasticsearch indexes had to be remapped. Any sync failures meant Elasticsearch had to be reindexed to restore consistency with customer and policy details stored in the database, during which time search queries would return only partial results sets.
2. Working with multiple query languages and drivers to query the database and search indexes, slowing developers down.
3. DevOps overhead in managing and monitoring three separate systems. It could take hours to diagnose and remediate application issues.

OUR SOLUTION

Migrating to MongoDB Atlas 

Migrating from DocumentDB to MongoDB Atlas was straightforward. With a proof-of-concept and testing complete, the Helvetia engineers simply restored the DocumentDB backups to Atlas. As DocumentDB uses the MongoDB drivers, there were no application changes, other than being able to exploit all of the latest MongoDB database features that had not been available to them in the DocumentDB emulation. Because MongoDB Atlas is tightly integrated with the AWS platform, the Helvetia team did not need to compromise on any of the existing Amazon services they use.

With the migration complete, the Helvetia solution architects took the opportunity to further streamline and simplify their technology estate by moving from Elasticsearch to Atlas Search. Because Atlas Search is built on the same underlying Apache Lucene library as Elasticsearch, key capabilities such as autocomplete, multi-language support with analyzers, along with fast counts and sorting across result sets would preserve core application functionality.

To start the migration, the Helvetia engineers first reviewed the Elasticsearch index definitions, and mapped them to Atlas Search. With a couple of API calls, the configured index was deployed within MongoDB Atlas, and data was automatically synchronized between the database and search index. After re-coding their queries to use the familiar MongoDB Query API, the Helvetia team was able to verify the performance and reliability of search results.

Note: If you want to learn more about how to move to Atlas Search, download the 5-step guide to migrating from Elasticsearch.

As a result of the migration from Elasticsearch, Helvetia’s developers are now more productive as they work with the single MongoDB Java driver across both database and search operations. This integrated experience eliminates them having to context switch between different query languages as they code, and removes unnecessary build dependencies.

THE RESULTS

Accelerating release cycles from days to hours

This deep integration between the MongoDB Atlas database and Atlas Search enables Helvetia developers to dramatically compress their release cycles. Rolling out new features typically demands the search engine reindex data. Doing that in Elasticsearch was a complex process. Engineers had to update the transformation logic and Kafka sync mechanism. To avoid search downtime, they had to create index aliases in application code that pointed to the existing indexes while the new index was built. Once the build was complete, the application code had to be repointed to the new index.

A key Atlas Search capability is no-downtime index modifications. Applications can continue to read and write to the database and search index while the index is being rebuilt. Once Atlas Search rebuilds the index, the old index is replaced in the background without any further action from engineers.

As the next step along its digital transformation journey, the Helvetia team will be exposing its sales application directly to customers via the company’s self-service portal. By replatforming to MongoDB Atlas, Helvetia now has the scalable, flexible foundation needed to continue delighting its customers.

If you are interested in working with the latest cloud-native technologies, the Helvetia team would love to hear from you! Take a look at the open positions on the Helvetia careers site.

NEXT STEPS

If you want to dig deeper into Atlas Search, spin it up at no-cost on the Atlas free tier. You can follow along with reference materials and tutorials in the Atlas Search documentation using our sample data sets, or load your own data for experimentation within your own development sandbox.