Enterprises anticipate IT ops benefits from GitOps
Infrastructure as code, configuration as code, security as code -- enterprise SREs set their sights on everything as code in pursuit of GitOps efficiency.
Enterprise DevOps shops look to take the next step in fully automated IT infrastructure with a GitOps approach, which will enhance efficiency for IT ops and SRE teams.
GitOps relies on version-controlled code repositories, typically housed in Git or GitHub, for everything from application to configuration to infrastructure management. GitOps limits DevOps engineers' access to production, as well as manual infrastructure maintenance tasks, in favor of automated machine-controlled processes to deploy and update applications and infrastructure configurations.
"You want to automate your operations, not operate your automation," said Josh Koenig, head of product at Pantheon Platform, a web operations platform in San Francisco that hosts more than 200,000 Drupal and WordPress sites.
Pantheon uses a set of DevOps tools, including CircleCI's CI/CD software, HashiCorp's Atlas and Terraform infrastructure-as-code software, to automate application deployments and infrastructure provisioning in Google Kubernetes Engine (GKE) clusters.
"We still have some direct access to production, but we fully embrace automation and eliminate shell access to servers whenever possible," Koenig said.
Pantheon's Kubernetes infrastructure, which runs up to a million containers in production at a time, is too large for site reliability engineers, or SREs, to manage manually. DevSecOps proponents also advocate the GitOps approach for the security benefits of limited access to production infrastructure, but the major benefit for Pantheon so far has been IT ops efficiency.
To that end, while DIY infrastructure and configuration as code scripts can be lengthy and cumbersome, fresh abstractions have evolved, such as CircleCI's Orbs, that standardize and systematize application build processes as code. Orbs reduce what might be hundreds of lines of scripts into one line per application resource. More than 700 Orbs are maintained and updated by the open source community, software vendors and cloud service providers, such as AWS, GKE, Azure, VMware, Red Hat and Kublr.
Josh Koenig
"Orbs give our developers 'one-liners' that sets up application resources in the most efficient way," Koenig said.
The owners of those resources regularly update these Orbs, which is a better alternative to copy and paste boilerplate configuration code from documentation that might be obsolete in six months, he said. "That makes configuration as code an order of magnitude more human-readable, especially for new developers."
Still, it's difficult to develop a single systematized set of GitOps tools and codebases in an environment with some customized infrastructure and legacy systems, and GitOps is still a work in progress at Pantheon.
"There's a lot of blur between what tools can handle versus what they're actually really good at," Koenig said. "It's a jigsaw puzzle."
Mercedes R&D embraces infrastructure as code
Few enterprises would call themselves GitOps masters, but those who have put as-code tools into production, such as Mercedes-Benz Research and Development, say that's the ultimate goal.
Like Pantheon, Mercedes R&D teams in Sunnyvale, Calif. and Seattle use a variety of infrastructure-as-code tools to deploy applications and manage infrastructure updates, including Terraform and a newcomer called Pulumi, which offers common programming language interfaces such as JavaScript and Python for its tool, as opposed to the more commonplace YAML files.
Mercedes R&D also works with a sprawling infrastructure that contains hundreds of microservices owned by various teams around the world. Each microservice must be scalable and allow other teams to understand and contribute to infrastructure and application code.
"If you want to provision a database, for example, Python and JavaScript may be easier to let a programmer understand what's going on, manage and maintain it than YAML and other infrastructure-as-code tools," said Dinesh Ramamurthy, engineering manager for Mercedes R&D.
Mercedes R&D doesn't mandate infrastructure-as-code tools, and it hasn't used Pulumi in production yet, Ramamurthy said. However, the company has used the tool to spin up infrastructure blueprints for application tests that can be destroyed and re-created quickly.
"Our application development, configuration as code, and infrastructure automation workflows are git-pull-requests-driven, and we are using technologies that are declarative by nature, like Kubernetes," he said. "Our goal is to have robust, observable, automated processes, with feedback and control loops that enable our developers to deploy or roll back changes."
GitOps mindset spreads, but remains cutting-edge
Our goal is to have robust, observable, automated processes, with feedback and control loops that enable our developers to deploy or roll back changes.
Dinesh RamamurthyEngineering manager, Mercedes-Benz Research and Development
Meanwhile, most enterprises struggle to modernize legacy applications that don't lend themselves as easily to modern methods such as GitOps.
"GitOps has legs, but in the enterprise, security, governance and legacy app migration are more at the top of the list where people want to spend budgets," said Jim Mercer, analyst at IDC.
IT management software companies such as Chef seek to bridge the gap between legacy apps and GitOps with as-code tools adapted to legacy applications. Three years ago, Chef shipped Habitat, an application packaging mechanism analogous to the CircleCI Orbs approach, but focused on application deployment to production infrastructure, rather than test builds.
This week, Chef rolled out its first integrations between Habitat and the rest of its product line, including Habitat patterns for its Infra and Inspec software, and dashboard integration for Habitat in its Chef Automate centralized orchestration management tool. It also introduced a migration accelerator pattern that uses Habitat encapsulation to move legacy workloads on Windows Server 8 and Red Hat Enterprise Linux 4 operating systems to public cloud.
As a declarative version-controlled approach to application configuration as code, Habitat fits the GitOps mindset, but has yet to see widespread production deployment. However, this week, Chef also expanded configuration and infrastructure-as-code options for its more popular Infra configuration management product, with support for cookbook code storage in GitHub repos. Previously, Chef Infra kept such code only in Chef Server.
GitOps purists might not count Chef Infra as a GitOps tool, per se, because it uses an imperative approach, rather than a declarative approach, to configuration and infrastructure as code. But the focus on as-code tools is a sign of the market's shift toward GitOps nonetheless, Mercer said.
"Chef is clearly trying to adapt to the market -- it can't just offer configuration management the way it did umpteen years ago," he said. "Clearly, enterprises want all of their automation in source-control systems, usually Git. Customers are surely asking about it."
Dig Deeper on Systems automation and orchestration
Josh Koenig
