How At-Bay improved operations with Dapr
Challenge
At-Bay is a fast-growing InsurTech startup that specializes in cyber insurance. Because the process of creating cyber insurance policies is a complicated multi-step process, At-Bay sought to improve operations by using asynchronous message-based communication patterns/facilities.
Solution
At-Bay determined that Dapr fulfilled its desired list of requirements and much more. The Distributed Application Runtime (Dapr) provides APIs that simplify microservice connectivity. From the application development perspective, Dapr is deployed as a sidecar container, supporting various integrations defined as components.
Impact
At-Bay uses Dapr to better reason its processes by offering increased visibility and traceability because of the built-in support of Dapr for the OpenTelemetry standard. This capability allows At-Bay to trace the communication between the partying services with granularity at the message-level and to effectively see the real-time, “big picture” of the running system — solving one of the most significant pain points in many other message-based systems.
Projects used
By the numbers
30% of services
Deployed with Dapr within 6 months
1000s of lines of code saved
For different integration implementations
Drastic increase
In visibility and traceability in message/event level
At-Bay is a fast-growing InsurTech startup that specializes in cyber insurance.
Because the process of creating cyber insurance policies is a complicated multi-step process, At-Bay sought to improve operations by using asynchronous message-based communication patterns/facilities.
Moving from monolith to microservices architecture, as well as from one cloud provider to another (AWS), At-Bay set the following goals:
- Be message broker agnostic, even across cloud providers
- Have minimal difference between local development and cloud-based (Kubernetes) environments
- Adhere to REST APIs throughout the entire microservices tech stack
- Reduce maintainability and preserve agility by eliminating communication-related implementation costs
- Be performant, fault tolerant, robust, scalable, and traceable — all with minimal footprint when consumed
Evaluating several approaches, At-Bay came across the possibility of using a service-mesh solution, but discovered they typically focus on abstracting away networking infrastructure details and not application-level details. At-Bay also considered brewing its own implementation to provide communication abstraction, either to be consumed as a library or as a sidecar.
Sidecar Containers
At-Bay determined that Dapr fulfilled its desired list of requirements and much more. The Distributed Application Runtime (Dapr) provides APIs that simplify microservice connectivity. From the application development perspective, Dapr is deployed as a sidecar container, supporting various integrations defined as components. The components vary in type, such as pub/pub, state and secret-management components, and many more.
Due to their need for asynchronous communication, At-Bay first investigated the possibility to use the pub/sub component fitting our AWS cloud environment. Dapr components are loaded on demand, as defined by the provided user component definition. For example, to use the AWS pub/sub component (AWS SNS/SQS), one has to define mostly just two pieces of information:
- The desired component type; here, “pubsub.snssqs”
- A name for the pub/sub to be used across the system as an alias; here, “atbay-pubsub”
The AWS SNS/SQS Dapr component creates an SNS topic per user defined topic, SQS queue, per subscriber, and SNS-to-SQS subscription connecting both and manages the security policies thereof. At-Bay’s success and ability to adopt Dapr can be attributed to it being an open-source project, which allowed At-Bay to contribute code and influence its components feature development. For example, the default AWS SNS/SQS behavior was to create the AWS resources automatically upon the first call to the component.
While it is very beneficial for local development and proof-of-concept activities, in production environments, At-Bay has its own set of tools, namely Terraform, that manages all infrastructure programmatically in the cloud. One of At-Bay’s contributions to the AWS SNS/SQS component was disabling entity management using the component configuration metadata. Other contributions from At-Bay include using other, more advanced SQS features, such as controlling the pull bulk size, polling interval, usage of FIFO queues, multiple retries with exponential backoffs, custom AWS related communication retries and backoffs, and more advanced usage of the AWS SDK within the component.
At-Bay promoted the component maturity to meet expectations along with contributing back to the strong and supportive community of Dapr.
The impact of Dapr
As a cyber insurance provider that handles complex business flows, At-Bay must be able to execute those flows asynchronously. To classify the business type of an insurance applicant, for example, At-Bay performs an in-depth analysis of its online assets. This multi-step process has many working units that communicate with each other using messaging. These messages use Dapr as their core abstraction over the communication infrastructure.
At-Bay uses Dapr to better reason its processes by offering increased visibility and traceability because of the built-in support of Dapr for the OpenTelemetry standard. This capability allows At-Bay to trace the communication between the partying services with granularity at the message-level and to effectively see the real-time, “big picture” of the running system — solving one of the most significant pain points in many other message-based systems.
Dapr bridges the gap between local development and cloud deployment for At-Bay. Developers previously needed to spin up a database on a local development machine just to be compatible with the database that runs over the cloud infrastructure, which required resource specifications and configuration variations. Dapr has solved this problem through its component system abstractions, which allow developers to consume a resource by specifying the resource name and providing a resource definition that varies between the environments. Dapr allows At-Bay to use Redis for all state management activities in its local environment, while switching to using another database for the cloud deployment, without having to change a single line of code.
When working on AWS, there are alternatives for local development that give a certain amount of API compatibility, however, many times their API compatibility is only partial, their enforcement of certain security features is limited, and still the developer must implement the connectivity to the local AWS APIs differently than to the real cloud environment API. On the other hand, Dapr abstracts away those fine API details and assures that the communication patterns used locally are intact and stable when moving to other environments.
Dapr is a scalable and flexible solution that fits At-Bay’s new and existing use cases for managing microservices interactions and communication. This can be attributed to Dapr adoption of component-based architecture and being a successful open-source project with an active community that welcomes contribution and feedback.