Ocean CD from Beta to Availability: 12 months of valuable customer feedback

As part of the Ocean CD release, we took some time to reflect. Ocean CD beta version was released a year ago with a plan to focus on progressive deployment strategies (Canary and Blue-Green deployments). The curiosity and eagerness Ocean CD created among the Spot by NetApp community helped advance its development and made it clear that our customers need a solution that meets their requirements. These include:

  1. Easy installation as part of the organizational DevOps ecosystem. This was the first lesson learned from the beta release, not only for software deployments but also new products that require gradual deployment.
  2. Controlling the potential blast radius, followed by frequent releases of hundreds of services into multiple environments.
  3. Automating responses based on real-time application behavior.
  4. Helping organizations adopt Ocean CD based on their platform standards to make the product accessible for developers

The immediate conclusion was that while the product provides capabilities that most organizations hadn’t had before and were asking for, the entry point should also support existing release routines that the organization manages. While our initial focus was around the most advanced and requested deployment strategy (Canary), we learned along the way that customers also wanted the “rolling update” capability to support their release strategies. Ocean CD’s newest features support the above requirements and will enable customers to adopt more advanced application deployments if they choose.

 

Meet Ocean CD Advanced Rolling Update

Rolling update is the native Kubernetes method to release changes of application workloads. It replaces all pods with a new one and almost immediately exposes 100% of the traffic to a new code version.

On the other hand, deployment strategies like Canary allow for risk mitigation by gradually introducing the updated version to a subset of users or traffic. This allows users to test and monitor the new release in a real-world environment. Using Canary, organizations can assess the impact of the new release, identify performance regressions or bottlenecks, and make necessary adjustments before wider adoption. This method is considered a best practice when dealing with frequent releases, something quite common in modern architecture and with Kubernetes.

That is why Ocean CD’s first version was all about Canary deployments over Kubernetes clusters, helping organizations not only to adopt it but also easily set it up and maintain it using simple and intuitive SaaS management model across clusters. With Ocean CD Canary implementation, organizations got immediate control over the Canary performance, gaining visibility into metrics, Kubernetes events, and failure policies.

While we have kept developing the Canary strategy, we also understood that a sizable portion of workloads in the user environments are still using the standard rolling update and didn’t necessarily need a Canary process. That includes for things like simple updates, minimal user impact, or time sensitive updates.

But the value-added layers that Ocean CD already developed for the Canary process were highly relevant for a rolling update: continuous verification of the application behavior following the change, controlling the rollout in a way that allows automatic responses in case of a failure, and visibility for developers.

For this reason, the advanced rolling update feature was released. Immediately after generating the new pods, a series of verifications is triggered to make sure the update is completed only if all verifications pass and rolled back in case of a failure. This process is fully automated, fully visible, and controllable. Here is an example of how the Ocean CD rolling update strategy looks:

 

Advanced Rolling Update
Advanced Rolling Update

 

See here a full example with templates

 

Verification templates with Custom Phases: Every user has their own test suite

Ocean CD has already supported verification phases based on Prometheus, Datadog, NewRelic, and CloudWatch metrics. The Custom Phase feature was added with the understanding that every customer has their own tools and methods to evaluate the application behavior. Accordingly, a generic mechanism was added to allow job-based triggers for external test pipelines and a webhook mechanism to get data from external tools.

Here is an example of how ELK (Elasticsearch, Logstash, and Kibana) query outcomes can be integrated to Ocean CD. Note that the query is focused with the pods of the new canary version, using dynamic arguments that are being sent by Ocean CD to ELK during the updated version rollout and injected to the ELK query:

 

Custom Phases Sample
Custom Phases Sample

 

Granular permissions for developers

This one may sound simple, but it is one of the main obstacles for organizations that ask to adopt products that enable a “shift left.”

You cannot allow all teams with permissions to view and act in all clusters and namespaces. Ocean CD is part of the Spot by NetApp powerful role-based access control, which means it already supports Admin/Editor/Viewer permissions. With Ocean CD we take one more step ahead to develop a permission engine at the granularity of Kubernetes cluster, namespace, and workload. As a result, DevOps can provide developers with SaaS control on their relevant workloads across clusters, with no need for comprehensive Kubernetes RBAC permissions.

Policy details
The permissions for cluster, namespace, and workload

 

Notifications

Ocean CD provides a comprehensive user interface for developers (and CLI). It’s also understood that users are not always able to watch a UI or CLI. As such, we have connected Ocean CD to the powerful Spot notification center and created dozens of notification triggers to make sure that the relevant teams are alerted to all the events within their services. These events in Ocean CD can be easily configured for Slack, email, or Webhook notifications that include a summary of each event and link to the detailed console page for in-depth investigation. All the notifications that are being sent are also presented in the Ocean CD notification center, allowing even more peace of mind in Ocean CD’s real-time operations.

Ocean CD dashboards

 

Dashboards and cross-cluster rollout data

The next step was to provide more data about the CD process performances. The metrics that our users were most interested in are ‘DORA’ metrics. DORA metrics refer to a set of key performance indicators (KPIs) developed by the DevOps Research and Assessment (DORA) team. It provides quantitative measurements that can help organizations identify bottlenecks and track their release progress over time.

Ocean CD compiles and displays data related to the rollout process and allows users to easily understand per each managed workload the frequency of successful rollouts, failed rollouts (rolled-back), time to release, and time to roll back when failure happens. With its multi-cluster control, Ocean CD’s ‘DORA’ dashboard can aggregate data based on labels, selected clusters, namespaces, and workloads. By focusing on improving these metrics, organizations can aim for faster and more reliable software delivery.

Rollouts frequency

 

Ocean CD was developed to allow organizations to control changes in production or any other environment, using reliable DevOps automation. With Ocean CD, both developers and DevOps can identify change, manage change, collect data on the impact of change, automate its analysis as part of the change release process, and make better decisions accordingly. Ocean CD is constantly being improved, and its upcoming features are based on Spot by NetApp Kubernetes users’ feedback.

 

Get started with Ocean CD

Start with the Ocean CD Workshop for a quick POC. In just fifteen minutes, you’ll go from Zero to Ocean CD hero with a fully automated progressive deployment strategy and observability.

Sign up for a demo from our experts and a free trial of Ocean CD.