ZEISS accelerates cloud-first development on Azure and streamlines order processing

A more agile solution for a digital age

The ZEISS Group is an internationally leading technology enterprise operating in the fields of semiconductor manufacturing technology, industrial quality and research, medical technology, and consumer markets. Since it was founded in 1846, ZEISS has continued to advance the world of optics and to shape technological progress.

However, the consumer business needed a more agile order management and processing system. “ZEISS always makes a great effort to deliver on time, and we wanted a solution that empowers us to consider all the multiple decision points in our business, reaching from globally distributed production capabilities to transport constraints in our supply chain,” explains Marvin Zielke, ZEISS Head of Business Information Technologies.

The main challenge was a 20-year-old back-end system with hard-coded business rules. “The original order validation and routing solution was based on a monolithic architecture with fixed capacities,” notes Kai Walter, a lead architect at ZEISS Group. Developers couldn’t easily update, reroute, or track orders without reconfiguring tables directly in the system. In addition, business units had no direct control over their order processing flow. With so many system dependencies, changes always required costly, time-consuming developer intervention.

In an earlier project, the team used APIs to decouple front-end interfaces from back-end systems. This time, however, the team also wanted to go global and distribute the order processing environment across multiple Azure datacenters to provide faster service to customers around the world.

The Dapr approach to coding a distributed solution

The team at ZEISS knew it wanted the flexibility of a microservices-based architecture. This style of software architecture composes applications using small, independent modules that communicate with each other through well-defined API contracts. Microservices also suit the small development teams at ZEISS, enabling them to test, deploy, and scale services independently.

However, that flexibility comes at a cost. Developers face the complexity of building distributed applications with a microservices architecture. They want to focus on business logic, while leaning on the runtimes and hosting platforms to give their applications scale, resiliency, maintainability, elasticity, and the other attributes of microservice architectures.

The ZEISS team found a solution for rapidly building its new order processing system using Dapr. This event-driven runtime helps enterprise developers build resilient and portable microservice applications. ZEISS was an early adopter of Dapr. As an open-source project, Dapr has a large and rapidly growing community—including the ZEISS developers—that contributes code, components, and tools.

Dapr solves the distributed system challenges facing developers when building microservices applications. It does this by codifying the best practices into open, independent, building blocks—APIs that enable developers to build portable applications with the language and framework of their choice. For example, using the secrets building block, developers can easily access secrets from Azure Key Vault or other secrets stores, not only reducing their development time but also making code portable across cloud and edge environments. 

Dapr exposes its APIs as a sidecar architecture, either as a container or as a process, using HTTP or gRPC. These sidecars separate the application logic from Dapr APIs, making it easy to adopt from any developer framework and improving supportability. By injecting each containerized microservice in a workflow with a Dapr sidecar, ZEISS developers can use the Dapr APIs to manage state and secrets, secure calls between services, and send events in a consistent way—without having to write the code to do it.

In addition, with no additional work, they get essential information for diagnosing issues in production. Using the Dapr APIs, ZEISS gets detailed tracing, metrics, and logging information from its applications to send to Azure Application Insights.

A global and regional event-driven workflow

The architecture of the Order Processing application distributes the workload across Azure datacenters. The ingress point for incoming orders is Azure Front Door, a scalable and secure entry point for global web applications. Azure Front Door routes a request to the nearest region, and each region includes the Azure resources needed to process and store data specific to that locale. An order submitted from a customer in Spain, for example, can be sent to the nearest Azure region in Europe. ZEISS plans to run in at least six regions, representing three continents. In the event of unexpected errors, an order is automatically routed to another region.

Azure Front Door passes the order to Azure Application Gateway, a web traffic load balancer that is mounted on an Azure API Management endpoint. API Management serves as the gateway to the regional resources, giving ZEISS a single place for efficiently managing its APIs hosted on-premises and on Azure. Next, API Management triggers Azure Service Bus, a message broker, to pick up the incoming orders. Order details are stored in Azure Blob Storage, and the order processing logic runs in containers orchestrated by Azure Kubernetes Service.

This is where Dapr steps in. Dapr is launched as a sidecar container in the same pod as the service container, and the containers can talk to one another. To deploy the Order Processing application (shown in the following diagram) and run it in the Kubernetes cluster, ZEISS simply added a few annotations to the Dapr deployment schemes. The company runs three nodes across the development, testing, and staging environments and five nodes in production. With AKS automating operational and maintenance tasks, such as provisioning, scaling, and monitoring of compute resources, the ZEISS developers save significant time. AKS also provides multilayered security—an advantage in the locked-down ZEISS environment.

Dapr sidecars make it significantly more efficient to build a microservices-based application and to run it in a Kubernetes cluster. For example, a Dapr sidecar can be configured by a microservice to publish and subscribe to messages on behalf of the application. In this case, a Dapr binding to Service Bus picks up the order and sends it to the specified microservices for processing. A developer writing the code doesn’t have to know and learn all the details of a specific technology to publish and subscribe to messages, making the code portable and faster to develop.

“With Dapr, you can be agnostic about the use of platform services,” Walter points out. “That made it easy to ramp up, because we did not have to dive into all the services, the service orchestrator, or service discovery.” This flexibility enables the ZEISS developers to swap out alternative services to support multiple cloud and on-premises environments. “Without having to change one line of code, we can still use the same state and use the same business code,” Walter says.

A closer look at microservices and Dapr sidecars

The Order Processing application orchestrates eight other microservices that make decisions about supply chain logistics, such as where to route an order and whether it is valid. To manage the life cycle of an order, ZEISS used Dapr virtual actors. An actor is an isolated unit of compute and state with single-threaded execution. Actors are ideal for creating workflow, IoT, and other applications that have independent compute units.

For example, the GlobalOrderID service generates a unique order number, and the Status service reports an order’s current status to attached subsystems. ZEISS created GlobalOrderID and Status as Dapr virtual actors. The actor state is stored globally in Azure Cosmos DB, a fast, multi-model database. If an order in one region encounters an issue, it can be processed in another Azure region, giving ZEISS greater business continuity. Other global resources include Azure Key Vault for storing keys, passwords, and secrets, along with Azure SQL Database for storing regional configuration data.

“With the combination of Azure Cosmos DB and Dapr actors, we can have this continuous order number,” says Walter. “Using actors, we can recover the order workflow at any time from any region, which makes the application simple to develop and resilient to failures.”

To make the application resilient across regions, global and regional deployments are connected using the Azure Private Endpoint interface. A private endpoint uses a private IP address from the ZEISS virtual network to shield Azure services from access or attack via the internet. These private endpoints connect microservices to global resources.

Next steps

The launch of the new order processing platform has given ZEISS the scalable and resilient architecture it needed. Using AKS in combination with Dapr helped ZEISS to develop services and get them to market faster. ZEISS customers benefit from faster order fulfillment and timely notifications of progress—something the existing system couldn’t do. The new solution is also completely configurable. The business can easily make updates when its customers or supply chains change and can roll these out in hours instead of days.

“Dapr made it much faster for us to build an app on Azure Kubernetes Service,” notes Walter. “The development team could focus on the business logic instead of spending cycles on the common configuration elements.”