About Mark Nunnikhoven
Is this system safe? Is my information protected? These are hard questions to answer. Mark Nunnikhoven works to make cybersecurity and privacy easier to understand.

A forensic scientist and security leader, Mark has spent more than 20 years helping to defend private and public systems from cybercriminals, hackers, and nation states. A sought after speaker, writer, and technology pundit, his message is simple: secure and private systems are a requirement in today’s world, not a luxury.

Announcer: Hello, and welcome to Screaming in the Cloud with your host, Cloud Economist 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 by a personal favorite: Retool. Retool allows you to build fully functional tools for your business in hours, not days or weeks. No front end frameworks to figure out or access controls to manage; just ship the tools that will move your business forward fast. Okay, let's talk about what this really is. It's Visual Basic for interfaces. Say I needed a tool to, I don't know, assemble a whole bunch of links into a weekly sarcastic newsletter that I send to everyone. I can drag various components onto a canvas: buttons, checkboxes, tables, etc. Then I can wire all of those things up to queries with all kinds of different parameters, post, get, put, delete, etc. It all connects to virtually every database natively, or you can do what I did, and build a whole crap ton of lambda functions, shove them behind some API’s gateway and use that instead. It speaks MySQL, Postgres, Dynamo—not Route 53 in a notable oversight; but nothing's perfect. Any given component then lets me tell it which query to run when I invoke it. Then it lets me wire up all of those disparate APIs into sensible interfaces. And I don't know frontend; that's the most important part here: Retool is transformational for those of us who aren't front end types. It unlocks a capability I didn't have until I found this product. I honestly haven't been this enthusiastic about a tool for a long time. Sure they're sponsoring this, but I'm also a customer and a super happy one at that. Learn more and try it for free at retool.com/lastweekinaws. That's retool.com/lastweekinaws, and tell them Corey sent you because they are about to be hearing way more from me.

Corey: This episode is brought to you by Trend Micro Cloud One™. A security services platform for organizations building in the Cloud. I know you're thinking that that's a mouthful because it is, but what's easier to say? “I'm glad we have Trend Micro Cloud One™, a security services platform for organizations building in the Cloud,” or, “Hey, bad news. It's going to be a few more weeks. I kind of forgot about that security thing.” I thought so. Trend Micro Cloud One™ is an automated, flexible all-in-one solution that protects your workflows and containers with cloud-native security. Identify and resolve security issues earlier in the pipeline, and access your cloud environments sooner, with full visibility, so you can get back to what you do best, which is generally building great applications. Discover Trend Micro Cloud One™ a security services platform for organizations building in the Cloud. Whew. At trendmicro.com/screaming.

Corey: Welcome to Screaming in the Cloud. I'm Corey Quinn. I'm joined this week by Mark Nunnikhoven, currently a VP of cloud research at Trend Micro. Mark, welcome to the show.

Mark: Thanks, Corey. Long time listener, first time screamer.

Corey: Excellent. So, you work at Trend Micro, an antivirus company, which seems like a very hip and relevant thing for 1998. Now, it seems like, so, you're effectively you're the equivalent of John McAfee, only they didn't put your name on the company? And yes, I understand that comparing you to John McAfee may very well be nastiest thing anyone has ever said to you in your life?

Mark: Well, while my hair is as crazy as John McAfee is just generally, yeah, Trend definitely has that reputation. The good news is, and this may be eye-opening for the listeners, antivirus like it's 1998, that was old for Trend in 1998. Trend’s been around 31, 32 years now. Started with the early products like PC-cillin for those of you who have been around long enough. And now, anything that needs to be secured Trends got products or research that does it, whether that's in the Cloud—relevant, obviously, to this audience and to you and me—or smart cars, smart factories, anything like that. Really, really cool. But yeah, that company built its power base, its customer base on antivirus, and that’s still a big strong part of the business.

Corey: Which I wouldn't doubt. The problem, though, is that I remember using Trend Micro. It was a solid product. There was a lot of, to be honest, crap in that market, where the systems were worse than the problems that they were designed to prevent against, and I don't talk about this too often, but I used to be a help desk person turned windows admin. And at that point, dealing with antivirus was part and parcel. 

Now, credit where due, Trend Micro’s offering was great, but that's not really the marketing angle anyone wants to care about these days because, “Yeah, we were awesome 20 years ago,” is really much more on-brand for IBM than it is for companies that are still, you know, relevant.

Mark: Yeah, fair. Totally fair. And that's why at this point, I would say antivirus is probably the smallest portion of our business. One of the biggest, and growing by leaps and bounds, is actually helping cloud builders secure their deployments in the Cloud, whether that's servers and instances or all the way through to serverless architectures. So, the one thing about cybersecurity is you can't stay resting on your laurels. 

If you were good six months ago, that's not even as relevant as what do you have that viable today, and on top of that, the way I'd like to describe Trend, jokes aside, is really, we're a company that has a huge amount of knowledge around cybercrime, computer security in general, the products that the company sells are just a manifestation of that knowledge, and they're going to change constantly because technology is changing constantly. What doesn't change is that history and that continuing quest to keep learning more, to keep pushing more. And that's why, blissfully in my job, I'm on the research side, I don't really have to worry about the products too much.

Corey: Yeah, that's one of the nice things, I think, about working on the research side is, for better or worse, you are a VP. You're not going to get on a podcast like this and then immediately savage the company, nor should you. That says something about a person, none of it good. But I've never gotten a sense from you that you were there to push a narrative or a company line, and we've hung out in passing it an awful lot of various AWS events. Which I think leads me to my next question for you. You by all appearances are a very traditional looking security person. Why do you focus on Cloud?

Mark: Yeah, so I'm going to take that reference to traditional-looking because I've been dealing with the diversity angle when trying to help initiatives to get diversity in tech.

Corey: Well, you do have earrings, at least one of them—

Mark: I do—

Corey: —so—

Mark: —I have two.

Corey: —it’s clear you’re not a culture fit for IBM.

Mark: Sure. Though ironically, I worked for IBM, and at the time when I was a much, much younger man, I had, at that point, a multitude of piercings and tattoos while I was working for IBM in an externally facing role. So, I've toned it down as I've gotten older. But yeah, I'm a very traditional security person. My background and my training is in forensic investigation, I worked for the Canadian federal government for a decade working on nation state-level security stuff. 

And if you've said, “How do you get to be a security professional?” I think a lot of the stuff I've gone through and a lot of the certifications and training really fits there. But the reason why I've been focusing on Cloud for the last eight or nine years is because it's a huge opportunity to fix everything that is wrong with cybersecurity and information security, and there is a mountain of things that are wrong with the approach for security. Go no further than talking to any team in a large organization and ask them what they think of their security team, hopefully, you'll get a disclaimer about how they're nice people, but then you're just going to hear the complaints roll out about how they're grumpy, how it's the team that says no to everything, they slow everything down, they make things way more complicated than they need to be. And I get it, I understand how things got to that point because it's one of those baffling things where if you unravel it and look at each decision in turn, they make perfect sense. 

Back in the 90s, we used to have strong perimeters around everything, so everyone had a big, big firewall, and we used to use antivirus everywhere because that was the only tool we really had. And add up 30, 40 years of these kind of decisions, and you end up where we are now, where more often than not, security just sucks; it just slows people down when it doesn’t have to be that way. And we're starting to see that now that Cloud is far more mature than it was 10 years ago, you're seeing security really be an enabler, really push things forward—and I hate that word enabler, but it is accurate. Security's there to make sure that whatever you're trying to build does what you intend and only what you intend.

Corey: That's an incredibly nuanced and difficult thing to do in a world of Cloud. Again, this was never easy working in on-prem environments, but at that point, you at least knew, for example, the number of computers you had running in the building, give or take. Now, at the time of Cloud, it's not just understand in some ways. You have a bit of an unbounded growth problem, but you also have the things that are running today could behave in different ways tomorrow, not just in terms of performance, but in terms of capability of, “Hey, the provider has now launched additional aspect of functionality.” A classic security example of this is tag-based access control which you can do what IAM now. And that's awesome and exciting, and it's more than a little confusing, but remember that for 10 years or whatever it's been now, that was not the case. 

So, everything was set to be able to set tags with reckless abandon, it wasn't scoped, people were encouraged to do it, and now as soon as you wind up doing anything that's using tag-based access control, you wind up accidentally creating security risks out of every single one of those things that are out there, perhaps unknowing, perhaps not. But it used to be that the worst-case scenario for tags was someone could wind up changing allocation rules or fill your logs with garbage. That was about it. Now, “Oh, wow. There's security problems here.” It's a new world. That feels like one of the dark side sharp edges to the amazing capability story that is Cloud.

Mark: Yeah, absolutely. And that example, I think, is the prime example because it hits on a few things. Permissions are hard for a lot of people. So, one of the things I keep getting frustrated at and I keep talking to the AWS teams about—not to call them out specifically—but in IAM, in the Identity Access Management console, there's a bunch of managed policies, which are great. They help you get up and running, they help you figure out what permissions are linked to what actions, but there's a whole bunch of them that end in the two horrible words, “full access.” 

And while these are great for maybe a limited development environment, you should never see them in a production environment because I have yet to really honestly truly hit a case where a role or a user needed full access to a server or a service in production. So, that's a fundamental problem. Now you add tags on top of this, and like you said, for years, we've been adding them and using them primarily to route billing. And now you're saying, “Well, now you can accidentally grant production rights to somebody because the tag is wrong.” That is an absolutely significant challenge, and definitely, a downside. 

It actually came up in a discussion I was having with some development teams I was talking to today. They were discussing how they were leveraging the well-architected framework. They're just getting started with it, which is great. They're on their learning journey, but they were discussing it like it was a one-time thing. And they're saying, “Well, this is our architecture, and we've done a well-architected review. And we're good now.” And I brought up your exact point, which is, “Hey, wait a minute. You may be done with your architecture, but that's built in the Cloud, and you're using all of these different services, and those service providers are making changes, which then have implications to your architecture, whether that's security implications or not.” 

And that's a huge shift for development in the Cloud, but for security, it's one of those sort of brain breaking things where you go in the traditional model, we used to love to put our arms around it and go, “This is mine, I can protect it. I know where the boundaries are.” And that is fundamentally the history of cybersecurity. “I can put my arms around it, I can protect it. I'm good,” even though that's just sort of a false belief that a lot of people live with to make it easier to sleep at night. 

When you're in the Cloud, yeah, you don't know what your environment looks like now versus 20 minutes from now, if you start to see a surge in traffic and things scale. And then the advantage of having all of these new features come out from your cloud provider is that they also potentially do open up these avenues, like with the tag example.

Corey: That is one of the best aspirational descriptions of cloud, the idea that the entire environment is highly dynamic, however—and maybe this is biased by the customers that I tend to work with—very often, that's not the case. I take a look at the big, expensive environments, and it's always stuff that was provisioned in 2016 or earlier. It's a lot less dynamic than people often believe that it's going to be. And that's not, incidentally, just an artifact of large accounts. I've been dealing with a lot of legacy cruft in my AWS account that I launched four years ago, and it's all serverless stuff, but I have a whole bunch of roles, I have lambda functions now using deprecated runtimes, that do ridiculous things I don't understand. 

I have a series of escalating challenges in that account where at some point, I want to burn it from orbit and start over, but that's kind of hard to do, and there's still library management problems and the rest. I'm spinning up new accounts constantly, like I work at Wells Fargo. It's awful. That stuff always accumulates in accounts, and fundamentally, no one understands it. I'm the only person that builds stuff in this [era’s] account and I still don't understand what all of the moving parts are. And look at how much time I spend on this stuff.

Mark: Yeah. Hundred percent. The challenge and the balance I always have is ‘nerd me’ is like, “Look at all the possibilities. Look at the amazing, crazy autonomous self-healing deployments that we can make.” This stuff is great. More pragmatic, older ‘I’ve seen some things’ me is exactly what you said. There's legacy, people are slow-moving in general, the vast majority of cloud usage is not the cool stuff. 

So, Cloud generally suffers from the same thing that security does from its public image in the respect that if you look at security conferences, 99.9 percent of the material is about the latest zero-day vulnerability and exploit; it's about the latest cool hack. The reality of cybersecurity is that you spend your day worrying about patching threat assessments, a whole bunch of stuff that's never talked about publicly. The same challenge exists in Cloud is that if you look at what happens at conferences, whether they're physical or virtual, all the latest blog posts, a lot of this stuff is like, “Look at this cool stuff you can do on the cutting edge.” It's not, “This is the reality that you have a business app that's working, and there's no way your boss is ever going to let you completely rebuild it from the ground up to make it just do the exact same thing, but in a better way because at the end of the day, it's doing what you need it to do.” 

So, the reality is very, very messy. But I think the possibility is there. The biggest challenge is the lack of tooling in general, not just for development, but tooling in general, to help people shift their mental model. And this is one of the unfortunate things that I see every year at re:Invent—not to call re:Invent out, it just happens to be the biggest single source of announcements—is that a lot of those announcements—

Corey: You’re telling me.

Mark: Yeah, exactly. I mean, you probably burned through a keyboard in November alone. And the challenge is, is that a lot of those new service announcements are stuff that are designed to help people bridge that gap and to get more cloud-y in their thinking, but not pushing cloud forward. And it's the Cloud coming back to bring them along, which is a very good thing, but also a lot of the time reinforces some of these older mental models, these older approaches because you're very right, in the Cloud deployments are not nearly as dynamic as they could be, and I think that's not a lack of the Cloud backing or the services not being able to do that, it's the people can't think that way. It's like, if you sit a programmer down and go, “Okay, write me a script that does XYZ.” And then if you tell them to do the same kind of thing across multiple threads, people's brains don't work in multi-threading mode, they work in, sort of, just serial mode, one after the other. And while parallelizing everything would be better for a lot of cases, it's just not how our brains work. And that's the same thing that we see in Cloud.

Corey: We talk about Cloud a fair bit, but let's make it a bit more specific. In addition to your apparently easy, minor day job as a VP at a major company, you also are an AWS Community Hero, which I interpret to mean that you looked at the vast landscape of what causes you could volunteer for, and picked a trillion-dollar company. What's that about? What's it like? What do you do?

Mark: [laughs]. Yeah, so the Hero program’s been going for a number of years now. I've been in it for a while, and it's basically some folks within Amazon, recognize what you're doing out in the community or in a specific technology stack—so there's Serverless Heroes, Machine Learning Heroes, Data Heroes, that type of thing—and it's just an extra recognition from AWS. The advantage for us as Heroes is it gives us some opportunity to speak at AWS events, to publish on AWS properties, but also to get access, and to give feedback to the product teams a little more frequently than the customers normally do. So, it's a nice little recognition; it feels good to see that the efforts for me specifically was based on a lot of speaking that I'm doing, a lot of community outreach to help people understand security, it's a nice recognition there. 

But yeah, volunteering for a trillion-dollar company is not a totally incorrect way, but the good news for me is that's in addition to volunteering to run the youth basketball, and scouting, and stuff like that. But yeah, it's a good program. It gives us some of the insights that you get a glimpse of being a prominent influencer, so that when you speak people listen. The Heroes program is a little bit of that endorsement for the company itself.

Corey: That’s, I think, a fair way to say it. One of the areas that I found the Hero program to be incredibly useful from my perspective—again, I am not a Hero for reasons that should be blindingly obvious. I have never been invited to be an AWS Hero because, let's not kid ourselves here, Amazon hires smart people who can read the room, but I've also only ever interacted with folks on the periphery of it. But one of the values that I find coming out of the Hero program is the fact that it helps me contextualize what a release means in a different context. Because the Heroes don't work for Amazon. There have been a few people who are no longer Heroes because they took jobs at AWS. At least one other is no longer a Hero because they took a job at Microsoft, but that's a different problem. 

And I see that this is a group of people who are not beholden to AWS for anything other than a bit of publicity, so if AWS does something egregious, they're in a much better position to sound off about it, or highlight things that may not make much sense. At least it feels to me like there's not any constraint on saying things because you don't work there; what are they going to do, take away your birthday? You can say what you think. And through that lens, I find that the stories that come out of the Hero program are a lot more authentic, for one, and also a lot more bounded to use-cases you might find in companies that aren't either Amazon or their specific target customer case studies. Would you agree with that?

Mark: Yeah, I think that's accurate. I think what you're saying there in a very eloquent way is that the Heroes tend to provide a little more perspective. So, I'll give you a very pragmatic or very practical example, every year for re:Invent, registration is a disaster. Trying to get a reserved seat in a session is always frustrating because the third party app goes down, and people who paid good money to go to this conference to see good content, have a really hard time getting into those talks, and that's frustrating for absolutely everybody, AWS included. As part of the Hero program, I think three years ago, they actually briefed us all ahead of time because they said, “Listen, we know you guys are looped in on a bunch of social media posts, and people getting really frustrated. Here's what we've done behind the scenes. Here's what we're trying to do to make things whole.” 

And they actually gave us a contact during the week of re:Invent as well to make it easier to answer community people's questions. So, they said, “Look, we know you're going to give the best answer you can if somebody is asking for some help, but here's how you guys can make that simpler for everybody, and here's a direct line into somebody on the events team who can handle that.” But I think for me, that was a good thing in that they didn't tell any of us to stop complaining about broken sessions and registration, they just said, here's how we're trying to help. And that rolls out to services, you'll see that Heroes are not necessarily going to be disparaging the company or taking it down, but we’ll speak our mind, too. So, for me personally, Amazon Neptune, the unheard-of one of many data stores—

Corey: Yes, their giraffe database, named after giraffes, which are of course themselves made-up animals that don't really exist.

Mark: Fair. Totally fair. Because what sound does a giraffe make? Nobody can tell me.

Corey: Exactly.

Mark: So, for Neptune: great service, super cool possibility, and totally wasted for a huge amount of customers because it's traditional spin up an instance and pick out your capacity, no serverless capability in it whatsoever where having a graph database, fully serverless, would have been amazing. And that's a frustration, so I mentioned that when it was launched, I mentioned that a few times before. So, there's definitely that context, and I think the advantage for the Heroes not being employed by AWS, but also having sort of the insider track on some AWS stuff is when new services get released, most of the time, we've either used them already or had a chance to provide feedback and help shape them, so we can help people understand the better context because that continues to be sort of a weak spot. When a service comes out, everybody looks at it through their own lens and goes, “This solves my problem.” And it's like, “Yeah, probably not, but here's the problem it does solve.” 

And then it also, like you said, shows those additional use cases. So, from the Heroes, you're going to see here's how you can build serverless applications using Auth0 instead of trying to shoehorn something into Cognito. Here's how you can leverage DynamoDB while doing your compute in GCP. That kind of stuff because we're not restricted, and I think—not to speak for every Hero, but I'll speak for every Hero—we're just trying to help people because we find this stuff interesting, and we just like to help people.

Corey: In what you might be forgiven for mistaking for a blast from the past, today I want to talk about New Relic. They seem to be a relatively legacy monitoring company, and I would have agreed with that assessment up until relatively recently. But they did something a little out there: they reworked everything. They went open source, they made it so you can monitor your whole stack in one place and, most notably from my perspective, they simplified their pricing into something that is much more affordable for almost everyone. There's even a free tier with one user and 100 gigs per month, totally free. Check it out at newrelic.com.

Corey: One of the common threads that I see with the Heroes that I've dealt with has always been a willingness to help others. It's not about, “Look at how awesome I am,” It's, “Let me help lift other people up and teach people things,” and they do this on a volunteer basis, in all seriousness, which makes the naming of it, in typical Amazon fashion, terrible. If you call someone an MVP at Microsoft, that tends to be something that you can self-describe: when you're elected MVP for a game, you can say that; it's on your resume. When you call yourself a Hero though, it always feels weird, at least in the common baseline, English language perspective. It's like ‘entrepreneur.’ it's one of those things other people call you far more than it is something that you call yourself. If you say, “That person's a Hero,” then yeah, you feel good; that person did something great. When someone says, “I'm a Hero.” Oh my God, this person is so full of themselves, I can only assume they're a venture capitalist.

Mark: Yeah, so I'm just thinking in the back of my head. Did I use the word Hero in my own intro when this started? I hope not.

Corey: You did not. I was listening for it—

Mark: Okay. [laughs].

Corey: —because I would have needled you. Instead, I had to go to my fallback, and needle you about your employer instead.

Mark: Fair.

Corey: Aren’t you glad you went that way?

Mark: Iffy. Depends what my boss says when he hears this. I agree, and Hero is a loaded word. I actually liked, or preferred—in Australia, there is a smaller regional program that's somewhat similar, that's the ‘Cloud Champions’ and that was a little more straightforward I think because these are people in the country who champion cloud usage and cloud technologies. And I thought that was simpler and easier to describe because I've been in a number of channels and outlets like the How to re:Invent series that AWS runs, and a few other venues, trying to explain the Hero program, and it the explanation of what we do is pretty straightforward but using the word Hero is uncomfortable because especially what goes on in the world on any given day, to call somebody who likes to teach people technology a Hero, I think that's a stretch, but I do very much like the program.

Corey: Especially during a time of pandemic where you have people literally risking their lives to bring you groceries, for example, and you look around it's like, “What do you do?” “I'm a Hero.” It rings a little hollow I guess is probably the best way to put it. I do love what they're doing in other geographical locations in AWS. They have a similar program I believe called Cloud Warriors, which just sounds incredibly badass.

Mark: Yes, for sure. But then I think the problem with warriors is you get this mental image, and then if I come on camera, you're like, “Oh, I didn't know it was nerd warriors. Not what I was expecting.”

Corey: Oh, yeah, in my case, that's all about fitness is really what I'm about, namely fitness entire burrito in my mouth.

Mark: You got it.

Corey: So, we've talked a bit about AWS, but what do you focus on? Do you spend time with the other cloud providers, specifically GCP and Azure—when we say cloud, that's generally what we're referring to—or are you more of an AWS focused person?

Mark: Yeah, I actually split my time among all three. The AWS designation and the reference point tends to go just to market share, and also the fact that they were first out so I've had the longest working relationship with them, but from Trend Micro’s perspective, we're officially partners with all three, and I've been involved since the beginning of all those, but just as a technologist I enjoy working with all three. They all have their ups and downs, but when I generally talk publicly about Cloud, it's Azure, GCP, and AWS.

Corey: So, you're in a great position to wind up answering this in a probably more objective fashion than I do, given the fact that my entire business revolves specifically around AWS. Compare and contrast the big three: what do you like, what do you hate about each of them? Superlatives, I guess. Go.

Mark: Nice. GCP, I think from a technology perspective, once you get your head around it, I like the basic structure. So, as a security guy, the fact that you need to turn everything on explicitly is a big win for me. Their project focus—as opposed to account focus—makes it a lot easier to implement some interesting boundaries. I also like the way that things like virtual machines are just sliders. Yes, they have templates for instance sizes in AWS, but it's easy to just say give me more CPU, give me less RAM, that kind of stuff. So very cool there. What I don't like about GCP is, when you're accessing it through the SDKs, you need to be Google-y. If you are not Google-y, it is going to be a very frustrating time. So, I do a lot of work in Python, the GCP Python SDK is the most un-Pythonic thing I have seen. It is tough to wrap your head around that, but once you realize it's really just all Java and Go primitives wrapped in Python, it works okay.

For Azure, I think the breadth of services are great. There's some really interesting things like Cosmos DB, which is trying to be all DBs to all people. Not quite getting there, but more than anything, I find the interesting balance where especially GitHub being under the Microsoft umbrella, there's a big merging happening there with some of the online coding tools that are happening in GitHub. So, I think there's some really good dev tooling in Azure. That being said, what the heck is Azure DevOps? Like, you can't take a philosophy and make it a service. That's not even really one thing, but combining thing among a bunch of other services. Really challenging there, very Microsoft-y. Same with the SDK for them. You better like having extra attributes for no reason in your properties just because that's the way they do it.

For AWS, it's the beast in the room, for sure. Very good at what they do. The biggest challenge I think, for AWS is trying to figure out what service at this point; there's just so many of them. But then also because of their rapid iteration in services, if you don't have the exact use case for a service when it comes out, it gets really frustrating really quickly because you see what it could be, and it will get there in a year or two, but not out of the gate, so whether or not you push through—and then I think lining up with with your opinion that you're never shy about, all three of them have a really, really hard time naming things.

Corey: I have noticed that, and I can't believe I'm going to say this out loud, but I have a sympathy for that problem because it turns out that it is way easier by four orders of magnitude to make fun of a name than it is to come up with a good one. I mean, for God's sake, my first version of this company was the Quinn Advisory Group. And it took us two weeks to come up with that.

Mark: Yeah. Yeah, it is hard, for sure—

Corey: Names are super hard.

Mark: —the challenge ends up being consistency. So, you look at AWS, and half of them seem to be named as nicknames, some of them are named very deliberately in what they do, others, you know, the whole AWS versus Amazon thing is just… okay. And then in GCP, it's better than their public-facing Google Meets, meet on Google, Google Hangouts, hang in a Google Meet, meet up in a Google Hang product fiasco, but it's not much better. And then Azure is actually surprisingly direct with the exception of the DevOps stuff. But again every once in a while, something more aspirational like Cosmos sneaks in. But at least they shoved a DB in there to make it make a little bit more sense.

Corey: You're absolutely right. And one thing that I think is happening is that, on some level, the folks using Azure and the folks using AWS—on the typical customer side of things, not necessarily the partners, or the folks that interoperate between the two—there tend to be almost two camps that don't talk very often. And when I started playing around with Azure, I find some things to be actively impressive about—same story with GCP as well. And it sounds kind of weird, but I mean, the best analogy I've got is when I learned French, I found that I understood English a lot better as a result. When I learned about Azure or GCP, I find that I start to understand concepts about AWS more effectively as well. For example, I still maintain one of the absolute best descriptions of what a lot of what AWS services are, are Microsoft's list of analogies and comparisons, were just lists a bunch of AWS services, the Azure competitor, and then—and this is critical—it describes what each one of those services does. And wow, how come AWS marketing hasn't gotten in front of this?

Mark: Yeah, [French]. The end of the day, as much as we poke fun at the naming, does the service work is really the key thing. But what frustrates me on the naming, you know, and again, I was having a discussion last week with some development teams, where they were having this revelatory experience because they found a service that addressed their need in one of these clouds. And I just kind of stepped back and went, wait a minute, that service has been out for, like, four years. But because of the name, it never clicked into them what problem it actually solved. 

So, they were trying a couple different workarounds, looking down different avenues, and then when they found this, they were like, “Wow, it's super easy. I just had to click a button, create the primitive in the service, and I'm done.” And that's where the naming thing—besides just being a fun pastime to poke fun at the names—that's where it really frustrated when it's hindering somebody to solve a problem because they don't understand at first glance what this thing does. That's a serious issue.

Corey: It is. And I also take that a step further. Some people think I focus too much on names, and they may be right, but the more I make fun of cloud services, and the more opportunities I have—let's call it that—to speak to the teams that are building these services, and when you start tying a human face to these things, you develop—at least I develop—a sense of sympathy because it's hard to build these things; no one claims otherwise. And the challenge, as a result, is I don't want someone to release a new feature that they've been working on for months or years, and the first thing that happens I make fun of it. But no one spent 18 months naming Systems Manager Session Manager, and if they did, they should feel bad. 

So, names are a safe thing, and another secret angle to that as well is you don't need to have 10 years of experience as an infrastructure engineer to appreciate a joke about a bad service name, whereas if I can start making esoteric references to XML as applied to the S3 API, yes, I can: you’ll want me to absolutely wash my mouth out with SOAP after that one. Those kinds of jokes are not going to be nearly as accessible, and it feels like it's inside jokes among friends. And that's never as engaging, and it acts as a gatekeeping aspect more than it is about building a bridge towards inclusivity.

Mark: Yeah, and I think there's another angle to that as well. I think using a joke to break down that barrier to be more inclusive also dispels the myth that cloud services are for the wizard on the hill, that you need this crazy level, that you need to be an expert before you just start experimenting and trying things. And that's one of the things that I think is amazing about Cloud is that you can just sort of stumble out of the gates, and have something working, and see the fruits of your labor. I spend a lot of time, especially now during the pandemic, looking at and helping kids learn to code. And one of the things that I find out amazing now vs way, way, way back when I learned was that there's a lot of tools, and kits, and toys that have a physical aspect that links to the digital so that kids are manipulating something physical with their code or with their hands, and it's changing the code. 

So, there's a linkage there that makes it easier to understand. And I think there's a parallel there to being able to make fun of some of these names that some of them are, they're fine, it's okay, but it's still fun to make fun of others, like System Manager Session Manager, that deserves to be shredded to the ground every chance we get, but it does make it a little more accessible as part of that inclusivity. It kind of demystifies them a bit to say, “Yes we're joking around about this stuff.” It's not only, “I need to be doing serious work with this stuff.” 

You can be having fun with it, which is where we see a lot of work around Alexa skills. There's a mountain of them that aren't ever going to be run more than once, but there's a lot of just little fun stuff that people use as an entry-level to start learning how to code, to start learning how to take advantage of cloud services, and that I think is really, really important because I don't think enough people experiment with technology and playing around with it not only just for the career-wise, but we're surrounded by this stuff. The more we understand it, and demystify it and make sure that it does break, but we can fix it. I think that's a win for everybody.

Corey: And I think that that's really what this comes down to. And I've seen that trend in the AWS ecosystem by itself, but I see it across the others as well, where once upon a time when EC2 first came out, you basically needed a doctorate to get it up and running. There was an entire cottage industry of companies like RightScale that made that interface something a human being could use. Over time, it's become more broadly accessible. 

Look at things like Lightsail. You don't need to know much about anything within AWS’s very vast umbrella to get started with that. And we're seeing it now move even further up the stack in other arenas, too. I'm excited to see what the next five years hold in that context. The idea of low-code and no-code movements and that type of engagement means that suddenly you can have a business idea and not have to go spend the next few years learning how computers work in order to enable some of that.

Mark: Yeah, and that's where I think Azure, may be the dark horse, especially with GitHub being under the umbrella, but as much as—

Corey: Microsoft gets developers, credit where due.

Mark: This is the thing. As much as I like to go at Microsoft, they have a long history of enabling development for outside of the traditional IT umbrella. So, Visual Basic, huge win. In the early windows days, you could throw a couple buttons on a form, double-click on it, and write a tiny bit of code that you could, you know—not Google at that point because Google wasn't a thing, but you could read through the Docs or kind of stumble your way through, and you had a working Windows application. You didn't know anything about the Win32 Library set, you didn't know anything about how this worked under the covers, but there was. You typed in something in your text box, you clicked a button, and it took an action. 

And I think we're starting to come back around to that with cloud services. We're seeing more and more of that in the data stack on Google, where Bigtable BigQuery, just shove a whole bunch of data in here, it's going to make some intelligent decisions, and then you can single-click or drag and drop things to get some really interesting business results out of that, and that's a huge win. Anything we can do to make it easier for non-technical people, or non-deeply-technical people, the better off we are. So, if we go back to our earlier part of our conversation, people like the AWS Heroes, people like yourself, people who are interested and really immersed in this stuff, we're going to figure it out no matter what. We can wade through the documentation, we can look at the mountains and mountains of bad JavaScript code and eventually make sense of something. But that's not who we need to worry about. It's a similar challenge we have in security is where we've made security this obscure art when really it's just one concern of many of everybody who's building technology, and we need to make that more accessible just like we need to make building the technology more accessible.

Corey: I don’t think that I've ever regretted making things accessible to a broader audience. One of the early versions of my “Terrible Ideas in Git” talk was aimed at inside baseball on Git developers. And yes, I had to learn how to Git worked before I could give that talk. And the three people who understood that in the audience thought it was great, and the rest didn't know what the hell I was banging on about. By instead turning it into something that was this is what Git is, and this is what it does, and here's how to use it by not using it properly, is fun, it's engaging, but it means that you don't have a baseline level of you must already have X level of experience in order to begin using this new and exciting capability. And that is the biggest challenge for all of the cloud providers from where I sit. And it sounds like I'm not alone, from what you have to say.

Mark: Yeah, I a hundred percent agree with that. And we're seeing it get better and better, with better interfaces, a better understanding that as far as—yes we need API first, but that also has a big assumption of technical level. If you're saying here, you can only interact with it via an API. But I have a similar experience. Last year—so 2019—one of the talks I gave at several of the AWS summits was about advanced security automations made simple, and it was targeted not at security people, but at developers. 

And the whole idea was breaking down this myth that cybersecurity was super hard, and it was something that they had to hand off to another team, and it was just showing them, “Look, this is the basic thing. There's a whole bunch of big language around this that doesn't mean anything. Here's what you're trying to accomplish. You're trying to make sure that if you write a function that creates a TPS report, it can only print TPS reports, and not HR, or finance, or inventory reports.” Which I always say because no one knows what a TPS report actually contains, so I just randomly name other things that it shouldn't be doing, and nobody's ever called me on it so I keep getting away with it.

But the concept comes across pretty crystal clear for developers or people who are building something is that I want this to be an apple, and if it is an orange, that is bad. And that's really just cybersecurity in a nutshell. But I don't think many people present it that way. So, as far as making this more approachable—which may be a better word than accessible—more approachable, easier to understand, that's a huge thing for me personally, with security, with privacy, but with cloud in general. And I think the advantage—early in our conversation, we talked about environments not being nearly as dynamic as they could be, or as that we think they are, and I think a lot of that comes down to this tooling and that approachability. 

Once we get there, and we make it super easy for somebody not to worry, that's really going to pay off. I saw that this week. I was doing a virtual meetup for Cloud Security London, and they had deployed a polling app, like an open-source Kahoot! And it was interesting because the cloud security meetup is run by twin brothers, one works for AWS and one works for Azure, and the third brother is not—

Corey: Thanksgiving dinner has got to be awkward.

Mark: It gets worse. The third brother, who's not a twin, is a .NET developer who works for AWS. It's a complicated relationship, to say the least.

Corey: And an NDA violation waiting to happen.

Mark: Oh, massively so. I'm sure even just the recipe for the yams at Thanksgiving is probably under one or more NDAs. But they deployed this open-source version of Kahoot! which was this multithreaded sort of polling app, and the nice thing is that they didn't have to know, even though these are really technical folks, they didn't have to know the ins and outs of it. The tooling was simple enough that they actually just ran one script—in this case, I think it was a Terraform—that deployed the whole thing for them, and it worked. 

And to think about what actually happened behind the scenes is now you have a-real-time highly scalable, dynamic audience polling system in place after just running one command was pretty amazing. And I think that possibility is extremely exciting. We just need to continue to relentlessly chip away at the barriers to make it more and more approachable.

Corey: That's, I think probably the best place to leave this. If people want to hear more about what you have to say, where can they find you?

Mark: You can find me on social @marknca, M-A-R-K-N-C-A, or at my website, Markn.ca, as in Canada because that's where I'm at.

Corey: And we will of course throw links to that into the show notes. Mark, thank you so much for taking the time to speak with me today. I really appreciate it.

Mark: Thank you. I appreciate the opportunity.

Corey: Mark, Nunnikhoven, vice president of cloud and research at Trend Micro.k I am Cloud Economist Corey Quinn, and this is Screaming in the Cloud. If you've enjoyed this podcast, please leave a five-star review on Apple Podcasts, whereas if you hated this podcast, please leave a five-star review on Apple Podcasts anyway, along with a comment after you update your antivirus software.

Announcer: This has been this week’s episode of Screaming in the Cloud. You can also find more Corey at ScreamingintheCloud.com, or wherever fine snark is sold.

This has been a HumblePod production. Stay humble.