 |
VOOZH | about |
|
VOOZH | about |
We’re so glad you’re here. You can expect all the best TNS content to arrive Monday through Friday to keep you on top of the news and at the top of your game.
Check your inbox for a confirmation email where you can adjust your preferences and even join additional groups.
Follow TNS on your favorite social media networks.
Become a TNS follower on LinkedIn.
Check out the latest featured and trending stories while you wait for your first TNS newsletter.
KubeCon in Paris was an amazing opportunity for like-minded people to gather together to talk about Kubernetes, GitOps and cloud native computing. We took the opportunity to survey expert developers about their modernization initiatives, including what works well and where there’s pain.
Developer experience (DevEx) is the primary driver for modernization initiatives. More than two-thirds of organizations are moving to cloud native, Kubernetes and GitOps to improve DevEx. Despite these good intentions, there are two common trip hazards that must be addressed:
GitOps and Kubernetes are natural companions. Compared to virtual machines, Kubernetes has superpowers in container orchestration and dynamic scaling. The ability to automate Kubernetes is also a huge advantage, and GitOps is the natural way to do this.
Pragmatic GitOps stops short of saying everything should happen in version control. For example, a dedicated CD tool will handle your Kubernetes manifest file and handle the deployment process. It will apply the correct configuration for each environment and ensure software versions progress through each environment.
The problem with the pure-GitOps approach is that you end up with YAML files everywhere. Not just two or three files, but thousands. It only takes a few services and environments to generate YAML sprawl, as illustrated below. If you apply different configurations per customer or location, the problem is even worse.
We spoke to Kubernetes experts at KubeCon Paris. We found twice as many advocated for pragmatic GitOps over a pure approach. (Pragmatic GitOps was preferred by 67% of experts vs. 33% who opted for pure GitOps.) As DevOps teams apply GitOps at scale, the need for specialized tooling to handle things like configuration becomes more apparent.
👁 Pragmatic or pure GitOps diagram
Hammers are great at what they do, but they don’t do everything. Once you’ve experienced YAML sprawl, you’ll double-check your toolbox to see what else you have available for the job.
We know that DevEx is the No. 1 driver for modernization initiatives, but developers want better continuous delivery tools.
The current problem stems from the fact that too many teams are using their CI tools to run CD tasks (but CI is not CD). This means they are writing scripts they then store in strings inside of YAML files. CI tools don’t offer features for environment progression, deployment observability and configuration management for environments and tenants.
While these hand-cranked scripts run inside a CI tool, they are actually more like a homegrown scripted deployment solution.
You have likely encountered a shadow IT project at some point in your career, where a business user has created a critical application inside an Excel spreadsheet. These inevitably become urgent rescue projects when their creator moves on or becomes overwhelmed with what they created. Creating a CD solution inside a CI tool is basically do-it-yourself shadow CD.
Almost two-thirds of developers are using a CI tool or all-in-one solution for their CD pipeline, and it’s leading to an explosion in self-managed scripts as a basis for deployments. This is one of the reasons DevEx is a problem to be solved. More than 80% of developers we surveyed told us that CD is the most impactful investment that can be made for DevEx.
As organizations invest in improving DevEx and software delivery performance, an appropriate consideration of CD will be crucial.
It has long been held that modern software development is fraught with cognitive overload. When you first pick up Kubernetes, the ecosystem of choices causes decision overload. Once you’re up and running, though, it’s YAML sprawl and DIY shadow CD that are limiting your software delivery and causing pain for developers.
In the “Leader’s Guide to Kubernetes Adoption,” Nikita Dergilev and Bob Walker explain that business goals need to drive your Kubernetes adoption to avoid being deprioritized by future initiatives. There are a number of decisions to make along the way that will benefit from a collaborative standardization process. The two crucial choices you can make are with respect to DIY shadow CD and YAML sprawl.
We’ve moved on from traditional infrastructure because modern cloud native solutions offer so many benefits. But unintentionally, we’ve lost finesse in the way we manage software versions. Updating our good practices to support modern software is critical if we want to solve the problems of cognitive load.
