Breaking Down DevOps
So, what is DevOps anyway? DevOps stands for Development and Operations, two of the cornerstones of tech enterprises. From this point on, I’ll refer to the teams as Dev & Ops, respectively. I’d now like to take a moment to talk about where the term originated and how it solves a major problem for tech companies in the modern age. At the end of this blog, I’ll also discuss how Adobe uses DevOps as its business model for Creative Cloud. Without any further delay, let’s get into it!!
In the beginning, tech companies employed a monolithic structure. They provided solutions to their customers in a very sequential standard going from point A to point B, in which the two teams I mentioned earlier, Dev & Ops worked. In addition to this, the company culture was in a silo. Many departments were isolated from each other and only focused on their tasks, making it hard to go back and add changes. If anything went wrong, it would be sent back up through the hierarchy and take the same amount of time to come back down.
Take a look at the diagram below to see what this looks like.
The image above shows that adequate testing wasn’t in place on applications at the right times in the pipeline, which itself lead to staggering security issues. It would be akin to trying to build a cardboard box without making sure that the item you want to insert can be supported (if at all). Applying this example to monolithic architectures, the cardboard problem wouldn’t be caught until later down the line after it has gone through a few channels first. To further compound the issue, teams back then would often blame and bicker with each other when things went wrong. These issues dramatically slow down the development of applications and decimate workflow. While this approach worked fine for companies for quite a while it eventually reached a point where this model simply became unsustainable as applications continued to increase in functionality and size. The solution? DevOps.
DevOps solves all of these issues by putting teams into environments where they are in balance with each other through every step of the development cycle. The DevOps model changes the culture, the practices, and utilization of applications. The approach looks different across corporations. Some firms maintain both Dev & Ops teams or coalesce them into a single team. Regardless the DevOps cycle changes the linear structure to one that is more durable and flexible. It looks like this:
This image explains the eight phases of the DevOps cycle: Plan, Create/Code, Verify, Package, Release, Configure, Monitor, and then Plan again when needed. It runs in a continuous loop, so this doesn’t necessarily mean that you are done when you reach the end. You repeat and mix the process.
With this new model, teams can automate practices that previously bottlenecked the product’s lifecycle. Utilizing a toolchain affords enterprises the opportunity to quickly scale and develop applications at a faster rate. It also gives engineers the tools they need without requiring manual input from other team members. Furthermore, using continuous integration (CI) and continuous delivery (CD) practices, enterprises can quickly develop, monitor, deploy, correct, and redeploy applications to meet the ever-changing needs of their consumers around the world with minimal error and downtime. As you can see, DevOps is more than just a list of tools, but a mindset that breaks barriers between teams and inspires creativity. (Note: When you throw security into this structure, this is called DevSecOps, with Sec being security).
How Adobe Uses DevOps
Adobe once operated in a monolithic point-to-point system, not unlike most enterprises, and they didn’t focus on server utilization until around 2012 when they wanted to expand their desktop applications (CSuite). Since then, over the past decade, however, Adobe has acquired many different companies, such as Magento in 2019. To manage their new integrations, Adobe heavily relies on DevOps, mainly microservices, security, and CI/CD automation under their Adobe Experience Platform. The goal of this platform was to enhance their security and automation by breaking down barriers they experienced through siloed teams and reducing deployment time.
The pipeline is shown here:
The Adobe Experience Platform is the central hub of their cloud solutions and, in a nutshell, collects and responds to an extensive amount of end-user data every second in real-time. In other words, it helps businesses focus on their marketing, analytics, and advertising and uses a combination of data centers from around the world to accomplish this. The platform itself is a messaging bus that connects many of their internal solutions (such as Adobe Acrobat Document Cloud) and affords their customers (including enterprises) breadth of knowledge about end users, which they can leverage for their business. Adobe runs a software as a service (SaaS) business model and uses Kubernetes clusters to manage and run their containers (internal applications).
The following is an image taken from Adobe’s website and provides a general overview of the pipeline:
Adobe’s pipeline is great for enterprises because consumers don’t follow a linear buying path. With all the options such as e-commerce, websites, and stores, there is no longer a global standard to evaluate user experiences. Many businesses choose suites like Adobe Experience Cloud because the suite includes many solutions for diverse customer experiences. One industry heavily taking advantage of this is the auto industry. Top brands like Mercedes-Benz, Helly Hanson, and Pfizer use the suite. Adobe knows that to help businesses, Enterprises need to understand more about how consumers operate on multiple channels and respond almost instantaneously. Acquiring multiple frameworks and putting them into a custom interconnected network puts Adobe in the best possible position to meet this need.
If you liked this article, follow me for more content. Feel free to post in the comments as well. Until next time.