When introducing our next generation data center (NGDC) platform inside NetApp, we wanted to meet certain minimum viable product (MVP) features including the capability to allow rapid, frequent production change through Continuous Integration, Continuous Deployment (CI/CD). We wanted our developers focused on writing code and rapidly releasing application changes, and not be concerned about other IT services like servers, storage, networks, and more.
With our NGDC platform, we provide automation for frequent small production application changes. Automation helps to reduce the risk associated with large-scale production deployments while adhering to DevOps principles like moving fast and making small changes quickly. With traditional IT there are change control processes that often involve large changes, with some requiring the application to be taken offline. All of this takes time and introduces potential problems for something going wrong. It is not fast.
My favorite feature of the NGDC platform is how the development (DEV), stage (STG), and production (PRD) environments are handled at the application layer. In our traditional data center model, the DEV-STG-PRD environments are dedicated and sit idle until used. With the NGDC platform, these environments dynamically spin up and down as needed at the application layer; the infrastructure and platform reside in the operational production (PRD) environment.
NGDC platform application onboarding
Our NGDC MVP introduction happened a few months ago. The MVP goal was to onboard simple apps onto the NGDC platform to prove out the technology, test the process, and confirm support roles. During application onboarding, we create what we call a DevOps Workspace and DevOps Host Space.
Workspace: Where developers do their work before an application goes live. 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.
Host Space: Where the stage and production application run. Its where continuous delivery releases are ultimately transitioned to. Our goal is to take the work that the developers do in the workspace, and via our CI/CD process, transition the changes to production in the host space.
Putting CI/CD processes to work
Applications are onboarded once. During this onboarding, both the workspace and host space are created so that the CI/CD process can automatically work. Once it’s done, then the development team can use the NGDC platform to rapidly move application changes to production. This is the continuous integration, continuous deployment (CI/CD) process of our NGDC platform.
There are three levels of our NGDC platform for application CI/CD. Our developers do most of their work in the first level (within the workspace) using primarily Microsoft Visual Studio Team Service (VSTS), also known as Azure DevOps. This service provides a full application lifecycle management ecosystem including dashboards, analytics, wiki’s, project and Kanban boards. It is where the developer’s code repository resides for the applications and where they work on source code.
When an application developer submits a code change to the code repository, it kicks off an automated application build. The build combines the application stack, along with the code changes, to create a binary that is deployed within the workspace (non-production). Within about three to four minutes—that’s how long the automation takes—the developer can see their change to the application running in a container and can determine if the change or bug fix worked. If it worked, the Continuous Delivery (CD) process takes the binary that is in the workspace and copies it into the stage environment in the host space. The code change can then be approved for release to production.
Based on role-based authorization in OpenShift and Azure DevOps, the developer, development lead, UAT technician, and even operations, can do the final testing and approvals of small changes. Those involved with the change must be satisfied. Once the final approval is made, then the binary image is moved to production via automation. With OpenShift we can migrate each container one at a time to the new binary image so that the application never goes down. The whole process to implement a change—from the developer working on the code all the way to production—can be less than 15 minutes assuming no delay in approvals.
By adhering to an end-to-end, automated DevOps workflows in NGDC, our developers can spend their time writing code and releasing changes, not having to deal with infrastructure or platform services. The automation provides the ability for frequent, small production application changes to reduce production deployment risk.
I realize it is difficult to fully understand how a development platform works without a demonstration. Please click on this video clip to see how easy it is to fix a bug in a demo application we created called Tiny URL Tool. By automating our release process end-to-end, we can rapidly make a small change to this app without downtime, risk, or duplicated supporting infrastructure.
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.