NetApp’s DevOps Struggles and Lessons Learned
NetApp sponsored this post.
Giving advice is the easiest tactic when wanting to seem like an authority on any subject. However, of course, it’s harder to lead by example. In this vein, for several years, NetApp has adopted its own DevOps methodologies and technologies into its own systems. Led by its internal IT team, NetApp made the declarative effort to adopt a software-defined, cloud-based data center with end-to-end DevOps workflow automation; in other words, it set out to build and run the technology platform to allow software developers to take advantage of DevOps.
But getting there was not always easy.
In this post, we describe NetApp’s path to DevOps and the struggles that come with any organization’s journey to get there.
The path to DevOps, for any organization, includes three major environments: developer tools, platform software and infrastructure-as-a-service (IaaS). The DevOps workflows are automated across all three environments, allowing software developers to push and pull source code, choose application stacks, run CI/CD workflows and rapidly produce business results. Ultimately, developers are expected to create cloud-aware applications, which use microservices architectures running in containers in infrastructure-agnostic designs. In this way, they are cloud-portable between public cloud providers and private cloud, while routing application workloads to whatever cloud infrastructure developers want to use.
The DevOps Maturity model, created by Sumardi Fu, reflects the usual course of action and what organizations typically experience when implementing DevOps. An organization’s degree of commitment to implementing DevOps typically ranges from Level 1, or “ad hoc,” meaning the organization has done nothing other than to say it has decided to embark on a DevOps journey. A Level 5 commitment, similar to what Netflix and Facebook do, involves constant updates with no noticeable downtime. NetApp IT meets Level 3 classification, i.e. an automated DevOps that can create, deploy and support real applications.
And yet, at NetApp, our capabilities, experiences and speeds are still immature. Reaching Level 5 will require a multiyear journey to improve our features, capabilities and human skillsets.
When addressing DevOps implementation challenges here are three invaluable lessons learned from our NetApp IT journey:
- Building a base environment: This has been a year-long effort from initial vision to the first release. It was realized early on that it takes time because of the complexity to get DevOps workflows automated across developer tools, platform software and infrastructure-as-a-service (IaaS).
- Educate app development teams: it’s mission-critical to educate the applicable teams on cloud-aware apps and DevOps. By taking the time to provide an educational focus you foster a trusted working relationship between the infrastructure and business apps teams. This can lead to pipelines of new and existing apps to build or migrate.
- Keeping key engineers focused: building a cloud-aware enterprise with DevOps is a service that will typically take years. Engineers who have participated in the initial build thus need to stay engaged throughout. This operating model uses agile practices and frequent releases to maintain engagement.
As Customer One, it was NetApp’s goal to use its own products, services and reference designs early and frequently. This meant spending a significant amount of time speaking to product teams, giving feedback on features, sharing good/bad implementation results and influencing new roadmaps — thus ensuring a continuous feedback loop to improving NetApp’s customer experience and satisfaction.
In the next phase, NetApp IT intends to implement ONTAP Ansible playbooks for infrastructure automation and the NetApp Trident plug-in for volume creation in OpenShift. The end results for private cloud using various in-house technologies include:
- Hyper-Converged Infrastructure (HCI) to provide compute, memory and (local) storage for containerized application components.
- All-Flash FAS (AFF) for the stateful (NFS, iSCSI) storage platform for databases and high-performance workloads
- StorageGRID is the repository for heavy object storage usage, since cloud-aware apps are inherently stateless and should use a stateless storage mechanism.
These cloud-friendly technologies are tangential to existing install-base products and are particularly important to a cloud journey. Ultimately, all DevOps tools, software and applications created by DevOps workflows need infrastructure. Taking an infrastructure product, simplifying it and making it software-defined has allowed easy plug-in for DevOps environments.
That’s the future of IT — inserting good products into existing DevOps environments through APIs and automation. As NetAppIT tests various DevOps and Private Cloud solutions within its own organization it truly encapsulates the proverbial phrase, “to eat your own dog food.” But it also makes for an authoritative demonstration that if the solutions fail within then they’re not fit for public consumption. So far, it’s been a lot of hard work but an unquestionable achievement.
Feature image from Pixabay.