Learning to Give in the Cloud with Andrew Brown

• ExamPro Training, Inc.: https://www.exampro.co/
• PolyWork: https://www.polywork.com/andrewbrown
• LinkedIn: https://www.linkedin.com/in/andrew-wc-brown
• Twitter: https://twitter.com/andrewbrown

Transcript

Andrew: 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.

Corey: 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 manage Redis service for global caching and primary database capabilities; Redis Enterprise. To learn more and deploy not only a cache but a single operational data platform for one Redis experience, visit redis.com/hero. Thats r-e-d-i-s.com/hero. And my thanks to my friends at Redis for sponsoring my ridiculous non-sense.

Corey: 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, et cetera, 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. Multus Medical, Construx.ai and Stax 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/benefits. That’s risingcloud.com/benefits, and be sure to tell them that I said you because watching people wince when you mention my name is one of the guilty pleasures of listening to this podcast.

Corey: 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.

Andrew: Hey, thanks for having me on the show, Corey.

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 #100daysofcloud; 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 obviously, you’re popping up an awful lot of places.

Andrew: 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. So.

Corey: 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 past, 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.

Andrew: 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.

Corey: Oh, yeah. It’s like trying to figure out, like, “All right, he said something really useful. What was that? Was that 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 in 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?

Andrew: 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 ExamPro, 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 in the last four or five years. I’m hoping that there’s some kind of impact I can make doing that.

Corey: I take a somewhat similar approach. I mean, at The Duckbill Group, we fixed the horrifying AWS bill, but I’ve always found 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 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 that 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-diming folks.

Andrew: Yeah. I think that if you’re out there doing a lot of hard work, and a lot of it, it becomes undeniable 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 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. [laugh] so.

Corey: I had a whole bunch of people a year or so after I started asking, like, “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 ten days and all proceeds go to benefit a nonprofit that is, 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 in 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.

Andrew: And I appreciate, you know, there are people out there that you know, do need to charge for their time. Like—

Corey: Oh. Oh, yes.

Andrew: —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 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, 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 like, you know, I don’t become a money-driven company, and I will see how long that lasts, but hopefully, a lot longer.

Corey: I wish you well. And 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 on 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.

Andrew: Yeah, I mean, it’s really challenging to know, 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 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 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 an 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 auto-scaling groups, and that seems to really help people get through the motions of it.

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. 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 it 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.

Corey: 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.

Andrew: 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 and I produce a lot of content. But that’s a lot different from making a course than implementing stuff. And I do implement stuff, but you know, it’s just at the scale that I’m doing that. So, just food for thought for people there.

Corey: Oh, yeah. Whatever, 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.

Andrew: 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 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, ExamPro, like, I built it with my co-founder, and it’s a quite a system. And so I’m going well, that’s all I need to know.

And I talk 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 a bit different, right? Not having to prove one hundred percent that you know it inside and out on day one, but have the confidence.

Corey: 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 someone who’s unsure 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.

Andrew: 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, 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 but—

Corey: In your case, you’re a very specific expression of this that is not typical.

Andrew: 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 up 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.”

Corey: One area where I’ve seen certifications act as an interesting proxy for knowledge is when you have a company that has 5000 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 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?

Andrew: 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’s what’s most popular.

But what they probably should have done is renamed that 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—

Corey: Oh, absolutely take a solutions architect, give him a crash course in finance, and we call them a cloud economist.

Andrew: Sure. You just add modifiers there, and they’re something else. And so I really think that they should have named that one as 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 sysops.” 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 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 may I might even say surpass 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 a Security Fundamentals.

And to me, that’s a lot more valuable than going over to an associate. And so I did all those, and you know, I still think, like, should I go translate those over for AWS because you have to wait for a specialty before you pick up security. And they say, like, it’s intertwined with all the certifications, but, really isn’t. Like—and I feel like that would be a lot better for AWS. But that’s just my personal opinion. So.

Corey: My experience with AWS certifications has been somewhat minimal. I got the Cloud Practitioner a few years ago, under the working 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 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.

Andrew: 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, when you go to 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 speak 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 kinds 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 these 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 was missing, right? So like, if you went through my course, and that 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 testament is and whether somebody even cares about what my opinion of, like, your skillset is. But I can’t imagine like, when you have a security incident, there’s going to be a pop-up that shows you multiple-choice answer to remediate the security incident. Now, we might get there at some point, right, with all the cloud automation, but we’re not there yet.

Corey: It’s been sort of thing we’ve been chasing and never quite get there. I wish. 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 at. Regardless of what level you are at, a hiring manager or a company is looking for more or less a piece of paper that attests that they’re 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?” Is, “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 at 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 bias 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 in that aspect of it than I am.

Andrew: 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 was like, “Your startup’s not going to work out. You really shouldn’t be building this.” And they still give me the money and it would fail, and I’d move on to the next one. It was very frustrating.

So, 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, CompSci 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 certifications and I was getting those opportunities because the certifications helped me prove it, but nobody cared about the certifications, even then, and 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.”

Corey: 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 at it with no quality control? Like, what is the baseline level experience? That’s a fair question. People are putting big levels of trust when they bring people in.

Andrew: I mean, I could see that as a factor of some clients caring, just because like, 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 get; there was one point where you had different tiers—as if you would know—and they would look and they would say—

Corey: Extended validation certs attend your browser bar green. Remember those?

Andrew: Right. Yeah, yeah, yeah. It was just like that, and they’re 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 an 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 [unintelligible 00:22:19] 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 in 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, it’s just superficial; I’m not sure.

Corey: This episode is sponsored by our friends at Oracle HeatWave is a new high-performance accelerator for the Oracle MySQL Database Service. Although I insist on calling it “my squirrel.” While MySQL has long been the worlds most popular open source database, shifting from transacting to analytics required way too much overhead and, ya know, work. With HeatWave you can run your OLTP and OLAP, don’t ask me to ever say those acronyms again, workloads directly from your MySQL database and eliminate the time consuming data movement and integration work, while also performing 1100X faster than Amazon Aurora, and 2.5X faster than Amazon Redshift, at a third of the cost. My thanks again to Oracle Cloud for sponsoring this ridiculous nonsense.

Corey: You’ve been building out certifications for multiple cloud providers, so I’m curious to get your take on something that Forrest Brazeal, who’s now head of content over at Google Cloud, has been talking about lately, the idea that as an engineer 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 probably be saying something fairly similar.

Andrew: Yeah.

Corey: 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?

Andrew: 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 that 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 in 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 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 poly-filling 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. 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 say, it’s too much to learn all 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.

Corey: 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 Pub/Sub works.” Those are functionally identical; I don’t know that is actually true. It’s just different to 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.

Andrew: Yeah. Well, I mean, just the paint 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 one hundred percent all about digital transformation. So, they love talking about digital transformation, and those kind of concepts there. They are really good at defining migration strategies, like, at a high level.

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 start 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 to these places, you’re not going to get covered other places, so you’re just going to be missing information till you get the job and, you know, that job has that information requiring you to know it.

Corey: 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—

Andrew: Yeah.

Corey: 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.

Andrew: 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 are ingress-egress costs, which I’m sure you might have some knowledge on there about the ingress-egress costs across providers.

Corey: Oh, a little bit, yeah.

Andrew: A little bit, probably.

Corey: Oh, throwing data between clouds is always expensive.

Andrew: 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 pla—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 Active 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 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 get serverless. So, I think that, you know, people are doing multi-cloud.

Corey: Yeah. I would agree. I tend to do things like that myself, and whenever I see 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 back-end 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.

Andrew: 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, 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 not going to 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.

Corey: For me, at least, the lock-in has always been twofold that people don’t talk about. More—less lock-in than buy-in. One is the 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 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 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.” 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.

Andrew: Oh, 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 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 Grafa—well, 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.

Corey: 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, “Mmm, depends. Maybe for yes, maybe for no. Here’s the story.” It’s a lot less hedge-y and a lot less edge case-y 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?

Andrew: Well, when we look at, like, Kubernetes or Web3, we’re just seeing kind of like the standardized boilerplate way of doing a bunch of things, right, all over the place. This distributed way of, like, 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, like, serverless and cloud-natives. So, it’s like, what direction? Or we’ll just have both? Probably just have both, right?

Corey: [Like that 00:33:08]. 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, turns out that we were wrong on this whole cloud thing, and everyone starts exodusing 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.

Andrew: Well, that or 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.

Corey: 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?

Andrew: You know, I think the best place to find me right now is Twitter. So, if you go to twitter.com/andrewbrown—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.

Corey: And we will of course put links to that in the [show notes 00:34:25]. Thanks so much for taking the time to speak with me today. I really appreciate it.

Andrew: Well, thanks for having me on the show.

Corey: 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’ve 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.

Corey: If your AWS bill keeps rising and your blood pressure is doing the same, then you need The Duckbill Group. We help companies fix their AWS bill by making it smaller and less horrifying. The Duckbill Group works for you, not AWS. We tailor recommendations to your business and we get to the point. Visit duckbillgroup.com to get started.

Announcer: This has been a HumblePod production. Stay humble.