Screaming in the Cloud - Episode 53: Company Migration On Two Fronts: AWS and the Career Paths of Software Engineers

Episode Date: March 27, 2019

Some of the highlights of the show include: Implications for migrating to AWSWhy and how for using Amazon vs hardwareThe positive effects of mentoring for both the mentor and menteeTechnical vs Management tracks at a software companyCareer advice for women in the tech fieldLinks:https://www.digitalocean.com/ https://sendgrid.com/DO.co/screaming http://blog.dbsmasher.com/https://github.com/

Hello and welcome to Screaming in the Cloud with your host, cloud economist Corey Quinn. This weekly show features conversations with people doing interesting work in the world of cloud, thoughtful commentary on the state of the technical world, and ridiculous titles for which Corey refuses to apologize. This is Screaming in the Cloud. This week's episode of Screaming in the cloud. Maybe give some of that to us. DigitalOcean, from where I sit, biases for simplicity. I've spoken to a number of DigitalOcean customers, and they all say the same thing, which distills down to they can get up and running in less than a minute

and not have to spend weeks going to cloud school first. Making things simple and accessible has tremendous value in speeding up your time to market. There's also value in DigitalOcean offering things for a fixed price. You know what this month's bill is going to be. You're not going to have a minor heart issue when the bill comes due. And that winds up carrying forward in a number of different ways. Their services are understandable without spending three months of study first. You don't really have to go stupendously deep just to understand what you're getting into. It's click a button or make an API call and receive a cloud resource. They also offer very understandable monitoring and alerting.

They have a managed database offering. They have an object store. And as of late last year, they offer a managed Kubernetes offering that doesn't require a deep understanding of Greek mythology for you to wrap your head around it. For those wondering what I'm talking about, Kubernetes is of course named after the Greek god of spending money on cloud services. Lastly, DigitalOcean isn't what I would call small time. There are over 150,000 businesses using them today. Go ahead and give them a try or visit do.co slash screaming

and they'll give you a free hundred dollar credit to try it out. That's do.co slash screaming. Thanks again to DigitalOcean for their support of Screaming in the Cloud. Hello and welcome to Screaming in the Cloud. I'm Corey Quinn. I'm joined today by Sylvia Botris, Principal Engineer at SendGrid. Welcome to the show, Sylvia. Thank you, Corey. Thank you for having me. You might be better known on the internet as DB Smasher, which is first, an awesome name, and secondly, deeply evocative of my entire relationship with databases,

dating back to my first experiences with technology 20 years ago. Me too. i've been breaking them for a while um my current nickname internally in the team is remote emp because a lot of times i'll just like touch something and it'll like i'm i'm i seem to have this secret knack of a of a qa engineer like i'll touch a tool and i'm the first one to find like a bug or just make it completely kernel panic and things like that. And it's been challenging sometimes. It's hard to realize at the time, because when you, when you, everything you touch breaks, one of the,

I think easiest things to do is fall into this pattern of assuming it's, Oh, obviously it's because I'm cursed. And well, yes, you are. That does wind up having a tremendously valuable aspect to it of finding the ways that things break in failure modes that you hadn't predicted or experienced before. I've learned that one when I wind up talking to product teams at various cloud companies and they want me to look at things. And the answer is not that the product is generally terrible. It's that I have

really weird use cases and I find ways that things fail that hadn't been predicted before. That alone winds up being tremendously valuable if you can only bottle it. It's super annoying when you're on deadline and trying to get something running. And, ooh, you found a new interpreter bug. No one's done that recently. That's awesome. It's great. Thanks, but I'd kind of like to get this thing

to ship this week. That would be awesome. So I feel your pain there. I really do. Yeah, I'm currently having this whole saga. We're doing this large project with Sengit that we announced maybe like less than a year ago, just under a year ago, where we are moving our infrastructure from in pieces. It's a long journey. We're currently self-hosted in our own colo centers and we're moving to amazon and so one of the very first thing you are told

when you're going to go to amazon is your if you do infrastructure as code which you really should uh terraform is the thing learn terraform i had been for years now managing the databases at sengred using chef which has its own obviously wars like nothing is perfect but i had i had come to terms with learning all the things like the tricks like don't get too crazy with attribute precedents things like that but now it's an entire mind shift with a declarative language that uh doesn't even have loops yet and um it's been a thing for a month now my team has watched me rail like keep trying things with terraform trying to use it to deploy Aurora clusters

with regional replicas, and it's been that kind of thing. I've already filed two bugs with Terraform, found a third one that totally applies to what I'm trying to do, and I am pretty close to just wrapping it in Bash to try to work around the bugs while things are being figured out.

So being on that edge of like, yeah, this is awesome that I'm finding bugs, but I really I've been working at this for a month and I would like to never look at it again for a while. That's definitely a thing. That's the interesting part I've always found about managing infrastructure as code. Once you get it up and running, it works. You do it in CloudFormation, Terraform, Chef, Bash script, etc. And then you invariably don't touch

it for six months a year or whatnot until you have to make changes and then you go back to it and it's almost like relearning whatever it is that you wound up building the first time and you look at this and it's what moron wound up writing this and you pull up git blame which we may as well call git shame because that's how everyone uses it and you realize that the moron was you and oh we're just gonna fix that now and we need never speak of this again and but it's one of the most demoralizing things in the world it's like on the one hand it's yeah i'm good at this and i'm considered an industry leader and on the other it's huh what is terraform and how might one use a thing like that? It's a constant humbling of wherever we think we are in this space.

Oh, yeah. So about the get shame part, I used to do that way back when I started at Sengred. And it is incidentally my seven-year anniversary today as we record this. Oh, congratulations. Seven years at a company in tech. That's like 25 years on a watch. And most, I know it's, it's, it's, I can't believe it either. I still vividly remember my first day actually.

Um, but I mean, at the time I was, I was still like a bit like had a hard time with the empathy bit of working as an engineer and like i would do this thing where i go get blame and be like what was that person saying thinking but seven years in and at the same company most likely the git blame will be me so all the time i go back i'm like oh man past sylvia was really an idiot when she did this um one of my favorite git extensions that made the rounds a while back on GitHub is Git Blame Someone Else, where it goes back

and rewrites history and attributes commits to other people, which is just spectacular. One of the people still on the ops team with us, and he's been at Sengred longer than me. It's going to be nine years for him in a couple of months. He was the first DBA, although he never held the title.

But he and I have this friendship where we troll each other a lot. And I distinctly remember only a few months ago, someone who was much newer on the team finding a script that was causing issues. And they were debugging this thing that is very arcane. And they go into the script, and it's a bash script and title at the top. Whoever wrote it put in the author as DB Smasher. But then I was like, I don't even recognize this. And I did blame it, and it was my coworker.

And that was definitely one of those. We like to show each other in our team. We love each other so much. It's a good relationship where we just throw jams at each other like that all the time. It's fun and it's easier to do in some cases with things like Git. Just because you wind up in this world of this incredibly complex tool, that's primary job is to make everyone feel stupid no matter who you are what you do you will go past your comfort zone with git full stop but then you wind up find that other people seem to know certain things that you don't it becomes a constant first excuse to share knowledge with people and secondly in that uncomfortable world of this complex critical thing that no one

fully understands comedy arises and it's always a reliable direction to go in as far as easy jokes at least well easy should be in quotes because it's good nothing's easy yeah i mean that that's definitely one of the like the lessons learned after this many years. Seven years at SendGrid, not everything has been smooth sailing all the times, but it's much healthier to come out of it with a laugh than get angry. So in the interest of full disclosure, I write a newsletter every week that goes out to give or take 10,000 people. And that is powered these days through SendGrid. I am a paying customer. This is not a podcast. This is me using a service

that works. So when I find a vendor I'm using like SendGrid is doing something publicly that is entertaining in this case, yeah, or as you just mentioned, moving to AWS. Hey, that also is relevant to my interests. I immediately get simultaneously intrigued and a little worried. It's, huh, well, this service I've been using is super reliable, but now they're publicly changing a fundamental piece of the architecture. Well, that's going to be interesting. How is that going to play out potentially? So I'm curious to hear, I guess, first, how you folks think about the migration to AWS. Starting at the beginning, what drives that? Yeah, we're going to pick up this thing that we've built and move it to a completely different environment is generally not something a company does for funsies. Exactly. So the conversation around making this move started like maybe a year and a half ago. We've been an AWS partner for a while.

We are in their marketplace as one of the email providers right next to SES and, you know, getting traction there. But one of the other things that were also happening during that time was we were talking as both as the ops org and generally as engineering of how much work was really going into hardware procurement, getting the racks in place, making sure they are actually usable, getting them provisioned, getting them out to the network, getting them in our internal system that we use to provision the host, and then turning them into a KVM host. The amount of work that goes from, hey, we need racks in DCX to the engineers have assets at hand that they can deploy things to.

It's a very long road and it was a serious concern at our velocity. There's also the other concern where as a business, we send mail and we have known peaks of traffic. There are certain times where customers want to send more mail. For example, Black Friday and Cyber Monday is a known thing for us. So, and we just tweeted like after last Cyber Monday, like we sent 3 billion emails just in the 24-hour span alone with a lot of like impressive peaks within that one-hour span

or 15-minute span internally. So if you're self-hosted, you find yourself having to procure hardware that accommodates the peaks, but then there's a lot of idle in other times. Weekends are pretty quiet. Not a lot of people send email over the weekends. So that became another concern. It's like how much money is sitting idle just to be ready to use when we have high peak days

like Black Friday, Cyber Monday, or other days. GDPR was another day as well that was very high peak. So those two things came to- Oh uh gdpr day alone was one of those absolutely horrible days for anyone who depends on getting important things in their email inbox here's the funny part so um our our big data team was waiting to see what happens with that day because it was going to be an interesting one-time event for them to see how we handle it. But from an operational perspective, we didn't feel it.

As in, we felt it way more in our own personal inboxes than, oh my God, the traffic is high and things are... Knock on wood, nothing went wrong that day. It just sort of flew by. And the next day we went, oh, we said, I don't remember what the number was, but it was definitely north of 2 billion. We said that much? Oh, that's cool.

So it was a clear example that we had a pretty solid infrastructure that handled the scale like very comfortably. But then on the other hand, you should, like it was enough for us to go, this is a good reason for us to move to the cloud because it would have probably cost us less in hardware or in infrastructure cost to not have all that hardware sit there waiting for GDPR to happen and for us to use it.

So between the idle infrastructure concerns and the developer velocity concerns, it became clear that we needed something that could just elastically scale with us for you know delivering all these billions of emails um but also like you said it's like we are a large company we've been around for a while we have many many customers it's not a you can't just change tires on a on a bus that's flying at 100 miles an hour um and just be like let's just stop it and get the tires off. It has to happen while you're running. So that's why we decided it's not going to be like a quick thing.

We set an ambitious goal still for a couple of years, but we're doing it in small portions. There's a lot of education internally for all of our engineers as to how to actually build stuff in Amazon. It changes your architectural mindset when you're designing things. Well, hopefully, if it doesn't, you've created a heck of a problem. Exactly.

You never want to. There's a lot of things that you can take for granted when you are owning everything down to the network here versus when you go into Amazon and things are far less under your control. But I think ultimately it's better for us as engineers to do that way because then you'll learn to make what you build actually resilient and not just happens to work because if the network goes down, I know who to poke.

It's interesting dealing with a company like SendGrid. In the interest of further disclosure, I started my career as a Unix administrator focusing on large-scale email systems. Not SendGrid large-scale, but large-scale enough measured in the millions of users. And as I was building out the newsletter, we talked earlier about the idea of finding weird edge case, strange bugs. it was very clear that I am, as every other aspect of my life, not the typical case for anything. So I'm talking to an account rep as I'm getting my SendGrid account sent up and they said, okay, how many emails do you wind up sending a week? Like, oh, cool. I have at that point, 3,000 subscribers. They said, great, cool. We can absolutely send email to your 3 million subscribers. And it's, whoa, whoa, whoa.

You're off there a little bit. Okay. No matter how big this thing gets, we got you. But the other side is, cool. And I want to build this newsletter management thing into it, too. And the response was, oh, here's our API. So the things that seemed very complex to me of sending high volumes of email with a great deliverability story,

your entire corporate approach is, yeah, no problem, we got that. But the stuff that involves some of the higher level moving up the stack aspects is on the other side of it, oh, yeah, that's not really what we do. And credit where due, I appreciated being told that explicitly, as opposed to the song and dance so many vendors like to do of,

oh, yeah, it'll also make fries. But that doesn't lead to a good experience. So this is where we start and this is where we stop is fantastic. A question that I have, though, as you've since then started to broaden out a bit into a marketing campaign story and going down towards, I guess, the, I don't want to say lower end of the market, but that's absolutely where I am. It's becoming an increasingly capable platform as time goes on. It's nice to see that enhancements, those enhancements start to come out. And I guess what I'm curious about, and feel free to tell me you can't answer it, but is

some of that flexibility and capability improvement being driven by, even in a tertiary sense, by the migration into the cloud? It hasn't been driven by it. It's actually helped accelerate it though, because our customers kept asking for it. They're like, we love your API, but we also want to use it for handling marketing. And our marketers are not developers, they can't write the API, but they can't write code that talks to API's they need to be able to do some things in the GUI. So that was one of the drivers actually, because a couple of years ago, we were embarking on the marketing campaigns application,

getting a new rewrite. We were wanting to add some features around automation, which is now in open beta, maybe closed beta, but I'm fairly certain it's on the website right now. That is marketing campaigns was one of the first parts of our of our product lineup that we wanted to move and to make all the new things that we add to it aws native so that was one of those um things that yeah like once we do this that's definitely the first one to start doing this with a because it's it's it's a smaller um volume compared to like our bread and butter infrastructure email business line. And two, because once they do that, it has a lot more potential to be able to leverage all of the cool things that are in Amazon

that we don't want to have to build internally. Because one of the biggest drivers for this move was also we need to focus our engineers on the things that are our business advantage. We no longer want to spend any engineering time building an internal provisioning system for hardware or building a DIY metric stack or any of those things that we don't actually bill our customers for. So when we start going into complex systems like handling marketing contacts and all of the things that go along with it, having the ability to use something like AWS, where it's like there's a lot of managed things can help us build the higher up pieces faster. Sorry, I was on mute. Please take silence out there's there's always a capability story that starts to enhance itself as you start moving towards more dynamic infrastructures

where okay we need to wind up being able to serve very bursty loads so when we wind up on gdpr day or whatnot suddenly we're at 18 times normal capacity. And then that drops down to effectively nothing. And we don't pay for it except when we're using it. There's something that winds up shifting from a perspective context around the idea of being able to take whatever it is you're doing and spin something up to see how it works and spin it down when you don't need it. That for whatever reason, you don't have that level of dynamic ability to innovate. When you're paying for hardware, having to get it racked and, oh, you want to try this new experiment? Cool.

We're going to expedite that and get the infrastructure spun up in only two short months. It tends to really actually break in effect. Yeah. Oh yeah. I'm speaking aspirationally here for startup territory, not big enterprises. It's cool. We'll have that for you by third quarter.

And they very conspicuously don't mention a third quarter of what year. So historically as well, you were focused primarily on databases. And now, as you mentioned to me earlier, you don't have the word database appearing anywhere in your title, either because you've scared them all into submission, or it's the future. We don't need databases anymore. Or perhaps least interestingly,

but most likely, your capability has now expanded beyond pure databases into other arenas. Can you give me a little context into that? Yeah, so way back when I started at SendGrid, we didn't even have written down job titles. The job title comes with your offer, and you kind of guess what it means. I had the luxury when I started at SendGrid, I was one of the first actually who wasn't hired,

it was like with a vague software engineer, quote- title, it was more specific to DBA. So I at least had an idea of where my scope was. But we didn't have enough effort at the time into explaining what those titles meant, what the levels attached to them meant what competencies we expect. And after that, the next step, as most companies do, people started needing that. So that was defined. But one of the biggest concerns that I had raised at the time was that the track seemed to, for individual contributors, would go all the way up to like senior engineer or senior DBA in my case, and then it would stop. And other than that, you start going into the management level where you start

seeing like senior management director, senior director, VP, and so on. So I, this was around, I don't know, year four or so or five at Sengred. And I started facing the usual question that all engineers around this time for like me face is like, do you want to go into management? I genuinely was not super interested in it. I knew that we still had a lot of technical things to solve, and I wanted to be involved in solving them. But I still pointed out that, hey, this difference in the tracks is sticking out to me.

So to their credit at Zangred, we started talking about, hey, do we need to redo our tracks? And that's when Zangred introduced a new rewrite of our leveling and our titles structure. And we started having a fully fledged individual contributor track. We started having what we call principal engineer, principal engineer two, and architects, that role starts becoming more of a leadership without direct reports kind of role. There's definitely an emphasis in it on helps the other people in the org do stuff, be a force multiplier for other engineers, helps teach, helps mentor far more than, you know, goes in a black hole and comes out with a shiny, fully done production product. So that's been really a great, at least for me, I felt it was very empowering to be able to say, hey, I've learned a bunch of things over the last few years.

I would like to continue solving problems here, but I would like that also acknowledged as part of the career track that we have. One of the things I think that I admire the most about you has always been your willingness to help mentor people, help people understand something they didn't before. It's something that I would love to see more of across the industry. It was even in early days when I first was getting a vague awareness of who you are, your willingness to help people understand complex things in reasonable ways was one of your defining characteristics. It's one of those things where people never quite know what their own reputation is, but that's one that you've been carrying for an awful long time. I figured

you probably have been told this before, but in the off chance you haven't, that is how people tend to view what you do thank you that's that's really nice of you i i really appreciate that yeah um uh i didn't have that much of a so my time at sangria for a very long time i was the only dba um i've i've had a consultant outfit helping me out for most of that time when i was solo but But as much as one tries to incorporate a consultant outfit as part of the org, there's always going to be that level of that you still have to be able to give them more specific things to do and contain the work so that the output is still usable when they are gone. So for a long time back then, I was starting to get very aware of the fact that a lot of the engineers that we had at Sengred at the time were still not super comfortable with databases.

And their quickest instinct was to ask the DBA to look at it. Like, please go fix this, whatever magic you do. And I started having issues with burnout for a while. And it was like I was feeling that I was doing the same thing over and over again. And it was not really, I wasn't growing. I was a new challenge. I wasn't learning new things. So that's when I decided that, no, I need to stop, you know, guarding things that way.

I need to be able to teach the engineers how to figure out what's wrong, try to document how the code that's running the databases looks like, things like that, because ultimately I was like, if nobody else knows how to do what I do right now, I will always be doing what I'm doing right now. So that's where that motivation came from, like slightly selfish motivation still, but I'm glad it helps everybody else out. Since then, we've started hiring more DBAs. We are now a team of four, soon to be five, which is still mind-boggling to me. But now that we are at

the stage, since I've gotten principal engineer, the database portion has been taken out of the title. I've recently joined our architecture team. I'm working closely with our architect team and PE2s who report directly to the CTO, which means I get to help with more strategic things. So it's less about databases specifically and more about how to build the things that bring the value to the business. And I've been definitely enjoying that a lot recently. Something fascinating is that you've been at SendGrid for, as you

mentioned, seven years as of today. Congratulations again. But you haven't, I guess, crossed over, for lack of a better term, into the management track. You are very publicly an individual contributor. What drives that? It's funny you mentioned that because my boss and our former VP of Ops would both say that, yeah, she didn't want to do management. We're still having her do all sorts of managing things. They're sort of sneaky that way. But what I'm doing is basically I help out with a lot of helping grow the younger engineers in the org without actually having to just write performance reviews and handle calibration meetings,

which is a really nice thing to do. The reason I've tried to avoid doing management was it was twofold. One of them was more personal. Let me start with the other one first. The general one is because I felt that there was a lot more technical changes coming up that I would love to be

involved in. I'm very aware of the fact that if I do the move to management I need to not be in the way for the code like for how to build the things it stops being about that I'm not a huge fan of the interim stage

of being asked to do both, where you're in charge of people's performance reviews and you have to help grow people's careers. And at the same time, you're responsible for building large parts of the product yourself. Charity Measures talked about that recently. There's also that amazing book by

Camille Fournier about the manager's path. And they both acknowledge that stage, but they always say it's a difficult one that needs to be short lived and has, you know, a time box around it. But I knew that it would still mean like, the next step would be step away from the technical and actually help with the people. And I'm fine with that but I was like I'm I know myself I'm gonna want to do the technical stuff and I know that we specifically at Sengred have a lot of very interesting technical challenges coming up and I wanted to be part of them so that was that was the one side of it the other side was far more selfish just because of the fact that at the time when this fork in the road appeared for the first time for me

there was not yet any principal engineers at Sanger who were women and I was like nah I kind of want to do that I want to start you know and like I want to make the case that yes you can have you can hire women engineers they don't have to go into the human side or like the quote-unquote soft skills side of things to continue working and to advance their career that like yeah i can totally like go in and be part of the technical decisions and um and do that i've recently given the architecture team flag because uh until i joined they were literally all like white dudes and they all loved black shirts in fact a specific shirt

so when i joined the teams we sort of like decided to compromise where they decided to buy me the black shirt but it's like now yeah like the team is not just dudes so i've been especially proud of that one it's neat to see people who have grown into their careers to incredibly lofty professional heights, remaining individual contributors. And SendGrid is a bit of a knack for this. One of the folks you have working over there used to be the CTO at a company I worked, now individual contributor, one of the most, I guess, distinguished engineers I've ever had the privilege of working with. And the list goes on where there's very clearly a separate technical track at SendGrid that is not perceived as being lesser than management.

And I really like that pattern, and I wish that more companies would embrace that. In too many environments, if you want to advance professionally, you're walking down a path of management, which is often terrible. You're a terrific engineer, so we're now going to focus on an orthogonal skill set that winds up having very little

relevance to what made you good at this. So we're going to lose a terrific engineer and gain a crappy manager. That sounds best for everyone, but it's the only way for you to develop. I really like it when companies go in a different direction. And it wasn't from day one, like I said. We've had our own hurdles learning that lesson the hard way. Sometimes we've hired people, we've promoted engineers into management roles and watch them not do so well. One of the people with me on the architecture team,

he was sort of dragged into management for a bit. And then he realizes like, it's not for me. The good thing about Sengred and it's, it's a name to our culture is that we have the humility, whether it's the executive team or the management team or the senior ICs to say, okay, that's not working. If I want to continue being here and providing value, we need to fix this part. And it's fine to admit that, you know, management is not for me. I'm not going to do that. And friend of mine uh sean kilgore he's he ended up you know stepping away from management after i think it was like a year maybe less and went back to no i want to be

senior ic i want to help this company build scalable you know long-term infrastructure that provides value but i don't want to be i don't want manage people. I prefer to help the people without being directly responsible for the performance reviews and all the other things that come along with it. And that was fine. Unfortunately, a lot of companies don't, they consider that a failure and that you're just not good at either anymore, which is mind boggling to me.

It's like, no, like I gave you this entirely other job and didn't give you any help understanding how it's supposed to go. And then you failed. And now I'm surprised that I'm going to let you go. It just doesn't make sense. I think that there's a terrific story

around the idea of being able to, I guess, continue to develop, nurture, and of course, attract talent. It seems very strange to me that in many cases, when someone is management at a company and they're not succeeding or thriving in that role, or they want to go back to working as an IC for a variety of different topics, there's no way to do that without changing companies or losing face. People in the industry tend to view that as a perceived demotion. And that's not great. I think part of it is because there's this implied presumption that IC doesn't actually help lead. I've seen this before, and I've argued with

people on Twitter about it before, where they'll say, like, senior engineer does algorithms this many times or has the focus with the senior individual computer, senior software engineer is that they write code really, really well. And I've taken issue with that because ultimately, I don't think that being IC means you're precluded from talking to people or precluded from helping mentor the younger engineers in the work. And once that dawns on people, it becomes clear that even as a principal engineer with no direct reports, I still have a responsibility towards everybody else in the organization to not just do things, but to teach things. So once that gets clear, you no longer have the delineation of like, yeah, the managers are a higher caste

than the individual contributors. And if I prefer to do IC work, then I'm going to forever have a ceiling on my career. It's nice to see companies embrace that. I think that's something that I think the entire industry could learn from in more depth. I want to thank you for taking the time out of your day to speak with me,

especially given this is your seventh anniversary at ZenGrid. There are probably things you could be doing that are a lot more entertaining listening to me prattle on. So thank you for that. Not at all. Thank you, Corey. If people want to hear more from you, where can they go? Well, I do have a blog. It's blog.dpsmasher.com.

And I'll make sure you have the link for the show notes. If you would like a more stream of consciousness, there's my Twitter feed. Sometimes it is literally just screaming in the void against some sort of bug. I will occasionally OH my team, which they seem to apparently enjoy. I don't know. But whenever they say something witty, I'll tend to sometimes just OH it in no context. And people seem to think that's funny. I certainly get some joy out of it.

But yeah, you can definitely catch me on Twitter and catch all sorts of things about what I'm doing right now that might be frustrating or even fun. Well, thank you very much. I'll definitely put those links into the show notes. Thanks so much again for taking the time to speak with me and my ridiculous nonsense. No worries. Thank you, Corey, for having me. It's been fun. Sylvia Botris, Principal Engineer at SendGrid. I'm Corey Quinn. This is Screaming in the Cloud. This has been this week's episode of Screaming in the Cloud. You can also find more Corey at Screaminginthecloud.com or wherever fine snark is sold.

This has been a HumblePod production. Stay humble.