CloudBees sponsored this story, as part of an ongoing series on “Cloud Native DevOps.” Please check back on this site for future posts.
Open source tools continue to serve as the underlying cornerstone of cloud native DevOps patterns and practices — while they also continue to change and evolve.
Cloud native’s origins, of course, trace back to when Amazon and then Microsoft began to offer so-called cloud platforms, allowing organizations to take advantage of massive resources on networks of servers in their data centers worldwide. Heavy hitters Google and Alibaba followed their lead, laying the groundwork for when, more recently, Netflix and Pivotal began to describe so-called cloud native architectures.
Netflix has been very transparent about its reliance on its large suite of open source stacks built for its momentous video sharing service, thanks largely to what the Cloud Native Computing Foundation [CNCF] has made available and Kubernetes and microservices architectures built on cloud native architectures. Additionally, about a decade after it was first introduced as a concept, DevOps has helped to set in motion the team culture fostering the development pipelines and workflows for the industry shift to cloud native deployments.
“Pillars of DevOps practices and cloud native architectures come together around consistency, portability and repeatability. The rise of software defined application infrastructure is also a crucial piece to the equation. As technology continues to evolve, the choice and flexibility of open source projects will continue to provide codification in areas underrepresented before,” Ravi Lachhman, a technical evangelist for application monitoring platform provider AppDynamics, said. “Ever a stalwart of the DevOps world, Jenkins is being steered strongly towards cloud native architecture. The robustness in cloud native architectures seems to push the capabilities and platforms in the DevOps space.”
DevOps’ deployments on cloud native tools and libraries obviously hinge on what DevOps teams think work best for their workflows. But in today’s new stack context, this era of open source and collaboration has created an explosion of possibilities. While arguably this is a good problem to have, making the final cut is not always obvious when selecting the best open source tools to use, not to mention the onerous task of mulling over the cloud vendors’ cloud native platforms on offer.
“Open source, and especially the open source community, are constantly coming up with new tools, approaches and best practices to solve business use cases in the cloud native world. Not a day goes by where we don’t see a new tool, library or framework seeing the light on GitHub that is solving key problems that adopters of cloud native run into as they start rolling out more applications through a DevOps delivery pipeline,” Andreas Grabner, a DevOps activist, for Dynatrace, said. “Thanks to the openness of the community and the willingness to share best practices with others, open source is a core building block of the cloud native movement. The flipside of this, however, is that many organizations are overwhelmed with the constant change in open source offerings.”
It is often hard to decide whether to put energy and time into an open source project “as history has shown that only a few projects actually survive the first hype,” Grabner said. “This is why we see the trend of software companies that contribute back to open source, and with that, give the larger community confidence that these projects are not just pet projects of individuals but that organizations have a vested interested in them to grow and remain,” Grabner said. “While this is great and reduces some of the complexity by narrowing it down to a more manageable amount of open source projects, I’ve seen organizations struggle when trying to manage different open source tools that provide the same functionality for different cloud native platforms.”
The Right Toolkit
A number of open source solutions exist, of course, that help DevOps to mitigate the enormous complexity and difficulty that is often associated with the use of open source tools for cloud native deployments.
In today’s cloud native world, “DevOps means a full stack developer and “shifting everything left,” said Brian Dawson, a DevOps evangelist at CloudBees, which offers a suite of tools for automated software delivery systems and Jenkins. “So, whether it’s cloud-native development or not, it means giving access to ephemeral cloud infrastructure and providing a developer with the tools that they need to test, commit code and go straight to production,” Dawson said. “That fits very well with what we’ve built with Jenkins access, which is an open source project where a developer can easily own the zone as they go from commit to production.”
CloudBees also seeks for the open source community and partners to help extend its platform “a bit like Jenkins has always done,” James Strachan, senior architect at CloudBees, the project lead on Jenkins X, said.
“Jenkins has always integrated lots of things together and made them consumable as a unified thing,” Strachan said. “What we’re trying to do is extend the classic Jenkins plugin model to be more cloud native, so you use more microservices, you use customer resources in Kubernetes and so forth so that anybody can extend the platform in any language.”
Security and Other Roles
Security concerns, of course, are always an issue during the tool selection process. “Open source is both an enabler of and challenge to modern DevOps and to the cloud native application movement. The availability of open source tools, frameworks and services has enabled the industry-wide sharing of best practices, patterns, and educated developers,” Steve Herrod, former chief technology officer of VMware and now managing director at General Catalyst, said. “However, this same ubiquity means that an unpatched security issue is publicly known and exploitable.”
However, almost paradoxically, security risk is a major driver of agile development and of the microservices movement, Herrod said. “Being able to very quickly test and deploy fixes for these known security issues is a huge improvement over the more rigid and traditional development and deployment approaches,” Herrod said.
Legacy open source-powered toolchains such as Chef, Puppet, Ansible and others; Kubernetes and microservices have continued to play a critical role in the open source movement, but the status quo can also quickly change, Navdeep Sidhu, head of product marketing, InfluxData, said. “But while some of these legacy apps are simply being moved to the cloud, a significant number are seeing open source-powered replacements. At InfluxData, we’ve observed this change, as our platform is used for monitoring the newly built cloud apps and also the DevOps toolchains,” Sidhu said. “We are also starting to notice the use of open source-powered workflows to provision, secure, connect, and run any cloud infrastructure for any application.”
But as the open source tools and platforms DevOps rely on for cloud native deployments continue to evolve, they should also continue to serve as the backbone of the workflows from the development cycle to their operation.
“In the entire cloud native app lifecycle, from design through the development process to production support, open source technologies get and [will continue to be] heavily involved,” Kasun Indrasiri, director of integration architecture at WSO2, said.
AppDynamics, Chef, the Cloud Native Computing Foundation, InfluxData, VMware, and WS02 are sponsors of The New Stack.
Feature image via Pixabay.