Adobe Achieves a Boring Network with Cilium for Cloud Native Platforms

Adobe is a company which needs no introduction. Their software for all creatives has been a mainstay in the technology industry since 1982. They’ve continued to create, deliver and optimize content and applications for their customers, leading and defining an entire industry over those decades. Using Isovalent Enterprise for Cilium to power their cloud native platforms across cloud providers gives them a “boring” consistent network layer; learn why “boring is good”!

Adobe is a pioneer in modernisation and adept at embracing technological changes, making it well-equipped to execute a Cloud Native strategy that drives its business goals. Adobe has been a long-time Cilium user as part of their cloud native infrastructure, migrating originally from Calico and, more recently, taking the step to enterprise support and software working in partnership with Isovalent. 

This write-up of Adobe’s Cloud Native platforms powered by Cilium is based on the CiliumCon presentation, “From Imagination to Implementation: Inside Adobe’s Production-Grade Deployment with Cilium” from Joseph Sandoval and Tony Gosselin. 

The Ethos of a New Platform To Smash the Silos

Innovation is a key factor in Adobe’s achieving its targets, leading them to tackle the rise of cloud native technology head-on.

By 2016, several teams within Adobe were already tackling cloud native; some teams were just trying to run containers and pivot to better-constructed pipelines to improve their application development experience, and other teams were starting to consume several clusters for their needs. Ultimately, this approach was not working, with each team working on its own to achieve the same outcome over and over. 

By 2017, a new infrastructure team was created to centralize the design, configuration and management of the new cloud native technologies and platforms. The individual teams no longer had to spend development cycles focusing on infrastructure and could return to focusing their efforts on developing software. The new platform was named Ethos, originally based on Mesos and heavily opinionated; it was later replaced by Kubernetes with the desire to offer more choices to its consumers in terms of features and functionality. Consumers of the platform ranged in experience, from running single containers as part of pipelines to the teams who had already tackled running their own clusters built with dedicated pipelines and metric tooling. 

Not only did the Infrastructure team have to contend with the varying levels of experience of their platform consumers, but also the varying workloads that would need to be hosted on these platforms;

• Single and Multi-tenant deployments
• “Legacy” applications that had been through “lift + shift” projects were essentially still the same old application wrapped in a cloud native bubble.
• Untrusted workloads – these are generated by Adobe’s Experience Manager offering, which allows customers to run applications on Adobe’s infrastructure
• Pipelines, Metrics and Stateful workloads
• Machine Learning and Generative AI

Cilium was chosen to power the underlying network connectivity and security to address all these needs. 

Pushing a lot of Packets Across a lot of Clouds

At the time of the presentation, Adobe had 23,000 Kubernetes nodes in its environment. Cilium was chosen because it held up to all of the performance, various workload types and end-user experience testing that the infrastructure team could subject it to. The turning point that solidified Cilium as the right choice was the shipping of a project named Firefly, which pushed the platforms to their limits. 

What makes an Ethos Cluster? It has to be Kubernetes and Cilium, without Cilium a lot of how we present and secure our infrastructure doesn’t work

Joseph Sandoval, Platform Engineering, Adobe

One of the goals of the Ethos platform is to offer their end users options. They can run in whatever cloud or location they want, whether it be AWS, Azure, Private Data Center, or using Enterprise Kubernetes offerings such as Red Hat OpenShift. The infrastructure team standardized Cilium for any cloud provider or infrastructure they consume, which is the constant component of their global infrastructure. The reason is simple, as quoted “When we chose Cilium as the CNI and the provided insight to the network, that visibility is necessary for us as platform operators”. They also found Cilium to be simple to consume, with the necessary abilities to be extensible as they grew their platform capabilities. Now in production, the developers have access to Cilium to create their own network policies. 

Hot Take – Cilium is Boring, and Boring is Good

The platform engineering teams at Adobe have been burnt in the past, deploying technologies that just didn’t quite offer everything needed to run at scale, in production, and for mission-critical applications. 

“Cilium is boring”, “But boring is good”, both Tony and Joseph round off laughing. Boring means that Cilium was easy to configure, debug, consume, and ultimately see how it works. “It’s important when you choose a CNI; it offers great visibility and is stable”, Joseph points out. When they refer to Cilium as boring, it’s a mark of respect. 

“Without the network, nothing works, so it’s important to invest and continue to use (a technology)” Joseph explains that once Cilium was the chosen solution, they decided to go all in, leading to this consistent component in their global infrastructure across all the cloud and on-premises platforms you can think of. 

Developers have access to Cilium; no, it’s not crazy, they love it!

The Adobe infrastructure team has continued the theme of innovation regarding the level of access they provide to their platform users by giving developers access to Cilium and the platform’s underlying network infrastructure. 

Originally, Adobe started out to solve the issue where development teams were taking on cloud native platform deployments in silos. Now, with a consistent approach to offer platform choice managed by a centralized team, platform users find via the internal developer platform Flex, built around Helm and ArgoCD, they have templates available to create and manage their own Cilium Network Policies without having to open tickets with other teams. This allows the platform users and developers to control their applications’ layer 3 and layer 7 services. For the more experienced teams, “We don’t want to be the gatekeepers of the platform’s capabilities” Joseph says, explaining the move to allow users access to the APIs of the platform and to deploy their own Cilium Network Policies without using templates. Of course, this isn’t carte blanche access to all the platforms; Open Policy Agent and Gatekeeper are deployed to ensure a level of control and that users don’t accidentally break things or misconfigure specific security configurations. 

Exploiting the Platform Further with Isovalent

After some time using Cilium and the success of the Ethos platform, Adobe partnered with Isovalent to take advantage of the enterprise software offerings. The user experience had been vastly improved overall with the new Ethos offerings, and allowing users to consume platform features directly led the Adobe team to push the innovation further by working with Isovalent, the creators of Cilium. 

With Isovalent, Adobe is further evolving its developer experience. Future tasks will revolve around addressing the Supply Chain models within the platform offerings. Capabilities such as mutual authentication and zero-trust implementation are part of future planning. Below Joseph talks Isovalent through how eBPF supervision with Hubble is helping Adobe “see inside the wire.”

When working with Isovalent, customers access the hardened Cilium offerings, including enterprise features such as Multicast, Multi-Network, High Availability Egress Gateway, and DNS Proxy. Not just product offerings but also Isovalent Customer Success programs, including 24/7 follow the sun Enterprise support for both Cilium and Tetragon, Solution Architects to help design and improve their cloud native platforms, proactive support environment reviews, exclusive technical training for Cilium and Hubble, and replica customer testing environments, an environment maintained by Isovalent which mirrors customers environment configuration for testing and validation. 

Learn more

Are you currently enhancing your cloud native platforms for your developers? Want to provide your developers more control over their workloads? Benefit from platform features such as layer 7 network policies, observability, and high-performance networking for mission-critical workloads; reach out to our Isovalent team to plan out how Cilium can address these challenges. 

Looking to get hands-on with Isovalent Enterprise for Cilium and learn how to operate at scale? Try out our free hands-on labs. Are you looking for a more structured approach to learning Cilium? Find a learning path to suit you!