Adobe gets control plus flexibility in its development platform from the Azure Service Operator project

The challenge of unleashing innovation

Adobe Document Cloud provides popular PDF and electronic signature solutions using the software as a service (SaaS) model. To make software development a productive and enjoyable experience, Adobe switched to cloud-native practices a few years ago. The shift from monolithic architectures to microservices decouples applications from many hard-coded dependencies, making them easier to update and maintain, in addition to being faster to scale and produce. Even small teams can compose targeted services quickly in response to customer requests and can scale their efforts globally. Cloud-native practices and microservices free individuals to choose the programming language and development tools, provision cloud resources on demand, and deploy changes—without the bottlenecks that can arise during linear processes and structured handoffs.

“The power of the DevOps model is that it allows people to do things for themselves,” observes Colin Murphy, Adobe Document Cloud Engineering Manager. “But the microservices model began to break down for us in Document Cloud.”

Document Cloud includes the Adobe Acrobat family of products, a common standard for reliably viewing, printing, signing, and commenting on PDF documents, in addition to Adobe Sign, a cloud-based e-signature service. Used everywhere—across institutions, industries, and businesses—Document Cloud must meet the highest security and compliance standards, including the Health Insurance Portability and Accountability Act (HIPAA) and the Federal Risk and Authorization Management Program (FedRAMP).

“We can’t separate the model of how a service is provisioned, deployed, and operated from compliance and security,” Murphy explains. “We had this challenge of hundreds of engineers making services and too few people to help them do it correctly. We don't want hundreds of services that don't look anything alike, or everyone solving the same problem over and over again. But that was happening.”

A move to microservices with governance

Adobe Sign is a case in point. Its original monolithic architecture became too unwieldy to safely develop and maintain. A few years ago, the development team began a transition to a microservices architecture, starting with a single service. This canary release allowed the team to introduce a new version of the service and to test it with a small set of users before gradually increasing traffic. The rollout went well, encouraging the team to embrace the microservices model. Today, all Sign features are built partially or entirely as microservices.

At first, the team used Open Service Broker for Azure to help handle integrations with security and governance services. No longer maintained, Open Service Broker provided a multicloud API and service catalog with a command-line interface. Document Cloud developers used it to connect their applications running in Kubernetes to other Azure services. But during a chance conversation at KubeCon 2019, Murphy found a better solution.

“I was at the Microsoft booth and said, ‘Hey, I’m using your service catalog.’ And they told me they had something new—Azure Service Operator.”

At the time, the Azure Service Operator project was under development as an open-source effort supported by the AKS engineering team. Its goal: to expose Azure services as Kubernetes operators. Developers can self-provision infrastructure and include service operators in their pipelines, enabling them to run their applications anywhere Kubernetes runs―across public, private, hybrid, or multiple clouds and on-premises.

Adobe signed on to collaborate with Microsoft and test the Azure Service Operator code with Document Cloud. The companies have worked closely for years. In fact, Microsoft and Adobe recently expanded their partnership to help meet their customers’ needs during the shift to hybrid work.

“Access to the Azure team is why we’ve been so successful with Azure Service Operator,” Murphy says. “I’ve been really happy to work with Azure, and the people I met at Microsoft have been really great.” He even posted about the experience on his LinkedIn page, noting, “We've made Azure Service Operator a major piece of the Document Cloud developer experience.”

A multicloud Kubernetes architecture

The Adobe Sign architecture demonstrates the Document Cloud team’s approach to microservices development. Adobe Sign features core services, integrations with external systems, and web components. The primary product functionality is composed of stateful services that maintain and operate life cycle functionality on specific data domains, along with some stateless services.

Another set of microservices handles the integrations between Adobe Sign and external systems, such as SharePoint Online or digital signature providers. These services interact with Adobe Sign through public REST APIs. Some store data, such as authentication tokens or other information needed to maintain cross-system connections.

Even the HTML, CSS, and JavaScript web components follow the larger principles of microservices development—they’re loosely coupled components that are delivered continuously.

Requests to microservices are routed through an Adobe gateway, which handles basic authentication, authorization, logging, and filtering. Microservices run on AKS, a fully managed Kubernetes service. To provision any additional Azure resources needed by these service containers, developers create custom resources—in effect, extending the Kubernetes API. They can then use the custom resource definitions (CRDs) built into Azure Service Operator to connect their applications to these resources. In this way, developers can manage the required Azure resources using native Kubernetes tooling and a familiar declarative model, right from within their Kubernetes environment.

Adobe Sign uses a variety of managed services. For example, some microservices store state information in Azure Cache for Redis. Some use Azure Cosmos DB, a fully managed NoSQL database with fast global access and throughput. Others use Azure Database for MySQL, a fully managed database powered by the MySQL Community Edition.

Developers have choices, as Murphy points out. “Azure Service Operator allows Document Cloud to provide a scalable developer experience. We can offer sensible defaults without restricting developer options and can retain control in a centralized manner without stifling creativity.”

This approach gives the Document Cloud team a template for flexibility with governance. As Murphy explains, “With Azure Service Operator, our infrastructure team can decide how to set up resources that meet our security and compliance requirements. But it also gives the engineering teams the ability to decide what their databases should look like.”

Service operators also help make development easier, he notes. “Modern services aren't a standalone business unit of business logic. They usually need backing stores. Azure Service Operator definitely makes it easier to talk about, diagram, and manage resources.”

The ‘Hey, don’t worry about it’ of features

Adobe was one of a handful of companies that worked with Microsoft on the Azure Service Operator project. Adobe’s feedback and multicloud insights helped Microsoft identify and address key requirements for real-life global deployments.

“The engineers at Microsoft have been incredibly responsive and accommodating,” Murphy states. “Microsoft resolved numerous issues with very quick turnaround—one time in under 24 hours. They’ve also welcomed our contributions to the project.”

For example, Document Cloud needed the equivalent of a “don’t touch” functionality that would kick in when an operator is moved to a different cluster. Developers needed to make sure that already-deployed resources would not be affected in Azure.

“We needed a way to say, ‘Hey, don't worry about it, don’t try to reconcile it,’” Murphy says. After explaining the situation to Microsoft, the skipReconcile annotation was added. It prevents changes from being propagated to Azure.

A necessity of scalability

Incorporating the Azure Service Operator capabilities into its microservices architectures on Kubernetes helped Adobe move past limiting workflows of the past. “I think the big story is that this evolution came out of a necessity of scalability,” Murphy points out. “Azure Service Operator helps us encapsulate changes and best practices into our existing deployment systems, and it makes it very easy.”

The experience of the Document Cloud team reflects the reality of enterprise development, where security and governance go hand in hand with innovation and microservices. Service operators have become a kind of gatekeeper for Document Cloud’s strict compliance regime. Developers continue to choose the data stores and other Azure resources they need and, as Murphy puts it, “They can go about their business—without the need for a central ITOps or DevOps team telling them how to do it or putting their request in a queue that’s one hundred miles long.”

Learn more about the Azure Service Operator project on GitHub.