Transcript
0:09
Hello, and 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, an interview with Eric Santelices. He’s currently a consultant working in the cloud space, but has an interesting journey, getting to the cloud, and I hope you’ll find very enlightening and interesting. Without further ado, we’ll get right to the episode.
I am sitting down with Eric Santelices. Eric, you want to say hi?
0:42
Hi, Joel. Eric Santelices here.
0:43
Yeah so Eric and I know each other from from past life, we work together on various endeavours. And so I think, Eric, if you just want to introduce yourself, tell everyone a little bit about your background, where you came from and, you know, really, you know, how did you get started with cloud? How did how did cloud become a thing in your life?
0:44
Let’s see, well I was born and … no, sorry. Yeah, so a long time ago, I was a I was a Sys-Admin for a Windows shop. And you know, I was dabbling in Linux. And this is during the .com era. And so, you know, there was kind of, during the typical.com era, there was a round of layoffs that occurred. And towards the end of the day, I was like, I’ve made it through, I’m not getting laid off. That’s awesome. And then my manager comes and taps me on the shoulder. He says, Eric, can we talk to you? And I was like, oh no.
1:49
Oh, crap.
1:50
And so he takes me into the director’s office. And we sit down, and we have a chat. And he says, you know, just to set your mind at ease, you’re safe. But we have a new job for you, if you’re interested. And I was like, awesome. What is it? And they were like, we want you to be you know, like a full time Unix admin, because we’ve been watching you, and we know that you’ve been dabbling in Unix, and we want you to become a full time Unix guy. And I was like, Sure. Okay.
2:21
Score!
2:21
So yeah, exactly score. So that kind of got me started going down the path of, of doing things, you know, much easier. You know, with automation, at the time, we called it scripting, also known as Pearl. And so, you know, during my time there, we went from a data centre that had you know, 18 servers, or I should say, three data centres that had 18 servers in total, to over 600 servers in my five years that I was at this organisation. And again, like I said, this was the.com days. And so we obviously had to do things that that made our life easier, right. And so I spent a lot of time building out automations, I spent a lot of time building out build scripts. At the time, we were doing Solaris and Linux. So I was doing both, you know, Kickstart, and what was it? Jump? No, it wasn’t Jump. I can’t remember what Solaris called it. But we had serial console is going to our all of our machines. And so, you know, one of my jobs one of my tasks was to kind of normalise and stabilise the build across platforms, right. So we wanted the same version of Apache on both systems, we wanted the servers to be hardened, because we were calm, etc, etc. So that got me down this path of like, trying to do things at scale. And so I promise there’s a point to this, right?
2:25
Oh, no, this is great.
3:44
So, so getting to doing things at scale. And in my research, Pearl was great, you know, but and we were using source control, right. And so I started adopting some source control principles in in my sysadmin because I was writing all these Perl scripts and had to keep iterating on them. We had a couple of folks who were like, seashell fans and they were like, you know, I I don’t do anything in less at Cincy. But, you know, again, I was just trying to keep things easy because I was still learning the platform while I was doing all of this. I came across CF engine right and so, when I landed on CF engine, you know, that was my first intro into doing kind of you know, large scale distributed you know, development right and so, you know that that was kind of the foundation and of cloud right and so, you know, when you take the the automated provisioning automated building of servers, and then layered on like CF engine Right. Everything I’ve done in my career kind of since then, has all been based upon the work that I did back in the early 2000s. So that’s the point I was trying to get at, like cloud for me started in like 1999. Although it wasn’t really cloud at that point. But automated provisioning, automated building of systems, automated hardening of systems, build scripts, and centralised management was something that we were doing way back then.
The company that I was at already had the notion of a deployer. And the deployer had to be modified because it didn’t support parallel SSH. Again, like I said, we started out with like 18 machines. So we had to move, when we got 600 servers, we had to move to parallel SSH. We already had a notion of machine types and machine groups in our deployer. So we didn’t have to go and rebuild that piece. But we had to add that distributed ability there, right. So the reason why I started back there, you know, way back when with Cloud is because like I said, the principles that I learned, the principles that we developed, have been applied over and over and over again, right, the patterns. And so that’s kind of the point I was making. The patterns that are used in bare metal data centre during the.com era, but the same principles that I applied when I really started in cloud, which was in 2009.
6:40
Right, so you were you were really early, and the things that you’re describing are actually things that we’ve talked about on the Podcast, obviously, just in a later form. But you were there at the beginning, or some of the formation of the principles that we talked about, like making sure that you have things under revision control, everything that you need to build your environment, building things in an automated way, standardisation, all that stuff. It sounds like you were you were really sort of pioneering the way in a sense.
7:12
I would say pioneering, yes. I didn’t do it alone, I didn’t do it in a vacuum. When I go back and I listened to you know, the DevOps Gods and listen to their talks and their, their their history. I was doing it on a much smaller scale. I didn’t come from a developer background. My background was System Administration. So I had a different perspective on all of this. But, you know, to some extent, yes. You know, it was pioneering, there weren’t a lot of companies who were doing automation.
7:49
Right. Yeah. I mean, that was really that was really early days. Yeah, for a lot of stuff.
7:55
Right. And so like, you know, even to that extent, like to sit down and write in CF engine, you know, to write I can’t remember what it’s called nowadays, but, it’s a recipe, right? Yeah, to write a recipe to install bind, right? It took the guy like four hours to do it.
8:16
Yeah, CF engine was pretty was pretty tricky to to use, as I recall.
8:22
Yeah, it took us the better part of three months to get the platform up and running to do basic things. But this is why tools evolve, right?
8:33
Yeah, totally. And actually that sort of that hits on something that I wanted to ask you. Because obviously, I know a little bit of your story, but it’s really good that you’re unpacking it for everybody. From from the time that you started doing that work, which was still inside the data centre, but definitely leaning heavily towards automation standardisation, things that look very cloudy today, to 2009 when you sort of first got cloud, and I’m making quote fingers: “cloud proper” sort of entered the picture. You know, what are the changes that you’ve seen, or the sort of missed maturity stages, or big changes in cloud that you’ve you’ve noticed over the years or how have things been reapplied in ways?
9:22
Yeah. So, you know, from a patterns perspective, I started out with Amazon in 2009. When we started an Amazon, it was a need because we didn’t have budget, we didn’t have data centre floor space. And we signed on a new customer and we needed to build infrastructure for him, right. So we started with EC2 classic because we were like, what is this VPC stuff? It’s Voodoo, it’s magic. We know what we know what a VM is, so let’s build a VM.
9:54
Right.
9:55
And so, we started building them by hand using the interface. Click, click, click, and that was awesome. Quickly realising that we need to do something more than just this. And so, getting back to that pattern, right, we had already established in our data centre, Kickstarter. You know, we already had the ability to build our boxes. We had dynamic DNS and MAC address registration and all that fun stuff. I can kick off a machine that’s a virtual machine that was a web server or an app server or a database server, just by putting the MAC address in a file, building machines in Amazon, we were clicking through the interface. We didn’t want to use any of the Amazon images or the Sint OS images, because if you guys remember, in the early days, it was like the Wild West in the marketplace, right?
10:50
Oh yeah.
10:50
RedHat didn’t exist, CentOS wasn’t publishing certified images at the time. And maybe if they were, we didn’t trust them. Because we didn’t want to go through the security audit ourselves. So after doing the onesie, twosie thing, you know, we were like okay, well, let’s figure out this VPC thing. And then we got a VPN up and running and, you know, kind of built out our first you know, VPC. Quickly after that is when we built our deployment server. And so, you know, having two environments now, quote, unquote, two data centres, right, if you want to call it that, and we were doing it the wrong way, we were treating Amazon as a data centre. We quickly found the need for, you know, better automation than that just the jump boxes and the scripts that we had written at the time. So we started looking for a centralised management, you know, we stumbled upon puppet, we had some brief experience with Puppet, I had brief experience with Puppet in other jobs prior too, and I was like, let’s introduce it. And you know, most of my admins were very against it. Because it was new and scary. And they had to code, right, as opposed to using cluster SSH or whatever other tool they liked using t mux, or whatever it was, at the time to work on 20 machines at one time. So we started down that path. And so that came to the second generation of in my in my world, right, the second generation of the second time, I got to apply that pattern of the CF engine and the automated boot script. And so as a leader in this organisation, I challenged the team. I was like, come on, let’s get to being able to build a machine, whether it’s in our data centre, or it’s in the cloud the same way. And let’s see if we can do it faster, right.
And so like, I created this, like they say, gamification. And this was probably like 2010 or 2011. And I’d been to a Gartner conference, and they talked about gamification. So it’s not something I invented, but I was like alright, here’s the cloud team. Here’s the on prem team. Who can do it faster, right? And, and I set them off on their ways. I said, you guys can share code, you can reuse code, all you want from Puppet, but you know, you have to do this. And you have to do this, right? You have to, you have to bootstrap your machine. And you have to deploy these packages. And so that’s where we started going down that path. Now, we were a team of three. So I was the fourth member. So we had two teams, and I rolled up my sleeves. I was there with him. I was a team member, I was building code, writing code supporting code. You know, it’s because I was always an active working manager.
And so that’s how we started down that path. Right. But I didn’t want to, you know, I kind of led the team and told them what I was trying to get to, from from a goal perspective, and I was absolutely, you know, helping the team. And I didn’t try to like, you know, see if edge to puppet are two very different beast, right? For sure. So it’s not like, I could just go and reuse the code that it did in the past. But, you know, I having done it once, before, I had in my mind, you know, kind of this master plan of how what I wanted to do. And so that’s how we kind of went down that path of, you know, breaking the teams up one on prem one cloud. But you know, ultimately, the goal was, let’s automate this and then let’s combine our code, right, let’s merge our code. Let’s figure out how we can use one code base to do the job and both look in both environments.
14:31
Okay, cool. So from that point, there were now two experiences two applications of the same pattern. And then, you know, obviously, that was, I think you said it was around 2010 2011 timeframe when you were doing this in Amazon. Fast forward to today. And the landscapes, in some ways is very similar. It’s very familiar, but it’s also pretty different. I mean, knowing what you know, now I think it would be interesting, like, what if you if you could go back and have a conversation with with Eric in 2010 or 2011, what would be the coaching, what would be the the, the learning that you would pass on?
15:15
Um, I would go back and tell Eric of 2010 2011, to look at Ansible more closely. Because Ansible, 001, beta, alpha, whatever it was, had just dropped. Number two, I would have put more emphasis on understanding the cloud patterns. You know, in those earlier days, in 2009 2010, we were looking at Google a lot and looking at their patterns, we were looking at Netflix a lot and looking at their build patterns, right? Yeah, because those were the big guys. And if, you know, I had a little shop, I had, you know, 30 bare metal machines, and we were running probably, you know, 200 250 virtual machines on prem. But, we still had aspirations, because we were a software as a service company, that we are going to grow and explode. You know, so we were looking at these patterns, but, you know, sometimes taking those patterns that the big guys are doing and applying them to, you know, on prem, I kind of shut things down a lot quicker when talking with some of my developers, on on some of these, you know, projects that were out there, you know, so the coaching would be: pick a language, learn a language, from a development perspective, you know, rotate a little bit more in and out of a development team, as opposed to being just an infrastructure guy on a scrum team.
16:48
That’s interesting.
16:50
And, and, and be more active that way. Because, truly, you know, if you don’t walk a mile in someone else’s shoes, you don’t know the problems that they go through. Right. Right. And so, you know, we, so we were going through this evolution as a company, right. And so, you know, we were adopting cloud, we had gotten some funding. And we were all trained in agile and became certified in Agile, right? So, I became a certified Scrum Master and a certified product owner. And I, and I was, we were struggling constantly struggling with how do we incorporate the infrastructure team into Sprint’s? How do we get the infrastructure guys, because we were all sis admins, right? How to write these old sis admins, you know, into, you know, this, this this approach, right, and it was very painful for us. And it took probably about two years. But we finally landed on, you know, you know, some key events, right? backlog, grooming, retros, retrospectives, sprint planning, and demo, right? We ended up, quote unquote, forcing the sysop team to participate. And I say forcing, right? Because even though we you know, there was a sprint out, there was no infrastructure activities, like, do I have to go? Yes, you have to go because you’re an active team member, etc. and stand up, right? So we would, we would also participate in stand ups, at least twice a week. So, you know, we ended up getting the team to start participating in that way, for a couple of reasons. In the backlog, grooming and the sprint planning, we could kind of, if we were actively participating, we could actually listen to and see when resources are going to be needed, or when decisions were being made about infrastructure, or an environment that affected us directly. Right. Right. And so even though we didn’t have we weren’t active team members, we may still have to understand that, okay, well, they’re changing the way this API is working, or they’re changing the way this applications talking, that’s going to cause me to have to go rebuild machines or update my my puppet code. Or I’m gonna have to create new firewall policies. And I don’t have a module for that yet. So, you know, let me go start working on that, right. And that’s kind of where, you know, we were still kind of where the infrastructure team and we’re gonna, you know, we’re gonna control when you deploy, and we’re going to control how you touch our environment, etc. And, you know, we were the team of No, is basically what we became right? But it was for good reason. Because we were the ones who were getting called the three o’clock in the morning. We were the ones who were deploying at 4am. We were the ones who, you know, had to leave the football game and go sit in our car for the next two hours to fix the production issue. Right. So so the coaching would be is, you know, walk a mile in someone else’s shoes right and And the same thing for the dev team, right? And that’s kind of what like DevOps is all about, right? Is is passing that baton back and forth. I was too focused on uptime and availability and stability. Well, that’s what availability is, right? But even just stability of the platform, because we would have, we would write quite a bit of pro code again, because Nagios was our monitoring tool to restart services, right? To kind of, you know, again, you know, my, my philosophy at that organisation became, I don’t know if you remember this, but back in the day, when I was in college, and we were up late night, watching TV, there was this guy on TV called Ron Co. Right? And he was selling these, like,
20:48
it’s like, it dices
20:50
Yeah, he was selling all kinds of crazy stuff, right. But yeah, one of his things that he was selling was like this chicken roaster, or whatever it was turkey roaster. And, and the key word, it was like, set it and forget it, right? The audience would always chant and he goes, and what do we do? set it and forget it. Right? So I, you know, that was that became our mantra. Right. And so I found the video online, I showed it to the team in one of our team meetings, and like, he’s like, Eric, we got to do this thing again. Alright, just Bronco it right? That was our tip there, right? Just go Bronco it right? In other words, go build it the automation to fix that problem. So we don’t have to deal with this again, right? It’s and then it was like, Okay, if you have to do something three times. You got to automate it. Right?
21:35
Right. Yeah. No, I think that’s, that’s, that’s fair. And I’m totally gonna steal the the ronto thing. Like, that’s, that’s, that’s gonna get used. I. So in that period, where people were getting used to a new way of working, and I’m sure you were fielding questions of why do I have to go to this meeting again? Like, why, how do I fit into this puzzle? Yeah, I, I’m assuming a good portion of that was, you know, a learning a new process, right, how the teams are interacting, but there’s got to have been a fair amount of skill set gap that was getting back filled?
22:11
hearing. Absolutely. Yeah, absolutely. And that’s where I was saying that, you know, going back to the walking a mile in someone else’s shoes, right. So the development team you know, homegrown application software as a service, our development team, you know, we we worked with them to kind of standardise on their configuration files, because again, we were using puppet to deploy. So if I needed to deploy an application server, if I had standardised configuration files and standardised directory, I could insert variables into that config file, check it out of source control, and then insert variables into that file to make that application server unique. Right. Right. So, you know, this was something that I had to learn first, and, you know, I mentioned that I started dabbling in, in programming languages like, like Perl to make my job easier and 99. Many of the guys on my team guys and gals on my team had not done that at all right? And so right? It was a new paradigm shift, right? First, I had to understand it, and and kind of architected and, and push the developers to to move things into a more standardised way. But then I had to turn back around and start, you know, helping my guys learn these new concepts and these new these new ideas. Right. Right. That’s where I, you know, I, that’s where that comment comes from. Right. Like, if you could go back, learn the language, become an active team member, and, you know, learn these other valuable practices, like, source control, like, you know, proper development.
23:58
Yeah, yeah, completely. And I guess, he, the, where I’m going with this is I’ve been having a bunch of conversations recently. And they all kind of touch on a similar theme. And I’m just curious to get your opinion about this is, you know, the, the experience you’re describing happened a little over 10 years ago, or roughly 10 years ago. Now, you know, the the world has moved on cloud has certainly matured. I mean, if you look at AWS or Azure, or GCP, any of the pick one, you know, they’re light years beyond where they were, or where they started. And there’s there’s people continuing to come into the ecosystem and experiencing those skill gaps on a certain level. Like I think the the skill gap that you experienced in 2011. I’m not sure that the world’s that much different today for people that are coming into Cloud only. Maybe the hills actually much steeper in some ways.
24:55
Yeah. I would agree with you. I had a conversation once with with A buddy of mine. And he was like, you know, I, and he’s 10 years younger than I am. But he was like, I grew up with the internet. And like, as a developer, and as an engineer, and he goes, had I not grown up with the internet. While the internet was evolving, new technologies are coming out and new concepts and everything. He goes, I don’t know that I’d be able to get into it today. Oh, that’s fascinating. So so that was that was kind of interesting. So I wanted to just share that with you. So to your point, though, it is different. It is hard. And I say hard. It’s difficult, right? There’s a lot to learn. There’s Yeah, but but the the one thing that has really changed since you know, I started doing this is the availability of information. Right?
25:55
Oh, 100%?
25:57
Yes. And so and I don’t mean just googling something, right. I mean, like, you know, we didn’t have like, a clock. We didn’t have podcasts, we didn’t have a cloud guru. Google, even back in those days, in the early days, what, you know, they didn’t have like, the search engine didn’t didn’t crawl the entire web, right? We didn’t have personal blogs, like we do today. I mean, personal blogs for geo city in my space. Right. Yeah. And who’s, who’s blogging? Or who’s talking about, you know, technology, right, during those days, on those platforms? But, you know, it’s so so it is, I would say it is exponentially, you know, more challenging, more difficult to get in today. But there’s also so many more resources available to learn. And I think right now, we’re back in a situation where you don’t have to be a generalist anymore. I mean, you could really be a specialist in cloud, and, and still be successful.
27:02
Yeah, absolutely, I think you you, you really, really can, because, in a one flavour of the conversation I was having earlier this week, I think really kind of touches on this is, we’re now in a world where it’s all you need to get started and have access to all of these services is a credit card. Right? Before your point, you needed a data centre with power and cooling and physical racks and hardware and cabling, and all this stuff. And there was a much, much, much higher barrier to entry. Now, you can swipe a credit card, and you can get access to all of these services. And so in a certain sense, the problem and the complexity is all shifted away from where it was before. And now it’s, there’s hundreds of services, all with their own operational paradigms, all with their own unique way of working, and you can compose them together and build amazing things. But it’s tackling that mountain of functionality.
28:04
Would you agree with that? Absolutely. Yeah. And that’s kind of why I said, you know, you can specialise again, right? Because we’re time. And there’s still, you know, there’s still people who will be like, I want to be a gentleman generalists, and I want to know, everything. But, you know, if, yes, you can, you can glue together the world, right? And I say glue together, right? Because there’s so many services that are out there that if you’re good at writing Glue Code, you can, you can cobble together some really amazing, highly scalable systems today, without having to write you know, a lot of the the underlying code, right, you’re just maybe you’re putting together some business logic and stitching together some services, right? You think like a shopping cart, or, you know, a retail site of some sort, right. But, you know, if you want to focus on on cloud, or, you know, that’s, you know, AI as our paths, right? You know, my advice would be is, is, you know, pick, pick one, right? You know, start with one, and then work your way towards the other. Right. And I’m, I’m always the type that, you know, again, coming from the sysadmin background, I like to start at the bottom and build my my knowledge base up, right, build my my technology stack going up. So I want to understand the nuts and bolts, I want to understand the networking, the load balancing, the server OS, the virtual machine, or OS write the function or the lambda, you know, whatever, you know, container that I’m building, right and go upwards. Versus, you know, the guy who just wants to get something out there that’s going to use some pass and sass and in some serverless
29:53
Yeah, completely, I guess where I wanted to take this in So you’ve got all of this, this weight of experience coming from, you know, really, you’ve passed through two big generations of the industry, at this point, right to two major sort of uplifts, right? Or a paradigm shift. And, you know, you’re, you’re now on the consulting side. So, you know, your relationship to the the technology is a little bit different, right? That’s correct.
30:26
Yeah. I’ve stepped away from the day to day operations, as they say.
30:31
So I guess, here’s, here’s my thought is, we’ve been talking on the podcast a lot about, you know, the journey of getting to cloud in a practical sense for for people that are just now starting the journey. And, you know, we’re, we’re sort of touching on on things in this conversation that we’ve, we’ve hit on, but maybe not in the same depth as a consultant. I’m curious about your perspective, because you’ve seen many, many, many customers go down this same adoption journey, you know, from different starting places, but ultimately, all kind of marching towards very, very similar goals. I’ll put it that way. Right. You know, what are what are things that, you know, the people that are listening to the podcast could take away as either, you know, things that you think are sort of critical success factors or activities, or things that you absolutely have to do? Or anti patterns that you would say, Look, just I’ve seen this over and over and over again, don’t do it?
Yeah, so good question. I actually have, so I’ve got use cases for multiple use cases on on each one of those points, right. So let’s start with anti patterns. One of the things that I’ve been experienced, or that I’ve experienced over the last five or six years is the Enterprise’s desire to kind of boil the ocean and have the the the the final state, perfect state architecture. You know, this will meet all of our compliance requirements, this will meet all of our application requirements, have that final design done from day one. And so right, when enterprises start going down that path, and I’m not saying it can’t be done, but I’m saying that most enterprises, when they start going down that path, they end up in that, you know, analysis paralysis mode, right? Where? Oh, well, you know, we need to to take this into account, we need to take that into account. They’re not being very agile, right? It’s very waterfall methodology. They’re where they’re trying to get to this final state. And as they go through that process, they end up having to bring in more and more shareholders into the conversation, which isn’t a bad thing. But when you have, you know, 20, or 30, chefs in the kitchen, it’s tough to produce a single, yeah, you know, a single dish, right? So, I would say, you know, don’t try to boil the ocean, especially if you’re learning new technologies, right? I mean, if you’re an old zactly, and you know, cloud, and you’ve been working on, you know, you know, Amazon Azure, or Google for for for a decade, as a company, then maybe that’s, you know, a way to or as as a as a team or a centre of excellence, then maybe that’s a way that you can be successful. But if it’s a new venture for the company, start small. I mean, don’t, don’t try to boil the ocean, don’t try to come up with that perfect design. Because you’re going to make mistakes. And and I said it earlier that, you know, I started out with EC two classic, and we’re building machines by hand. We made the mistakes, we found out that was the hard way to do things, there’s easier ways through sees your patterns to learn. Yeah. So so that’s the, you know, the the anti pattern right is Don’t do that. Don’t Don’t just try to like, oh, we’re going to close our data centre down and move everything to cloud. Well, what’s your cloud experience? So we don’t have we’re gonna run it as we do it. Right. Okay.
And can we can we push the pause button for like two seconds and talk about lift and shift? Sure. Because I think that there’s a lot of confusion out there about what lift and shift what what that actually gets you. And I would love to know, like, if somebody is going if somebody is going to go down the path of we’re just going to we’re going to evacuate our data centre, we’re gonna lift everything that we currently have, and we’re going to plop it in easy to what, what does that actually get them? Practically speaking?
Practically speaking, it will get them. No one on the phone is from Amazon, right? It’ll get them a higher a higher cost per month run rate, right? I mean, the math is out there. If you literally do a lifted shift, you end up with an environment that costs money. More in the cloud to run in than it does on prem. Now, one thing that you can argue, and if you look at certain, you know, the big organisations like Forrester, IDC, Gartner, when you eliminate the data centre costs, you eliminate the hardware costs, you can see some reduction. But, you know, when you say lift and shift, right, I’m taking it at word lift and shift, meaning all of my machines in my data centre are currently over provisioned, because I built them for peak capacity. Because I didn’t have an elastic environment, I didn’t have the ability to source additional hardware. In minutes. It took me months or years, or budgeting cycles, right? So if I lift and shift, then I’m over provisioned. Now. Yep. What I what we do as consultants, right, is we talk about lifted, right sizing, you know, lift and shift, but with an optimization. Right? You know, and there’s different, you know, different organisations will call it differently, but, but you’d never just want to take machine a, and virtual, you know, take that virtual machine a and make it an EC two image, that’s the exact same specs, you always want to do that right sizing. Because otherwise, like I said, you will eliminate the hardware. So you don’t have to go and replace a hard drive in the middle of the night, which, you know, nowadays, our manufacturers pretty much do for us. So you don’t have to worry about that you don’t have to worry about your hardware cycle, reordering your hardware every every three to five years and upgrading your switches and all that fun stuff. Because that’s taken care of for you. So you can eliminate those challenges. From from a lift and shift to the cloud. And then but you need to recoup that time, you know, that you’re not spending on the hardware portions, and learn the cloud technologies to optimise the environment that you just shifted into the cloud.
Right. So that’s kind of your your, your hitting on exactly what I thought you were gonna say. And that’s, do you think that people when they are organisations, when they pursue lift and shift like that, understand that effectively what they’re doing is entering a transitional state, that the lifting and shifting is not the end of the story?
Well, they may understand it going in, and it may be in the back of their mind. But again, most of the it organisations that I’ve encountered over in my consulting career are overworked and understaffed, right? Yeah, for sure. You know, they have they have a lot of tech debt, as we say, right. And so they, they, they may displace the, the infrastructure bits, right, so they don’t have to worry about that anymore. But now they’re worrying about trying to figure out the cloud. So it’s just backfield with something else. Right, the the the extra time that they would have gained 10 15% of their time, is is backfield with the additional backlog that they have. And, you know, learning or understanding this new technology, and not trying to say this as a negative. You know, I’m trying to, you know, I’m just painting the reality of what I’ve seen. And and for sure,
yeah, I mean, yeah, so they, they now, I mean, practically speaking, the way that I look at it is alright, they take the initial step, they now enter a transitional state, while their organisation then addresses that skill set gap and learns everything that they need to learn to go and optimise and put the things that they lifted and shifted into a state that they can sustain long term.
Right. Yeah. So yeah, one of the other things that I you know, I also talk to organisations about is, you know, what are the pain points, right, where are the problems in the environment? You know, I lived through this early on in my career, with with contention in the environment, whether it was not having enough application servers, not having enough, you know, queuing systems not having enough I ops of storage, not having enough memory, right, you know, pick, pick whatever you want to pick in your environment. And I can guarantee you’re going to find some contention in that at some point in time. So, you know, look for areas, if you’re going to just do a lift and shift, look for areas where you can actually improve the platform by adopting or using a cloud native technology. So if using my sequel, then go to Aurora, or go to RDS, right? Because now you no longer have to manage the server. And if you do need more resources, it’s a couple of clicks away. If you want to do it the lazy way, if you want to do it the right way, do it through an API call, or c li, and, you know, now you’ve got more capacity, right? Yeah, so sure. So that’s, that’s what I you know, that’s my recommendation is look for those areas that are easy. web servers, you know, put them into an auto scaling group. You use the cloud providers load balancer because Because they automatically manage that for you, you can eliminate licencing and eliminate costs by doing that as well.
Yeah, totally. So getting to so I don’t know, if you had more anti patterns you were, you’re wanting to get to, or maybe we want to get too.
out there. Yeah, I’ll throw one more anti pattern out there. Because it’s, it’s just one that, that I’ve bumped into time and time again, and, and it’s around security, security in the cloud. You know, there’s a lot of great security engineers that are out there. You know, and they do a fantastic job. And it’s not to, you know, to talk down about the work that they’ve done on prem. But, you know, in the cloud, there’s different security patterns, there’s different ways to gather, collect, analyse, and inspect information between the applications. If you have an environment on prem today, that’s insecure, by nature, and you’re using, you know, your security appliances to create that. Those those security boundaries. As you as you’re looking to move your these applications or these systems to the cloud, look at the two things right, what can the cloud provide you with, that can display some of those systems that you have on prem today, and still meet your security compliance requirements, because I guarantee there’s a pattern already out there that someone else is doing that is meeting these requirements in the same industry that you’re in, number one, but number two, it’s kind of the, the the old adage of, you know, VMware was a great technology, because it allowed developers to be lazy, because infrastructure, was able to create the high availability and resiliency, you know, security is kind of one of those same things, right. There’s a lot of security appliances and security devices that are created to instal and protect or create these boundaries for systems and applications that are covering for accounting for lazy development, lazy develop, or lazy requirements to the developers, right. And so, you know, if you if you find these as you’re, as you’re looking to move to the cloud, they need to be put into your backlog. And they need to be prioritised, right? Because otherwise, you’re never going to modernise your application stack if you continue to use, you know, some of these legacy systems in the cloud. The other thing that you end up with is potentially you end up with an and this goes along with the anti cloud pattern, right? If you have all of your routes going through these pair of devices, right in the cloud, you’re no longer using cloud native networking, cloud native routing, it’s networking and routing you had on prem.
Yeah, it’s it’s funny, because john and i have already we’ve beat up on the network teams, I think a little hard in this podcast so far, is specifically for that. And also from the standpoint of resist the urge to recreate legacy and another form. Right. And I think that’s, that’s at least in part, kind of what you’re describing is, you know, there’s, you kind of want to there’s, there’s a tendency to want to drag everything with you and just say, well, it works over here, it must work over here to
exactly understand. Yeah, and that’s where I’m getting that from going, as I understand the technology, understand what it can give, give you and do for you. And then use the cloud platform technologies to give you those same capabilities without dragging that legacy hardware with you, or those legacy services with you.
Yeah, completely. So on a more positive note, what what are things that people should absolutely do? What are the must haves?
Well, you know, I would strongly discourage using the console, the must haves is, you know, do it through c li, B, because that will get you using the API’s of the clouds. A lot of the clouds now have these cloud consoles, which give you the ability to log into kind of a container that has persistence, and give you a shell command in the cloud versus using your your machine on prem or your laptop or whatever it is you’re using. So that’s that’s one thing, manage the cloud through API. Because that will get you thinking differently about the console. It will get you thinking, thinking differently about the environments and how you’re interacting with them. So that’s one the second one would be is you know, don’t you know, find an application, you know, going back to the lift and shift, you know, portion of the conversation, don’t just try to close down a data centre, move everything, right? Find applications that are actively being developed, that are actively being worked on, that you can work with those development teams, and talk about what it would look like to run a pilot of that application in the cloud. And if you’re, if you have the right patterns in the environment, where you’re using source controlling using a deployment tool, you know, start up again, my my sis admin is my inner sis admins coming out, right? You know, take it upon yourself to try and deploy that application stack in the cloud, right? You know, fork the code, you know, fork, your, your ci CD pipeline, if you have one. If you don’t, you know, take your dogs that you get one, right. That’s, that’s another conversation for another day. But, you know, take your deployment guides, and your run books and build and deploy that environment and build an environment in the cloud for that application. So start small, right? Because as you do that, you’re going to really learn a lot about the cloud platform, you’re going to learn a lot about the application and all of its requirements. And And then from there, you can start building upon it, right. So you know, again, don’t try to boil the ocean. But you know, rather start small and build from there. Yeah, you’re
you’re definitely yes, ANDing a lot of stuff that we’ve talked about on the podcast already. And I want to make it extremely clear to the listeners that Eric is not on our payroll in any way. He has not been coached. Yeah. So anyway, keep going, I can’t wait to see what happens next.
46:55
You know that the next thing I would go do from from a from a positive, you know, from a pattern perspective is, is start looking at what containers can do for you. Clearly, if you’re in a Windows environment, Windows centric environment, your your, your mileage may vary, but for sure, if you have Linux systems, or Linux based systems, applications, start looking at containers. You know, even if it’s a matter of deploying a virtual machine in the cloud and putting a container on it, to see if you can containerize that application, if you don’t have a proper dev environment on prem, I would go down that path, because super good learning exercise, learning exercise, it, going back to my previous comment about well, but I teach Eric in 2010, you know, learn some better practices around, you know, build, and how to define properly, you know, runtime environment, and codify it, which then starts setting you up for being able to use Kubernetes. And or, you know, orchestrator, like like Kubernetes. Right?
48:07
So anything else on your, your must have list.
48:12
If the cloud provider that you’re going to has a service for the technology that you’re using, adopted. I was at almost all costs, right? You know, and that starts with, you know, SQL Server. If it’s, if it’s cost effective. It starts with MySQL, Postgres, right? They the common databases that are out there, you know, if you’re using something like, you know, memcached, or Mongo, or Hadoop, I mean, there’s, there’s cloud equivalents, depending on which cloud you’re going to mileage may vary, of course, but adopt those technologies, queueing systems, right. A lot of the pain points that I had in my previous lives. Were around our queueing systems. Joel, we’ve talked about, I’m not going to name names, but we’ve talked about some of the horrific, horrific queueing systems that are out there. From the early days, you know, yeah. And then you have licencing costs on top of them, right? Oh, yeah, I
49:15
think we’ve I think we’ve both been bitten by that, by that bug in the past.
49:21
But but these are, these are systems, right? So like databases, right queuing systems that can have the potential to grow quickly, and to grow out of control. And if you’re trying to keep up with a very active queue by building and provisioning machines through automation, you may never be able to catch up right to keep ahead of the curve of what’s required. Yeah. And and if you if you’re building this through triggers, and and monitoring, certainly you’re not able to keep up because monitoring chiefly throwing alerts when it’s already too late. scale up scale up. Yeah, but Then Then you have the scaled down problem, right? So that built all these virtual machines, and you may have messages that are sitting out there persisted to disk at some at some point and, and now you need to scale it back down. And you know, you’ve running, you know, 2030 4050 machines that don’t scale down easily.
50:16
Yeah. Talk about an underappreciated problem. Right? Everybody talks about scaling up, but nobody does, you know, follows that train of thought to Alright, well, when they’re not needed, how do we contract? Right? And sometimes it’s not so straightforward.
50:33
Yeah, it things can get complicated very quickly. Yeah. You know, I’ve, I’ve been in a number of situations where we’ve had to take systems offline and extract messages from queues manually re inject them to make sure that everything processed properly, and, you know, eliminate duplicates, and all that kind of fun stuff. So, you know, it’s not a fun problem. And so that’s, you know, kind of where my, my scar tissue lies is. You know, if you adopt, you know, and again, whatever, whatever queueing system, I’m not saying one’s better than another, because that’s a whole nother religious holy war there
51:10
is there’s like, you will need a young priest and an old priest for this one.
51:14
Yeah. But, but use the technologies that the cloud providers are giving you because they’re experts at scaling it up and scaling it down when it’s no longer in use, right. And they can scale up faster than you can and scale it down when you’re not needing it, which ultimately leads to lower cost. So going back to that lift and shift, yeah, I said that lift and shift will get you a datacenter. That’s more expensive in the cloud. If you start modernising these pieces of your application, or applications, now, now you’re you’re reducing costs in your environment, right? You no longer have to run five servers, just because that’s what I’ve always run before. You can run no servers and have it be, quote unquote, serverless, or a service that is just called upon as needed.
51:58
Yeah, absolutely. Well, Eric, I really appreciate you coming on and talking with us. I do for Is there anything that you’d like to share with the listeners, anything that you’d like to leave behind Twitter handle? Anything like that?
52:14
Yeah, you can find me, although I haven’t been doing a lot on Twitter lately, except for liking things. You can find me on Twitter at Digital roadies. And that’s it. He in rhodies. Just because there’s someone took my Twitter handle and hasn’t tweeted in 10 years.
52:37
Will will tweet it out with the episode so people can find you.
52:40
Sure. And aside from that, I mean, you know, this has been really fun. I appreciate the opportunity to come on here and talk with you.
52:49
Great. Well, it’s been fun talking to you and catching up. And hopefully we can do this again sometime.
52:54
Alright, thanks.
52:56
A big thanks to Eric for coming on the podcast and talking with us. We will be back next week at the same time Wednesdays. If you have questions, comments or other feedback on the show, ee would love to hear from you. You can rate and review us on your favourite podcast app. Tweet us at Cloud underscore Todd unplugged or email us at Cloud unplugged podcast@gmail.com also find us over on YouTube at Cloud unplugged for episodes, transcripts and bonus content. As always, thank you so much for listening and we will see you next time.
Transcribed by https://otter.ai
