Episode #140: From Zero to Cloud Engineer with Gwyn Pena-Siguenza

June 13, 2022 • 50 minutes

In this episode, Jeremy and Rebecca chat with Gwyn Pena-Siguenza about why everyone in tech should start out at a help desk, how flexibility versus simplicity affects a developer's cognitive load, how Azure differs from GCP and AWS, the state of serverless, and so much more!

Gwyn is currently a Regional Cloud Advocate at Microsoft as well as a YouTube content creator. She started in tech at a help desk role, where she was first introduced to cloud computing and the learning hasn't stopped since then. Her favorite topics are .NET and Azure Functions, and she’s always down to try out new things. Gwyn is passionate about introducing others to the cloud; creating friendly and concise content; and her family. When she’s not doing Advocate things, you can find her playing video games, hanging out with her family, or eating mint chocolate chip ice cream.

What if everyone in tech started out in helpdesk... tweet

Transcript

Jeremy: Hi everyone I'm Jeremy Daly.

Rebecca: And I am Rebecca Marshburn.

Jeremy: And this is Serverless Chats. Hey, Rebecca!

Rebecca: Hey Jeremy how are you doing? How are you feeling? How are you being?

Jeremy: I am feeling much better after having COVID. So it was like two weeks ago something like that. And it was awful. The first week was like head cold stuff. And then basically after that it was a headache for a week straight which was pretty rough. So luckily I am feeling better now and I actually got to go to MongoDB World yesterday which was pretty exciting.

Rebecca: I would love to hear about what that was exciting. I also knew that you weren't feeling hot because in our text threads usually you bring the cleverness and instead you were like 'yes can do.' It's like 'oh no Jeremy must not be feeling well.'

Jeremy: My brain was just in a fog could not process it. I actually drove down to New York City just because it's faster for me to drive than it is to get on an airplane and do all that stuff. So when I do that I listened to Audible books usually or podcasts or something like that. But on my way down on Tuesday night I was listening to a book called Category Creation by Anthony Kennada, I think his name is. And there was a part in it, It was like perfect- it was like sort of serendipitous that this came up- where he was talking about the difference of having a event in person like a conference in person versus having a virtual one and basically said that having a conference in person is like going to a sporting event. Like being there. Like you're just consumed by the event. There's so many things going on, like you're constantly whatever. Whereas if you watch a basketball game at home or something like that where it's like you get up, you get a drink, you know. And of course now we can pause it and whatever. So just you're disengaged whereas it's so much better to be in person. So being down at MongoDB World it was just funny cause I get there and I'm like 'yeah this is such a thing.' I gave a talk and I got the energy up in the room and it's just it's an absolutely amazing feeling. So I know we've been doing all these virtual conferences but I am so happy that we are back to being able to do some of these things in person now.

Rebecca: It is super exciting. And I am going to make a shameless plug that also leads us into introducing our guest. If that sounds good? Okay, so shameless plug but really because I do think it serves our listeners and our community really well: Common Room HQ has put together a developer relations compensation survey. And what we've been seeing is that there's like really good emerging data around what community managers and community leaders make in terms of salary compensation transparency. But that doesn't yet exist in a very specific and formative contextual way for developer relations and developer advocates and people in that space. And so we have the survey. You can find it. It's on our Common Room HQ Twitter and then we'll be posting it on our website as well. And then folks like Mary Thengvall and Shawn Wang and Tessa Kriesel from Devadvocate are our collaborators on the survey to make sure it makes the most sense to the developers in the space. So please take that survey. We will share the results freely back in the month of July, probably in later July. We have a data team. We're going to splice up the information in ways that make it really accessible, really useful so that you can have more contextual conversations when it comes to compensation. So please go take that survey. I think it'll help everyone understand better how to have these conversations with an informed understanding of what they should bring to the table and what they BRING to the table in terms of just that monetary value. Obviously, people bring all sorts of things to the table. That being said, talking about advocacy, developer advocacy, cloud advocacy. Would you like to introduce our guest today?

Jeremy: I would and I would also like to say about that survey- the more open, transparent salary data and things like that that just makes it so much easier for people to know what they're worth and not have to have these secret conversations, I think that is absolutely amazing. So that's great stuff there. And I know I mentioned I love going to conferences in person, I do. But one really effective way to learn I think and for people to advocate and teach you how to do cloud and things like that is to use YouTube right? Or to use any sort of online media, some sort of virtual way to do it. So our guest today is a cloud advocate at Microsoft, a content creator on YouTube. You might know her as GPS. Gwen Pena Siguenza is our guest today. Gwen, thank you so much for joining us.

Gwyn: Thank you both. This is awesome. I'm a big fan. I've been listening- I remember the first episode I listened to was the Linda Nichols one back in May, I think, or March 2020. And that was the first time I was like I really want to dig more into serverless things, I want to listen to more of these episodes. I'm a big fan of Linda so yeah it's great to be here with both of you. Excited for the chat.

Jeremy: Awesome.

Rebecca: For people's contexts we were introduced because of Forrest Brazeal. I was like 'Hey Forrest, you know we'd love to have you on the show.' He was like 'Yeah yeah I've been on there before. Let me tell you about people who are amazing in this space.' And your name came up. He was like you got to talk to Gwen. And so thanks to communities for those connections and to you trusting us and trusting Forrest to put us together. It's always really fun when someone's like 'Don't talk to me Talk to Gwen.' Talk to this person. You're like building from first principles in terms of like starting from the beginning starting from zero. It's showing people the whole journey. So really glad to have you here.

Jeremy: Yeah and, you know, I just read a Tweet earlier today that was something like 'what does the developer want to hear in four words?' And one of the responses was something like 'I appreciate your work.' One of the things that we love to hear is that this program inspires people. Gets them interested in the subject matter. And there's so many amazing people in this space that if somebody clicks with you, that's awesome. So that is super great to hear. So now that you're in the serverless space, could you tell us a little bit, or tell the audience a little bit, about not only your background a little bit but what you do at Microsoft as a cloud advocate.

Gwyn: Yeah, I'm going to try to keep it a short .You know everyone's story is super long and there's so many a sideways steps and things like that. Which I believe is a very beautiful and unique thing to everyone's story. But I started in tech at like an Apple Store. I was selling phones. And I got quickly tired of that because I don't know if you've ever been to an Apple Store that's in a mall on a Sunday. But people can get aggressive like very, very aggressive. So after doing that for like a year...

Rebecca: I'm already nervous.

Gwyn: After doing that for about a year and a half I was like 'I gotta do something else.' And I'm a college dropout. I did about two semesters of CompSci and then I was like this is just- I was also you know a very arrogant teenager. I'm like 'I'm better than this. I can teach myself all these things on my own. Oh I don't like this teacher. This teacher doesn't like me, whatever. So I dropped out and I was like 'I enjoy tech. I know I kind of want to dive into it more but I didn't really know where that was going to take me. So I landed a help desk role and I am a big fan of help desk roles because of how entry-level friendly it is for people getting into the space without having like fancy credentials or degrees. Did that for about a year and a half. And I was introduced to an infrastructure team there who was working with AWS. And I didn't really get hands-on with anything but I became cool and friends with them. And at one point some of them one of them told me 'Hey why don't you take a look at this AWS certification. It was the developer certification specifically. And I was like okay, And this was complete foreign to me because I had so much programming knowledge from school, and I had some like database knowledge and things like that but nothing when it came to the cloud. So I spent about six months studying for that certification, which one I tell people now that they're like it took you that long to study. And I was like yeah it took me that long.' But then I recently found my notes that I took and it's like a 60 page .PDF And I really went in to just learn all the content for that certification. I got it. After a couple of months I felt very comfortable with like okay I need to go find roles that I can like build on these skills. I landed a SIS admin role and they were working with moving things to Azure. And in the job description it was like there'll be potential for you to work on like things with Azure. I was like cool that's all I need to know. Interviewed, went well, and then after a bunch of onboarding and things like that, I was quickly sort of thrown into like 'Hey we need to do these things in Azure.' I'm like I have no idea but I'm down to do it. And my manager was very cool. We're still very cool to this day. I think when my career like one of the biggest like impacts that I've had is I've always had very cool managers that have been very supportive. Obviously some of that is on me and my performance and the fact that I'm willing to put in the work and stuff like that but I've just been very lucky with great, great people who have supported my career. And quickly got on to do a bunch of Azure projects. And I remember the first automation thing that I had to automate. I used Azure logic apps and Azure functions. I didn't have really any traditional software dev or when you think of deploying things on virtual machines or more of like the traditional model. None of that experience. I went straight to serverless. And I didn't even know it was serverless. I didn't even know what I was getting into. I was just like all right this sounds like something I could potentially manage on my own, so let me do that. And then that turned into automating a bunch more complex things. And then developing these processes that save the company like hours and lots of money and things like that. At one point the pandemic hit and we were doing fully remote. I had more time to like 'I kinda want to make videos.' I've always had an interest in making videos I just didn't know the thing that I wanted to make videos on. So I'd become a cloud engineer by then. And I was like I'll just make tutorials and stuff that I'm doing. And I would share them on Reddit, share them on like Twitter and things like that. And that's where I met, how I met Jeff Holland, who's also been on on on Serverless Chats. He found one of my Azure functions videos on the Azure subreddit and he shared it on Twitter. And at this one I had maybe like 19 followers or something like that. He shares and he's like 'oh this is great. I hope you keep doing these.' And then that for me was enough to be like 'oh I want to, I have to absolutely keep doing this.' And then I recently told Jeff this, cause he's made a career move, and I told him 'look because of people like you and I hope we get more people like you in this space, I was encouraged to continue following this thing that interests me.' Which was the support that I wasn't necessarily getting at my role that I was in then or with my team that I was there. But I was getting it from other people on online. And like with community things like that. That turned into me being like 'oh I want to do more community work. I still want it to be technical but I don't want to beat necessarily be like an engineer every day all the time.' And then I was introduced to what advocacy was then. I was like 'oh this is actually [inaudible].] And I had a brief six months at ACloudGuru which is where I met Forrest. Fantastic company. Forrest is such an amazing leader, such a creative person when it comes to these technical content things as well. And also one of the smartest people I've ever met. And then the role of developer advocate here at Microsoft opened up. And I was like it just I felt like I didn't want to leave ACloudGuru. Cause it was great. It was a little too soon but I was like 'I've always wanted to work at Microsoft. And it worked out and I think long story short, here I am.

Rebecca: I think, I mean knowing how wonderful the ACloudGuru team is too. I can only imagine that they were like 'go do what it is you've always dreamt of.'

Gwyn: Oh absolutely. Yeah my manager was like 'You got to do it.' I'm like I'm sad.

Rebecca: You got to go. You're actually not allowed to work here, Gwen. You have to go do it.

Gwyn: Yeah no no absolutely. And my manager at ACloudGuru, we are still very close as well. Again like I said I've always had just great managers. I'm so so so thankful for that. But yeah it was my time there was very impactful as well and I wouldn't be where I'm at here and doing the things that I did without all the stuff that I learned there as well.

Rebecca: Well little do you know- or maybe you do- but your introduction has teed up so many of the questions that we're about to ask you. But we're going to start with one I usually I've been saving these towards the end, but I like to like go through someone's Twitter and see what they've tweeted about recently or something that's on their mind. And the one that actually stood out to me was one that you posted and I have pinned from December 16th, 2020. But you're like 'what if everyone in tech started out in help desk...' It got over a thousand likes. There's 186 comments like over 400 retweets. And I love that Tweet because it's not only a part of your origin story, but man it's so true. You're like yeah either that and I think, I started out in food service and I think both of those things feel very similar where you're like 'you know what? Be at the help desk, be at food service, be in some sort of thing where you both learn deep empathy as well as, not only for the person trying to help you, but also like just how chaotic things can get and who you don't want to be in a moment of, let's say stress. How you don't want to treat others while also learning how you do want to treat others. So I love that thread. We will post that link to that thread in the show notes because there are like quite a few really interesting answers. I am curious if any answer still stands out to you to this day?

Gwyn: I can't really think of one specific to me. Whenever I think of that thread, and I was just thinking about it yesterday- so it's interesting that we're talking about it now- is just the amount of people who are like I started helped us get I'm here I work at Google, I work at Amazon,. I work at Microsoft, I work here, I do this, I'm like a distinguishing engineer here. I'm like the amount of people that started from like a support role into ended up like turning their career where they wanted it to go I think is: we need more of that. We need more of this transparency. I think oftentimes we downplay our own stories because we've lived it. And it's like 'oh yeah who's this going to help?' But the reason I wanted to find that thread yesterday was because I was doing a live stream and oftentimes I'll hop on and I'll just answer career questions or things that I've sort of gone through. And someone asked me like 'well I feel like I can't get anywhere If I start in help desk.' I was like 'No, here is, go through these replies and you'll see people actually shared their stories. Like no this is this you can actually do this. But yeah I think it was also interesting to see how many companies have developers or other roles that are outside of the help desk do some time in their help desk as well. I think that was very interesting to see. Overall it was a very positive thread. I think a lot of people would also agree you learn a lot and it a help desk world that are skills you are gonna carry on for the rest of your .Career There were some people who were like 'that's a terrible idea.' Sure. But you know that's social media. So they have their reasons of course. But overall yeah that was an interesting time of when I used Twitter and the replies were great.

Jeremy: Yeah. So: fun fact. I started my first internship as a help desk support at a PR firm. And this is what happened for me: well besides the fact that you get to a point where basically you just tell people to restart their computer- that was one thing that was the easiest solution. But what was great was I made friends with all the tech and IT people that were there. And then we did a whole or they did a whole sort of re-networking. They brought in new switches and things like that. And I learned how to do networking from all of them because it was sort of 'like well I have the phone clipped to my belt.' And then I could go and do and watch them do this other stuff. So there was just a huge learning opportunity there at that particular organization that I was at. It was a good sized company. There was 200 something people there. But I think that's right. I think, Rebecca you said it, the empathy that you when you're talking to people and you get their frustrations. And then for me it was, I would hear the same thing over and over again. Like 'oh we're having issues with this ODBC connector into our accounting software thing whatever.' So you'd have to go and know always have to fix it or whatever. And I remember just saying 'Wouldn't it be great if I could just fix this problem' right? So that nobody had it again. And that got me more into software development actually at that point because I was thinking like 'wouldn't it be cool to build these things and just make them work correctly.' Then of course you realize it's very hard to make software work correctly. So you get the frustration there. But I do think that is totally worth it. I mean it dramatically helped my career .I launched a web development company after that and did hosting and all that kind of .Stuff A lot of the knowledge I picked up from that internship at a help desk.

Gwyn: Absolutely. I like to think of my time in help desk, the years that I didn't do in college. It's because you know in college you get like a lot of like general classes you should have kind of trying to figure out where you want to go. It's like help desk was that for me, except I was getting paid.

Rebecca: That does sound pretty good.

Jeremy: As opposed to paying or acquiring debt in order to be in college.

Rebecca: So guess what time it is? We've officially made it to talking about serverless.

Jeremy: Serverless time. So speaking of serverless, Data Dog recently released their state of serverless report. A little bit different this time than it was I think last year. Last year was focused a lot more on the tools. This year it kind of dove into this idea of how many companies are using serverless. It expanded the idea of what maybe serverless is. And it started including a lot of these container services. And I know that Azure just launched Azure container services or something like that. There's so many names, so if I got it wrong, I apologize. But so there's now this idea where it's like people that are learning serverless, they're learning the different managed services. Obviously there's Faas in there right? So whether it's Azure functions or Google cloud functions or Lambda or any of the other ones that are coming out. But there's also a bunch of other services like Google Cloud Run which is just I think way ahead of the curve when it comes to "serverless containers." But then there's AppRunner and then Azure and a bunch of these other ones. And then as well as a bunch of other companies that are starting these sort of container scaling things that are calling themselves serverless and so forth. Semantics, whatever. But I'm just curious what you think about this sort of shift into sort of where I guess serverless is now being considered containers as well as Faas as well as all these managed services and so forth.

Gwyn: I think it's first interesting. I feel like serverless used to get so much hate and now everyone wants to slap serverless onto their names right? It's like 'oh we got to do it.' But back a couple of years ago I remember being in rooms and people would laugh at like 'oh yeah that's that's fun for a little like little automation thing but in production it's never gonna work.'

Rebecca: It's a toy.

Gwyn: So like okay underdogs on top now. Which is awesome. It's interesting. I feel like, yeah we're moving from I guess maybe the core of what serverless actually is to now it being, it almost feels like 'oh any managed service you can slap serverless onto it.' And then that is what it is. And then you go into the discussion of like 'well what actually is serverless? Is that worthy of the name?' or whatever it is. And I think that is something for other people, not that I wouldn't want to figure it out, but I think for me it's more so like 'all right so if I want to introduce someone to serverless like how would I go?' And I think you and I sort of briefly discussed this before, where it's like 'it is getting a lot of complex to just get into the space' because now it's more so like it's not just like 'oh if I need event driven code I can go find a fast service that works for me.' It's more like 'no well what actually am I trying to use serverless with?' Is it the containers and then we start talking about devops. Or is it like the databases. Cause you know I think things like CosmosDB now is like a serverless consumption plan. Yeah it's getting maybe bloated isn't the right word but it's more so like there's just so many paths and and yeah it's an interesting conversation to have.

Rebecca: Yeah maybe it's bloated or like conflated right? Or just like they're like' let's put all the words in the bucket!' And so you had touched on this a little bit but to broaden it out for listeners, that idea of flexibility. But when you add flexibility or you add like serverless as an addendum to any other managed service that's also added complexity versus simplicity right? Where maybe the beginning of serverless was like reduce all parts of cognitive load except for writing the code. Like you write the code, the rest of the cognitive load is somewhere else. Obviously we have I think moved much more toward here's a bunch of flexibility which has added complexity. Maybe you call it flexibility, maybe you just call it stuff. But where do you see the state of serverless today? And how are we looking or should we look for the future? Do you feel specifically as you're building with these new services that you're like 'this actually doesn't feel like inherently right.' Or like 'I actually want this to be simpler I don't want all these knobs.' And when you see other builders get started with serverless do you see a future where they should or shouldn't be like trying to get too deep in where they're getting like stuck in the details where like the goal of serverless is like the simplicity?

Gwyn: Yeah it's interesting. It's more so like we started by stripping down and like 'okay just the absolute essentials. Let's just worry about the code.' And now it's like 'oh well now do we need the container options? Do we need the database option cells to be serverless?' And be like 'oh we have so much more to think about.' It's like we were trying to not think about this in the first place alright? Yeah that's a hard one because I feel like so for example when I was more focused on like functions, so Azure functions the fastest offering that Azure has, and that was always sort of been my serverless experience and sort of like where I continue to grow. Because Azure functions continues to grow, adopt more languages, more features, and things like that. And that's sort of like, I can spend the rest of my, I guess maybe not the whole career, but a big chunk of it, just focused on functions and there'll be lots to do there right? But now even I found myself the other day I was like 'should I be like thinking about container apps?' Cause like everyone's talking about containers and I feel like if you're not talking about it you're going to be left out. And if you're not up-skilling in that kind of space you're going to be left behind or you can't find a job or whatever it is. It's like should I be shifting my focus to to learn container apps- which I think is, to be fair, a very cool service. I think the idea behind it is, I mean it's nothing new. I think you mentioned Google what is it Cloud Run?

Jeremy: Cloud Run.

Gwyn: Cloud Run which has been kind of like the staple when it comes to an area, for a while now. Yeah it's hard because I understand that the making more things serverless makes sense because people want to people want to save money. But it's also like as someone who wants to come into the space or someone who is in the space, it's like I don't really feel like I can focus anymore It's more so like how do I adapt my solutions to also incorporate these new things? Because you know everyone wants new things. Cause marketing words, if you put it in your pitch or you put it in your deck like you can raise a bunch of money or whatnot, right? So.

Rebecca: Web three crypto serverless.

Gwyn: Yeah right?

Jeremy: The more buzzwords you have, the better.

Gwyn: Serverless web three. I'm sure that's a thing right? That's gotta be a thing. It's gotta be a thing. Yeah and I guess it makes sense. I just I think there's something very special about serverless where it's like 'okay it really does matter.' Like .Just care about your business logic So I would hope we wouldn't lose that and turn it into something that it was never meant to be. But then again, like how much control do we have over that?

Rebecca: You brought up something super interesting where you're like 'okay if you're losing focus' let's say as a cloud advocate or as a developer as a builder, there's this thing where okay we used to, in the serverless space, have to, when I was at AWS, we'd have to say 'yeah but look at your total cost of ownership.' Serverless is actually really good for TCO. And now it kind of feels like you're saying, not that you're making this claim, but if you're losing focus as a developer. Let's say the total cost of ownership, sure. Now some of the products or what you're building or the app might be a little cheaper, but if it's taking a lot longer time to build it or if it's taking developers and engineers or advocates longer to explain it, longer to onboard new people, then there's probably a total cost of ownership thing that at some point you're like we actually again have to return to this idea of total cost of ownership, or TCO, looking at it from the other side now of what we're trying to solve.

Gwyn: Yeah I think in tech we often fixate too much on how the actual, how much the tech costs. Or how much this plan is going to or this tier is going to cost me. And then we tend to forget about everything else that comes outside of that. It's just like the example of me. Like yesterday I was supposed to be working on this demo thing and I kinda got sucked into thinking if I should use it with container apps and I ended up not building it. So now I have to build it after this. But then that time could have been spent actually going with using functions instead of trying to rearchitect it into something that- it's not necessarily wouldn't benefit but the time spent there is already that's money there, right? And are we reallyl- yeah you're right. Are we really saving by by having everything serverless? Because then we have to think about it. Then we, just for example, Azure itself has 10 different services that you can deploy containers on. Some of them have serverless options. So it's like 'all right If I want to go that route I got to go through all these services and figuring out which one's great for me.' But how much time is that going to take me? So yeah. It's 'are we still saving money?' Maybe, maybe not. Who knows.

Jeremy: Well, so what's interesting is and this is something that I've been trying to sort of articulate and I haven't done a good job of it yet but I think that it's becoming clearer. And what Rebecca said about TCO and what you said again about the cognitive load and having to think about these different things, one of the things that was nice about serverless when we first launched was it was relatively simple, right? And even as you're adding more services you're like 'okay well now you have a database service that you can access fine.' And there's an API gateway. And then we're like 'okay well now there's a graph QL service.' That's a little separate. Now we have logic apps and we have step functions. So I get it. We're adding some complexity. But you're still thinking about the ultimate thing being functions. Then suddenly it's like, 'well wait a minute. Now there's some things that the cloud can do that you don't even need functions for.' So if this service can do computation for you, now you don't need that. And now you sort of lock that into some specific service. And then when it comes to containers you've got to ask yourself 'well it might be cheaper to run something on containers in a serverless container, but now I have to package that specifically for containers as opposed to a Lambda function or an Azure function or whatever. And maybe I can deploy the same code, the same containerized app, to a Lambda that I can whatever and maybe there's some things there.' But now you're starting to make a lot of architectural choices. And you start saying 'well okay I have maybe some events coming in from a queue. I don't want to have those hit a webhook on a containerized app. It's just easier to run those in a Lambda function or in a Google cloud function.' So maybe that's better to do there but then my HTTP traffic for my API like oh maybe that makes more sense to run in an app because I can get the cost to be a little bit lower. Cause one thing about serverless costs is they're linear right? So the more usage- it's not like you, until you hit some major discount levels you typically don't see a reduction in cost. And again yesterday I was at Mongo DB World and they mentioned that their new serverless Atlas or Atlas serverless instances that they have, they actually set it up so that they scale, the cost goes up linearly until you get to a point where it starts to level off. And then actually when you get enough usage, it's like 90% discount over the on demand price as it gets greater. And I think that's a really interesting billing model that serverless and serverless services have to move to. Is, as you start to get more stable workloads, yeah get the benefit of the elasticity, pay for that. That's fine. But maybe as you start to get to a point where these workloads look more like provision workloads, with just a little bit of variability, still be able to use serverless but still have the cost benefits right? Because you get to that point where it's like 10 requests per minute. You're like okay I can handle this. A hundred requests per minute, getting expensive. Thousand requests per minute, okay now this is starting to get really pricey. And then you get to whatever some high level of scale. And you're like this is insane. I could hire an entire team of developers or dev ops people to come in and watch servers for me, and it would be 10 times cheaper. So anyways I think that's an interesting place where we are now where it's like I think serverless scales really well but is the cost, the TCO, and all those kinds of things actually worth it when you get to that point?

Gwyn: Yeah I think the challenge is also like, for example, I guess my first time using serverless technologies back in like 2017. Then for me it was from like just reading docs and things. It was really clear as to when you would use functions and even a combination of like logic apps and functions. Cause I feel like those two have always worked in a way where it's like 'oh if you're trying to accomplish this you could use this and do the hand off to functions or hand off to logic apps in a clear scenario.' Whereas now I have no idea. I don't think, I would like to say like 'oh I would go straight to something like a Faas or a low-code no-code whatever.' But like you mentioned like oh you got to consider now you can have serverless containers. You're like well the database and all these kinds of things. So I have a, um not a fear, that might be a strong word, but like serverless is trying to adapt for everything. Like this model that you mentioned is interesting. It's like okay I can see people who have more traditional workloads would would see like the benefit of having something like this, like you said mentioned Atlas offers. I was like okay I can see that because like are we trying to... serverless became a thing because there were like very specific use cases where your use case will shine when you use serverless. And now I feel like that area is so gray or becoming very gray. Or it's like 'oh there's not a clear like yes serverless- it's an easy sell. Now it's a little tougher now.

Rebecca: I'm like laughing a little bit because we love serverless on the show. Obviously: Serverless Chats. And our guests we imagine also really enjoy serverless and that's why they would have chosen to be guests. So I'm like laughing because we're like 'Ooh serverless. Ugh. And we're like 'Actually we love you serverless! We just want to make sure you're the best that you can be.'

Jeremy: But that's it right? We just want to make it the best that it can be. And that's the biggest thing for me cause I'm not an official developer advocate or anything like that but I feel like just with what I do with the show and the newsletter and the other things I do, I'm an advocate for serverless. And I criticize a lot of it. Cause I think you can't be in that, you can't look at a technology and say this is a silver bullet. This is going to solve all your problems, right? And you know with the current product that I'm working on like we found a lot of a lot of rough edges that we ran into with the traditional ways that you're supposed to use serverless right? And serverless containers is one of those things that, for us, came up as like 'this is a huge cost savings.' And it's not as hard to manage, or it's I don't want to say hard to manage but it's not that much harder to manage because it does most of the work for you. It's just a matter of getting the packaging right. And making sure that you know the routing is correct and some of these other things. So there's a lot to think about. But, yeah I mean, I just I look at it and I say serverless I think is the way. I think that regardless of whether you slap a serverless logo or a serverless name on it or whatever, it doesn't matter. The point is the type of applications we're starting to build are getting to this self-managed, infinite scale. Or you know I guess auto managed whatever self managing- you don't have to manage yourself. And then you know this auto scale and event driven type thing which is another thing, by the way. I started adding, every time I give a serverless talk, I always give the four bullet points of 'It's scalable. You pay for value. And then I always add an event driven there because I feel like unless you're putting a web hook on a container then it's not really event driven right?' So I'm trying to draw a line there but anyways and I'm just rambling on but this is the thing is that serverless- I love it, I love the promise of it. But I feel like people are, I don't know, I feel like we're not quite heading in the best direction we could be.

Gwyn: Yeah I would definitely like to see more of a clear definition as to like what it is. To me, I a hundred percent agree event driven is, it's just, it's stable. I think it just has to be. If it's not event driven I don't think it can be considered serverless. I mean I'm not the person who defines these things, but that's just my humble opinion. But I've always thought whenever I think serverless I always think event driven. And I feel like that's a very popular, like I think most people would share that opinion as well from what I've heard.

Rebecca: Let's talk about a little bit of definitions. Okay, so I would say there's like three sort of primary serverless providers or cloud providers that focus on serverless. There's Azure functions Microsoft, TCP cloud functions Google, and then the AWS serverless portfolio Lambda et al. There are certainly more players in the space but we'll use those three kind of large ones. Oftentimes, right, people are limited- or not limited- but they are building on whatever cloud provider their organization uses. But when people get to choose whether or not they're working on their own project or maybe they're looking to work at an organization specifically based on what cloud provider they want to build on. Do you know like- can you describe how do people, how does Azure, how does Microsoft describe what they believe is serverless? Like what are their tenets, if you will? And then do people ever ask you around like 'Hey what should I know if I'm trying to build on Azure functions versus Google cloud versus AWS?' Do you get these questions around like what do I need to know per cloud provider? And then how should I imagine I operate let's say working with Azure functions?

Gwyn: Yeah absolutely So we ideally define serverless as pay per what you're using and when you're not and when it's not in use you're not being charged. Also it's stateless, so your I guess it's code, at the end of the day it's code right? Runs in a stateless container. And I'm not talking about like serverless containers is more so the infrastructure that your code is running in stateless. And like scalable like you mentioned already. And I think to answer your following question there is like what is sort of like a heads up when people want to work with Azure serverless is more so: Yes, I work at Microsoft and I know .Azure has its great pros and things but I'm also very like honest and transparent. I think that's a very big part of advocacy I would say like the tooling and like what you're trying to use to build your application and such when it comes to languages is one thing to consider. I know when it comes to like Python like Lambda has overall some of the best support out there. Also there's GCP when it comes to .net no one can beat us. I would also say we have durable functions. I'm not sure if you're familiar with durable functions. It's an extension on top of Azure functions. So if you do want to create architectures like fan out or chaining or things like that, you can. I don't know if there's anything similar to that in other cloud providers but I think that's a pretty unique offering that we have with Azure functions as well. But yeah it's more so, it's not that I don't think that you can find something to use in Azure for whatever it is that you're looking to build. It's more so consider everything and the good thing is that you have plenty of options. And the good thing is a lot of them are somewhat similar. But I feel like although I'm like a functions person end to end If I needed to go figure out how to build something in Lambda I could probably do it. If I needed to figure out how to do something in cloud functions, I could probably do it as well. But I think the tooling. Cause you know every developer wants to work with a whatever they're most comfortable, most productive with. And you've got to find the space that supports that the best way.

Rebecca: Yeah that's probably one of the benefits of having some version of shared definition right? It's like you can at least then port over that way of thinking so long as the definitions across these different providers are the same right? But if like one is stateless and the other one does not define it or one defines as event driven one doesn't then you're like 'now we're going to have a problem because I'm thinking in a specific way.'

Gwyn: Yeah.

Rebecca: To develop in this way.

Gwyn: Exactly. If they were drastically different than I think we would have a massive issue. Definitely.

Jeremy: I also think too, doesn't matter which- I mean, it matters- but I I don't think it matters too much which Faas provider you choose. I think they're all going to perform pretty well. I mean Lambda is advanced, Azure functions is advanced. Durable functions, by the way, I really liked durable functions when they came out. Cause I like the idea of being able to do that orchestration in code, as opposed to having a completely separate state language like step functions does in AWS or what's it, Google workflows or whatever the other one- I think it's Google workflows. Whatever it is. Anyways, there's too many of them to know which is part of the problem. But beyond just the functions as a service right? And again forget about containers for a second. If you want to write an app in Azure functions even though the function itself is stateless, your application probably isn't right? So you're going to need some sort of a database right? You're going to need probably some sort of a queue. You're going to need some of these other things. So I think no matter which provider you pick there's a whole suite and ecosystem of tools around that that you need to learn as well in order to really build an app. So I might be able to write you know a simple conversion function in Azure functions. But if I want to connect that to a database or I want to make something sort of interesting happen I think there's a lot more to that that you have to learn.

Gwyn: Absolutely. And that brings me back to like the first introduction I got to functions. And the reason we selected functions was because we needed to work with files that was already in our Azure blob containers. Like we were already here like, grabbing that from a function was a lot easier than having to go incorporate something like a Lambda or trying to figure out how to use Lambda. Everyone wanted to use Faas. It's just more so like what led us to be to continue working with like an Azure product was 'oh we already have our data here.' We already have our SQL server instances here as well We have our files being pushed to blob containers. Like the next step to like 'oh let's just use functions' is kind of an easy decision. You could also probably make the right argument as to like 'oh let's actually use a different cloud provider' whatnot. But yeah you're right. There's a lot more to if you're picking Lambda, if you're picking functions, if you're picking cloud functions you're not just picking that you're picking what comes with it and around it.

Rebecca: So one of the, I mean one of the [inaudible] drivers of using serverless or really anyone choosing whatever it is that they choose to build with right, your developers want to feel however they can be most productive, whatever feels best to them. And ultimately it's because they want to deliver something. They want to ship the thing that is right. Like ship the right feature ship the right code. Something that delivers impact to their role, their job, their business, who they're working for. So I wanted to ask you a little bit about the project that you did to get you to cloud engineer and I loved how you framed this right? So the project was you built a serverless XML file submission app. You said yeah I took a process that was 18 hours of weekly manual work to a monthly solution that costs $1. That is why it should be promoted. Like basically you could say that as a headline and they're like 'Check. Yep.' They're actually like you actually got two promotions at once. Thank you. Plus a huge bonus. So I love that project that you did to get to cloud engineer. I would love for you to talk a little bit about that but you say like 'Hey the person across from you is going to ask why do you think you deserve a promotion to cloud engineer?' And I'm wondering where you see some of the most ripe areas for automation organizations or what builders should be looking for, how they should start thinking about where to find those flags? Where they could have a huge impact. Where they are 18 hours of weekly manual work. Like how did you discover this outsized impact that you could have with your serverless XML file submissions?

Gwyn: I think to start that off, I feel like no one understood the impact that actually automating that process had. Even the person who assigned it to me. They were like 'Yeah we have this thing. Go figure it out. Like there's some people, somebody has files.' And I was like all right it sounds I don't know, straight forward. That's what I thought, right? I was a CIS admin then, early on in my cloud journey. And I felt like throughout that project I had every stage. Like you know I was architecting, I was administrating, I was developing, I was doing the dev ops. All this kind of stuff. And I was also the person having the conversations with the people who were actually doing the process that needed to be automated. I think internal tooling, internal processes is a massive, massive area for anyone who's looking to build their experience or sort of try to get on projects or volunteer for projects. Or maybe if you have I don't know like you get the opportunity to work on something else I think first look at things that you can automate or work on internally because it's not that it's less pressure. But you know, with it not being public facing maybe there's a little less pressure on you to be like 'okay if I mess up there's not like this massive like money loss.' I mean still internal tooling will translate to money to some but it's not like a direct impact. So I definitely, that definitely was a big help for me to be like 'okay I have a little bit more time to work on this to figure this out and own the solution end to end.' It started off with me just kind of sitting with a team, like understanding what they were doing. And I think that is a big part of like fully understanding 'oh is is serverless a good fit or not a good fit?' It's like sit down and have the conversations. I watched them do the process multiple times. I took notes. I was like 'okay I think we can use blob storage for this. I think we can use Azure functions where they blob trigger here and then I'm going to need to send it somewhere else cause we need to archive it all. We also need the results to be put in like a table. Okay I think I could do this, use this output binding here.' And just before even building ,absolutely anything playing around, absolutely. I sat down and I fully understood the issue. And then I worked with them. And then what was cool is with that with that process I also got to work with other teams too. Because there was other changes that needed to happen in other systems in order for this to work. And for this little automation to sit perfectly where it needed to sit. And that also got me closer to our senior engineers, our data engineers, our senior software devs and things like that. So I'm a big fan of like look internally cause there's always something you can automate internally. Absolutely. And this goes back to like what Jeremy you were saying like you when you work help desk, you kind of get into the mindset of like oh this problem it keeps happening. How can we like develop a solution around this? And if you have that mindset of like 'oh I need to be on the lookout for for okay Is there something that someone's doing that they could be spending their time better?' And this was like a clear example. Like they were spending two to three hours every single day, six days a week- even on Saturday. Which you know work-life balance? I don't know. That's probably another issue. It was probably another issue that they needed to figure out right? I was like okay that just seems like such a waste of their time. Like the they're incredibly capable analysts. They should be doing what they're supposed to be doing. But yeah a lot of that comes from I was wearing many hats. I could also have conversations with anyone and I kind of became friends. And I think I developed that skill set and help desk. It was like just talk to everyone and anyone. And then they were like 'yeah I have to do this process and it's like annoying.' And then they turned that into telling my boss 'Oh can you get Gwen to automate it?' And you know, just being close with everyone which is great and yeah I think internal tooling is a big way to get your feet wet with these kinds of things. Like less pressure than like a public facing thing. But again serverless is capable of production level things. Like you know Netflix uses it, Legos, Coca-Cola, Nordstrom. All these these places. So it fits in many areas which is great.

Jeremy: Yeah I mean and that's the thing about serverless is: automation. Dev ops automation or any sort of automation is such a great use case for it because again you don't have to be building these super polished apps. You just need to be able to trigger these things that happen. And actually I've done a lot of hiring in my day and we were interviewing dev ops engineers that we needed to come in and help manage infrastructure. This was before serverless but I remember I always asked the question 'what does success look like for you at this job?' Like what would you consider to be successful or how would you consider your role to be successful? What needs to happen? And he said my goal is to automate myself out of a job. And I said you'll have an offer this afternoon. Because it was like the perfect answer. I mean that's exactly it. The more automation and things you can add, it's amazing how much time I love people who are like 'well it only takes me an hour to do this and it would take me five hours to write a script that did it.' Yes, but if you have to do that every day and it takes you an hour every day after a week or two weeks guess what? You know that original time investment would be gone. So I love automation as a use case for serverless. And I also just love it as a thing that people should absolutely be doing.

Gwyn: Yeah I think also just it I saw how it empowered my colleagues who will like now had two hours free to their day to go do other things to you know further their skillset which is great too. And I think when we think of automation like we've got to also think about, you know you're also enabling you're freeing other people's time. And that's great too. It's not just about your work, it's sort of like that can impact down the line and up the ladder or whatnot.

Jeremy: And I've never seen anybody lose their job because they've added automation that reduced the amount of work that they have to do. There is always something new to do. All right, well we're running out of time, speaking of time. And we mentioned or I mentioned MongoDB being in or MongoDB World being in person this year in New York. You are also involved in a conference in New York that is coming up. Would you like to tell us about that?

Gwyn: Absolutely Serverless Days New York City. We're back. Well, I say 'we're back.' I say more so Serverless Days in New York City's back. This is my first time actually organizing a conference at all, which has been quite the experience. But it's gonna be June 24th. We're coming up like two weeks from now. It's going to be at the Microsoft Times Square building. They're actually our venue sponsor and they allowed us to do it for free, which is cool. So we can now offer tickets for free as well. I think Rob, who's another organizer, was saying this is one of the few Serverless Days events that we've been able to do like free tickets. Which I think is fantastic. Yeah we're going to be there and Times Square isn't like the happiest place to be in New York, but it's very accessible. As a New Yorker, I live here in New York and I know how annoying it is to be in Times Square. But it's accessible for people coming out of the city and the state, and I think that's great. We've got a great, great lineup that we just announced two days ago or so. Very excited for that. We got people from all over the world coming in. We got our super special keynote speaker as well I've heard.

Jeremy: I heard about that, I heard about that. I'm excited.

Rebecca: Wait. I haven't heard. Am I supposed to know?

Jeremy: Oh it says on the website 'mystery speaker' but by the time this airs, I think it will be announced. I am giving the keynote. So I am doing a talk on the past ,present, and future of serverless. And I will be talking about serverless containers.

Gwyn: Oh that's awesome. I'm looking forward to that. That's going to be a great one. Yeah we're all I'm just excited.

Rebecca: Why did I not know this? I feel duped. What a reveal!

Gwyn: Well, maybe you just announced it. But that's cool. I'm excited. Going back, at the beginning, I remember you saying like the difference between in-person events and online events. And I remember the first in-person tech event I attended was an AWS summit at the Javits Center. And that was like, I dunno maybe four years ago. And I had come to New York for that and that was the moment I was like I want to 'live in New York.' And I would have not had that sort of thought if I didn't attend that conference. And I had spent like two days in New York because of that. Hung out with friends, was around the culture. And I was like I really want to live here. And like you know now I do. Which is awesome, but that wouldn't have happened if I never attended that event.

Jeremy: Awesome. And the Javits Center- that's where I was yesterday. And I had no idea but they have a working farm on the roof of the Javits Center.

Gwyn: Yeah. Yeah.

Jeremy: It's amazing. It's so cool. Well anyways, I'm looking forward to Serverless Days New York. I hope people will join us there. I'm assuming it will be recorded and so forth so the people that can't make it hopefully, they'll be able to watch it later. But it should be super exciting and again thank you for organizing this. If anybody has ever tried to organize a conference or if you if you have any complaints about organizing a conference or how a conference is organized- go try organizing one yourself and then come back and and tell me your complaints because it is very hard. So thank you!

Rebecca: It's like the help desk for events. You're like listen...

Jeremy: Right.

Gwyn: We're back full circle.

Jeremy: Exactly. So anyways thank you so much for organizing that, you and Rob Sutter. And I think Richard Boyd is part of that as well right? So just awesome group of people. It should be an amazing event. And Microsoft when we did Serverless Days Boston, Microsoft sponsored our space as well so we were able to do thatw ithout any cost of the space. So we were able to do a lot more other things with that. So that's super awesome of Microsoft. Anyways, if people do want to find out more about you or watch the videos on your YouTube channel you've got so much stuff going on- how do they do that?

Gwyn: Yeah probably the easiest way or the place I'm more active or most active is like my Twitter, my DMS are open if you have any questions, anything you want to chat: cloud, career, help desk, serverless, anything: Made by GPS on Twitter. Actually Made By GPS everywhere.` I got lucky where I was like my username is available everywhere. So like Instagram, LinkedIn, YouTube, Twitch. If you go to aka.ms/madebygps, all my links are there and that's probably like the easiest. I make new YouTube videos about literally anything cloud related almost every every week. And I host a lot of workshops with like advocacy stuff events, mostly playing around with something new in Azure. So yeah connect with me. We'll

Rebecca: chat.

It's a trove. It really is a library. You have like things about certifications, things about getting started, like what the gotchas are, how beginners intermediate... it's really cool. Highly recommended. Six out of five stars.

Gwyn: Thank you so much. I appreciate that.

Jeremy: All right. Well we'll get all that stuff in the show notes. Thanks again, Gwen.

Gwyn: Thank you all.