Screaming in the Cloud - The Serverless Insurance Startup with Adithya Reddy

Episode Date: September 8, 2020

About Adithya ReddyI do everything from web and mobile to backend architecture at Branch Insurance. I started out as a purely frontend developer but after joining Branch, which was 100% serverless from day 1, I expanded across the stack and probably write as much CloudFormation today as I do JavaScript.Links Referenced: Branch Insurance Main: https://ourbranch.com/ Twitter: https://twitter.com/TheTallpantsGitHub: https://github.com/tallpants

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, or hey, bad news, it's gonna be a few more weeks, I kinda forgot about that security thing. I thought so. TrendMicroCloudOne is an automated, flexible, all-in-one solution that protects your workflows and containers with cloud-native security.

Identify and resolve security issues earlier in the pipeline, and access your cloud environment sooner with full visibility so you can get back to what you do best, which is generally building great applications. Discover Trend Micro Cloud One, a security services platform for organizations building in the cloud at trendmicro.com slash screaming. Normally, I like to snark about the various sponsors that sponsor these episodes, but I'm faced with a bit of a challenge because this episode is sponsored in part by A Cloud Guru.

They're the company that's sort of famous for teaching the world to cloud, and it's very, very hard to come up with anything meaningfully insulting about them. So I'm not really going to try. They've recently improved their platform significantly, and it brings both the benefits of a cloud guru that we all know and love, as well as the recently acquired Linux Academy together. That means that there's now an effective, hands-on, and comprehensive skills development platform for AWS, Azure, Google Cloud, and beyond. Yes, and beyond is doing a lot of heavy lifting right there in that sentence.

They have a bunch of new courses and labs that are available. For my purposes, they have a terrific learn-by-doing experience that you absolutely want to take a look at. And they also have business offerings as well under ACG for Business. Check them out. Visit acloudguru.com to learn more. Tell them Corey sent you and wait for them to instinctively flinch.

That's acloudguru.com. Welcome to Screaming in the Cloud. I'm Corey Quinn. I'm joined this week by Aditya Reddy, the first developer hire at Branch Insurance. Aditya, welcome to the show. Hi, Corey. Nice to meet you. Always a pleasure. So you're working somewhere fascinating, specifically Branch Insurance, which despite all assurances to the contrary, I refuse to accept is not what developers need to get for when they really screw up a merge. So is that roughly what you do or is there a bit more

to it than that? I would love if that was actually what we did. I would personally be the highest paying customer for that. But no, we are an insurance startup, and we sell a bundle of home and auto insurance in a bunch of US states. It's growing. And what kind of sets us apart from the technology sense is that we've been serverless from day one.

We started out serverless. We are, till today, entirely serverless. We have never had an instance running, and it's kind of like an interesting perspective, just technically, about how that kind of works in an industry like insurance, where that's definitely not what you expect. It's not, in fact. When you hear about a company that is, oh, we are all serverless,

never had an instance running from the very beginning, you think, oh, so what do you do? We're Twitter for pets, which is just like regular Twitter, only somehow 80 times less racist. But you're an insurance startup, which is synonymous for most of us with regulated industry, which means not, shall we put this, the most avant-garde technology selections, if for no other reason than explaining it to regulators and auditors becomes a more than full-time job. I mean, I had this problem back when I was working in fintech startups, where we'd have auditors rock in and ask, great, so where's the active directory credentials? Yeah, we don't really have one of those. And they looked at us like we were out

of our minds. For all I know, maybe we were. But what has your experience been when talking to other folks about, oh, we're in the insurance space, but we're also full serverless. Is there a disconnect there? Most people, when I say that we work in insurance, it's just like, see your IPL SQL queries and you have stored procedures and the best you could possibly hope for is lots and lots of Java. But it's that assumption, but it's far from the reality of what needs to be done.

Oh, let's be fair. I'm sure there are some insurance companies that are all about the.NET instead. Oh, definitely. There's like a lot of diversity in this space with technology. It's one flavor of big enterprise software versus a different flavor of big enterprise software. But again, as you mentioned, you're an insurance startup.

And the idea of approaching an industry like that that is, frankly, so incredibly rife or in need of disruption with a frankly bleeding edge architecture. I'm sorry, I just sort of look at this from a perspective of you can't help but admire the audacity of that. Yeah, I mean, we've had our own challenges, but I would say like overall, I'm pretty happy that this is what we've chosen and just the benefits that we've seen from this. I don't think we would be able to replicate what we've built so far if we were just using the architecture that you would read about on Twitter,

which is like a giant Kubernetes cluster and lots of Java apps. Just for some perspective, we were like pretty small i think when we launched we were two engineers inside the company plus three people helping us out from uruguay and right now we've just added a bunch more people but we're still about 10 software developers and we've managed to launch a complete insurance product that you can buy from five states everything works And people kind of don't, they're not able to reconcile insurance plus tiny team that builds stuff fast. And I would say probably the biggest thing

that's enabled that for us is just not having to worry about a lot of things that serverless takes care for us. Now, as you mentioned, you're 10 engineers and you have an established track record. Your founder, Joe, is a known entity on the stage constantly at Serverless Conf. The hardest part is getting him off the stage long enough to have a conversation with him. And now it's a known thing, but you were the first engineer hired at Branch.

And what was that like walking in the door? Because my immediate knee-jerk response to, hey, we're doing this very legacy, very controlled thing in a brand new way architecturally, it sounds like hacker news broke loose somewhere and is now dictating architecture. Today, it makes an awful lot of sense. But grinding back the clock a few years when you first started, did it seem as nuts then as it sounds like? So there were a lot of very odd things about how I ended up here. For one, so for some backstory, I was in my final year of college in 2018. And I was like,

okay, I need to find something to do now or I'm going to be broke. So there was a thread on Twitter. I forgot who it was. and it just said, if you're a new guy looking for a job, put your resume here, we'll critique it for you. So I put it up and I got a DM from Joe who said, yo, I'm looking for an intern, a front-end developer intern, would you be interested? So the whole thing was very suspicious because that's not the kind of offer you get on twitter dms so and then as i found out more about it it's like oh we're gonna build an insurance startup and and everything was just very fishy about it but i kind of thought you know i'm out of college now if i'm gonna do something stupid like ridiculous job beats no job

yeah so i said yeah let's let's go for it. And I was an intern at Brunch for six months. And at that point, I mostly just used the front-end stuff. So I would build the front-end UI. I did some React Native stuff for our mobile app. And I did some weird UI sketches in Balsamiq. And all that ever convinced me was that I shouldn't be designing UI. And it just grew into a proper company and everything just sort of came together. and Balsamiq and all that ever convinced me was that I shouldn't be designing UI. And it just grew into like a proper company and everything just sort of came together.

And that wasn't really something that I expected. So, I mean, now it's like I'm really happy that that's how it's like all come together. And we have a great company running right now. But it was just very strange to me that we're building an insurance startup. And also when I joined, it's like, oh, we're all serverless. And the day I got there, I asked, okay, so I'm going to build your front end now. Where's the API? And he said, oh, there's no API.

It's like GraphQL. And I said, well, what's GraphQL? That was like a big rabbit hole. And then I said, okay, so where's the backend running? And he's like, it's not running anywhere. It's just, it's serverless. And that was like another six-month journey for me to discover that all the stuff that I had learned in college was kind of not as mandatory as they made it sound. I had to go through that same transformation myself

only instead of college, because some of us never went, or at least never graduated. It was, well, just unlearn the last 15 years of your career. It's fine. And that 15 years of the career was spent on things that are now largely irrelevant in a serverless world, but they were the entire core of what I did. So for an awful lot of folks looking at this with suspicion and distrust, it's not even so much a problem with the architecture or the constraints itself,

but rather that it sort of cuts at the core of our identity. For the longest time, I was a Unix Linux server administrator, and now there are no servers for me to administrate. What does that make me? It's the evolve or die dinosaur type of paradigm. And I won't lie, it's scary. Oh yeah, definitely. I mean, there's still a lot of the questions that I get from people who I talk to when I tell them,

this is what our architecture looks like. Where's your DBA? Where's your on-call? Where's your DevOps person who manages the infrastructure? And it's just, Amazon does it because they do it better than I could. So why would I want to take on that load for myself?

And a lot of people seem to have just gone in the opposite direction of, I want to self-host everything. And to me now, with the perspective that I have at branch that seems just a tremendous waste of time and also just a tremendous amount of stress and responsibility you take on yourself why would I try to do what Amazon has been doing for a decade now and they have people who are paid much more than I would be able to pay someone to do it. And they're going to do a better job than me.

So why would I just not leave that up to them? And I will do what I'm good at. And I will do what my company needs. So the big focus, the big shift for me has been coming out of school as I'm an engineer. And I do tech stuff. And that's what I care about. And it's all about the technology. And it's kind of changed to what does the business want and what do we want to build for our customers? And if we can pay

someone else to take care of the stuff for us and we can focus on the product that we're building and what our customers want, then that's like a net win for me. It really gives you the opportunity to focus on some level on the things that differentiate your business, that lead to success. I spent untold weeks or months of my life in aggregate now configuring and building load balancers. But I never worked at a company whose job was to build the load balancer. It was always to do something else, be it, I don't know, help with expense reports or help dogs tweet to one another. It was never aimed at, I'm working at a load balancer company. Like, yeah, if you work at F5, you probably should spend a fair bit of time building load balancers. But for the rest of

the world, that is no longer a differentiator or internal core competency that you need to have in most companies. There are always exceptions, and there are always going to be these expressions of those core competencies. I'm a big believer in the idea of the T-shaped engineer, where you should be broad across a wide variety of different things and deep on one or two areas. I started off being deep on email systems, because every company back then needed an email administrator, and I thought it was fascinating and the closest thing I'd ever seen to magic. Now I look at this through a lens of, huh, it was pretty clear, in retrospect, that fewer and fewer companies ran their own email servers, so this was not going to be a job for most companies. Instead of every company needing

dedicated email people, there were a couple dozen, and that was it. I wanted to go with something that had a bit more mass market appeal. And one of the neat things about serverless is that it seems to me, at least, that it's making every engineer, to some extent, step through that gateway. Oh yeah, definitely. I think one of the things that won me over about this whole architecture is that I came out as a front-end developer.

That's what I do. I want to write React apps. And what was kind of interesting to me is that Joe was like, that's fine, you don't have to learn this stuff. And all of the engineers that we've hired have also just been front-end devs primarily. And we've always had the confidence

that they'll just be able to pick up whatever they need to do for the back-end just because there's really not that much to be done, right? There is no setting up a server, there is no load balancers, there's no, how do we set up this relational database, and how do we make sure that the replicas talk to each other? There's not been any of that. What has to be done? Can you write it in JavaScript? Cool, so let's put it on a lambda and then it'll run. And what do you need to store? Can we put it in JSON? Sure. So let's throw it onto DynamoDB. And it's just been, it kind of moves the barrier to entry quite a bit back. I wouldn't say it removes it entirely.

There's still like, you know, you kind of have to be an engineer. It's not like a no code thing, but it makes it so that you as a front-end developer suddenly have a lot more power, so to say, about what you can build without having to rely on, I need the DPA and I need someone who knows Java really well and I need someone who can deploy things to clusters and knows about Linux. It's just removing a lot of those things has kind of made it so that we've hired engineers

who have just been purely front-end and then in two months, they're writing CloudFormation and setting up SQS queues and reading messages off it. It's just been really, really refreshing in that sense. One of the things that you're almost certainly going to hear from the Hacker News Well Actually Brigade is, ah, but by going with serverless, you have now locked yourself into AWS. If you were to want to port branch insurance over to GCP or Azure or to your burning dumpster fire of your own data center, you're going to have an awful lot of work to do that. So you've made a grievous error,

and now you are beholden to whatever Amazon decides to do with you. How do you feel about that? I mean, initially, I kind of bought into it. You find new young developers and put them on Hacker News and just they're going to absorb everything and the end result is not going to be pretty. Luckily, I had a lot of people who kind of, yeah, no, just don't fall into that click, let's say, of Hacker News use and the realization for me about lock-in has been yes you're not going to leave amazon anytime soon but then i have never seen a company who are like yeah we're going to leave amazon for google because amazon has like decided to

screw us by raising their prices and as far as i know I don't think Amazon has ever raised prices on anybody. It's always been a concern, how do we make things cheaper, and sometimes far cheaper. And also the lock-in, it's kind of, there's this assumption built into that statement of if we don't use serverless, we are not tied to Amazon at all

and we can just leave at the drop of a hat, which is not true. There's a lot of stuff set up implicitly, maybe not documented very well, but there's just a lot of stuff going on with the way you set up your clusters on Amazon, on the way you use EC2 or the way you set up your load balancers or your network or your DNS. You're not going to be able to port all of that to Google or Azure tomorrow. So we're just talking about degrees of how hard it's going to be to migrate, notwithstanding the fact that it's very, very unlikely that you'll ever have to migrate.

And then also it becomes, if you work and build apps with the mentality that I need to be able to switch this away to other providers at the drop of a hat, you're kind of locking yourself up in saying that I will only use the lowest common denominator of services. And you're just making life harder for yourself. So why would you make the 99% case much harder to solve for the 0.1% case of, oh my god, Amazon is screwing us and we need to leave and go to Azure right now? In what you might be forgiven for mistaking for a blast from the past, today I want to talk about New Relic.

They seem to be a relatively from the past, today I want to talk about New Relic. They seem to be a relatively legacy monitoring company, and I would have agreed with that assessment up until relatively recently, but they did something a little out there. They reworked everything. They went open source, they made it so you can monitor your whole stack in one place, and most notably from my perspective, they simplified their pricing into something that is much more affordable for almost everyone. There's even a free tier, with one user and 100 gigs per month, totally free. Check it out at newrelic.com. I agree with everything you just said, but by hearing someone who's actually built something on top of these technologies, it comes across as way more genuine than if I sit here on my

pedestal of thought leadership, which turns out not a real thing, and then go and tell everyone that, oh, this is what people should or should not do. Hearing people who have made actual business decisions around this is one of the most authentic ways to make the point. I keep looking for people to take the other side of it. Like, oh no, we actually had to build something in a way that was portable to other providers. But you never see them taking advantage of that capability. It always, for whatever reason,

comes down to a baseline model of, well, we built this optionality in and kept everything agnostic, and then we feel better about running it all in AWS or GCP or Azure or wherever they happen to be running. But it's an optionality that people never take advantage of. So my position is go all in on a provider, I don't care which one, and see what happens. If you have to move later, at least you've survived long enough to get to that point of

having to make the pivot rather than spending all of your time working on these agnostic shim layers rather than building out features that will move your business and get you to the next milestone. I agree with that. One thing that people don't realize is that you might think you're building an agnostic application, but I can almost guarantee that in 99% of cases, if you have to move your cloud provider,

you're going to find out it wasn't really as agnostic as you thought it was. That's one of the things that I find so, I guess, ridiculously strange as far as these people talking about, well, what if? What if everything changes and we have to pivot massively? Well, what if AWS shuts down?

Okay, let me back up for a second. If AWS shuts down, are any of us going to keep our existing jobs? Or, far likelier, are we going to instead pivot to helping all of these companies with big problems and bigger pocketbooks migrate off as fast as they can? unrealistic outcome that I can't quite fathom. It comes down to where do I want to spend my time? I don't really think that hedging the risk of this cloud thing being just a giant fad is the best use of my time anymore. That's true. Also, it also just comes down to probabilities. You know, what is the probability that you are going to run out of money trying to build everything yourself versus the probability that AWS is just going to decide that, you know what, screw you, we're going to raise all our prices. And it's just, I feel like a lot of people just want to tinker with cool stuff. They want to tinker with load balancers and play around with

Linux and that's fine. But it's the fact that I'm going to justify this as with a business reason that I really don't get. That's very strange to me. So one of the things that you put in your biography that we always ask for, so who are you and what do you do when people sign up to record an episode here, is that you started off as a front-end engineer and now you write at least equal amounts of JavaScript or JavaScript, as some pronounce it, and CloudFormation, which is interesting on a couple of levels.

We'll start with the easy one first. Why CloudFormation instead of Terraform? So I think there's a couple of reasons for it. The primary reason that we started off with CloudFormation is that we have a really excellent partner in Stackery who support CloudFormation really well. And they give us a lot of help with our tooling. And a lot of times it's been, we need this feature. And we ask Stackery, like, hey, how do we do this? And they say, oh, no, we can't do that yet. But thank you for pointing that out. We will build it for you. And we have it two weeks later. So that was kind of the reason we started with CloudFormation. And then as time has gone on, we kind of realized that it's a lot simpler

to do things with CloudFormation if you're primarily being serverless on AWS just because of SAM and the way that AWS is kind of supporting it. And they're doing a lot of work by creating these specific serverless resources of an AWS colon colon serverless function. So having that kind of higher level abstraction over the base CloudFormation, which kind of encapsulates all

these common patterns of here's one resource you can declare that will create IAM roles for you. And also our CLI is going to package up your code and upload it and then set up the function running. And, you know, you have things like an HTTP API resource, which would be very, very hard to set up manually. But because of this kind of thing where Amazon has seen the patterns that are generally prevalent with serverless applications and made it much easier to use,

and they seem to keep iterating on it, that's been a big plus for us. And also just having the state of your application be managed by Amazon itself, like the rollbacks and updates and Terraform's kind of coming there now with their Terraform cloud offering. But that's how we've started. And now it's maybe Terraform can do some of what it does, but I would much rather bet on CloudFormation in the sense. Of course, if you're doing this on not AWS, you probably might have a different answer and you should do your own research and come to your own conclusions. One of my favorite things is watching people, I guess, incorrect each other on, oh, well, you should only ever use one or the other or some other system because of this one weird edge case that it turns out hasn't been true in three or four years. But

as a counterpoint, I have problems personally with JSON. Specifically, it doesn't parse as well as YAML because I have a Python background and whitespace messing things up for me has really been my entire career. So back originally, CloudFormation only supported

JSON. And then one day, bam, YAML showed up. And this was awesome. And this was great. And one of the problems I saw for the longest time was that all of the examples, all of the blog posts, all of the stuff people had written, it didn't really matter because all these examples and this giant history with CloudFormation had been written in JSON. So it took time for there to start to be public examples of what the YAML version of it would look like.

And I'm wondering, first, if you've encountered that, and secondly, if that seems like it's a bit of a carry forward into other areas where a new feature comes out, for example, but all the old examples don't demonstrate how that feature works. I mean, I've seen my Fed Sheriff share of Google, how do I do this? And then it's like a bunch of JSON. And I personally think the JSON representation of CloudFormation is pretty hard to read. There's no comments.

There's no lots of flex spacing. You can't really differentiate things for the reader. So luckily, if I just copy this JSON and like paste it into a JSON to YAML converter it does have to work it's not going to be accurate but it's useful enough that I can write my own YAML now looking at that or you could just write your own YAML looking at the JSON but I think in general this is something that most developers kind of have to pick up as a skill of how do I differentiate old information and how do I not fall into the trap of reading old blog posts or old books and thinking yeah

this is how it is now just because this field changes quite a lot and this is kind of like just the general skill that you need because a lot of stuff on the internet when it comes to anything related to software is going to be outdated. And you need to figure out what resources that you need to use. And also trust the authoritative source of Amazon's documentation first. And only then go around looking for supplemental information, let's say. And also be very suspect. Look at the date of the article before you start to read it. And don't take anything you read as gospel, because it's quite possible that the thought leader whose blog post

you're reading also might have been wrong about something. Oh, my stars, yes. One of the hardest challenges for me when I'm putting together my newsletter every week is I see a lot of things come across the wire in terms of blog posts that touch on what the community is doing. I have to vet these because some of them are not just poorly written, but actively harmful. I saw one somewhat recently that's, oh, you can save money by moving all of your S3 long-term stuff into Glacier Deep Archive.

Well, yes, you'll save some money, but there are some serious constraints around that, around access times, how it's billed in certain ways. And it didn't even hint at some of those. If you blindly go ahead and click through, sure, that sounds awesome. It's not going to go well for you. You want to make sure that the thing you're applying is relevant and it takes your constraints into consideration. In some cases, it feels like people write things that don't even take their own constraints into consideration. It's more or less Hacker News fan fiction.

Oh yeah, I mean, you'll see this a lot in Hacker News specifically. You go look at a post about, oh, look at this cool new thing I built, and you look at the comments and it's all, oh, doesn't this have this issue, and doesn't this have this bug? Oh, this was fixed in 2006, but it's just, you did it once, and now you just, I mean, it's a general thing in software, where you did it once and now you just i mean it's a general thing in software where you create it once and you just like assume like yeah this is like a constant this is not going to change but stuff changes all the time and you always have to approach everything you read in this industry with a lot of skepticism about is this still up to date does this person know what they're talking about even if Does this person know what they're talking about? Even if this person does know what they're talking about,

have they made a mistake with this? Do your own research. And also, it kind of applies to you to know that your own research isn't infallible, and you're going to make mistakes. And when someone else points that out to you in a blog post, let's say, don't go to the

hack and use comments for that blog post and point out how the person writing it is a really stupid idiot and they don't know what they're talking about. Oh, absolutely. People don't know how to, in many cases, ask questions or answer them. I tend to assume good faith and I find that I am pleasantly surprised way more often than I am negatively surprised when I do that. I assume that people are asking a question that they've tried the basic things. I assume that they're asking in good faith, not trying to prove a point. And I assume that when someone says, I'm looking to do X with Y technology, that the correct answer is not Y technology sucks. There has to be a reason that they're asking this question.

Helping, in some cases, clarify and refine the question is a better path than assuming they're a moron and lighting into them. I wish more people took that perspective, if I'm being perfectly honest and grouchy about it. I couldn't agree more. So if people want to hear more about what you have to say, where can they find you? You can find me on Twitter. You can follow me on GitHub. I should start a blog sometime soon, but i just never get around to it the story of our lives you are the tall pants on twitter and we'll put a link to that in the show notes of course so aditya thank you so much for taking the time to speak with me today i really appreciate it great thank you thank you so much thanks for having me of course thank you for

taking the time aditya ready first engineer hired 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 this podcast, please leave a five-star review on Apple Podcasts and file your complaint in both JSON and YAML. 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