How One Engineer Spearheaded the Development of a Single DevOps Platform – InApps 2022

DevOps software developers and operations staff are now being asked to work collaboratively on projects from start to finish. The problem with onboarding applications manually is an issue of human speed and bandwidth. It is also a misuse of time that could be used for developing new features or correcting bugs.

Efforts to use microservices architectures running in containers using cloud for rapid software creation and change are, thankfully, replacing traditional silos and governance methods. This trend certainly holds true at NetApp where, as a senior manager developer within NetApp ITI, I have applied my experience to making the shift as best as I could.

Over the past two years, I have been part of a NetApp IT initiative to build a DevOps platform that provides cloud services, automation, and CI/CD release models for application development teams that need to build cloud native applications. The impetus for this started as an internal testbed to, as is eloquently spoken in the office, “to eat our own dog food.” That is, using NetApp technologies and tools to create a platform they would be proud to recommend to customers. Additionally, this type of service platform needs to automate application deployment in the cloud to stay market competitive. Without that link to the cloud, the platform cuts its usability and convenience factors.

The new platform for which I led the development efforts was called CloudOne. It provides one consistent developer experience, irrespective of the destination being a private or public cloud. This frees up valuable headspace on the part of the developer to not worry about storage limitations, how data will flow or fetching when needed. It’s no different than reinforcing a residential home foundation with steel beams; the house will stand without them but it creates a better sense of reliability.

My team also automated the processes to onboard applications onto the CloudOne platform as well as the continuous integration and continuous deployment (CI/CD) processes to rapidly move application changes to production.

The onboarding process starts when a development team accesses the self-service catalog to identify the type of application being onboarded and to make selections around the type of application stack and environment sizing requirements of their application. This begins an automated workflow that updates the CMDB — the single source of truth — so that any assets that get created during the onboarding process aren’t lost.

Using APIs, the team then hands off to Red Hat CloudForms, which invokes an Ansible automation. Ansible Tower performs four key routines:

1. Creates the repository for all the binaries with jFrog Artifactory, the place where all stored binaries get created during the application CI/CD process. It is during this step that the Docker registry, as well as third-party registry and Helm registry, are established for the application. Helm is used to manage Kubernetes applications.
2. Creates the access groups using email distributions lists (through Active Directory) to do role-based authorizations for OpenShift and Azure DevOps. It is important that we have clearly defined roles embedded in the process so that changes are not made in production without proper notification and approval. It serves as an embedded checks-and-balances based on preassigned responsibilities and accountabilities.
3. Configures the Red Hat OpenShift environment, which creates and manages the containers.  It manages the quotas, assigns roles and groups and integrates with Artifactory.
4. Configures Azure DevOps Project to create the developer environment including everything from code repositories to code branching to the CI/CD process itself that gets created for the application.

It takes about 30 minutes to onboard an application through this automated process, which creates the Workspace, Hostspace, and if needed, a Dataspace.

Workspace: Where developers do their work before an application goes live. This is the non-production environment. For example, developers can create code branches, develop the code, create pull requests and trigger continuous integration builds. It’s where they can test out new features, fix bugs or try out new capabilities using our standards-based technology product catalog.

Hostspace: Where the stage and production application run, and where the continuous delivery releases will ultimately culminate. The goal is to take the work that the developers do in the workspace, and via CI/CD process, transition the changes to stage and production host space.

Dataspace: Representing Database as a Service (DBaaS), this provides the productivity, performance and data security needed for databases.

Upon completion of this onboarding process, both the workspace and host space(s) are created so that the CI/CD process can happen automatically. Once completed, the development team can use CloudOne to rapidly move application changes to production. The end result reflects the inherent power of a well-orchestrated continuous integration, continuous deployment (CI/CD) platform with public and private cloud connectivity.

InApps is a wholly owned subsidiary of Insight Partners, an investor in the following companies mentioned in this article: Docker.

Feature image via Pixabay.