PurePerformance - Digital Transformation: The Cloud is not your next data center with Mike Kavis
Episode Date: December 9, 2019If you lift & shift to the cloud or move things back from the cloud to on-premise you most likely didn’t understand cloud and how it can help you transform your business and organization. A bold sta...tement but very much true so as we learn in our conversation with Mike Kavis, Chief Cloud Architect at Deloitte.Mike (@madgreek65) has been in technology for 35+ years and was an early adopter of cloud technology as early as 2007 when AWS only had about 6 APIs. He has launched several startups and is now helping organizations to rethink what cloud means for them!Listen in to this podcast and learn why organizations fail if they don’t understand that cloud is about agility, it’s a platform for innovators and that traditional IT teams have to transform into internal cloud providers that provide services to their development teams for them to deliver better business value faster.Mike also runs his own podcast – you may want to listen in to the episode he recorded with Andi on Speeding up Digital Transformation with Cloud Native.https://www.linkedin.com/in/mikekavis/https://twitter.com/madgreek65https://www2.deloitte.com/us/en/pages/consulting/articles/digital-transformation-requires-a-cloud-native-mindset-cloud-computing-cloud-value-devops-noops-aiops-software-development-business-value.html
Transcript
Discussion (0)
It's time for Pure Performance!
Get your stopwatches ready, it's time for Pure Performance with Andy Grabner and Brian Wilson.
Hello everybody and welcome to another episode of Pure Performance. This is our first episode after our 100th episode, so that would make this, I guess, episode number, what is that?
101. Wow. Okay. Hey, Andy, it's our 101st episode. I'm going to drop this soon with
the whole 100 thing. It's just kind of cool though. But how are you doing, Andy?
Well, I'm just fascinated that you got your math straight.
It was tricky because I had to add 100.
Yeah, I know. I know. I know. But basically, so does this mean this is a 101 session?
Yeah, I guess technically, but not really. i think today's session is going to be a little
a little beyond 101 level course right yeah but uh fun topic nonetheless but how you been it's
been a little while it's been a little while no everything's good so we some exciting things
happening here in my part of the world austria we moved into the new dynatrace headquarter
uh engineering headquarter here.
Kudos to everyone that was involved in making this project a reality.
It's a fantastic building.
They don't let me stay in there.
I'm still in the other kind of satellite office,
but I'm sure they have a good reason for it.
But I keep walking over and just being amazed of the work environment there.
And invitation to everyone that is listening.
If you ever make it through the Austria Linz area,
make sure to stop by and not just have a Linz at work day or check out the Blue Danube. Also check out the Dynatrix office. It's a really,
it's an iconic building now in the city.
Well, I don't want to ruin the surprise for you,
but they're still working
on your office. It's going to have a plush carpet,
gold foil walls,
a pretzel dispenser, and your own personal
beer tap on your
desktop. So they're just
running into some
delays on that. I think the
delay is the gold foil coming through.
Yeah,
there's not too much going on over in my part of the world at all right now.
So let's get to our guests.
Let's not delay this any further.
So typically I just let guests introduce themselves
because they simply know themselves better than I do.
And I want to just keep it that way.
So today on the show, Mike Kavis, actually Mike and I, we met each other online.
He invited me a couple of weeks ago to actually present his podcast.
It's called the Deloitte OnCloud Podcast.
And we had a great chat.
And then he said, well, you know, what about him sharing his experience that he has in the world out there where companies are struggling with kind of transforming themselves, figuring out what cloud technology really means for them, but not only from a technology perspective, but also from how to transform organizations.
And this is just my little intro, Mike, for you. Mike, hopefully you are still with us here and you can give a much better introduction about who you are, what you do, what your background is,
and then why we need to educate people out there on what it actually means to run a cloud-optimized business.
Yeah, thanks for having me.
I just booked my flight to Australia once I heard beer tap.
So I'll see you there. Well, I have to go after reInvent, I guess. I'll see you in two weeks. Well, I don't think you'll see Andy because if you book the flight to Australia, then...
Austria, right?
Austria, exactly. Cows love kangaroos, my friend.
That just brings me back to your old intros, Andy. Andy used to do this great, when you do presentations,
he would start with, what's the difference between Austria and Australia
and go through all these things.
So I just couldn't let that go. Sorry.
So thanks for having me, guys.
Mike Kavis here, Chief Cloud Architect at Deloitte.
I've been working in the cloud space since, I think, 2007.
I kind of left the corporate world and did a startup and was
using Amazon back when Amazon had like six APIs. So I tell everyone everything I learned in the
cloud was from doing it wrong and fixing it. So I've got a lot of, I've done a lot of things wrong
and I learned a lot of things over the years. And I've seen cloud from its infancy when it was just startups and innovators to now we're
pretty much every industry, every company is using cloud in some context. So it's great to be here.
I think the topic that we were chatting on towards the end of my podcast was on kind of the operating
model, the organizational structures. I think a lot of companies are starting to figure out the tech,
but they're having a hard time moving forward
because there's so many barriers and roadblocks in their way.
Exactly, yeah.
And I know when we chatted, you know, I think it was after the podcast,
also we kind of said, you know, there's so many things
that you've learned over the years,
not only on the technology part,
but especially on the people's
and organizational processes part
that we should dedicate a podcast to.
And that's why it's awesome to have you here with us today.
So it's interesting.
So 2007, and now 12 years later,
almost 13 years later, the the cloud topic is
obviously as you said it's it caught it completely caught on everybody is talking about cloud before
we go into the the details of of the kind of process change organizational change just one
personal question that i have for you aren't what your thoughts? It seems like with a lot of other,
let's say buzzwords,
like cloud has long been a buzzword
and has been completely misused,
abused by, I would say, marketing sales.
You've been with, in this field for that long.
Has it always, I mean,
how has it felt over the years
that so many people really kind of
brought it into different strange areas and that nobody at some point did really know what cloud really means?
Well, what's ironic is I've been in IT for almost 35 years.
Pick your buzzword.
It's the same pattern repeating itself.
BPM tools, whether it was the internet, whether it was SOA, marketing gets a hold of it. Your old products now become the new
product with the new buzzword and stuff just gets distorted. And on the company side,
the implementers, a lot of time they move to a new technology with their old methods,
their old processes, their old mindset. So they don't seem to get a lot or reach the promised land of what these
technologies will offer. And nothing's more true than that when it comes to cloud. And I think
the big difference in cloud is what it can provide you, the capabilities it can give you,
the opportunities it gives you to create things at scale that you just couldn't feasibly do before
are tremendous. I think this is the biggest thing since the internet and too many companies
just see the cloud as a data center in the sky and they just do the same things they did in their
data center in the cloud. And it just, that doesn't have the ROI. So I think there's a huge opportunity
that people who get it are doing tremendous things. The people that don't are finding that,
hey, maybe this is more expensive
or it's hard or this and that.
And there's been a lot of buzz.
I follow a lot of people on Twitter and they're talking about all these people migrating back.
And I'm like, well, before you brag about migrating back,
that just means to me that you don't know how to do cloud.
It's more expensive, it's harder.
Well, because you don't know what you're doing.
If you're migrating back, either A, that workload never should have gone to the cloud or b you're doing a terrible job of it
so there's a lot of missed opportunity but the people that get it right are doing tremendous
things in the cloud but isn't i completely agree with you on that but i think this also has been
a learning right there's been a lot of hope and all the promise and then as you said if you don't
do it right if you started moving the wrong things to the cloud,
or maybe you started out in the cloud because you had a new grand idea,
you wanted to validate if that idea actually makes sense.
So instead of building your own data center,
you try it in the cloud because obviously there you can play around,
experiment, and then if it doesn't work out, throw it away.
If it works out, eventually you can still,
and for me that's still a valid point, decide,
do you want to keep the workload in the cloud or are we big enough to move it back to something
because we have an optimized system that's running to move it back to something that might be operationally cheaper?
Or am I wrong here?
Yeah, and I think people chasing the cheaper thing are chasing the wrong thing. What the cloud really gives you is agility
and it gives you the ability to give the plumbing to the plumbers, right? There's no business value
to doing plumbing anymore. Racking and stacking servers are great, but the business value,
you know, this is a race for speed. How can you get features out faster in your competitor? How
can you disrupt markets? How can you get new product out before your client is?
And if you're spending 50% of the project dollars on racking and stacking and patching, you're doing your business a disservice.
This is all about how can we offload that and really focus on getting our customers or our salespeople the tools and technologies we need to win.
So then what do you say about the whole hype around the hybrid cloud model now where you kind of try to balance it out?
Or what does hybrid cloud actually mean for you?
Is this something that makes sense?
Does it just mean hybrid across different public cloud vendors
because you need it to have certain geographical coverage
or maybe, I don't know for whatever for whatever other reason um and what is hybrid cloud because for
me hybrid cloud it kind of means you're still you're pulling stuff back on premise for whatever
reason right and you're leveraging maybe the public cloud for some experiments, some new projects, or I don't know what for.
So hybrid cloud, isn't that a kind of a contradictory statement?
Yeah, so there's hybrid and there's multi.
So my definitions, I'm not saying they're right, but when I hear multi, I'm thinking
about multiple public cloud providers.
When I hear hybrid, I'm thinking about an on-premise solution with a public cloud solution.
That may not be the right, but at least for this discussion, that's the context I'm going to use.
And very rarely do I think it makes sense for an application to span public and private.
I think it makes sense that certain workloads make more sense on-prem and certain workloads make sense in a public cloud but i'll give you a client example
as an exception there's a client that has this huge dot com website you know it's an asset
management company right and the the system of records on the mainframe and and the joke is when
i was talking to the cto there i said do you have any plans on getting off the mainframe he goes how
how old are you back then i was i was like 50 He goes, you'll be dead before we get off the mainframe.
So that's not any worse. But what they did was they built this whole
new digital experience for the clients or the customers
in the cloud, and they built a kind of
data, they built a way to get data in the cloud that can sync back
to on-prem. So That's a true hybrid application.
Very rarely would you design a hybrid application from Greenfield,
but there's great reasons to move the digital experience to the cloud
when the system records always remain on-prem.
But that's rare.
I think most hybrid implementations is really,
I got some stuff running on-prem and I got other applications running in the cloud.
And it's valid.
But what about the case for something as simple as datastore on-prem because the data might be sensitive and you don't want it to be accessible through maybe if Amazon gets breached or something else.
And you run the front end in the cloud and have your data store on-prem.
Is that a valid case or maybe is it not anymore so much?
It's a valid case based on an invalid fear of the cloud.
I can guarantee you I can make and have made data more secure and safe in the public cloud.
And as long as you manage your own keys, Amazon is getting breached.
No one could see my data anyway.
So I think it's an unfounded fear.
I understand why people have that fear.
A lot of companies, especially early in their journey,
just said, I'm never moving my sensitive data
to public cloud.
I think that's a mistake,
but it is a valid architecture.
It's an expensive architecture.
You know, you get all kinds of egress charges.
Obviously, anytime processing is further away from the data, you get latency issues. So, you know, it's a trade-off,
right? If you feel so strong that you can't have sensitive data in the cloud, then you may not have
the best performing apps. And I assume there's a lot of vendors out there that want to sell more
hardware. So they want to make sure that people are still keeping their stuff on-premise.
And therefore, maybe also make sure that
this stays that way.
There's plenty of companies that want
to stay alive. In your experience
with that, though, when you have things like HIPAA
compliance, CU, or maybe
federal kind of components,
is it still
a term that, in your opinion,
they could still do that in the cloud?
Or do you think in those cases there might just be simple laws that prevent that from happening in the cloud?
Absolutely. I've done it in the cloud.
I've built a company 100% in the cloud that had to be PII data, had to be SOC 2 compliant.
Another company had to be HIPAA compliant where there's challenges is when you get to global
implementations and there's certain countries that just will not let data leave the premise then
then you absolutely need some kind of hybrid solution for that cool hey moving on I know as
you can see Brian and I both we just love to talk about, obviously, technical challenges or people also kind of discuss fears because we hear them all the time.
And so it's great to have somebody like you on the podcast that can talk from experience, helping customers actually overcome these fears, whether they are valid fears or made up fears or whatever they are.
But let's switch over to, I think, the topic that you really wanted to address
with this podcast, cloud technology. What does it actually mean for organizations in order to
truly understand the potential and leverage the potential of the cloud? What are the things,
as you said earlier, don't get? What are the things that organizations don't get
when they start moving into the cloud?
Well, moving into the cloud is one thing.
A lot of companies' first approach is, I'm just going to pick everything up and move it to the cloud.
And in my opinion, there's very low value there, except when you're trying to consolidate data centers or kind of avoid a huge, you know, multimillion dollar refresh, if you're just
lifting and shifting and you're not eliminating huge costs and data centers, there's not much
value there. It'll probably actually, you know, the code was probably not written to be in the
cloud to begin with. And I've seen people lift and shift and then, you know, they had something
that, you know, it was very reliable, all of a sudden it's broken and they blame the cloud.
Right. And then they migrate back.
But so the value in the cloud and I did an interview with the,
with the CTO from Vanguard. I can,
I can name it because it's a public podcast, but he,
they went through a journey, right? They were on a private cloud,
did that for years and said, we're not getting the value.
We can't compete with what Amazon's doing. They went to Amazon, started a public
cloud journey. And when they started, they were thinking about costs. And as they got into it and
got more familiar with the capabilities, they said, you know what, this is really about agility.
So they started, they realized when they just got, stopped thinking about the IIS and started thinking more about the pass-like services, they were able to accelerate delivery.
And then this next realization is this is really a platform to innovation.
Not only can I go faster, but these companies are innovating. And if you look like last year at reInvent, Amazon released, you know, a blockchain ledger database as a service.
You think about that before a tool, a managed service like that's available.
People were taking six, seven months cobbling together open source technology.
They were taking six, seven months just to get the technologies to work before they could do a proof of concept.
Now you can do a proof of concept.
Look at Amazon with the healthcare API.
You know, we're beyond technology.
Here's business process as a service.
Here's healthcare.
And both Amazon and Google and probably Microsoft, I don't spend that much time on Microsoft,
they have recommendation engines, right?
A company I came from 13 years ago, I had a team of 10 people that built, if you buy
this, buy this next.
That's an API now, right?
So people need to get past data center thinking and look at
the capabilities that are out there, the ability to strap together a bunch of high-level services
and accelerate delivery and actually get, you know, Google's recommendation engine instead of
trying to build it yourself. You know, Google's probably pretty good at that. They've been doing
that for 15, 20 years, right? Let's use that. That's what's
possible out there. And the other thing I always talk about, I grew up in a company that's like,
Oracle's your database for OLTP. And back then it was Redbrick, which IBM bought, which became
something else. But this is your transactional. And that was it, regardless of what my business
problem was.
And then I would get a business problem.
Well, I need a document store.
Well, you're screwed.
You got this box and that box.
Now you're in the cloud.
And it's like, I can use five different database technologies in the same app.
I don't have to hire five different types of DBAs and buy 10 different types of machines.
It's just an API.
I can use Mongo when it makes sense for Mongo.
I can use a graph database here.
You don't need to train people and hire people.
You know, what's available to you
has never been available before.
And that's the power of the cloud.
And too often people are like,
I need a thousand things in my portfolio.
I got to move them over here.
And they move them over there,
but they still haven't turned off anything over here.
Now their costs are 2x.
Can it also be kind of explained with the it has not been invented here syndrome?
It seems a lot of organizations are still trying to do everything themselves, even though that's not the core business.
But still, we want to build it ourselves because then we understand it and we know it
and then we are independent of some other entity uh even though as you correctly said right you're
basically wasting resources and time to build something that actually doesn't really contribute
immediately to your core business on what your what the business use cases are i agree i wrote
a blog post about a year ago they said agility is the new gold right so if if getting to market
is a competitive advantage what good to spend in a year you know mucking around with kubernetes do
for you right when you can get kubernetes as a managed service on any of your favorite cloud
providers right so from so i i like so i'm taking some notes here because you know it's just managed service on any of your favorite cloud providers, right?
So I'm taking some notes here because, you know,
it's just fantastic to learn these things.
And you said, you know, cloud is about agility.
It's a platform for innovators.
And obviously, as you said earlier, you can see this,
that where true innovation, where a lot of innovation comes from, at least Otis is very public,
that they're all going to the cloud and building new business benefits
or new value on top of existing technology
instead of reinventing the wheel.
So from an organizational perspective, though,
I think this is also something we're going to talk about.
What does it mean for organizations in general?
There are structures, there are hierarchies, there are processes.
What else are kind of holding organizations back for organizations in general. There are structures, there are hierarchies, there are processes.
What else are kind of holding organizations back to really become, let's say, a cloud native digital company?
Yeah, so this is a total mind shift change and it's a reorg.
And if you go to the cloud with the same exact processes and the same exact people and the same exact structure, you're going to fail.
And what you often see is there's some early adopters in an organization.
And they have, within their domain of control, they do some pretty fantastic things on the cloud.
The problem is it doesn't scale, right?
Because there isn't governance
around it. They're able to do some magical things, but you can't scale that because A,
one is they probably have all kinds of vulnerabilities in there because they're
not patching regularly. They're not following the standards. Two is maybe they can think the
new way, but the rest of the organization isn't. And there are people in the value stream of a normal software development lifecycle that have specific tasks that may not be relevant in the cloud.
So, like, do you need this storage manager?
No, I have an API call there.
It doesn't mean you don't need those people.
Maybe they can start doing architectural things instead of administrative things.
You know, same thing when you start looking at the database.
You know, now I have database as a service.
I don't need someone racking and stacking and, you know, managing the threads in a database.
You know, something like RDS taking that back for me.
I need data architects, right?
So it's different.
The problem is people don't want to let go of that responsibility they have. So they create all these roadblocks. And then the
other problem is a process of delivering software. We call it the value stream. If you ever did a
value stream analysis on that, you're going to see, wow, there's a lot of non-happy path things.
Happy path meaning going left to right. There's a lot of things going back.
There's a lot of tickets. There's a lot of gates. And if you analyze that, many of those things,
you can't even answer why those things are there. There's probably some event happened 15 years ago
and they had to put it in a process to make sure it never happened again. And it's just, there's a
lot of waste in that. And I've seen teams that invested heavily in CICD and they could hit a button and do a build
in an hour or two, but it still takes them six months to deploy because they only fix that piece
of the process. So you have to really rethink things and that's hard. And especially when we
start talking about, we need to reorganize, we need to start focusing more on product focus rather than project focus.
You start crossing VP-level boundaries, and that's when wars start, right?
I'm not giving up my people.
Hey, I'm not giving up my people.
And that all gets in the way.
And this is where a lot of the work I'm spending right now is trying to coach companies into, you need to rethink the software development
lifecycle. You need to rethink goals and incentives, right? You need to think more
product-centric teams. Everyone owns security on this product, not just the security guys.
Everyone owns quality, not just the testers. And we're moving to a world where you can deploy
multiple times a day instead of twice a
year. Things have to change. The processes weren't built for this. And that's the barrier for cloud.
There's every company I go to, they're smart people and they're certified and they can
figure out anything in the cloud. There's just too many barriers in their way of getting the
flow of work to be fast. Sounds like a tough problem, obviously, right?
Especially if you have a lot of people that over the years have put themselves into a
very comfortable position within an organization, you know, like basically climbing up the hierarchy
ladder.
And now you basically tell them, well, this was for, well, not for nothing, but it's basically
you start from scratch.
You kind of have to kind of, you know, throw the dice again and start from i don't know level the playing
field i'm not sure what the right terminology here is but uh how does this then work how do you get
how do you get i mean this must be tough how do you get people to say all right i understand that
the things that i've done in the last 10 or 20 years was great, but now I have to basically play with the same rules than somebody that just started a year ago.
I mean, that's hard.
Yeah.
Yeah, I always say technology is easy, people are hard.
And it's very true here.
And the way you approach it is one project at a time.
It's too drastic of a change to just flip the organization overnight.
You need to say, what are the first two workloads we're moving to the cloud?
And if you ever look at a project plan, it's loaded with all these things we're going to do from a technology standpoint.
There also needs to be a swim lane for the people and process standpoint.
You can't change everything at once, but you start making incremental changes,
but you need to create this culture where it's okay to make changes
and it's okay to do it incrementally.
And here's the vision where we're going to go to,
but it's going to take us a while to get there.
As long as we have open, honest, constructive feedback along the way.
Because I've been at clients where for the first time ever, you know, we created this full stack team and there's people from security team, even people from the SOC participating.
And, you know, the Sprint Zero meeting was a bloodbath because these people never worked together before and had different needs and wants. By the time we got out of Sprint Zero and had an architecture that probably wasn't great, but it was better than a data center
centric one and people compromise, it was a start. And as they progress through their journey,
there's more and more understanding, more and more compromise, and the architecture gets better over
time. But you go to these
conferences and you'll be a guy up there with this 150 microservice that's great that's it takes you
a long time to get there and he's probably not talking about all the disasters that happen trying
to manage that right so you see a lot of great stuff on stage and i've seen a lot of clients
on stage and you think that the whole company is like netflix now it's not but
the good thing is they've made progress towards that vision they still have all kinds of battles
to fight but you got to start you got to start small and you have to build trust within the
organization this that's the missing pieces a lot of these silos don't trust each other don't like
each other don't work together and you have to build that and that's hard and you forget who it was a while back someone mentioned
it would be great if at all these conferences people talked about all their failures instead
of all their successes right all the things that went wrong just like you're talking about
all the conflicts that they had and maybe you know part of the story obviously would be how
they got around them and how they got through them but instead of just being like oh look where we are this is great you know we're at
this you know wonderful place everyone that's where everyone's story is going to end up hopefully
let's hear let's hear how you know your battle scars and you know let's hear about the time
someone threw a hot pot of coffee at someone during a meeting or something you know you
recovered but but i guess it's just you know we, we are people, and we've been, as kids, we've always been told fairy tales,
and there's always a happy ending.
And so it's always good to have the happy ending.
I tell you one conference that comes close to that
is the DevOps Enterprise Summit,
and they just had their annual one probably last month.
But because it's not AWS, it's not Google, it's not Oracle,
there's no vendor products being pitched, right?
There's actually companies like our clients up there, and they're saying, we did this, this worked, this didn't.
And that's refreshing.
That's my favorite conference.
Because when I go to the vendor conferences, I pretty much just go listen to the customers anyways, because I want to understand what they're going through.
That's a good conference for that.
There is a lot of that.
So, Mike, I want to shift gears a little bit because when you were sending a couple of
bullet points over in preparation of this podcast, there were a couple of points that
were really intriguing to me.
One of the things was talking about self-service, building self-service capabilities or offering things as a self-service as part of the platform.
And I wanted to ask a little bit more about this because this is also a topic that we are kind of discussing a lot when we talk with our customers.
How can we provide self-service models to different teams?
And I've seen organizations implementing it in different ways,
either having a centralized team that is, as an example,
it's a performance where they provide performance as a self-service to the individual application teams
and then they onboard them.
I've also seen where an organization is basically
putting performance experts into the different teams
and then they build kind of performance as a self-service for
the rest of their teams. I was wondering, what do you see out there and what things have you
seen work and not work maybe? Yeah, and I've seen all of the above, as you mentioned. What I recommend
to most of our clients is the role of IT is going to change here. You're going to become an
internal cloud service provider. You're going to be Amazon, Google, Microsoft, plus your company's guardrails. So you need to think like a product team. And I always say, like WWJD, what would Jesus do? I say, what would Jassy do? What would Jassy do? Well, what does amazon do well amazon creates incredible service catalog that you can use but they also put people out in the field with the clients evangelizing helping them
architect helping them learn and oh and by the way while they're doing that they get feedback
and that feedback goes back to their builders and isn't it amazing how you're working on amazon
and say i wish this api would do these three things. And then Jeff Barr writes a blog post and there they are.
Right. That's the kind of mentality that IT needs to take over.
We're going to be a cloud service provider and you may be providing guardrails on multiple clouds.
Right. You may be Microsoft, Google, Amazon, whatever.
And your job, your customer, this is the most important piece. Your customer is the
developer. It's not the security team. Now, the security team is a stakeholder, and you need to
make sure that the developers are developing with the right guardrails, with the right compliance,
but the customer is the developer. So how can we implement the guardrails and still create a great user experience?
I think that's where most companies fail is their only customer security compliance,
and they create this really hard environment to use. And the developers just can't use it. They
can't get the agility. They have to jump through 38 hoops to get work done. Sometimes they even
say, screw this, and they get their credit card out and they go out this way. But that's it. It's a combination. There's usually a centralized team that owns
cloud, owns the cloud strategy, and owns building the capabilities and managing the service catalog
of the cloud. The other thing that's important here is not every customer is the same, right?
So you may have a business unit that is extremely
cloud savvy. You may have bought a company born in the cloud. They needed high level self-service
capabilities, just get out of their way. But you may have another team that isn't all that up to
speed and they need kind of more white glove service. So what's important to realize is that
the platform team may have its own operating model, how it's structured, but each business unit may have a different way of engaging with.
And Amazon gets that, right?
They may be working with a client that's in year one of their journey, and they're really, really helping them.
And then they may be working with one of these guys that have been on stage for five years. And they're more working on how do I improve IoT capabilities.
That's the mentality you have to have, which is very different than give me a ticket and I'll create you a server in six months.
I like that.
So basically, this is the path for the cloud-ready IT department,
which means rethink your service to the company.
You become your internal cloud provider,
which means you need to provide services that are so easy to use
that your developers see the value in staying with you
and sticking with you instead of swiping the credit card
and going to, let's say, some other vendor
outside.
So I think that's what it's going to become.
Exactly.
And part of those services, like your guy's solution is a service the platform can provide,
right?
And if I go to that example of we bought this company and they're savvy, they're like, well,
we already have this tool, right?
We're going to use our own.
Well, that's okay.
But then they also may come to the like, well, we already have this tool, right? We're going to use our own. Well, that's okay. But then they also may come to the point where, you know what, they're doing such a good job providing this tool as a service. I don't have to do this work anymore. And now I can
migrate that capability off to the platform. I think what's where companies go wrong is they say,
here's our service catalog, take it or leave it. You can't use anything else. And that's where,
you know, you get a lot of heads button, but you know, you need to it, you can't use anything else. And that's where you get a lot
of heads buttoned. But you need to think, what would Jassy do, right? Jassy doesn't dictate
anything to us as builders. They just provide the best capabilities that they can. And if you look
at their service catalog, some things like Beanstalk, I don't think that's a highly used
service. It doesn't meet the needs, but that's okay.
I don't have to use that.
I'm going to use these other things.
And that's the mentality we have to take.
Very cool, very cool.
So, Mike, I know we could, I mean, with your many, many years of experience,
both on the cloud and then you said you've been working in IT for,
do I remember this correctly, 30, 35 years?
Too long. Too long.
Too long.
I started at a mainframe with vSAM tape.
Okay.
So see, I guess I wasn't even born back then when this technology was around.
Not that I feel old now.
And, you know, I would love, I think for this topic,
I'm sure we could probably talk more about this,
but kind of conclude with a couple of your final thoughts on if organizations are listening in right now
and they are either feeling that they're not doing cloud right
or they're feeling that they need to give some advice
to their management.
Is there anything that you can pass on to the listeners now
where you say, hey, here are a couple of warning signs.
Maybe just reiterate what we said earlier.
Here are a couple of warning signs,
or here's a couple of things that you definitely have
to make sure that you're covering,
because otherwise you just don't get the cloud,
and you will in five years from now
just have wasted a lot of time and money and realized that the cloud is not the right thing for you.
But not because the cloud is not right, but because you are not right for the cloud.
Well, I think I would say there's this golden age of opportunity right now.
You know, 10 years from now, all this is a commodity and it'll just be like we're all running data centers or something.
But there's an opportunity now for companies to make a substantial difference in the marketplace if they can figure out how to leverage the capabilities of the cloud and not treat it like a data center.
To do that, it takes very strong leadership and it takes empathy, right?
So you're going to have a lot of people pushing back.
And if you put yourself in their shoes, they're not doing it because they're bad people.
I mean, they have valid reasons.
And you need to address that head on, right?
A lot of people are afraid of their jobs.
And what I try to tell people is, you're looking at this wrong. If you're a disk or a network person, if you are the cloud
expert at disk and network or security, you can write your own ticket anywhere. So this is an
opportunity. Yeah, it's going to change what you do today. But if you make that change, you are
a better contributor to your company. And oh, by the way, all of a sudden, everyone in the world
is pinging you for other opportunities. So you need to look at this as this is a career changing opportunity if you do this
right. And people need to get out of this fear that 10 years from now, everyone's going to be
there anyway. So you might as well get on board now and go there. 10 years from now, if people
are still racking and stacking and buying and building new data centers in certain industries, they're going
to fall way, way behind.
So this is the future.
I've built two companies from scratch on it with hardly any money and sold it to companies
that couldn't do it themselves.
They should have done it.
Matter of fact, one company I left that was proposing, and their competitor bought it. We need to think about the business value, not about the task I do today.
It's hard.
It sounds easy.
It's great to say, but it takes strong leadership, and that goes all the way up.
And a lot of times, the barrier is the leadership, right?
So just remember, technology is easy. People are hard. technology is easy people are hard this is a
people problem it's a process problem i think there's a good point in there too with the people
side a lot of people think about this in terms of it being like the cloud transformation
and if we want to do a little buzzword for marketing right it's it's more of like a people
transformation because people fear what's gonna happen to their jobs,
but at the same time,
and we've discussed this, Andy, several times
with several different people,
how this is an opportunity for you to,
maybe we call it level up, but change,
to become part of this.
And if it's done right within an organization,
you have the knowledge of everything that's been going on in that organization
up until this point.
You have all the historical knowledge.
The best thing for that company to do
is to bring you forward into the new paradigm.
So there's an opportunity there to move with this
and to now get that new skill
and become part of, let's say, the next 10 years or so
of the way IT is going to look. I'm kind of just repeating what you're saying in a different way,
I guess, but it really comes down to changing the people. Not changing them out, firing them
and hiring the right ones, but changing their mindsets and changing their role and getting
them to embrace that so that this can all happen and you get to save all the historic
history and experience within the organization at the same time yeah and and if it's done right
it's fun work becomes fun so i was at a place where i needed a server and six months later i
get a server and then i start do the startup thing, I'm broke working for food now, but I right click, boom, and there's a server, right?
So what we were able to build with five, six people, we couldn't have done with 100 people where it was.
So there's a sense of it.
When done right, there's such a sense of accomplishment.
And if you're building for the business, man, they love you because all of a sudden you're delivering at a velocity they'd never seen before.
Yeah. man, they love you because all of a sudden you're delivering at a velocity they've never seen before. Yeah, it kind of reminds me, I'm going to take a little musical side journey here,
is play like Ringo.
Ringo, you're saying, what does the business need?
And to me, I'm a drummer, and what I love about Ringo is he plays to the song.
What does the song need?
It's not, I'm going to do what I do because this is what my skills allow me to do.
For a musician in music, they could just try to show off and there's plenty of bands and plenty
of musicians who just get on a song and try to show off all over it. And then there's other
musicians who listen to what's going on and say, what's missing from this song and what can I contribute to make it better? And if you take that
same mindset in this, what do we need to serve the customer?
Whether that's the end customer, the real
customer, or any customer within the chain of the whole process.
What does that customer need to be successful and how do we give it to them?
And take that approach. Exactly. And if you're on the platform team and that customer is a
developer, how can we empower the developer and keep them safe at the same time? All right. Wow.
Mike, I normally, and I know Brian, you probably would ask me for it. Normally I do a summary at the end of a show.
And I think there's so much content here
that it's hard to summarize.
That's why I just want to repeat one thing at the end
that you said just almost at the very end.
Don't treat the cloud as a data center
because if you do it like that,
then obviously you're doing it completely wrong. And there's a lot of other amazing things that you've said. And Mike,
I would really love to have you back on another show, because I know there's a lot of more,
you know, wisdom and experience on your end. And we should be, you know, doing another show and
talking about more experience and maybe to kind of pick up on
what Brian said, wouldn't it be cool to actually do like a show where we talk about the failures,
like really the bad things that happen, right? Not, not the, not the fairytale end, but actually
things that, that really are, you know, we want to share so that people see the early warning signs
or early warning signs in case their organization
is going down the wrong path.
Yeah, I could do 100 podcasts on everything I failed.
I think the more important side of the failure is either what was the lesson learned from
that failure or how did you get past it then?
Right. So I think, I think, yeah, I think we could do,
that'd be a great thing. And I do want to interject quickly here, Andy,
only because we brought this up on,
on the last podcast or two podcasts ago about coming up with a new name.
So we call Andy the summerator Mike, because being Austrian,
he's kind of like Arnold Schwarzenegger is also,
if you've ever seen him in person, he's built like him, too.
I'll be back.
So we said, hey, does anybody have a better name for him?
And we did get one suggestion for Sumtron.
Sumtron, yeah, yeah.
Yeah, well, I guess it was the show with the guys from Citrix. So I even asked, because they talked about Ultron and all the different bots.
Sumtron.
Yes.
Anyway, but yeah, Mike,
we'd love to have you back on
and talk about that
if you think that would be incredible.
Yeah, I actually have a great lessons learned story
in the area of monitoring,
or lack thereof,
which might be really good.
There you go.
Yeah.
Definitely.
All right.
Well, let's schedule that.
Anything else, Mike?
Was there anything that we maybe didn't touch?
I know we're out of time here, but is there anything briefly that we didn't touch that you wanted to make sure you got in here?
Yeah, just, you know, there's a journey, there's an opportunity.
If we do it right, you're going to, like, work a lot better.
So let's go out there
and knock down those barriers and enjoy working yes exactly and we'll make sure to put all the
links to your work to your podcast and i know you mentioned a couple of blogs so we'll make sure to
put these into the uh the podcast summary an hour and right well i appreciate that all right well
thank you for being on if um do you do Twitter or anything like that in any kind of social media?
At MadGreek65.
MadGreek65.
I tweet a lot.
I argue a lot.
Especially around DevOps and SRE.
DevOps is not an engineer.
That's a whole other topic.
DevOps is a thing.
So, yeah. You'll see me battle with some people out there.
Yeah, you can follow Mike there.
Follow us, Pure underscore DT.
If you have any show ideas, suggestions,
or you think you want to be a guest,
make sure you reach out to us, Pure underscore DT,
or you can send us an email at pureperformance.dynatrace.com.
We'll have the links up to all of Mike's stuff as well,
so make sure to check them out.
It's always great to have
more technology-related podcasts.
It's awesome that you've been doing that.
Sorry to say I didn't
know about that until today, so shame
on me, but it's awesome.
Thank you for being on, Mike. Yeah, I'm a small speck
in the atmosphere.
We all are. It's technology.
We're not talking about murders.
Much smaller audience, but we appreciate our audience greatly.
Anyway, bye from me.
Bye.
Bye-bye.