Various cloud native projects are celebrating their first decade. While there are obvious big names, such as Kubernetes itself, Helm, and Cilium, the ecosystem is much wider and includes lesser-known tools that have been around for a while as well. I’ve been involved in the werf project since its inception more than 10 years ago, and I’d like to share its story to contribute to a broader picture of the present cloud native world.
What is werf? Basically, it’s an opinionated, all-in-one command-line interface (CLI) tool for building container images and deploying them to Kubernetes. At this point, you might be wondering why anyone might need it, given that today we already have so many other tools performing similar tasks. Good question! To address it, I suggest diving into the project’s history to understand its peculiarities, reasoning behind it, and evolution.
Werf originated from a Linux-focused DevOps service provider that was challenged by automating numerous container orchestration routines for various customers. It happened in 2015-2016 when containers were already widely used, and even Kubernetes existed, though it was not yet very popular.
When we talk about running applications as containers, what was the first thing the engineers did with them? They built the images by invoking docker build and several other commands. That’s exactly how werf started: Making a wrapper for these actions and improving this process by embedding several enhancements, such as different build stages, smart caching, adding third-party artifacts, and even Chef support. (Again, it was when such configuration management tools were widely used, and this kind of integration seemed natural for the Ops world.)
Importantly, it was not a universal type of wrapper. From its inception, it was a tool strongly focused on automating well-established workflows and, thus, forcing specific views on how the images should be built, tagged, etc. While the approach was opinionated, it was based on real-world experience operating infrastructure, not for a single company but for numerous customers across varying industries and sizes. Facilitating the same best practices for orchestrating containers was the very sense of creating werf, and this ideology has lasted since then.
The next big capability werf got was deployment. After you build a container image, you want to run it in some environment, right? At that time (2017), it was obvious that Kubernetes would be the preferred platform to run containerized workloads, and Helm was already around. Thus, werf used Helm to implement deployment to Kubernetes. It was another core idea of the project: despite being opinionated about how you want to get your work done, the fundamental technologies you’re using to achieve that are mainstream: git, Docker, Helm, Kubernetes… In some way, werf became a “glue” for these technologies — for example, you could execute one command, werf converge, to (re-)build your app and (re-)deploy it to Kubernetes.
Over the years, other significant capabilities and best practices were added to werf, such as parallel builds, content-based image tagging, advanced resource tracking during deployment, a sophisticated approach to cleaning up the container registry, bundles for distributing release artifacts, ready-to-use integrations for GitLab CI/CD and GitHub Actions, so-called Giterminism for hermetic builds, and so on.
Eventually, werf evolved into an all-in-one CLI tool with many features on board, proven over years of production use by its creator and later by many other companies. Another fundamental idea behind the project contributed to this growing adoption.
The creators of werf were heavily involved in open source, as their entire service business was built on deploying, configuring, and maintaining Linux servers and endless other open source software needed for web services. This made werf open source and available on GitHub from the very beginning for both ideological and practical — or should I say professional — reasons.
Interestingly, implementing many features in werf resulted in creating other open source projects that turned out to be helpful on their own. Some of such examples include:
Seeing that more users adopt werf for their needs and are willing to provide stronger guarantees for the project, we decided to donate it to a trusted foundation. At the end of 2022, werf became a Cloud Native Computing Foundation (CNCF) Sandbox project, signaling to the wider tech community that this tool will stay open source and won’t be owned by a single vendor.
Over the past decade, the cloud native ecosystem has evolved significantly, offering software engineers an impressive variety of tools and solutions. At the same time, werf has undergone a long way from a simple wrapper to a comprehensive solution. Being an opinionated and all-in-one tool, it is mostly focused on specific use cases nowadays, such as other DevOps agencies, organizations that want to ensure strict rules for delivering software in Kubernetes, and just some users who like the principles facilitated by werf. (As a side note, perhaps the werf’s subproject Nelm has more potential for a massive adoption.) Nevertheless, werf is actively used in at least 18,000 projects worldwide today and maintains a robust pace of development, continuously adding unique features for its current and potential users.
For me, the story of werf illustrates how a passionate, consistent development of in-house tooling, coupled with dedication to open source, can benefit a wider engineering community and maybe even inspire others.
YOUTUBE.COM/THENEWSTACK
Tech moves fast, don’t miss an episode. Subscribe to our YouTube
channel to stream all our podcasts, interviews, demos, and more.
Source: thenewstack.io…
