In this DevOps Chat we discuss IBM’s Cloud Private. Cloud Private is the new offering from IBM that encompasses much of the different cloud offerings the company has developed over the years. Our guest on this DevOps Chat is Michael Kaczmarksi, an IBM Fellow and CTO of DevOps and Service Management. In his distinguished career at IBM, he has obviously seen technologies come and go. Michael gives us an inside look at IBM’s Cloud Private offering and how it relates to DevOps, service management, hybrid cloud and so many other contemporary technologies in the market today.
As usual the streaming audio of our discussion follows immediately below. Below that is the transcript of our conversation to follow along.
Alan Shimel: Hey, everyone, it’s Alan Shimel, devopsy.kinsta.cloud, and you’re listening to another DevOps Chat. We’ve got a very interesting chat lined up for today, with a great guest. Let me introduce him. We have today Mr. Mike Kaczmarski of IBM. Mike, welcome to DevOps Chat.
Mike Kaczmarski: Thank you, Alan. Glad to be here.
Shimel: So, Mike, you have a CV résumé full of accomplishments, and I don’t mean to embarrass you, but why don’t you just share with our audience kinda what you’re doing now with IBM and a little bit of your background?
Kaczmarski: Alright, I’d be glad to. Well, my title is IBM Fellow, CTO of DevOps and Service Management, in a unit inside IBM called Hybrid Management—Hybrid Cloud Management. I’ve been with IBM—well, in February, it’ll be 35 years.
Did a lot of work in the storage portfolio—a lot of the Spectrum products, Spectrum Protects, Spectrum Control. I came into a business unit that was called Tivoli at the time, became very familiar with all of the service and systems management products, and then into products like Maximo and others that we acquired or built out organically. And then became involved in a lot of the cloud technology—IBM Cloud and now I’m working very hard on DevOps technology and service management technology in a new offering that we have out called IBM Cloud Private.
Shimel: Excellent. Excellent, excellent, excellent. And we’re gonna try to get to as many of these as we can, Mike. But in order to do that, I think we need to lay down a little sort of baseline, if you will. And how I wanted to do it was, you know, let’s talk about really what I think is one of the primary drivers behind the whole hybrid cloud transition that we see, and that is that traditional applications—you know, everyone would just like to move everything to the cloud, perhaps, make it easy, and be done. But that’s not the way the world works, right?
Kaczmarski: [Laughter] Right.
Shimel: You know, customers are beginning that migration, but that migration will probably take—Mike, you said you were with IBM 35 years. I’ve been around awhile myself. We’ll be long gone by the time that migration is over, I suspect. [Laughter]
You know, so in the meantime, customers are faced with sort of this hybrid period where, you know, some of the applications and some of the application infrastructure may still be on-prem, may still be maybe a private cloud on-prem, maybe on a public cloud, maybe on a private cloud in a data center. You know, truly, a multi-cloud and hybrid environment. Is that what you’re seeing at IBM?
Kaczmarski: Certainly what I’m seeing. If you consider things like the importance of customer data, data sovereignty, customers’ concerns over security, proper connectivity—all those need to be addressed, and customers’ businesses are running on their IT, and they’re comfortable at different stages with different aspects of those things being on the cloud, whether public or dedicated, and you often find something, like private cloud is a wonderful way to get started on understanding what operational architecture programming changes and even organizational changes they need to make to best start to utilize the cloud. Whether they take all those capabilities to public or dedicated cloud or not, the private cloud helps them.
Shimel: No doubt about it. And so, Mike, when we talk about—you know, they may be IBM customers. But when we talk about organizations transforming their traditional—and by traditional, I mean non-cloud, they’re not cloud native apps—and trying to migrate them to the cloud. You know, I think you highlighted some of the things that we run into, but anything else that I think listeners may be interested in or at least gotchas that they should be looking for in transforming these apps and trying to move them to the cloud?
Kaczmarski: Yeah. Well, I think there’s three patterns that we see pervasively. The ones you hear a lot about are those customers who are building out new cloud services, new cloud native programming models, and extending their business into the cloud using some of these new microservice-oriented programming models—polyglot technologies—and perhaps connecting them to their enterprise from the cloud; hence, the hybrid sense through APIs and API management so they can take advantage of their back office systems and the data and expose other application pieces on the cloud.
There’s a few other patterns. We see customers who have applications that would fairly easily be optimized by cloud technology, such as container technologies for rapid deployment, rapid scale out, resiliency. There are applications that can be, we call it, lifted and shifted fairly easily. And then there’s a whole area of applications that are built out in monolithic fashion that have very tight interdependencies that have been around for years and years, and customers are making decisions on what they do with those applications, and it kinda depends on how much those applications are changing, how critical they are to the business—I don’t wanna touch it, it’s not changed in years, it’s doing its job. That might be some of their criteria. In other hands, parts of those applications might be changing fairly rapidly. And if that’s the case, then they start looking at refactoring or factoring out the portion of application code that is changing fairly rapidly into, say, microservices and placing those in the cloud.
So, I think there’s a number of approaches that they’re taking, and obviously, it’s a business issue. What makes sense for me to refactor? What am I gonna gain by the refactoring of these applications and putting them in the cloud? How am I gonna lower operational costs? How is DevOps gonna help me, and what kind of return am I gonna get from that versus continuing to do what I do or even leaving some of my monolithic applications alone?
So, I think, you know, there’s a broad range of considerations that customers have when they look at moving their applications to the cloud, and hopefully I’ve kind of listed a few, there.
Shimel: Absolutely. So, Mike, you know, this is all—it’s all happening, and I think we’ve kinda described it well. But now, so IBM has recently come out with this Cloud Private, as they’re calling it, and you know, frankly, I think there might be a little misunderstanding in the market where, hey, you’re talking about hybrid cloud, but now, why are you doing Cloud Private? Right? Is it private cloud, is it hybrid cloud? Cloud Private—where does that fit in? Can you help clear it up for our listeners?
Kaczmarski: Yeah, sure. IBM Cloud Private is an on premise cloud offering based on Kubernetes technology, optimized by some of our systems group. It does run and allow you to deploy private clouds, what I’ll call on premise clouds, on Intel, on Power, on zLinux, so you can take advantage of the systems you might already have deployed, but it has full connectivity to any services in—cloud services that are running in the cloud public or dedicated cloud. It’s a way for customers to start to either write new microservices or write new capabilities or refactor, as I mentioned, some of their applications into a cloud that is running on premise, allow them to experiment without concerns of data privacy, data governance, data sovereignty, and allow them to figure out what’s the best approach that they want to take for refactoring their applications or moving them to the cloud.
It is Kubernetes-based. It’s based on the same technology that runs on our public cloud and what we call the container services. So, much of the workloads that can run in the private cloud if the customer chooses can be transparently moved to the public cloud or a dedicated cloud for them. The Kubernetes technology overall, the Docker containerization—everything’s running in Docker. They’re fairly pervasive in the industry, so it does give the customer a choice. I think it gives them a foundation that they can start with. They can move workloads at their most comfortable, keeping them on-prem, and then they can start to extend those workloads to the public or dedicated clouds as well.
You know, another big difference with IBM Cloud Private is, we’re moving our middleware, our traditional offerings like the WebSphere and message queue and IIB and DB2 and the data science experience—traditional middleware that customers have running on-prem that they’re writing their applications against are now available in IBM Cloud Private in containerized versions, the same service, the same APIs, a lot of the same capabilities. And so, they can actually take advantage of the same middleware that they’ve been running with, now containerized in clouds so that they can take advantage of simpler deployment, AB deployment, a simpler upgrade, resiliency, scale out, and so on.
So, that’s what I think we bring to the Cloud Private arena is the ability for customers to leverage the investment they have in our middleware and middleware services now in a cloud deliverable. And that also makes it easier for them to move their applications into a cloud architecture, whether it’s on-prem in Cloud Private or in public in IBM cloud or a dedicated cloud, an IBM cloud.
Shimel: You know what, Mike, that was fantastic, and it kinda made a lightbulb go off for me, here. What really, what Cloud Private is offering customers, or anyone—you know, eventually, I guess, their customers—but it’s portability. It is giving you a cloud ready infrastructure, whether that cloud be on prem, at an IBM data center, maybe in a public private type of situation, hybrid situation or not. And not only is it allowing that infrastructure through containers and Kubernetes to be portable like that, you’re now portable-izing, if that’s a word, [Laughter] that whole layer of middleware that so many have been using for so long—
Kaczmarski: Yeah.
Shimel: – and making that also portable to whatever or however and in what combination you want to post your applications going forward.
Kaczmarski: Yes, that’s sort of a—
Shimel: And that’s really powerful.
Kaczmarski: – yeah, that’s a good description, yes.
Shimel: Yep. And, you know, I think, you know, Mike, it really goes to the heart of what we’re seeing in technology today, which is the—and a lot of it is via Kubernetes; well, microservices and containerization, let’s call it that.
Kaczmarski: Yes.
Shimel: It’s fundamentally shifting the IT infrastructure or the preferred IT infrastructure in a way that we haven’t seen maybe since when we moved from client server, or maybe when virtualization and hypervisors first became sort of dominant or started really asserting influence in the market. This is really a shift of that magnitude. Do you agree?
Kaczmarski: Yes, I do, and actually, those are two perfect storms that kinda come together, the virtualization and the client server. I think containerization is an interesting supporting feature of microservices. It really allows a full stack deployment, and actually changes some of the roles and responsibilities of what developers have traditionally done.
Shimel: Absolutely on that. So, this is DevOps Chat, though. Let’s talk a little bit about DevOps. I always like to tell people that—hey, DevOps is an umbrella term today. It’s more than just the breaking down of the silos between dev and ops, and there’s obviously a cultural aspect to it. But, you know, the thing about DevOps is, it’s about how things get done today. And so, when we talk about things like microservices and containerization and cloud, right, I don’t know if DevOps is a byproduct of those things or if DevOps is a precursor or an accelerator to those things, but they seem intrinsically linked.
Kaczmarski: Yes.
Shimel: What’s your view on that?
Kaczmarski: Yeah, I think they are tightly linked. I think DevOps enables the kind of automation you really want to be able to understand how your applications are being developed, are integrated, how they’re performing, whether or not you’re ready to go into production with what you currently have, whether or not you’re really ready to support, operationally, the applications you already have—all of those things, as early in the life cycle as possible.
And, you know, when you talk about containerization and microservices, as compared to monolithic applications, there’s a lot more moving parts. There’s many more moving parts in a microservice container organization of your code. You know, you have business function decomposed into various different microservices. It’s actually an organizational construct as well as an architectural construct. You have teams around those microservices building them. They all have API contracts with each other on their behavior, and now they’re deploying at different times into what should be a running system that’s providing a service. At every point along that line, you wanna understand. You wanna be able to herd all of these microservice teams that are together building out the application in a consistent way and always know where you stand in terms of the application being built.
By the way, the same applies to monolithic apps, because they undergo change if they’re interacting with these cloud native apps and microservices. So, you need to be able to automate and make sure nobody breaks the builds, you need to be able to do continuous deployment of the microservices in, say, a test cluster or a cloud where they interact with each other. You want to vary the versions that are out there to understand if the API contracts have been violated. You want to have a real good idea of the performance and scale of the microservices that are out there—and there are so many of them in a traditional application now, manual tasks would never be able to keep up. So, automation through DevOps in terms of build, deploy, the manageability, the testing of the microservices is paramount in being able to scale a true microservice architecture to a product that has reliability and can be easily updated and can actually iterate very quickly to meet customers’ needs.
Shimel: Absolutely. Mike, let me introduce another term into our term goulash today, and that’s service management, alright? So, service management is something that has certainly been on the IT agenda, right, on the IT menu for longer than the word DevOps has been used, right?
Kaczmarski: Yes.
Shimel: Service management is an important piece of it, right? And there’s been somewhat, frankly, of a disconnect on the nexus or connection of DevOps and service management. Are they compatible? Do they work together? Is there a continuum with them?
What’s your view? I mean, you have both under your portfolio, here. What’s your view on that?
Kaczmarski: Well, I think that integration of DevOps into Ops, if you will, relative to DevOps I just talked about in terms of automating, you know, build, deployment, test—integration into Ops is more about making sure you can monitor the application, making sure that if there are outages, you have procedures, run books that can quickly bring things back, supporting things like site reliability engineers, understanding who’s going to be notified if there’s a problem with a particular service—all of those kinds of things push back operational characteristics on the DevOps and even the development team.
You know, as our teams were building out IBM Cloud, a lot of the services in IBM Cloud are managed by, developed by individual squads, so a logging service or a particular database service or whatever we make available in that cloud, there’s a squad behind it. Obviously, they develop it, they go through regular DevOps deployment and testing, they determine when it goes into production a lot of times based on analytics from a lot of the automation that they have.
When it goes into production, they’re immediately also responsible for the ongoing operation of those services. This is the development team. They’re now responsible for the ongoing operation of those services. Now, they have site reliability engineers as well, but if you take some development teams and make them responsible for the operational characteristics of their services, a lot of interesting things start to happen. You start seeing development not around the application itself, but also around, “Oh, hey, I have some Selenium scripts that I’m gonna use to automatically monitor response time of the application. This needs to get deployed with the code.” “Oh, I have some run books for the SREs or automated scripts that, should certain events show up, will automatically restart or scale out services appropriately.”
You start seeing operational artifacts as part of the development of the particular microservices or applications that are being built. And of course, as that starts to occur, you start seeing standards for handoff of these kind of artifacts between DevOps and Operations teams so that not only are they deploying application, they’re deploying the management around that application and they’re ready to go when that application goes to production.
So, I think that’s the biggest cultural change I’m seeing with DevOps going into Ops is really integrating the management capabilities and intelligence into the application and the awareness that now the developer and the DevOps team have in providing what is needed to properly manage the application and operations.
Shimel: Mike, that was one of the best answers to that particular subject that I’ve heard. Thank you very much for that.
Unfortunately, Mike, as I told you before we started, the time here goes really, really fast. I promised you we’d be done in 15 minutes and we’re on 20 minutes already, so I know we had a lot of other topics we wanted to cover. Maybe we’ll have you back on at another time and we can do a part two on this, but we’re about out of time right now.
Thank you so much for being our guest on DevOps Chat today, Mike.
Kaczmarski: Oh, thank you, Alan, I really enjoyed it.
Shimel: Not a problem at all, and as I said, I’d love to have you back on here soon, and we can continue the discussion. But before we go, for anyone who wants to get more information on IBM Cloud Private, where can they go?
Kaczmarski: Well, actually, the easiest thing you can do is Google IBM Cloud Private, and there’s a number of references out there, and tools. There’s cloud reference architectures, developers, communities. If you want to engage with some teaming with IBM on what’s the best way to move some of your applications to the cloud, there’s IBM Cloud Garage, and there’s some wonderful blogs out there where developers will take you through how they actually move some of the applications to the cloud. So, I would just Google IBM Cloud Private, and you should see, in the first two things that come up, some really good references.
Shimel: Fantastic. Mike Kaczmarski, IBM Fellow and CTO for IBM Private Cloud, DevOps Service Management—thanks so much for being our guest on this episode of DevOps Chat. To everyone listening, hope you enjoyed it, and we’ll see you soon on another DevOps Chat. Have a great day.
— Alan Shimel
