Tag: CloudBolt

  • FinOps Gaining Ground, But Progress is Slow

    FinOps Gaining Ground, But Progress is Slow

    A CloudBolt Software survey found that while the majority (98%) of respondents worked for organizations with a formal FinOps team (82%) or are actively considering adding one (16%), realizing value from FinOps is slow. More than half of existing FinOps teams (54%) were formed just 12 months ago or less, the survey also found.

    The trouble is, only one in of 500 respondents claimed to achieve any material value from FinOps to date. More than three-quarters of respondents (76%) said they will have to wait two to three years to see real FinOps-driven results.

    The survey polled 500 executives, engineers and developers at companies with over 5,000 employees in the U.S., Canada, United Kingdom and Australia. It was conducted by Wakefield Research on behalf of CloudBolt Software, a provider of a platform for managing distributed computing environments.

    A total of 45% of respondents also questioned FinOps efficacy in the real world. Specifically, 15% flagged FinOps as being “theoretically easy but harder in practice,” with another 13% regarding it as “much ado about nothing.” Another 10% said it is “nothing more than a suggested framework,” while 7% labeled FinOps as “a necessary evil.”

    Nevertheless, a full 89% also described FinOps as the silver bullet for reining in the complexity of cloud cost management, with 68% noting that FinOps is among their organization’s most strategic priorities for 2023. The average size of a FinOps team is now 4.1 people, with the “director level” being the senior-most leader on the team 53% of the time, the survey noted.

    A total of 71% noted that achieving this year’s IT goals without a FinOps practice would pose a significant challenge, with 74% reporting that FinOps is now on par with ITOps, DevOps, SecOps and other IT disciplines.

    In addition, 71% of respondents said funding for FinOps initiatives increased in 2023, with 58% reporting key performance indicators (KPIs) and metrics to the C-suite or board of directors.

    CloudBolt Software CTO Kyle Campos said it’s clear that when it comes to reining in costs, large enterprises are struggling to effectively manage IT across multiple silos. In many cases, organizations were investing heavily in IT before and during the COVID-19 pandemic to drive digital business transformation initiatives without many cost controls being put in place, he added.

    Now that organizations are encountering economic headwinds, many chief financial officers are now asking IT leaders to be a lot more efficient, noted Campos.

    Developers, in particular, have for years been provisioning cloud infrastructure resources with little to no oversight. Unfortunately, developers are prone to leaving the proverbial lights on by, for example, leaving application development environments running over a weekend or simply forgetting that a virtual machine has been left to run for weeks—sometimes even months.

    Developers are also not especially good at alerting IT leaders of possible spikes in consumption due to, for example, a data-intensive workload being constructed. No finance team likes to be surprised by a monthly bill for a cloud service that is twice as much as the previous month.

    The one thing that is certain is that time is of the essence. FinOps, at its core, may not necessarily be a new idea, but IT organizations that fail to practice it may soon find themselves being held more accountable than any time in recent memory.

  • Orgs Shift Toward Centralizing Automation Initiatives

    Orgs Shift Toward Centralizing Automation Initiatives

    A survey published today found that 75% of respondents recognized that automation silos hamper their ability to unify cloud operations across functions.

    Conducted by CloudBolt Software, the survey polled 350 senior IT and DevOps leaders at organizations with more than 3,000 employees. On a positive note, the survey found 57% of respondents were starting to pursue a more centralized approach to automation, with a total of 88% acknowledging that having all previous and new automation centralized for the entire organization would ensure compliance, bolster security, enable business continuity, encourage reuse and reduce risk.

    Rather than taking a more holistic approach, well over half of respondents (57%) reported automation efforts are limited to specific silos. On average, organizations are employing 27 different automation tools their organizations have deployed, using one or a few as they see fit, with little to no consistency across teams. More than half (55%) of respondents said they have four or more separate automation teams, with 95% noting that each of those teams operates in their own silo.

    CloudBolt CTO Rick Kilcoyne said that lack of continuity clearly creates inefficiencies and redundancies that conspire to raise the total cost of IT. The challenge is that each team tends to favor one approach to automating a silo with little to no regard for a larger overall strategy to create an automation standard, he said.

    That approach also creates issues whenever a member of one of those teams leaves an organization, he noted. In fact, the survey found 77% of respondents reported that continuity is at risk any time a vital member of the team leaves.

    CloudBolt has been making a case for a federated automation platform that can be invoked either via application programming interfaces (APIs) or a graphical user interface (GUI) that provides access to low-code tools. The goal is to make the platform equally accessible to DevOps teams or IT administrators that tend to lack programming skills, and do so in a way that doesn’t require individual teams to replace their automation platform of choice. Instead, each of the automation platforms can be programmatically invoked via a central framework, said Kilcoyne. That approach eliminates any political debate over the potential need to replace one team’s favored automation platform with another, noted Kilcoyne.

    Regardless of who is accessing the platform, most organizations would be well-advised to develop a center of excellence for automation, he added.

    DevOps teams have always been committed to ruthlessly automating as many IT processes as possible, but in many cases, that has resulted in a plethora of automation tools being employed. In effect, automation may have become too much of a good thing. One approach to regaining control over those platforms is to create a platform engineering team that centralizes the management of DevOps workflows.

    Regardless of approach, Kilcoyne said the most important thing for any team to do before automating an IT workflow is to first understand how to manually set it up. Too many IT teams are trying to apply automation to processes they don’t really understand with mixed results, he added.

    The one thing that is certain, especially with the rise of artificial intelligence (AI), is the management of IT is going to become more automated.

  • Survey Illuminates Long Dark Road to Hybrid Cloud

    Survey Illuminates Long Dark Road to Hybrid Cloud

    While hybrid cloud computing will play a critical role in enabling digital business transformation it turns out most IT organizations lack the skills and technologies required to achieve it.

    A survey of 108 IT executives conducted by the research firm Pulse on behalf of CloudBolt Software, a provider of a cloud management platform, finds 94% believe hybrid cloud computing will be critical to digital transformation. A total of 92% also noted that empowering end users through self-service IT is a digital transformation accelerator, while 99% said successful automation depends on streamlining integrations.

    However, 78% of respondents said they lack the visibility necessary to optimize cloud deployments. More than half (56%) believe that their self-service offerings fail to meet user needs and more than three-quarters (76%) still rely on some form of custom coding when it comes to integration.

    In terms of the capabilities respondents are looking to acquire, 80% noted they want real-time insight into cost optimization and security remediation. A total of 71% want self-service to be easy for end users, while 62% want an approach to integration that doesn’t require deep domain knowledge or special expertise.

    CloudBolt CEO Jeff Kukowski said the biggest immediate obstacle when it comes to hybrid cloud computing is the lack of visibility IT organizations have into their existing IT environments. IT teams are not going to be able to unify the management of distributed IT environments without it, much less achieve anything approach observability, noted Kukowski.

    Pressure on IT organizations to accelerate application development while simultaneously reducing costs rose as the economic downturn brought on by the COVID-19 pandemic began. The challenge is that each new platform adopted by an organization tends to increase the total cost of IT as organization acquire tools and hire specialists to manage those platforms. It’s not likely all those platforms will be managed via a single console, but Kukowski said it’s clear IT organizations are moving toward a more federated approach that will enable them to centralize the management of IT.

    In the meantime, Kukowski noted organization are collectively wasting billions of dollars on IT platforms that are employed inefficiently. Most of that waste stems from either overprovisioning of IT infrastructure, or simply because someone didn’t think to turn off a virtual machine left running on a cloud service.

    It may be a while before IT organizations are able to strike that perfect balance between flexibility and control that currently remains elusive. However, organizations that focus on improving a few small things today will find themselves in a much better position to manage what is rapidly becoming an over extended enterprise tomorrow. Right now, Kukowski estimated only about a quarter of IT organizations have the sophistication required to manage a hybrid cloud computing environment.

    There’s no doubt the management of IT will become more automated in the months and years ahead. The challenge organizations face today is determining what tasks either can or soon will be automated. Once that’s determined, it becomes a lot easier to identify what DevOps skills those IT teams will require tomorrow.

  • How to Make Self-Service IT More Intelligent

    How to Make Self-Service IT More Intelligent

    It’s an old story: DevOps’ need for speed and agility clashes with IT’s need for security and control. Striking the right balance between control and agility is key to fostering a smooth relationship between DevOps and IT.

    Many enterprises have achieved this balance by implementing a self-service IT model. In a self-service environment, IT creates a pre-approved catalog of resources that developers and engineers can access themselves, regardless of where they are, through a single portal. These resources might include storage, compute, networking or multi-tier app stacks. Thus, DevOps can get the things they need on their own, when they need them, avoiding the IT bottleneck while IT still maintains control.

    This gives DevOps the speed and agility they want while allowing IT to maintain control. IT can place guardrails on resources, such as role-based access controls and permissions, usage quotas, cost controls, security and compliance measures. IT can also set up approval workflows to ensure visibility and management. DevOps increases efficiency and expedites time-to-market. They will also be much less likely to go around IT and procure the resources they want on their own, such as spinning up public cloud resources with a credit card. This kind of activity leads to unauthorized apps and resources running in the background without IT’s knowledge – otherwise known as shadow IT – which can create significant security vulnerabilities and cost overruns.

    So, the balance between DevOps and IT, the yin and yang of speed and control, is attained. All is well in the kingdom, right? Not exactly. While self-service IT is essential, it needs to grow more intelligent to remain effective.

    Hybrid cloud environments are changing rapidly. As helpful as most current self-service IT systems may be, a multi-cloud strategy will continue adding more layers of complexity to IT infrastructure management. While a prudent enterprise will automate as many cloud management processes as possible and have stringent guardrails in place to enforce cost and security policies, there is still plenty of room for things to go wrong when you have multiple engineering and development teams consuming cloud resources in a rapidly-changing environment.

    When various combinations of resources are provisioned in ways that IT didn’t foresee, or new tools are added that didn’t exist when existing policies were drafted, you have an environment that’s susceptible to misconfigurations and inadvertent security risks. Furthermore, tools and resources available to DevOps via the self-service portal may become outdated or not be as effective or useful as they once were. If IT hasn’t replaced or upgraded them yet, DevOps might still be tempted to go outside the system to get what they need.

    Staying on top of the evolving challenges in hybrid cloud management will require a new, more intelligent approach to self-service IT. This approach will further empower DevOps and assist IT by embedding greater awareness into decision-making processes across the organization.

    Say, for example, a developer writes a piece of code. Unbeknownst to the developer, something they just wrote in the code could potentially create a security vulnerability. The old way of preventing cybersecurity breaches resulting from flawed code entails top-down, more centralized security scans or reactive audits.

    The new, more proactive approach would leverage an advanced automated alert and visualization system that informs people about the impact of the decisions they’re making, as they’re making them. In the example above, the developer would automatically receive an alert about the security issue in the code so it can be rectified right then and there, before resource deployment.

    Similarly, this shift-left-and-rectify approach can be applied to cost control and compliance issues, as well. If resources are being provisioned sub-optimally and would incur unnecessary expenses, DevOps would be automatically alerted to the oversight and presented with a cheaper option. IT can make the solution even more cost-effective by allowing developers to take direct actions from the platform, instead of going to various portals. (According to the FinOps Foundation’s State of FinOps 2021 report, 39% of engineers do not currently have the necessary tools to take these actions). This type of intelligent automation can also ensure regulations and standards such as PCI-DSS, CIS and the AWS Well-Architected Framework are always adhered to.

    While traditional self-service IT systems still serve a vital purpose, these types of proactive cloud management and optimization initiatives will keep self-service IT agile and able to adapt to rapidly changing conditions. By embedding greater awareness into decision-making across the enterprise, DevOps functions even faster and more efficiently, and IT maintains even greater control. Hybrid cloud environments can be managed more intuitively and with greater confidence that misconfigurations and oversights that lead to security issues, cost overruns, and compliance risks will be intelligently and continuously remediated. The yin and yang endures.

  • CloudBolt Acquires SovLabs to Advance Hybrid Cloud Strategy

    CloudBolt Acquires SovLabs to Advance Hybrid Cloud Strategy

    CloudBolt Software this week announced it has acquired SovLabs, a provider of a framework that extends the reach of automation frameworks from VMware.

    Company CEO Jeff Kukowski said that as a provider of a cloud management platform, the SovLabs framework will extend CloudBolt’s reach deeper into VMware environments that have already invested in automation tools from VMware.

    As IT environments become more widely distributed across a range of platforms, demand for a platform that enables IT teams to centralize the management of multiple cloud computing environments has increased, Kukowski said. The addition of SovLabs to the CloudBolt portfolio will make it easier to bridge the divide between cloud computing platforms and enterprise on-premises IT environments that have standardized on VMware.

    CloudBolt has been making a consistent effort to enable IT teams to invoke its cloud management framework via whichever IT automation framework they have adopted, including tools such as Terraform. The goal is to reduce the need for IT organizations to rely on their own custom-built code to achieve that goal, said Kukowski.

    In general, many IT organizations are now investing more heavily in centralizing the management of multiple IT environments as part of an effort to reduce the total cost of IT in the wake of the economic downturn brought on by the COVID-19 pandemic. That shift is accelerating a transition to hybrid cloud computing models that require increased reliance on IT automation.

    The challenge many organizations face is enterprise IT environments tend to have many islands of IT automation in place. CloudBolt is pursuing a strategy that enables IT teams to extend those islands of automation or access CloudBolt directly to manage hybrid cloud computing environments.

    The CloudBolt approach offers IT teams an alternative to relying on a single platform vendor to achieve hybrid cloud computing. VMware, for example, has been making a case for deploying VMware vSphere on multiple clouds versus relying on the virtual machines provided by a cloud service provider. Most of the large cloud service providers are simultaneously pushing to deploy instances of their platforms in on-premises IT environments that can be managed as an extension of a public cloud.

    It’s too early to say how this titanic battle for control over hybrid cloud computing will play out. CloudBolt, however, is betting that rather than getting locked into a single platform, many IT organizations will prefer to run toward some neutral ground to deploy a control plane capable of managing multiple clouds and on-premises IT environments.

    Of course, CloudBolt is not the only provider of a cloud management platform making this case. Competition between providers of hybrid cloud management platforms is heating up as interest in hybrid cloud computing starts to move beyond the theoretical. Regardless of the path forward chosen, history would suggest that most IT organizations in the months ahead will be seeking more control over their IT environments.

  • DevOps Chat: Hybrid, Multi-Cloud Management for DevOps With CloudBolt

    DevOps Chat: Hybrid, Multi-Cloud Management for DevOps With CloudBolt

    Agile, DevOps, multiple cloud providers, serverless, contemporary cloud native apps, shadow IT using a credit card–it can be daunting for any IT organization to be responsive to the internal customer needs. It’s even tougher to be proactive and get ahead of the curve. Enter Cloud Management Platforms (CMP).

    On this episode of DevOps Chat, we talk with Bernard Sanders–no, not the presidential candidate–CTO of CloudBolt. Our conversation explores how IT can use a CMP to provide the IT and self-service capabilities so DevOps and Agile teams won’t feel the pain and slowdown of IT past.

    As usual, the streaming audio is immediately below, followed by the transcript of our conversation.

    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

  • Moving from legacy to DevOps is a journey that takes time…and the right tools

    Moving from legacy to DevOps is a journey that takes time…and the right tools

    If you wanted to start a new company tomorrow it would be easy to look at the tech landscape and the prevalent trends and decide to just build everything around a DevOps culture from the beginning. Most of the companies in the world already exist, though, and they already have processes, tools in place. Making the move from legacy to DevOps isn’t just a moment-in-time decision—it’s an arduous journey over time.

    That’s where CloudBolt comes in. I had a chance last week to speak with CloudBolt CEO Jon Mittelhauser and CloudBolt CTO Bernard Sanders about the company, its vision, and the latest version of the CloudBolt platform. Mittelhauser explained that what customers appreciate about CloudBolt is the ability to transition from the past to the future on their own schedule.

    One of the problems with change is that it takes time. While the new process or tool you’re moving to might be better in every way, getting there can be a challenge. In the meantime you’re forced to manage and maintain disparate systems or platforms—both the old and the new. CloudBolt wants to help organizations reduce the chaos by providing a single platform that enables customers to administer all of the above.

    Large enterprises in particular don’t just adopt a new technology en masse. One site or department might start to use DevOps tools and processes out of necessity. Another department might also embrace DevOps—but choose different platforms and tools. Mittenhauser explained that even if the entire organization is on the same page about which DevOps tools and processes to use the transition occurs slowly over time—often by attrition as licenses expire or platforms reach the end of their support lifespan. Those customers still need a way to view and manage their entire ecosystem throughout the slow evolution.

    CloudBolt also shared that one of its newest customers—the London Borough of Camden—has adopted CloudBolt to get better insight and control of its vast virtual environment. “At a time of austerity in government, running a low-cost, flexible hybrid cloud service for our customers is essential. CloudBolt provides a service that enables our customers to get the compute power they need, on demand, increasing their productivity and reducing our administrative overheads,” said John Jackson, Assistant Director (ICT), London Borough of Camden.

    Sanders claims that CloudBolt v5—released Wednesday, May 27—makes it easier for IT admins to manage activities, applications, and services across a multi-cloud, multi-platform environment. He described a variety of new features in v5. According to the press release the list of new features includes:

    • powerful new service catalog functionality to facilitate complex, multi-tier app deployments
    • provisioning of service catalog blueprints available through both the CloudBolt web interface and a powerful REST API
    • deeper out-of-the box integration with technologies such as VMware, OpenStack, AWS, Azure, Infoblox, Puppet and Chef
    • ability to define arbitrary server actions so DevOps experts can provide simple buttons for users to perform complex operations on servers
    • ability to snapshot VMs from the CloudBolt user interface
    • increased control for administrators, including the ability to set rate-based limits and set limits on environments in addition to groups and handlers
    • significant UI improvements, including adding social aspects to the interface
    • even deeper extensibility – additional trigger points for hooks/actions
    • revamped docs, now made public: http://docs.cloudbolt.io
    • new trigger points for power on/off, rebooting servers and post-order completion process have been introduced and currency units are no longer limited to USD

    In many ways it would be easier to just switch gears and embrace the DevOps culture throughout an organization, but with large enterprises—and even some medium or smaller organizations—that is simply unrealistic. For organizations that are maintaining multiple technologies and environments during that transition a tool like CloudBolt can help IT monitor and manage everything efficiently.

    Existing CloudBolt customer can download the latest version from the support portal.