This post was originally written for
Trend Micro .Reasonably Accurate 🤖🧠 Transcript
Mark: Hey everybody, how’s it going? Thanks for jumping on the stream today. Uh, we’re just double checking everything in the background. It looks all good. Um, we’ve got our live on LinkedIn. We are live on, uh, we are live on YouTube.
Um, as of course the audio hits me in the back which is why I had that stunned look for a second. There is a lot of logistics that go behind the multi-streams and despite having done this a ton of times, there’s always little nitty gritty, uh.
Let us know in the comments on LinkedIn, on Twitter, on YouTube at #LetsTalkCloud. If there are any issues, but more importantly if you have any questions as we go along. The whole goal of this, um, is to interview experts from around the world but also to open that discussion up to the broader community.
[00:05:56] Um, and that is absolutely key to get your input, um, to help steer this because everybody has a different perspective on this. Everybody has a different perspective on cloud and a different experience, and part of this series, Let’s Talk Cloud is really about exploring that.
So this is the second episode in the second season, we did the first season in the Fall. I had six episodes, mainly within the Trend Micro family. Um, because of some of this logistics, uh, we wanted to make sure, uh, we didn’t, uh, you know, embarrass ourselves or make it challenging for our guests. Um, but also, you know, leading up to reinvent, there was a ton of stuff going on and it just made it easier.
[00:06:31] Um, so, uh, well, we’ve got people tuned in from all around the world. I saw people in the comments from uh, East Africa, from Egypt, from Ireland, from the States, from Canada, from everywhere. Um, and our guest today is one of our first from outside of the Trend Micro family.
Um, and before I introduce him, I should probably introduce myself ‘cause you’re probably like, who’s this crazy guy talking to you into my, into your face in the, in the live stream.
My name’s Mark Nunnikhoven, I am the vice president of Cloud Research at Trend Micro. Um, and you’ll probably see me on these quite often and on other Trend properties.
[00:07:02] But more importantly, I have connected with a good friend of mine, uh, Forrest Brazeal who is the, uh, Cloud Bard at A Cloud Guru. And he’s gonna explain that in a second. Uh, he is an AWS Serverless Hero.
He, uh, was previously a senior solution architect at Trek10. He is a writer. Uh, he is a cartoonist, a very talented speaker, a man of many, many talents. Uh, Forrest, welcome to the stream. Uh, say hi to everybody.
[00:07:33] Forrest: Well, hey, thanks Mark. It’s so wonderful to be here and I certainly appreciate you inviting me on the show.
[00:07:37] Mark: Well, thanks for coming. So right off the bat, easy, easy question, hopefully. Cloud Bard at A Cloud Guru?
[00:07:45] Forrest: That is an unofficial title.
[00:07:47] Mark: Unofficial, I hope so. But what are you going for there? So I am an old, uh, unfortunately too old with a beard now. Um, but very old geek and as soon as I hear bard, I think like Dungeons and Dragons.
The bard character who goes around and tells stories, who communicates, you know, through music, through stories and through adventures. Why, why did you pick Cloud Bard?
[00:08:09] Forrest: Yeah. So, well, basically my job is telling the story of the cloud through music stories and adventures, so that was really well put. Um, but, uh, yeah, no, so I’ve been in the industry a long time. Uh, well I don’t know how long it would seem to you, but to me it seems like a long time. Uh, and I’ve done a lot of things.
I’ve been everything from, you know, an IT help desk administrator. I’ve crawled through floors and ceilings, laying cable. I have, um, uh, I’ve actually, uh, installed antivirus on doctors computers during live surgeries. And I’ve created robots to do machine learning. It’s, uh, I, you know, I’ve been a software developer. I’ve been a DBA. I’ve, I’ve, uh, managed teams in the cloud. I’ve been a consultant.
[00:08:43] And so through all that, what I’ve learned, I would say is that the really challenging problems in the cloud are typically not technical, they are interpersonal, they’re human. And that goes for technology as a whole, right? And so over the last few years, I’ve developed a real passion for, uh, educating people, helping them understand how the cloud works, why it works, what it does, how we can work together to solve problems.
And so what I do in A Cloud Guru is, uh, simply to try to tell that story, reach people, uh, through a variety of different media and, um, uh, if you’ve ever seen any of the like serverless versus containers wraps or the cartoons or other things that go on, you know just how crazy that can get.
[00:09:18] Mark: And that is actually a great reference point that I will include in the show notes. Um, an absolutely epic and legendary rap. That was a few months ago. It was around re:Invent time or a little before, somewhere in there?
[00:09:30] Forrest: Yup. Well before re:Invent at 2019. Yeah.
[00:09:32] Mark: Yeah. For those of you in the audience, that’s a treat post show, this will, this will be your lunch or dinner depending on the time zone, uh, force wrap can be your dessert.
Uh, it is truly amazing. Um, but I love that, that uh, you know, what you expressed there with communicating in a different, uh, different media, um, in different methods. Um, you know, and really, uh, what I find is a different voice, right? And it’s a very human voice. It’s very understandable. So, um, in the show notes we’ve got a bunch of references to some of your cartoons, some of your blog posts.
[00:10:02] Um, and I think as people read through that and as they hear you talk today, uh, they’re going to really realize that, that people side, and I think that’s critical ‘cause we see too much stuff that’s purely like, okay, so here’s the configuration parameter and then I did this and I did that. And it’s sort of dehumanizing when some of the challenges are really on that people side.
[00:10:20] Forrest: I think that’s true. And look, I mean, I don’t want to, you know, criticize anyone who is sharing things that they know. And I want to encourage everybody who’s doing that. That’s a fantastic thing.
And the reality is, you know, look, we’re, we’re talking about stuff that on its face could kind of come across a little bit dry, right? It’s a little bit abstract perhaps. Uh, and so I find it takes some extra effort to inject creativity and fun into that. And so that’s how I, how I try to connect with people.
And I think, you know, coming to A Cloud Guru that’s been their strategy for a long time, I guess you could say is, uh, making things really fun and relatable and fresh and, and that always attracted me to what they’re doing as well.
[00:10:55] Mark: Yeah. Okay. And let me, so let me just put a little disclaimer in the stream for myself so people know. I am actually, I do, uh, I have two courses out with A Cloud Guru as well. It’s, um, teaching the world to cloud is their mission statement and it’s really that all encompassing looking at AWS, GCP, Azure, all the challenges around cloud.
Um, just so those who aren’t familiar with ACG … A Cloud Guru, and that’s a relationship there. And that’s part of the, how we got to know each other is through that connection and through emceeing ServerlessConf.
[00:11:23] Um, you know, I was, I was your little, uh, you know, pad one as you were the master, um, going along. But in those conversations and, and you know, chatting with you and seeing your workout, but one of the terms that I’ve seen you use repeatedly and sort of increasingly over the last little while, um, is cloud fluency. Can you explain what that means to you?
[00:11:43] Forrest: Yeah, so I mean, fluency in cloud is the same as fluency in any other language, right? It’s a, uh, it’s not necessarily just something that you can look up some words in a dictionary and translate back and forth and figure out what they mean.
Because, you know, if I’ve never heard of an S3 bucket before, I can go Google and, and read a paragraph about what an S3 bucket is. That’s not cloud fluency, that’s just, uh, you know, cloud translation, I guess you could say.
[00:12:04] Mark:[00:12:04] Mm-hmm. [affirmative].
[00:12:05] Forrest: So for cloud fluency to, uh, have an impact, you need to have an entire organization full of people that have some baseline level of competence in the cloud.
You need them to be able to, uh, tell the, tell the appropriate story and to be able to, for example, when they’re considering a new architecture, to be able to say, well, um, you know, we need to, uh, consider, uh, let’s say we’re working in S3 and we need to consider having some lifecycle rules in place here so we don’t kill ourselves on spend.
But on the other hand, we need to think about, you know, do we need to replicate data across regions? Right? And what’s that going to look like from a redundancy standpoint?
[00:12:36] And, uh, if we have a lot of data that’s not critical and we’re replicating it, then what are we getting ourselves into there from a cost perspective? That’s a cloud fluent conversation that you’re having. And it’s why we try to encourage people to not just rely on kind of a small handful of experts within an organization who, uh, sort of you go to for all of your cloud questions and problems, because that just doesn’t scale past a certain point.
And what we see is organizations that have a kind of a, a central nucleus of cloud people, and then there’s low cloud competence across the rest of the org. Uh, those central teams get slammed with requests and problems and help desk tickets and all that kind of thing. And that really, um, it slows down the progress of the organization as a whole.
So cloud fluency to me is getting the whole organization speaking cloud, uh, and uh, on the same page.
[00:13:18] Mark: Okay. That’s really well put. Let me, let me give the, uh, the audience, maybe you’re even more succinct answer. I’m going to put up, uh, one of your latest cartoons on there and it’s your cloud translation, cloud fluency one.
And I think, um, you know, while they’re looking at that, they get an appreciation for your style. Um, which is, is fantastic and it is a very, you know, um, you know, I don’t want to say whimsical, but it’s very easy and relatable. Right?
[00:13:41] Um, so one of the things that I found interesting in your answer there, um, that I don’t think hits home for people is because people are stuck on that cloud center of expertise model. Um, right?
And cloud fluency doesn’t mean that that model doesn’t work, but it’s getting the rest of the organization up. So you don’t just go, oh, the cloud guys are going to handle it. It’s so that everybody can talk and work in this new environment.
[00:14:04] Forrest: Exactly. Right. And I have worked on, you know, central cloud teams in the past. Um, and there, there are challenges to that from not just externally with people coming to you for questions, but there’s challenges internally because you start to get this idea, if I’m on the central cloud team, that all the cloud solutions have to flow through me and I need to come up with these sort of general solutions that will work for everyone.
And particularly in large organizations, that’s just not how things work. So you have to provide enablement, uh, where you can say, okay, we’re going to have some guidelines or is, someone I was talking to recently calls them cloud non-negotiables, uh, things like, you know, we are, we are going to, um, have, you know, MFA turned on, on all of our, uh, accounts, things like that, right?
[00:14:42] Is you just have to have, and to make sure that those guidelines and guardrails get extended across the whole org, but you’re going to empower individual teams to go out and design solutions that work best for the challenges and problems that they have and not provide these sort of bottlenecks for them, not provide these, uh, situations where they have to come back to you and get approval anytime they want to do something.
And certainly not in a case where they have to use a centrally designed system that is suboptimal for what they’re trying to achieve. I’ve been in situations, I’ve been on teams that have tried to design like, you know, central CI/CD systems or central deployment orchestration stuff, right?
[00:15:16] And it just … It always, it’s not even an 80% solution. It’s like a, it’s like a 20% solution. It’s being pushed out to 80% of the people. Uh, so I, I try to push people away from that and, uh, yeah. While you have, while centralization is important in the sense that you want those guidelines and guardrails-
[00:15:31] Mark: Yeah.
[00:15:31] Forrest: I try to talk about a cloud center of enablement, right?
[00:15:34] Mark: Mm-hmm. [affirmative].
[00:15:34] Forrest: What your goal really is to reach out and help other people be the experts that you want to see.
[00:15:39] Mark: And I think there, there’s, you know, that was all excellent, but there’s two choice quotes right in there, right at the end with the, you know, the 20% solution pushed to 80% of the people.
Um, and I love the term cloud enablement center as opposed to cloud expertise, because that really hits home in that it’s not these guys do everything, right? It’s, it’s they put in the, uh, you know, that structure to help you move forward, but it’s really you moving forward.
Um, and that kind of goes to the next thing that I wanted to, to talk about. And of course, I’ve got one of your great cartoons queued up for this too. Um, which was, uh-
[00:16:12] Forrest: I’m implicit in the choice of these cartoons, this is all on you.
[00:16:14] Mark: [laughs]
[00:16:15] Forrest: I can’t actually see what you’re putting up, so I-
[00:16:17] Mark: I know, it’s even better. It’s totally blind. The good news is they’re all, I, I hope you’re familiar with them. Um, though I know you’ve been neck deep in another project which we’ll talk about in, in a minute where you may have been a, you know, forget on some of the recent work.
Um, but I cherry picked these from your last few blogs, uh, on the, uh, A Cloud Guru site. Um, so one of them is around migration. Um, so we know as much as it would be great to work for a company, um, you know, and some of us like yourself have the opportunity to do that. Um, that was completely born in the cloud and just built from day one and sort of where you want to go.
[00:16:48] Um, but, uh, most of the reality is organizations have a ton of stuff somewhere that is working and the business is moving along and they are migrating into the path. So you had a post. Um, and I’ll pull it up now and again, you’re blind to this.
So just give Forrest a break everybody. He is absolutely blind to this one, but it’s the four squares of cloud migration healthy, uh, is your cloud migration healthy? Right? So the dead tree pruning, the asteroid farm, the donut hole and the Petri dish. Um, in general, so this is just a good visual for the folks at home.
Um, but in general, uh, what do you see for migrations? ‘Cause I know you have a long history help, in helping org start those steps and continuing all the way through that process. What’s, what’s your view on it?
[00:17:29] Forrest: Yeah, I do. And look, it’s, it’s, a lot of it is about the organization size and the maturity level. Uh, depending on what size they are. I’ve worked with startups, I’ve worked with Fortune 50 type size companies and everything in between.
A lot of companies that are kind of in that, uh, that range where they have maybe 20 to 30 product teams, products that are, that are in the cloud. And a lot of times they do have those central cloud teams that are trying to help the product team scale up and, and be able to lift and shift or whatever the term of choices, get those products functioning in the cloud in some way just so they can declare some amount of victory, some amount of success.
[00:18:06] And the pattern that I see there most commonly is, well, we’re going to “Lift and shift.” This is the, um, the dead tree pattern that you see on that, uh, uh, visual if it’s still up there. Uh, we’re, we’re going to lift and shift and we’re going to pick up our applications without changing a lot about them.
We’re going to put them in the cloud and that’s just step one. No one intends for it to stop there. Uh, but we’re going to get some value there.
[00:18:29] Mark: [laughs]
[00:18:29] Forrest: We’re going to have a, a measurable improvement, right? And then later on we’ll figure out once we get in the cloud how to re-architect things and that, that absolutely can be, um, a valid point at the time that you’re, that you’re doing that.
But where people make a mistake is they say we are guaranteed even if we never take the next step to get longterm value out of just lifting and shifting and putting our applications in the cloud. And I have another post called the lift-and-shift shot clock. Where I talk about that, once you move those applications to the cloud, you have started kind of a clock on your chance for success because you immediately start to get diminishing returns.
[00:19:03] Um, as you’re placing those applications in the cloud and you’re not changing the way they’re architected, you’re not changing the way they’re built to take advantage of cloud services or take advantage of the cost model in the cloud, you’re going to start to see those initial wins that you got by moving out of your data center decrease. Um, as the disadvantages, the negative side effects start to accumulate of that lift and shift. I’ve seen-
[00:19:22] Mark: I’ve that one up for you on the, on the screen right now. I’ve got the chart for you, so people know what you’re talking about.
[00:19:27] Forrest: Okay, perfect. Yeah, yeah, yeah. So, and I definitely recommend going through, uh, some of the, some of the, the charts and things in that posts. But, uh, you’re, you’re thinking about, you know, uh, not only are you looking at, uh, not getting the costs that you are,
[00:19:40] the costs, um, uh, increases the cost winds that you thought you were going to get, you’re actually gonna start getting some brain drain as the folks who did have that had cloud expertise start to say, well, this is not what I expected and they start to move on. Uh, and then you, you’ve kind of created a new set of legacy practices for yourself.
[00:19:54] So you never really had an improvement, you just created a new set of problems as you worked around the, um, cloud best practices that you’ve sort of thought at some point in the future you’d have the chance to create. So that’s, that’s the track that I see a lot of people fall into. And what we ask people to do is, uh, immediately have a plan for how you’re going to go cloud native and how you’re going to take fullest advantage of cloud.
[00:20:14] Mark: So let’s just pause there for two seconds, ‘cause I think that last little bit on the shot clock was really, really interesting with, um, you know, and on, on that, uh, diagram, on that graph you’ve got drawn up is basically, you know, to a year and a half to two years in, you start to see that brain drain.
Does that in your experience relate back to people who think center of expertise versus center of enablement? Because the people in the center of expertise are essentially answering the same questions over and over and over again from people and because they haven’t raised the cloud fluency?
[00:20:45] Forrest: I think to some extent, yeah. And that year and a half to two years that, that is, uh, it’s a rule of thumb based on what I’ve seen at a lot of places.
[00:20:50] Mark: Yeah.
[00:20:50] Forrest: But obviously you’re [inaudible 00:20:52], right? And there’s a lot of, I’m not trying to say a year and a half to two years is the, uh, it could be a lot, it could be a lot sooner than that, right? You could have less runway in a lot of places. So I’m not saying you’ve got that much time. I’m not saying you only have that much time.
[00:21:02] Mark: Sure.
[00:21:02] Forrest: But, uh, yeah. So, so why, why do people get frustrated? Why do you have the brain drain? Because people go to the cloud thinking that they’re going to use the cloud to the best of its ability, right?
That’s why we, uh, if we’re serious cloud professionals, we’re technologists who, uh, are excited about these moves, it’s because we think they’re going to actually provide some value for us. So people get disillusioned and that’s one reason that they leave.
[00:21:22] But then another reason is if you bring people to the cloud and you don’t have the underlying, um, training and certification and enablement that enables them to take advantage of that, they’re, they’re going to say, “Well, you know, I liked it better in the data center because at least there I had more control and I knew how things worked. Here, everything’s new and frustrating to me, and the pace is faster, but I haven’t had time to learn, so I’m going to go somewhere that will help me learn.”
[00:21:44] Mark: Okay.
[00:21:44] Forrest: Um, and yeah, that’s, that’s, uh, unfortunately what we see.
[00:21:48] Mark: Yeah. So we had, we had a question on LinkedIn, uh, from Mazen AbuAbed, uh, who was asking about, uh, you know, on this topic on migration, um, we’re seeing a huge uptick, uh, in migrations in the speed of those migrations. Um, are people making these mistakes faster? Uh, are they, you know, is … So we talked about, you know, you may have that sort of up to two years on that lift and shift.
[00:22:12] Forrest: Yeah.
[00:22:12] Mark: Um, and we know that people, you know, go, okay, we just got what we have, we’re just going to shove it into the, into the cloud. Um, and you mentioned, you know, you, you strongly encourage people to have that cloud, that plan to switch that existing infrastructure into a cloud native one. Um, but in my experience, I know that’s a really, really hard step for people to take, um, because it requires a completely different way of thinking.
[00:22:34] Forrest: Right. And that’s why it can’t always be step one. So I’m not trying to say lift and shift is something that you shouldn’t do, right?
[00:22:39] Mark: Mm-hmm [affirmative].
[00:22:39] Forrest: Because there absolutely are a bunch of reasons and I think I have a bunch of them listed in that post.
[00:22:43] Mark: Yep.
[00:22:43] Forrest: Why lift and shift makes sense up front. I mean, it could be the case that you need to sort of do some financial engineering to go from a CapEx model to an OpEx model and actually show financing what you’re spending on cloud and why you need to re-architect and consolidate around things.
You may need to have an engineering team that just gets their feet wet and uh, make some of those mistakes you were just talking about. Okay? Making mistakes is not necessarily a bad thing. I mean we all, we have to do it. That’s how we learn, right?
[00:23:05] One of the amazing things about the cloud is that it provides us a way to fail really quickly, uh, and uh, you know, get that feedback in real time and make changes very quickly. Um, and the, the quicker you’re able to go to a cloud native model, the faster you’ll be able to fail, the faster you’ll be able to respond to feedback and you’ll be able to re-architect. Uh, I come from the, the serverless world as you know, where, uh, it’s quite possible not just to AB test things, but to ABCDEFG test features.
[00:23:30] Mark: Yep.
[00:23:30] Forrest: Because the infrastructure itself is so cheap and the time to spend things up, the time to value is so short. That’s where you want to go. That’s the end of that road. So yeah. So you don’t want to get stuck on step one, even though step one certainly can be necessary.
[00:23:43] Mark: Yeah. And it’s interesting ‘cause I think one of the things that’s implied in what you just said, that the audience, you know, needs to explicitly understand is that, um, you need to have your teams ready to fail and learn from that failure and experiment because a lot of them are, you know, especially from an operations perspective, especially from a security perspective, the sort of default assumption is that failure is unacceptable.
Um, when it’s really should be, you know, failure is acceptable when you’re expecting it and anticipating it and react to it.
[00:24:12] Forrest: Yeah, that’s exactly right. And that’s why you hear a lot of IT teams, unfortunately, and this goes back decades now, where you’ll ask them what their primary responsibility is and they’ll say what? We keep the lights on.
[00:24:22] Mark: Yeah.
[00:24:22] Forrest: That’s, uh, that’s their charter is keeping the lights on. Um, and there’s two problems with that. Number one, because obviously it, you know, it implies that there is no world in which it’s acceptable for the lights to go off. Right?
[00:24:33] Mark: Mm-hmm [affirmative].
[00:24:33] Forrest: And number two, the problem is if all I’m doing is keeping the lights on, that means I’m not learning anything new. I’m not changing anything, I’m not improving anything. I’m just sort of on this treadmill of maintaining the status quo, uh, and getting trapped deeper and deeper into legacy technologies and legacy processes and ways of thinking.
And that’s again why you have to make a, a deliberate step at the organizational level to say we’re not just going to pick our things up that we had in the data center or on premises and we’re going to run them in the cloud, kind of the same way we were doing. Because then you have a team keeping the lights on in the cloud and doing manual things instead of automating.
Right? And just responding to every fire and putting it out as it goes on. Firefighting is the, the constant, um, rule of the day. And instead of that actually having a team that is trained and enabled to, um, as they’re continuing to contend with daily tasks, right? Be able to actually make some substantial steps forward.
[00:25:23] Mark: Yeah. ‘Cause in that, in that model that you’ve just described, you know, you’re essentially just moving the firefighting from traditional environments to a cloud environment, which is still the same problem.
But for me, it’s almost even worse because now you’re sitting in this environment where it’s not a requirement and you’re still doing the same fire-fighting over and over again when you’re surrounded by fire extinguishers and fire hoses and a whole bunch of fireproof stuff. And you’re like, yeah, we’re still gonna firefight. Right?
[00:25:48] Forrest: Exactly.
[00:25:48] Mark: So I want to, I want to ask you something that a mutual friend of ours has non-stop, uh, you know, uh, narked about online. Uh, of course, Corey Quinn from the Duckbill Group, uh, has a very valid point. And, you know, as much as I love GCP, as much as it’s a solid cloud provider, they do have a habit of deprecating things.
[00:26:08] Um, and he in fact fired out a tweet, uh, the other day, which was hilarious because it tied to the untitled Goose Game, which I think is brilliant on Nintendo Switch where you’re just the obstinate goose that grabs things and honks at people. Um, but it was somebody who had put the goose from the goose game on the Google logo and said, deprecate things on purpose.
Uh, yeah. So, you know, obviously standard Corey, like let’s just stir the pot a little bit. But how does that relate to um, organizations that are migrating, that are trying to take that trust step of going like, okay, we’re going to move this stuff into the cloud, but then they see stuff like this where you go like, oh, but that service may go away.
How does that tie to migration and that failure and sort of innovation cycle from your perspective?
[00:26:51] Forrest: Right. So lock in, the vendor lock in question as it relates to my creation.
[00:26:55] Mark: Yeah.
[00:26:55] Forrest: There’s basically four big reasons that people get concerned about vendor lock in, at least as far as I’ve been able to tell. And I’ve had a lot of these conversations with folks. The first reason, which is the most challenging is I have external constraints that are requiring me to think about this.
And that could be, I have a regulatory problem, right? Where I’m not able to, uh, put things on cloud services because my regulator says you have to be multi-cloud or cloud agnostic or whatever. That’s not even an engineering decision at that point. It’s just something that I have to work with my regulator on.
Um, the technical concerns are a little bit easier to deal with. And those are concerns about, well what happens if, as you just said, my cloud provider deprecates a service I rely on?
[00:27:32] More drastically, what if the entire cloud provider somehow vanishes, goes up in smoke, right? Goes out of business, um, hasn’t really happened yet. But then again, I mean, it’s happened in history that tech have gone belly up.
And then, uh, you know, most commonly what happens if the cloud provider gets me in and I build on that cloud native service and then they raise prices or they deprecate some feature or basically they, they get me in a situation where I’m in their walled garden and I have no place to go and I’m just at their mercy. They can do whatever they want.
[00:28:00] And that’s I think the easiest one to address from a technical perspective because realistically the cloud providers have not done that in terms of raising prices. Um, at this point I think it would be suicide to do it because the competition is so strong and the backlash would be so fierce and they know that and that’s why we haven’t seen it.
I mean, heck, what did Google do just recently where they, um, they added a charge for, uh, the control plane of their, uh, GKE clusters and [inaudible 00:28:24].
[00:28:24] Mark: Yes, yes.
[00:28:25] Forrest: And just fire and brimstone rained on them from every corner. It’s unbelievable.
[00:28:29] Mark: ‘Cause that was not just a like, hey, you’re going from 10 cents an hour to 15 cents an hour. That was a significant, like up until now we’ve made, we’ve encouraged you to make a cluster for anyone and everyone who wants one and now we’re going to charge you for everything after the first. Like that was a huge move.
[00:28:46] Forrest: Big deal. Big deal. And I guarantee you, you know, every, um, meeting that happens inside of a cloud provider now, where they’re thinking about their, their pricing strategy, they’re, they’re going to point to that GKE fiasco and say, well we don’t want to do that. Right?
[00:28:58] Mark: Which is a win for us as users. Right? Like, that’s, that’s a solid thing.
[00:29:02] Forrest: Yeah, of course it is. And I think that the market forces are aligned in the consumer’s favor there. And what we’re seeing is another mutual friend of ours, Simon Wardley likes to talk a lot about the commoditization-
[00:29:12] Mark: Yes.
[00:29:12] Forrest: …Of cloud compute, right? And that sort of thing. So, so you’re going to see this get cheaper. You’re going to see it get easier to access. You’re not going to see, uh, this bulkanization where people get locked up and not able to do things that they want to do.
Um, and, but there’s a, there’s a flip side of this whole conversation too because I think we can get way too tied up in the walk in conversation. Again, if you’ve got regulatory concerns or you’ve got this weird stuff where like, um, I don’t know, you’re in the Microsoft ecosystem and they don’t want you to use any partners that are running on Amazon products or you know, weird stuff like that. That’s, that’s another weird conversation.
[00:29:40] But if you’re strictly trying to evaluate it from a technical perspective and make the smart decision, which engineers like to do, we like to look at things from all sides and you know, we, we, we want to feel like we are making a decision we won’t regret.
[00:29:52] Mark: Yeah.
[00:29:53] Forrest: Um, I, I … You have to look at it from the perspective of risk. What is your risk, uh, of, you know, building on a managed service that is taking away a lot of upfront effort for you versus the, you know, low risk down the line that they’re going to, uh, deprecate something versus the risk of, you know, staying in your, uh, data center or building something, um, and having a slower time to market and is having something that’s potentially more expensive for you to run, not just in terms of raw costs, but in terms of your maintenance time and your R&D time on the front end.
And, uh, all of the, you know, engineering hours and, and really hours taken away from building other things. It could be more directly beneficial to your business.
[00:30:29] Uh, so once you start talking about that with people, then I think, uh, folks start to get it a little more on, oh, there’s, there’s a huge value prop being handed to me here with the cloud. And, uh, if I get fixated on, you know, what is every little minuscule thing that could happen. Um, it just, it’s, it’s not a, we’re, we’re very bad at judging risk as humans.
[00:30:46] Mark: [laughs]
[00:30:46] Forrest: And I think vendor lock-in has taken, loomed in an outside for, in some people’s minds.
[00:30:51] Mark: Oh, we’re horrible at, uh, at risk decisions. Actually, I just submitted a talk to an online conference exactly about that from the security perspective of going, you know, humans are the worst risk deciders on the planet. Um, but, uh, the interesting thing is, and this kind of ties into the next topic I wanted to tackle, um, which is Brazeal’s corollary, which is now a thing. Um, congratulations. Um, the, uh, around, um, CI/CD pipelines and data.
[00:31:17] For me, those are the two biggest things when it comes to lock-in that I evaluate or tell organizations. ‘Cause if you’re doing everything else in a cloud native way, if you’ve automated everything, you know, in a serverless design, it’s even easier. Like here’s my compute and it links through these APIs to these other services and I can always switch those out relatively straight forward.
Um, you know, with a little bit of engineering investment. But for me it’s like where’s your data sitting and where’s your, your build pipeline? Um, you know, because those are the two things that are sort of customized to you and have the biggest pain in the, you know, what to move somewhere else.
[00:31:49] And that ties in, you know, to that migration discussion. But really to that lock-in, you know, and I think lock-ins really legacy ‘cause it always surprises me when people are like, “Oh, you know, we’re really worried about lock-in into storage vendor X.” And they never look at the fact that all their data’s locked into Microsoft office document formats.
And you go, well that’s that, that second thing that the data format is far more important than where the data is, because at the end of the day you can copy the data somewhere else, but to transcribe it in a different format is a huge amount of, uh, lifting. Right?
[00:32:18] Um, so you did this post, uh, on CI/CD pipeline. Uh, of course I have your cartoon for that pu- pulled up in a second as well. Um, but can you run us through, uh, what your, your, your sort of epiphany was, uh, on CIDC pipelines as they relate to the orgs?
[00:32:34] Forrest: Uh, yeah. And so just real quick too before I address that, to touch on your point about data gravity, and, and things like that. I mean, you know, people have concerns about things like data egress charges being so expensive getting out of the cloud provider too, right?
[00:32:45] Mark: Yeah.
[00:32:45] Forrest: So, that’s, that’s a valid point. It’s not necessarily just about file formats and things like that, but I think you make a great point that everyone’s locked in on, you know, on technology choices you made. I talk about this a lot, uh, in, in the realm of IAM, which is a, you know, tremendous form of lock-in if you’re building on a cloud provider, taking advantage of their authentication. But 15 years ago, everyone made the choice to lock-in on Microsoft active directory. Right?
[00:33:08] Mark: Yeah.
[00:33:08] Forrest: Uh, you know, and I mean, that’s an incredibly hard decision to move away from. Uh, but no one really regrets having made that decision 15 years ago. You know, what else were you going to do? Were you going to take LDAP and build your own … I’ve actually heard from people who’ve done this and it’s not like their real happy about it. You know.
[00:33:24] Mark: I was waiting for someone to go, I built on Novell, to have to go, oh my God.
[00:33:27] Forrest: Yeah. Yeah. Especially like university seems to be really, uh-
[00:33:31] Mark: How’s that working out for you now, is the question, right?
[00:33:33] Forrest: Yeah, yeah. So look, it just, because something is a standard and it’s well supported and there’s a lot of people out there in the industry who know how to build it, uh, that’s a good indication that it’s something you should be locking in on-
[00:33:43] Mark: Yeah.
[00:33:43] Forrest: Because you’re actually providing yourself with a lot of security. I mean, hey, the word locks, you know, it has a, has a, a security and safety aspect to it as well. Right?
[00:33:49] Mark: Of course.
[00:33:49] Forrest: There is nothing, there is nothing worse to be locked in on than a bespoke solution that you’re the only one who understands how it works and you’re responsible for maintaining it. Right?
[00:33:57] Mark: There is a pile of Dilbert cartoons to support that premise as well.
[00:34:02] Forrest: I have a pile of them sitting on my shelf over here actually.
[00:34:05] Mark: [laughs]
[00:34:05] Forrest: But yeah, so, uh, anyway, but back to your question about, about CI/CD. Uh, I built a lot of CI/CD systems for a lot of different people, um, both in house and as a consultant. And what I’ve learned over the years is CI/CD is notoriously hard to generalize and that’s because it is about, as I say, the Conway’s law-iest thing you can build. For anyone who doesn’t know, Conway’s law is the, the famous, uh, statement that says architectures tend to grow to look like the organization that they’re part of. Right?
[00:34:38] Mark: Yeah.
[00:34:38] Forrest: And CI/CD pipelines are really bad offenders in that regard because you really are expressing the contours of your engineering organization itself as you’re building out that pipeline, because you’re putting in things like approval gates. Who is it who is going to have to, uh, make a decision about when this code can move from development to production?
Who’s going to have access to move it from development to production? Um, who’s going to, you know, actually be packaging up the artifacts and who’s going to be, for example, running smoke tests on stuff after it’s deployed? All of those decisions that get chained into your pipeline are decisions that happen about how your engineering organization is put together.
[00:35:14] And so a lot of times you can look at an engineering pipe or a CI/CD pipeline and you can say, well, I know how that org is structured. And so I’m assuming the graphic you have on the screen there now-
[00:35:22] Mark: Yes.
[00:35:22] Forrest: …Is kind of showing, and that’s that, it’s a little bit hokey, right? I mean it’s, that’s not especially formal, it’s a little bit anecdotal.
[00:35:28] Mark: It’s hokey but it’s pretty eerily accurate.
[00:35:32] Forrest: Uh, yeah, the, the one that I’ve had a lot of feedback on, that people say, oh yeah, that’s what my organization is, is the one that I call a blob. Uh, and the, the reason the blob is so, um, I guess dangerous is because people deliberately create the blob thinking they’re doing something that’s best practice.
They think I’m going to have a centralized cloud team, we’ve already talked about this a lot and I’m going to create a central CICB infrastructure and this will solve the problem I see, which is everyone going off on their own and building and not having CI/CD or building their own thing. That’s, that’s really um, uh, concerning on a security level and it doesn’t have all of the gates that we want it to have.
[00:36:07] Mark: Mm-hmm.
[00:36:08] Forrest: And so we try to centralize this and unfortunately, you know, what happens is, uh, there … Let’s say you have 15 or 20 different product development teams that you’re trying to work with, it’s going to work fine for five of them, like the five that you prototyped it with, who gave you their feedback. And then you’re going to have teams who they’re using languages and tools that aren’t well supported by what you’re doing.
[00:36:26] Mark: Mm-hmm.
[00:36:26] Forrest: They perhaps had their own processes that were working pretty well that they’re not really interested in giving up.
[00:36:31] Mark: Yeah.
[00:36:31] Forrest: You haven’t built strong relationships with them, so you’re not necessarily, um, you know, just going to convince them by sending out a memo and saying, you need to be using this system now.
And so what happens is that they either they, they give kind of a bad faith effort at integrating with you and then they go off on their own to do this shadow IT thing behind the scenes and that ends up creating more problems than, than we, uh, had initially.
[00:36:50] So w- where I try to push people toward, and again this goes right back to that concept of cloud fluency and cloud enablement is come up with what your non-negotiables are and I don’t necessarily care what tooling you’re using as long as you are meeting the security guidelines that we have and you are making sure that you have, you know, code coverage or whatever we’ve decided is the standard for your organization to get code to a production level, right?
You have code review. I don’t care what your source control platform is necessarily, unless we’re Google and we have a giant monitor repo with every line of code and the entire company in lace. Um, but …
[00:37:20] Mark: I still don’t understand how that works, but yes.
[00:37:23] Forrest: If you’re not Google I don’t think you need to worry about understanding of why that would be a choice you might want to make, but uh, yeah. Anyway, so let, let them choose the processes and tools that work best for them to move fast, provide the centralized enablement and guidance for them to build those tools in the context of what the organization needs and then just let them go and let them take pride in what they built and push that cloud and dev ops competence onto the teams where it belongs.
That’s what dev ops has been about, right?
[00:37:46] Mark: Yeah.
[00:37:46] Forrest: For 10 plus years though, is … And embedding that expertise.
[00:37:50] Mark: And so, and I 100% agree with you. And what I thought really interesting on this graphic just before I pull it down, was the gumbo version, um, where everyone builds their own little thing. Because what I’ve seen from that, and I’ve seen all these models and which is why I said, you know, this is eerily accurate.
What I find really interesting is the war that happens after the gumbo phase, when everyone’s built their own thing and somebody sweeps along and says, okay, now we’re going to do a more centralized blob or we’re going to do the umbrella. We’re going to do something else, because we’ve got a thousand different pipelines now.
And then you get this total fight of like, my pipeline’s better because it’s blue and they’re like, mine’s better ‘cause it’s orange. And you’re like, ooh, but it’s a, it just ends up being a Holy war. It’s like Vim versus Emacs or tabs versus spaces.
[00:38:34] Forrest: I mean in fairness, that’s just engineers.
[00:38:36] Mark: Yeah.
[00:38:36] Forrest: You know, we weren’t … That [inaudible 00:38:38] was something else though.
[00:38:39] Mark: We would, which is why we fight about tabs and spaces and which editor is best. And …
[00:38:43] Forrest: That’s right. That’s right.
[00:38:44] Mark: But yeah, I thought that was really interesting ‘cause I know that road, that parallel is a lot of the work I’ve been doing, uh, looking at security, um, and within organizations and how, um, not the build pipeline, but in this case the HR structure of security dictates the activities that that team takes on because of the organizational challenges.
And we just saw a comment on YouTube from Clint, yes, people still use spaces Clint, it’s a thing. It’s 100% of a thing, man. Um, but, uh, the um, you know, we see that and I think that’s an area of, because the tech side for engineers is so much easier or clearer, is probably a better word, right?
[00:39:20] I can give you an answer as to whether something will work or not either off the top of my head or with some testing, like it works or it doesn’t. Whereas the people side, the soft side, its constant negotiation, explanation.
The staff changes out, you know, you’ve got a whole new team to bring on board. It’s just this constant turn that a lot of us aren’t comfortable with, but it has such a disproportionately high impact on what we do that it’s amazing to me that people just kind of blinders on it.
[00:39:49] Forrest: It really is amazing. And I was having a Twitter conversation about this with some extremely smart people yesterday who were looking at the CI/CD article and saying, well, I mean the technology side of this is not so bad, right?
[00:39:59] Mark:Mm-hmm [affirmative].
[00:40:00] Forrest: Like we can make something that works for scarcity.
[00:40:02] Mark: Yeah.
[00:40:02] Forrest: And, and of course you can, you know, because the technology here is not the hard part. The hard part is convincing the organization to go along with you building something that works for people with disparate goals and disparate skill levels. And again, that brings us back to comprehensive fluency, right?
[00:40:15] Mark: Yep.
[00:40:15] Forrest: And having a shared baseline of understanding for what we’re doing and how we’re building it and why.
[00:40:21] Mark: I see what you did there.
[00:40:23] Forrest: Yeah, full circle.
[00:40:24] Mark: Full circle, very impressive. But I mean that’s, that’s an absolute key point. And I think, you know, that’s a number one takeaway for people listening to this is that the cloud fluency is key to cloud success. If you, if you don’t have fluency, you may have short term success, but you definitely won’t have sustainable success. Right?
[00:40:40] Forrest: Yeah. That’s right. And can we talk about success for a minute? ‘Cause I want to talk-
[00:40:44] Mark: A hundred percent man. We can talk about whatever you want. Success, hit us. Let’s go.
[00:40:47] Forrest: Yeah. So I want to talk about this just for a minute because I think what I see, and I see this even a lot now that I’ve come to A cloud Guru talking to customers, people who are, are doing a lot of things in the cloud or they want to be doing a lot of things in the cloud, but it’s almost like going to cloud itself is the success criteria and you know, long term, that’s never the case.
So thinking about what, how do we know if we’ve succeeded in the cloud? What would, uh, what would validate what we’re doing as a, you know, reasonable use of all of this time and, uh, human resources and everything else that we’re pouring into this? Um, and, and ultimately it’s about, you know, value for your customers downstream, right?
[00:41:24] Mark: Mm-hmm [affirmative].
[00:41:24] Forrest: I mean, that’s [inaudible 00:41:25] things like, you know, the success of your company fiscally, obviously, but it’s reflected in the satisfaction of your customers and the growth of your business and, and all that sort of thing.
And the, the question of how you get there. Um, I, I had a, a post come out that I worked on with some other folks at A Cloud Guru a couple of weeks ago called how many, how well, how much measuring cloud success and have seen a lot of really good feedback to this rubric. And so I want to share it with this group here.
[00:41:48] Mark: Yeah.
[00:41:48] Forrest: And that is, yeah, as, as you’re thinking about how do I measure my cloud success, how do I know if I’m headed in the right direction? Um, there, there’s three kind of pillars that you can look at. And the first one is how many, how many workloads am I moving to the cloud?
So thinking about what’s still in the data center, what have I moved out and really what is the consequence of what I’ve moved out. So I can pick up a lot of peripheral things and I can put them in the cloud. This is the, um, the asteroid pattern. If you remember the diagram we showed, the asteroid farm, right?
Where I’m, I’ve got all these little auxiliary workloads, but I haven’t touched the big stuff. I haven’t touched the big Oracle database. I haven’t touched the, the monolith that’s actually running my business. That’s all staying on premise.
[00:42:27] So how many workloads and what’s the quality of the workloads that I’m actually moving to the cloud? Am I able to say things like, yeah, we’re closing a data center or yeah, we moved X amount of petabytes of data, you know, the things that are just really measurable wins that will allow us to know if we even are getting value out of the cloud because we’re putting valuable things there, right?
[00:42:42] Mark: Mm-hmm [affirmative].
[00:42:43] Forrest: And so that’s how many, how, how much or how well is how well architected are the things that I’m putting in the cloud. And this is where you get from that lift-and-shift standpoint over to the more cloud native side. Uh, am I using something like the well architected framework, which I do believe Mark, that you have a course on, is that correct?
[00:42:56] Mark: That is correct, yes.
[00:42:57] Forrest: Yes.
[00:42:58] Mark: It’s one of my favorites. And even though it’s called the AWS full architecture framework, it’s just principles for building well in any cloud.
[00:43:05] Forrest: Right, and these are pillars like performance, reliability, cost optimizations, security, right?
[00:43:10] Mark: Yeah.
[00:43:10] Forrest: Just really basic ‘cause I think all the cloud providers have rubrics that will help you evaluate yourself against their best practices in these areas, right? So it’s not like it’s some, you know, arcane alchemy to figure this out. It’s, you can … It’s amazing how many of these things are kind of common sense.
And it’s also amazing how many of them you typically won’t be doing until you actually sit down and formally go through the process.
[00:43:30] I’ve done those well architected reviews for a lot of people and it’s always valuable. So I highly recommend doing that. Find a consulting partner if you need, uh, and go through it. Um, and so that’s how well, and then, uh, how, how much is, is how much am I spending? How am I doing with cost optimization?
How am I doing with governance? You know, am I getting the most value out of the … ‘Cause I mean, spend in itself isn’t necessarily an interesting metric, right? I mean, just because you’re spending more on IT in the cloud isn’t always a bad thing.
[00:43:55] Mark: Mm-hmm.
[00:43:55] Forrest: It could just mean that you’re getting a ton more value and your business has grown.
[00:43:58] Mark: Yeah.
[00:43:58] Forrest: Right. And what do you want to bet that zoom is spending more money in the cloud this month than they ever have in their lives? You know, uh, and it’s a good month for zoom, right?
[00:44:05] Mark: Yeah.
[00:44:06] Forrest: So just spend is not like a, it’s not a indicator of how successful or, or failing you are, but you need to figure out how much of that money, how much of that spend is going toward value for you and for your customers. And having good governance and tagging and all that good stuff is how you get there.
So how many, how well, how much, and then underlying all those three is, is the people that the, how to how, if you will of, um, you know, you can’t evaluate any of the things effectively unless you have people on board who understand what to look for, uh, and can have conversations at the level of sophistication that you want, which is another word for cloud fluency.
[00:44:36] Mark: Yeah. And I think, you know, I’ll, I’ll add that, uh, post in the show notes for sure so everyone can, can get to it. Um, and uh, we’ll put the general link for the show in all our … on Twitter, on YouTube and on LinkedIn so everyone can go and we find it much easier to push out one length than a bunch.
Um, uh, but one of the big keys there I think was that, you know, starting with the how much, ‘cause I hear that all the time from executives. Is like, we’re going to save money. And I’m like, no, no, you’re not. You’re going to get more value. But I’ve never seen anybody’s bill go down substantially for a long time by migrating into the cloud. Right?
[00:45:08] But they do get way more value if they do it right. And you know, zoom was a great example. Same with Slack. So, uh, yesterday or on the weekend, um, uh, Stuart from Slack, the CEO had said like, “Hey, our normal signups are like 5,000, uh, and we’re up to like seven to 9,000 already for paying customers.” So like their cloud bill is going up huge, but they’re also seeing a massive influx of revenue in paying customers.
If you’re just looking at that one metric, you’re not seeing the other, right? You’re not seeing that ratio of how’s our cloud spend versus our income. Um, and how effectively are we doing this? And you know, I think that’s really, really key. And I like that. So how, how many, how much and what was the last one?
[00:45:45] Forrest: How well.
[00:45:45] Mark: How well, okay, perfect. I should have remembered that one given I did the course, but still.
[00:45:50] Forrest: [inaudible 00:45:50] maybe there much.
[00:45:51] Mark: [laughs] So there is one thing we did in season one of the show that I like to do with guests, it’s not bad. It is a surprise always though. I like to do a little rapid fire questions, so I just want you to pick one or the other and then we’ll circle back and explain a couple of things and if you need to skip, we can skip, but there may be one you want to skip, but we’ll see. Gonna put you on the spot a bit if that’s okay with you, Forrest.
[00:46:13] Forrest: Uh, all right.
[00:46:15] Mark: You’re like, ah, I’m having Skype connection issues. I may not be able to continue with the stream.
[00:46:19] Forrest: Yep.
[00:46:19] Mark: Okay. So breaking up.
[00:46:20] Forrest: Yeah.
[00:46:21] Mark: Exactly. I’m going through a tunnel right now and can’t get the signal. Um, so, uh, you recently spearheaded, uh, cloud madness for A Cloud Guru.
[00:46:30] Forrest: Yes.
[00:46:30] Mark: Um, at the end it came down to, so this was after the basketball tournament style cloud services, which was cloud service. The final round came down to S3 or Lambda.
Uh, what was your choice? Your personal choice between S3 or Lambda, which is the greatest cloud service of all time? Single answer, S3 or Lambda?
[00:46:48] Forrest: Yeah. Yeah. Uh, so, and, and first thanks Mark for all of your help with that much, I released this bracket early on and, uh, had thought through it way more, I think even than I had, that’s pretty amazing. I thought I’ve thought about it a lot.
Uh, he had like conferences and all the schools going on. Um, yeah, yeah. So, uh, look, at first I, I had thought Lambda because I’m a serverless fan of longstanding and you know, who doesn’t love that changed a lot of our world’s, changed a lot of our careers, changed the way we build and design and, and really the frontiers of what was possible in the cloud.
[00:47:16] Mark: Yeah.
[00:47:16] Forrest: Um, but as we got, I think toward the elite eight round, I started thinking more about the services that were left. I started realizing it’s awfully hard to beat S3.
[00:47:23] Mark: Mm-hmm.
[00:47:24] Forrest: You’re talking of a service that is kind of the OG cloud service.
[00:47:28] Mark: Yeah.
[00:47:29] Forrest: It’s enabled much of what’s going on. And I, I went and talked to Tim Wagner, the inventor of Lambda about it, and he helped me understand that Lambda was actually created as an offshoot of S3. It was created as a way to process S3 triggers.
That’s, um, the initial, uh, business plan for Lambda, that’s, that’s how it was pitched.
[00:47:43] Mark: Yep.
[00:47:43] Forrest: And he told me that’s one of the scariest days of his career, um, was actually … Oh, did I lose you Mark? [inaudible 00:47:50].
[00:47:50] Mark: Yeah, I know. I’m switching on, my camera overheated apparently. So I’m switching sides.
[00:47:54] Forrest: All right. All good. So, yeah, so what Tim told me was, uh, one of the scariest days of his career was the day that they connected S3 to Lambda, uh, to, for Lambda to consume S3.
[00:48:05] Mark: Yep.
[00:48:05] Forrest: He said at that time it was like being a fire hose to a dixie cup.
[00:48:08] Mark: [laughs]
[00:48:08] Forrest: And thankfully [inaudible 00:48:10] has grown up and has, has gone to places that perhaps even Tim never dreamed of, although he’s a pretty perceived guy. Uh, so look, as great as Lambda is, S3 made it all possible. I think it was exactly the right choice for, for it to win cloud madness, I feel pretty good about that.
[00:48:21] Mark: Okay. Okay. That’s fair. That’s fair. Um, so next one then. What’s harder, uh, convincing an org to go serverless or writing a book?
[00:48:35] Forrest: It would depend on the org.
[00:48:36] Mark: Okay.
[00:48:36] Forrest: Um, but I would say writing a book is easier.
[00:48:40] Mark: Okay. And I say that only because I don’t think Forrest would do this, so I will pump it for him. He has a book coming out in the fall, you can see the, um, details, uh, onscreen right now. Uh, the Read Aloud Cloud, uh, you’ve seen some of his cartoons in this stream, uh, you can pre-order it now on Amazon.
This is in the show notes. Ah, trust me, fantastic. Well worth your money. Put the pre-orders in now, help Forrest out because this is a huge contribution to the community and an insane amount of work. Um, which is why I find your answer surprising, um, because I think convincing people, at least they have to do the work for the cloud. For the book, you did all the work, man.
[00:49:16] Forrest: Well, yeah, look, it’s, it’s always a lot of work to do a book, but the reason I say that is, um, as much work as it is to do a book, it’s a technical problem. Meaning it’s something that I can solve myself, sitting at my computer.
Going serverless is an organizational problem, it means getting a whole bunch of people to row in the same direction and that’s always going to be a bigger challenge.
[00:49:31] Mark: Are you using my own stuff against me now?
[00:49:34] Forrest: Uh, maybe.
[00:49:35] Mark: Oh man. Okay. Uh, all right. Next one. And this one, uh, I will remind you not to bias your answer, but you’re an AWS Serverless Hero. Uh, containers, are they stopping devs from going serverless or are they a legitimate solution on their own?
[00:49:49] Forrest: Wow. Well, that’s a loaded question Mark.
[00:49:51] Mark: It is.
[00:49:51] Forrest: What in the world.
[00:49:52] Mark: [laughs]
[00:49:54] Forrest: Uh, look, containers are, uh, an interesting case because they have come up so fast, uh, and have solved, um, a problem that a lot of people have been struggling with for a long time, which is how do I take application artifacts and package them up and make them widely available?
Uh, the, the challenge that you’re seeing with containers is they are essentially perpetuating and refining an existing paradigm of how to deliver software, whereas serverless is inventing a new paradigm of how to deliver software.
[00:50:23] Personally, as you said, I’m a AWS Hero, I believe that the serverless model points the way to a future that is more sustainable longterm. Um, you’re, you’re looking at, uh, a future that’s built primarily on, um, consuming services that are built and, uh, only that are, uh, that are bought and only building things that are providing direct value to you.
[00:50:42] Mark: Yeah.
[00:50:42] Forrest: Whereas I think in some ways container backed architectures can, um, encourage you to spend a lot of time on layers of the stack that are ultimately not providing a lot of differentiated value. Uh, I think that it’ll be interesting to see over the next five years what happens with services like Kubernetes. I, I believe that we are already seeing, um, a heavy shift toward that layer being managed. Right?
[00:51:05] Mark: Mm-hmm [affirmative]. Oh, God, yeah.
[00:51:06] Forrest: And people just have to feel … Yeah, yeah, it’s, it’s happening. Um, and you know, I, I believe that the word serverless will have less prominence five years from now. I think that people will be just using the, uh, building principles that the serverless folks have been espousing for a few years.
[00:51:22] Mark: Mm-hmm.
[00:51:22] Forrest: But we’ll just be thinking of this, this is what building in the cloud looks like, you know. And it’s interesting, I’ll say this real quick, uh, when I talk to companies who are just now making the move to cloud after having been somehow on premises for all this time, like until 2018 or 2019 and now they’re looking at going cloud, they’re not thinking, oh, I really want to go like run a bunch of virtual machines. You know?
[00:51:42] Mark: Yeah.
[00:51:42] Forrest: They, they, they look at cloud, they say, oh, the excess value here for me would be if I didn’t have to run VMs anymore. I didn’t have to run a bunch of containers anymore, but I could get all these great services that exist for me. Uh, and so they’re, they’re just, they’re not even thinking serverless.
They’re thinking, well, that’s what cloud native means. That’s what I should be doing. Uh, so five years from now you’ll, you’ll see that, uh, I mean, containers will always be there. They’re going to be invisible subsystem as I think some people have said, and we’ll have great managed services that will make it easy to run those not thinking about them.
[00:52:08] Mark: Yeah, fair. And I think that, you know, that example you gave is very similar to what we saw in telecom in China, in India, where the wired infrastructure wasn’t in place and they just leapfrogged it into mobile instead because it didn’t make sense to run wire anymore.
You’re like, why are we doing this? Why don’t we just go sell and set? Right? Um, so, uh, you know, what I mean, obviously a huge problems in general, but if you’re trying to connect 2.5 billion people, what do you expect? Um, so another question on the serverless side because serverless is still a hot thing right now.
Um, on just pure opinion. Um, and this isn’t slagging one or the other, but better serverless primitives, Azure or GCP?
[00:52:45] Forrest: You know, I’m not super qualified to answer that question just because so much of my hands on work tends to be with AWS.
[00:52:51] Mark: Mm-hmm.
[00:52:51] Forrest: Uh, I would say that GCP has staked its claim in the serverless world for a long time with services like Firebase, right?
[00:52:59] Mark: Yeah.
[00:53:00] Forrest: So, and you need, uh, things like, you know, Google app engine, whatever you wanna call it, from a past perspective was making some inroads into, uh, you know, taking some of that lifting away from developers.
Uh, so GCP has got the pedigree there, Azure has got such great developer experience. Um, and I mean, I’ve even had a lot of success using Azure DevOps the past year or two.
[00:53:17] Mark: Yeah.
[00:53:18] Forrest: Uh, that’s an interesting service that ties a lot of things together. So look, I, I mean, I, I don’t know that I would declare a clear winner between either one right now, um.
[00:53:27] Mark: Fair enough.
[00:53:28] Forrest: But…
[00:53:28] Mark: But you know, that, that’s an answer in of itself as well, given that, you know, the prominent amount of your time was spent on the third one of those options. Um, you know, and I agree, Azure DevOps is a great service worth checking out with a horrible, horrible name.
[00:53:40] Forrest: Yes. So it’s like trying to Google, um, the new AWS HTTP APIs for API gateway. You know, that’s a, yeah, it’s impossible.
[00:53:49] Mark: Yeah. You just need to figure out where to put the quotes and it finally ends up working. But I honestly, I’ve tried that a few times and ended up just navigating through the console to get where I needed to go faster than Googling, which is not something I say often. Um, all right, last question to put you totally on the spot. Um, ACG does a fantastic show, uh, this week on AWS, who’s a better host?
[00:54:09] Forrest: Yes.
[00:54:09] Mark: Faye or Ryan?
[00:54:12] Forrest: Wow. Well, I mean.
[00:54:14] Mark: [laughs]
[00:54:16] Forrest: Uh, one of the amazing things and if you’ve ever been to a, like an AWS summit or a physical event like that is when you see Ryan show up at booth and there’s like this pied piper line of a million people going up to get selfies and things with him.
[00:54:27] Mark: Yep.
[00:54:27] Forrest: Um, and uh, that, that has always blown me away. Uh, so with all due respect to Ryan, I have to say that Faye is an amazing presenter. Um, and so, you know, uh, I, I’m, I’m bringing up Ryan’s pedigree to say, I don’t think he’ll be insulted if I say, I think Faye might take it by my nose, but they’re both great.
[00:54:44] Mark: Fair, good, good, well handled. Well handled. And yes, the selfie line is, is also amazing and disheartening when you see Ryan, is Ryan Kroonenburg and is Faye Ellis from ACG. And I’ll put those links in the show notes too.
Um, but yeah, when you’re, you know, there’s, uh, there’s been a few times where there’s been a number of AWS heroes around the booth, um, having a chat and then everybody just comes up to Ryan and like it, the, Drew Firment there and Casch is there and I’m there and Ben Kehoe, like a whole bunch of people who are decently well known in the community and everybody's just like laser focused, nobody even realizes we exist. And there’s like, excuse me.
Yeah. Excuse me, I need a picture with the hair. Let’s go.
[00:55:23] Forrest: I guess what I’m saying is Ryan’s ego can, can survive.
[00:55:27] Mark: [laughs] Fair. Absolutely fair. Um, so, ah, fantastic. I appreciate those, that rapid fire. It’s always fun. Uh, nice to put a little spin on it. Um, we’re getting to the end of this here.
You’ve provided so much amazing information and perspective. And I know, uh, you know, everybody from around the world has really gotten a lot of this. Um, let me ask you a couple of more personal technology side stuff.
[00:55:46] Forrest: Sure.
[00:55:47] Mark: Um, what’s the coolest, especially ‘cause you know, you’ve emceed the serverless, serverless conf, uh, for a number of years now. Um, what’s the coolest serverless solution you’ve seen?
[00:55:58] Forrest: That I’ve seen or that I’ve personally worked on?
[00:56:00] Mark: That you’ve seen? It can be something you’ve personally worked on, if that, if that hits your top 10.
[00:56:05] Forrest: Yeah. So, uh, I, I mean, I, I’ve, I’ve seen a lot of cool stuff. I, I don’t know … The superlatives are hard. I can tell you something I’ve seen that’s, that’s pretty cool.
[00:56:15] Mark: Sure.
[00:56:16] Forrest: Um, and that is, uh, I, I think I referenced this even at the beginning, but, um, a service to do machine learning on pizza is one of the cooler things that I’ve seen.
[00:56:25] Mark: Okay.
[00:56:26] Forrest: Uh, which is, you know, imagine you’ve got pizzas, you’ve ever been in a pizza kitchen, you’ve seen pizza’s going through a pizza oven, right? Um, they, uh, they, they roll through, they have like a make table on one side where they’ll put all the toppings on and then they roll slowly through this oven at a very high heat and they come out the other side and they get cut and put in a box.
[00:56:42] And, uh, the, the problem that you sometimes have in a pizza kitchen is that, uh, because there’s so much customization, uh, customers will ask for a certain thing on their order and you know, there’s a lot of stuff going on.
And so the pizza comes out the other end of the oven and it doesn’t have all the topings in it that the customer asks for. Um, or potentially if you really rushed somebody, sometimes might slide a pizza onto the oven halfway through and so it comes out and it’s not fully cooked. So it’s kind of a food safety issue.
[00:57:03] Mark: Yeah.
[00:57:03] Forrest: Right? So, um, a project that I saw and had a bit of a hand in was uh, creating a, a little robot that lives at the edge of that pizza oven and takes a couple of pictures, a couple of images of the pizza right when it rolls off of the oven and it’s got a thermal camera that checks the, you know, surface temperature of the pizza to make sure that it’s hot enough, uh, for what you can assume is, you know, food safety on the interior and in a, just a regular visual image where you can, um, take a look at the, the toppings. Do some machine learning, use like AWS Sage maker or something to compare it to-
[00:57:34] Mark: [laughs]
[00:57:35] Forrest: Other brand standard pizzas, right? Make sure that the crest isn’t too dark or too light and that if it’s supposed to be a pepperoni pizza, that it is a pepperoni pizza. And then just the, it has a little red light green light on it that tells the pizza chef, okay, this one’s ready to go, or this one might need to be remade.
Um, so you’re, you’re seeing a lot of pizza kitchens come out with this. The, the one that I saw was not Domino’s. This is not the chain I was working with, but I, I did notice, uh, the other day I was looking at Domino’s pizza box and if you look at the side of that box, there is a note on it saying something like, um, do you want to, uh, share your pizza, take a picture, put it on Instagram.
[00:58:08] And there’s very specific instructions that’s hilarious about the lighting to use on the pizza and the hashtag to use and how far away to hold your phone. This is on all Domino’s pizza boxes now. And I don’t know this for a fact, but I would guarantee based on what I know about the industry, that they are doing machine learning on those images to help them train.
Uh, you know, ‘cause there’s, there’s sentiment analysis like on phone, right?
[00:58:26] Mark: Yeah, yeah, exactly. I loved my pizza, I couldn’t stand this. Yeah.
[00:58:31] Forrest: So they’re, they’re crowdsourcing a, a library of images to help them train better pizzas, which I think is fascinating. And one of the cooler, um, systems that I’ve seen, ‘cause that’s all, you know, the, the one I was with, it’s all in green grass and several stuff on the back end.
[00:58:43] Mark: Yeah, yeah, that is amazing. I will dig up a link to that and shove it in the show notes too. And because I guara- … just the way you described that, that is absolutely 100% what they’re doing. If they’re worried about the lighting, if they’re worried about how to tag it, then they’ve got a little bot in the background that’s trolling those, you know, shove [00:59:00] it through comprehend on the AWS back end and go, okay Forrest liked this pizza, Forrest didn’t like us pizza.
[00:59:05] Forrest: Yeah.
[00:59:05] Mark: Um, you know, and then pulling out the, uh, the different, uh, structure in the language and everything and well, that’s amazing.
[00:59:11] Forrest: It’s solving one of the tough machine learning problems, which is classification.
[00:59:14] Mark: Yeah.
[00:59:14] Forrest: And you’re getting kind of this, um, uh, you know, mechanical tech army for you, uh, to, to go in and tag the, classify the pizzas for you. It’s, it’s really, uh, pretty ingenious.
[00:59:23] Mark: And on top of it, it’s a marketing campaign.
[00:59:26] Forrest: Of course, it is.
[00:59:26] Mark: Right?
[00:59:27] Forrest: Everybody wins.
[00:59:29] Mark: That’s just super clever. Like you know, that’s just getting a note hit on so many levels. Um, and you know, you’ve got to imagine the back end, that’s all serverless. It’s nice. It’s handy. It’s, you know, it’s minimal overhead for operations and that cost is directly, you can tie that directly per pizza, right?
So, you know, 2 cents per pizza enables this additional quality assurance, blah, blah, blah, or whatever it ends up being for the cost. Um, you know, which…
[00:59:53] Forrest: Yeah, you factor that against the cost of losing a customer for potentially a period of months or years ‘cause you gave them a bad pizza. Right?
[00:59:59] Mark: Yeah.
[00:59:59] Forrest: And I mean it’s, it’s easy to calculate, uh, you know, what were the marginal return on investment of that.
[01:00:03] Mark: Yeah. And that comes back to, uh, how many, how much and how well.
[01:00:08] Forrest: There you go. And now look at you closing the loop now, Mark.
[01:00:11] Mark: I try, I’m learning. I’m learning, Forrest.
[01:00:13] Forrest: All right, cool.
[01:00:14] Mark: Um, this, this has been fantastic. I appreciate you taking the time. Um, for those of you who’ve been tuning in from home, uh, you know, in isolation, we appreciate you guys spending the time with us.
Um, the team will put the link to, uh, to the, um, series into this episode up in the chats on LinkedIn, on YouTube, on Twitter so that you can go to all the fantastic blog posts that we reference to Forrest, um, a bunch of his work to pre-order his book. I will dig up the stuff for the, uh, for the pizza, uh, serverless solutions, um, just to share that out ‘cause that’s the whole point of this.
So Forrest, thank you again for joining. Very much appreciate it. Uh, any last words for the show in general? Just for the show, not in life.
[01:00:56] Forrest: Not, not in life. Yeah. Just in general I would say, um, as you’re thinking about building, remember not to be code-wise and cloud foolish. Uh, which means try to make sure when you’re considering a solution, uh, that you are taking full advantage of what’s already out there for you.
Stand on the shoulders of the giants, focus on building what is going to provide direct value to your business. And, uh, you will see success in the cloud and make sure you watch for clouds lunacy.
[01:01:20] Mark: Fantastic. Thank you Forrest and thank you everybody. Cool.
