PurePerformance - 058 The State of CI, CD & Observability: Why you don’t have to build it yourself
Episode Date: March 26, 2018You wouldn’t build your own Jenkins – would you? Neither would you build your own CRM, Office or Email service. So why are the “cool” DevOps kids still building their own continuous delivery s...cripts, log analytics and monitoring and showing it off on GitHub or conferences?In this episode we invited Steve Burton (@BurtonSays), CD geek at harness.io, and discussed the current state of Continuous Delivery and the role of Observability (that’s Monitoring++). We learn about use cases that commercial vendors in these spaces provide out-of-the-box, the APIs they offer to integrate these tools into a larger eco-system and why we believe it’s time to stop building your own tools but investing in building better software for your users. We also learn about Blue/Green deployments, Canary Releases, Continuous Verification and Rollback vs Roll-forward.
Transcript
Discussion (0)
It's time for Pure Performance.
Get your stopwatches ready.
It's time of Pure Performance.
My name is Brian Wilson and as always, Andy Grabner. How are you doing, Andy?
I'm pretty good actually. Well, as always.
But today, very good because it's amazing. It's February 21st and I think have 70 degrees outside, and I'm in Boston, which is unusual.
But snow is coming in tomorrow, so everything back to normal tomorrow.
But today is an exceptional day.
Yes, that time of year where everything's up and down, it's just insane.
It's been a while since we've done this, so apologies, not apologies, but I guess sorry in advance if we're just not on the ball today because it's been a while.
A lot of stuff's been going on since we've last recorded one of these.
We had Perform.
I went to my first and probably last ever Mardi Gras down in New Orleans.
That was really insane.
And you've been quite busy yourself, Andy, right?
Yeah.
I mean, especially after Perform, I think there was a lot of sketch-up work to do. really insane. And you've been quite busy yourself, Andy, right? Yeah.
I mean, especially after Perform, I think there was a lot of sketch-up work to do on regular business.
And one thing that happened in the last two weeks, which now actually kind of brings me
over to our guests today, is we've been starting to build more and more integrations with some
of the tool vendors out there in the DevOps space.
And I've been involved with some of these conversations
and enabling our partners, and some of the partners also came to us.
And Brian, if you're all right with me going ahead
and introducing our speaker, our guest today.
Well, I first want to just say the work you've been doing lately has been amazing.
And I know it's not all you, but you've been spearheading it and helping it go.
So congrats to that.
It's some amazing stuff.
But yes, please go ahead.
And this leads perfectly.
What a great segue, Andy.
I don't know how you managed to pull that off. So today on the show is a it's interesting.
Steve Burton.
And for people that don't know Steve Burton, we have had the pleasure over the last couple of years, but more on the competitive side.
And now we are partners.
And it's great because in the end, even though back in the days when we were competitors
with Dynatrace and AppDynamics, now we are partners.
And in all these years, I believe we all try to help people out there that are trying to
build better software faster.
And I think, Steve, without further ado, I think you are hopefully still with us.
And I don't want to steal too much thunder, but I think you can probably introduce yourself
better than I can.
So fill us in.
Thanks for inviting me.
Not great to be here.
Again, Steve Burton.
I work for a company called Harness.
And so we, again, focus on continuous delivery. But again, a similar pass
to Andy and Brian in terms of performance monitoring. That's what I've been doing for
a long time. And it's great to be a partner. And as you guys kind of said, I think over the years,
the customers benefited from the competition and vendors kind of innovating to kind of create
better monitoring technology so yeah it's it's good to talk about how things have changed and
and what the future is for monitoring and development teams yeah and i think change
change is a big thing obviously right we all we all see the change out there i mean i've
you and and brian and i and we all we've listened to a lot of companies that are going through whatever you want to call it, digital transformation, cloud transformation, going cloud native, doing CI, CD, continuous delivery.
And these terms have been out there for a while.
And Steve, I just read some of your blog posts on Harness.io.
You said you've been following the whole DevOps community.
I think your first DevOps days was back in 2011.
So it's been a while.
But still, it seems a lot of companies are still struggling to get into how do we do CI?
How do we do CD?
How do we do this all correctly?
And it seems a lot of people are spending a lot of time in figuring this out
while they shouldn't do it because I think over the years in the community,
a lot of best practices came out, a lot of tool vendors came out
that actually help and support whether it's open source tools or commercial tools.
And I think there's also one thing that you guys are addressing now with Harness
is kind of ease the pain and kind of, I think you can probably put it even better,
and we just chatted about this, but why focus on building something the hard way
if you can focus on what's really important, which is the business, and let us help you with the other stuff around it?
Is that right?
Yeah, yeah, definitely.
And I think, I mean, we've all attended those DevOps events, and they're always sold out, and there's a lot of great content. perhaps in the early days when you talked about devops everyone was like automation let's build
stuff let's build frameworks let's do test automation let's automate our builds um let's
automate how we deploy and kind of what what we've seen especially the last year is a lot of companies
did that um and they did it through dedicating three to five people to basically script a lot of the frameworks and the automation.
And what's challenging with that is technology is changing every day.
So like if you mention Kubernetes, like two years ago, people would be like, what's that?
Or even Docker.
Whereas now if you're not talking about Kubernetes, people think you're mad.
And so like I have no doubt six months from now, there'll be some new technology. And
whenever that changes, those scripts don't script themselves. And it's kind of like going back to
performance monitoring in like 2005, right? Or even beyond that, like the early days of Wiley
or Precise, where you had to almost script
the instrumentation and tell it like hey i've got an app go and instrument these points whereas
today all of that's completely automated by the tools and the vendors like if you're a customer
and you're writing instrumentation like that's a lot of effort and time that you don't need to do because tools already do that
for you um so yeah where there's a lot of complexity we see is is continuous delivery
right there's not been a lot of options out there um and so just like you guys have automated a lot
of the monitoring with a single agent and discovery of all of the entities you want to monitor.
We're trying to do the same in the continuous delivery world, where we make it super simple
for a customer to pick up their app and push it through their deployment pipelines into production.
I think you raise an interesting point about the whole building your own tools, right? For a long
time, especially in the earlier days of all this,
there were no existing solutions out there. So everyone had to build their own. It was also a badge of pride to say, we built our own pipeline or we built our own monitoring solution, or
we built our own auto scaling solution, whatever it was, because there really weren't too many that
existed. Nowadays, though, if you're moving into these realms and you're going to start building your own, not only do you face the challenges that you talked about with, you know, having to maintain the code, having to get the people full time dedicated to creating this, these frameworks and maintaining them.
You're also now putting yourself behind.
If you're just starting your transformation now, you're already behind a lot of other companies and a lot of your
competition, right? So if you're going to then take the time to build your own framework,
you're putting yourself even further behind. Whereas we're at the time now, we're at a point
in time now where a lot of this stuff has already been created. There are solutions out there where
you can say, Hey, you know what? I'm just going to go grab that solution, use that, and then get
on, as you said, with putting code, putting features, improving our product out there and
not spend the time worrying about the tooling. Yeah. The lead time, right? It takes you a year
to get a 1.0, then you've got to maintain it. And it's not like open source is free either.
Like sure, you can download it but then i need
five or six engineers full time on it for a year and then i've got to then maintain it so like you
can easily spend a million bucks on open source to build whatever you want to build but like it's
time to market gonna kill you before cost does because i would argue a lot of companies today their biggest threat is their competition
delivering things faster and same in our industry right same in monitoring if you come out with the
next killer feature customers are going to love it they're going to buy it all your competitors
are trying to catch up as soon as possible um and i kind of use the the analogy it's kind of like us
building salesforce.com.
Like, why would we build a CRM system?
Or like, why would we build a version control system?
Like, those things exist, they're mature, and I can go and pay a subscription and use it when I need it.
So, yeah, I think there's a happy balance.
And a lot of commercial tools already use open source anywhere.
So like a lot of the best frameworks like you'll see in commercial tools.
So I think it's when does it make sense and when should you kind of move away from being
in the tools business when your core business is not selling tools?
It might be like video games or it might be retail or shopping or travel.
That's really where I think you move the needle.
Digital transformation is not about building tools.
It's about making your business better.
It's about acquiring more customers and hitting the bottom,
like making the bottom line and top line kind of better than your competition.
I want to raise a question then.
Aren't we then, it seems right now,
I mean, I love the DevOps days,
but it seems we are glorifying everyone
that can get on stage and show their next GitHub project
with the next library that they built and you know yeah i mean it's
it is something that we we did in the last couple of years because we had to because simply there
were no tool vendors out there that kind of took it over and it's maybe the time is over now to
glorify all these heroes or do we still need these heroes because in in the end, it's great if we say we have all the tool vendors and we can focus on building just the business benefits, the business logic on top into our products.
But I think we still need to make sure that people understand that having the basic skills of scripting and understanding what's actually going on, this is still important. On the other side, I think we probably need to go away
a little bit from glorifying everyone
that has just announced their latest cool GitHub project
and solving the same problem the 500th time now.
I totally agree.
In fact, I'd love to go to a DevOps event
where someone stands on the stage and says,
we implemented this bunch of technology
and this was the business impact. And this is how long it took this is how long it how much it cost
and this is where our business is today and i think a key point is a lot of these discussions
lack the business context like we talk about it and we talk about ideas and going fast but
understanding the real business impact of agility and change and tooling and, and all these GitHub projects, I think there's a complete void.
And there needs to be more transparency into what the business reasons are and what the value or the results are.
And so like absolutely and we need to stop focusing on the nuts and bolts and like what's
the big picture we're all trying to achieve um and and i do i think i think like observability
is a new word for monitoring and that whole argument like let's not like why aren't we
talking about like business like how fast you can move or user experience or like conversion rates or
like how we track business KPIs from our applications. Um, why are we still talking
about like drilling down and asking, like, it just, it makes no sense.
Yeah. I think too, that going along with both of what you're saying is in the,
where the whole process has matured so much. And, and to your
point, Andy, um, you having someone talk about, this is the way we did the same thing everyone
else did. That's what people have been doing for a bunch of years now is, is kind of becoming an
old story. And sure, there's always some inspiration, but it should be a lot more about,
this is how we got to our goal.
And our goal was to make our business more successful.
And we got there as quick and cheap as possible.
Right. That's a great story.
You had to do it the hard way in the old days.
And in the old days, we're talking about what, a year, even a few months ago.
Right. But you had to do it the hard way in the past because that was the only way, right?
And I just think the goal,
just like the goal for DevOps and all this stuff
shouldn't be like, hey, we want to get to the cloud
and we want to have microservices and containers.
That should not be what your goal of your company is.
The goal of your company is to put out a better product,
faster, cheaper, more reliably.
And whatever those new tools that might help you
get there, whether it be moving to the cloud or moving to containers, microservices, whatever
those are going to facilitate that you leverage. But the point isn't to be in a container. My goal
is not to run my business in a container. My bulk goal is to be more efficient and profitable as a
company. Same thing with all these monitoring and
tooling stories. And I agree with you, Steve, it'd be great to see a story, a little quick story.
Hey, we, we leverage these things. It cost us this amount of money and it had this much impact
on our business. And it only took us, you know, three weeks to get up and running on it or
whatever. That's a great story. That's an inspiring new model business story
because we're already past those exploratory days
of trying to figure it out.
So, Steve, then, from a continuous delivery perspective,
these are obviously the use cases that people,
hopefully not much longer, try to build themselves.
But what are the key aspects of continuous delivery
that you guys see with your customers
that people try to do with a platform like Harness?
You know, Phyllis, and I think something like Canary released,
but I'm sure there's other stuff too.
What are the things that you make so easy for your customers?
Yeah, sure.
So we define CD as artifact forward so continuous integration
is about taking code and creating artifacts we see continuous delivery about taking those artifacts
into production and i think a lot of people have an idea of continuous delivery as we need a
provision infrastructure we deploy a few scripts, and we're done.
And, I mean, you can do that.
You can drop files on production servers and crush your fingers.
I think where we've seen more of the complexity is how do you verify those deployments were successful?
So what was the performance impact?
What was the errors, the security impact you had with the deployments?
How do you deploy? Like, What is your strategy for deployment? Is it just a straight swap where you just basically
provision the new version right over the old version and cross your fingers?
Or do you do canary deployments where you phase the release,
you have verification gates, and you minimize the business impact?
And so, I mean mean there's lots of
others rolling deployments blue green um and so a lot of complexity you might not think about
um also security as well like one one surprise maybe is a lot of the conversations we've had
with customers security has actually been the reason they can't do continuous delivery. Like, how do you manage secrets?
What is the audit trails?
Where's the role-based access control, the authorization?
Everyone wants to give developers the freedom to deploy,
but how you control what they can do and the audit behind it
is still very, very difficult to build.
And you might not think of that, right?
If you're going to build your own CD platform, security might be the last thing you think
about, or you might think of it towards the end of building the framework or the platform.
And so that's the complexity we see.
Continuous delivery is almost like a jigsaw puzzle of many different pieces.
And then I guess where we see customers struggling the most is once the deployment has occurred,
how quickly can they roll back?
And what's interesting is there's two different views.
Do you roll back or do you roll forward?
And I think there's a perception
that if you do continuous delivery,
you must roll forward and you must fix's a perception that if you do continuous delivery you must roll forward
and you must fix things as soon as possible and you know that doesn't always work right you deploy
a production you might have an outage or a production issue like rolling rolling forward
or fixing it really really quickly is really difficult and so sometimes you have to roll back
and again it comes down to do you have the visibility?
Can you understand how your application's behaving?
And if you don't have monitoring or APM or the right visibility,
how do you know whether to roll forward or roll back?
Because when production's screaming and the business is asking you
why are things failing, every single minute that ticks
by like you lose money whether you like it or you or you don't like it yeah i mean canary releases
obviously are a great way to to kind of fix that problem isn't it because basically you put the
canary out there and you observe it but you still have your quote-unquote regular production service running and then if you have as you said earlier i think you call it build
verification or validation or what do you call it we call it continuous verification
i can give yeah i can give you a real customer example um so build.com like huge retailer online
they used to do blue green deployments where they would just flip over the new version from the old version.
And so they'd have obviously the existing production environment
and they'd have a staging environment.
Internal employees would test against it,
and then they would just flip that over in their production.
And that's almost like 100% exposure rate because if the new version fails,
all the customers get impacted.
And so what they wanted to do was then move to Canary
where instead of flipping the switch,
they would just deploy a 5% of traffic,
and they'd just sit back and watch and check logs
and look at monitoring to make sure everything was good,
and then they'd deploy a 20%, and then 50%, and then gradually until they're at 100%.
So Canaries are almost as fashionable as microservices these days when it comes to deployment.
But it's a really good way to minimize the business impact during a deployment.
Let me ask you a question, Steve, about the Canary deployments.
What do you say, and this has nothing to do necessarily with your role in your business,
but a lot of people probably think, oh, Canary deployments are great, but we're not Amazon,
right?
People kind of really just associate that with these really large-scale deployment operations.
But obviously, this whole concept is picking up steam.
How would you address that pushback to somebody?
It has nothing to do with the underlying technology.
You have a business.
Do you want to expose a new release to 100% of your users?
Or do you want to test it on a small percentage of your users, make sure it's successful, and then deploy it to the rest of your users and customers. And it's kind of like, there's obviously a link to A-B testing
and feature flags and things like that.
But if you want to test innovation, test it on a small sample size.
And then if it goes well, then incrementally roll it out.
It's not just about cloud-native architectures
or those types of customers like Netflix or Google or Facebook.
If your business is online, and most customers' businesses are these days, like, it's about managing risk.
And you manage risk and less bad things happen.
Or when bad things do happen, they don't impact as many customers or users as it would have happened in the past.
But obviously, I think it sounds easier.
That's two Canary releases.
And you said you don't have to be an Amazon or a Netflix.
But still, obviously, the architects that build the software, you have to architect correctly so that you can do things like only pointing certain traffic to
to the canary because it just doesn't work with any type of application that has
has not been built with canary releases in mind or am i mistaken here
yeah so i mean the sort of i mean what we do is we we have native integration with load balancers
so if you've got f5 or using amazon elb um we we kind of hook into the load balancers. So if you've got F5 or you're using Amazon ELB, we kind of hook into the load balancers.
And so, again, standard APIs allow us to communicate
and direct traffic to clusters and things like that.
So I think APIs exist.
How you stitch together those APIs,
so how you manage your load balancer
with the telemetry you get from your monitoring tools
to verify that the first one of the canary is good right i'm going to move to phase two and
flip the load balancer and and direct it to more traffic like how you synchronize those things is
is i think like that's that's doable today and you might have scripted it yourself the last three or four years but for
a vendor like harness we we treat load balancers as a first-class citizen almost hopefully the
police is not coming for you it sounds like you have a lot of activity in the background there
maybe a release gone bad yeah the release police that's an awesome release police um so i love your your continuous
uh validation um and remind me did i get this right continuous verification validation okay
so what we've been talking about and this is something that i've been doing in the last couple
of weeks uh trying to kind of implement also, I call them build
verifications. So, hey, Nanotrace, I'm pushing a build through the pipeline and tell me what you
think about that build by looking at key metrics and comparing it with the previous builds or maybe
with something that is in production right now and then basically act as a quality gate along
the pipeline to stop the pipeline, they're pushing back or promoted into the next stage.
And this is also thanks to your team, stuff that you guys built,
pulling in Dynatrace metrics.
And what I really love about, it seems we have a similar approach to this,
is that we are strong believers in configuration as code,
and not only configuration as in infrastructure as code,
where we basically define what type of infrastructure we need
but basically everything is code
or everything is configuration.
And we've seen this obviously from a pipeline perspective
with, I think, not sure who was the first one
that came up with a pipeline definition as code
but I know Jenkins with their Jenkins 2.0
with their pipeline,
you can configure the pipeline as configuration
and you store it in your Git repository
or in your version control.
And you guys do the same thing, right?
You basically give all the power
to whoever owns the pipeline,
to the administrator,
and everything can be configured through YAML,
I believe in your case,
including the quality gates
and everything that you do underneath the hood.
Is this correct?
Yeah, everything.
I mean, it's fine having a beautiful and a sexy, simple UI,
but I think to get continuous delivery to scale
and to make it kind of adopt it
is really about allowing you to do everything as code.
And so, yeah, there's a full YAML API.
So you could literally just write an entire pipeline, a canary workflow, a verification, a rollback.
You can define all of that as code.
It all gets version controlled.
You can create templates.
You can give it to different teams.
That's the genesis of why we did configuration as code.
Cool.
Now, do you have any suggestions for – I mean, I saw one of your blog posts where you were comparing Jenkins to Harness.
And I thought that was really interesting because you said – and as you mentioned earlier, Jenkins for you is CI, and you take the artifact that drops out of CI, and then you are basically continuing with continuous delivery.
And Jenkins for you is a first-class citizen.
Now, do you have suggestions or what are the first steps when you approach somebody that is kind of on the verge of what we do?
We do continuous integration, and now we want to go to continuous delivery.
And maybe they already started down the path of implementing something for themselves like deployment tools and orchestration tools or scripts.
What do you typically tell them to convince them that, you know, it's great that you're moving down the path, but maybe you want to stop investing in your own, build your own,
but look at something that is available.
What are the first steps to kind of get them confident enough
that the stuff that is out there ready for vendors is good enough
and ready for prime time?
Yeah, I think customers and real stories about how customers are using it.
Like any vendor can come up with a great story or a pitch or buzzwords,
but like real customer stories of how it's being used.
And the reality is no single vendor takes all in continuous delivery or any market.
CICD is a buzzword that I think is being bundled together.
And as I kind of mentioned mentioned it we see it as two
different disciplines um all our customers use jenkins um harness uses jenkins um and
while we're playing it is very different um sure you can go and build your own cd
platform in jenkins but you're building it Like you still have to write the shell scripts. You
have to, Jenkins, all Jenkins is doing is orchestrating the scripts that you write.
And so you have to build a canary workflow. You have to build a verification, the integrations
with, with Dynatrace or Splunk. Um, you have to script the rollbacks. Um, and so like that,
that becomes a question of, do you want becomes a question of do you want to build it
or do you want to take it as a service?
And so for us, it's about speed.
We think we can get a customer up and running in a few hours,
and that's very, very different.
We had one customer that kind of asked the question,
how are you different to Jenkins?
And my first question back to them was
how long did it take you to build your cd platform and the response i got was we're still building it
and and it's no different to monitoring right if you're going to build your own monitoring
platform like how long does it take to build or you could sign up at dynatrace.com download an
agent and in 10 minutes you can see your application instrumented.
It's about speed.
And that's the same thing, right?
We think we can deliver value very, very quickly.
And the proofs in the pudding these days with products,
people don't believe what vendors say.
They go and test the product themselves,
and that's the way it should be yeah
and i think to to add to this how fast we can you know both of our companies can help our customers
see the value it's not only the how fast do we get there versus building it your yourself but
also the maintainability i think you mentioned this as well in the beginning right if you build
it your own then not only you have to build, but you also have to put effort in maintaining it.
And maintaining means you have to maintain an environment that is constantly challenged with new technologies that it has to support.
I mean, we at Dynatrace, we built our own pipelines, obviously leveraging some of the tools that are available.
But in the end, we built a lot of the stuff ourselves because when we started, there was simply nothing available.
So we had to build it ourselves.
Will we do it again?
Probably not because now the tools are much more mature out there.
So I think this is another aspect that people have to think about,
how to maintain it.
And in the end, it comes down to what we said earlier.
You know, you in the end, you want to benefit your business. And your business is, if you're in the end, it comes down to what we said earlier. You know, you in the end,
you want to benefit your business. And your business is if you're in the tool business,
then yes, stay there. But if you're not in the tool business, then probably you should focus
on something else. And I would add to Andy that a lot of these tools, you know, ours and harness
and most of the new tools these days have a very rich API interface, both inbound and outbound. And if you want to take the effort that you would be putting into developing your own tools
and instead put that effort into saying, hey, I have an API here.
What can I do creatively to interface and enhance these tools or share the knowledge
if it's not something that a lot of us, we build integrations just as Steve and his team did with us. But there's still so many things you can do with these API interfaces.
Put your creativity there if you're going to spend some time trying to do some of your own coding.
Yeah, I mean, the APIs that you built on Dynatrace, I mean, I think it took our developers
like two days. And that was a complete automation between deployment pipelines
and deployment verification.
And there's a bunch of other stuff we could do as well.
And the kind of possibilities are almost somewhat endless because I think in the past 10 years,
a lot of DevOps vendors were trying to be the single tool or grab the mindshare or be the single pane
of glass or be the the kind of control plan of everything in the devops ecosystem actually the
power is when you link them together yeah and you let the products do what they do or they were
designed to do well and you have a best of breed ecosystem that plays nice with one another.
And I mean, for us to go back to a customer and was like,
hey, you asked for Dynatrace and a few weeks later, here it is.
Like that was unheard of in the last five or six years, right?
You'd have to get engineering teams to speak to one another and then prioritize it in the roadmaps.
Or you could just publish an API and say, there you go, do it yourself.
Yeah, no, that's really fantastic no no and and again kudos to your teams and and thanks to our api teams that were
they kind of foresaw what type of apis were needed for these integration scenarios now i have two
more questions for you the first question is where does continuous delivery end? That means you said
you deliver into production and then you validate and make sure that everything is working correctly,
otherwise you're scaling back or going back to the previous, take out the canary. But where does
it really end? Meaning, when is your pipeline green? Can you explain that to me? Because the reason why I'm asking is,
does self-healing fit into CD as well?
Something that in case something in an hour
and a day happens,
is this something that you see in continuous delivery
or is this a separate activity?
I think it's linked.
So we have two things.
One is, I'd say, where does continuous delivery end?
I think it ends with a verification in production.
So what is success for production?
And a big thing that I think a lot of customers need to do is,
what is a successful deployment?
And almost right down on a whiteboard,
what are the things that need to happen for a deployment to be successful?
And so business KPIs, application KPIs, customer KPIs, like how do
you know whether things are green or things are red? And that's the first thing. The second thing
is we have something called a failure strategy. And so if things do fail or the verification fails,
how do you handle that? And so the self-healing part of continuous delivery i think it's linked right it's like
something's bad's happening or the deployment's failing now what do i do and having apis to almost
orchestrate whether it's a rollback whether it's just manually notifying someone or even if it's
running a script or it's communicating with another another tool to self-heal. I think it's all linked.
I don't think continuous delivery stops.
I think you should always look at what was this, like,
are my deployments getting better?
Like, is the business getting better or is it getting worse?
Are things the same?
I think, as the name implies, right, it's continuous.
And until things are peaked or plateaued, I think, as the name implies, it's continuous.
And until things are peaked or plateaued, you've always got work to do.
So I guess it's two things.
What is success?
And if things fail, how do we handle it and recover from that failure?
Cool.
And the second question that I have, and we see, so we just came out of our Perform conference and we had a couple of big partners there.
For instance, Red Hat was there where we were partnering with them on OpenShift.
We also had Pivotal there.
And obviously, these are all partners of ours that are selling their platforms to their joint customers and uh and their platforms also include at least best practices on how to do continuous delivery are you guys
also playing uh with these platforms even knowing that from looking at pivotal for instance i think
they have concourse asse as their pipeline tool.
Yeah.
Is this something that you also integrate with
or that you think of integrating with?
Because obviously you have a lot of expertise in that area.
Yes.
So right now we're actually building support
for Pivotal Cloud Foundry and OpenShift.
So yes is the short answer.
Again, a lot of the platform as a service providers
do provide some kind of deployment APIs
and kind of tooling.
Where we're really playing is to keep deployment consistent,
right, across the different clouds,
across the different applications.
Similar to what Dynatrace does, right, where you want the same monitoring tool consistent right across the different clouds across the different applications similar to
what dynatrace does right where you want the same monitoring tool across the different clouds and
the different applications some customers might use a certain tool in one environment
but on the whole they want a standardized approach for deployment or they want a standardized
approach for monitoring and in a lot of aspects as well, enterprises,
they don't put their eggs in one basket.
And so they'll always pick at least one or two vendors
or solutions in each area so that they're not tied down.
So we complement, but again,
different cloud providers have different tooling.
So as another example, we have support for AWS CodeDeploy.
So if you're already using CodeDeploy to do deployments,
you can simply wrap Harness around that,
and then we can add all of the additional things like verification
and secrets management and rollback as part of it as well.
So, yeah, we'll integrate where we can for sure.
Yeah.
Perfect.
Brian, shall we start the summer razor?
It's been a long time.
Hi, Andy.
Shall we summon the summer raider?
Let's do it.
Let's summon the summer raider.
And we also have to do the Release Police.
That's a new song
by Cheap Trick.
They're going to come back
and...
So what I took away from
this session today, I believe
we are beyond
the time where we all
need to build our own tooling
to solve the same problem the 500th time
even though we've been we've been obviously glorifying the people that have done this on
stage at different events i think we are past that and we should focus on what the real the real
thing is what why we go to work every day which is building building better services for our
customers and delivering that service faster than our competition.
So maybe a challenge for people out there,
next time when you are proposing a talk to one of the DevOps conferences
or any other conferences out there,
don't try to show them what cool things you built,
but actually what the underlying business benefit is that you achieved
and what the investment was.
I think that's a cool thing.
Now, I also learned a lot about the difference between CI, CD, and how long, where CD kind
of ends.
I really like, Stephen, what you guys built at Harness.
Thanks for building the integration with Dynatrace.
And I'm sure we will obviously continue sharpening that integration.
We had a discussion last week,
and I know there's a lot of other use cases
we would love to implement.
So please also forward also the thanks to your team
that built it, and thanks for the feedback.
Yeah, but other than that, I think we are finally
at a stage where we can really say another problem most likely solved.
We may make things like monitoring and continuous delivery available to the masses
because we focus on that.
And so you guys can focus on the stuff that is really important,
which is building better services for your end users.
That's it from my side.
Excellent, Andy.
The only thing I want to add is that, you know, although I did, I feel like I was coming down hard on anybody who's attempting to build their own.
I don't mean it in that way.
You know, you can roll your own all you want.
You're not, probably not this unicorn you might think you are.
And I think you really should take a look at what tools are out there because you can save a lot of time. However, I do think it is still important though,
for people to look at maybe not recreating the same things that have been created before,
but we still need those innovators. Obviously as, as when we had, you know, I, I, and I think the
APM wars are still going on, right. But as the APM wars were going on, that pushed us all, the companies at least, to innovate more.
I think with the new things like maybe Harness and other companies going after the same thing, they will do some innovation, obviously.
That's just part of business.
But I still think we need regular people looking at what's out there and instead of trying to recreate what's already been done
find something new or find some find a gap because that's how all this stuff started in the first
place um so again going back to if i can go back two performs ago when i don't know if you recall
andy when josh mckinty was talking about um you know oh what's uh internet 3.0 or whatever it's
like when i don't have to care about it like when I don't have to care about it anymore, when I don't even have to think about it anymore. Same thing with the tooling kind of idea.
Like if I need to get into a CD situation, I don't care how it's done, make that done. So I can
continue with what I need to do. Um, let's let that happen. I think it's time. I think we're,
we're past the early adopters in this and it's time to move on with what we can move on and spend time either
innovating with new ideas or as i was saying innovate with how we can make these different
tools talk to each other and do cool things via their apis um steve any any last thoughts on your
side any anything you want to get off your chest before we wrap up no i think i think the key thing for me is i think apis are driving the the integrations and
making the ecosystems more powerful um i i think that's the big thing when when you use apis everyone
wins the customer wins the partners win the vendors win um and i think building things on your own
later on down the line where you need to scale or you need to change things, it often becomes very, very difficult.
And so a little bit of research before you build stuff sometimes can pay a bit of dividend.
And pick the right solution.
It doesn't have to be buying it.
It can be building it, but just pick the right solution for the right problem.
Right.
What's your end goal? Yeah. Excellent. Well, thank you very much, Steve. it you can be building it but just pick the right solution for the right problem right what's what's
your end goal yeah excellent well thank you very much steve we really appreciate you coming on
um you have uh i guess you're obviously on twitter um what's your twitter handle burton says
but it says there you go and uh any you have your blog on harness.io um any other plugs you want to go ahead and i'm still figuring out
whether i need to get a superhero costume like i'm thinking like if you're a guy in evil canary
or something like that so if you've got any ideas let me know we did not want to mention
head man on purpose but now you brought it up so i just said a canary costume. I didn't say you like the cosplay.
That's all right.
Who doesn't?
I mean,
if you want to,
honestly,
if you haven't tried it,
you've got to get a superhero costume.
It's,
it's,
it's one of life's hidden secrets,
but you know,
there's also the whole furries movement too.
That's a whole different topic.
That's got nothing to do with this.
Taking it way too far.
Yeah.
But I can't, I can't encourage it enough.
Excellent.
Anything else from you, Andy?
No, not really.
Just thanks again for this great partnership.
And if any topics come up in the future that we should enlighten our listeners, then just let us know.
We will be happy to have you back on the show. And for everybody else out there that is listening,
if you have any topics or if you want to challenge the stuff that we say here,
because you say, well, these are just two tool vendors
that are just trying to sell their tools,
then happy to take you on the show and then let's discuss this.
Yes.
And I'd also love for anybody to come up with a cover version of Release Police
done to Cheap Trickstream Police.
Please send that over if you can create one for us.
Perfect.
Anyway, thank you all.
All right.
Thank you.
Bye.
Bye.