Creating a Full-Stack Team with Continuous Delivery as a Service
There’s no doubt that Kubernetes orchestration is so hot right now. There’s also no doubt that when you go from a single source of truth with a monolithic architecture to highly distributed systems, application delivery gets harder — especially for the developer. There’s no such thing as a full-stack developer anymore because the new cloud native stack has so many layers. Instead, modern organizations need to embrace full-stack teams with expert individuals.
Continuous-Delivery-as-a-Service (CDaaS) is emerging as a solution for organizations that want to leverage microservices and containers to allow customer-facing applications to scale up quickly, but that also want to camouflage the complexity behind delivering that software into a simple user experience for developers and DevOps engineers. The idea is that, as a creative software worker, you should only worry about working on the piece you own — the piece you’re good at.
CDaaS is particularly helpful for mid-sized businesses looking to achieve continuous integration, delivery, and automation without having to build and maintain their own pipelines.
Continuous integration and continuous delivery (CI/CD) is naturally deterministic. You configure what it should do, making workflows easier to automate. Organizations need no longer rely on manuals written after a deployment to record what’s expected to happen the next time. Now developers can write what will happen within the code.
“Now, with CI/CD, once you figure out how it’s supposed to work, you can insure it’ll work every single time. And when it fails, it fails in a controlled way and it explains how it fails and you can change your configuration and then it’ll work right.” — Tom Petrocelli, Amalgam Insights
In this piece, we understand what CD as a Service is, who it’s for, and why CloudBees has just announced the arrival of CloudBees CI/CD powered by Jenkins X.
What Is CD as a Service (And What It’s Not)
Tom Petrocelli, research fellow at Amalgam Insights, defines CDaaS as simply taking your continuous delivery pipeline to the cloud.
Petrocelli focuses his research on the “why” driving the migration of systems from monolith to microservices. He has followed the CI/CD transition from very simplistic workflows to a sort of enterprise DIY phase to what is now becoming completely integrated pipelines and end-to-end solutions.
He says it’s fair that companies no longer want to have to bear the burden of cost and time in maintaining their own CI/CD pipelines. And he appreciates the need for end-to-end enterprise support of a whole CI/CD pipeline. Both of which a CD as a Service covers.
But he warns against the risk of vendor lock-in. Particularly for mostly hybrid enterprises. He is wary of cloud provider CD solutions like AWS CI/CD pipeline and CI/CD with Google Cloud because he believes their objective is more pay-as-you-go cloud resource consumption rather than an improved UX.
Petrocelli thinks success for CDaaS comes down to something that can translate across different departments and use cases. He held up the Continuous Delivery Foundation’s open source Tekton project as a simple-to-use, very visual, Lego-like way to build CI/CD pipelines that many products are built on top of.
The broader market now demands out-of-the-box simplicity, not customization. While a more regulated and complex environment, typical of financial services companies and government agencies, still needs flexibility and customization. And even those industries are leveraging the cloud and CI/CD Software as a Service even more.
For Jamie Bliss, Continuous Delivery as a Service integrates with an existing configuration management tool — or several — and makes shuffling data from your Git source code to that configuration management system easier. It also eases the handling of multiple environments and hybrid environments.
And it must have a user experience that developers actually want to use.
“In a tooling-focused role, using a CDaaS to connect my code repos to my servers is one less thing to set up and one less thing to run and maintain and keep online,” Bliss said. “On the flip side, it’s also a constraint I don’t have a lot of control over, so if my company’s systems grow too big or too complex for the service to handle, we’d have to migrate.”
Bliss doesn’t worry it’ll put her out of a job, it just means she can focus on more interesting work and less maintenance.
“Using services like a CDaaS means that you don’t need to spend engineering hours — money —on that task and you can focus on other things,” Bliss said. “Basically, you throw money at the problem and make it go away, so your teams can focus on the problems you actually want to solve — your product — instead of meta-problems and meta-meta-problems.”
Bliss continued that using CDaaS even opens up more space for developer specialization.
She said, ”I think there’s a lot of room for application developers with focuses — UX, algorithms, databases, Ops, etc. Having a multidisciplinary team like that is good, even if they all have the title of developer or software engineer and they don’t do their focus full time.”
Bliss self-describes as a niche CDaaS developer. With 15 years in Web, DevOps and Systems, she’s worked with what she calls “general-purpose public CI services” — Travis CI, Appveyor, CircleCI, Cirrus CI, and GitLab CI. She explained that out-of-the-box they have very limited or no defaults, so you have to provide them with scripts and tell them what to do.
She says it’s the same with other self-hosted and paid-only options.
“You can teach them how to run a deployment, but it’s a lot of work and copy-pasting code all over the place, and, if things go wrong, it can be a pain to debug,” Bliss explained.
She continued that she thinks there’s a lot of room for CI/CD- specialized services. These are “glue services” that are less flexible but “cover 80 percent of use cases with less fuss and hassle than getting a general CI to do that.”
Who Is CD as a Service for?
Petrocelli contends that the heart of the problem with CI/CD is that so much of it is still DIY. It leads to enterprises hiring engineers whose main job is to implement and maintain the CI/CD platform, managing updates and testing.
CD as a Service should take care of all of that, so you don’t have to.
“Would you rather have your IT dollars go to build applications to help your org meet its goals or do you want to be building infrastructure? IT is supposed to be driving revenue or lowering cost.” — Tom Petrocelli, Amalgam Insights
Bliss sees a natural first market for CDaaS at companies that don’t want to own their own metal or servers but that have big enough pockets to afford these services. These are the startups where “If you have more money than engineers or time, then using something like CDaaS to accelerate your time and bootstrapping makes sense.”
She believes CDaaS will be adopted as part of the baseline greenfield infrastructure these well-funded startups need in place to get up and running, alongside a Git repository, projects setup, deployment pipelines and operational stories. She calls this combination a good way to automate services, so your engineers can focus on actual problems.
She says a CDaaS is also appealing If you have reasons to not use Heroku, like if you’re running your own Kubernetes or own your own metal. Or if you want more control over your billing in the public cloud. Or if you are simply getting priced out of Heroku because you have a heavy service-oriented architecture.
“I’m never going to judge a company [on] what their choice is in this CI/CD tooling spectrum because choosing your architecture in this space is a very complicated decision. Each story is very different.” — Jamie Bliss, Lumami Software
Bliss reiterated some common benefits she’d want from any CDaaS tooling, including strong environment management, integration with an existing configuration management tool, and reliability.
In general, there seems to be a mid-market niche for CD as a Service.
“Now that we have vender-supported, end-to-end solutions, it brings more people into the CI/CD world.” — Tom Petrocelli, Amalgam Insights
CDaaS is emerging fast in response to the tremendous growth seen in the containers and CI/CD market. In fact, Petrocelli argues that you can’t have one without the other.
Indeed, Kubernetes and CI/CD have a symbiotic relationship where container architecture enables constant deployment and CI/CD addresses the process and organizational needs. CI/CD and CDaaS are helping to alleviate a lot of slow-down that occurs when organizations first start to implement Kubernetes orchestration.
Petrocelli continued that even “for more traditional apps it still holds that you want automation because it’s a pain in the ass to deploy software manually across any mid-size enterprise.”
Manual deployment usually happens nights and weekends and contributes to developer burnout. And it’s still very expensive to employ a staff of maintainers.
Is CD as a Service a Cure for Kubernetes Anxiety?
CloudBees’ VP of Cloud Moritz Plassnig has witnessed a major shift in the industry toward Kubernetes but he says it doesn’t come easily. Organizations are often shocked to find how difficult it is to transition to thousands of microservices and then run Kubernetes in production.
“Kubernetes is becoming very popular — it’s the leading tech in the space — but so many companies really struggle in that new world.” — Moritz Plassnig, CloudBees.
He clarified that, for those few experts who work with Kubernetes every day, it’s not actually very hard, but that’s just a small group. The challenge is for the thousands of developers who have to interact with it, when it’s not their jobs to become a Kubernetes expert.
“A developer is supposed to be focused on writing code to create value for the customers. When they interact with Kubernetes, because it can do so much, it’s easy to do things wrong,” Plassnig said.
And developers simply don’t need to learn everything about the Kubernetes ecosystem and updates. This becomes a security risk when you’re dealing with such a complex system. And this complexity is multiplied by so many tools, environments and data sets.
There’s an important demand for a product that abstracts Kubernetes to a certain degree, allowing these developers to leverage Kubernetes just for what they need it for. And they don’t even have to know it’s Kubernetes they’re leveraging.
“What really matters is that you frequently and continuously deploy.” — Moritz Plassnig, CloudBees.
CloudBees Introduces CloudBees CI/CD Powered by Jenkins X for Enterprises
Plassnig said Jenkins is the most adopted open source continuous integration project in the world, and CloudBees is its largest corporate sponsor employing an entire product organization whose mission it is to contribute to and maintain Jenkins. CloudBees offer an enterprise self-managed CI solution, CloudBees Core, which utilizes Jenkins as one of our commercial offerings Plassnig said. It began as an enterprise tool built around the Jenkins CI/CD tool. Now he says it still continues with CI but the industry is also demanding continuous delivery, preferably in a production environment.
The CloudBees suite now helps customers continuously test and deploy, which includes open source project Jenkins X, a CI/CD solution for cloud applications built on Kubernetes. Jenkins X was built at CloudBees and donated to the Continuous Delivery Foundation (CDF) in 2018. The CDF also manages the Jenkins project. Plassnig described this as a product of 15 years of learning from Jenkins, but said it doesn’t share any code with Jenkins.
Plassnig believes there’s a lot of innovation and it will get there, but right now CD and Kubernetes is slightly overhyped. He quipped that you will find few if any Fortune 100 companies with global, enterprise-wide Kubernetes deployments for all their existing applications. Adopting a new technology like Kubernetes simply takes time and migrating legacy workloads takes many years. Without a centralized Kubernetes strategy, apps break in production and developers are constantly on call.
Jenkins X aims to simplify this so anyone with secure access could build on top of Kubernetes.
For example, a developer makes a change to code. She would commit it to GitHub. Jenkins X will have it automatically appear in a preview environment for this specific code change in that Kubernetes cluster. Then it posts the URL to view this change as a GitHub pull request. Then feedback is shared in that URL, too. Then, once everyone agrees on that change, it’s a single command to a staging environment. Finally it’s one click to a production environment.
All this functionality is out of the box with Jenkins X. And in an experience that the developer never has to think about Kubernetes.
And for those Kubernetes experts within a company, it’s helpful that it is heavily integrated with other open source Continuous Delivery Foundation projects like Jenkins X, Vinegar and Tekton.
This week at DevOps World Lisbon, Jenkins X was released as a CDaaS called CloudBees CI/CD powered by Jenkins. This is a logical evolution because, as Plassnig said, other than the largest companies that own their own metal, “People want to consume Jenkins X, not run it.”
CloudBees will continue to open source everything that’s good for one developer or a small prototyping team, CloudBees CI/CD powered by Jenkins X will house proprietary features geared towards the Fortune 50 companies that have to prioritize security and governance.
CloudBees CI/CD powered by Jenkins X is for companies developing greenfield, cloud native applications on Kubernetes. Though the largest pool of users to date comes from the Jenkins community, it’s designed for users who may also be new to Jenkins. This solution is opinionated or on so-called guard rails, with many ready-made pipelines that automatically employ modern CD best practices which makes it easy to use from the get go.
You can also rollback with one click. And automatic rollback is in the product roadmap.
Plassnig stresses the most unique part of CloudBees is that it does all this within the view and use of one tool.
“There are many solutions focused on a subset of the problems Jenkins X is checking [for]. CloudBees is an enterprise company. What we realized is that we can solve those problems in a single product that devs love,” Plassnig said, like with banking giant client HSBC, which has 40,000 IT professionals.
“The unique advantage is providing a product that enterprises trust and developers love,” he continued.
Plassnig said Jenkins X is, in part, in response to the change in how software is purchased these days. It used to be the CIO deciding, purchasing and deploying for the whole company. Nowadays the end-user developers bring the products in the company — that’s how Slack gained traction.
Plassnig continued that “Having a product that developers really love is important. But then, when we look at the other startups in our space, it’s not enough that it’s a product that end-users love — if you’re working for a bank, and if the CIO, the compliance officers or security team don’t love the product and it doesn’t do what they want,” you’ll never gain traction.
