Tag: hybrid environment

  • Some Technical Debt is Self-Resolving

    Some Technical Debt is Self-Resolving

    But don’t count on it.

    Fellow devopsy.kinsta.cloud contributor Bill Doerrfeld recently wrote, “Enterprises Face Growing Technical Debt,” a great article about trends in technical debt, and it got me thinking about some of the things that have been going on in the industry over the last few years.

    As I’ve mentioned before, the changes underlying our systems combined with the need to keep systems that existed before those changes alive are making for quite the debt ratio, and that debt is coming due, probably sooner than you think.

    We’ve got enhanced ways of tracking how much time technical debt is consuming built right into our CI/CD tools, but there are inherent weaknesses in those tools. The ability to track time spent on issue X, and to categorize issue X as debt, requires a solid categorization process and relies on staff to keep close track of their time. Right or wrong, the industry has currently (maybe permanently) moved away from tracking time in small increments and, instead, most organizations track results. But unless you know the percentage of time spent keeping a system that is outside your main-line development toolsets alive, you can’t determine how bad technical debt really is.

    There are some bright spots though, and while I (and others, to be sure) have been sounding the alarm about technical debt since DevOps teams were all allowed to pick their own toolchains (glad that’s mostly over with), we need to be aware that counter-forces will help alleviate technical debt issues, also.

    First is the trend of making things simpler. Let’s face it, on the DevOps side, Python became popular at an insane pace. There is a very good reason for that. Shell scripts written by master scripters to achieve a goal are impossible for even good IT folks to follow. What you can’t follow will take much longer to fix–because you have to break it apart, figure out the parts, parse through massively complex pattern matching, etc. Python simplified all of that. If you write a Python script to do the same thing as a bash script, a far higher percentage of IT will be able to glance at it and go, “I know what this does.” This trend exists across IT (bug dashboards are another good example at a much higher level), and as easier-to-understand tools are increasingly part of the mix, the old and arcane will be less of a debt.

    Second is that, while I have raised warnings about things like the growth in API usage and CI/CD toolset complexity, the fact of the matter is that both of these things reduce the amount of code that we, internally, are maintaining. Steps automated, be they by calling someone else’s API, or calling your CI/CD vendor to handle build or deploy steps, are less steps for us to worry about (as long as they work, of course–have trusted partners).

    But we still need to be aware of technical debt, because all of the things we’ve mentioned in the past—the increasing complexity of our environments, staff turnover, team-specific tools and languages—are driving up debt.

    Check with your CI/CD vendor to see what their offering for tracking debt looks like. Other measures that don’t require tracking actual time spent on individual activities include keeping a tally of the number of bugs. And a surefire way to get a great feel for where your weaknesses are is looking for the software no one wants to work on, or the software that someone warns the new people not to touch. That’s where your debt load is the heaviest. IT is full of tinkerers;”If it ain’t broke, don’t fix it …” only applies in IT if “…because no one here knows exactly how it works,” also applies.

    Ask your teams to list which tools in their area (be it silos or DevOps teams) need to be updated and/or replaced, and then to rank them. Then take that data to team leads, and ask them to decide where your limited hours and money should go. Provide data on relative debt that you gathered above, so a comparison of team rankings to debt cost can be made.

    And then, set aside time to alleviate debt. It doesn’t have to be massive, just keep moving forward on it. You set aside time for all sorts of things, even a few man-hours a week on debt will multiply. It will start slow, but once you are spending less time each week fixing “product X,” some of that time can be added to technical debt resolution, increasing what can be done. Look for low-hanging fruit; a small app or script that eats up an outsized amount of time, or a system that is insanely expensive to keep, while the market has moved past what it actually is used for in your department, etc.

    Then enjoy the fruits of your labor, and put those astounding skills and that extra time to use rocking even more new apps for your users.

  • 3 Ways To Tackle the Operations Complexity of DevOps

    3 Ways To Tackle the Operations Complexity of DevOps

    DevOps is challenging, some of its complexity requires a platform that is both SaaS and managed environments, running on top of several cloud providers and potentially on-premises as well. Is there a platform that connects applications and systems while supporting enterprises as they accelerate their digital transformation efforts? If done the traditional way, you have all the ingredients to fall into an operations nightmare. Unless you tackle the challenges with cloud-native approach from day one.

    Let’s explore three ways to tackle the operations complexity of DevOps.

    Cloud-Native Architecture

    Why use Kubernetes? This technology is an open source system for automating deployment, dealing with massive scale and management of containerized applications. If the main initiative is to isolate every single integration that runs, then select an architecture component that could give you a head start.

    A well-designed application based on microservices and running on containers can benefit heavily from technology such as Kubernetes in the following ways:

    • Resilience & Fault Tolerance: These are key ingredients for today’s highly available, always-on systems. With the help of Liveness and Readiness probes, we can set up an environment where any misbehaving container could be automatically recycled and have a new instance ready to use.
    • Multizone Cluster: With a multizone cluster, it is possible to apply hard-to-achieve fault-tolerant architectures where a container running on a zone is automatically moved to another zone if there is a failure. By coupling that with GCP’s ability to replicate volumes across zones and you can deliver a true fault-tolerant architecture.
    • Millisecond recovery: Any restarted container takes milliseconds to get ready again, so absolutely no interruption occurs.
    • Microservice Isolation: Misbehaving containers won’t affect others as there are reinforced limits in terms of CPU and Memory usage.

    Deployment as Code

    GitOps is our mantra. GitOps is a way of implementing continuous deployment for cloud-native applications. It focuses on a developer-centric experience when operating infrastructure, by using tools developers are already familiar with, including Git and continuous deployment tools.

    The technique here is to follow regular Git Flow methodology and have automated “operators” apply changes to a Kubernetes cluster. These operators are regular containers running on a Kubernetes cluster, which constantly monitor Git source repositories for changes. Once a change is detected, the operators automatically trigger an update.

    For the automated installations, use Helm as the deployment engine. When changes are committed to the Helm configuration in Git, the operators automatically apply those changes.

    This approach essentially reverts the classical imperative deployment model where actions are performed in the environment to a declarative approach where the state of the environment is defined by a set of rules and kept in sync by these operators.

    Outstanding levels of governance can also be achieved in all clusters from a single source of truth. If a manual change was introduced in any of the environments, the operator would detect and revert back to the defined state.

    Normalize Hybrid Environments

    Kubernetes is powerful, but comes at a price. It is very challenging to maintain different versions and distributions, especially when using different cloud providers and on-premises environments. Due to that fact, you must identify a technology that would abstract the complexity away, normalizing the operation.

    Consider Google Anthos for this, which is a full Kubernetes distribution based on Google Kubernetes Engine and is available to Google Cloud Platform customers. Over the years, Google refined its Kubernetes distribution and eventually released it as a product in its cloud platform.

    Main advantages of using a technology such as Anthos include:

    • Standard Kubernetes installation for on-premises, VMware-based environments.
    • Connectors for Kubernetes Engines in AWS and Azure cloud providers.
    • Built-in configuration management capabilities allowing us to declare our clusters and keep them in-sync.
    • Remote-controlled Kubernetes environments from a single admin portal so all cluster resources are easily accessible.
    • Monitoring metrics consolidated on Google’s StackDriver.

    The three ways are more than enough to achieve greater scalability, governance and control of hybrid environments to address DevOps and complexity. They are actually a new mindset for application design and operations. I truly believe that they can help companies deliver better software while recognizing the complexity and challenges of dealing with enterprise applications.

  • Building Hybrid and Multi-Cloud Architectures for Analytics and AI

    Building Hybrid and Multi-Cloud Architectures for Analytics and AI

    We are in the early stage of the data revolution. Today’s conventional wisdom states that hybrid latency prevents you from running analytic and machine learning workloads in the cloud with the data on-prem. As a result, most companies either do not burst their workloads into the cloud or have to copy their data into a cloud environment and maintain that duplicate data—and even this can take days or weeks.

    Counter to conventional wisdom, you can create a high performance hybrid/multi-cloud data platform for analytics and machine learning by using data orchestration technology. Container orchestration technology (e.g. Kubernetes) enables containers to run in any environment agnostic to the hardware that is running the application, similarly data orchestration technology enables active working sets and data to be orchestrated on demand. This enables enterprises to create a compute agnostic, storage agnostic and cloud agnostic stack to serve all their data driven workloads, including analytics (e.g. Apache Spark, Presto, Apache Hive) and AI (e.g. Tensorflow, PyTorch).

    An enterprise hybrid cloud analytics strategy should burst compute that spans on-prem and cloud data stores. By bringing the hot data to the analytics and machine learning applications, the performance is the same as having the data co-located in the cloud. Also, the on-prem data stores will have offloaded the computation and minimized the additional I/O overhead.

    Specifically, a data orchestration system should:

    • Abstract data access across storage systems. Today, data is siloed in various storage systems and deployments. For example, lots of on-premise data is stored in systems such as Apache HDFS, Ceph, EMC Isilon and IBM Cleversafe, and data in the cloud is stored in systems such as AWS S3, GCP Store, Alibaba OSS, etc. Historically, there have been many attempts to unify all data into a single storage deployment with limited success. As a result, we’ve seen more of a trend around embracing these data silos by abstracting the data in various storage systems/deployments. To do this, the data orchestration system needs to abstract and virtualize across various storage deployments/deployments by server side API translation, which enables users to run existing applications without modifying any code. The system also needs to provide a single global namespace to enable apps and users to access all the data in their environments without the need to understand which storage the data is stored in.
    • Bring data locality in a separated compute and storage environment. While cloud vendors and leading companies in data-heavy industries have adopted a decoupled compute and storage architecture, it can still be very challenging to implement this type of architecture, especially when it comes to bursting on-premises data into the public cloud. A data orchestration system resolves this challenge by providing caching functionality that enables the system to automatically orchestrate the hot data to be closer to compute while at the same time keeping cold data in a cheap storage. Because each workload may have a different usage pattern, the system must have a policy that enables customized policies best suited for those specific workloads. Moving forward, it is also very critical to have policies across various clouds to enable a multi-cloud environment.
    • Provide security for data in motion and at rest with secure access methods. A data orchestration system plays a critical role in the success of an organization’s data strategy. While open source software is important and can help in avoiding potential vendor lock-in, it is also critical to provide necessary security features in this environment given the system touches a lot of data in the organization.

    Besides empowering data driven application developers, a data orchestration system also brings value to data and infrastructure engineers. It de-risks vendor lock-in by providing organizations with flexibility at the infrastructure level. Transitioning to different storage systems (including cloud storage), adopting another application framework, or even having a hybrid or multi-cloud environment are all possible without the need for many different technologies or incurring large development costs.

    — Haoyuan Li

  • 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