Transcript

Mitch Ashley: Hi, everyone. This is Mitch Ashley with devopsy.kinsta.cloud, and you’re listening to another DevOps Chat. Today, I’m joined by CTO Bernard Sanders from CloudBolt. Our topic today is DevOps for hybrid and multi-cloud environments. Bernard, welcome to DevOps Chat.

Bernard Sanders: Thanks, Mitch. Great to be here.

Ashley: Super good to have you on the podcast. Would you start out by introducing yourself? Tell us a little bit about you and also a little bit about CloudBolt.

Sanders: Sure. So, I’m Bernard, CTO and co-founder of CloudBolt, and spent most of my career in the data center automation/DevOps/cloud management space as it’s been known throughout various eras, you know, since 2000 when I started in the industry. And I’ve gotten to see a lot of different enterprise IT shops and how they work—what goes well, what goes wrong. I spent a lot of time in IT shops and the financial services industry and in retail and government, and it’s been interesting seeing the commonalities between these.

And it was through an observation of those commonalities and talking with a colleague of mine, Augie, that we decided to start CloudBolt software in 2011 and started working on the software, put out first GA release that year. And CloudBolt is a hybrid cloud management platform, sometimes called a CMP. It essentially helps large organizations who have a data center presence and also want to use the public cloud. It helps them consume both from a single interface.

Ashley: Cool. Well, first of all, I have to compliment you—anybody with a buddy named Augie has to be a good person.

Sanders: [Laughter]

Ashley: Augie sounds like a great guy. [Laughter] So, this was like, sort of from your garage, kinda from the basement type of startup that you two started it originally and got this company rolling?

Sanders: That was basically it. We did have a leg up in that we were working for a consulting company at the time based out of Washington, D.C. named August Schell, and we spun this company out of August Schell. So, starting up, the two of us and the others we brought on were able to focus on the technology and the solution and going and getting some customers, and we didn’t have to worry so much about the back office stuff—the HR, payroll. We piggybacked on our parent company’s infrastructure for a lot of that, so—

Ashley: Nice. So, kind of a spinout or bootstrap off of the parent.

Sanders: Exactly, yep.

Ashley: Very nice. Alright, well, you know, not everybody gets to start out doing cloud applications in a cloud-native format, or even just within one cloud. You know, oftentimes, we’re saddled with complexity, we’re saddled with the existing applications—I don’t mean it in a bad way, it’s just the reality of the business—or we’re part of a digital transformation moving to the cloud, which is sort of where we get these hybrid and multi-cloud environments.

What are some of the challenges that you saw that set you about, “Let’s go start this company, build this cloud management platform.”

Sanders: Yeah, yeah. So, there’s a couple areas to discuss there, you know, the first of which you touched on is that not everybody gets the luxury of starting greenfield. You know, if you’re starting a brand new software company with a few people and a few needs for servers, you could start entirely containerized, serverless with the latest technology. But so many companies we talk with, still ask us, “Oh, do you support mainframes? Do you support AIX, do you support HQX?” [Laughter] The answers to those questions are no, in our case, you know? We gotta draw the line somewhere. But there’s a very long tail of technology at these enterprise companies. There is a need for stability and continuity and they can’t just drop everything and move to the latest platform with all their applications.

Ashley: You know, I like to say generations of technologies never go away.

Sanders: That’s correct.

Ashley: There’s probably code I wrote when I got out of college, scary enough, if we think about that. But yeah, it is. You’ve got to adapt to what you have. We can’t rewrite everything.

Sanders: You know, your other part of your question was what problem did we see that inspired us to start CloudBolt, and what we were seeing, Augie and I, any time we went out to these large institutions is a breakdown in the communication between the IT department at a large company or organization and their end users.

Ashley: I’ve heard that happens, yeah. I’ve never seen that, but I’ve heard.

Sanders: [Laughter] Yeah. It just happens so much it’s almost a joke, but you know, end users will have to put in a ticket with IT if they wanna get a VM, either in their private data center or sometimes even in the public cloud. And then that IT group has to go do a lot of manual steps and there’s oftentimes a lot of hand offs between groups to eventually build that environment or that individual VM or network storage out and then get it back to the user. And it’s a black box and everybody gets frustrated with each other.

Ashley: Mm-hmm.

Sanders: We thought—there’s gotta be a better way to do this.

Ashley: So, how organizations can work together more effectively, let’s also tease apart both the multi-cloud and the hybrid aspect of this. So, multi-cloud, do you find that’s because things sort of start up on their own and different groups go out and somebody starts on Azure because they’re Microsoft code, and somebody starts out on Amazon or Google or wherever and then some day, somebody else says, “Why don’t we pull this together?” Or is it more of a conscious, “No, we need these different cloud environments for these good reasons, so let’s put together a cohesive strategy or architecture for how we go about that?” How do those things evolve?

Sanders: I think it’s both. I’d say it’s probably 60/40. A lot of times, it’ll be a company that says, “Oh, we’re all on Amazon.” Then they go acquire another company that does Azure and then another one that does something else. So, a lot of times, it’s that unintentional growth.

Ashley: Mm-hmm.

Sanders: But I think more and more, you’re seeing each of the cloud providers, they are diverging over time and they each have their own strengths and weaknesses. So it’s totally valid to say, “Hey, we’re gonna use Google Cloud for this one thing and we’re gonna use AWS for this other use case, because that’s where these platforms are strong.”

Ashley: Interesting, interesting. So, talk about the hybrid part of this. You know, whenever there’s a new generation or a new shiny object, it’s like, everything is gonna go there. So, everything is gonna go to the cloud, and of course, many things have and some things have fully and some things have just partially.

Sanders: Mm-hmm.

Ashley: And there’s always that need. You talked about mainframes, for example. There’s that need of having a hybrid environment. How do you define a hybrid environment?

Sanders: Yeah, so I define hybrid as using both a private cloud and a public cloud. So, private cloud meaning your own data center or, you know, maybe one that you colo or somehow rent out. But basically, your own gear, your own hardware and infrastructure, but also using the public cloud at the same time. And that—you know, I think that’s been one of the biggest about faces in the last five or six years is, if you went back five or six years ago, listening to a lot of the industry analysts, you would’ve thought that we’d be off public cloud, you know, a year or two later. Or we’d be off private—

Ashley: Of private, yeah.

Sanders: –and that would go totally extinct.

Ashley: Of course.

Sanders: And that we’d be completely on public cloud. But I think that was an unrealistic expectation. There was a Goldman Sachs study earlier this year that said 26% of workloads are in the public cloud. So, that leaves a huge portion that’s still a huge majority in the private environments.

There’s a growing need for hybrid, you know? People don’t want to use both totally disjointedly, they wanna use them together in some way. That’s what I would call hybrid cloud.

Ashley: That kinda sets the context for talking about this cloud management platform. Define that for us—what is a cloud management platform?

Sanders: Yeah, cloud management platform is a tool which can provide a single pane of glass or interface as well as API to manage disparate IT environments, and that can be public cloud, private cloud, containers, virtual machines, physical. It can include serverless, it can include public cloud services as well as basically any request you would make of IT. That’s what I would call a cloud management platform or CMP. The other main defining characteristic is, it needs to provide self-service to end users. It has to be a tool where end users can go and get what they want on their own rather than asking IT to do it for them.

Ashley: So, really, the ability for IT to manage its environment but also to provide portal access, if you will, if you thought about it that way, anywhere for people to do self-service, APIs, STKs, so DevOps groups can tie into the platform.

Sanders: Exactly. Yep.

Ashley: Okay. So, let’s go there. Let’s talk about how does DevOps fit into—IT wants to organize things, right? IT wants to get its hands around and be able to at least manage—you know, not necessarily control or constrain, but you know, they’re responsible for what’s happening in the organization with the technology and so, they want some form or semblance of management control over that.

How do you do that and, at the same time, let the DevOps groups thrive and flourish?

Sanders: That’s right. Yeah, so, really what it’s about is having the IT team, giving them a tool where they can set their policies, set the standards, but expose an interface, or multiple interfaces, to different departments or groups for those teams and DevOps folks within those teams to go get what they need when they need it and automate what they want on top of that base that IT has given to them.

So, in the case of most cloud management platforms, the IT group would bring it on, purchase it, get it installed and set up and then expose that UI and API out to these departments who can code against it. So, the DevOps team in a particular department, for example, might have a CI/CD pipeline that calls into the cloud management platform that’s exposed by IT.

So, both groups are empowered. IT gets to set the quotas and the approval process and the host name standards—like, everything policy related within that cloud management platform, and those end users and DevOps folks get to provision what they want when they want it.

Ashley: I don’t want to make it sound like a panacea, but it sounds like this would be a path for an IT organization who maybe has lost control or doesn’t feel like they have their arms around everything that’s happening in the organization and they can become sort of the provider of the cloud computing infrastructure resources.

Sanders: Absolutely.

Ashley: And this could be a path to them kind of getting in front of what’s happening instead of just being reactionary.

Sanders: Absolutely, yeah. The other effect that it has that we’ve seen, you know, CMPs have, whether it’s CloudBolt or a different one is that, you know, the private data center has lagged behind public cloud in terms of its interface. Like, going to the Amazon console or Google cloud, ordering a VM—it’s a pretty easy, fairly self-service process. It’s not that way with OpenStack or VMware and Nutanix. I know it was one of private virtualization systems people use.

Having a cloud management platform levels up your private data center to a level that’s similar to public cloud where people can do self-service in the private data center, not just the public cloud any more.

Ashley: Okay, so at risk of me sounding like I’m just happy ears and throwing you softballs—

Sanders: [Laughter]

Ashley: –what’s the hard part about implementing a CMP?

Sanders: [Laughter]

Ashley: It can’t be all roses and, “Here’s a credit card and download and—poof, your NPS scores shoot from 10 to 56.”

Sanders: Oh, can I only name one thing?

Ashley: Yeah. [Laughter] What are the challenges of getting from “life’s pretty tough” to, “we’re in a much better position now that we’ve gotten this platform in place”?

Sanders: Yeah. So, for folks who bring in a cloud management platform, I think the challenges are oftentimes less technical and more organizational, because it affects so many different groups. You have to get people’s buy-in that, “Hey, we’re gonna do this thing. We’re gonna use this as our common interface to IT.” And that can be challenging. I think it’s made easier if the interface is good and you make it attractive and appealing and powerful and give them what they need in that interface, people will come to it. But it can still be hard enacting any kind of a change within these large organizations.

Ashley: So, is it easier in a smaller organization, mid-sized or large? I can imagine maybe it’s easier in a large enterprise where you can sort of lay out standards and how you have a process for doing that or maybe mid-sized is tougher because it’s harder to herd the cats? I don’t know, what’s your experience?

Sanders: That’s a good question. I think, just generally, any time you get more humans together, it’s harder to make change and to get them all doing the same thing. And, yes, if you have executive buy-in in a large organization, that can make it easier, but I think it’s still basically always harder to move more people than it is to move fewer people to a new way of doing things.

Ashley: Okay. So, another, tougher question—why is CloudBolt better than the rest of the CMPs on the market? Why is it a better mouse trap?

Sanders: [Laughter] Good question. You know, I don’t do a lot of the competitive analysis myself, but what I’ve heard from our customers is that they can get CloudBolt installed and running and get value out of it much more quickly than other platforms. You know, we’ve done demos before where, by the end of the demo, you know, where in a GoToMeeting or a Zoom meeting or we’re showing the product to a customer and by the end, they’re asking us, “Oh, where’s the button for X?” We have to pause and say, “Wait, what’s going on over there?” In the time it’s taken it to demo it to them in half an hour—so, they’ve downloaded it, installed it, connected it to their VMware environment, they’re, like, provisioning VMs. It’s a pretty nice bar, I think, we’ve hit in terms of consumability. They also talk about the extensibility being very powerful.

We try to build all kinds of hook points and extension points, capabilities to let them extend it to do whatever they need it to. A lot of these IT shops have very specific requirements and systems and standards and ways they need things to operate, so they like that extensibility.

Ashley: Well, teams doing agile, DevOps teams, you know, they build an environment around them where they can execute quickly because they can get access to resources quickly, you can go to Amazon credit card—poof, I’ve got whatever. And it’s great to build that kind of process and that environment around them. Of course, we run into things that are gonna slow them down, like quote-unquote IT, or some new thing, the shiny new CMP kind of thing.

How do you get a DevOps team on board that’s been just fine going to Amazon and Google and Azure and whoever else to get what they need and now they need to go through this IT thingy that’s been placed in front of them?

Sanders: Yeah. I think, really, what you need to do is solve problems that they’ve got, and CMPs do that. You know, when they see one interface, one API that is consumable and up to their standards and allows them to deploy to any different cloud as well as the private data center, usually, it doesn’t take much more convincing than that. They say, “Wow, we were gonna have to build that,” because we were just given the mandate to do two different clouds or to do VMware plus Azure.

And now, we don’t have to do that ourselves—that’s great. We can build more functionality and just build on top of that great platform there.

Ashley: Can you come in and work with an existing either homegrown automation, or if they’ve built around some build and automation tools for deploying both code and to the cloud? Can you work with tools that a DevOps team has already set up, or do you have to kinda retool parts of what they’re doing?

Sanders: There’s usually very little retooling. There’s bidirectional integration that usually happens. You know, if somebody’s gotta build pipeline in Jenkins or Concourse, they’ll oftentimes have that start calling into CloudBolt to do those builds, and they can sometimes remove some of the complexity from their systems if they were calling directly into infrastructure to do that themselves.

And then, similarly, CloudBolt can call out into existing tools they’ve got. A lot of our customers have homegrown cloud management or change management databases, CMDBs, and they want CloudBolt at some point in the provisioning process to call into those to register a new server or CI in there.

Ashley: Mm-hmm. What’s the next thing that’s happening for you with your product and where you’re taking this?

Sanders: There’s a lot of things that are happening in the cloud management space, you know? The space is not too old, so it’s still defining itself, and the industry is still figuring out what they need in this kind of a tool. So, we have been introducing increased cost management and analytics to show you what your public cloud spend is and what you could save and give you recommendations on how to save. So, that’s a common area of improvement, continuing to make it more and more extensible and consumable, of course, doubling down on our containerization support, we started supporting Kubernetes in 2015 and we’re leveling that up in each of our releases.

And then, as well as supporting all of the different directions the public cloud providers are going, they’re trying to diverge; we’re trying to provide a common platform. So, that’s a constant challenge for us to solve and it’s a fun one and it’s one the engineering teams thrive off of to give people a common interface with increasingly different underlying technologies.

Ashley: I can imagine, obviously the more tool support that you provide for Kubernetes to Jenkins or whatever the next iteration of fantastic tools that are used in a DevOps environment, all the better. But also, if you’re solving, “Here’s log aggregation, here’s audit trails, here’s access controls that DevOps teams don’t have to set up,” that would be—and you can do it through a programmatic interface—that’s gonna be a win for them.

Sanders: Absolutely. Yeah, and security is an increasing focus for us as well, providing tools and integrations through which they can make sure every VM that’s deployed is up to standards and compliance and they can get security reports across their entire enterprise.

Ashley: Yeah, if you can help them sell through a security audit or review, they’re gonna love you, I would think.

Sanders: Yes.

Ashley: We could talk about this for another 40 minutes if we wanted to. Unfortunately, we don’t have that much time. I’d like to thank you, Bernard Sanders from CloudBolt, for joining us.

Sanders: Thanks, Mitch. It’s been really fun.

Ashley: And I’d like to thank our listeners, of course, for being with us today. This is Mitch Ashley with devopsy.kinsta.cloud. You’ve listened to another DevOps Chat, and be careful out there.

— Mitchell Ashley