Transcript
0:09
Welcome to Cloud Unplugged, the podcast where we take a lighthearted and honest look at the who, what, when, where, why, how and OMGs of cloud computing. In today’s episode, a very special b-b-b-bonus episode, an interview where I sit down with one of my oldest professional and personal friends Alicia Davis to talk about her experiences in cloud adoption and also lots of random thoughts and things that occurred to us. This one’s a pretty fun one. We cover a lot of ground, and I hope you find it informative and useful. So without further ado, let’s get straight to the episode. So I’m here with a friend of mine that I’ve known for a long time, we’ve worked together multiple places over the years, been sort of Co-conspirator on things large and small. So I’ll just introduce he: Alicia Davis, say hello.
1:05
Yes, hello! And co-conspiritor’s a good term. I think when you work with somebody so long that you become buddies.
1:14
Yeah, yeah, it’s it’s definitely good. So we’re, we’re sitting in her palatial villa, in the south of France, just catching up on an afternoon here. Well, first of all, I mean, if you wouldn’t mind for the listeners, just tell then a little bit about your current role, what it is you do, and then we can sort of get into some more specifics.
1:36
I make change happen. Well, so I work in IT – that’skind of usually my you know, over dinner story. ‘what do you do?’. ‘I I work in IT.’ Right? I work in operations, more specifically in, you know, a, what I call it commercial industry, we do insurance related industry, from third parties, right? So really, when we, when you hear the word operations, right, you think about okay, we got to make sure our servers are up, we’ve got to make sure our applications are up, we have our monitoring, things like that. And so that’s, that’s kind of the world I’m in. But I really focus a little bit more around platforms, such as modern application platforms like Kubernetes as an example. Or platforms around that platform as a service type of thing, right? And so what I’m doing at a high level today is a lot of a lot of projects, is what I call it, right? So a lot of consolidations, a lot of upgrading. So whether we’re talking about versions of software or platforms, or rethinking the way companies work, specifically the company I work for. So we’ve got a lot of things going on, all at once. I just had an intern start this week, and he’s like, wow, I thought that meeting was for the the Tanzu project and I said, Oh, no, that’s for this other migration project that’s going tomorrow, like … on Saturday!
2:58
Surprise!
2:58
So I’m confusing the new guy, but that’s alright, we’ll get them learned into the world of operations.
3:05
Cool, so I mean, what we’ve talked about on the podcast so far, and this is gonna be like, the format of this is gonna make you chuckle because this is stuff that we’ve talked about for ages and ages, is it’s really we’re talking about the the first push towards cloud with the eye of, what should you do? What Shouldn’t you do? What are the patterns that we know are successful, and the steps you need to obey in order to get an organisation from sort of one way of thinking and working to another way of thinking and working. And some of the topics that we’ve covered off so far are, first of all, you know, setting the goal, understanding what it is you’re going to achieve early on, and making sure that it’s tangible, the types of people that you’re going to need in order to build a team to be successful at it. Yeah, that’s a behind that, you know, getting started with your first account, what’s the account structures that you should be looking at to make this sustainable and not be in a position where you have to go back and refactor everything that you’ve done at some point in the future, unnecessarily. And then the last couple of conversations we’ve had have been around, you know, the hybrid or multi cloud story, like what are the right reasons to do it? What are the wrong reasons to do it? And then, what does it mean to be cloud native? You know, putting some definitions behind some of these terms. So I know in your position, you you’re tackling all of this sometimes it in parallel and with things being not necessarily in the right order. So I know this, but maybe you can unpack this for the listener and give a little more context.
4:43
Where to start? I mean, yeah, I mean, so, wow. I mean, that the biggest thing…
4:51
So let’s maybe start at I’ll give you a clean lead here. So you know what I know about your your company. You know, in majority, the way that the company has has modelled its growth is by acquisition.
5:07
Yep.
5:07
So, as you’re acquiring new companies, you’re never quite sure where they are in the journey. And you know, you’re sort of integrating them into a larger company that has a momentum of its own, and is at a different point in the journey, maybe. So, you know, what it what is it like? Or what is your experience with, you know, kind of trying to absorb not only technologies, but teams?
5:34
Yeah, no, I mean, it’s, you know, but also doing your day job. Yeah. Right. So, yeah, I mean, you just described my day yesterday, right? We’ve got a lot of projects going on, where we’re looking at, you know, modernising platforms. We’re moving forward with a Kubernetes product and looking at how do we kick that off? A couple weeks late, but, you know, we’ve got enough wiggle room in the schedule.
5:56
Yes.
5:57
So we’re not on critical path. Right. So that’s great. You know, so, you know, we’re getting into, hey, let’s understand once your acquisition closes as an example, right, you’ve got to go talk to your people understand what they’re doing from a people process and technology perspective. Right So do we have similar vendors that we’re working with, as an example, right? Because we want to be able to consolidate and streamline communications at one at first, right? Again, because you’re juggling your current day and that, you know, that other company and those people are juggling their current day to day, but they’re also juggling this integration task. Right, of integrating the two teams.
6:38
Yeah, their world has just been shaken up.
6:41
Well, everybody’s has, right? .Because it’s like a blended family. Right?
6:45
Yeah.
6:46
Like a divorced couple with kids.
6:49
Here we go!
6:49
And gets remarried, right? You have all these things when you’re taking the soccer practice, right? And then right guys got baseball and who has the car? It feels like that a little bit. But there’s a part once you get past ‘Okay, now the deal is final, we’ve closed, let’s start having those deeper level conversations.’ Once you understand who’s who. And you get that communication going quickly, like let’s consolidate vendors, we have one Tam, we have one account manager per vendor, right? Then you can go to and say, allright, what are these two teams doing? What are their forecasts doing? What are their projects look like per vendor? And then say, all right, what makes sense moving forward based on what we have from a budget and a resourcing perspective? And what are our overall objectives and goals for the new company, right? Because obviously, they’re going to be very similar, but they’re going to be a little different, because maybe they have competing products as an example. You’ve got to decide which one’s going to fit. And maybe they’re, depending on the market as an example. Right? So there’s a lot of things that are unknown. But when it comes to the technology piece, right, because I think that’s the easier one to really focus on, right? So say, you’ve got EKS, and you’ve got AKS, and you’ve got something on prem, maybe it’s the open source version of Kubernetes. Right? How do you consolidate and understand should you even consolidate? Right? Because that’s the first thing. You don’t want to do projects, just to do projects. If it doesn’t make sense financially, and from a business, you know, outcomes perspective, don’t consolodate.
8:14
Well, also, sometimes the applications are so different and have different requirements that it doesn’t make sense to sort of commingle the environments, like, let there be a wall of separation between them, I would think, right?
8:28
Oh, absolutely. Yeah. And that’s the whole point. And so you have to be okay, if you’re going to not do that you have to be okay with some additional overhead from a resource and a process perspective, right? Because you may have something that’s very, very legacy out there running on prem and all your new stuff is running agile and cloud, you’re not going to be able to to integrate those two pieces, because by the time you get through all that integration, your product may be coming into the next version anyway. So why would you go and do a 2.0 or 3.0 version of your platform and all the processes around it, when it’s gonna be gone in three months?
9:05
Ah that’s true, right. Yeah.
9:06
So even just taking a look and doing all that data discovery. Okay, now that we have everything, what is the most critical thing that we need to do? And this is what I’ve been kind of doing in the last couple weeks is, do we have any concerns around our current contracts? And, you know, AWS commits as an example. Right. That’s a big thing that a lot of companies have they have EDPs. Are we on track to meet the fiscal year and the the contract year commitments? And if not, what do we do to fix that immediately, right? Is that a renegotiate? Or is that how do we go move things around? Right?
9:38
Right.
9:39
Once you get past that, then the pressure is off a little bit and you say, Okay, let’s focus again. Kubernetes. Right? What, what are we going to do? Where are we in those phases? Are we mature? Do we? Are we moving towards a PoC of something else? Because we found maybe we don’t like open shift as an example. Right? Where are we there? Did one of our companies just do a PoC and we just did a design for a brand new product. Hey, maybe that was was done in the proper way that we can just rubber stamp that across. Right? I think I think we’re there!
10:12
*crossed fingers*
10:12
I think we’re there based on what I can tell we’re moving very swimmingly around that model.
10:17
Well, you know, it’s interesting. So one of the things that you hit on, and it’s like, I think this episode is just going to be schizophrenic. All right, so everybody just needs to, everybody just needs to buckle up. All right, because there’s so many things that we can talk about. So I’m going to sort of take them as they come. You know, one of the things that Jon and i talked about, in one of the recent episodes was, was hybrid cloud, and you know, why people go for hybrid cloud. And we outlined some some reasons that in our minds are legitimate reasons for doing it. And also some, like reasons that maybe you should really, you know, check yourself. Right. You know, my thing is, you know, your, your company is growing by acquisition, you got lots of disparate environments, you got lots of different regulatory concerns, right, and compliance obligations? You know, I know that you do have a hybrid environment right now. I guess, I would love to know your perspective on like, whether you see a how you see hybrid, and then like, behind that, you know, where’s that going? Do you think it’s gonna stay that way? Or is that or is this a transitional state?
11:26
So hybrid, I’m all for it. And I think you have to pick a strategy. First it and hybrid is not your first strategy. Hybrid is a strategy.
11:37
Yeah.
11:37
But it’s not the first for anybody. Right? Okay. I think you just need to pick a strategy, whether that’s on prem or cloud, whatever that is, pick it. And then the next thing is your secondary if you can’t do that one. So you have a data locality issue, or a customer specific thing where you can’t get performance because they don’t have a cloud region where where you need to be right, then you say, all right, now I am going to do hybrid cloud, and what are my options to be able to do hybrid cloud? Do I have a do colo? Do I stand up my own DC, right. And so I think once you understand that, and have an agreement, hopefully your architecture team, your enterprise architecture group has decided that and everybody loves it and blesses it right? Then, then you can just follow that. So then when you get all of these acquisitions, and all of that stuff, then it’s just reading your playbook to say, hey, this is my agreed upon 123. And one doesn’t work for me two doesn’t work, mehhh, three works, , let’s move there. And it’s quick and move. Right. So So I think if you if you have a company that adopts that kind of mentality, you will always have hybrid cloud. And I think hybrid cloud will be here. But I think the technology underneath it will be evolving, as especially when you get more outposts and Azure Stack.
12:33
So that was actually one of the things that we were talking about in terms of like, if you’re going to if you’re going to be hybrid cloud, and you expect it to be something that’s going to stick for a long time, there’s kind of two approaches. One is you can take an on prem technology, something that was designed originally to run in your data centre. And you can build the same thing in EC2. And you know that sort of, right, yeah, you could, or, and we actually said that that’s not such a hot idea, right? It’s a great kind of shape, the direction of travel is wrong, right? What you should do is take like you said, outposts, or Azure Stack, or the notion of the cloud of how you take a piece of the cloud and put it in your private data centre, and run that way. So it falls under common management.
13:39
I mean, you’re you’re solving the problem that hyper-converged solved, but in a different layer of the stack. When you talk about that, right? Because hyper-converged put together all the physical components, right, to make it easier. What you’re talking about for Azure Stack or Outpost is the management or virtualization layer of the applications on top of that hardware. That is the next evolution in my opinion … of anything.
14:03
Yeah, so you get the piece of hardware that you drop in your data centre, but all the services, the API’s, the control plane, everything is an extension of the cloud, rather than trying to take your private data centre and shove it into the cloud, which is sort of like…
14:19
Or do what some people, and when I mentioned this you’ll know who I’m talking about, okay where they’ll recreate cloud on-prem.
14:27
Oh, yeah. Yeah, that doesn’t. That doesn’t work.
14:32
Never works. Because I mean, it’s a great idea if you want to build products is a great thing to do. Yeah, right. But go work at a product company.
14:39
Yeah, I mean, it’s definitely not for everybody, because what you’re doing is and we haven’t touched on this directly, but I think this is a good call out is yeah, if you want to try and recreate all of the all of the services and the interfaces and the robustness of cloud in your private data centre you can, with the right expertise, time and resources.
15:03
Money, yep.
15:04
…do it. But I have to question your motivation in most cases, because is that how you’re making money? If it’s not, then why?
15:14
I mean, that’s the thing, Amazon didn’t come up out of nowhere. And they didn’t show up overnight. And either it Azure, they’ve been around for years. So while they may not have exactly what you need, they have enough services to tailor to your need and your evolution of your application, your application platforms. And that’s key. And I think a lot of people back in the day when they were just getting into virtualization. They’re like, oh my God, it takes forever to build something, I have to build it right now and never change it. But the whole concept and whole reason for cloud, and even when the application is that you can change it, and you should, so the first iteration of whatever you do, doesn’t have to be perfect. Because it’s so easy to change it.
15:57
No, and I think that’s a good call out for the listeners is and we’ve cautioned this a few times about you know, keep your scope creep under control, keep your complexity under control, and know that you’re going to iterate on this over time. Just I hate to spoil it for everybody, but the first thing that you build is not the thing that’s going to stay forever, or at least it shouldn’t be now you should take the the lessons learned and roll that back into it and make that the next product. Or the next version of it. You know, sort of jumping off from that because your company is large enough, complex enough, and it is global in scope. One conversation that’s been coming up a lot, and it really comes up around the hybrid use case, and specifically around the multi-cloud use case is multi-cloud, specifically and hybrid cloud lesser around satisfying, disparate or changes in compliance obligations, specifically from one geo to the next or one, you know, sort of the borders of one governing body to the next right. We’ve talked about it kind of briefly, but I would love to know, like what your perspective is, like, just sort of practically, in how that plays out for you guys, you know. I mean, how it’s helped simplify some of your compliance puzzles. Or has it?
17:23
No.
17:24
Really?
17:24
No. The hard part about picking cloud in general, and not even hybrid or multi, is understanding all the regulations for the industry for the country and for the customer. And sometimes those are conflicting.
17:45
Okay. Can you give an example without naming names?
17:50
Perfect example. All right. So if we’ve got something that’s built-in a specific cloud and that cloud, you’re trying to enter a certain market, and that cloud doesn’t have a reformant region in that market.
18:04
Right?
18:05
What do you do? Do you have to refactor your whole application to go on that market? Or you find something else to do?
18:14
Right.
18:14
Right. Well, that’s what I mean. Like that, that is one where, okay, it’s a market that doesn’t exist. And well, as you say, the region doesn’t exist for your drop-in solution. Right. So do you take the hit on performance?
18:30
Well, I guess so…
18:31
I don’t know. Do you want to offend your customers?
18:34
Well, I mean, so that’s, that’s another question. I would say, though, like, that has been in some of the discussions so far, that has been one of the cases made for a multi-vendor or multi-cloud solution. And in dealing with that compliance obligation, I think that’s really what I’m getting at right is, like, is adopting or at least acknowledging upfront that if you’re in that sort of global space, and you’re dealing with lots of different compliance and regulatory concerns, that you almost have to adopt a multivendor approach, or is that not necessarily approach?
19:09
Well, the problem with the multivendor approach is the way you would architect a solution. Right? When you look at Cloud, there’s different say Azure, you want to have really good data like Azure is good. And data lakes. I’m sure AWS is too but you don’t I don’t see that. Right. So and if you have you need a specific GPU, then maybe Google is good for that one. So right. So if you’re going to be more abstract around your service selection within the cloud, you are going to lock yourself out of very unique specific services in a specific cloud, that might work best for your workload, right? So and that that goes to all of your PaaS and SaaS offerings in all your cloud, right, because that again, that’s multi-cloud that’s, that’s not agnostic. So how do you do that? Are you going to run your application on EC2 the whole time? Or are you gonna have an abstraction layer. So that’s, that’s what I mean.
20:06
So that’s sort of like there’s the fit-for-purpose version of multicloud that says, alright, we’re not going to distribute, like, let’s say, one application’s components across multiple clouds, right? Like, it’s going to live in one or the other, but we’re gonna sort of place it based on fit for purpose. Like where it’s best, where the functions are most aligned to support what the application actually does.That’s sort of one mode. Another mode is we’re going to place the applications based on geography or compliance or regulatory concern. And it’s,
20:40
IF you can.
20:42
Okay.
20:42
That’s what I’m saying. If you don’t have … if you if all clouds had all regions that were same, I agree. But all clouds don’t.
20:49
Right. Well, and yeah, and the dodge that some people have applied, or at least thought it’s like, well only use lowest common denominator resource of EC2 or something,
20:58
And then you’re screwed because you have a really expensive bill.
21:01
Exactly. Right. 100%. So the interesting thing to me, because you we talked about Kubernetes and you and I just full disclosure to everybody listening, we’ve been around Kubernetes space for friggin ever.
21:13
Too long.
21:13
Too long is probably a good description. Um you know, what’s interesting is like the old idea of we’ll just gonna build on infrastructure, and like baseline storage, is now sort of getting picked up. And like the same assumption is getting applied to containerization and Kubernetes. In a certain sense, which, I kind of understand why, right. But it seems like, Alright, well, it definitely gets you closer to the mark. But it’s still like, that’s got its whole other set of considerations. You know.
21:45
Yeah, but here’s the thing, if you use the if you learn and as you’re saying this, I’m literally seeing this in my brain, how this actually works. Like you take a pod off a node, and you stick it on EKS, or you stick it on AKS. But okay, that’s one thing. But where’s your management plane? And so if you use something a third-party tool, to do management like a TMC or a Rancher, dude it doesn’t matter underneath, right? You may have some small config change, because the logic is different between like arm and what’s the other one in AWS, can’t even remember? I keep cloud fares in my head…
22:21
Cloud formation!
22:22
Cloud formation, right? So arm and a cloud formation…
22:24
I thought you were talking about chips for a second. Like, arm chips. I was like, what?
22:27
Who knows about that! Yeah, so if you think about it, right, if you look at the top layer, and where the app connects, and then essentially the networking around it, yeah, you have a little bit of differences. But ultimately, if you get those the same, and they’re vendor agnostic, you could really pretty much run Kubernetes in any cloud.
22:46
Right? Exactly. Yeah.
22:48
If you do it that way?
22:49
Yeah. It’s a question of at that point, what other services sit outside the Kubernetes cluster that the application components are talking to? And does that constitute a configuration change when you go from Cloud A to Cloud B, or Environment A to Environment B. Right?
23:06
It’s all going to depend on your application, your workload, honestly right?
23:09
I mean that’s an app architecture problem.
23:10
Yeah. And the thing is, that will only come into play, if you have a legacy app that you’re porting into Kubernetes. And you’re not writing new.
23:18
Which, let’s just establish right up front that, you know, taking a legacy app, and just sticking it in a container and throwing it at Kubernetes solves nothing. I am sorry to disappoint people out there that thinks that that is like the right way to go. But it just isn’t. In fact, it’s gonna make your life a lot lot worse. Please don’t do that. Refactor your app to behave in a way that’s compatible with … you’re laughing. I think I may have hit a nerve.
23:48
No Pivotal may sell you something cool like that?
23:51
Yeah, well, yeah. But it doesn’t, it doesn’t really work. It’s not sustainable. It doesn’t pass the sniff test for sustainabilit. You may be able to get away with it for a short period of time.
24:01
And that goes back to the whole reiteration, right. And in a pinch, you can do that without, you know, sacrificing performance or user experience. But ultimately, as your app grows, and as you build to it, you have to refactor. And I agree if you don’t have to, don’t throw a VM in a container, please.
24:19
Yeahhh. Well, and I honestly, one of the pieces of advice we’ve been giving people and have reiterated a few times is if you’re not new to cloud, if this is your first pass, and you’re trying to get your first workload out there and running on cloud, and you’re looking at services and trying to scope what it is you’re going to deploy … try and avoid deploying on cloud infrastructure if you can. Because if you do, it’s going to open the door to temptations for like, well, it’s a VM here, it’s a VM over there. So I’m just going to bring all my old stuff with me and you don’t ever really get unburdened from the thing that you had before.
24:57
Yeah, that that ‘R’ in the six ‘Rs’ is scary R for a lot of people that understand the technology underneath.
25:04
Well. you hit Six Rs and we have not talked about that. So do you want to talk about the six Rs?
25:09
Sure, I can’t name them sll off top my head though! It’s been a day.
25:12
Alright, let’s just take a couple of them. So ‘re-host’ is one.
25:17
Yes, yes.
25:17
So re hosting is where you’re taking something. And you’re just you’re not really making any modification to the applications at that point. You’re just saying, okay, it’s running in one piece of infrastructure amd I’m now going to put it into a different piece of infrastructure. And we’re going to move forward.
25:35
Right.
25:35
Right? So and that one, I think everybody like, that’s kind of old hat, like, pretty much everybody should be comfortable with that one. There’s replatforming, which is slightly different, right? That’s where you’re taking something and you’re changing the underlying platform. So one example of that would be alright, you’re on Oracle today and you decide that you don’t want your databases to be Oracle. So you’re going to use a different type of database. And, you know, replatform that way. Right, right. Yeah. And so you know, those two, again, those are kind of understandable. But when we get to refactor, which is taking an application and changing its functionality, like the change that’s being applied in the refactor case, is actually at the application layer, right? Right. To say, all right, we’re going to throw everything below the application layer, sort of out the window, and we’re going to make it run the function, it’ll be functionally equivalent, but it’s going to run it in a different context. That is really scary in some cases, because sometimes people don’t know how the applications work, right?
26:47
Sometimes? I mean if you think about the life cycle of an application, and the life cycle of an employee at an individual company, when that application was born, right? WAY different cycle times. Right? I mean, I can tell you some applications that we’ve seen before in our shared journeys have been around longer than I’ve been alive.
27:12
Yeah. In some cases decades, like multiple decades.
27:15
And they’re in scary locations because of the industry they work at. So like, you have your whole business that needs to have low latency running on mainframe, and all your mainframe guys are retiring in five years.
27:28
Yeah, yeah. Which is…
27:29
What are you gonna do? There’s no way you can refactor or re architect or create a reference architecture for that application before that guy retires.
27:37
Well, yeah, especially since it’s literally like the beating heart of the business and money doesn’t move.
27:43
Well not even that. It’s the beating heart of the business, but it’s not just that business. It’s the, you know, industries that are severely critical to the US economy. Like that kind of stuff.
Yeah, yeah, I mean, there’s still a certain amount of the the US economy that ceases to function without Cobalt, right? Yes, like big chunks of it, actually. So you know, that is sort of an interesting proposition. But you know, in my way of thinking, you know, if we get back to the Six Rs. You know, that more than anything is if you do get the opportunity to rethink how you approach your day to day business, right, and you get the opportunity to set the new working paradigm, don’t waste it by bringing along the thing that you’re not particularly enamoured with in the first place, especially when it’s ancillary tools that really don’t add a lot of value to begin with. The example, and I know I keep probably harping on this and people are gonna send us letters or whatever.
28:47
It’s management tools, like you know, stuff that’s used for system patching, right figuration and stuff like that. It’s like, why?! Why would you drag that with you? :eave it alone, ring fence it on prem and let it stay.
29:00
You know, some of those people just can’t get rid of their puppet man. They gotta love learning that different language. Is that company even still around anymore?
29:09
Yeah, they’re still around. Well, I mean, or the odd person who really bought into promise theory and need their CF engine fixed. But…
29:17
Oh, God.
29:18
But, you know, again, what is … trash talking with Joel and Alicia! But you know in my way of thinking, you know, that is that is the argument to say if you can avoid deploying stuff on infrastructure in your first pass do because it’s a forcing function to shake everybody’s heads, right? And make them think different. Rather than just saying, you know, it looks like this over here. We can make it look exactly like that over there, which kind of misses the point.
29:43
Right. Yeah, I completely agree. And I think a lot of folks are just so used to kind of caring about the only thing they’re doing there, maybe they’re writing puppet scripts, and that’s the only thing they do. Like they’re gonna live for that but they don’t understand why they’re writing it or what it’s connecting to. If you don’t take a step back from what your day to day job is, you can’t see that big picture. And then when you have those opportunities to say, hey, let’s re-architect, then you’re not in a position to do that, because you haven’t been learning all of the ancillary things around your environment or processes to say, I know even where to start if I was going to do this,
30:17
So that’s actually another interesting direction that we can go in is an especially for your position where you’ve got a variety of teams who have come into the organisation at different times, and may have wildly different experiences, and expectations and paradigms about how things work. Right, right. So when you’re, when you’re bringing these people into the organisation, and you’re trying to get them all oriented behind that common set of goals, give them the why behind the what they’re doing, right. Give them the context to know, this is the value of why we do this specific thing. How have you found effective… what are effective ways you found of doing that? I mean, it’s kind of it’s difficult.
31:04
So the easiest way to do that, it honestly, and it’s not even technically, it’s not even saying these are our goals, here’s our last quarterly business review or anything, right? It’s none of that. It’s actually understanding that person’s viewpoint and how they see things, so that when I say, hey, when I use the word application or platform in their head, I know what they what they hear when I say that, because I still remember to this day, we were in this meeting room years ago, talking about platforms with with a co worker.
31:41
Yeah, I remember!
31:42
You and I had an understanding of what that meant. And we agreed, right? It was it was VRA – V realised automation. Right, I think? That person had a completely different idea of what platforms were. I think they they thought it was like Tomcat, or something completely opposite. Yeah.
32:03
So what, as I remember the conversation, it was we were trying to draw the line between, you know, where does infrastructure in and platform begin, and then crawling further up the stack? Where does platform and an application begin? And we had sort of and in this particular environment, it was death by 1000 meetings? Yeah, I think we we hit about 1900. With this particular discussion, I think we were fully dead by the end of it. Because it took forever to get everybody to get behind a common vocabulary in describing not only where those lines were drawn, but also how they applied to specific applications that were running. And the whole point of that was so that we could start to figure out how to decompose this and run it in a different way and deploy them faster,
32:56
Yeah, it was. And so we would have never gotten to that state where we got an agreement across different teams, have we not been speaking the same vocabulary. And so I think that’s really critical, again, for somebody that’s coming into an environment, and I’m learning their environment, and we don’t know each other’s environments, to get that understanding so that when we do have those conversations, you do learn, what does this mean? What’s the process? What’s the next step? How do you do releases, that everybody’s talking the same thing. And it’s easy for me as a manager, or somebody that would be managing or owning decisions around that, for me to understand how they think, because then I can tailor my conversation with them, so I can be most effective with what they’re doing.
33:38
Right? So you’re gonna hate this.
33:42
Oh, I hate everything but that’s okay
33:44
No, the place I’m going here is, and I think that this is something that gets less attention than it really deserves, especially in the cloud space, is the changes that have to occur when if you’re adopting cloud, around your IT Service Management Practices, and the way that you pursue it, specifically, change and release management, asset management, you know, functions that look like CMDB. Today, there, I think it’s, it’s completely under appreciated, how much that can just completely rob the value of cloud. Like, you know, you go to cloud for a whole bunch of reasons. And if that piece of it doesn’t adapt along with cloud adoption, you just like sort of like pull the rug out from underneath the value prop of cloud.
34:39
Yeah, no, I agree. Like if you don’t know what’s there and how to categorise whatever their means to you, whether it’s on prem or cloud, you have no idea how to migrate, how to manage how to do anything with it.
34:52
Well yeah and I mean, there’s some specific things like, you know, like going back to discussions I’ve had in other places before of, okay, well, you’re used to tracking VMs. Like you did physical servers before, right? So you have this phoney baloney serial number that’s attached in the asset record to a virtual machine? Well, okay, that doesn’t really apply in the cloud context. Nor does it really apply to say, you know, in an extreme case, all right, well, I’m going to treat containers as assets, which is completely bonkers, right? Because they don’t they’re the the whole point is they’re intended to be short lived.
35:33
Well, but just think about it from a different way. Think about it from an operations view. I actually had had this come up before, where you have alerting and monitoring. Are you going to alert when a pod restarts like you would if a VM restarted?
35:51
I mean, give me more context. I mean, maybe, but probably not.
35:56
But that’s the point, though! You have to think about it. If your VM restarts and it’s a single VM, not under a load balancer at all right? You probably really care about it, you want to have a lots of alerting and monitoring.
36:08
It’s a service-impacting event.
36:09
Right, but if it’s under a load balancer, you probably still care, right? You have to make sure you you move it away from the load balancer, efficiently. Think about a pod, though. Do you actually care? It’s the inverse, right? There’s probably a rare edge case that you do care. Most often you don’t care because that’s what Kubernetes does. So if you had VMs, restarting and redoing itself, and we learning that technology for years, nobody would care.
36:39
Yeah, I mean, it is it really is the difference between, you know, where you’re used to monitoring for, like infrastructure level metrics and up downs there. Now, instead of doing that, you’re measuring and you’re monitoring against, are we throwing four hundreds?
36:56
Right, or ive hundreds or yeah, anything. Or do we want to track performance instead?.
37:04
Right. Yeah. And I mean, there’s, there’s other stuff in the Kubernetes world that, you know, eventually we’re going to get to Kubernetes and containers, and we’ll do a deep dive on that. But there are things that you know, Kubernetes will throw that are indicative of like, ooh, something’s really funky here. Where, like, you know, the master can throw a thing that basically says, I can’t schedule this pod, because I can’t find any nodes that are appropriate.
37:27
Yeah, that’s a little scary.
37:29
That’s something you want to go look at, right? Or I’ve attempted, you know, like, a pod is crashing. And I’ve tried to reschedule it a whole bunch of times. And now I’m gonna back off because, you know,
37:39
I’m tired of doing it!
37:42
I’m tired of doing it. And I’ve hit a point where I could, you know, just consume resources for no reason, right. This thing is, this thing is clearly sick. I’m not trying to fix you anymore.
37:51
I have an idea for a kid’s story now.
37:55
Oh, okay.
37:56
It’s Kubernetes if it was a person, okay…
38:01
I think this is an episode of storytime! So, please continue.
38:04
So when you were saying that I’m thinking myself, okay. If I was there physically trying to go restart a VM, and I got tired of it. You would probably hear some cuss words, I’d probably go text somebody as I hey, or, you know, send them a chat on Teams, like, Hey, how are you seeing this problem too? Like, have you seen this before? Right, or maybe do some googling, right. And then eventually, I’d be like, alright, I’m tired. I’m gonna get a drink of water. And you know, it’s probably dinnertime. I’m gonna leave and just stop. But if your Kubernetes, like … I don’t know where I’m going with this.
38:36
No, exactly. Yeah. This is like a twisted version of Goodnight, Moon. It’s like ‘good night pod’.
38:41
Right, ‘Good night pod. I’m done with you. I’m sorry.’
38:43
Good night DevOps and the ops squad.
38:46
I’m sorry I failed you!
38:50
Okay, yeah, I guess we could write some kids books.
38:53
But if you think about it, like in the old world, and old being, just VM virtualization, that is a realistic thing, right? You have to have a person there doing it. But when you have a Kubernetes thing, you probably care after like, a couple hours of something happening, not the first time. And it won’t end because it’s a system, right? It’ll end when it runs out of resources or, like, it’s not running through a script, right? It’s running through its processes.
38:54
Yeah and I mean, it’s just a transition in thinking that if you don’t adapt your thinking, and you think that you know, you can go to, and we’re talking about sort of like three steps down the road, frankly, even if you just go to cloud infrastructure, and you try and treat it like you did your on prem infrastructure, and you don’t make the leap to say okay, I’m going to use the cloud providers tools, and ways of detecting when things are busted versus dragging Nagios or something weird along with you. It’s like you’re missing the point. You’re robbing value that you could be getting, you’re also reinventing the wheel because cloud providers have already dealt with this, right? They have mechanisms for figuring this out. And their guidelines are generally pretty good, right? It’s because it’s not just based on one company’s experience. It’s based on kind of the world’s experience running stuff on that platform.
40:11
Right? Yeah. And and it’s going to have not, you know, when you talk about the world’s experience, it’s not gonna be just your application. It’s gonna be applications like yours written in different languages, but also same, right? So you have the different tools available based on your needs. The hard part is not going service and go use every service for everything, because then you’re just like, you’re wasting time. But it’s also using it in the right way. I mean, there’s some really cool services I like to use in AWS, but I have no use for them. So like, I’m never gonna learn that.
40:42
Yeah, we kind of touched on that a little bit of just like, there’s way more services than you’re ever going to touch, most likely. And that’s okay. Like, they’re not, you don’t have to use all of them. There are some that are very niche. Like the I don’t even know what it’s, I forget what it’s called. But it’s AWS’s satellite thing. There’s like zero chance of me ever dealing anything with it.
41:05
Is it a satellite? What is it?
41:06
Yeah, I think it has to do with like running workloads on satellites or something.
41:10
Like on an actual like a, like a, like a satellite or like location that’s not near you. Satellite?
41:16
No, no, no, no, no. Like, they announced that they were working on running stuff on on satellite running stuff in orbit or something. Yeah note to listener, I will see if I can dig up a link and we’ll tweet it out. But yeah, it’s legit. And then they have another thing that’s like 5g, like it’s all wireless broadband based. And it’s for like mobile, like IoT applications and stuff. It’s like, it’s all really interesting. I’m sure it’s very valuable to somebody, that somebody is not me. Like, I’m not gonna touch that. Right. And it’s okay. Not for me.
41:53
Yeah, no, that’s … yeah, I mean, that they, so so that would be like, interesting. Like, I want to go Just think of random stuff to go create, like services to go create. Like that’d be cool. How do you get that job?
42:03
I just want the job of whoever names AWS services. I also want to know what substance it is that they’re ingesting on a daily basis, because those names are nuts.
42:13
Well, it’s not even that. What bothers me about it is the format of the names, they’re not all the same, like they’re not all AWS service name. It’s service name, it’s lowercase. It’s a couple of words, like when there’s AWS somewhere in the middle, it’s like, the whoever internally inside of me that has OCD. When I see the name. I’m like, okay, it’s not uppercase. It’s camel case. Where is your data dictionary? Like where is it, please?
42:42
Yes, exactly. Well, look, I appreciate you taking the time to, to talk and I feel like this might be a, you know, semi annual segment or something like that.
42:53
Yes, ramblings!
42:55
Yes, ramblings with Joel and Alicia. But anyway, thank you much as always, always good to chat chat with you. And we’ll, we’ll do this again sometime.
43:04
Awesome. Thanks. Appreciate it, man.
43:07
Thanks for listening to this special episode of Cloud Unplugged. We will be back next week with the first of our two part series on modern application development. How do you build applications that run in a performant cloud native way? As always, if you have questions, comments or other feedback on the show, we would love to hear from you. You can rate and review us on your favourite podcast app. Feel free to tweet us at cloud_unplugged, or email us at cloudunpluggedpodcast@gmail.com. You can also find us on YouTube: Cloud Unplugged, for episodes transcripts and bonus content. Thanks so much for listening. We’ll see you next time.
Transcribed by https://otter.ai
