Screaming in the Cloud - Learning to Give in the Cloud with Andrew Brown

Episode Date: January 20, 2022

About AndrewI create free cloud certification courses and somehow still make money.Links:ExamPro Training, Inc.: https://www.exampro.co/PolyWork: https://www.polywork.com/andrewbrownLinkedIn: https://www.linkedin.com/in/andrew-wc-brownTwitter: https://twitter.com/andrewbrown

Hello, and welcome to Screaming in the Cloud, with your host, Chief Cloud Economist at the Duckbill Group, Corey Quinn. This weekly show features conversations with people doing interesting work in the world of cloud, thoughtful commentary on the state of the technical world, and ridiculous titles for which Corey refuses to apologize. This is Screaming in the Cloud. This episode is sponsored in part by our friends at Redis, the company behind the incredibly popular open source database

that is not the Bind DNS server. If you're tired of managing open source Redis on your own, or you're using one of the vanilla cloud caching services, these folks have you covered with the go-to managed Redis service for global caching and primary database capabilities, Redis experience, visit redis.com slash hero. That's R-E-D-I-S dot com slash hero. And my thanks to my friends at Redis for sponsoring my ridiculous nonsense. This episode is sponsored in part by our friends at Rising Cloud, which I hadn't heard of before, but they're doing something vaguely interesting here. They are using AI, which is usually where my eyes glaze over and I lose attention, but they're using it to help developers be more efficient by reducing repetitive tasks.

So the idea being that you can run stateless things without having to worry about scaling, placement, etc. and the rest. They claim significant cost savings and they're able to wind up taking what you're running as it is in AWS with no changes and run it inside of their data centers that span multiple regions. I'm somewhat skeptical, but their customers seem to really like them. So that's one of those areas where I really have a hard time being too snarky about it, because when you solve a customer's problem and they get out there in public and say, we're solving a problem, it's very hard to snark about that. Multis Medical, Construx.ai, and Stacks have seen significant results by using them and it's worth exploring. So if you're looking for a smarter, faster, cheaper alternative to EC2, Lambda, or Batch, consider checking them out.

Visit risingcloud.com slash benefits. That's risingcloud.com slash benefits. And be sure to tell them that I sent you because watching people wince when you mention my name is one of the guilty pleasures of listening to this podcast. Welcome to Screaming in the Cloud. I'm Corey Quinn. My guest today is, well, he's challenging to describe. He's the co-founder and cloud instructor at ExamPro Training Inc., but everyone knows him better as Andrew Brown because he does so many different things in the AWS ecosystem that it's sometimes challenging, at least for me, to wind up keeping track of them all. Andrew, thanks for joining.

Hey, thanks for having me on the show, Corey. How do I even begin describing you? You're an AWS community hero and have been for almost two years, I believe. You've done a whole bunch of work as far as training videos. You're, I think, responsible for 100 Days of Cloud. You recently started showing up on my TikTok feed because I'm pretending that I am 20 years younger than I am and hanging out on TikTok with the kids. And now I feel extremely old. And honestly, you're popping up an awful lot of places. Oh, yeah.

A few other places like Polywork, which is an alternative to LinkedIn. So that's a space that I'm starting to build up on there as well. Active in Discord, Slack channels. I'm just kind of everywhere. There's some kind of internet obsession here. My wife gets really mad and says,

hey, maybe tone down the social media, but I really enjoy it. You're one of those folks where I have this challenge of, I wind up having a bunch of different AWS community slacks and cloud community slacks and discords and the rest, and we DM on Twitter sometimes. And I'm constantly trying to figure out where was that conversational thread that I had with you? And tracking it down is an increasingly large search problem. I really wish that, forget the unified messaging platform. I want a unified search platform for all the different messaging

channels that I'm using to talk to people. Yeah, it's very hard to keep up with all the channels for myself there, but somehow I do seem to manage it, but just with a bit less sleep than most others. Oh yeah, it's like trying to figure out, all right, he said something really useful. What was that? Was it a Twitter DM? Was it on that Slack channel? Was it that Discord? No, it was on that brick that he threw through my window with a note tied to it. There we go. That's always the baseline stuff of figuring out where things are. So as I mentioned at the beginning, you are the co-founder and cloud instructor at ExamPro, which is interesting because unlike most of the community stuff that you do and are known for,

you don't generally talk about that an awful lot. What's the deal there? Yeah, I think a lot of people give me a hard time because they say, Andrew, you should really be promoting yourself more and trying to make more sales. But that's not why I'm out here doing what I'm doing. Of course, I do have a for-profit business called Exam Pro where we create cloud certification study courses for things like AWS, Azure, GCP, Terraform, Kubernetes. But, you know, that money just goes to fuel what I really want to do is just to do community activities to help people change their lives. And I just decided to do that via cloud because that's my domain expertise. At least that's what I say because I've learned up on it in the last four or five years.

And I'm hoping that there's some kind of impact I can make doing that. I take a somewhat similar approach. I mean, at the Duck Bill Group, we fixed the horrifying AWS bill, but I've always found that that's not generally a problem that people tend to advertise having. On Twitter, like, oh, man, my AWS bill is killing me this month. I've got to do something about it. And you check where they work, and it's like a Fortune 50.

It's, yeah, that moves markets markets and no one talks about that. So my approach was always be out there, be present in the community, talk about this stuff. And the people who genuinely have billing problems will eventually find their way to me. That was always my approach because turning everything I do into a sales pitch doesn't work. It just erodes confidence. It reminds people of the used mattress salesman. And I just don't want to be that person in the community. My approach has always been, if I can help someone with a 15-minute call or whatnot, yeah, let's jump on a phone call.

I'm not interested in nickel and diamond, folks. Yeah, and I think that if you're out there doing a lot of hard work, and a lot of it, it becomes undeniable to the value you're putting out there. And then people just will want to give you money, right? And for me, I just feel really bad about taking anybody's money.

And so even when there's some kind of benefit, like my courses, I could charge for access for them, but I always just feel I have to give something in terms of taking somebody's money, but I would never ask anyone to give me their money. So it's bizarre. I had a whole bunch of people a year or so after I started asking, I really find your content helpful. Can I buy you a cup of coffee or something? And it's,

I don't know how to charge people a dollar figure that doesn't have a comma in it, because it's easy for me to ask a company for money. That is the currency of effort, work, et cetera, that companies are accustomed to. People view money very differently. And if I ask you personally for money versus your company for money, it's a very different flow. So my solution to it was to build the annual charity t-shirt drive, where it's great. Spend 35 bucks or whatever on a snarky t-shirt once a year for 10 days, and all proceeds go to benefit a nonprofit. And that has sort of assuaged that. But one of my business philosophies has always been work for free before you work for cheap. And dealing with individuals and whatnot, I do not charge them for things. It's, oh, can you, I need some advice on my career. Can I pay

you to give me some advice? No, but you can jump on a Zoom call with me, please. The reason I exist at all is because people who didn't have any reason to did me favors once upon a time. And I feel obligated to pay that forward. And I appreciate it. You know, if there are people out there that, you know, do need to charge for their time, I'm like, I won't judge anybody that wants to. But, you know, for me, it's just, I can't do it because of the way I was raised. Like my grandfather was very involved in the community. Like he was recognized by the city as for all of his volunteer work and doing volunteer work was like mandatory for me as a kid, like every weekend. And so for me as a kid, like every weekend.

And so for me, it's just like, I can't imagine trying to take people's money, which is not a great thing, but it turns out that the community is very supportive and they will come beat you down with a stick to give you money to make sure you keep doing what you're doing. But, you know, I could be making lots of money,

but it's just not my priority. So I've avoided any kind of funding. So, you know, I don't become a money-driven company and I will see how long that lasts, but hopefully a lot longer. I wish it well. Again, you're right. No shade to anyone who winds up charging

for their time to individuals. I get it. I just always had challenges with it. So I decided not to do it. The only time I find myself begrudging people who do that are someone who picked something up six months ago and decided, oh, I'm going to build some video course on how to do this thing, the end, and charge a bunch of money for it and put myself out as an expert in that space. And you look at what the content

they're putting out is, and one, it's inaccurate, which just drives me up a wall. And two, there's a lack of awareness that teaching is its own skill. In some areas, I know how to teach certain things. And in other areas, I'm a complete disaster at it. Public speaking is a great example. A lot of what I do in the public speaking stage is something that comes to me somewhat naturally. So can you teach me to be a good public speaker? Not really. It's like, well, you gave that talk and it was bad. Could you try giving it, only make it good? Like, that is not a helpful coaching statement. So I stay out of that mess. Yeah, I mean, it's really challenging to know whether,

if you feel like you're authority enough to put something out there. And there's been a few courses where I didn't feel like I was the most knowledgeable, but I had produced those courses and they had done extremely well. But as I was going through the course, I was just like, yeah,

I don't know how any of this stuff works, but this is my best guess translating from here. And so, you know, at least for my content, people have seen me as like the lens of AWS on top of other platforms, right? So I might not know, I'm not expert in Azure, but I've made a lot of Azure content and I just translate that over.

And I talk about the frustrations around like using scale sets compared to AWS autoscaling groups. And that seems to really help people get through the motions of it. And I know if I pass, at least they'll pass. But by no means do I ever feel like an expert. Like right now, I'm doing like Kubernetes. And I like I have no idea how I'm doing it. But I have like help with three other people. And so I'll just be honest about and say, hey, yeah, I'm learning this as well. But at least I know I passed. So, you know, you can pass too, whatever that's worth. Oh, yeah. Back when I was starting out, I felt like a bit of a fraud because I didn't know everything about the AWS billing system and how it worked and all the different things people can do with it and things they can ask. And now five years later, when the

industry basically acknowledges I'm an expert, I feel like a fraud because I couldn't possibly understand everything about the AWS billing system and how it works. It's one of those things where the more you learn, the more you realize that there is yet to learn. I'm better equipped these days to find the answers to the things I need to know, but I'm still learning things every day. If I ever get to a point of complete and total understanding of a given topic, I'm wrong. You can always go deeper. Yeah, I mean, by no means am I even an expert in AWS, though people seem to think that I am, just because I have a lot of confidence in there.

I produce a lot of content. Well, that's a lot different from making a course and implementing stuff. And I do implement stuff, but, you know, it's just at the scale that I'm doing it at. So just food for thought for people there. Oh, yeah. Whenever I implement something, it's great. In my previous engineering life, I would work on large scale systems.

So I know how a thing that works in your test environment is going to blow up in a production scale environment. And I bring those lessons written on my bones, the painful way through outages, to the way that I build things now. But the stuff that I'm building is mostly to keep my head in the game as opposed to solving an explicit business need. Could I theoretically

build a podcast transcription system on top of transcribe or something like that for these episodes? Yeah. But I've been paying a person to do this for many years to do it themselves. They know the terms of art. They know how this stuff works. And they're building a glossary as they go and understanding the nuances of what I say and how I say it. And that is the better business outcome. That's the answer. And if it's production-facing, I probably shouldn't be tinkering with it too much just based upon where the... I don't want to be the bottleneck for the business functioning. I've been spending so much time doing the same thing over and over again, but for different cloud providers.

And the more I do, the less I want to go deep on these things because I just feel like I'm dumping all this information I'm going to forget and that I have those broad strokes. And when I need to go deep dive, I have that confidence. So I'd really prefer if people were to build up confidence in saying, yes, I think I can do this as opposed to being like, oh, I have proof that I know every single feature in AWS Systems Manager,

just because like our platform, Exam Pro, like I built it with my co-founder and it's quite a system. And so I'm going, well, that's all I need to know. And I talked to other CTOs and there's only so much you need to know. And so I don't know if there's like a shift between or difference between like application development,

where let's say you're doing React and using Vercel and stuff like that, where you have to have super deep knowledge for that technical stack, whereas cloud is so broad or diverse, that maybe just having confidence and hypothesizing the work that you can do and seeing what the outcome is, is a bit different, right? Not having to prove 100% that you know it inside and out on day one, but have the confidence. And there's a lot of validity to that and a lot of value to it. It's the magic word I always found in interviewing on both sides of the interview table

has always been, when someone isn't sure about something, start with, I'm not sure, but if I had to guess, and then say whatever it is you were going to say. Because if you get it right, wow, you're really good at figuring this out and your understanding is pretty decent.

If you're wrong, well, you've shown them how you think, but you've also called them out because you're allowed to be wrong. You're not allowed to be authoritatively wrong. Because once that happens, I can't trust anything you say. Yeah. In terms of like, how do cloud certifications help you for your career path?

I mean, I find that they're really well-structured and they give you a goal to work towards. So like get passing that exam is your motivation to make sure that you complete it. Do employers care? It depends. I would say mostly no. I mean, for me, like when I'm hiring,

I actually do care about certifications because we make certification courses. In your case, you're a very specific expression of this that is not typical. Yeah, and there are some like cases where like if you work for a larger cloud consultancy, you're expected to have a professional certification so that customers feel secure in your ability to execute. But it's not like they were trying to hire you with that requirement, right? And so I hope that people realize that and that they look at showing that practical skills by building out cloud projects. And so that's usually a strong pairing I'll have, which is like, great, get the certifications to help you just have a structured journey and then do a cloud project to prove that

you can do what you say you can do. One area where I've seen certifications act as an interesting proxy for knowledge is when you have a company that has 5,000 folks who work in IT in varying ways. And all right, we're doing a big old cloud migration. The certification program, in many respects, seems to act as a bit of a proxy for a way of gauging where people are on upskilling, how much they have to learn, where they are in that journey. And at that scale, it begins to make some sense to me. Where do you stand on that? Yeah, I mean, it's hard because it really depends on how those paths are built. So when you look at the AWS certification roadmap, they have the certified cloud practitioner, they have three associates, two professionals, and a bunch of

specialties. And I think that you might think, well, oh, solutions architect must be very popular. But I think that's because AWS decided to make the most popular, the most generic one called that. And so you might think that that's what's most popular, but what they probably should have done is renamed that to the Solution Architect to be a cloud engineer because very few people become Solutions Architect. Like that's more, if there's junior Solutions Architect, I don't know where they are, but Solutions Architect is more of like a senior role where you have strong communications, pre-sales. Obviously, the role is going to vary based on what companies decide a solution architect is. Oh, absolutely. Take a solutions architect, give them a crash course in finance, and we call them a cloud economist.

Sure. You just add modifiers there and there's something else. And so I really think that what they should have named that one is the cloud engineer, and they should have extracted it out as its own tier. So you'd have the fundamental, the certified cloud practitioner, then the cloud engineer, and then you could say, look, now you could do developer or the sys ops. And so you're creating this path where you have a better trajectory to see where people really want to go. But the problem is a lot of people come in and they just do the solutions architect, and then they don't even touch the other two because they say, well, I got an associate, so I'll move on to the next one. So I think there's some structuring there

that comes into play. You look at Azure, they've really, really caught up to AWS and I might even say surpassed them in terms of the quality and the way they market them and how they construct their certifications. There's things I don't like about them,

but they have like all these fundamental certifications. Like you have Azure fundamentals, data fundamentals, AI fundamentals, there's like Fundamentals. And to me, that's a lot more valuable than going over to an associate. And so I did all those and I still think,

should I go translate those over for AWS? Because you have to wait for a specialty before you pick up security. And they say it's intertwined with all the certifications, but it really isn't. And I feel like that would be a lot better for AWS, but that's just my personal opinion. My experience with AWS certifications has been somewhat minimal. I got the cloud practitioner a few years ago under the obworking theory of I wanted to get into the certified lounge at some of the events because sometimes I needed to charge things and grab a cup of coffee.

I viewed it as a lounge pass with a really strange entrance questionnaire. And in my case, yeah, I passed it relatively easily. If not, I would have some questions about how much I actually know about these things. As I recall, I got one question wrong because I was honest instead of going by the book answer for, how long does it take to restore an RDS database from a snapshot? I've had some edge cases there that give the wrong answer, except that's what happened. And then I wound up having that expire and lapse. And okay, now I'll do it. It was in beta at the time, but I got the SysOps associate cert to go with it. And that had a whole bunch of trivia thrown into it. Like, which of these is the proper syntax for

this thing? And that's the kind of question that's always bothered me. Because when I'm trying to figure things like that out, I have the entire internet at my fingertips. Understanding the exact syntax or command line option or flag that needs to do a thing is a five-second Google search away in most cases. But measuring for people's ability to memorize and retain that has always struck me as a relatively poor proxy for knowledge. It's hard across the board. Like Azure, AWS, GCP, they all have different approaches. Like Terraform, all of them, they're all different. And, you know, if we go to an interview process, you have to kind of extract where the value is. And I would think that the majority of the industry, you know, don't have best practices when hiring. There's like a superficial

AWS is like, oh, if you do well in star program format, you must be a communicator like, well, I'm dyslexic. So that stuff is not easy for me. And I will never do well in that. So like, a lot of companies hinge on those kind of components. And I mean, I'm sure it doesn't matter if you have a certain scale, you're going to have attrition, there's no perfect system. But when you look at the certifications, and you say, well, how much do they match up with the job? Well, they don't, right? It's just Jeopardy. But, you know, I still think there's value for yourself in terms of being able to internalize it. I still think that does prove that you have done something,

but taking the AWS certification is not the same as taking Andrew Brown's course. So like my certified cloud practitioner was built after I did GCP, Oracle Cloud, Azure Fundamentals, a bunch of other Azure Fundamental certifications, cloud native stuff. And then I brought it over because it was missing, right? So like, if you went through my course,

and then I had a qualifier, then I could attest to say like, you are of this skill level, right? But it really depends on what that attestment is, and whether somebody even cares about what my opinion of like your skill set is. But I can't imagine like, when you have a security incident, there's going to be a pop up that shows shows you a multiple-choice answer to remediate the security incident. Now, we might get there at some point with all the cloud automation, but we're not there yet. It's been sort of the thing we've been chasing and never quite get there. I wish, but I hope I live to see it. Truly, I do.

My belief is also that the value of a certification changes depending upon what career stage someone is in. Regardless of what level you are, a hiring manager or a company is looking for a more or less a piece of paper that attests that they ought to solve the problem that they are hiring to solve. And entry level, that is often a degree or a certification or something like that in the space that shows you have at least the baseline fundamentals slash know how to learn things. After a few years, I feel like that starts to shift into, okay, you've worked in various places solving similar problems on your resume that the type that we have, because the most valuable thing you can hear when you ask someone, how would we solve this problem? Well, the last time I solved it, here's what we learned. Great. That's experience. There's no compression algorithm for experience. Yes, there is hiring people with experience. Then at some level, you wind up with the very

far side of people who are late career in many cases, where the piece of paper that shows that they know what they're doing is, have you tried Googling their name and looking at the Wikipedia article that spits out how they built fundamental parts of a system like that. I think that certifications are one of those things that buy us for early career folks, and of course partners when there are other business reasons to get it. But as people grow in seniority, I feel like the need for those begins to fall off.

Do you agree? Disagree? You're much closer to this industry and that aspect of it than I am. The more senior you are, and if you have big names under your resume there, no one's going to care if you have certification, right? When I was looking to switch careers, I used to have a consultancy

and I was just tired of building another failed startup for somebody that was willing to pay me. And I'm like, I was not very nice about it. I always be like, your startup's not going to work out. You really shouldn't be building this. And they'd still give me the money and then it would fail and I'd move on to the next one. It was very frustrating.

So I closed up shop on that. And I said, okay, I got to reenter the market. I don't have a computer science degree. I don't have big names on my resume. And Toronto is a very competitive market. And so I was feeling friction because people were not valuing my projects. I had like full stack projects I would show them.

And they said, no, no, just do these like comp sci algorithms and stuff like that. And so I went, okay, well, I really don't want to be doing that. I don't want to spend all my time learning algorithms just so I can get a job to prove that I already have the knowledge I have. And so I saw a big opportunity in cloud

and I thought certifications would be the proof to say I can do these things. And when I actually ended up going for the interviews, I didn't even have the certifications and I was getting those opportunities because the certifications helped me prove it, but nobody cared about the certifications even then. That was like 2017.

But not to say like they didn't help me, but it wasn't the fact that people went, oh, you have a certification, we'll get you this job. Yeah, when I'm talking to consulting clients, I've never once been asked, well, do you have the certifications or are you an AWS partner? In my case, no, neither of those things. The reason that we know what we're doing is because we've done this before. It's the expertise approach. I question whether that would still be true if we were saying, oh yeah, and we're going to drop a

dozen engineers on who are going to build things out of your environment. Well, are they certified is a logical question to ask when you're bringing in an external service provider. Or is this just a bunch of people you found somewhere on Upwork or whatnot, and you're throwing them out with no quality control? What is the baseline level experience? That's a fair question. People are putting big levels of trust when they bring people in. I mean, I could see that as a factor of some clients caring just because when I used to work in startups, I knew customers where it's like their second startup and they're flush with a lot of money and they're deciding who they want to partner with.

And they're literally looking at what level of SSL certificate they purchased, right? Like now, obviously they're all free and they're very easy to get to. There was one point where they had different tiers as if you would know, and they would look and they would say- Extended validation search

that turned your browser bar green. Remember that? Right, yeah, yeah. It was just like that. And they were like, we should partner with them because they were able to afford that and we know, like, whatever, whatever, right?

So, you know, there is that kind of thought process for people at the executive level. I'm not saying it's widespread, but I've seen it. When you talk to people that are in cloud consultancy, like solutions architects, they always tell me they're driven

to go get those professional certifications and their customers matter. I don't know if the customers care or not, but they seem to think so. So I don't know if it's just more driven by those people because it's an expectation because everyone else has it, or it's like a package of things like, you know, like the green bar, the certifications, SOC 2 compliance, things like that, that kind of wrap it up and say, okay, as a package, this looks really good. So more of an expectation, but not necessarily matters. This is superficial. I'm not sure. This episode is sponsored by our friends at Oracle HeatWave, a new high-performance query accelerator for the Oracle MySQL database service, although I insist on calling it MySquirrel.

While MySquirrel has long been the world's most popular open-source database, shifting from transacting to analytics required way too much overhead and, you know, work. With HeatWave, you can run your OLAP and OLTP, don't ask me to pronounce those acronyms ever again, workloads directly from your MySquirrel database and eliminate the time-consuming data movement and integration work, while also performing 1,100 times faster than Amazon Aurora and two and a half times faster than Amazon Redshift at a third the cost. My thanks again to Oracle Cloud for sponsoring this ridiculous nonsense. You've been building out certifications for multiple cloud providers, so I'm curious to get

your take on something that Forrest Brazil, who's now head of content over at Google Cloud, has been talking about lately. The idea that as an engineer, it is advised to learn more than one cloud provider. Even if you have one as a primary, learning how another one works makes you a better engineer. Now, setting aside entirely the idea that, well, yeah, if I worked at Google, I'd probably be saying something fairly similar. Do you think there's validity to the idea that most people should be broad across multiple providers?

Or do you think specialization on one is the right path? Sure. Just to contextualize for our listeners, Google Cloud is highly, highly promoting multi-cloud workloads. And one of their flagship products is, well, they say it's a flagship product, is Anthos. And they put a lot of money, I don't know if it was subsidized, but they put a lot of money in it because they really want to push multi-cloud, right?

And so when we say Forrest works at Google Cloud, it should be no surprise that he's promoting it. But I don't work for Google. And I can tell you, like, learning multi-cloud is like way more valuable than just staying in one vertical. It just opened my eyes. When I went from AWS to Azure, it was just like, oh, I'm missing out on so much in the industry.

And it really just made me such a more well-rounded person. And then I went over to Google Cloud and it was just like, because you're learning the same thing in different variations and then you're also polyfilling for things that you will never touch. Or like, I shouldn't say you never touch, but you would never touch if you just stayed in that vertical when you're learning the same thing in different variations and then you're also polyfilling for things that you will never touch.

Or like I shouldn't say you never touch, but you would never touch if you just stayed in that vertical when you're learning. So in the industry, Azure Active Directory is like widespread. But if you just stayed in your little AWS box, you're not going to notice it

on that learning path, right? And so a lot of times I tell people, go get your CLF-C01 and then go get your AZ-900 or AZ-104. Again, I don't care if people go and sit the exams, but I want them to go learn the content because it is a large eye-opener. A lot of people are against multi-cloud from a learning perspective because they say it's too much to learn all of them at the same time. But a lot of people, I don't think have actually gone across the cloud,

right? So they're sitting from their chair, only staying in one vertical saying, well, you can't learn them all at the same time. And I'm going, I see a way that you could teach them all at the same time. And I might be the first person that will do it. And the principles do convey as well. It's, oh, well, I know how SNS works on AWS. So I would never be able to understand how Google PubSub works. Those are functionally identical. I don't know that that is actually true. It's just different interface points and different guarantees, but fine. You at least understand the part that it plays. I've built things out on Google Cloud somewhat recently.

And for me, every time I do, it's a refreshing eye-opener to, oh, this is what developer experience in the cloud could be. And for a lot of customers, it is. But staying too far within the bounds of one ecosystem does lend itself to a loss of perspective if you're not careful. I agree with that. Yeah. Well, I mean, just to paint it more of a picture staying too far within the bounds of one ecosystem does lend itself to a loss of perspective if you're not careful. I agree with that. Yeah. Well, I mean, just to paint it more of a picture of differences, like Google Cloud has a lot about digital transformation. They just updated their,

I'm not happy that they changed it, but I'm fine that they did that. But they updated their Google Digital Cloud Leader exam guide this month, and it like is 100% all about digital transformation. So they love talking about digital transformation and those kinds of concepts there. They are really good at defining migration strategies like at a high level, go over to Azure. They have their own cloud adoption framework. And it's so detailed in terms of like execution where you go over to AWS and they have like the worst cloud adoption framework.

It's just the laziest thing I've ever seen produced in my life compared to out of all the providers in that space. I didn't know about Zero Trust Model until I started using Azure because Azure has Active Directory and you can do risk-based policy procedures over there. So, you know, like if you don't go over these places,

they're not going to get covered other places. You're just going to be missing information until you get the job. And, you know, that job has that information requiring you to know it. I would say that for someone early career, and I don't know where this falls on the list of career advice ranging from that is genius to okay, boomer. But I would argue that figuring out what companies in your geographic area or the companies that you have connections with,

what they're using for a cloud provider, I would bias for learning one enough to get hired there, and from there, letting what you learn next be dictated by the environment you find yourself in. Because especially larger companies, there's always something that lives in a different provider. My default worst practice is multi-cloud. And I don't say that because multi-cloud doesn't exist, and I'm not saying it because it's a bad idea, but this idea of one workload, to me, that runs across multiple providers is generally a challenge. What I see a lot more done intelligently is, okay, we're going to use this provider for some things, this other provider for other things, and this third provider for yet more things. And every company does that. If not, there's something very strange going on. Even Amazon uses, if not Office 365, at least Exchange, to run their email systems instead of Amazon WorkMail, because let's be serious. That tells

me a lot. But I don't generally find myself in a scenario where I want to build this application that is anything more than Hello World, where I want it to run seamlessly and flawlessly across two different cloud providers. That's an awful lot of work that I struggle to identify significant value for most workloads. I don't want to think about securing like multiple workloads. And that's, I think a lot of friction for a lot of companies or ingress, egress costs, which I'm sure you might have some knowledge on there about the ingress, egress cross providers. Oh, a little bit. Yeah. A little bit. Oh, throwing data between clouds is always expensive. Sure. So I mean like, I call multi-cloud using multiple providers, but not in tandem.

Cross-cloud is when you want to use something like Anthos or Azure Arc or something like that, where you extend your data plane or control plane, whatever the plane is, whatever plane across all the providers. But, you know, in practice, I don't think many people are doing cross-cloud. They're doing multi-cloud. Like, I use AWS to run my primary workloads and then i use microsoft office suite and so we happen to use azure back to directory or you know run particular vm machines like windows machines for our accounting you know so it's a mixed bag but i do think that using more than one thing is becoming more popular just because you want to use the best

in breed no matter where you are so like i love bigqu BigQuery. BigQuery is amazing. So like, I ingest a lot of our data from, you know, third party services right into that. I could be doing that in Redshift, which is expensive. I could be doing that in Azure Synapse, which is also expensive. I mean, there's a serverless thing. I don't really think it's serverless. So I think that, you know, people are doing multi-cloud. Yeah, I would agree. I tend to do things like that myself. And whenever I see it, it generally makes sense. This is my general would agree. I tend to do things like that myself, and whenever I see it, it generally makes sense. This is my general guidance. When I talk to individuals who say, well, we're running multi-cloud like this, and my response is, great, you're probably right,

because I'm talking in the general sense. Someone building something out on day one where they don't know, like everyone's saying multi-cloud, should I do that? No, I don't believe you should. Now, if your company has done that intentionally rather than by accident, there's almost certainly a reason and context that I do not have. Well, we have to run our SaaS application in multiple cloud providers because that's where our customers are. Yeah, you should probably do that. But your marketing, your billing systems, your backend reconciliation stuff generally does not live across all of those providers. It lives in one.

That's the sort of thing I'm talking about. I think we're in violent agreement here. Oh, sure, yeah. I mean, Kubernetes obviously is becoming very popular because people believe that they'll have a lot more mobility, whereas when you use all the different managed, and I'm still learning Kubernetes myself from the next certification I have coming out,

like course, study course, but, you know, like those managed services have all different kind of kinks that are completely different. And so you know, it's not going to be a smooth process. And you're still leveraging like, for key things like your database, you're gonna be running that in Kubernetes cluster, you're going to be using a managed service. And so those have their own kind of expectations in terms of configuration. So I don't know, it's tricky to say what to do. But I think that, you know, if you have a need for it, and you don't have a security concern, like usually it's security or cost, right? For multi-cloud? For me, at least the lock-in has always been twofold that people

don't talk about. It's more, less lock-in than buy-in. One is a security model where IAM is super fraught and challenging and tricky and trying to map a security model to multiple providers is super hard. Then on top of that, you also have the buy-in story of a bunch of engineers who are very good at one cloud provider and that skill set is not in less demand now than it was a year ago. So, okay, you're going to start over and learn a new cloud provider is often something where that a lot of engineers won't want to countenance. If your team is dead set against it, there's going to be some friction there and there's going to be some friction there

and there's going to be a challenge. I mean, for me at least, to say that someone knows a cloud provider is not the naive approach of, oh, yeah, they know how it works across the board. It's that they know how it breaks. For me, one of the most valuable reasons to run something on AWS

is I know what a failure mode looks like. I know how it degrades. I know how to find out what's going on when I see that degradation. That, to me, is a very hard barrier to overcome. Alternately, it's entirely possible that I'm just old. Well, I think we're starting to see some wins all over the place in terms of being able to learn one thing

and bring it to other places, like OpenTelemetry, which I believe is a cloud-native Kubernetes. CNCF, I can't remember what it stands for. It's like Linux Foundation, but for cloud-native. And so OpenTelemetry is just a standardized way of handling your logs, metrics, and traces, right? And so maybe CloudWatch will be the 1.0 of observability in AWS.

And then maybe OpenTelemetry will become more of the standard, right? And so maybe we might see more managed services like Prometheus and Graphon. Obviously, AWS has a managed Prometheus, but other things like that. So maybe some of those things will melt away. But yeah, it's hard to say what approach to take. Yeah, I'm wondering on some level whether what the things we're talking about today, how well that's going to map forward because the industry is

constantly changing. The guidance I would give about should you be in cloud five years ago would have been a nuanced depends, maybe for yes, maybe for no. Here's the story. It's a lot less hedgy and a lot less edge casey these days when I answer that question. So I wonder in five years from now, when we look back at this podcast episode, how well this discussion about what the future looks like

and certifications and multi-cloud, how well that's going to reflect. Well, when we look at like Kubernetes or Web3, we're just seeing kind of like this standardized boilerplate way of doing a bunch of things, right? All over the place. This distributed way of having this generic API across the board and how well that will take, I have

no idea. But we do see a large split between serverless and cloud-native. So it's like, what direction? Or we'll just have both. Probably we'll just have both, right? I like that. I hope so. It's been a wild industry ride. And I'm really curious to see what changes as we wind up continuing to grow.

But we'll see. That's the nice thing about this is, worst case, if, oh, it turns out that we were wrong on this whole cloud thing and everyone starts exodus-ing back to data centers, well, okay. That's the nice thing about being a small company. It doesn't take either of us that long to address the reality we see in the industry. Well, these cloud service providers are just going to get better at offering those services within carrier hotels or data centers or on your on-premise under your desk, right? So, I don't know. We'll see. It's hard to say what the future will be, but I do believe that cloud

is sticking around in one form or another, and it basically is like an essential skill or table stakes for anybody that's in the industry. I mean, of course, not everywhere, but like mostly, I would say, so. Andrew, I want to thank you for taking the time to speak with me today. If people want to learn more about your opinions, how you view these things, et cetera,

where can they find you? You know, I think the best place to find me right now is Twitter. So if you go to twitter.com forward slash Andrew Brown, all lowercase, no spaces, no underscores, no hyphens, you'll find me there. I'm so surprised I was able to get that handle. It's like the only place where I have my handle. And we will, of course, put links to that in the show notes. Thanks so much for taking the time to speak with me today. I really appreciate it.

Well, thanks for having me on the show. Andrew Brown, co-founder and cloud instructor at ExamPro Training and so much more. I'm cloud economist Corey Quinn, and this is Screaming in the Cloud. If you've enjoyed this podcast, please leave a five-star review on your podcast platform of choice. Whereas if you hated this podcast, please leave a five-star review on your podcast platform of choice. Whereas if you hated this podcast, please leave a five-star review on your podcast platform of choice, along with an angry comment telling me that I do not understand certifications at all, because you're an accountant and certifications matter more in that industry. If your AWS bill keeps rising and your blood pressure is doing the same, then you need the Duck Bill Group. We help companies fix their AWS bill by making it smaller and less horrifying. The Duck Bill

Group works for you, not AWS. We tailor recommendations to your business and we get to the point. Visit duckbillgroup.com to get started. This has been a HumblePod production. Stay humble.