Kevin Montalbo

As organizations begin their cloud adoption journey, they quickly discover that there can be several barriers that hinder their progress towards digital transformation. These may include factors such as legacy operating models, outdated processes and organizational resistance to change. Our guest for today focuses on the human side of digital transformation rather than technology. He talks about the organizational mindset that is needed to ensure a smooth transition to the cloud. 

Joining us today from Australia is Toro cloud’s CEO and founder and Cocktail's co-host David Brown. Hi David.

David Brown

Hi Kevin.

Kevin Montalbo

Our guest for today is the author of architecting the cloud design decisions for cloud computing service models and the upcoming book accelerating cloud adoption, optimizing the enterprise for speed and agility, which we'll be talking about today, a pioneer in cloud computing. Our guest has also been ranked as one of the top 100 cloud experts and influencers in the world. 

He's currently the chief cloud architect in Deloitte, consulting LLPS cloud practice responsible for helping clients implement cloud strategy and architecture to drive digital transformation. Beyond his technology experience, he brings an insightful understanding of how to address the organizational change process improvement and talent management challenges associated with digital transformation. Joining us for a round of cocktails is Mike Kavis.

Mike. Welcome to the show.

Mike Kavis

Hey, thanks for having me.

Kevin Montalbo

All right. So in your book, you said that to succeed with cloud adoption, you need to consider people process and technology. So we often focus on the technology side of the equation when considering cloud related projects, right? So can you elaborate on the considerations associated with people and processes?

Mike Kavis

Yeah. And that's, that's why I wrote the book cause my first book was about the technology because when I started on cloud, it was 2007, 2008 and there were no books and I learned a lot of stuff the hard way. So I said the next person shouldn't have to make all the mistakes I had. So here's what I learned. And then as I still that business gone consulting, I started seeing the struggles of all these companies, they would have all the smartest people in the world, but they just couldn't get enough stuff into the cloud. They could never turn off the old stuff. And the patterns I kept seeing were legacy processes, legacy orb structures, legacy tools that were preventing them from moving to the cloud. As fast as they would as fast as they wanted. So an an example often is, you know, a lot of companies focus on CICD. So, you know, we have clients that have a great automated pipeline, but there's three months of process before they can hit the button to create it to go to stage. And there's another three months of process to put it in production because we still have these silos that have to do all these approvals, even though we automated all of it in the CICD pipeline. 

So that's, that's one example with that and, and then when it comes to run to run the system, we try to run it the way we always have with a separate group over here that knows nothing about our cloud implementation. And then all of a sudden our reliability goes down when there's an incident because we're, we're trying to do things with tools that don't work in the cloud and with processes that were built for, you know, biannual releases on a mainframe, not daily releases in the cloud. So, you know, too often the focus is purely on technology, but we need to change the org supporting org structures, the operating model and supporting business processes at the same speed that we're changing to technology.

David Brown

Yeah, you mentioned this CICD pipelines and I think that's where a lot of people started with, you know, becoming an agile organization is to, you know, focus on the build process, right? But it goes way beyond that, right? And a lot of people have solved that problem, they have some sort of automated build process. But you know, when we're talking about cloud adoption and digital transformation, we we're talking about a lot more than that, right?

Mike Kavis

a whole lot more and a lot of it is just pure mindset. So, you know, traditionally we were organizing technology silos, right? So when I wanted to get work done, I needed to go talk to the database team, the server team, the storage team, the network team. And as we moved to the cloud, a lot of that stuff is subtracted in its code. So we put these pipelines in place, right? The problem is we still need to get approval from the server team, the storage team, the network team. And and there's also this, this fear that this cloud is this big and insecure place and reality is with the right rigor, it can actually be more secure than what you have on crime. The the problem is there's a lot of old thinking. Another example I use is a lot of people think of the cloud as someone else's data center. 

Anytime you hear someone say clouds, just someone else's data center, they're on a path to failure because that means they're gonna treat the cloud like a data center, right? I got a VM here, I'm gonna have a VM there and the cloud is much more than that. The value in the cloud is when you start moving up the stack and you use database as a service right now. All of a sudden you have a fully managed database that auto scales across its zones and regions. I can instead of implementing my own Kafka Q, I could use a Q as a service, right? So I don't have to worry about scaling and managing these third party solutions. So the the value is going up that food chain per se and and in the cloud vendors now are even creating healthcare APIs and financially, they're even moving up the stack to business services as a service. And when you're allowed to, to go up to stack like that, the, the speed at which you could deliver software is incredible. And what you focus on is your specific requirements instead of all the plumbing in the commoditized business process.

David Brown

That's as I understand it, your basic premise is that whilst cloud technologies offer this agility and speed of the services that you can leverage. Many organizations are bringing to that new paradigm, they're all processes of bureaucracy within a la large organization.

Mike Kavis

A absolutely. And it's, it's kind of worse than that. So no matter how good or bad your processes are in your data center, they're known, right? So when there's an issue, no matter how good or bad a company is at resolving it, there's tribal knowledge and they figure it out, then you move through this blank canvas in the cloud and what people do is they focus on building the software but then something breaks. And first of all, all those old processes don't apply because there's no physical infrastructure anymore. So what, what, what I see often is reliability actually goes down because they never rethought how you respond to incidents in a world where half the stuff is abstracted from you. So you run, I see it so often and then you, you see these companies, you know, going back to the data center. It's not because the cloud isn't any good. It's because their approach to the cloud, you know, created a lot of failure.

David Brown

All right. So I guess the obvious question then is, is how, how should they be approaching the cloud adoption? So how can they overcome this? You know, when you're talking about a large organization, it's easier said than done to break down processes which have been put in place for a reason over time. And it's how, you know, a large organization can become a sausage machine because they have those processes in place. How do you break down those processes become a more agile organization when looking at, you know, adopting cloud technologies? Yeah,

Mike Kavis

it's easy to write stuff down on paper, but it's hard to actually do it. So there's a lot of methodologies and processes you can use to like value stream map and you can go analyze processes and figure out where the waste is and remove it. But if you can't get everybody in the room to talk about it because they're holding on to their turf or even if you say, well, there's 60% waste in this process. Why don't you move this team to that team and create, create this, you know, cloud operations team. But there's politics involved. So it's easy to recommend methodologies to identify waste and redesign it. But it's hard to break down the political barriers and break and change the kind of the mindset of the why. So I talk, in the book, I give a lot of examples of both companies that applied something that didn't work and companies that applied stuff that did work. I don't really have the answer in the magic bullet in there. But what I do is create awareness, you know, these things in my experience work better than these approaches and, and a big part of it is the operating model, right? You, you really need, I mean, Adrian Cocker off, I don't know if you know Adrian from Netflix fame always said DevOps is an org change. 

He, said that years ago and, and cloud is even a bigger org change, right? And, and why do we say that because we're building software entirely different than we had before? It doesn't make sense to put teams of domain expertise anymore, you know, server team storage team, network team because all this stuff's in api a now. So now what we need is we need the brains from the storage people, the network people to sit in a room with us and help architect virtual private clouds and figure out what's the right storage unit to use. But we don't need them turning screwdrivers and patching devices anymore. So we still need those people probably more than ever before, but we need their engineering minds, not their administrative minds. And when they're in silos and I'm trying to deliver daily, I can't be sending tickets and having meetings and cab reviews cause that you can't do that in a day, right? When software is being deployed a day, so you really have to change things. It has to be more collaborative, more engaged of. 

And I really recommend teams are focused, more product oriented as opposed to, you can still have your center of excellence, but you pull from there and you have security engineers on your product, right? So that way you don't need 58 meetings to get you, you have someone with that expertise and they can go back to the security well, when they need to, to get answers, but you have a full stack team there with shared goals and those shared goals are the goals of the product, right? So that, that's the formula that works. It's real easy to say that it's incredibly hard to, to change the heart and souls of the corporations to, to get them to move that way.

David Brown

We talked about this recently in terms of the the differences between monolithic application design and microservices and how with monolithic application design, you tend to have your front end developers, your service layer, your database security engineers and the like and like you said, they're all different disciplines and in a monolithic design of an application that can work because you're talking about lo long periods of time where the communication can be facilitated between those engineering teams. 

But in a microservices world, what tends to work better is bringing those teams into a single team around a domain of knowledge or a product knowledge as you were just saying, so you know, it might if you're building the service for a shopping cart, then you have the shopping cart team. And so everyone is working collaborative, collaborative on that domain of knowledge. And and so then the the the issue becomes, how does that team collaborate with other teams? Because whilst they can have agility inside that team, they still need to collaborate with other stakeholders, other stakeholders are dependent on the services they create, right? And so how, how do you, how do you see that sort of communication?

Mike Kavis

Well, I mean, if you look at what Amazon does, right? Amazon provides all these services. Each one of those teams is a product team with their own culture. So what the only requirement Bezos puts on them is that the interface is the same the API interface, but they can go solve that problem any way they want and they have AAA culture of collaboration to do that. It within companies. It's a, it's a lot harder because they're not used to, to operate in that way. But if you take that approach and get a standard API interface, you may not be able to have the level of collaboration that some of the unicorn companies do, but you can be kind of self sufficient in the service you deliver, right? If it's loosely coupled, you can deliver that service. It may not satisfy the customer at the end of the day because they need these other things. But at least you can, can deliver what's expected of, of your group. But they're, they're really a again, this goes back to operating models. If everyone's in silos, it's, it's harder to get them to communicate. 

If, if I'm building a product, I, you know, I wanna either Colo or now everyone's virtual. But II, I wanna set up ways that people can meet either virtually or in real time. A and their day is focused marching towards the same product goals. It's, it's really, you know, it's a culture, it's a culture thing, but I, I wanna add one thing to the monolith story you were painting there. There's a no and I've been both a victim and a criminal of this is a lot of times in the monolith because we're in those silos, you know, the database team is supporting many, many teams. So a lot of times they can't service my needs. So sometimes I solve a problem that should have been solved in the database in the U I layer, the middle tier. So I I work around the bottlenecks. So, you know, monoliths are hard as they are, but it becomes like this, I call this trailer park architecture. You just start, you don't do the right things all the time. You do the things that help you get it out the door. 

So you, you code around bottlenecks, you just get the Spaghetti architecture that you know, every release is just more technical depth. Now, on the microservice side, you could go down a rat hole there pretty quick too, right? You know, microservices are great. But how do you manage, you know, 100 microservices, especially if you know, three teams are writing at the wrong level of granularity. And you know, it it can become a mess. I've seen spider graphs of micro services where there's like, like someone fell asleep, drawn the crayon. I'm like, how do you manage all that? So you know, m services can create challenges too and they require new tools and new processes and new ways to monitor and you start getting into things like AI ops, right? Humans can't process, you know, 250 microservices run at the same time. So we need to look at new ways of operations. So there's no easy ticket,

David Brown

I guess there's also some efficiencies in the monolithic approach in that when you do have that database team, which is in demand by lots of different project teams. And so their resources are being allocated by the it manager according to priority or who has the loudest voice that at least those resources are being efficiently used, you know that they're being run at maximum capacity all the time,, in, in what we're talking about by breaking them down into independent teams working on a single product or domain of knowledge. 

Um, I guess we're talking about, you know, it sounds like a lot more people. You, you now have database engineers across every product. And so is there a danger that we're just increasing cost and expense and, and what used to be an efficient model where it was driven by almost a capitalistic approach to, you know, what, what project had the highest, you know, return on investment as opposed to, you know, replicating our teams across multiple product domains. Yeah,

Mike Kavis

I don't, I don't think there's a difference between being very busy and being efficient. So, yeah, the database teams were very busy but normally not efficient. Right. And you don't need more and more people to do microservices, you're delivering smaller batches, so you're actually delivering more frequently. And hopefully if you have a architectural vision you're inheriting the work you did in the previous releases, right? So you're not creating from scratch all the time. So if you have good architecture, you know, with every release, you can start consuming all your other services, just going back to that monolithic model again. You know, you with every release, your architecture usually gets worse, right? Because you're, you know, like I said, people are skating around the bottlenecks. And the other, the other important point, you know, when I was working for a large company, regardless of what my business problem was. 

Oracle was the answer for OLTP. And NASA was the answer for, for transactional data. Right. Well, what if I had a requirement for document store database? Well, I had a stick at one of those two. What if I had a graph date? You know, I didn't have those options because you would have to go through a procurement process, which was usually longer than my project and do a RFP and evaluation, then we'd have to hire DBAs that could do that. And we'd have to, you know, it's a year right now. It's an API call and I don't need a DBA to, for a Mango database because it's an API call. So now I can build architectures that choose the right tools for the job instead of having to shove everything in the oracle like I always used to have. So, yeah, those oracle people were busy but it wasn't the most productive work because we were making bad technology choices.

David Brown

And, and I guess that leads to agility that organizational units can now adopt software or cloud platforms on their own independently. And as a result, the it department that centralized it department which used to manage the procurement process and deployment process has lost control. This shadow it concept.

Mike Kavis

Yeah. So there's good and bad to that. And a lot of the book talks about those types of opera mis, talks about Federated versus centralized versus decentralized. And I go in and say, what's the pros and cons of it? Well, the, the pros of the decentralized model where my business unit, you know, controls things as I can move as fast as I want. nothing's prescriptive, I can choose the technology I want. The cons is if I'm not really good at security, I can really damage the company's reputation, right. So often what I see, a lot of companies all depends. If the company is one that has bought in a lot of start ups or a lot of web properties. Usually there's so much cloud skills in those groups because they're born in the cloud that you know, the it's, it's a decentralized model. And what they try to do is build a Federated model that says, OK, what, what kind of services do we need to centralize? And usually that focuses around, OK, we need to get control of the operating system, at least. Right. And create the most patched operating system and let them pull from that. There, there are some services but usually when it's top down, it's entirely centralized. Right? We control everything to the point where you can't get anything done because it's just another data center in the sky. Right. So they follow the same processes. It's OK to start there because you don't wanna start everyone doing their own thing. But at some point as your practice matures, you should start allowing business units to take on some responsibilities, right? To move faster. 

So I think the ultimate, again, it depends on each company. But the, the promise land is kind of a Federated model where there's some level of some things we need to control essentially. And there's some things you have autonomy out in the business unit. So like in the financial institution, there's gonna be a lot more that's controlled internally for like a media company. Maybe the only thing they wanna control is maybe, you know, here's the tool selections you could use for CICD or you can use one of these three. but not 12, right? And here is, we're gonna give you the blueprints for, you know, Red Hat Os and Apache tomcat. We're gonna make sure that's patch and that's it, but it really varies on what you're trying to do. And then the other part of that, what I talked about in the book is there's a different engagement models for, for that central team is that I may have a real web savvy team that doesn't need my help. So I, they just need self-service capabilities, but I have this newbie group over here that doesn't know anything and they needed like a white glove service. And I think that's where a lot of companies go wrong is they treat everyone the same and it's usually to the lowest denominator of, of skills. So the teams with skills are just, they can't get their work done. So they just, you know, shadow it is born and, and flourishes.

David Brown

Interesting. Let's, let's talk about where we're at in the future. So, you know, we're talking about DevOps and Cloud ops and you've even mentioned a IOPS. So it seems like every, everything up. So it seems like it's constantly evolving and, and, and, you know, people could be adopting DevOps and thinking they're on the bleeding edge. But where do you think we realistically are? And where, where are we going?

Mike Kavis

Yeah. So I, that's, that's a good question. First of all, I like, I like to find what, what I think DevOps is cause a lot of people think DevOps is CICD, you know, the tools and that's a piece of it. But in my mind and if you talk to some of the, you know, the godfathers of DevOps like the Gene Kims and, and those guys, it, it's really about outcomes, right? It's really about how can we as an organization deliver software better, faster, more reliable and work, more product focussed. Th those types of characteristics now, part of working better and faster is automated CICD pipelines. But before you build an automated CICD pipelines, you may want to re evaluate the business processes otherwise you're just automating waste. So you're failing faster, but you're still failing. So with that out of the way that what I see is there's, there's a big challenge, there's so much change coming at us at the same time, right? That's why you have all these X ops, right? So it was DevOps. Then we said DevOps and AI ops yesterday. 

I was in a podcast and it was at IOPS, it's all ops, right? I in my mind, it's just the technology is different. So the approaches to it are different. But at the end of the day, you know, people bash it to frameworks, but those things still apply, you may not need to have the meetings that we're used to with it to, but you still need service request management, you still need capacity management, incident management problem. You still need those things, just you can solve a lot of those things through automation. And then the other thing that is happening is, you know, the cloud is a distributed environment. I was fortunate enough to grow up with in distributed environments. You know, I was always in retail where we had stores everywhere or, and you know, everything was distributed. So my learning curve was a lot less, but that's a different beast than the three tier architecture. We, we have a lot more to worry about and it's a lot harder to maintain. So what you're seeing is this boom in, in operations right now of new ways of thinking about ops and you start hearing terms like observ ability and chaos engineering, testing and production and and these things are, people wouldn't dream of purposely breaking things in production in, in the old world. 

But if I have, you know, 500 micro services running in hundreds of servers and sometimes you're there and sometimes you're not how, how do humans manage that through looking at dashboards? I mean, we, we need to be proactively finding flaws in our system and fixing them before our users encounter these issues. Like I mentioned earlier, a lot of people move to the cloud and suffer worse reliability to the systems. They move because it's, it's kind of a different game here and, and, and that is not good for the user. So I think there's a tremendous amount of good thinking happening in the world of operations and the companies that start embracing that even if it's slowly and start not thinking about how they operate things today, I think we have a lot more success in the cloud and, and AI and ML is a, is a piece of that, right? You know, AI is good at automating things that humans do, right? And when you're trying to monitor thousands and thousands of applications or containers or whatever, humans can't do that. So you, you let AI do it. ML is more better suited for discovering the unknowns, the unknown unknowns and you know, anticipate, you know, finding things that make you foul later that you don't know about and you can fix that in your code today. So I said a lot but and a lot of it is bias on my side because where I, even though I grew up on app development, most of my focus now is on things like SRE and you know, the operation side of it because I, that's where I see a lot of the challenges to

David Brown

and a lot of this stuff. you know, we're talking about automation. It, it such as microservices and, and container management with you, as you say, hundreds of thousands of microservices. Cloud adoption is not an option. It's a necessity, right? So it's not something you can, you can really realistically do in house. And so so increasingly cloud adoption in terms of hosting this stuff on a public cloud provider is a necessity which of course leads to the value added services of the A IOPS or to manage those services. And so it's going hand in hand. I think this orchestration and management of microservices and devops as well as the services to manage those. Would you agree?

Mike Kavis

I, would agree in, in one area I like to talk about is containers, right? So you know, Kernes is now the orchestration engine of choice, but people want to roll their own Kernes, right? And this cloud service providers have kind of co it's not called this, but they basically have Kernes as a service, right? And the amount of energy people spend to be cloud agnostic is quite incredible. And and you have to kind of ask the question at some point, what, what is portability really mean? Right. So people work so hard to be cloud agnostic. They don't get any value out of the cloud because the cloud is just compute, work in storage. So I can't, I don't know if I probably didn't answer your question. But anytime we start talking about capabilities of cloud, I, I think the ability to offload plumbing and it's not just infrastructure, it's at that middleware layer, it's even at the business layer, it, it's where the value is. 

So like a IOPS ML I, you know, I worked at a loyalty marketing company many years ago, we had, you know, petabyte of data before anyone had a petabyte of data. And we used to extract huge amounts of data and throw it into a SAS data set. And then these, they weren't called data scientists, but these SAS geniuses would do all this analysis and, and they would come up with hypotheses of things that they know. And, you know, six months later, we would have a new way to target employees or, or no employees, shoppers or we would have new ways to do analysis, post shopping trip. Today you could do it's an API, right? Or there's a model you can go get, you know, I had a team that provided all the next buy type analysis, right? If you're gonna shop, I think this is the next thing you're gonna buy. Therefore, we're gonna put this coupon come out when you shop in, you go to Amazon or Google, there's an API for that. Your purchase history says this you should get, you know, so I had a team of 89 people and tons of servers and, and now it's an API call, right? So the value of the cloud is there if you just go get it.

David Brown

So we're talking about outwardly, you're consuming services for machine learning and AI which again, I think you're largely forced to, with the investments being made by public cloud providers in those sort of spaces to leverage the APIs they're creating. And you talked about saving six months of engineering effort by using an API, but it also works in an inward fashion as well, right? So as I'm building applications and services, building up my databases and exposing them to teams throughout my organization. I also want to take the same approach, don't I? So in terms of exposing everything as api so that people can consume my services, extract the value out of it just the same way as you'd be consuming that machine learning service at a public cloud.

Mike Kavis

Absolutely. And I'm starting to see industry sink that way. So I was just talking to a CTO financial institution and they're doing a lot, they're trying to automate the process of the data science. Like right now, data scientists have to download stuff, the hard drive. I have all this work to do, which is non data scientists work to get to, you know, the models are created and they're trying to automate that. But at the same time, they're trying to create an environment where other companies can share models and it's the same thing with your code. If you're delivering a service that has a valuable data set, not only may it have value to provide that as an API within your company, but there may be opportunities to monetize that and offer it outside your company or not monetize it but offer it to a community who's also offering APIs back to you. 

So, you know, we we've heard about the API economy for a long time, you know, it comes from vendors trying management tools but I I think it's starting to get here. Right. I think, you know, the companies that have been in the cloud for four or 56 years who've gotten pretty good at this, they're, they're starting to move up that stack and, and they're not thinking about infrastructure anymore, they're thinking about data. Right. And they're thinking about how can we not write code? You know, how can I get the market faster with writing the least amount of code possible? And traditionally, we just love to write millions of lines of code. But then every line of code you write, you maintain.

David Brown

I'm very tempted to start talking about low code application development, but I think that's a whole different podcast. Yeah, look, Mike, it's been a great talk. Thank you very much for your time. How how can people learn more about you and your upcoming book?

Mike Kavis

Sure. So I'm on Twitter, Mad Greek 65 not mad geek, Mad Greek 65 and my daughter, I'll tell you a quick quick story. My, my daughter is a marketing major, right? And she built my website in the day and she doesn't know what a server is, right? So, talk about abstraction, right? She's using platforms and she's has is talented at content. And so if you go to Mikekavis.com Kav, as in Victor is, there's a website, has both my books, has a bunch of blogs as my podcast. She created that in a day and she doesn't even know one time we were talking servers. She goes, what's a server? Right. Well, she doesn't have to know what's a server and that, and we should think about that as we're building these things. Right. I can do IOT without knowing too much about IOT. I'm just consume APIs. But anyways, that's a long goodbye.

Kevin Montalbo

All right. That's it. Thank you very much, Mike for being here with us to our listeners. What did you think about this podcast? Have you ever experienced migrating to the cloud? Do you have any cloud success or cloud horror stories that you would like to share? Let us know in the comments from whatever podcast platform you're listening to. Also, please visit our website at www.torocloud.com for our blogs and our products. We're also on social media, Facebook, LinkedIn, Youtube, Twitter and Instagram, talk to us there. We'll listen, just look for Toro Cloud again. Thank you. Thank you very much for listening to us today. This has been Mike Kavis, David Brown and Kevin Montalbo at your service for Coding over cocktails.