Ignition Group speeds development and payment processing using Dapr and Azure

The challenge of distributed systems

Founded in 2002, Ignition Group is one of Africa's largest providers of technology, media, telecommunications, and financial services. Two years ago, the company made a significant investment in Azure cloud computing to expand its global reach. Today, Ignition Group serves businesses across Africa, Europe, and the United States with end-to-end B2B2C services—everything from sales to fulfillment to payment. The company built its own order processing software to track products, manage subscriptions, and handle payments from a variety of sources.

“Over the years, we built in-house solutions to do what we do,” explains Russell Stather, Chief Digital Transformation Officer at Ignition Group. “We ended up with a mishmash of systems that took a long time to deploy and a long time to make changes to.” In addition, the development team was spending more time than it wanted to maintain and update the infrastructure.

Ignition Group wanted a more flexible way to make changes to its solution. The order processing software was originally developed using .NET Framework and Windows Workflow Foundation. The engineering team also chose to move to .NET Core to speed up the development of microservices and deploy them to Azure Kubernetes Service.

“We knew we wanted to use microservices and were looking for the right toolset,” says Stather.

Dapr paves the way for microservices development

Order processing involves many dependencies. A purchase starts a tracking mechanism that invokes a customer subscription, triggers accounting and billing processes, and determines the appropriate payment channel. Ignition Group wanted the benefits that microservices would bring to its workflow logic—high availability, resiliency, scalability, and performance. Microservices are also straightforward to test, maintain, and replace when requirements change.

The answer turned up where so many answers do—in an internet search. The team found Dapr, which has an active, growing community. Dapr was created to solve the complexity associated with building resilient stateless and stateful microservices that run in the cloud and on the edge. Ignition Group became one of the first Dapr adopters and is now a community contributor.

“We looked at Dapr and thought, this is exactly what we need,” Stather adds. “We started building stuff straightaway. It was very easy to work with. We could get services speaking to each other, and so it was really exciting for us to take it on board.”

Dapr provides building blocks that ease the challenges inherent in cloud-native development. A building block provides an HTTP or gRPC API for capabilities that help developers build microservice applications based on industry best practices. By making a call to the Dapr API, developers can decouple their application code from state management, resource bindings, pub/sub messaging, and other common distributed system challenges. But what really caught the attention of Ignition Group was the built-in service discovery and invocation building block.

For the APIs, Dapr uses a sidecar architecture, which runs next to an application. The Dapr control plane integrates with Kubernetes and provides service-to-service encryption, identity, and other capabilities. It also launches the Dapr sidecar inside each Kubernetes pod. The sidecar architecture encourages each application to communicate to its own instance of Dapr, and the Dapr instances discover and communicate with one another for calls between services or to publish and subscribe to messages.

The team deployed this approach in a new order processing solution on Azure called Marketic, which solved an immediate problem. When a new product is added to Marketic, the workflow requires a custom activation. Before Dapr, the developers had to write new code for this activation and then re-release the entire system without knowing for certain which existing services might be affected. In the new order processing solution, the microservices are deployed as Dapr applications and perform direct service-to-service invocation. When the developers add a new service, it’s automatically discovered by other services in the order processing workflow.

Marketic architecture on Azure

Ignition Group automates solution deployments using continuous integration and continuous deployment (CI/CD) tools. To add a feature to the Marketic platform, the developers can create, build, and deploy another microservice in as little as a day—considerably faster than they previously could. They write code in C#, host the microservices in Docker containers, store the images in Azure Container Registry, and run them in Azure Kubernetes Service clusters. To date, the Marketic platform includes more than 100 microservices and continues to grow rapidly.

We didn't want to invest in a lot of Kubernetes experience, so using AKS was an obvious choice,” Stather notes. “We run all our Dapr services in AKS, so we can concentrate on the business logic.”

His team wanted the advantages of platform as a service (PaaS). Azure services handle the complexity of infrastructure management and free the developers to create, run, and manage apps. As a compute platform, AKS offers managed Kubernetes, a CI/CD experience, and enterprise-grade security and governance. It also provides autoscaling features that easily handle the burst workloads during Marketic billing periods and the anticipated scale as Ignition Group expands into more markets.

An API gateway sits between the microservices and the client applications that make use of the Marketic platform. Ignition Group uses Azure API Management to expose publicly accessed services to the outside world. API Management makes it easy to see how the APIs are being used and how they’re performing.

Dapr APIs provide an easy way for developers to build distributed applications. Dapr offers bindings that specify how to connect to an external resource, such as a queue, database, or any system that an application needs to integrate with. The component approach of Dapr makes it very flexible to adapt an application over time or to change a technology decision without having to rewrite code.

Stather notes that the team uses bindings a lot. “It saves us so much time.” For example, while building Marketic, the team realized that it was using a relational database, SQL Server, to store documents. It switched to MongoDB instead. “All we did was build a new microservice and deploy it with the same ID as the one that spoke to SQL Server, so nothing else notices that we changed the backing store,” he adds.

The team also uses the Dapr secrets API to simplify secrets management. In the local development environment, the secrets API uses Kubernetes secrets, but when deployed into production, it uses Azure Key Vault for more secure secret management. For developers, it’s just one call in the code—by simply changing configuration options, they can change the underlying secrets store.

Custom tooling automates Dapr development

Ignition Group invested the time to build tooling that streamlines the development process. “One of the first things we did was build a Visual Studio plug-in that allows you to generate a Dapr microservice just by clicking a button,” Stather notes. The tools proved so useful that the team published them in Visual Studio Marketplace for others to use.

An early success was a workflow engine for the business rules based on Windows Workflow Foundation. The tool models the workflow using the Dapr actor programming model. Actors encapsulate code and state and are ideal for building workflow applications. A different actor type is used for each of the real-world entities involved in the workflow, such as orders, customers, and invoices. For example, an actor maps a product’s order ID to the workflow instance that processes an order and then stores the state in Azure Cache for Redis.

Dapr actors provide a level of abstraction that suits the long-running workflows required by the order processing application. An order workflow might last for three months, but it’s not running in memory all that time. If it’s inactive for a certain period of time, it deactivates and persists its state. But when the order processing solution needs to update the order again, the actor activates into memory, thereby making economical and efficient use of the cluster resources.

The extra work to develop tools on top of Dapr paid off. “By putting our own workflow tooling on top of Windows Workflow Foundation, we enabled our business users to make significant changes themselves—in a controlled fashion—to all our business processes without having to put everything in a dev queue,” says Stather. Now the developers can focus on the core microservices code and continue to build value quickly, while the end users focus on business processes.

Next step: Scaling up and out

In Dapr, Ignition Group found the right solution to fast-track its development processes using simple APIs that make it easy to build distributed applications. Internal users can now use the self-service tools to streamline change requests, and customers benefit from a faster end-to-end order processing and payment platform.

Stather credits Dapr for giving Ignition Group the opportunity to solve some nagging business problems. But the investment in Dapr really paid off when the developers realized they could resell their internal payment processing solution to other enterprises through Azure Marketplace and Microsoft AppSource. The company plans to replicate the Marketic platform in new Azure regions and anticipates increasing throughput by a factor of 100 or even 1,000.

“It's only because Dapr and AKS are so scalable that we can do that,” notes Stather. “You just stick a few more nodes into the cluster.”