What I’ve Learned Since Joining Harness.io
It’s been exactly one month since joining Harness and learning about the CI/CD space. I have an extensive background in software development and over half a decade of experience in delivering products to the enterprise IT space.
I’ve definitely had my fair share of exposure to the various technologies, processes, and platforms out there. Admittedly, it is hard to keep up with so many buzzwords popping up almost daily. Every IT conference is another platform to announce some sort of new startup, product or initiative.
But, CI/CD? That is the least sexy or top-of-mind concept for as far back as I can remember. CI was really solved for, right? And CD? Isn’t that just bundled into CI? Nothing could be further from the truth. Let’s jump in.
What is CI/CD?
Continuous Integration (CI)
CI and CD are not the same thing. Not by a long shot. First, let’s draw a diagram of how software is built:
Developers write code, they check in code, and then that code gets tested. If the tests pass, the software is essentially ready for deployment.
I know, I’m oversimplifying, but you get the point. Go back and reread a key term that you probably just glanced over: deployment.
"We’ve taken it for granted that deployment is something that is made possible by all those sophisticated SREs and DevOps engineers who can make your code fly like white pigeons ceremoniously released at a wedding."
We’ve taken it for granted that deployment is something that is made possible by all those sophisticated SREs and DevOps engineers who can make your code fly like white pigeons ceremoniously released at a wedding. Not true. What do these folks do in order to successfully deploy your (hopefully not) shitty code?
Continuous Delivery (CD)
To deploy software, you’ll need to go through a few different phases. I’ve created a simple diagram to overview the phases here:
Do you see how complicated CD can be when it’s done right? It literally is not simply pushing your artifacts post-build into production. That’s a silly thought, although a fun one for lazy developers. To deploy correctly, you’ll need to:
Abstract these various steps into a pipeline that can stitch together the various stages and environments (e.g. QA, stage, production)
Automates the necessary workflows within each stage. That is, what the heck needs to be in each environment in order for the artifact to progress to the next stage
Manage the auditing and change management of deployments (e.g. tickets)
Deploy your software using the various best-practice release methodologies (i.e. blue/green or canary)
Verify that your artifact is not bad. Remember that all those performance and log monitoring tools you invested in? It’s time to orchestrate their utility in an automated way within your pipeline to ensure your application isn’t degrading the application performance
If needed, rollback the software in an efficient, effective, and non-disruptive fashion so that your users don’t have a clue that you just screwed up.
What took CD so long?
I have a theory. I could be wrong, but I’m probably right. Building software used to be a pretty complicated process. Let’s go back, say, 10 years ago. You would write code into these giant monolithic applications, run some tests, then release your software maybe once or twice a year. If you’re super agile then maybe you released once a month. Good for you.
Then, you have the entire deployment process that was literally a herculean effort among the developers, release teams, and IT operators. No one imagined software would be deployed multiple times a day. It was accepted that releases were rare.
Apparently, at Facebook, software releases were an all-hands-on-deck endeavor that involved the entire development team in a single IRC channel while the release team would push code live into production. Engineers all had “karma points” and if your code ever broke a release then your karma points would be taken away. The less the points, the less the trust in your code being deployed. Savage.
Today, we’ve improved the process but we’ve also introduced two problems:
Software is way easier to build, so the bottleneck has been pushed downstream to the deployment phase
Applications are broken into microservices causing a massive amount of complexity within environments that are difficult to keep track of (welcome, Kubernetes).
So, the release process itself has become the new bottleneck
Software Development Bottlenecks
So, let’s imagine a funnel of what building software used to look like:
Do you see where the bottleneck used to be? Writing code! Then, the bottleneck became performance
With the introduction of modern APM tools and better performance monitoring techniques, performance no longer became a bottleneck. So, here is where we are today:
And this, ladies and gentlemen, is where we find ourselves today. The SDLC process has officially found a new bottleneck: how do we rapidly deploy stable and performant software?
“The SDLC process has officially found a new bottleneck: how do we rapidly deploy stable and performant software?“
Wait, isn’t CD Solved by Chef/Puppet/Jenkins?
Absolutely not. Chef/Puppet are configuration managers, instructions as code on how to configure the various nodes within your infrastructure environments. Jenkins is a CI tool, which helps teams build and test code, not deploy it. Jenkins was never designed to handle deployments. Yes, you can extend Jenkinn to create a release pipeline. For those of you who have taken on this pain know full well how much scripting and extending is involved to make this happen. Not worth it.
I’ll make it really easy for you to understand the difference between CI and CD with the following diagram:
"...the same way your team isn’t interested in building your own CI tools, you also should not be interested in building your own CD tool. This is where Harness comes in."
Everything on the left is considered Continuous Integration, or CI. Everything on the right is Continuous Delivery or CD. Are you seeing the differences, now? All those scripts and manual work that you do (on the right) in order to build a successful CD pipeline has been abstracted into a powerful platform that we’ve built at Harness. Once you understand the difference between CI and CD, you begin to understand why Jenkins is NOT a CD tool. Neither is Chef, Puppet, or Ansible. And the same way your team isn’t interested in building your own CI tools, you also should not be interested in building your own CD tool. This is where Harness comes in.
Also, what’s an artifact?
An artifact is whatever state your application is built in and ready to be deployed. Artifacts can also be interpreted as services. This could be a Docker image, an AMI, WAR, Zip, Tar, or RPM files. It doesn’t really matter what software stack you build your application/service in or how you package it — Harness will take the artifact from build to production.
Pros and Cons of Continuous Delivery
Pros
You can deploy multiple times a day. Developers can push new features almost as fast as Product Managers can think them up. But, why does this matter so much? Here is why:
Your customers demand more functionality and are impatient
So, your sales team responds and asks for innovation
So, your product team responds and asks for more features
So, your company responds and invest in more R&D
So, your engineers get to coding
So, your QA team starts testing
So, your release team gets ready to push live
So, your bottleneck is to ship, ship, ship!
If you can unlock your CD bottleneck, the cascading effect literally reverberates throughout your entire organization and — most importantly — felt by your customers! You’re now on the bleeding edge of innovation.
Cons of Continuous Delivery
You probably weren’t expecting this, but there are some disadvantages that I’ve noticed. These aren’t difficult problems to solve for per se, but nonetheless a consequence of the cutting-edge deployment techniques that our customers are leveraging with Harness.
Customer Enablement
Your customers are becoming confused with the pace of your deployments. How awesome of a problem is this, though? As cool as it is to CD so well, you cannot ignore that your customers are using your software and becoming accustomed to a particular way to do things. If you drastically change the way your features work or even rearrange a button, this will cause confusion among your customers.
Solution: release intelligently without drastically interrupting the UX.
Sales Enablement
If you’re an organization that relies heavily on a sales force to sell your software, you cannot push out new features faster than they're informed and trained on the value of the feature. Back when software was released in a waterfall fashion (e.g. once or twice a year), it was easy to prepare all the enablement material to train the sales organization on:
What’s new
Why it matters
How to sell it
Why the customer should care
Fast forward to 2019: if you’re deploying your software multiple times a day using Harness, how do you ensure your sales organization is enabled?
Solution: be ahead of the curve and keep your sales organization enabled about new features before customers are.
Marketing Launches
This was one of the most fun problems we marketers loved to solve for. We used to put together giant launches once a quarter, or twice a year, and rally the market around a single theme intended to solve specific business goals. How do you do this when your company product is being deployed daily? Multiple times a day. New features are already in the hands of your customers probably before your marketing organization has even had a chance to look at the new features.
Solution: divorce your marketing launches from product launches. Marketing can now pick and choose whatever features they want to bundle into whatever cadence of launches they feel the need to do so.
Sum it up
I have yet to have a dull day at Harness since joining. As I write the finishing touches on this blog, we just announced our Series B fundraising round of $60 million raised putting our valuation at $500 million. How awesome is that? We’re already half a unicorn and it’s only been one year since our GA launch! More importantly, it's a testament to the value we bring to our customers in accelerating their product velocity.
This party is just getting started!
This article originally appeared on the Harness.io blog. You may read the original article at: https://harness.io/2019/04/what-ive-learned-since-joining-harness/
