Subscribe
Share
Share
Embed
Christie Brandao is a software engineer at Branch Insurance, a startup that uses serverless infrastructure to sell home and auto insurance more efficiently. Prior to this role, she worked as a developer at the LHT Group. In a previous life, she was also a Twitch.tv Partner and gained over 4 million views and 30,000 followers in that position. She’s also a graduate of App Academy, a full-stack engineering boot camp.
Join Corey and Christie as they talk about what it’s like to work for an insurance startup, Christie’s thoughts on whether her four-year degree or boot camp experience better prepared her for her role at Branch, how serverless technology empowers Christie to do her best work while ignoring things like availability and scalability, how Branch was running on AWS credits for two years and why that’s mind-boggling, Christie’s advice for people interested in learning serverless technology, and more.
Screaming in the Cloud with Corey Quinn features conversations with domain experts in the world of Cloud Computing. Topics discussed include AWS, GCP, Azure, Oracle Cloud, and the "why" behind how businesses are coming to think about the Cloud.
Transcript
Announcer: 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.
Corey: This episode is sponsored in part by Catchpoint. Look, 80 percent of performance and availability issues don’t occur within your application code in your data center itself. It occurs well 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.
Corey: 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/backitup. 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 is 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 as snark.cloud/backitup.
Corey: Welcome to Screaming in the Cloud. I'm Corey Quinn. I'm joined this week by Christie Brandao, a software engineer at Branch Insurance. Christie, welcome to the show.
Christie: Thanks for having me, Corey.
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 as anything other than what you really want to have when you completely screw up Git.
Christie: [laughs]. 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.
Corey: 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.
Christie: 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.
Corey: 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 focus 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.
Christie: Yes. Yeah, it's really real. We have real customers and I'm really working on it on a 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, but—
Corey: Oh, they don’t tend to do an insurance policy speed run.?
Christie: [laughs]. 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.
Corey: 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—Epsagon 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?
Christie: 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; that’s still a pain point that we're trying to solve.
Corey: So, one of the recurring themes that we talk about on the 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 boot camp and took a job at Branch as a software engineer, correct?
Christie: Yep. Yeah, that's right. It's hard to believe that it's been already seven months of—but yeah, I am here. [laughs].
Corey: 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: spend 10 years as either a sysadmin or an SRE-type, getting increasingly angry at beating on servers and deep-level Linux, and finally emerge 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?
Christie: Yeah. 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 Sciences adjacent called Geographical Information Science where I ended up learning SQL and Python, so it ended up being great to learn different technologies.
But when I graduated from college, I realized I didn't major 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 a kind of a no-code authoring tool for eLearning, and probably only eLearning people know this tool. It's called Lectora, 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 in 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, 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, and it wasn’t—
Corey: So, it’s not just about coding or the algorithm piece, it's effectively a full-service on how to navigate the technical workforce?
Christie: 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 then 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 STE1, 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.
Corey: 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 now, would you do anything differently? Would you avoid the CompSci degree? Would you avoid the boot camp? Would you do exactly both? Would you do neither and decide, “Wow, I'd be much happier raising goats somewhere instead. Computers are terrible.”
Christie: 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—so go 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.
Corey: 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 have been in the space for, let's say, the last five to ten years and then you talk 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.
Christie: Yeah, exactly. So, when I left the boot camp, and I learned about architecture, and scaling, 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 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’ is marketing terms.
I'm sure that people still are using serverless is 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'm making for the business, and not necessarily, “Oh, 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.
Corey: 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 this 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 mind 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?
Christie: 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 grilling him with these questions, “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. 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.
Corey: 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.
Christie: Yeah, exactly. You said it better than I could.
Corey: 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 serviceless 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 ten years hard labor in the data center salt mines?
Christie: So, I mean, it's kind of difficult to answer this question 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 the traditional background, and a five-year experience in the field, and so I kind of talk 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 going to have to contact someone to figure out how to create this,” 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 environments?” 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 a hundred 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.
Corey: 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 [00:19:07 unintelligible]—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; 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, the most recent one that I did 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.
Christie: Yeah, exactly. So, when I talk to Joe about these things, one of the things he brings up a lot of the times is that we were running for two years on our AWS credits, which is just, kind of, 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 already 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.
Corey: It also—almost definitely from what you're saying—helps that you have coworkers 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, 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 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 worked? What resources did you fall back on?
Christie: 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 on 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 of 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 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.
Corey: 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?
Christie: So, I was just a part of an alumni panel for my boot camp 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 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. 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—
Corey: The first time I heard it, I heard it as ‘Cerberus,’ 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.
Christie: 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 that, just because you see these terms and they might be new—or newer—than that doesn't mean that it's going to be some type of otherworldly experience that you have to learn.
It turns out 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.
Corey: 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?
Christie: I'm writing my code and then our Lambdas are actually, most of them are a bit too large to be just writing them inline 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 happen all together in my environment, which is the copy of production.
Corey: 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?” “Yeah, 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.”
Christie: 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 on a lot about observability and how to implement that into our codebase, so she's a huge proponent of testing in production which is super scary, and a lot of people immediately probably wince when they hear that, but I think it’s really important—
Corey: I’m a big fan of testing in other people's production. It's easier. Less risk for me.
Christie: Yeah, 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.
Corey: 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.
Christie: I can't even tell you the amount of times I've audibly laughed out loud at watching people interact with our 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.
Corey: 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.
Christie: 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.
Corey: Christie, 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?
Christie: Sure. Yeah. I'm on Twitter at @ChristieBrandao. And then I have my portfolio website, which I believe you linked below, but it's just cbrandao.dev.
Corey: Excellent, we will indeed put those in the [00:29:02 show notes]. Thanks again for your time. I really appreciate it.
Christie: Thanks, Corey.
Corey: Christie Brandao, 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 and tell me exactly what kind of servers serverless runs on.
Announcer: 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.