Screaming in the Cloud - The New Way to Become an Engineer with Christie Brandao

Episode Date: November 5, 2020

About Christie BrandaoChristie Brandao is a software engineer at Branch Insurance, a company utilizing a fully serverless infrastructure to sell home, auto, renters, and bundled insurance with just a name and address.Links ReferencedBranchTwitterChristie's portfolioConnect with Christie on LinkedIn

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. outside those boundaries. So it's difficult to understand what's actually happening. What Catchpoint does is makes it easier for enterprises to detect, identify, and of course, validate how reachable their application is, and of course, how happy their users are. It helps you get visibility into reachability, availability, performance, reliability, and of course, absorbency, because we'll throw that one in too. And it's used by a bunch of interesting companies you may have heard of, like, you know, Google,

Verizon, Oracle, but don't hold that against them, and many more. To learn more, visit www.catchpoint.com and tell them Corey sent you. Wait for the wince. This episode has been sponsored in part by our friends at Veeam. Are you tired of juggling the cost of AWS backups and recovery with your SLAs? Quit the circus act and check out Veeam. Their AWS backup and recovery solution is made to save you money, not that that's the primary goal, mind you,

while also protecting your data properly. They're letting you protect 10 instances for free with no time limits, so test it out now. You can even find them on the AWS Marketplace at snark.cloud slash back it up. Wait, did I just endorse something on the AWS Marketplace? Wonder of wonders I did. Look, you don't care about backups, you care about restores. And despite the fact that multi-cloud's a dumb strategy, it's also a realistic reality. So make sure that you're backing up data from everywhere with a single, unified point of view. Check them out at snark.cloud slash back it up. Welcome to Screaming in the Cloud. I'm Corey Quinn.

I'm joined this week by Christy Brando, a software engineer at Branch Insurance. Christy, welcome to the show. Thanks for having me, Corey. So I know there's a whole spiel about what Branch Insurance does, and I ignore it completely because I refuse to accept it is anything other than what you really want to have when you completely screw up Git? Yeah, yep. That could be one perspective of what Branch is for sure. But at the core of it, I do work for an insurance startup and our name also just so happens to be Branch. Gotcha. Those are two words that almost never go together.

Insurance startup. It feels, at least for whatever reason, like, oh, an insurance company, you must obviously be an 80-year-old company with trillions of dollars. And it turns out that's not actually true. Right. Yeah, that's not actually true. So Branch was actually founded in 2018 by our CEO, Steve, and he has 20 years of insurance experience. So it is quite rare that you have an insurance startup. Normally, you hear these big giant company names. But with that giant company name, what you get is really legacy technology. So the fact that we are a startup really helps us bring a super bespoke experience to our customers. One of the talking points for Branch on Twitter and other places is that you folks are built entirely on top of serverless infrastructure. So you're an insurance company that focuses on home, auto, renters, the actual usual quote-unquote boring kinds of insurance,

not exciting type of insurance like Git. But you're doing all of those things on top of serverless, which sounds like something that AWS made up to put into a keynote so they could say, see, there's this company that might be doing a thing like this. However, after a series of conversations with you folks, it turns out it's real. Yes. Yeah. It's really real. We have real customers and I'm really working on it on my day-to-day job. So it's really exciting. I actually knew absolutely nothing about insurance before joining Branch. So it's been a journey learning about insurance and also just serverless in general. We really

do use technology to create the most efficient way to bundle and save with your insurance. So with just the name and address, we can give you a price on your home auto renters and bundled policies. And from there, you can just go ahead and purchase. And I mean, under 30 seconds, of course, people take more time to customize and see if all the numbers are correct. Oh, they don't tend to do an insurance policy speed run. Yeah. Speed run check, 30 seconds in and out. Definitely possible, but probably not recommended. But yeah, it's really exciting to be harnessing the power of serverless in order to do this.

So there have been other companies that have come up that have prided themselves on being full serverless. One of them was a serverless monitoring company that has since been acquired, and they were big on eating their own dog food slash drinking their own champagne slash whatever ridiculous analogy you want to apply. And using that particular product, it felt like there were always cold starts, latencies in the environment as things spun up, whereas one of its competitors that is still in business as an independent concern, Epsilon, at the time of this recording, at least, because who knows what acquisitions look like in this time, had servers on the front end so that there was always a

responsive dashboard and you didn't have cold starts done in quite the same way. How did you folks approach that? Yeah, that's really interesting. So we do have a fully serverless architecture built on AWS. Cold starts are still very much a thing for us, specifically for our lambdas. And so we're probably still struggling with the latency and the speed issues, but still a pain point that we're trying to solve. So one of the recurring themes that we talk about on this show from time to time is how people got to where they are in their careers and how we approach as an industry, finding the next generation. And what makes your story fascinating is that seven months ago, you graduated from a

bootcamp and took a job at Branch as a software engineer, correct? Yep. Yeah, that's right. It's hard to believe that it's been already seven months, but yeah, I am here. One of the fascinating parts about that story is that it's not a common one, at least that I've seen yet in the market. You have the whole DevOps engineers where it's, what's the job requirement? Well, step one, spent 10 years as either an sysadmin or an SRE type,

getting increasingly angry at beating on servers and deep level Linux, and finally emerged through to the other side with a little bit less anger and bitterness, ideally. But with serverless, one of the interesting stories here is you got to bypass that entire world of pain in some ways. And although you are a quote unquote software engineer, which in most jobs means infrastructure is someone else's group entirely, with serverless, it doesn't generally work out that way. Is that a fair assessment? Yes, that is an accurate assessment. So just to backstep a little bit, you're totally right. I did just graduate from a boot camp in 2019.

And kind of surprisingly, I also have a bit of formal education in computer science as well. I have a minor in computer science, and I majored in something computer science adjacent called geographical information science, where I ended up learning in web development. All these job postings have technologies that I don't know. I mean, I learned Java and C++. I didn't learn React and JavaScript. So I ended up taking a job that had the developer title, but we were using kind of a no-code authoring tool for e-learning. And probably only e-learning people know this tool. It's called Lektora. And it's basically you just generate a static site by drag and dropping some images and doing some simple Boolean logic actions on those images.

And you just press publish and boom, you have your HTML, CSS, and JavaScript, and you didn't write any of that code. So during that position, I really was starting to yearn for more of the computer science and coding that I had studied in college. But of course, everyone knows you don't major in web development, and that's the kind of stuff you learn over time. And so I decided to join a boot camp to kind of supplement that formal knowledge of computer science with more vocational skills and skills I can put on my resume that I can build a full stack web application with these technologies, React, GraphQL, and Node, and basically enter the job force for web development. So the boot camp was really helpful at that. Super helpful. I mean, it was from March through August and the majority of the boot camp

was focused on pair programming. And then there was a portion of it where you would build your full stack projects to put on your resume and show that you can actually build these things. And then finally, there was the job search portion of it where they teach you negotiation for salaries, what to expect, how to interview, and all those things. So it's not just about coding or the algorithms piece. It's effectively a full service on how to navigate the technical workforce. Exactly, exactly. And so as you can only imagine, to have that kind of accelerated curriculum

in such a short amount of time, systems design and architecture is not super important to be taught. It's more important to teach the basics and what an array is and what a string is than to teach about what a server is. Of course, they're equally as important to do your job, but that's not something they teach you to be an SDE1, let's say, to get your foot in the door. And so I only learned about systems design and architecture

and all the different ways you can do those things, scaling availability and what all that means in terms of interviewing for a company so that I can look like I know what I'm talking about on a whiteboard. It's an interesting story where you see people going through computer science degrees and realizing that there was no minor in clicking the retry button on the failed Jenkins build. And the things that they teach in a formal computer science education don't always have a one-to-one mapping with what's going on in the workforce. So knowing what you know now, would you do anything differently? Would you

avoid the comp sci degree? Would you avoid the bootcamp? Would you do exactly both? Would you do neither and decide, wow, I'd be much happier raising goats somewhere instead. Computers are terrible. I do love animals. Maybe I'd go and raise some parrots or birds or something. But in terms of tech, that's a really hard question to answer. I always struggle with these types of questions because you can always circle around back to the fact that, well, I wouldn't be here exactly where I am today and I'm happy where I am today if I didn't do all those things. So it's hard to say that I wouldn't do my four-year bachelor's degree in something technical. I think it helped me build the foundation of computer science. But I really do think I could have gotten here with just the boot camp experience, because that's where I learned my day-to-day skills that I use on the job at Branch. One of the neat things from your perspective that I really want to make sure we get to talk about

is if you talk to people who've been in the space for, let's say, the last five to 10 years, and then you talk to them about serverless, everything that they're dealing with and interacting with is filtered through the lens of having to worry about stateful, large server-style systems. For that class of folk, and I'm certainly in that class, it's a story of everything we're learning is filtered through a lens, and now we're defining serverless in terms of its constraints. And that can lead to a very frustrating getting started story. It sounds, and please correct me if I'm wrong, like you aren't coming from that background. You are effectively having infrastructure handled for you out of the gate. Yeah, exactly. So when I left the bootcamp and I learned about architecture and scaling and

availability in order to interview properly, I left with the impression that I had to learn those things to be a quote unquote, good developer. And everybody defines what a good developer is. And I feel like the goalposts are constantly shifting. And that kind of contributes to imposter syndrome a little bit. But these are things that I'm going to have to learn, or at least are handled for me internally, like in my company, that I will be joining. But I was so wrong. I was so wrong because to me, when I left and I saw the term serverless on the job posting for branch, honestly, I thought it was like a buzzword at that point. I didn't know much. I thought it was a buzzword, kind of like how people use machine learning and artificial intelligence

as marketing terms. I'm sure that people still are using and artificial intelligence as marketing terms. I'm sure that people still are using serverless as a marketing term, but it meant so much more than that. And it played so much more of a bigger role in my day-to-day development job than I thought it would. So I have been able to contribute within six months of joining Branch tickets that complete features and bugs across the entire stack. And I've only been able to appreciate the things that Serverless has brought for me, which is the empowerment that I don't have to worry about things like availability and scaling. And I can focus on the problems that directly contribute to the business and features that directly contribute to the business. And that's what brings me joy and satisfaction in my job is to see the difference that I am making for the business and not necessarily, oh, you know,

like what's going on with the server, because let's let the pros handle that and the vendor that is really good at doing those things. I am going to attempt to head off the swarm of replies to what you just said that I'm certain I will get, where, oh, if your provider is handling your availability, you're going to have a problem someday. I would call the attention back to what you said at the beginning of the show, that you are an insurance company.

If all of AWS Lambda, for example, is down for a couple of hours, everything is more or less going to be broken. And it's not as if people are going to change their minds suddenly and not buy an insurance policy in that sense. That is a global cataclysmic event. For what your business does, it sounds like that is not a showstopper for what you do. Is that accurate? Yeah, that's super accurate. I remember during my first month at Branch when I was talking to Joe, who is the CTO and my direct boss, I was grueling him with these questions, right? Like, what is the purpose of serverless for us? And I don't quite understand, but it ended up just being that if AWS goes down,

we have bigger problems than that. You know, our problems are not contained to, oh, we cannot have this person buy a policy right now. It's going to be a bigger problem that is affecting way more people than just us, and that's okay. It comes down to, I think, understanding blast radius and what's going to break in that eventuality. I've always looked with scorn and derision at disaster recovery and business continuity plans that assume that the city is lying in ruin, but all your employees are going to show up on time to head to the backup site. And yeah, people are going to care about their families a heck of a lot more than they are about anything that's going on for work. It's the human element. Like, view this in the larger context of what's going on.

Yeah, exactly. You said it better than I could. So when we take a look at what the onboarding experience was like, how was it in the early days? What was the experience of encountering the modern state of serverless? Not serverless as it was four years ago when the console broke half the time, but today in this era,

what was that like not coming to it with a bunch of preconceptions that were earned through 10 years hard labor in the data center salt mines? So, I mean, it's kind of difficult to answer this question, right? Because I haven't been burned by these types of issues

that you would have if you weren't serverless. But I do get a little bit of insight from my partner. He's a software engineer as well with a traditional background and a five-year experience in the field. And so I kind of talked to him about these things after work. And so I do kind of understand what the pain points would be. But for me, it kind of really clicked in my first month on the job, where I was completing a ticket where I needed to create an SSM parameter or something. And I thought, oh, man, I'm gonna have to like, contact someone to figure out how to create this. And, and then I realized, oh, I can just do it in the AWS console. I go in,

I type SSM. It's not the term that popped up. It was parameter store. I'm like, okay, it's the third option. That's weird, but I guess this is what I need. And I go and click manually creating the SSM parameter. And then I have a moment of clarity. I'm like, wait, how is this going to get to every other developer's environment? And just a side note that every developer on our team has their own AWS account with their own environment that's pretty much a copy of production so that we can deploy our code that we're working on to our environment and not step on anybody's toes

if we break something, which is really great. So I went ahead and did that. And I realized, wait, how is this going to get to everyone else's environment? I call Joe over, and then he just shows me the magic of infrastructure as code. And I can't even explain to you how empowering it felt to be able to write some code and create the SSM parameter and know that this is kind of automatically going to happen for everyone else when you deploy. And so that was kind of when it really clicked for me that this stuff is really powerful

and it's really empowering to be able to work on any ticket across the full stack without worrying about things like availability and scaling. This episode is sponsored by our friends at New Relic. Look, you've got a complex architecture because they're all complicated. Monitoring it takes a dozen different tools. Troubleshooting means jumping between all those dashboards

and various silos. New Relic wants to change that and they're doing the right things. They're giving you one user and 100 gigabytes a the right things. They're giving you one user and 100 gigabytes a month completely free. Take the time to check them out at newrelic.com, where they've done away with almost everything that we used to hate about New Relic. Once again, that's newrelic.com. One of the fascinating parts about all of this is, and I think the reason that I had a lot of trouble with serverless at first, was I came to it with this idea of, oh, it's like a Linux box, only

weird and strange. And I kept, at least in my era, smacking into and finding the problems with my face, because reading the documentation is clearly A, for losers, and B, a lot harder back when the documentation was in a prototype state compared to what it is today. It's, oh, what do you mean I can only have so much code in there and I can't package up an entire environment? Huh. What the hell do you mean the file system is read-only? Oh, slash temp is there. What do you mean that file could still be there if it re-invokes or not? It took me two weeks to build my first Lambda function because I kept smacking into those things, and I'm a terrible programmer. And by the time I got to the end of the most recent one that I did,

it took less than 20 minutes because I am a terrible programmer and don't know what tests are. So it comes down to an understanding, at least, of the constraints. And once you wrap your head around that model, in my experience, it is way faster, more durable, fewer things to break, and let's not kid ourselves, a lot less money. Yeah, exactly. mind-boggling that you can just create a company, a startup, and be able to survive on those credits for serverless and have it up and running and have actual users, which is kind of mind-boggling for me when I found out about that. With your experiences with Lambda and taking two weeks to build it up, I guess I'm really lucky that we really had most of that built out for me when I joined. And so all those pain points of starting a serverless architecture was kind of

already weeded out for me once I joined. But I can only imagine the type of knowledge that you have to have of how you've been burned before in order to figure out how to create this new architecture and have it resilient. And it kind of naturally works out. It also, almost definitely from what you're're saying helps that you have co-workers that you can ask these questions to who have already figured out a lot of these answers. In the early days when AWS releases something on stage and everyone's super excited about it's available today, well, just because AWS releases something to production doesn't mean that it's a good idea for you to release it to production. Now that there's a community out there that has found the sharp edges, knows how to

explain things, at least ideally, and you can reach out to folks to get guidance on this, it feels like just from a community perspective alone, it is so much nicer having that path. But not to put words in your mouth, how did you wind up getting help when you started figuring out how this works? What resources did you fall back on? At first, I went to the docs to read all these things. And I figured that I wasn't really grasping it as well as I wanted to. So like you said, I did fall in the community. I ended up asking Joe for a lot of his recommendations of people to follow on Twitter, did my own research online for people to follow and resources to learn these things. A lot of YouTube videos, a lot of Googling, but honestly, it was pretty overwhelming. The amount of services that AWS has, just that list when you first look at it. I mean, all I knew about when I joined Branch was Lambda. And so it was news to me that it's actually pretty common

to not know all these services that AWS is offering. And that's okay because you don't have to use all of them. It's just about figuring out which one works for your need and you don't have to know about it before you need it. So when I was trying to figure out something that I could grasp into for Branch and kind of take ownership over, one of those things was observability. And so it was a lot of researching on, well, okay,

how can I use what AWS is offering in order to send these events to, you know, whatever vendor that we're going to be using for observability. And it was just overwhelming. But I think the community, and you're super right about this, the community does a really great job at breaking it down for those people who don't want to rely on those docs for that information. So what would you say has changed in your understanding or perception of this in the seven months you've been there that would alter how you would have approached this on day one? In other words, what feedback would you give to you seven months ago, who's entering the workforce today to make their path easier?

So I was just a part of an alumni panel for my bootcamp last week. And I think a lot of the questions that people were asking were either directly about imposter syndrome or indirectly about it. So if I were to give myself advice, you know, seven months ago when I was applying for all these jobs and reading about all these technologies that people are using is to not be afraid to challenge yourself, right? So I didn't know anything about serverless. Like I said, I thought it was a marketing term. I thought it was just the newest buzzword in tech,

the new sexy thing. The first time I heard it, I heard it as serverless and it's, oh great, do I have to fight the minotaur when I get there? And it turns out that if you view the API gateway through a certain lens, yes, yes you do. Yeah, it's like serverless. What does that even mean? No servers? Well, I mean, it just turns out it's just someone else's computer, right? So

I mean, those are the types of experiences that you really don't fully grasp unless you ask someone who's been in it before. So I try to assure people to that just because you see these terms and they might be new or newer, then that doesn't mean that it's going to be some type of otherworldly experience that you have to learn. It turns out, you know, for me at first, it's just JavaScript in a Lambda and that Lambda runs on someone else's computer. There's nothing really to be worried about or frightened or scared that you can't learn it. It's all learnable. People have done it before. People will do it again. And that's the kind of advice that I would give to

people starting out. You don't have to learn about these things in a boot camp in order to be able to use them in your everyday dev career. Do you do local development on your serverless stuff and mock services locally? Or do you do remote development in the cloud where every iteration you push and then run it in the actual AWS environment? I'm writing my code and then our Lambdas are actually, most of them are a bit too large to be just writing them in line in the AWS console. Or if I need to do a console log or something like that, a lot of the times I'll just locally invoke it. But for the larger stuff and most of the time, I do just deploy it to my environment so that I can ensure that it's not going to be breaking something I wasn't expecting it to break. Because that's kind of how I gain assurance that my code is working is to see it all together in my environment, which is the copy of

production. I've always found that mocking cloud services, except for the way that I mock them, which generally includes making fun of them, is sort of a losing proposition at some point, because you're always going to have an imperfect copy and developing to that rather than the actual thing never seemed like it was quite the right direction to go in for me. People say, oh, well, what about when you're on a plane and need to develop? I spent entirely too much time in planes most years, and I still don't see that I spend that much time in that situation to the point where it is worth making that the common use case for my development work. Yeah, yeah, that makes a lot of sense.

I mean, something that I have found very valuable is I was reading a lot about charity majors because I'm working a lot about observability and how to implement that into our code base. So she's a huge proponent of testing and production, which is super scary. And a lot of people immediately, you know, probably wince when they hear that. But I'm a big fan of testing other people's production. It's easier. Less risk for me. Exactly. Yeah. Sorry, Joe, just messed everything up there. But I think it's really important because you can't ever mock exactly

what is going to be happening when a real user is interacting with your app. That is, I think, one of the biggest problems with technology, is it's almost impossible to effectively predict what a user is going to do and how they're going to break things. I can't even tell you the amount of times I've audibly laughed out loud at watching people interact with their app through those screen recordings. I'm just like, why are you clicking that button? I can't

believe you even found it that way. The types of things that people will go through on your app is unimaginable. It's still one of the biggest challenges I see is I've been doing this for a decade and a half now, and I don't know where I would tell someone to start if they were starting today because there's so much that brought me to where I am. It's nice to see that there are paths forward that don't require going through the same levels of pain in the same areas. Yeah, definitely. It's really freeing to know that the boot camp experience and the non-traditional background is being more accepted now in technology. So it's really great that alongside me, I have my colleagues that have all different

types of backgrounds and come from all different paths of life. And it's really exciting to be able to see that our future generations are going to be able to come in technology and have that experience as well. Christy, thank you so much for taking the time to speak with me today. If people want to hear more about what you're up to and how you view these things, where can they find you? Sure. Yeah, I'm on Twitter at Christy Brandow, and then I have my portfolio website, which I believe you link below, but it's just cbrando.dev. Excellent. And we will indeed put those in the show notes.

Thanks again for your time. I really appreciate it. Thanks, Corey. Christy Brando, software engineer at Branch Insurance. I am cloud economist Corey Quinn, and this is Screaming in the Cloud. If you've enjoyed this podcast, please leave a five-star review on Apple Podcasts. Whereas if you've hated it, please leave a five-star review on Apple Podcasts, whereas if you've hated it, please leave a five-star review

on Apple Podcasts and tell me exactly what kind of servers Serverless runs on. 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 humble pod production. Stay humble.