Contributed by Bartek Antoniak, VirtusLab
When it comes to the cloud native technology landscape, the rate of change in this space is impressive. Almost every day we hear about new technologies and open standards that are advocated as “advancing software delivery and how we work”. This often leads to the following consideration: staying with the legacy solution we currently have or migrating to the new technology stack.
If we want to stay on top of the latest technologies with legacy solutions, it requires interoperability in the cloud native world. The technology itself needs to adjust to cloud native architecture principles like scalability, stateless components, declarative configuration, and automation.
On the other hand, if we decide to migrate to the new solution, it’s often a big question mark. Does this technology really fit our needs? What about a seamless migration path, upskilling people and security aspects?
This article focuses on paving the way for Jenkins interoperability in the cloud. We’ll understand what makes Jenkins cloud native ready and how to stay relevant in the dynamic nature of new technologies these days.
Minimizing the distance between Jenkins and cloud
Jenkins was created a while ago in 2004. However, it still holds 51.02% of the market share with more than 5,887 companies using this software according to this Datanyze report.
Jenkins was not necessarily designed to be run in the cloud from day one. It was especially not built to work in a dynamic environment like Kubernetes, which has become the de facto standard for running containerized workloads in the cloud nowadays.
The good news is, we can significantly minimize the distance between Jenkins and the cloud by delegating more responsibility to the cloud. This approach also reduces costs by creating less operational overhead.
What makes Jenkins Cloud Native ready today
Running stateful applications like Jenkins in a distributed, dynamic cloud environment like Kubernetes is probably the hardest aspect of achieving truly cloud-native infrastructure due to complex life-cycle management and scaling activities.
With stateless applications, we can scale up, scale down, or terminate them at any time without fear of data loss because all states are stored outside of a container. At the moment, this is barely possible with the current architecture of Jenkins, however, the Cloud Native SIG is leading the effort to make it better in the near future.
Let’s have a look at the key aspects that make Jenkins Cloud Native ready today.
Extensibility – thanks to the rich ecosystem of plugins, Jenkins is highly modular. Without changing the core architecture, the system can be integrated with the cloud environment, e.g. by using external AWS S3 storage for backups. Plugins are the main source of configuration and adding new capabilities on top of Jenkins.
Declarative configuration as code – designed with immutability in mind, it helps deploy and manage software faster. Jenkins directly supports the execution of Groovy scripts, which are the main entry point to the Jenkins API, and the Configuration as Code plugin, which is a nice abstraction layer with some predefined tasks. Initial configuration can be entirely defined in code and automated from end-to-end.
Security by default – Jenkins is extensible via a plugin ecosystem. Some plugins are community-driven and maintainers have a lot of autonomy, which is a potential security thread. The secure defaults should be defined in immutable configuration as code to prevent common security risks like misconfiguration or vulnerable external plugins.
Full lifecycle management – instead of managing Jenkins manually, you can automate common operational activities and build repeatable workflows. The operator pattern enables engineering teams to put human operational knowledge into software operators, and at the end of the day focus on more important tasks.
Observability – you should bake monitoring and logging into your system. Make sure the system’s health is fully observable. Nowadays, the Open Tracing project is becoming a de facto standard in the cloud.
Interoperability in the cloud – everything that makes Jenkins easier to run on top of Kubernetes or other cloud platforms. For example, the kubernetes-plugin was built to scale Jenkins agents running in Kubernetes. The plugin creates a Kubernetes Pod for each agent started and stops it after each build. This provides a dynamic and resource-effective provisioning of Jenkins jobs.
Freeing up engineering teams from operational work
The operations space is not well recognized. It’s often deemed as uninteresting, sometimes even undervalued. With the Jenkins Operator for Kubernetes, we want to bring more satisfaction to this space, make it more interesting and improve perspective.
By putting human operational knowledge into software operators we can free up engineering teams from repeatable and boring operational work. The Jenkins Operator for Kubernetes is a Kubernetes native Operator that manages operations for Jenkins on Kubernetes. It.takes care of:
- Full lifecycle management.
- Integration with Kubernetes (Jenkins kubernetes-plugin) with declarative configuration.
- Pipelines as Code (Jenkins pipelines) using the GitOps model.
- Extensibility via Groovy Scripts (similar to Jenkins script console) or YAML configuration files (configuration as code plugin).
- Secure Defaults and hardening (security section of the documentation).
Infrastructure View
A typical day one activity involves setting up underlying infrastructure such as networking, compute, and storage; integrating with enterprise tooling; supporting ticket systems, etc.
Activities related to upgrades, patching, infrastructure life-cycle management are ongoing tasks which take significant time, especially at scale.
Developer View
From a developer point of view, the day two activities involve onboarding, installing Jenkins, and some post-configuration tasks. These processes can be simplified and partially automated using configuration as code and the operator.
Closing words
If we wrap up the key takeaways from this article, it is clear that making good old technology fully interoperable in the cloud is not a trivial task. It requires alignment with cloud native architecture principles like scaling, immutability, stateless components or declarative configuration.
Additionally, if we really want to free up our engineering teams for repeatable operational work we need to adopt the software operators pattern to automate common lifecycle management activities. The cloud native technology landscape rapidly evolves over time, it takes a lot of effort to stay on top of technology.
Getting started
Get more out of the engineering effort to solve business problems with Jenkins Operator!
