Screaming in the Cloud - Making the Cloud More Secure with Mark Nunnikhoven

Episode Date: September 10, 2020

About Mark NunnikhovenIs 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.Links Referenced: Trend Micro: https://trendmicro.com/Twitter: https://twitter.com/markncaMark’s website: https://markn.ca/ 

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 tools. It'll 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 front-end. 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 slash lastweekinaws. That's retool.com slash lastweekinaws. That's retool.com slash lastweekinaws and tell them Corey sent you because they are about to be hearing way more from me. 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 gonna be a few more weeks, I kinda 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 environment 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 at trendmicro.com slash screaming. Welcome to Screaming in the Cloud. I'm Corey Quinn. I'm joined this week by Mark Nunnikovan,

currently a VP of cloud research at Trend Micro. Mark, welcome to the show. Thanks, Corey. A longtime listener, first-time screamer. 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 what? 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 the nastiest thing anyone has ever said to you in your life. Well, while my hair is as crazy as John McAfee is just generally, yeah, you know,

Trend definitely has that reputation. The good news is, and this may be, you know, 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 Sillin, for those of you who've been around long enough. And now anything that needs to be secured, Trend's got products or research that does it. Whether that's in the cloud, relevant to obviously to this audience and to you and me, or smart cars, smart factories, anything like that. Really, really cool. But yeah, the company built its power base, its customer base on antivirus, and that's still a big, strong part of the business. 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 would be 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. 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 it's, you know, 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, you know, what do you have that's viable today? And on top of that, you know, the way I like to describe Trend, describe Trend, jokes aside, is really we're a company that has a huge amount of knowledge around cyber crime, computer security in general. The products that the company sells are just a manifestation of that knowledge, and they're gonna change constantly because technology's 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. 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, you know, 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 at 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? Yeah, so I'm going to take that reference to traditional looking because I've been dealing with the diversity angle when, you know, trying to help initiatives to get diversity. You do have earrings, at least one. I do. So it's clear you're not a culture fit for IBM. Sure. Though, ironically, I worked for IBM. And at the time when I was a young,

much, much younger man, I had at that point a multitude of piercings and tattoos while I was a young, 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, you know, if you've said like, 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, you know, it's one of those baffling things where if you unravel it and look at each decision in turn, they make perfect sense. You know, back in the 90s, we used to have to have strong perimeters around everything. So everyone had a big, big firewall, right? And we used to use

antivirus everywhere because that was the only tool we really had. And, you know, 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 is there to make sure that whatever you're trying to build does what you intend and only what you intend.

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 in a time of cloud, it's not just understanding that 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 an additional aspect of functionality. A classic security example of this is tag-based access control, which you can do with 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 scope. 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. 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 and 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, you know, 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 like, this is mine. I can protect it. I know where the boundaries are. And that is fundamentally the history of cybersecurity, right? I can put my arms is mine. I can protect it. I know where the boundaries are. And that is fundamentally the history of cybersecurity, right? I can put my arms around it. I can protect it. I'm good. Even though, you know, 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, you know, 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. 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 a 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 built 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. Yeah. A 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, you know, autonomous self-healing deployments that we can make. Like this stuff is great. More pragmatic, older. I've seen some things. Me is, you know, exactly what you said is 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% 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 reInvent, not to call reInvent out, it just happens to be the biggest single source of announcements, is that a lot of those announcements... You're telling me. Yeah, exactly, right? I mean, you probably burned through a keyboard in November alone, right? And the challenge is that a lot of those new service announcements are stuff that are designed to help people bridge that gap and to get more cloudy 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 X, Y, Z. 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. We talk about cloud a fair bit, but let's make it a bit more specific. In addition to your, you know, apparently easy minor day job as a VP at a major company, you also are a 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?

Yeah, so the Hero program has 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 right to the product teams a little more frequently than the customers normally do. So it's a nice little recognition. You know, 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, you know, 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. 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, and 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? Yeah, I think that's accurate. I think, you know, what you're saying there in a very eloquent way is that, you know, the heroes tend to provide a little more perspective. So I'll give you a very pragmatic or very practical

example. Every year for reInvent, registration's a disaster, right? 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 of 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 reInvent 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's 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, you know, 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, you know, we'll speak our mind, too. So for me personally, Amazon Neptune, the unheard of one of many data stores. Yes, their giraffe database named after giraffes, which are, of course, themselves made up animals that don't really exist. Fair, totally fair, because what sound does a giraffe make? Nobody can tell me. Exactly. because what sound does a giraffe make? Nobody can tell me, right? So for Neptune, great service, super cool possibility and totally wasted for a huge amount of customers because it's traditional spin-up in 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 you know it also like you said shows those additional use cases so from the heroes you're going to see like here's how you can build serverless applications using auth zero instead of trying to shoehorn something into like, 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, you know, 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. 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. 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, oh 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. 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. I was listening for it because I would have needled you instead. I had to go to my fallback and needle you about your employer instead. Aren't you glad you went that way? 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's 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 Reinvent series that AWS runs and a few other venues trying to explain the hero program. And 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. 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 geographic locations at AWS. They have a similar program, I believe, called Cloud Warriors, which just sounds incredibly badass. 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. Oh, yeah. In my case, that's all about fitness is really what I'm about, namely fitness entire burrito in my mouth.

You got it. 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? 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 threes. They all have their ups and downs. But when I generally talk publicly about cloud, it's Azure, GCP, and AWS. 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. 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 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 programming, when you're accessing it through the SDKs, you need to be googly. If you are not googly, 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 a combining thing among a bunch of other services. Really challenging there. Very Microsofty. 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, you know, aligning up with your opinion that you're never shy about, all three of them have a really, really hard time naming things. 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. Yeah. Yeah. It is hard for sure. Names are super hard. You know, 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 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. 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've 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 learn 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. This is 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? Yeah, you know, certain amounts, Is that correct? At 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, you know, a couple of 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, you know, create the primitive in the service and I'm done. And that's where the naming thing, you know, besides just being a fun pastime to poke fun at the names, that's where it really frustrated me. 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. It is. And I also take it 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, 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 as 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. Yeah, and I think there's another angle to that as well. I think, you know, 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, right? Like 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 amazing now versus 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, you know, some of them are they're fine. It's OK, but it's still fun to make fun of others like system manager, session manager like 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 like, yes, you know, we're joking around with this stuff. It's not only, you know, 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.

And I think that that's really what this comes down to. And I've seen that trend 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. Yeah. And that's where I think, you know,

Azure may be the dark horse, especially with GitHub being under the umbrella. But, you know, as much as Microsoft gets developers credit where due. 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, right? 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 it 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. You know, we're seeing more and more of that in the data stack on Google, where big table, big query to shove a whole bunch of data in here. It's going to make some intelligent decisions. And then you can, you know, 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, you know, 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, right? 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. You know, and 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. 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 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. Yeah, I 100% 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 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 like,

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, you know, 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, you know, 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, you know, 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 meetup, 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... Thanksgiving dinner has got to be awkward. 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. And an NDA violation waiting to happen.

Oh, massively so, right? 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 multi-threaded sort of polling app. And the nice thing was, 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. 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? You can find me on social at MarkNCA, M-A-R-K-N-C-A, or at my website, MarkN.ca, as in Canada, because that's where I'm at. 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. Thank you. I appreciate the opportunity. Mark Nunnikovan, Vice President of Cloud and Research at Trend Micro. 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've hated this podcast,

please leave a five-star review on Apple Podcasts anyway, along with a comment after you update your antivirus software. 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.