Send new GitHub mention to Slack as message
Slack + GitHub
Send new GitHub mention to Slack as message
Slack + GitHub
This article is about how many skilled DevOps and SREs currently misuse Jenkins for automations completely unrelated to CI or CD. We explore common use cases for abusing Jenkins, and identify the risks of using Jenkins for CloudOps.
Let’s start with the obvious. Jenkins is a modern miracle. This venerable DevOps automation server was initially released on February 2, 2011, and few platforms have managed to achieve and maintain such a positive reputation within its community of developers, as well as a creating a vibrant ecosystem of plugins and educational resources. In just over 10 years, Jenkins has become a workhorse in DevOps automation for platform engineering teams big and small.
According to their official website, “Jenkins is the way to build, test, and deploy [cloud applications].” This is a good summary of what Jenkins does well. Primarily, it is “an extensible automation server, [that] can be used as a simple CI server or turned into the continuous delivery hub for any project.”
In other words, Jenkins was built to solve for the continuous delivery and deployment of software. You can use Jenkins to build your code from many different services, run tests on your code, and then ultimately deploy your code to your cloud infrastructure. All these activities must occur before an application is available in production.
But, that’s not all Jenkins is being used for today.
This article is about how many skilled DevOps and SREs currently misuse Jenkins for automations completely unrelated to CI or CD. We’ll explore some of the more common use cases for abusing Jenkins, and identify what are the bigger risks of using Jenkins for CloudOps use cases.
There’s a whole different class of operations activities concerned with managing, maintaining, and securing already in-production cloud applications.
These include many activities, such as:
Every single bullet above has an entire category of cloud tools associated with that specific activity. Each of these tools requires some degree of custom integration effort, configuration, and learning its own unique terminology and user experience.
Platform engineers are constantly onboarding, learning, and integrating to new cloud platforms. The widespread adoption of cloud-native and serverless architectures has redefined the daily experience of platform engineering teams. DevOps and SREs now spend much of their time doing CloudOps – building integrations, manually administering cloud platforms, and writing scripts to automate manual processes.
Jenkins may be a perfect fit for DevOps, but it’s not a good match for CloudOps.
One common misconception about Jenkins is that it is a DevOps automation platform, which isn’t quite true. There’s a very good reason why the Jenkins website says “DevOps automation server” instead of “DevOps automation platform.” That’s because Jenkins does not include many of the usability features commonly associated with platforms.
For example, there is the whole aspect of managing your Jenkins. Unlike managed cloud services like AWS or Slack, Jenkins is a service that you need to manage by yourself. That means you’re on your own for setting up RBAC, access, backups, plugin management, etc…
This a complete headache, and only skilled platform engineers are able to do this kind of work. Most of the industry are consuming managed services because of that pain, but platform engineers ignore this problem with Jenkins because it seems like there are no better options.
Compared with DevOps, VMware explains that “CloudOps codifies procedures and best practices for cloud-based operational processes, much as DevOps codifies the same for application development and delivery processes.”
Until , there wasn’t a general-purpose CloudOps automation platform. Without an optimal solution, resourceful platform engineers turned to their trusty companion Jenkins to orchestrate CloudOps workflows across different cloud services. While you can hack your way to a working automation in such cases, this is actually an anti-pattern that you should steer clear to avoid.
Let’s examine why Jenkins is not a fit for CloudOps.
Consider this self-service workflow. Suppose you want to build a Jenkins pipeline that automatically creates a new customer license on-demand. In Jenkins, this is a problem. Running a self-service automation on Jenkins requires the consumer to have Jenkins access. Since you probably use Jenkins as a CI/CD tool, it already has access to your private networks. Now, that consumer requires access to sensitive networks, just in order to run a simple Jenkins workflow.
That means whenever your business team needs to create a new customer license, they are at risk of jeopardizing your cloud application’s security and reliability.
There are a number of ways to determine if your organization is exhibiting risky behavior using Jenkins.
Here are 3 warning signs that your organization has bad Jenkins hygiene:
If you identify any of these anti-patterns, there’s a better option for your CloudOps automation workflows than using Jenkins.
Blink is a no-code/low-code automation platform that’s purpose-built for CloudOps. Blink comes loaded with more than 20,000 cloud-native actions and an Automation Library of over 300 automation templates for common CloudOps workflows.
Blink makes it simple to compose, manage, and secure all your cloud and security operations workflows. You benefit from a fully-featured cloud platform, with managed workspaces for all your different teams and projects. Blink workspaces come with support for granular RBAC and self-managed Git repositories. Bring all your existing scripts and processes, or quickly compose new no-code/low-code automations.
Blink also redefines how DevOps and SREs serve the other teams within their organization. Using Blink, CloudOps teams can provide a self-service portal with on-demand automations to developers, business stakeholders, and executive leadership. This proactive service model significantly reduces context-switching associated with ad hoc service requests. Furthermore, CloudOps teams can expose on-demand automations via Slack, Teams, or project management platforms to engage stakeholders wherever is most convenient.
Blink helps DevOps, SecOps, and SREs achieve flow in their everyday work, by making it easy to create automated workflows across the cloud platforms and services they use every day. The impact of adopting a low-code/no-code platform like Blink is happier, more productive teams and more reliable, resilient, auditable cloud operations.
The best part? Blink early access is available today. Try out the future of no-code/low-code CloudOps for yourself. Get started with Blink today.