IBM Cloud Private has cemented itself in the DevOps space as a personal cloud environment, which is great for developers who need the agility and computing power of the cloud but don’t want to step into a public cloud setting. Tony Corbin, technical lead for the Microclimate Project, describes IBM Cloud Private as “a cloud specifically targeted at individual customer.”
In this DevOps Chat, Corbin and I talk more about IBM Cloud Private and its role in DevOps. As usual, the streaming audio is immediately below, followed by the transcript of our conversation.
Transcript
Alan Shimel: Hey, everyone. It’s Alan Shimel, DevOps Chat, and you’re listening to another DevOps Chat. I happen to be joined today by a first-time guest on a podcast. So this’ll be an experience for him. It’s Mr. Toby Corbin of IBM. Toby, welcome to DevOps Chat.
Toby Corbin: Thanks, Alan. How are you doing?
Shimel: Doing great, and happy to have you on today’s show, Toby. Rather than introduce you to the audience in terms of your title and role and everything, I thought it would be a good icebreaker for you to kind of introduce yourself. So why don’t you kind of share with the audience, if you will, what your title is and what that means and kind of what you do with IBM?
Corbin: Sure. So at the moment I’m Technical Lead for one of the squads in the Microclimate Project. Microclimate is our developing experience, which we’re targeting to help onboard customers and developers into the IBM Cloud Private. So my role and my squad is – we sort of deal with the backbone of Microclimate. So we deal with making sure everything runs smoothly. We add in things like analytics and the sort of analysis application. But we make sure the whole thing sort of runs. So we’re kind of the backbone. So the squad that I lead, we’re the backbone of Microclimate.
Shimel: Excellent. So Toby, this sounds sort of like an Ops role, if you will, right? When we talk about the Microclimate – and you know what? Let’s back up. Some of our audience out here may not even be familiar with IBM’s Cloud Private offering. And I don’t claim to be an expert. I’m going to assume you know much more than I.
Corbin: A little more.
Shimel: Yeah, a little bit. I would hope so, so you’re not collecting your check under false pretenses, correct?
Corbin: [Laughs]. Correct.
Shimel: So Toby, let’s start with that. How would you describe Cloud Private to our audience?
Corbin: So we’ve all heard of public cloud – things like Amazon have a cloud and Google have a cloud and IBM also has their public cloud. And these are quite large deployments. They’re hidden in the ether somewhere, no one knows where they are, and that’s where all the really, really clever analysis goes, and that computing power that IBM can bring. Cloud Private is sort of the onboarding into that. So Cloud Private is a cloud specifically targeted at individual customer. So they won’t be sharing that with anybody else. It will be an instance just for them and they’ll have the very similar applications and things on there that the public cloud would have. The intention being that when our customers are happy using this Cloud Private installation – so they don’t have to have their own machines. They can have the Cloud Private stuff working for them, doing all of their processing. When they’re happy having that working, we can then take them up to the public cloud, where they get even more of IBM’s processing power and they have an even better experience.
So it’s kind of taking them from a private cloud that’s just for them up to the bigger public cloud, where although it’s still for them and they don’t share with other people, they have bigger computing power available to them.
Shimel: Got it. So is it sort of a way station along an upgrade path? Or can someone stay on Private Cloud indefinitely?
Corbin: Oh, you can absolutely stay on Private Cloud. You’re not forced to go up. But obviously as we go up through the clouds, the capabilities IBM can offer you get a lot greater. So that’s why often you’d find that the customers would want to move up to the next level, because there is an even greater amount of processing and a greater amount of options available to them and to their customer deployments.
Shimel: So they grow into it, I guess. So Toby, I was under the impression, and maybe I’m wrong, that in Private Cloud there was also – I thought it was a Kubernetes-based offering. Is that –
Corbin: That is correct, yes. So IBM’s Private Cloud is all based around Kubernetes. It’s IBM’s flavor. So it’s Kubernetes under the covers and IBM have made it sort of into their ICP, their private cloud offering. But it is Kubernetes-based, that’s correct.
Shimel: So it’s containers with Kubernetes and this whole sort of – you know, the _____ _____, obviously, but now we’re starting to see the domination almost of Kubernetes kinds of architectures.
Corbin: Yeah, and that’s how IBM’s helping our customers. So you think of the old way of doing things, you’d have a _____ application that was a huge monolith, a giant application that couldn’t really go anywhere. With IBM’s Private Cloud what we’re looking at is, how can we take these applications, deploy them on the cloud, free up all of the hardware – in a customer’s site they don’t have to worry about those things – and take these large-scale applications and deploy them into a cloud environment? And then it’s not just make them work in a cloud environment. How can we work with customers to actually make them change their applications and sort of rebuild them, if you like? Strip them down, put them back together again, as a microservice opportunity?
And that’s where Microclimate comes in. That’s what we’re doing for the developers. It’s how you create those microservices.
Shimel: Perfect. And of course, Toby – I think a lot of our audiences are familiar with the term “microservices,” and we see microservices being mentioned a lot around Kubernetes, around containers, around DevOps and cloud and so forth. And you anticipated my next question, which was, when we talk about a microclimate, is that sort of the climate in which we do microservices or perform microservices.
Corbin: Yes. Well let’s say for this, yes. Effectively what microclimate is, it’s the environment that we want to give to our developers to go from having absolutely nothing to being able to develop their very first microservice, test it and then deploy it up into production through things like the Jenkins Pipeline and using Travis, and get it running in their cloud, all without actually having to need any prior knowledge. We sort of do this all for you. So in the past there was always ways of being able to create an application and there was always ways of pushing an application into a cloud, but it was several steps, different technologies. You had to rely on the customer having various knowledge themselves. So Microclimate is aimed to make this really seamless. You don’t have to leave your web browser; it’s entirely web-based. But we give you the ways to easily create an application, develop it in the cloud in a web-based editor, test, adding in these performance issues that we’ll talk about in a second, and then when you’re really happy, then get it run in production environments, all with the under-the-covers work being done for you by Microclimates.
Shimel: That’s fantastic. So this whole Microclimate, if you will – excuse me, microenvironment and Microclimate, this is all managed via web browser? All web-based, huh?
Corbin: Exactly. Because this gives you the opportunity that if you are fully running in the cloud, you don’t actually have to have anything on your laptop at all. Everything can be based in your ICP installation. You need nothing on your laptop to run it, which means then you don’t have to have Swift installed or Node installed. But you can still go and create and generate Swift and Node and _____ applications without having anything local to your machine. It frees up your environment to do everything in the cloud, so you’re straightaway using the power of the cloud to do your development.
Shimel: hat’s fantastic. And Toby, it sounds to me, even more than that – you know, so I’m old, right? So I’ve been around for a while. And wen we first saw microservices and containers, to me this was like Heroku – better than Heroku. It was truly moving from infrastructure as a service to platform as a service. So that if you’re a developer and I want to write stuff let’s say in Swift or JS or whatever, I didn’t have to worry about, “Was that installed? What was the infrastructure like? What was going on? Was it installed in the OS level?” I could work directly on my application. Do these sort of Microclimate, microenvironments – is that what this really represents?
Corbin: Absolutely yes. So that’s one of the beauties. Before coming on to work on Microclimate, I was doing Swift developments and Node developments, and I would have to have the latest versions of Swift on my machine and I had to keep up with them to make sure that I would have the latest bug fixes done or whatever it was to make my application run smoothly. With Microclimate, we take care of that whole environment for you. So when you say, “I want to create myself a Swift application,” you get a container running with the latest version of Swift. All of the security patches for that run are already applied. You don’t, as a developer, have to worry about, “Do I have the right installer? Do I have the right version of he compiler?” All taken care of. As a developer you can now just write code and we will do everything else in the background for you, so it really frees up the developer to do their job and not have to worry about keeping their machines up to date with all of the latest patches and run-suns and everything else to do that.
Shimel: That’s pretty nifty. Good stuff right there. So then, Toby, as part of your – you know, you’re a team lead with portal, you had mentioned, and – but you know, but your whole team and what you’re doing – would you say most of the people you’re serving are developers? Or do you kind of correspond with their Ops team, who are still servicing the developers within their organizations?
Corbin: So this is where Microclimate has nicely evolved. We started off s being the developer experience. So we were the developer experience _____. And we were aimed at, how do we nicely onboard the developer from having nothing on their laptop to being able to write their first microservice and deploy it to the cloud? But then we quickly realized that we need to have DevOps. So we brought on a whole DevOps pipeline to the backend of Microclimate. So Microclimate is really _____ _____ as an end-to-end story of two either distinct parts, if you like, but they actually work in one. You start with, “I’m on my laptop, even though I’m running in a cloud environment.” So I’m coding on my laptop and I’m writing my first microservice. And then when I’m happy, I’ll use Microclimate to actually send it to my preconfigured Jenkins Pipeline, and the backend of Microclimate that deals with DevOps will take that and will build you on your Jenkins Pipeline, it will push towards your production and you’ll actually go the full end-to-end now.
So Microclimate is not just really about writing your first piece of code now. It’s taking any application and pushing it right through to deployment at the other end and have it run in production.
Shimel: It’s end-to-end. That’s beautiful, man. That’s really nice. So share with our audience, if you can a little bit, what are the kinds of things that you and your team are actually doing as part of maintaining this environment?
Corbin: So one of the things that we brought – so as I said before, my background in this, I actually came from doing tools monitoring for things like Java and Node. We now bring that to Microclimate. So we can think of things like a performance issue that you would typically see. You know, my CPU is going mad and it’s at 100 percent, or my disk is thrashing or running out of memory. And often it’s very difficult to know why that’s happening or even if it’s supposed to be happening. So what we do, what we bring to Microclimate is, we bring to the table our analysis tooling that we have outside Microclimate. So when you use Microclimate, we actually build in our monitoring stuff. So that means that when you write your very first line of code, we actually start monitoring it straightaway.
So you don’t even have to think about, “Okay, do I have to monitor my application for performance problems?” or, “I’ve got my application written. We normally have a performance team that does this.” We give it all to the developer. Because if a developer can see a problem with a line of code they just put in – for example, they’ve just coded a new function and when they run that function their fan goes mad on their MacBook and it’s thrashing away and they think, “What have I just done?” If we can tell them what they’ve just done at the point they do it, this speeds up development in the future and your testing gets quicker, because you don’t get a performance team two months down the line saying, “Hey, we’ve just run your stuff and it performs like a dog,” and then it comes back to the developer to have to re-find-out what they’ve done. We show you straight away. As you type your code in and hit Run for your first test, we can show you what performance was, so you can see, am I regressing? I can see where my CPU is going mad or I can see where my hard disk is lighting up or I can see where I’m running out of memory.
We build that in for you. So hitting the developer experience right from day one means that hopefully when you get to the end and your application deploys, there’ll be no surprises around, “Well it’s not running anywhere near as well as I thought it would.” So that’s what we bring to Microclimate.
Shimel: Got it. Like you’re the developer’s best friend.
Corbin: We’d like to think so, yes.
Shimel: So Toby, as I mentioned before, I’ve been around the block a little bit. You know, one of the problems with what you’re describing is territorial issues, let’s call them, right? “Hey man, I’m the Ops guy here from my org, and I’ll help my developer, thank you. Don’t be giving away our secrets, telling the developer some of these performance things.” You know, performance kinds of insights. Do you run into having to deal with pre-existing performance teams as part of the Ops at these organizations?
Corbin: Well not so much, because we actually find now is that the sort of dynamic of a team is changing. As we go into this sort of more agile world where each team is intended to be self-directing, we find by having smaller teams with sort of jack of all trades, we get away from this developing, developing, developing, testing, testing, testing situation that we _____ _____ five or ten years ago. And this means that much smaller teams can deliver functionality that’s fit for purpose a lot quicker, because you’re not waiting for a longer test run at the end or other sort of testings that happen that would typically end up in this loop of sort of, “I deliver my code, someone tests it, it comes back to me to make changes, someone tests it and it comes back.” This is a sort of way development has now evolved. So with the agile world, smaller teams can do things a lot faster, and that’s why giving them the tools they need means they can do that.
But this doesn’t mean we put testings out of business, as it were. Because we aim our stuff at the developer, for like the piece of function they’ve just written or for what that application is doing as a whole. There will always be a need for sort of larger-scale teams that need to oversee the entire application. So whereas before, if we take the example of the giant _____ monolith that was one giant application, you might find in today’s environment that that’s actually seven, eight, nine, ten small microservices. So a developer would be working on one microservice and he’d get the performance stats back from that microservice in isolation. But what about the bigger picture? What about when all ten of those are working together? How do you get the overall view of your microservice environment that’s 10, 20, 30 things all talking to each other? So that’s where you still have DevOps teams and other teams working on that. And there’s software for that as well.
So as an example, there’s Prometheus, that’s an open source monitoring solution that’s very good at taking data from different sources. And then what we do with the stuff that we add into the applications at the developer level so that the monitoring solutions we put into Microclimate for the developer, that will actually talk to Prometheus. Which means that if the developer is happy seeing their code running and their single microservice view of the world all looks good – “Yes, my database function is performing as I expect it too.” I’ll now put it into the cloud where there’s 20 other microservices running, all talking. And Prometheus, that sits over and above all of this, can now take the data from each of those 20, and the data they’ll be taking will be the same data that the developer has already been seeing when running it locally or in the small view. We just pass it up through. So this again gives the developer an easy way of seeing – or actually in fact _____ ____, the SysOps guys, what their applications are doing without any additional changes. Because the code has been in there from day one to provide this information.
Now that’s one of the hardest things about monitoring. It’s, how do we get at the data? If you can get at the data, there’s plenty of ways to visualize it. All sorts of fantastic tools, even the simplest of just writing out to the screen. It’s always the case of, how do we get to the information? So we build the information in from day one, and that’s what makes Microclimate so cool, as it were, because it’s just there for you. And no matter what sort of environment you run in, we’ll be able to make the data available to see the performance at any level.
Shimel: You know, Toby, that’s excellent. Hey, when we started – before we started recording I told you, “You’re going to be surprised when I tell you, ‘Hey, we’re going over time.’”
Corbin: [Laughs].
Shimel: So we’re really way over. That was a difficult interview. It was pulling teeth to get you to talk to us.
Corbin: [Laughs]. I’m sorry.
Shimel: No, not a problem. Toby Corbin, IBM’s Microclimate Developer Experience Tribe, thanks for being our guest on DevOps Chat today, and continued success with the Cloud Private team at IBM.
Corbin: Thank you very much for having me on, Alan.
Shimel: My pleasure. This is Alan Shimel. DevOps.com. You’ve just listened to another DevOps Chat.
