Screaming in the Cloud - Enterprise Developer Advocacy with Maish Saidel-Keesing

Episode Date: July 5, 2022

About MaishMaish Saidel-Keesing is a Senior Enterprise Developer Advocate @AWS working on containers and has been working in IT for the past 20 years and with a stronger focus on cloud and automation for the past 7.He has extensive experience with AWS Cloud technologies, DevOps and Agile practices and implementations, containers, Kubernetes, virtualization, and a number of fun things he has done along the wayHe is constantly trying to bridge the gap between Developers and Operators to allow all of us provide a better service for our customers (and not wake up from pages in the middle of the night). He is an avid practitioner of dissolving silos - educating Ops how to code and explaining to Devs what the hell is OperationsLinks Referenced:@maishsk: https://twitter.com/maishskduckbillgroup.com: https://duckbillgroup.com

Hello, and welcome to Screaming in the Cloud, with your host, Chief Cloud Economist at the Duckbill Group, Corey Quinn. This weekly show features conversations with people doing interesting work in the world of cloud, thoughtful commentary on the state of the technical world, and ridiculous titles for which Corey refuses to apologize. This is Screaming in the Cloud. This episode is sponsored in part by our friends at Fortinet. Fortinet's partnership with AWS is a better together combination that ensures your workloads on AWS

are protected by best-in-class security solutions powered by comprehensive threat intelligence and more than 20 years of cybersecurity experience. Integrations with key AWS services simplify security management, ensure full visibility across environments, and provide broad protection across your workloads and applications. Visit them at AWS Reinforce to see the latest trends in cybersecurity on July 25th to 26th at the Boston Convention Center. Just go over to the Fortinet booth and tell them Corey Quinn sent you and watch for the flinch. My thanks again to my friends at Fortinet. Let's face it, on-call firefighting at 2 a.m. is stressful. So there's good news and there's bad news.

The bad news is that you probably can't prevent incidents from happening, but the good news is that Incident.io makes incidents less stressful and a lot more valuable. Incident.io is a Slack-native incident management platform. It allows you to automate incident processes, focus on fixing the issues, and learn from incident insights to improve site reliability and fix your vulnerabilities. Try incident.io to recover faster and sleep more. Welcome to Screaming in the Cloud. I'm Corey Quinn. I'm a cloud economist at the Duckbill Group, and that was a fun thing for me to become because when you're starting to set out to solve a problem, well, what do you call yourself? I find that if you create a job title for yourself,

well, no one knows quite how to categorize you, and it leads to really interesting outcomes as a result. My guest today did something very similar. Mesh Seidel-Casing is an Entreloper, or Enterprise Developer Advocate, specifically for container services at AWS. Mesh, thank you for joining me. Thank you for having me on the show, Corey. It's great to be here. So how did you wind up taking a whole bunch of words such as enterprise developer advocate, because I feel like the way you really express seniority at big companies, almost as a play of dominance, is to have additional words in your job title, which all those words are very enterprise-y, very business-y, and very serious.

And in container services, to boot, which is a somewhat interesting culture, just looking at the enterprise adoption of the pattern. And then at AWS, whose entire sense of humor can be distilled down into, that's not funny. You have the flexibility to refer to yourself as an entreloper in public. I love it. Is it just something you started doing? Was there like 18 forms of approval you had to go through to do it? How did this happen? I love it. So no, I didn't have to go through approval, of course, same way you didn't call yourself a cloud economist with anybody else's approval. But I got the idea mostly from you because I love your term of coining everybody who's in developer advocacy or developer relations as a developer. And specifically, the reason that I coined the

term of an entreloper and actually looked it up on Google to see if anybody had actually used that term before and no, they haven't, is the fact of I came into the position on the premise of trying to bring the enterprise voice of the customer into developer advocacy. When we speak about developer advocates today, most of them are the people who are the small startups, developers who write the code. And we kind of forget that there is a whole big world outside of, besides small startups, which are these big, massive behemoths of enterprise companies, who kind of do things differently because they've been around for many, many years. They have many, many silos inside the organizations. And it's not the most simple thing to open up your laptop and install whatever software you want on because some of these people don't even give you admin rights on your laptop. Or you're allowed to SSH out to a computer in the cloud because also the same thing. Everything is blocked by corporate firewalls where you have to put in a ticket in order

to get access to the outside world. I worked in companies like that when I was before I moved to Amazon. So I want to bring that perspective to the table on behalf of our customers. Bias is a very funny thing. I spent the overwhelming majority of my career in small environments like you describe. To me, a big company is one that has 200 people there. And it turns out that there's a whole other sense of scale that goes beyond that, and there's like 18 different tiers beyond. But I still bias based upon my own experiences

when I talk about how I do things and how I think about things to a certain persona that closely resembles my own experiences, where just install this thing as a tool and it'll be great, ignoring entirely the very realistic fact that you've got an entire universe out there of people who are not empowered to install things on their own laptop, for example. How is developer advocacy different within enterprises than in the common case of, we're a startup, we're going to change the world with our amazing SaaS? Great. Maybe you will, statistically you won't. But enterprises have different concerns, different challenges, and absolutely a different sense of scale.

How is the practice of advocacy different in those environments? So I think the fact is mostly working on standardization from get-go, that these big enterprises want things to work in a standard way where they can control it, they can monitor it, they can log everything. They can secure it mostly, of course, the most important thing. But it's also the fact that as a developer advocate, you don't always talk to developers within the enterprise.

You also have to talk to the security team and to the network team and to the business itself, the C-level to understand. And as you also probably have found out as well in your job, you connect the people with inside the business one to another, these different groups,

and get them talking to each other to make these decisions together. So it's kind of a bridge in between the people with inside the own company where they don't really talk to each other or don't have the right connections or the right conduit in order for them to start that conversation and make things better for themselves. On some level, my line about developer relations, developer advocacy has generally taken the track of, what does that mean? Well, it means you work in marketing, but they're scared to tell you that. Do you view what you do as being within marketing, aligned with marketing, subtly different, and I'm completely wrong, etc., etc.?

All positions are legitimate, by the way. So I think at the position that I'm currently in, which is a developer advocate, but for the service team is slightly different than a marketing developer advocate. The marketing developer advocate, and we have many of them, which are amazing people and doing amazing work within AWS, their job is to teach everybody about the services and the capabilities available within AWS. That is also part of my job, but I would think that is the 40% of my job. I also go on stage. I go on podcasts like this. I present at conferences. I write blog posts. I also do the kind of marketing work as well. But the other 60% of my job as a service developer advocate is to seek out the feedback

or the signals or the sentiment from our customers and bring them back into the service teams, into the product management, into the engineering teams. And as I said, sit as the enterprise customer in the chair in those meetings to voice their concerns, their opinions, how they would like the products to go, how we can make the products better. So the 60% is most what we call inbound, which is taking feedback from our customers back into the service teams directly in order to have some influence on the roadmap.

And the 40% is the outbound work, which we do, as I said, conferences, blog posts, and things like this. I have a perception, and I am thrilled to be corrected on this, because it's not backed by data. It's backed by my own biases, and some people tend to conflate the two. I strive thrilled to be corrected on this because it's not backed by data. It's backed by my own biases. And some people tend to conflate the two. I strive not to. That there's a, I think the term that I heard bandied around at one point was the dark matter developers. These are folks that primarily work in.NET or Java.

They work for companies that are not themselves tech companies, but rather tech as a supporting function, usually in a central IT style organization that supports what the business actually does. And they generally are not visible to a lot of the traditional developer advocacy approaches. They, by and large, don't go to conferences. They don't go on Twitter to yell at people about things. They commit the terrible sin, according to many startup folks, of daring to view the craft of writing software as this artistic thing, and they just view it as a job and a thing to make money for, filthy casuals, as opposed to this higher calling changing the world, which I think is a wild take. But there are a tremendous number of people out

there who do fit the profile of they show up they do their jobs working on this stuff they don't go to conferences they don't go out into the community and they just do their job and go home the end is that an accurate perception are there large swaths of folks like that in the industry and if so do they centralize or congregate more around enterprises than they do around smaller companies. I think that your perception is correct, specifically from my experience when I worked, for example, my first two years before I was a developer advocate, I was a enterprise solutions architect, which I worked with financial institutions, which are banks, which usually have software, which are older than me, which are written in languages which are older than I am.

So there are people which, as they say, they come there, they do their job, they're not interested in looking at Twitter or writing blog posts or participating in any kind of thing which is outgoing. And they're there to write the code. They go home at the end of the day. They also usually don't have pagers that they can page in the middle of the night because that's what you have operations teams for, not developers, because they're completely different entities. So I do

think your perception might be correct. Yes, there are people like that which you say, these dark matter people, dark matter developers. And I don't have any particular problem. I'm not here to cast shade on anything that they're doing, to be very clear. Not at all. Everyone makes different choices, and that's great. I don't think necessarily everyone should have a job that is all

consuming, that eats them alive. I wish I didn't some days. The challenge I have for you, then, is as an interloper, how do you reach folks in positions like that? Or don't you? I think the way to reach those people is to firstly expose them to technology, expose them to the capabilities that they can use in AWS in the cloud, specifically with my position in container services,

and gain their trust because that's one of the LPs in Amazon itself, customer obsession, and we work consistently with our customers to gain their trust and help them along their journey,

whatever it may be. If it might be the fact, okay, I only want to write software for nine to five and go home and do everything afterwards, which most normal people do without having to worry about work. Or they still want to continue working and adopt the full model of you build it, you own it, manage everything in production on their own

and go into the new world of modern software, which many enterprises, unfortunately, are not all the way there yet, but hopefully they will get there sooner than later. There's a misguided perception in many corners that you have to be able to reach everyone at all times, wherever they are, you have to be able to go there. I don't think that's true. I think that showing up and badgering people

who are just trying to get a job done into, hey, have you heard the good word of cloud? It's like evangelists knocking on your door at seven o'clock in the morning on a weekend and you're trying to sleep in because the kids are somewhere else for the week. Yeah, I might be projecting a little bit on that. I think that that is the wrong direction to go in. I find that being able and willing to meet people where they are is key to success in this. I'm also a big believer in the idea that in any kind of developer advocacy role, regardless whether their targets are large,

small, or in my case, patently ridiculous, because my company is in fact ridiculous in some ways, you have to meet them where they are. There's no choice around that. Do you find that there are very different concerns that you have to wind up addressing with your audience versus a more mainstream, quote unquote, developer advocacy role? For the enterprise audience, they need to, I would say, relate to what we're talking to. For example, I gave a talk a couple of weeks ago in the AWS Summit here in Tel Aviv of how to use AppRunner.

So instead of explaining to the audience, this is how you use the console, this is what it does, you can deploy here, this is how the deployments work, blue, green, et cetera, et cetera. I made up an imaginary company and told the story of how the three people in the startup of this company would start working using AppRunner. In order to make the thing more relatable, something which people can hopefully remember and understand, okay, this is something which I would do as a startup, or this is one of my projects which I'm doing or starting to work on, something I can use. So to answer your question in two words, tell stories instead of demo products.

It feels like that's a heavy lift in many cases, because I guess it's also partially a perception issue on my part, where I'm looking at this across the board, where I see a company that has 5,000 developers working there, and how do you wind up getting them to adopt cloud or adopt new practices or change anything? It feels like it's a Herculean impossible task. But in practice, I feel like you don't try and do all of that at once. You start with small teams. You start with specific projects and move on. Is that directionally accurate? Completely accurate. There's no way to move a huge mothership in one direction at one time. You have to do, as you say, start small,

find the projects which are going to bring value to the company or the business, and start small with those projects and those small teams teams and continue the education within the organization and help the people which you're teaching or introducing them to the cloud to help others inside their own organization, make them or enable them or empower them to become leaders within their own organization. That's what I try to do, at least.

You and I have a somewhat similar background, which is weird given that we've just spent a fair bit of time talking about how different our upbringings were in tech at scales of companies and whatnot. But we're alike in that we are both fairly crusty old operations side folks, sysadmins, grumpy people, etc. Grumpy old sysadmins, yeah, exactly. Exactly, because you ever notice there's never a happy one? Imagine that. And DevOps was always a meeting of the development and operations, meaning everyone's unhappy. And there's a school of thought that,

like, I used to think, oh, this is just what we call sysadmins once they want a better title and more money, but it's still the same job. But then I started meeting a bunch of DevOps types who had come from the exact opposite of our background, where they were software developers, and then they wound up having to learn not so much how the code stuff works, the way that we did, but rather how systems work, how infrastructure works. Compare and contrast those for me. Who makes, I guess, the more successful DevOps engineer when you look at it through that lens?

So I might be crucified for this on the social media from a number of people from the other side of the fence, but I have the firm belief that the people who make the best DevOps engineers, and I hate that term, but people who move DevOps initiatives or changes or transformations within organizations are actually the operations people

because they usually have a broader perspective of what is going on around them besides writing code. Too many times in my career, I've been burnt by DNS, by a network cable, by a power outage, by somebody making a misconfiguration in the puppet module or whatever. It might have been that somebody wrote to deploy to 15,000 machines, whatever it may be. These are things where developers, at least my perception of what developers have been doing up until now, don't really do that. In a previous organization that used to work for the fact was there was a very, very clear delineation about between the operations people and the developers who wrote the software. We had very hard times getting them into rotations for on-call. We had very hard times educating them about the fact that not every single log line has to be written to the log because it doesn't interest anybody. But from a developer perspective, of course we need that log because we need to know what's happening in the end. But there are 15 different thousand turtles all the way down which have implications about the

number of log lines which are written into a piece of software. So I am very much of the belief that the people that make the best DevOps engineers, if we can use that term still today, are actually people which come from an operations background because it's easier to teach them how to write code or become a programmer than the other way around of teaching a developer how to become an operations person. So the change or the move from one direction from operations to adding the additional toil of writing software is much easier to accomplish than the other way around, from a developer learning how to run infrastructure at scale. And now, EnterpriseDB has you covered wherever you deploy PostgreSQL. On-premises, private cloud, and they just announced a fully managed service on AWS and Azure called Big Animal.

All one word. Don't leave managing your database to your cloud vendor because they're too busy launching another half-dozen managed databases to focus on any one of them that they didn't build themselves. Instead, work with the experts over at EnterpriseDB. They can save you time and money. They can even help you migrate legacy applications, including Oracle, to the cloud. To learn more, try Big Animal for free. Go to biganimal.com slash snark

and tell them Corey sent you. I once believed much the same because it made sense coming from the background that I was in. Everyone intellectually knows that if you're having trouble with a piece of equipment, have you made sure that it's plugged in? Yes, everyone knows that intellectually. But there's something about having worked on a thing for three hours that wasn't working and only discover it wasn't plugged in that really sears that lesson into your bones. The most confidence-inspiring thing you can ever hear from someone in an

operations role is, oh, I've seen this problem before. Here's how we fixed it. It feels like there are no junior DevOps engineers, for lack of a better term. And for a long time, I believe that the folks coming from the operational side of the world were, in fact, the better DevOps types. And in the fullness of time, I think a lot of that, at least my position on it, was rooted in some level of insecurity, because I didn't know how to write code. And the thing that I saw happening was my job that I had done historically was eroding. Today, I don't know that it's possible to be in the operation space and not be at least basically conversant with how code works.

There's a reason most of these job interviews turn into algorithm hazing. And my articulation of it was rooted, for me at least, at least in a small way, in a sense of defensiveness and wanting to validate the thing that I had done with my career that I defined myself by was under threat. And obviously, the thing that I do is the best thing, because otherwise, it's almost a tacit admission that I made poor career choices at some point. And I don't think that that's true either. But for me, at least psychologically, it was very much centered in that. And honestly, I found that the right answer for me was, in fact, neither of those two things. Because I have met a couple of people in my life that I would consider to be full-stack engineers. And there's a

colloquialism these days that that means, oh, you do front end and back end. Yeah, the people I'm thinking of did front end, they did back end, they did mobile software, they did C-level programming, they wrote their own freaking device drivers at one point. Like they have done basically everything. And they were the sort of person you could throw any technical issue whatsoever at and get out of their way because it was going to get solved. Those people are, as it turns out, the best. Who does a better job, developer or operations folks? Yes, specifically both of those things together. Exactly. And I think that that is a hard thing to talk about. I think that it's certainly a hard thing to find. It turns out that there's a reason that I only know two or three of those folks in the course of my entire career. They're out there, but they're really, really hard to track down.

I completely agree. A challenge that I hear articulated in some cases, and while we're saying things that are going to get us yelled at on social media, let's go for the fences on this one. A concern that comes up when talking about enterprises moving to cloud is that they have a bunch of existing sysadmin types while we're on the topic. And well, those people need to learn to work within cloud. And the reality is, in many cases, at first, that's a whole new skill set that not everyone is going to be willing or able to pick up. For those who can, they have just found that their market rate has effectively doubled. And that seems on some level to pose a significant challenge to companies undergoing this. And the

larger the company, the more significant the challenge. Because it's my belief that you pay market rate for the talent you have, whether you want to or not. And if companies don't increase compensation, these people will leave for things that double their income. And if they raise compensation internally, good for them. But that does have a massive drag on their budget that may not have been accounted for in a lot of the TCO analyses. How do you find that the companies you talk to wind up squaring that circle? I don't think I have a correct answer for that. I do completely agree. I'm not convinced there's a correct answer at all.

I'm just trying to figure out how to even think about it. I have seen this as well in companies which I used to work for and customers that I have also worked with as part of my tenure in AWS. It's the fact of when companies are trying to move to the cloud and they start upskilling their people, there is always the concern in the back of their mind of the fact, okay, I'm now training this person with new technology. I'm investing time, I'm investing money. And why would I do this if I know that, for example, as soon as I finish this, I'm going

to have to just say, I have to pay them more because they can go somewhere else and get the same job with a better pay. Why would we invest the amount of time and resources into upskilling the people? And these are questions which I have received and conversations which I've had with customers many times over the last two, three years. And the answer from my perspective always is the fact is because, number one, you're making the world a better place number two you're making your employees feel more appreciated giving them better knowledge and if you're afraid of the fact of teaching somebody to become better is going to have negative effect on your organization then unfortunately you deserve to have that person

leave and find that and let them find a better job because you're not taking good care of your people. And sometimes it's hard for companies to hear that. Sometimes we get, you know what, you're completely right. Sometimes I don't agree with you because I need to completely get to the bottom line and make sure that I stay within my budget and my TCO. But the most important thing is to have the conversation, let people hear different ideas, see how it can benefit them, not only by giving people more options to maybe leave the company, but it can actually make their whole organization a lot better in the long run. I think that you have to do right by people because reputations last a long time. Even at big companies, it becomes a very slow thing to change and almost impossible to do in the short term. So people tell stories when they feel wrong. That becomes

a problem. I do want to pivot a little bit because you're not merely an entreloper. You are an entreloper specifically focusing on container services. Correct. Increasingly, I am viewing containers as what amounts to effectively a packaging format. That is the framework through which I am increasingly seeing. How are you seeing customers use containers? Is that directionally correct? Is it completely moonbat stuff compared to what you're seeing in the wild or something else? I don't think it's the packaging format.

I think it's more as an accelerator to enable the customers to develop in a more modern way with using 12-factor apps with modern technology and not necessarily have their own huge, sticky, big monolith of whatever it might be written in C-sharp or whatever

or C++, whatever it may be, as they've been using up until now, but they now have the option and the technology in the background in order to split it up into smaller services and develop in the way that most of the modern world, or at least what we perceive as the modern world, is developing and creating applications today.

I feel like on some level, containers were a radical change to how companies envisioned software. They definitely provide a path of modernizing things that were very tied to hardware previously. But some companies even just leapfrog the virtualization migration that they've been considering doing. also feel like it runs counter to the ideas of DevOps, where you have development and operations working in partnership, where now it's like, well, inside the container is a development thing, and outside the container, ops problem now. It feels almost on some level like it reinforces a wall. But in a lot of cultures and a lot of companies, that wall is there, and there's no getting rid of it anytime soon. So I confess that I'm conflicted on that. I think you might be right, and it depends, of course, on the company and the company culture. But what I think that companies need to do is understand that there will never be 100% of people writing software that want to know 100% of how the underlying infrastructure works and the opposite direction as well, that there will never be people which maintain infrastructure and understand how computers and CPUs and memory buses and NUMA

works on motherboards, that they don't need to know how to write the most beautiful, enticing and wonderful software for programs for the world. There's always going to have to be a compromise of who's going to be doing this or who's going to be doing that and how comfortable they are with taking at least part of the responsibility of the other side into their own realm of what they should be doing. So there's going to be a compromise on both sides. some kind of a divide today of separating, okay, you just write the Helm chart for your Kubernetes bot spec or your ECS task or whatever task definition, whatever you would like. And don't worry about the things in the background because they're just going to magically happen in the end. But they do have to understand exactly

what is happening at the background in the end because if something goes wrong, and of course something will go wrong eventually, one day, somewhere, somehow, they're going to have to know how to take care of it. I really want to thank you for taking the time to speak with me today about, well, I guess a wide-ranging variety of topics, some of which will absolutely inspire people to take to their feet or at least their Twitter accounts and tell us, you know what your problem

is. And I honestly live for that. If you don't evoke that kind of reaction on some level, have you ever really had an opinion in the first place? So I'm looking forward to that. If you don't evoke that kind of reaction on some level, have you ever really had an opinion in the first place? So I'm looking forward to that. If people want to learn more about you, your beliefs, call said beliefs misguided, etc., etc., where's the best place to find you?

So I'm on Twitter under MaceUSK. I assume they'll be in the show notes. I pontificate sometime on technology, on cooking every now and again on Friday before the end of the weekend, a little bit of politics, but you can find me, MeshSK, on Twitter, or MeshSK everywhere else social that's possible.

Excellent. We will toss links to that, of course, in the show notes. Thank you so much for being so generous with your time. I appreciate it. Thank you very much, Corey. It was fun. Mesh Seidel Kaysing, Entreloper of Container Services at AWS. Thank you very much, Corey. It was fun. along with an angry comment that your 5,000 enterprise developer colleagues can all pile onto. If your AWS bill keeps rising and your blood pressure is doing the same, then you need the Duck Bill Group.

We help companies fix their AWS bill by making it smaller and less horrifying. The Duck Bill Group works for you, not AWS. The Japanese fix their AWS bill by making it smaller and less horrifying. The Duckbill Group works for you, not AWS. We tailor recommendations to your business, and we get to the point. Visit duckbillgroup.com to get started. this has been a humble pod production stay humble