Breaking Free From Legacy DevOps Platforms – How Ozone Outperforms the Competition

In this article, we will examine how different DevOps platforms can limit organizations from achieving optimal efficiency, speed, and quality in their software delivery processes.

After evaluating several software delivery platforms for various scenarios, we will highlight a few critical shortcomings that can impede teams in ways they may not be aware of. Rather than comparing ancillary products, we will focus on the core CI/CD capabilities of our competitors’ and comparable tools to ensure a fair comparison.

Through this evaluation, we will determine whether these platforms are genuinely “modern” enough to enable the deployment of complex, contemporary microservice applications.

The comparison is broadly classified into these four critical issues that plague most or sometimes even all of these “CI/CD” or “software delivery platforms”: 

1. Lack of standardization and reusability
2. Unsatisfactory user experience and a high learning curve
3. Complicated deployment of parallel microservices with release management
4. Runners that hinder the scaling of the CI/CD pipelines

Let us now substantiate by diving deeper into each of these issues and have a look at how Ozone aims at tackling them:

1. Lack of standardization and reusability

The core problem of most of these platforms stems from the fact that they tie a git repository to a pipeline definition. This implies that for every git repository you create, it will have its own independent pipeline.

While that solved the problem years ago, today’s needs are different. The world of microservices implies that a complex feature might have 10s-100s of microservices that interact with each other, which means that you will end up with 10-100s of pipelines that are managed independently of each other; be it by a central team or by the developers themselves.

This problem is further complicated because teams usually work with a handful of stacks to reduce development complexity. But this increases the number of pipelines and negatively impacts pipeline management and reusability, thus affecting governance.  In case of a git repo, teams may choose to run a full scale CI/CD pipeline on the master branch, but limited pipelines for local testing by developers for their preview branches. 

For e.g.:

As a use case, imagine a security/DAST/SAST/QA policy that needs to be introduced/modified across a particular tech stack like Go. In other software delivery platforms, to do this, you will need to modify the policy across all microservices, resulting in a scaling order  proportional to the number of microservices you have as part of your tech architecture.

Solution:

Since ozone pipelines are first class citizens and not linked to an application repository, you may choose to run different pipelines for different branches through our GitOps integrations. A typical use case is for when a developer needs to purely run unit test cases and functional test cases as they develop, but once a merge to the master branch is requested, they would also run additional security scans. Ozone gives you the flexibility for just the right amount of parallel testing at every stage. 

In addition, Ozone’s pipeline templates allow you to write a CI/CD standard for a particular framework instead of per repository. A single template that can be reused across the organization improving pipeline management and introduces standardization of CI/CD that can scale seamlessly.

Write once and reuse it on-demand. Modify and enforce across the application stack. 

2. Unsatisfactory user experience and a high learning curve

Most of these delivery platforms are built around the fact that since developers code, they can configure pipelines that look like code as well. While this is still true, we must ask ourselves whether it is worth it. 

The answer is no; because with the adoption of the shift-left movement, where developers maintain and manage all that it takes to get their code to production, it is all the more a need to make their lives simpler and improve the Developer experience so they can focus on the core set of business problems that add value to customers.

For eg:

Let’s continue where we left off, i.e., someone has to modify a pipeline or create a new one to enforce a deployment standard. All the DevOps platforms more or less offer the following workflow with little changes across each of them:

• Use some kind of template that is pure-code (YAML)
• Copy-paste tasks from an upstream git repo
• Mentally visualize parallel execution, if any
• Map results downstream through code (i.e., by volume access)
• Repeat it for every single use-case that you find or copy-paste from another CI/CD YAML file that is mapped to some other git repo.

This kind of developer experience only leaves room for error and a lot of pointing fingers leading to no productive output and possible loss of talent  as the product and CI/CD processes scale.

There’s also a break in the user flow on some of these platforms as developers need to navigate from one current window to another to select or copy-paste steps and add them into the pipeline. 

Solution:

Not only are Ozone’s pipelines templated, but we also supply an upstream catalog that you can modify in a low-code fashion using a canvas-based editor – The Ozone Pipeline Studio. Results are mapped visually without the need to understand where the results are stored on the infrastructure.

The templates become a part of your organization’s internal catalog, thus baking in CI/CD processes that can be reused and modified seamlessly in the future.

Developers should not be coding pipelines. The Ozone Pipeline Studio eliminates coding, saves time, and helps teams focus on the product and business outcomes. 

3. Complicated deployment of parallel microservices with release management

Most feature introductions, changes, or fixes made in modern applications require a train of microservices to go live together. These microservices are interdependent, and the condition for a successful release implies that all of them have been pushed to production without compromising quality.

For eg:

Now, imagine a scenario where there are three microservices: A, B, and C. The order of dependency is as follows:

C → B → A.

This implies that first, A is pushed to production successfully, post which B is pushed, followed by C. Here are a few problems with legacy platforms for this scenario:

• Has to be handled manually for each microservice 
• A few popular platforms need to chain it manually through parent-child pipelines that trigger at the same time.

This is dangerous as parent-child pipelines have no inter-dependency of results. So assume that A fails, but B and C go through. This will result in a broken feature release that will need to be rolled back

• Harness: Another pipeline needs to be put in as a stage. This violates the principle of dependency injection and inversion of control. this is complicated as a pipeline exists as a sub-stage and violates the idea of templating. 

Solution:

A chain of microservice releases can be set up for complex scenarios using Ozone with relevant approvals in place. You can use the same pipeline templates as long as the stack is constant and the compliance requirements are the same. You may also inherit the results from a prior deployment. So in case microservice A fails, the whole release fails, thus minimizing the risk of deployments.

Link/chain and deploy your microservice train across any Kubernetes cluster with Ozone’s Release Management. 

4. Runners that hinder the scaling of the CI/CD pipelines 

The common thread that all the other software delivery platforms share is the fact that every single one of them is based on a runner concept that executes the pipeline workflows within the runner’s pod. As a result, this places a bottleneck at the runner level, thus limiting the number of pipelines that can be run in parallel. 

For eg:

Considering that you may have 10-1000s of microservices, this is less than ideal. You will need a team to monitor the performance of runners and scale them up and down as per need. Alternatively, you may choose to run at the highest possible configuration and choose to de-optimize costs.

Solution:

Ozone’s pipelines themselves run as a container. As long as you set your cluster to auto-scaling, so will Ozone’s pipelines.

SREs should maintain your product’s SLA, not that of your CI/CD solution’s. 

These critical issues tend to affect teams and handicap them in ways that they aren’t aware of. Hence, it affects aspects in the long run, such as:

• Support for modern development practices and tools as they evolve
• Automation and self-service capabilities for faster and more reliable deployments
• Greater flexibility and scalability for changing business needs
• Improved collaboration and communication across teams
• Real-time monitoring and analytics for proactive issue resolution

This reference article is intended to analyze only the CI/CD component of all the platforms, and not any ancillary solutions.

For instance, Ozone offers federated monitoring outside of CI/CD, while some platforms promote solutions like cloud cost management and feature flags.

This apples-to-apples comparison is restricted to the usability and CI/CD workflow available on all the major DevOps/Software Delivery Platforms in the market today.