A new generation of IT automation tools targets platform engineers


Platform engineers also need abstractions.

These teams of IT operations specialists — increasingly the norm among enterprises delivering microservices applications to cloud-native infrastructure — create self-service interfaces that hide the complexity of DevOps platforms from application developers. But as they shoulder the burden of this complexity themselves, platform engineers are also turning to new IT automation tools that can lighten the load.

According to a presentation by Anusha Ragunathan, Principal Software Engineer at Intuit, at the recent KubeCon + CloudNativeCon North America Conference.

“We talk a lot about developer velocity, but using a [self-service] The abstraction layer also allows the platform team to move much faster,” Ragunathan said during the presentation. “They don’t have to worry about spending time making sure developers are managing Kubernetes correctly or deploying [something like] a new service mesh when they need to expose developers directly to it.”

We talk a lot about developer velocity, but using a [self-service] The abstraction layer also allows the platform team to move much faster.

Anusha RagunathanSenior Software Engineer, Intuit

A Danish bank’s platform engineering team found that the open-source Backstage tool they use to build a self-service interface for developers also eases IT governance burden with built-in tracking ownership of services.

“We were recently tasked by our auditors to do software classification and asset management, and we have that in Backstage,” Kasper Nissen, principal platform architect at Lunar, said in an interview with KubeCon. “From the auditor’s perspective, we categorized everything as ‘this property is defined in Backstage as this team in this area, with this criticality attached to it. “”

Pulumi targets platform engineers

As those discussions continued after KubeCon, infrastructure-as-code specialist Pulumi this week rolled out a new technology preview deployment API SaaS offering, targeting platform engineers with GitOps in as a service.

The Deployment API is based on Pulumi’s Automation API, a REST API interface for vendor infrastructure-as-code libraries written in popular programming languages ​​such as Python and Java. With the Deployment API, Pulumi’s managed service is triggered by pushing code to GitHub repositories, automatically creating and previewing Kubernetes-based back-end infrastructure stacks and cloud infrastructure-as-a-service resources on AWS and Microsoft Azure.

“It’s kind of like GitHub Actions, but for the infrastructure,” said Joe Duffy, founder and CEO of Pulumi, in an interview this week.

Platform engineers and developers can also use GitHub Actions itself to create similar workflows, but Pulumi’s Deployment API replaces manual configuration for this type of process, Duffy said.

“You need to put together a few dozen lines of YAML, you need to go give GitHub your cloud credentials – it takes a bit of setup for a very clear common workflow,” he said. With the Deployment API Service, “you don’t need to recreate the wheel on things that are pretty standard setups.”

Deployment API can be triggered via CLI or REST API calls for other code repositories, and Git-push-to-deploy support is planned for Azure DevOps, GitLab and Bitbucket. Pulumi also integrates with a dozen CI/CD pipeline tools, including CircleCI and Jenkins.

An engineer whose SRE team uses Pulumi’s automation API said he had to wait for this deployment feature to be integrated for Azure DevOps to take full advantage of the new deployment API, but the concept is appealing .

“This could allow us to scale better by offloading the actual execution of deployment code, as we pay for parallel work for Azure DevOps,” said Dan Swartz, principal software engineer at Altana AI, a deployment automation company. supply chain in New York, in an interview this week. “There is also [another scenario] when we just want to update config settings or Pulumi YAML files… that’s where it’s going to knock it out of the park, because [right now] we don’t have that kind of nice and clean workflow [for that]where you commit the code and then it launches a preview for you.”

Pulumi emerged with HashiCorp’s infrastructure-as-code Terraform tool in its competitive views, adding a general programming language interface on infrastructure-as-code tools, rather than requiring developers to learn YAML or a domain-specific language such as HashiCorp’s HCL. Now, according to an analyst, the deployment API is equivalent to a foil for another HashiCorp product, the Waypoint deployment automation service launched in public beta on the HashiCorp cloud platform in early October.

“They both have the same ambition to abstract the real infrastructure components from the developer and allow the operator to build the models and automate the process,” said Torsten Volk, analyst at Enterprise Management Associates, in an interview this week. But rather than using YAML or HCL, “the key with Pulumi is that developers can just have it in their IDE, create a pull request and that gets merged, and the automation and deployment API s ‘take care of everything else’.

Kubernetes management tools integrate with cloud-native platforms

KubeCon’s platform engineers also shared how they improved IT automation using open-source utilities built around Kubernetes, the core IT infrastructure layer that underpins most platforms. DevOps forms. This year, several presenters and attendees made reference to Crossplane, a Cloud Native Computing Foundation (CNCF) project that uses the Kubernetes API to orchestrate resources outside of Kubernetes clusters.

Lunar’s Nissen said its platform engineering team is studying Crossplane, but also plans to use the Cluster API to standardize cross-cloud Kubernetes deployments.

“Managed Kubernetes is really annoying to run on three different clouds because they want their own version of the Kubernetes cluster in each cloud,” he said. “We really want to have a way to line up jobs just to minimize operational load… [to have] a description or specification that says, “This is how we want our clusters, with these core components, and it’s the same across all clouds.”

A small team of three full-time and one part-time platform engineers who serve 45 developers at Kognic, a Swedish SaaS provider, used another CNCF project, cert-manager, to eliminate recurring manual cycles of updates. update of SSL certificates and continuous restarts of the Kubernetes cluster. , according to a KubeCon presentation.

“Every time we renew our certificates…every 60 days…we had to first use a shell script to create the new certificate…and then manually edit the secret in Kubernetes to contain the new certificate,” said said Jessica Andersson, product area manager for engineering enablement at Kognic, during the presentation. “That’s great, except Kubernetes deployments don’t pick up the changed secret unless they’re redeployed, so we had to restart all deployments. That was a pain.”

Cert-manager eliminated this entire process, Andersson said.

As platform engineering and a focus on developer experience has begun to take hold for the Kubernetes generation, some early adopters of PaaS see history repeating itself and hope it can catch up soon past platforming moves.

“We previously had the Open Service Broker API framework [with Cloud Foundry], and now we have things like Crossplane moving towards accepted frameworks and standards that plug into the Kubernetes ecosystem,” Greg Otto, executive director of cloud services at cable company Comcast, said in an interview with KubeCon. “But it has to be more than just trendy bingo. … For us, all of our decision-making is based on, ‘How does the benefit of this increase developer experience and business results?’ I will trade complexity for simplicity for my platform team, but only if it comes with great reward and ROI for the developer experience.”

Beth Pariseau, Senior Writer at TechTarget, is an award-winning veteran of IT journalism. She can be reached at [email protected] or on Twitter @PariseauTT.

Source link


Comments are closed.