Episode 30: The Hybrid Cloud Forecast Series - Outlook: Cloud Transformation

Speaker 1: You are listening to the Hybrid Cloud Podcast where the forecast here is always compelling as we discuss real- life challenges, successes, and stories from the journey to Hybrid Cloud with your host, Andre Tost.

Andre Tost: All right, welcome everyone, and thanks for listening to another episode of the Hybrid Cloud's Forecast podcast series. Today I have the pleasure of welcoming AB Vijay as our guest. Thanks a lot for joining AB.

AB Vijay: Thanks a lot, Andre, thanks for this opportunity. It's exciting.

Andre Tost: So AB is actually in awe, obviously this is the Hybrid Cloud podcast and his title is, he's an IBM fellow, but he's also the CTO of Hybrid Cloud management in IBM and we'll obviously hear more about that. But maybe as always we should start with introductions AB, if you could just tell us a bit about your background, your history, kind of how you got to be where you are today, and maybe a bit about what you're doing at IBM today.

AB Vijay: Just a quick correction there. So I just got into a new role. I'm the CTO for Hybrid Cloud services now, which includes both Hybrid Cloud transformation and management. So anyway, so about me, I'm from Bangalore, India. I've been with IBM for more than 25 years now. IBM is my first job. I did work on various technologies, mostly in the delivery side, delivering client projects in the area of systems programming, application programming. Now more and more cloud, I'm an IBM fellow, I have around 60 patents in my name. I'm also a master inventor. Like I said, I just got promoted to be the CTO for Hybrid Cloud services. So which is basically all the way from advising our clients on how to build a Hybrid Cloud strategy to building the Hybrid Cloud strategy, helping them move, migrate, modernize their workloads onto cloud, and then of course managing those workloads on the cloud.

Andre Tost: Excellent. You mentioned various things that I want to poke at a little more of course. But maybe we should start out by simply a definition of what Hybrid Cloud, what you think Hybrid Cloud is and what its definition is in the context of your job role.

AB Vijay: If you look at most of the clients, they have already invested quite a lot in their data centers. They already have very stable applications that they have been running through these data centers. When the cloud revolution started, there were initially a lot of resistance in a lot of these enterprises getting onto the cloud journey. So they were still not very clear in terms of what is the security privacy, what is the total cost of ownership and things like that. But over a period of time as the cloud matured, what we have started seeing is all these large enterprises have started embracing cloud. I mean, initially some clients really looked at, hey, can I just close my data center more a hundred percent on cloud? But most of the clients realized that a hybrid strategy would be much better rather than moving everything onto the cloud mainly because of the compliance reasons, security reasons or the stability reasons. Could also be because of the comfort that they had with the system. So more and more the clients, what they're doing as they are moving towards the cloud, they want to retain some applications on- prem. Some applications are on the cloud, public cloud, some of them are on private cloud. So what we really mean from the Hybrid Cloud standpoint is basically covering all of these various types of workloads. Our focus is to provide the consulting services as IBM for all of these workloads.

Andre Tost: Okay. This is pretty common I think in terms of the definitions that are here for my guests is that it's a very broad definition of Hybrid Cloud as with respect to location being very flexible, respect to location, but also the types of applications that it goes about. So coming back to your job title, you said there's Hybrid Cloud management, but there's also Hybrid Cloud transformation. So I'd like to dig a little into both of these. When we talk about transformation, what does that actually mean? So if I am an enterprise and I'm running my own IT and my own data center in whatever way, and then now IBM approaches me and say we can help you get to the Hybrid Cloud, what does that mean in concrete terms? Maybe you can have some examples of what that entails.

AB Vijay: The way we are organized in IBM, unlike I said in Hybrid Cloud services, under Hybrid Cloud services, we have Hybrid Cloud transformation and Hybrid Cloud manage. Most of our clients that we work with from the transformation standpoint, it all starts with having a conversation in terms of how can I help my client move their workloads to cloud and what kind of cloud strategy should I be using? Should it be a private cloud, should it be on a public cloud or should it be an edge, for example? It requires lot of thinking, lot of conversations that we have with the clients and that is what we do as part of Hybrid Cloud advice. So when we say advice, what we are really trying to do is we are discovering what applications do they have, what technologies are they using and what is the overall roadmap for moving these workloads onto the cloud? When we do that, the obvious focus is on their non- functional requirements such as what is their current security, what is their current privacy compliance and things like that, performance of course. More importantly, what is the cost that they are spending right now and how cloud can help them reduce the overall total cost of ownership? So all this strategy work comes under Hybrid Cloud transformation advice. Once we advise our clients, typically we come up with a roadmap which might say, hey, these are the workloads that can move on to the cloud. These are the workloads that cannot move as it is onto the cloud, it might read a little bit of refactoring. These are the type of workloads which does not make sense for you to move to the cloud, maybe you keep it on- prem or completely rewrite them. So there are various types of measures that we use to identify which kind of workloads follow what kind of a journey, and that is what comes out of the roadmap. From the roadmap you can either follow two major path, one is move or migrate or modernize or the second path is build a fresh application. So that comes under build and move as part of the Hybrid Cloud transformation. Now it is not just enough for us to help our clients to move their workloads or build up workloads on cloud, it's also important to manage them, what we call the data. The manage is very, very important though we, and that comes under hybrid floor management. When we are building or when we are moving these applications onto the cloud, we focus on how manageable these applications are going to be. That's where we bring in our practices of site reliability, engineering, bringing in a lot of automation, observability so that when the applications move on to the cloud, the manage piece is not an afterthought where as much as possible the management is done in a self- healing way with automation and AI. So all of those topics will come on Hybrid Cloud management. Am I making sense?

Andre Tost: Yeah, that makes perfect sense. Coming back to the... You said the assessment of the applications and which applications to move, is there a typical mix that you see? So it starts out with what I always call this lift and shift. I take an app, I don't touch it, I'm just running it in a different place so that I don't have to worry about say the infrastructure anymore, somebody is running the servers for me and I don't need to worry about that. But the software layer remains intact versus truly modernizing, refactoring, whatever you might want to call it, which entails touching the application, making changes to it, making it better so to speak, or more suited for the kind of cloud environment that are running in it. What kind of mix do you see in terms of maybe even percentage of how much do you see a list and shift versus true modernization of applications?

AB Vijay: It actually depends on the type of technology that we talk about. So the recent client I'm working on, they have huge SAP workload and around 800 plus applications is what they have and most of them are SAP and most of them are already running in a VM. So it is very naturally easy for me to lift and shift such VMs. The client actually has a plan to shut down their data centers and move a hundred percent onto the cloud and we are moving it to AWS cloud in this case. So the strategy is more in terms of first, obviously first we build the landing zones on the target cloud, the landing zone will have all your security policies and how are you going to do observability, how are you going to do overall fin- offs for example, and things like that. So we kind of build that boilerplate or the landing zone and then once that is done, we are looking at moving all of these workloads onto the cloud and watching how they perform before we think of any modernization or migration. So it depends on the client and on the other hand you have clients who want to modernize before they move some of their workloads. So it really depends upon, it all boils down to how mature the application is written and sometimes you end up with a lot of performance issues and lot of costs if you just lift and shift blindly. So you'll have to do an assessment because you would've built a monolith. One good thing about data center is you don't pay as you go, but when you go on cloud, you are paying for every CPU cycle, every RAM that you're using and things like that. Now the biggest issue is if you take a monolith as it is and move it to cloud, you might be spending more money on cloud than keeping it in data center. So for such applications it's important to understand even before that's what we do in advice, in terms of, as part of advice, we go through the application portfolio, what type of application is this, what is the technology stack that you have and help our clients decide in terms of whether you have to modernize before you move or you have to migrate, lift and shift as it is or make slight tweaks before you move. So percentage is very difficult because it depends, but typically if you look at the modern ways of doing things, I mean if it is a modern technology. Already the current applications are all built on modern technology. We migrate a lot. While if it is a legacy technology, we modernize a lot.

Andre Tost: When you say legacy, does that include even things like programming language, platform it runs on? I guess one of the questions I would have for you is how much do you see hardware architectures playing a role in there, things that run maybe on a mainframe today and moving those and what it means to" refactor" those?

AB Vijay: Yeah, that's a very good point. See there are multiple layers to this, right? Obviously it starts with the hardware infrastructure. So there are some workloads that you cannot run on cloud. These are very old legacy applications that you have. Typically, and the client might decide because it's a very, very banking for example, so a lot of banks I work with, what they say is, hey, my core banking system is running on mainframe and AS400 applications. I don't want to touch it, but I want to build a layer on top of it which allows me to build modern applications on cloud. So the AI part of it or the mobile front end or the web front ends, all that can be on cloud, but I want the core banking system to be here where all the transactions are coming. So there are architectures like that that we propose. To answer your question, it basically starts with the infrastructure. Is this an operating system or a middleware that you have that I can migrate as it is? If it is, like I said, if it is already virtualized in some form, like on a VMware or something, it's a very good candidate for us to move faster. We don't have to modernize a lot. But if it is not virtualized, if it is a legacy programming language, if it is a legacy architecture, like you build it on systems but it doesn't support Intel architecture for example, it is very difficult for us to lift and shift. You'll have to modernize programming languages. Yeah, you are right. I mean all the legacy programming languages we modernize a lot like COBOL for example, you might want to modernize if you really want to move to cloud. Otherwise, the real benefit of running applications on cloud comes when you use a microservices kind of a mindset rather than a kind of a mindset because you need to scale up and scale down at a functional level, not at an application level. Only then you have all the control in terms of, okay, during Christmas these are the functionalities that are predominantly used. I want to scale up only those functionality rather than the ones, otherwise you'll end up scaling up the whole application and it ends up eating more and more CPU and all the resources and you end up paying more and more. So again, the architecture is another thing that will help you decide whether you want to move or modernize.

Andre Tost: How do you deal with the fact that, and I've come across various examples of this where clients of ours were saying we would like to bring some of the applications onto the cloud in an isolated kind of fashion, but there's very few applications that are actually isolated. Everything depends on say, an existing way of obtaining system of record data for example, using some MQ connection tools, a core banking system like you mentioned as an example, on a mainframe, right? So that it turns out in a spider web of dependencies between all applications and to then say, how can I just grab a few of those and pull them out without breaking all the dependencies that they have on the existing systems?

AB Vijay: APIfication is one of the primary things that we start off with in such scenarios. For this bank that I'm working on, they have this core banking system which they don't want to touch for very good reasons because of compliance, because of the whole bank runs on it. So what we really started doing is going for an API and more importantly event- driven approach towards that because we don't want to have too much of... Because we know this has to scale up. So this whole applications that we built on top of core banking system should scale and we are talking of millions of users who will be using their mobile phones or their web applications to ask about, let's say, to do transfers of money or to buy something online or things like that. In such cases what we really do is we look at an event- driven approach and an API layer which exposes the core banking or core functionality and build our cloud applications on top of it. That way it is a very scalable architecture and once we do that, you are hiding the legacy system and there could be some of those legacy components which we slowly modernize over a period of time, which doesn't affect the consumers because they are still accessing through the API. We do this blue- green deployment, canary deployment so that they don't even know that we modernize the backend applications. So these are some approaches that we use and there are various, like you said in our MQ-based or Kafka-based applications that we expose through that.

Andre Tost: Do you see certain industries or do you see different behaviors in different industries? Obviously we use banking a lot as an example. Banks are obviously very IT heavy, IT centric, but you see other industries doing all the same things or does it depend?

AB Vijay: Each industry they have their own. See, it all goes down to, point number one is, what is your compliance security, privacy policies, right? Point number two is, how risk- award are you? Point number three is, what is your TCO right now? Will cloud improve your TCO? So it's not really the functional things that really matter. It is all these non- functional aspects which help you decide which industry is doing better than other. If you take retail for example, there are a lot of born on cloud on retail that you will see and it's very easy for them and it is very intuitive for them to go onto the cloud- based models rather than the banks who still are, they are willing to go, but they still have this, they can't go a hundred percent onto the cloud. But having said that, when I said cloud, again, I don't mean public cloud here, it's based on the, they cannot modernize everything that is there because the core banking systems like manufacturing systems for example, they're all built on legacy platforms and they cannot throw away those supply chain systems, for example. So you can't just throw away that and build a new Kubernetes- based, Microsoft- based architectures out of it. So they're all going to be monoliths. You have to live with those monoliths. Then you look at your TCO, is it making sense for me to move this onto a cloud? What is the cost of running that monolith on cloud versus keeping it in data center and things like that. So those are all the decisions that we take. So again, you will find different types even in banking, there are banks who are embracing cloud- native mindset, a microservices mindset, more and more now. Of course they're a little slow compared to retail for example, who embraced it much faster.

Andre Tost: You said, and by the way, I assume when you say public cloud, you're pretty agnostic as far as which cloud that is. So it could be all of the usual candidates, it could be IBM's of course, but it could all be Amazon or Google or Azure and so forth, right?

AB Vijay: Yeah.

Andre Tost: You mentioned earlier that it could also be Edge. Can you give an example of what is running on the Edge today?

AB Vijay: If you look at Edge is becoming more and more prominent now because you have manufacturing plants, you have shops where you have computers now. So we are looking at real- time insights, real- time analytics. Now if you have all your applications on a public cloud and you have to transfer all the data all the way to the cloud to do analytics, for example, real- time analytics or streaming analytics, one, you are spending a lot of money on egress, egress and all that. Two, there is a point of failure, one single point of failure where there might be delays in the network and things like that. So what we are moving more and more towards is a distributed architecture with Edge where now the Edge architectures have become very mature. Now we are able to run, I would say micro clouds or whatever is the right word for that, right? You can have a micro version of Kubernetes for example, running on a Raspberry Pi microcontroller. Now the advantage of doing that is I can actually do most of the data filtering to certain extent, AI and control the sensors, give real- time insights as much as possible at the Edge and move some of the workloads to the Edge and only send summary data or the consolidation of what has happened to the main cloud. That way I'm saving a lot on egress ingress, I'm saving a lot on my CPU, the CPU cycle, neutralizations on cloud, and I'm getting real- time analytics. That's one use case. There are a lot of use cases and you'll find that a lot in manufacturing systems because when you are doing, for example, work- in- progress tracking of a car, there's a lot of logic that you need to do then and there, very close to the PLCs, very close to the conveyor belt, which is carrying your chassis. You can't be streaming all the, and there's just crazy amount of data that goes through all the IOT sensors that you have and correlating what's happening between these IOT and data coming across multiple sensors at server side or at the cloud side and alerting might delay and in which case you might lose something. So those are all very good use cases where we are doing it in delivery. Now when I say delivery, I meant the logistics. So all the logistics company are embracing Edge kind of a model, manufacturing, like I said, even banks, retail banks are looking at, hey, can I use Edge- based analytics rather than go every time, go onto the server side and things like that.

Andre Tost: So that seems to be something I'm hearing a lot is just like you said, there is more and more data now and there is more and more that companies want to do with that data and apply analytics and just plain intelligence to that data. At the same time that is countered by moving data is the most expensive thing you can do in this space of cloud computing in general. So there seems to be this desire to leave the data where it is and do most of the processing as close to the data of a source of the data as possible, simply for efficiency and cost reasons.

AB Vijay: We're moving the process instead of data right so and the maturity of the cloud, if you look at the cloud software that you have, like Kubernetes, all these, they allow you to do this in a very efficient and optimized way. So that is also allowing you to do this. Your overall DevSecOps. Having a single control plane- based model with something like Kubernetes- based architecture allows you to deploy the workloads closer to the data rather than get the data to the process.

Andre Tost: Well it's a good point. I was going to mention that is... It is a bit of a cultural change in terms of how you built your applications, how you maintain your applications, how you manage them. You mentioned management earlier, right? So let's say management includes things like logging and tracing and security obviously being a big deal. Often the cloud comes with its own stack of tools and processes in ways and in which you run these, in which you do these, in which you define... Every cloud has its own way of defining security policies, for example, that control access to certain things. I would assume that that's where the bulk of the work lies. Just like you said, not necessarily changing what the application does, but changing how you keep it alive so to speak.

AB Vijay: The best part is, of course it's very important to build applications which are manageable, but the best part of this cloud stack architecture is everything is core. So your infrastructure is core, your policy is core now, and then your overall pipelines that you do on how you want to build and where you want to deploy is core. Of course your application is also a core and your data pipelines is also core. So the best part of that is it's become very easy for us to inject policies onto the applications. A lot of the application... So application programmers focus mainly on the application logic. They don't worry about, hey, how do I do security or policy or things like that. So it gets injected into the core depending upon where you're deploying and how you are deploying the core. So that is a beautiful thing because that again helps you in terms of having a very systematic way of deploying applications and managing more importantly, like you said, managing the applications. If your observability is zero, there is no way you can manage the applications because it's not like a data center where the computer is and you sit in front of the computer, login into the computer, you know what processes you are running there. Here you are distributing the workloads in a Hybrid Cloud scenario. You might have workloads on Edge, you might have it on- prem, you might have it in a private cloud or some of the workloads might be on a public cloud. Sometimes some clients have some workloads on Google, some workloads on AWS, right? So it gets very messy because of this distributed nature. More and more you embrace microservices, you are going more and more distributed. So from day one, that's what we say. I mean we call this day zero where you design an architect. Day one is where you build. Day two is where you manage. So the philosophy is on day zero, you think about day two. So how are you going to build these applications manageable? What will be your GitOps pipe? How will you code your policies? How will you code your security? What is the overall observability and AIOps engine that I'm going to run on top of it so that on day one you code these as part of your infrastructure code so that when an application developer comes and deploys through your infrastructure code, all of these things kind of come together.

Andre Tost: How do you, at the end of all this, how do you measure success? So obviously cost is one, but just also like you mentioned, sometimes that backfires because there is this blind assumption that if I'm going to the cloud, I'm going to save money, which is not always true. So what other factors are there to measure the benefits of a transformation like the ones that you've been describing?

AB Vijay: I think the key measure, obviously the cost, keeping cost aside, so cost is very key. The TCO rather than just cost, right? The business agility is another very, very important factor. That's one of the motivation factors for a lot of our clients to move to cloud because they want to quickly roll out applications or change in the logic in the applications, and they want to scale very, very quickly. So if they want to scale up in terms of number of users or new geos they want to roll out. So they want to do that. So that is... It is business agility and scalability I would say, right, is very, very important factor that is helping decide the success or failure of a cloud implementation. Third very important thing is in terms of the manageability, right? So when I say there is a cost aspect to the manageability, but then there is also a qualitative thing on top of it in terms of how manageable is your portfolio of applications. In general, I have seen it's much easier for you to manage applications on cloud if they have written, if you have done the right things versus having applications running on data center. What it helps you do is you can constantly look at which are the applications I'm really using. There are tools like Turbonomic for example, which helps you say, okay, what is your overall application resource management and optimizations that you can bring in? So there is an opportunity for you to continuously modernize and optimize your portfolio, which is not happening because here in data centers, in traditional way, you just have those applications running. You don't know who is using what applications and things like that. But the visibility of these applications' usage, the resources that it uses is very, very mature on a cloud rather than on- prem I would say. So what allows you to do is it also indirectly impacts your TCO, end of the day because you don't have any junk applications that are still running, but more importantly your portfolio is much more clean and where you're spending your money and how you can prioritize those applications and based on the business priorities that are changing.

Andre Tost: Now, unfortunately, I'm looking at the ticking clock here, we've almost run out of time, but I don't want to let you go before asking the final question, which I always ask at the end of each of these episodes. That is if you can give us an example of something that you're working on right now that really excites you, something really cool that makes you want to get to work in the morning, so to speak, any kind of project that you could share with us?

AB Vijay: Officially and unofficially both of them, I'll tell you. So officially, so right now I just took up this role, like I said in the beginning. So I'm trying to understand the scope of this work. It's apparently much broader than what I was doing till last year. I'm given this challenge in terms of how we can optimize the way. So first of all, we need to integrate the whole storyline from advice inaudible all the way to manage and the day two thinking on day zero is the other thing. So accordingly, what I'm working on is in terms of, so we have this platform that we had already announced called ICCA, I think it's called IBM Consulting Cloud Accelerator. So that is what I am looking at in terms of being the one platform which will bring all these phases together in a way of journey. It is, the work has already started when I took up the role and my job is to now take it to the next level in terms of how we have this day, day two thinking in day zero, so that when you go through the journey, you are ensuring that you are bringing day two aspects into it. Then of course I'm working with a couple of clients where we are talking of large migrations and modernization, all the good stuff in terms of coming up with the strategy for them. There are clients which I'm working on, where things are not working well for them. So I'm sitting with them, their TCO is way too high, so how can we optimize that? So that is the other thing that I'm doing. On the personal front, I do a lot of Raspberry Pi programming and all that inaudible. So I'm now set up the Raspberry Pi cluster, Kubernetes cluster. I do a lot of blogs because of all the work that I do in office, I kind of purify myself by writing a lot of code. So I don't want to lose the coding practice. So if you look at most of the blogs that I write is more in the coding space where I'm building the whole book library application and putting it on inaudible. Walking through inaudible.

Andre Tost: Okay, very interesting. I mean, if people could see me, they would see me smiling because there was a time when I played a lot with Raspberry Pi's, I have a whole bunch of them at home. I've kind of dropped that. Every now and then, I think I should pick it up again because there's so much fun to work with. Especially so I've never tried to run a Kubernetes cluster on Raspberry Pi. So maybe you should share your blog link. Could maybe even put that in the description for this podcast, right?

AB Vijay: Yeah, sure. inaudible.

Andre Tost: Go check it out. All right, very cool. Thank you so much for joining us today AB. That was some great insight. Thanks for sharing that.

AB Vijay: Yeah, sure. Thanks for this opportunity. I enjoyed talking to you.

Andre Tost: All right, well and with that we'll wrap up today's episode. I want to thank everyone for listening and hope to see you all again soon. Bye- Bye.