Make DevOps Even More Effective by Building a DevOps Platform

Many IT organizations are implementing DevOps practices to realize the benefits that companies like Google, Microsoft, Facebook and others have been experiencing for years. They want to deliver features faster, improve the stability of applications, and move from a reactive delivery organization to one of innovation.  No doubt these are great benefits, yet you cannot reach the full potential of DevOps if you only focus on getting the practice going.

I find that many organizations have DevOps practices split across multiple teams with each one having their own tools, applications, and processes. While each team is effective within its own microcosm, you risk losing productivity when developers move among teams or cross-team collaboration is needed. Development is interrupted as new team members adjust to specific tools, applications, and processes. It’s also not uncommon for developers to build their own tools and applications, as well as maintain them, which means they are not developing.

Our approach

To address these pitfalls and reduce interruptions as developers move between projects, we built a standardized DevOps platform with a finite set of developer tools, platform software, and infrastructure. The platform automatically provides the elements that often distract developers while offering consistency across projects. Overly simple right? Well, yes and no.  Since we recently started our DevOps practice, we had a greenfield opportunity to build a DevOps platform and influence the DevOps practices.

We set our own practices, process, and tools which would meet the needs of our current DevOps maturity. The hard part is delivering a single platform that can serve different development teams, especially with the plethora of available tools and technologies. As you know, there is no one single tool or technology that provides a full DevOps solution; it’s a variety of tools and approaches integrated together.

The first release of our DevOps platform, called CloudOne, happened in November of 2018.  CloudOne provides the cloud services, automation, and CI/CD release models that our application development teams need to build cloud native applications. As shown in Figure 1, we have four guiding principles and benefits.

As a service

It is important that the platform be viewed and implemented as a service. This means it is defined by a solid value proposition for your developers, driven by their requirements, and continually enhanced and improved. As a cloud agnostic service, CloudOne can deploy environments both on premises and off prem. In the current release of CloudOne:

• We offer a service catalog of application stacks including Angular.js, Envoy, and OpenResty, with more to come.
• It automatically updates the Configuration Management Database (CMDB) with what is being developed.
• Builds out the baseline structure in Azure DevOps for the application development.
• Builds and destroys development and test infrastructure as it needed.
• Integrates security checks for what is being developed.

Most of this was previously done manually by the different developments teams but is now handled by the platform.  We have several future releases already on the roadmap so we can continue to improve the developer experience.

Developer productivity

One of our primary goals of CloudOne is to ensure developers have the tools and automation needed to do their jobs. We want them focused on application development, not managing tools and infrastructure.  Yet, we recognize that most developers have their favorites tools like Azure DevOps, Atlassian, or Team City. The problem with “favs” is NetApp ends up with many different DevOps tools being used across multiple development teams. It results in lost efficiency and productivity as developers move from team to team, learn different tools, and spend time managing the development platform instead of developing. To promote developer productivity and achieve economies of scale, we have standardized on a set of tools which can be used across all teams.  Our CloudOne platform automatically builds out an environment that is based on service catalog selections for tools, which includes programming language options.   

Built-in security

Building security into the development process is a challenge as it involves an “interruption” in the developer’s workflow and is often viewed as a productivity hit. We are addressing these concerns in an upcoming release of the CloudOne platform by injecting security checks into the developer’s workflow.  For example, after a developer submits code, security software runs against that code to see if there are any bad practices which may lead to a vulnerability.  If so, it will generate a bug against the code for the developer to address. In the final stage of the workflow, when the production binary is generated, additional security software is run against the binary to see if there are any vulnerabilities. Again, generating a bug if something suspicious is found.   

Private or public cloud

With CloudOne we adopted a container strategy from the very beginning. As a cloud agnostic solution, we use containers to deploy application components at any location. In a future release of the CloudOne platform, we will enable portable capability to move applications to any location or deploy across multiple cloud instances simultaneously.   

Summary

As a total package that provides control, standardization, and cloud agnostic capability, CloudOne is an end-to-end solution as a service.  It is a single environment for managing the entire DevOps lifecycle and helps our teams deploy quality code faster.

The NetApp-on-NetApp blogs feature advice from subject matter experts from NetApp IT who share their real experiences using NetApp’s industry-leading data management solutions to support business goals. Visit www.NetAppIT.com to learn more.