KubeCon 2023: Consistent Enterprise Deployments

Speaker 1: This is Techstrong TV.

Step 1 of 7

14%

Which of the following best describes how you currently monitor and manage systems across your hybrid cloud environment?(Required)

Multiple separate tools for different environments

Multiple separate tools for different monitoring and management functions

Single consolidated dashboard

Custom built monitoring and management solution

No full monitoring and management solution

Don’t know

How valuable would it be for your monitoring and management solution to incorporate predictive analytics to help you identify and address system issues that are critical and not waste time or effort working through all the data and “noise” that is not critical?(Required)

Extremely valuable

Moderately valuable

Somewhat valuable

Slightly valuable

Not valuable

How do you most typically address potential system issues BEFORE they impact your operations?(Required)

Automated workflows and playbooks to remediate potential issues as soon as they are detected

An orchestrated response process that leverages automation, AI, and human expertise to rapidly respond to potential issues

Advanced monitoring tools such as predictive analytics and anomaly detection to proactively identify and address potential issues

Respond to issues as they arise, using manual processes and troubleshooting techniques

A combination of automated remediation, orchestrated response, and/or proactive monitoring to address potential system issues

Don’t know

Other

What methods does your organization use to control and monitor cloud/IT spending?(Required)

Centralized procurement processes

Pre-approved budget thresholds

Automated cost monitoring tools

Department-level spending controls

Regular cost audits and reviews

Cloud cost optimization platform

Approval workflows for resource provisioning

Native financial operations tools provided by the cloud provider

No formal controls in place

Don’t know

Other

Please specify:

Which methods do you rely on most to detect security vulnerabilities in your systems?(Required)

Automated scanning tools

Manual assessments

Vendor notifications

Threat modeling (for early detection)

None of these

Don’t know

Other

Please specify:

What are the TWO most common ways you prioritize vulnerabilities to address within your environment?(Required)

Based on potential impact

Based on exploitability

Regulatory compliance requirements

Based on CVSS scores

Risk-based analysis of multiple factors

First-in-first-out approach

No formal prioritization process

Don’t know

How do you typically handle system updates and security patches?(Required)

Automated updates and patches

Manually review and apply updates and patches on a regular schedule

A combination of automation and manual review

Apply updates and patches on an as-needed basis.

Outsourced update and patch management

No defined process

Don’t know

Other

Δ

Alan Shimel: Hey, everyone. We’re back here, we’re live in Chicago at KubeCon, continuing our day two coverage here at KubeCon. We’re going to be here the rest of today, and I think we go until about 2:00 tomorrow afternoon. And then that’ll put a wrap on KubeCon North America 2023. I wanted to introduce you to, well, you’ve been on Techstrong TV, but I don’t think we’ve ever been live at an event before. Paul Stovell. Paul is the founder, CEO of Octopus Deploy, correct?

Paul Stovell: That’s right.

Alan Shimel: All right. Paul, first of all, welcome.

Paul Stovell: Thank you.

Alan Shimel: And look, I know flying here, I’ve flown to Australia, I can only imagine flying from Australia. There’s a bit of a jet lag going on there, right?

Paul Stovell: It is.

Alan Shimel: Yep. Did you fly nonstop Chicago to here, or…

Paul Stovell: No, so we get direct flights to LA or San Francisco, so you pick one of those, and then you wait usually for delayed flights and so on, and then it is about 20 hours round trip.

Alan Shimel: So they do have… Actually it is, I guess, it’s San Francisco is nonstop to Sydney or whatever.

Paul Stovell: Yeah.

Alan Shimel: I’m trying to think. I thought there was a nonstop out of Newark Airport, but that wouldn’t do you any good anyway.

Paul Stovell: No, not quite on the way.

Alan Shimel: Newark.

Paul Stovell: Yeah, and that’s a very long flight. That’s like 20 hours I think. Yeah.

Alan Shimel: I’ve taken that flight. I know, yeah. Well, there’s two. There’s the one from Newark to Australia, and then there’s another one, Newark to Sydney, or not, to Singapore. Well, it used to go over the top, but with the wars and everything, it doesn’t even go over the top anymore. That’s a long flight too.

Paul Stovell: I think, if you haven’t flown to Australia, it’s a good way to just say, “Okay, now I’ve flown to Australia, everything else is short.” You can go, “New York to London is long.” It’s not.

Alan Shimel: [inaudible 00:01:59] That’s what we say now. So we’re based in Florida, and we’ll fly from Florida to, let’s say, San Francisco. It’s about five and a half hours. Now for some people, that’s all day for them. If you’ve done the Australian flight, it’s a walk in the park.

Paul Stovell: Yeah.

Alan Shimel: Walk in the park.

Paul Stovell: Makes it easy.

Alan Shimel: Anyway, enough about our flights. Let’s talk about you and Octopus Deploy. Paul, before we get in Octopus Deploy, let’s talk a little bit about your background.

Paul Stovell: Yeah, so, I think, our technical developer started Octopus back in 2012 as a hobby project, nights and weekends.

Alan Shimel: You remember?

Paul Stovell: Turned it into a business, and we bootstrapped it. So different to a lot of companies here, a lot of companies in the DevOps space, in particular, heavily venture backed, round after round of fundraising. We took a very different path. Bootstrapped, profitable all along the way, and we are here, and we’re about 200 people spread around the world. A lot of folks here in the U.S, and then Australia, New Zealand, UK as well. Yeah.

Alan Shimel: Excellent. You mentioned DevOps, but what exactly does Octopus Deploy do?

Paul Stovell: Yeah, the best way to think about us is, if you imagine the DevOps infinity circle, and all the stages along that. So there’s a lot of companies that try and do all of it at some basic level of depth. So you take GitHub, GitLab, trying to do every part of those stages. We think generally, in most companies, especially in enterprises, a lot of those things that solve problems, except how they deliver and deploy software. So for the last 10 years, that’s where we’ve focused on, that’s where all of our energy goes. So helping enterprises to release, deploy, operate software at scale, particularly for the really complex deployments, those sort of deployments that the end-to-end tools, they’re going to help you deploy a web app to dev test production. But once you start deploying to remote sites all around the world, once you start having hundreds and hundreds of project teams trying to do deployments consistently within an enterprise, that’s ours. That’s our cup of tea.

Alan Shimel: Love it. Just before we start the next thing, for people who want to get more information on Octopus Deploy, the website?

Paul Stovell: Octopus.com.

Alan Shimel: Octopus.com. I love it. Okay. Now let’s talk turkey a little bit, as we say here, right? Look, this is my, I don’t know sixth, seventh KubeCon. The fact of the matter is it’s technically CloudNativeCon, KubeCon/CloudNativeCon, and I think that was recognition that KubeCon was kind of the king of the hill. Kubernetes was king of the hill. To many people, Cloud Native is synonymous with Kubernetes. But if you’re involved in this community, you know now that Argo, OpenTelemetry, Prometheus, I forget, what is there, 140 something programs in CNCF?

Paul Stovell: Stages, yeah.

Alan Shimel: It’s not just Kubernetes anymore. Don’t shoot me, but some people are saying maybe Kubernetes isn’t all that anymore. Maybe it’s always been rather hard. And there are some fundamental issues around building your whole architecture around this. And I’m not saying Kubernetes is going away, I’m not saying it’s a failure. I’m just saying people are beginning maybe see some of the warts, if you will, around Kubernetes. And talking to people at the show, there are certain subjects or areas that they want to see movement on, progress, evolution, modernization. I’m wondering what are the kinds of things you guys see at Octopus around this?

Paul Stovell: I think we are in a fortunate position because we help customers with Kubernetes, other cloud native things, serverless, et cetera, across all the clouds and the on-prem stuff as well, and the VMs and the data centers that they’ve built up over time. And so we’ve sort of watched this play out where you start to talk to companies a few years ago and it’s like, “Yeah, we’re doing Kubernetes. There’s a team somewhere, and they’re experimenting with it and we think we might standardize on it because there’s something quite enticing about the idea of everything we do as a container. We’ve got one technology stack to learn. Yes, it’s very complicated, but it’s going to become the standard within our company.” But then when you talk to them also and you ask about where does AWS Lambdas fit in? Where do Azure websites fit in? There’s often space for those as well when they think about what does the future look like?

So there’s definitely a future technology stack for companies that is more than just Kubernetes. And then of course big enterprises, they’ll have virtual machines for a really long time as well. I think one of the challenges is when you think about, because the fundamental architectural layer of where the software is running is changing, that doesn’t change every year. Technology moves fast, but virtual machines, we’ve been doing that for a really long time, and now if we start to run things in containers on Kubernetes, that’s going to be something we do for a really long time. And the challenge there is a lot of the tooling that may have worked for one, that when you change that thing at the very bottom of the stack, everything else on top kind of has to find its place in the new world and maybe it makes it, maybe it doesn’t. I think when it comes to software delivery, one of the things I think they’re finding is that there’s a lot of tooling that’s sort of rediscovering stuff that was discovered a long time ago.

So a great example, when we talk to folks using Argo, they’ll say, “We love Argo, we love using GitOps.” And then you talk to them in a bit more detail and it’s like, “But it’s really hard to do dev test production stages. The scaling is something that we are struggling with. It works for the Kubernetes part. But actually when you ask them, “What’s your real deployment process?” It’s like, “Well, I send an email, I do a thing in service now, then I change the thing in YAML then I do some database schema migrations, I call an API.” There’s an orchestration that exists outside of that. And I think in purely a cloud native community world, the answer is, well, let’s reinvent all that with a K in front. But there’s I think particularly where we focus on the kind of more human elements of how software is delivered, but we find we deploy to Kubernetes just as easily as we deploy to other things, and it works really well.

Alan Shimel: Agreed. I want to peel back the onion a little bit on multi-tenancy and stuff because that’s not a problem we hear a lot about, but it’s nevertheless a problem. And let me just further refine that. When I talk about multi-tenancy, it’s not only, it’s multi-homed as well. The whole idea… Let me give you a little of my history. 2000, friends of mine were starting a company because we saw that eventually applications were going to be distributed. This is before modern containers, it’s even before really the cloud.

But we knew that applications were going to be distributed multi-homes in different data centers around the world but connected, and that you had to develop management platforms that were going to allow you to manage these multi-home distributed applications. We named that company Lattice Networks, failed miserably. We were way ahead of our time. We wound up taking what was a little security piece we had developed for it and became a security company, that’s my start. But that world lives now 20 years later, 24 years later, right? And that’s kind of the world you are talking about too.

Paul Stovell: I think there’s two parts, but I think you’re right. I think there was a period where is the cloud going to be a place that real enterprises run software? That’s been settled, right?

Alan Shimel: Absolutely.

Paul Stovell: Of course they do. And then it was, you would see a lot of announcements of like, this car manufacturer is going all in on cloud A, and then of course six months later, they acquire a company that went all in on cloud B. And so in every one of these enterprises, they have every one of the clouds. And in some ways that’s intentional because they want the ability to move between and kind of make the best of all of the clouds that they’re in. And in other ways it’s purely accidental as happens in enterprises. So there’s that software delivery challenge. I think there’s another one which is, when you ask a customer, “Okay, you’ve got some software and describe to us what it does.” And then you say, “What happens when you get a new customer? What happens there?”

And if they say, “Well, the new customer signs up on the website, Aero goes into the database and everything just kind of does its thing.” Okay, the way you’ve designed that application is the software understands the nature that there’s more than one customer. So you think of an accounting system, a new company signs up, they get their own space in the database, but it’s one application. But there’s a very different class of that, which is when a new customer signs up or we open a new site, we open a new restaurant or a new hospital, something like that, then someone drives out and they install some hardware and they do a bunch of things.

Or there’s in the cloud, in a SaaS product, there’s when a new customer signs up, we provision infrastructure for them. And once upon a time, I think the idea that a new customer signs up and we are going to provision infrastructure, I mean, that’s crazy talk because that meant we’re going to phone Dell. We’re going to wait a bunch of time for something to come. We’re going to figure out how to rack mount it, find power for it. So no one did that. But then architecturally, I think Kubernetes has changed a lot of that because Kubernetes provides a lot of that density and it simplifies the software layer. And so there’s a lot of reasons to do multi-tenancy kind of in a Kubernetes native way. And so we focus a lot on those kinds of deployments as well.

Alan Shimel: That’s your spot.

Paul Stovell: Yeah.

Alan Shimel: Excellent. What else is happening with the company?

Paul Stovell: We are very focused right now on two big things. Obviously continuing the multi-tenancy thing. We were at Multi-TenancyCon that was here yesterday, run for the first time.

Alan Shimel: Yesterday or Monday.

Paul Stovell: Oh, sorry, Monday. Yes.

Alan Shimel: I know, that’s the jet lag.

Paul Stovell: I’m on Australian timestamp.

Alan Shimel: I got you.

Paul Stovell: And then we talked about multi-tenancy. The focus there, we are doing a lot of work on doing that at scale. So our customers keep scaling tens of thousands of tenants, infrastructure there to point to, so we are working a lot on that. The other part, of course, is Kubernetes and in particular how we help customers go from doing GitOps. And it works okay for operations workloads, but the jigsaw puzzle doesn’t work with CD. I’m changing a line in YAML about what image I’m running, but what Jira tickets were solved as part of that? What source code commits went in? How did it go between dev test and prod? Am I really deploying the same thing?

So we are very focused on that. We shipped a lot of things recently around integrations with things like customize and being able to see the live status of Kubernetes objects as we’re deploying them. And the powerful thing there is particularly, we talk a lot about platform engineering, and I think the challenge is Kubernetes, like you said, is so complicated that people are trying to set up these platform teams that are going to tackle the complexity of platform engineering. So our app developers can just build an app and ship it somewhere, and we are very focused on helping make that work and make it work really well. Yeah.

Alan Shimel: Love it. Octopus.com, we got to leave him with that. Paul, first of all, I appreciate you, man, making the long flight here, having done the flight. But more than that, I hope you enjoyed KubeCon and we’ll see you on Techstrong TV where it’s a little bit easier for you on the hours.

Paul Stovell: Sounds good.

Alan Shimel: But keep doing what you’re doing, man. We appreciate it.

Paul Stovell: Thank you. Cheers.

Alan Shimel: All right. Octopus deploy here live at KubeCon in Chicago. We are going to take a break and we’ll be right back.