Building Modern Apps with Serverless & Feature Flags

What are the technologies that one should leverage to build modern, scalable, and flexible applications? Julian Wood, developer advocate at AWS Serverless, talks with Jessica Cregg, previously a developer advocate at LaunchDarkly, now an information technology operations engineer at CybSafe about the mindset and tools required to build scalable software without over-engineering a solution.

---

Intro

Julian Wood: Hello and welcome to another episode of "GOTO Unscripted." We are here in the lovely city of Copenhagen for GOTO Copenhagen. My name is Julian Wood, I'm a developer advocate who works in the Serverless team at AWS, and I'm joined by the lovely Jessica Cregg who was working for LaunchDarkly. How are you, Jessica?

Jessica Cregg: I'm good, thank you. How are you doing?

Julian Wood: I'm doing very good. We are actually both live in London, but now we're in Copenhagen for a few days, so....have you been here before?

Jessica Cregg: I haven't. No, this is my first time in Copenhagen. It's a beautiful city, and I'm really excited about the venue. It's really cool seeing the big screens and everything, isn't it?

Julian Wood: Have you had a Danish yet? That's the...

Jessica Cregg: I have not had a Danish Danish.

Julian Wood: Danish and sandwiches, and I always keep talking about the food with coming to any place really, yeah.

What is serverless?

Jessica Cregg: But I wanted to ask you, kick things off with, I mean, let's talk about Serverless. What is Serverless?

Julian Wood: Yeah, so Serverless is a bit of a weird term because as with cloud it can be meaningless, and it can mean a whole lot of things. But the idea of being serverless is that you manage your applications without having to look after any servers or any pods, or any clusters, or anything kind of like that. So, you don't have any infrastructure to manage. That's a sort of operational ideal of having to have as little infrastructure to manage, get AWS to look after all that for you, so you don't have to, you know, rack servers, never mind doing that. You're doing that in the cloud, but you don't have to patch operating systems. You don't even have to patch your language run times. So, it's far more secure and far more simple from that operational aspect. Also, the other benefit is, Serverless is scale.

We handle all the scaling for you, so you don't need to add things behind a load balancer. You can scale up as big as you need really, and also as small as you need. So, one of the big tenets of Serverless is that if you're not using any service, you don't pay for anything. So, you really pay for the value, and that's a sort of useful part of it. And yes, it is a sort of new way to build applications, but part of the reason I joined AWS was, I came from an infrastructure background. I could see that this is just the way that applications are going to be built. So this is just a great way to be able to build more modern applications.

Jessica Cregg: Oh, fantastic. So, coming from an infrastructure background, did you kind of see the change in tide when it came to people planning their architectures, how they structured applications?

Recommended talk: Why Cloud Native is the New Standard • Tibi Covaci & Eric Johnson • GOTO 2022

Julian Wood: Yes. And that's it, because people are used to this sort of traditional three-tier applications, and they've got a database and some sort of processing tier and then a web tier. And from two perspectives, when I did mention the scale before, if something needs to scale up, well,, you've got to replicate a database tier, or you've got lots of different compute nodes or a web front end, and you have a sale comes on, or something happens and how do you manage at scale? You'll end up paying for peak when you're not really using that. Then the other perspective was, well, when things aren't happening, and on a weekend, you've got applications that are not being used, or you've got development environments that are not being used, and you're just paying for that unnecessarily.

And what's the other benefit of Serverless is sort of handing over control and sort of resting control are some of the things, what we call undifferentiated heavy lifting. So, things like patching servers and managing, all that kind of thing. Just let somebody else do that because that's not your core competency for the business. So, rather focus on your business logic, and the way that your application is gonna integrate with different kind of things, and that is what is new with Serverless, and that's the kind of thing people need to learn as a new architectural practice is, okay, how am I going to connect these different services together? And then sure, I'm gonna have my own code that I'm gonna run, and that's my business logic. 

Building modern applications: best practices

Julian Wood:  But I know you've done a lot of work on architectural practices. What have you been seeing, working with a company that is feature flags and seeing how applications are modernizing?

Jessica Cregg: I think the biggest thing I've been seeing is people kind of questioning why they're necessarily engaging in a practice. I'll never forget reading, I recently read one of Sam Newman's books. It was talking about microservices. And he had this brilliant anecdote, which talked about how he's running this workshop, and six people came along, and he was like, "Why are you here? Thanks so much for coming." And he was like, "Well, we were told to be here, and we were told we were doing microservices." And there wasn't that sort of engagement with the why aspect. And I think that's something that's maybe like a trend I spotted recently. People kind of potentially looking at the advantages of maybe, like, a modular monolith, or sort of stepping away from the hype of a technology trend potentially.

Recommended talk: When To Use Microservices (And When Not To!) • Sam Newman & Martin Fowler • GOTO 2020

But I find microservice-based architecture is interesting because, obviously, you can with the advent of feature flags, you can stage a service behind a feature, and you can truly delegate that responsibility, and it can be surfaced in an environment that everyone can truly access, but can be integrated maybe with your Slack instance. So, you can change a flag in Slack. It can be hooked up to your observability platform. So, say if you fall below a certain SLO, you can notice what's going wrong, see what's going wrong, and change that.  I think having that level of control, and truly distributed responsibility can lead to happier teams.

Julian Wood: I like your framing of that because I think I always tell people, especially because Serverless can be seen as a sort of newer way to build applications that people think, oh, I must be Serverless, or I must be containers, or I must be Kubernetes, or I must be anything. And I always say to people, don't change anything unless you've got a real sort of architectural need you're bumping up against. And that may be cost that may be availability that may be scale, or that kind of thing. But I always say for funsies, don't just go and change your app because you're gonna come out of that without also learning about what you're gonna be doing. But I know, you know, at least from the feature flags, one of the things with the...and a monolith is all fine.

I mean, I will never say that a monolith is bad. If it's all working for you, absolutely fine. But when you start bumping up against something, maybe it's gonna be scale or cost, as I said, as soon as you start breaking things apart for good reason, you then got something as distributed. And I know because I work with Serverless services, something like AWS Lambda, which is compute in the cloud. So, you just literally upload a zip file or a container image, and we will run your code up to your ridiculous scale or down to zero. But within that code, you've obviously got different code paths that people want to do, and they want a reason about that. So from a Serverless compute perspective, feature flags are sort of a super important thing of it because when you are using the cloud, you also don't have knowledge and visibility into how the rest of the cloud infrastructure is happening. And so, you want to reason about your production applications. You want to test in production, and feature flags is the sort of super way to do it. 

The benefits of feature flags

Julian Wood: So, how are you seeing people sort of evolve their architectures for distributed computing?

Jessica Cregg: I think the typical path I've seen so far has been people, they start engaging with us on the client side with augmenting their UIs, just standard AP testing. But they obviously need to develop at scale, speed up their processes. And sometimes we often find ourselves becoming that sort of essential middleware for people to work with. So, that's the kind of general sort of like journey of seeing other people implementing LaunchDarkly deeper than their stack. I think things are starting to get slightly more interesting when, I think there's a lot to be done more in terms of the altering...this is very much a wishlist, and that's something that isn't live at the moment, but I think we could maybe do some more interesting implementation at the infrastructure level. Like it's wild that you have to completely rerun an instance when you change something. So, and I obviously...

Julian Wood: So, be smarter with what your feature flags can give you. So, how does LaunchDarkly then work from a code perspective? You, obviously, got a piece of code, and it reaches out to LaunchDarkly to get, I suppose a value that then you can use in your code to, you know, go down this path, or display a widget on the screen or, you know, update one database or another database. Yeah, how does sort of LaunchDarkly and your code fit together?

Jessica Cregg: So, we create two types of SDKs in about 30 different languages, and they're very language-specific SDKs. You reference us like a library within your code. Implemented us in the sort of either in like an FN sort of ternary statements. So, it's right there in your repository. And we have a flag delivery network, almost like a CDN style distribution where your application will reach out, and your flag will evaluate or open a streaming or polling session. Depending on the evaluation, you'll get a different flag resolved. And it's really useful because I guess if for whatever reason your application goes offline, or your application isn't able to reach the FDN, you'll resolve to your L statements. So, it makes rolling back gracefully a little bit more of a sort of conscious decision, which is good.

Julian Wood: Okay. And I suppose the bigger picture I didn't ask about was one of the points of feature flags, as I understand it, is you could have one huge production application, and you want to test out a new feature for 1% of your users or even five users. And then you would amend your code, use this feature flag and say when it's, you know, five different people in your team are accessing this particular website, then do X, Y, and Z, and that that would happen. Then once you get confident, you could then roll that out, and that would just be changing a flag in your FN statement saying, well, you know, 5,000 people and then, you know, hopefully, your business is good, and it's 50 million people using your new part of it.

Jessica Cregg: Exactly.

Julian Wood: And then that can iterate old... I suppose that means that you can deploy more quickly because you know that your production code is running in production, and you can just ramp up and down the different features that people are using.

Jessica Cregg: Precisely. And you can also build out your...we are talking about users, but we are kind of talking about contexts really. It could be your user could be more of an endpoint and you could define a particular pathway, like a particular use case. It becomes, I think, super interesting when you look at safeguarding your application against uses that it shouldn't be used for. So, there's one particular use case I love where someone consents nefarious use of their application, and return, like, a 404 for that one person, and everyone still gets their 200s still.

Julian Wood: Okay. And I suppose it must be really quick because that sort of code checking is literally front end to the website, so you can roll out this kind of check, or block a particular user or enable a particular user really quickly.

Jessica Cregg: Yes.

Julian Wood: And then as... Yes, carry on.

Dos & don'ts for serverless

Jessica Cregg: Oh, no, I was going to say, if we're talking about what people should and shouldn't do, I wondered whether or not you have any sort of should or shouldn'ts for Serverless.

Julian Wood: For Serverless, yes, I think as with all architectural decisions, it's not biting off more than you can handle, or more than you can chew. I think Serverless has a huge amounts of benefits. And I think as with all things cloud, let alone Serverless, is to just start small and iterate and play. That's one of the big benefits of Serverless is because you pay for only what you use, if a developer is exploring a new way to do something, they're literally paying, you know, hardly anything to use it. I mean, in fact for Lambda, you get a million free invocations every month, and that's across a lot of Serverless services where there's a generous free tier that you can just explore and see how that can happen. And so, a very common way that people doing, and if we are talking about web applications is a lot of people run their own web servers, and so, they're gonna use, you know, Apache or Nginx or this kind of thing.

And a good sort of Serverless way is, well, why are you gonna manage that complexity of a big cluster to handle all your web requests? You could use a managed service like API gateway, which just allows you to outsource a lot of that API management, and still have a lot of the control. Then behind that, you're gonna still run your own code because obviously, you've gotta return stuff to your users, and AWS Lambda is a super good use case for that. And again, it's not going to scale. You're just going to upload your code in any language you can think of under the sun, and that thing is  going to be able to use that. And the cool thing is you could have a website with many different languages because Lambda function is just a small discreet piece of code. It's very easy to reason about. It's built-in, connected to the rest of AWS in terms of security. So, you know, really secure and sort of simple way that you can do that. And so, that's where I would start from a web background. If you're doing data processing, another super use case for Serverless where people have vast amount of data, and it could be streaming data, it could be event data, and it could be data you wanna pull off a queue. Again, you can run some compute, and you can, with Lambda for example, we've got polars that just we run on your behalf. So, you don't have to have a container or an EC2 instance grabbing messages off the queue. We'll handle that all for you, and you just concentrate on your business logic.

Jessica Cregg: Nice.

Julian Wood: So, that's where I'd say to start, there's actually a website, serverlessland.com. Really good website to just explore and find out the different use cases. The reason I'm actually here at GOTO Copenhagen is we've put a coffee bar called Serverlesspresso.

Jessica Cregg: Nice.

Julian Wood: And actually, you get a cool free coffee at the end of it, but it's a way to explore how you can use service architectures, and actually the sort of important bits of using some sort of orchestration and choreography. There's a bit of a microservices story into that, there's an event-driven story into that with event-driven architectures, and how it all ties together to build a suppose what would be a modern application, and we're using this sort of hook of getting some free coffee out of it. So yeah, we're actually doing that here at GOTO, and we've done it at a number of GOTOs this year, which is super good. But that just made me think something that's, I know that's near and dear to your heart, is the complexity story. I'm talking about how we desegregate things, and I know people in the back of their minds going, hang on, this is getting complicated and complex. Well, yes, what are your thoughts on that?

Recommended talk: The Many Meanings of Event-Driven Architecture • Martin Fowler • GOTO 2017

Jessica Cregg: Software gets complicated really fast, doesn't it?

Julian Wood: Yes.

Jessica Cregg: I mean, I think it's, I can't remember. I think, was it the founder of the, originated the BDD concepts, was talking about software getting complicated. It was almost like a form of entropy. Yes, it's the inevitable. I love a good abstraction. I really. That's what we're about. And I think there's always the... I mean, I've absolutely loved getting involved in the DevOps scene, and I think it's very interesting looking at the combination of people and process, and how that comes together, but obviously, where it could be so tempting to do something in a cool way just because that's the...

Julian Wood: Yes, the new hotness.

Jessica Cregg: Exactly. And I mean, when it comes to computer science, you've gotta look at a solution that is applicable and appropriate and complete for the use case, and this is the best use of performance. I'm quite excited about a session that I'm running tomorrow about how to avoid the temptation of over-engineering a solution, which is something that I'm always trying to learn myself. If you have any tips, please hit me up for that. That should be coming up soon. But in terms of learning how to do things in an efficient way, we've also launched academy.launchdarkly.com, which is a fun course that you can kind of work through with a couple of nice little replica examples, getting you going with your first feature flag. So, I think that's a good practical, tangible example of how to keep things simple and manageable, and to manage that scalability, which…

Complexity in software

Julian Wood: So, based on your talk, not to give too much away...

Jessica Cregg: Of course.

Julian Wood: ...but what are the sort of kind of tips that you would give people? Because there are some new ways of doing things that are gonna be great, and then some other things that may not be great. And some of that's going to  be, you know, people talk about revenue-driven...not revenue. Resume-driven development where you're just trying to learn something to stick it on your CV, so you can get your next job. I know that there's, you know, sometimes a push for that, but what tips would you give people to handle that complexity, and to decide what they should invest their own time and their company's time in?

Jessica Cregg: I think remembering that a lot of the solutions that we're trying to implement are inherently communication in themselves. Code is a order of instructions. Architecture is some order of service. It's, we have a lot of communication methods that we don't necessarily traditionally think of as communication methods. So, I think working with the environments that we really have to...I know everyone talks about minimizing context switching, but I think we all know being advocates that context switching can eat away at your time very easily. So working with the environments that you have and remembering that the solutions that we are already invested in can probably work harder for us. So, maybe looking at ways that we can maybe integrate what we want to do into our existing practices.

Julian Wood: So, is that a story there of sort of not reinventing the wheel, and not getting overcomplex, but using the systems you maybe already have available to you, which will integrate? And I suppose that's from a technology point of view, different parts of your application integrating, but also with people, and being able to communicate, and develop applications with teams of other people. I suppose in COVID times, these people are all across the world on the other side of a Zoom call, or somewhere, which makes it harder.

Recommended talk: Expert Talk: Scaling Down Complexity in Software • James Lewis & Kevlin Henney • GOTO 2022

Jessica Cregg: Precisely. And I think that one of last year's state of DevOps reports was talking about the importance of being able to define our communication patterns, which sounds like such an obvious thing on the surface, but I think there's a reason why distributed systems are our favorite because I think that distributed sense of responsibility leads to a better working environment, and potentially defining our organizational patterns is a good way to be able to replicate that in a repeatable, scalable way. So, that's going to be one of the methods that could be out. One of the measures I'm gonna be advocating for. That and also leveraging a good observability platform.

Julian Wood: Yes, very important. Specifically for Serverless and distributed applications.

Jessica Cregg: Exactly.

Julian Wood: And when you are using something like LaunchDarkly, you need to know exactly what's going on and where.

Jessica Cregg: Definitely. I think I am quite excited to try one of your Serverlessespresso though. So...

Julian Wood: Oh, definitely. Well, you're more than welcome to come over. Yeah.

Jessica Cregg: Great. Let's get some coffee.

Julian Wood: Let's get some coffee. Well, thanks so much for joining us here for "GOTO Unscripted." It was awesome to be able to chat with Jessica. We'll have to meet up in London, which will be much closer.

Jessica Cregg: Definitely.

Julian Wood: But we'll certainly enjoy Copenhagen at the time. So, for people who we have met here at GOTO Copenhagen, thanks so much for coming.

Jessica Cregg: Cheers.