AWS re:Invent 2019: [REPEAT 1] Building microservices with AWS Lambda (SVS343-R1)

thanks for joining me here today this is a deep dive into Microsoft Access in the cloud hope you guys are all in the right room because they just locked the door so buckle up no just kidding this is SVS three four three building micro services with AWS lambda I've got a lot of content here or plugin use up almost the whole full hour here going into stuff my name is Chris Mons I am currently a senior manager and principal of developer advocacy for serverless here at AWS been at AWS for a little over seven and a half years now across a couple different roles but basically for the last three years completely focused in this world of service and so I lead a team of people who maybe you've had a chance to see speak or lead workshops or read some of our recent launch blog posts this week but a whole lot of stuff going on in this space so why are we here today so as we were ruminating about talk topics and the things that we would talk about reinvent one thing that we kept coming back to was this this trend that we keep seeing the industry and it's this idea that somehow the two terms containers and micro services seem to be kind of married together people kind of sometimes conflate the two and I think it's very important to understand that containers are a delivery mechanism micro services are an architectural pattern and micro services existed before containers containers can be used to deploy monoliths and so basically the two shouldn't necessarily always be thought of in the same sentence and so what we wanted to do was find to do talk where we would break down some of this and talk about how lambda can be used to build micro services and so again that's basically that the gist and the point for today now in terms of micro services at Amazon AWS we've been building micro services for a really really long time since the early 2000s this is a diagram of all of the services that were inside basically Amazon slash AWS and wrote circa 2008 2009 and so you can see here many many many hundreds and thousands of application points and black lines basically represent dependencies across them and so somewhere in the center of this Deathstar if you will or things like identity services security services and user management stuff and if we were to draw this again today it would be many many many times the size of that in ten years a way to think about this another reference point is that last year Malin who is on the VP of storage services at AWS here at reinvent spoke about how when s3 launched first back in 2006 was made up of eight micro services so the very first part the very very first version of s3 that you would have consumed back then eight different services and then when we looked at s3 at reinvent 2018 so again a year ago at that point in time it was now two hundred and thirty-five plus different micro services so again over time we keep expanding and building this out and building this out and I like to say that some number of these are lambda based like I can't give any direct specifics but again when it comes to micro services we do this a lot at Amazon and we have a lot of repeatable patterns for it now one pattern that I like to talk about is something that you'll see others in the industry talk about which is this concept of the micro services iceberg if you will and so with the micro services iceberg there's this idea that you typically have just a single public interface usually that kind of sits above the waterline so in the public range and then below the waterline you have all of the other services that you are that that support that public interface and the overall capability of the product so again if you think about s3 you're not talking to two hundred and thirty-five different API endpoints for that one service you talk to the one s3 API and then all those other capabilities are kind of mimicked and hidden behind it and so I also like to call this the the micro services mullet we've got API is in the front party in the back or a sink in the back if you will and so there's a bunch of again common patterns that we see with this so when we talk about you know microservices we're very often talking about API driven capabilities so on that front end where we have this more synchronous direct client or direct to customer capability that's again where we're typically using things like traditional HTTP web or mobile clients we're gonna rely on things like API gateways or load balancers to provide access into our actual application that's running and we typically have again some sort of rich or flexible client interface if you think about most HTTP your REST API is the number of capabilities and we're focused on securing against the client verse back on the party side of things underneath the water here with our asynchronous services and we'll talk a lot more about asynchronous later we've got much much simpler interfaces typically things aren't as flexible very similar purpose maybe we're making use of a service to help us with messaging between that front end and that back end and we'll talk about a bunch of events or assuming that you can do as well and then again you're gonna have a much more opinionated event and message model this isn't something that's going to have a lot of different dynamic customers you could have micro services that have basically one-to-one mappings to each other inside of a larger application so we're gonna kind of follow through a simple model here today of just a very simple iceberg we're gonna have one public service one non-public service and we're going to talk about some of the options that you have for thinking through this and I'm gonna give a bunch of what I would say are semi opinionated I'll say they're heavily opinionated thoughts on how to choose certain technologies make of it what you will but hopefully you get some good guidance to all walk away from this talk with some things to do so again we're gonna have a front-end component that public component we're then gonna have what I consider the the backend or again below the waterline component and then in order to support the two of these there's going to be some number of shared capabilities or shared things that we're going to make use of and so again we're gonna basically fill in these boxes here today with different technologies to serve this now this is a session all about lambda so we obviously have to spend a little bit of time here talking about lambda so a Nimbus lambda is a compute service we first announced it here at reinvent five years ago and so it's in in AWS where all this makes it an old dog spin around for a long time Latin to throw for those of you are new have some really interesting unique characteristics when it comes to building applications with it they make it different than just building an application inside of again a container or VM or even physical hardware so again lambda is a compute service we consider a service compute service what does that mean it means that it meets four key criteria for us at AWS one that there is no physical virtual or container orchestration that you have to manage in order for this compute resource to work it's highly available and it has security built in from the base of it it also like many of our cloud services should automatically scale that means both up and down without you having to think too much about what's involved in that and the last thing we say that with lambda there's this concept of pay for value we talk about pay for value typically means that when you're not using it you shouldn't have to pay for it but actually just yesterday we announced a new capability for lambda called provision current provision concurrency provision concurrency helps solve what many of you may know of as a cold start issue with lambda and it allows you to basically pre-warm a certain concurrency capacity for lambda now you end up paying for that so you are essentially paying for the value of having that available but again it's a little bit of a tweak to the model for lambda and again this was just announced yesterday afternoon on the twitch launchpad now code inside of lambda is deployed in a unit that we call a function and typically we think of functions being very granular very purposely built very much aligned with very single or small number of use cases and we'll talk about that a little bit more here as well today it also has some other unique characteristics that come in the form of effectively limits in the function so today a function can have anywhere from 120 megabytes up to 3 gigabytes it has a maximum 15 minute duration for a single execution the application artifact can be a maximum of 250 megabytes and we give you another 512 megabytes worth of temp storage now there are some other limits that are out there around things like open file handles and some other stuff but we're not going to get too too indepe on that today now the unit of a function also has a number of characteristics towards what you can configure with it so things like security which we'll talk a little bit here about security but you can make security and performance patrols very granular to the function and so it gives you the ability to get you in really really fine-grained across your application but there's another key point that you really have to understand about lambda which is this fact that it is an ephemeral environment so what this means is there's no ability for you to say have a sticky session down to a lambda function it's a really poor practice to store any sort of important stateful information in there because what we do is we run a massive compute massive massive pools of compute and we execute your functions on those but we basically every now and then turn them out them as we call it behind the scenes and so there's no way for you to be able to store state on a lambda function and repeatedly get to it for any prolonged period of time now with lambda you pay in the original on-demand way per invocation and then for the duration of the function and the new provision concurrency model that we just announced yesterday you also have a provision concurrency rate that you pay but the execution or the duration cost is actually greatly reduced so if you actually use provision currency really well and it has a heavy utilization you actually save money on your lambda workloads first the will we now consider on demand model another thing that makes lambda really unique is that there's no concept of a socket or a port for lambda you can't directly talk to it on the network you can only access or invoke a lambda function via its API and so because it has this event API driven model again you think about it a little bit differently than if you were running say an application on a container and you had you know a sidecar or you had something like nginx or something else that would be presenting out the interface to that you can only talk to lambda via its API and we support two core models and how you can invoke lambda functions synchronous and asynchronous and so you do have again a couple different ways that you can use it now we talked about a service application there's basically three components that make that up there's some sort of an event source today we have over a hundred different services of AWS that can either directly or via SNS or event bridge or another service invoke lambda and this represents everything from endpoints so let's talk about UK gateway here in a little bit but also services like Alexa some of our I Oh T services changes in databases dynamodb for example and then also in responding to events that happen inside of your infrastructure so this could be dev tools Mena's with tools security tools all sorts of things that can directly invoke lambda that will then go cause again an invocation essentially running of your code today with lambda we support six languages that we manage for you so Java node.js Python Go dotnet and Ruby we also have something called a runtime API which allows you to bring your j any language that you could think of to lambda so you have customers running things like PHP and Swift other jvm languages and stuff like that and the last whatever it is that your function does talking to different databases or data stores that's entirely up to one of your business logic is now we're not going to spend really any time here talking about different databases or data store options the scope for that's a little bit too big but what I do want to share is that also just yesterday we announced great improvement to being able to make lambda work with your relational databases in RDS announcing something called RDS proxy and so what RDS proxy does is it does connection pooling and management for databases so you can connect your lambda function to an RDS proxy and then the RDS proxy to your database and it greatly helps reduce the amount of connection management that you would have had it done previously before we launched the service so really really big improvement in terms of database connectivity with lambda so again this is a talk focused on lambda so we're gonna make lambda B both in the front end and the back end of our microservices architecture but the next thing that we have to figure out is how are we going to front our our lambda based API and we've got a couple different options here at AWS today for how you can do this I'm really happy that the slide didn't get out of date from Monday till now um although it did a little bit so I'll talk about some really exciting stuff here for API gateway that literally before I walked in the room we just published the launch post for so you're the first people to hear about it I think in person today so three different options Amazon API gateway application load balancer which is part of the overall load balancer family that we have here at AWS and then AWS app sync and again all three of these have the ability to represent what we consider an API out to our end client now with with API gateway I say here that we have two different types of api's that we support but we just announced a third so we have rest-based API S which is the first type of API that we announced API gateway for and then we added WebSockets last year just today we announced basically a new version of API is that we call HTTP API s HP api's are a bit of a simpler way of doing what you could do with REST API is before it's 70% cheaper than API gateway was previously for REST API is about 50% of the overhead that you had on top of it it also has a bunch of new capabilities around different authentication models better cores support a number of other things that we think is gonna make this pretty exciting so this is again brand-new it's in preview but you can check that out after you leave this talk if you want but with API gateway across both rest WebSocket and now this new HTTP model we have a number of other things that basically are pretty standard for it we've got caching we've got throttling in usage tiers we could do things like Client SDK generation we support a couple different types of API endpoints so we can do what are called edge which include a CloudFront distribution regional which as the name sounds are available public within a region and as well as private API so for things like internal micro services inside of the V PC and again we've got a bunch of talks this week that go a little bit more in-depth than this so SVS 2 + 2 + s vs 402 if you don't get a chance to catch them this week definitely check by the end of the week or next week when the recordings and slides are made public so that's API gateway and again big new announcement here today just coming out about lower costs faster whole bunch of new features and we think that folks gonna be pretty excited about that the next is application load balancer and so application load balance are again part of the overall load balancer family that we have here at AWS it just supports HTTP or GPS based endpoints so it doesn't have any sort of opinionated interface around rest or WebSocket or anything like that it's basically just going to forward an HTTP request back to a lambda function supports a concept of path based routing so what this means is you can have a single little alb and you can have some part of your site or your API live in say containers or ec2 and then some part of ant lambda so it could be really good if you need to mix model some of your application for some reason allows for things like URL redirects custom HTTP responses and again it can integrate with more than just lambda which technically API gateway can as well now the pricing model for this and apologies I didn't say the pricing model is a PA gateway it's per request and data transfer for alb the pricing model is per hour so you pay for a time period and then for something called an LC you and so an LCU is kind of a interesting metric that combines thing is like connections data transfer and a number of other things but it's a little bit of a different pricing model for how you think about hosting web services and finally we have a two-bit SAP sink so ATM SAP sink is considered part of the mobile family here at AWS and it's just kind of by organizational where it lives but it's actually a really flexible service there's a lot of capabilities now app sink is built to host what are called graph QL based api's graph QL is kind of I'd like to say it's kind of a slightly newer technology in the industry but really it's been out for a number of years now Facebook uses it companies like Starbucks have started using it very heavily and it's pretty cool technology that allows you to take a single API and be able to map it back to many different data sources different data tables and write really really rich queries that have the ability to pull data from multiple places in a single query so with Apps Sync I could write a query that gets data from dynamodb from elasticsearch from a lambda function from a relational database and present that back as a similar response to my client so as opposed to a traditional rest or HTTP based API where I might have to say get information about one thing get information about something related get information about something related I can pull all this information in with a single graphic ul request so appsync has again a bunch of different capabilities you could talk to a number of different backends including lamda including relational database creating dynamodb elastic search I believe a couple others has really deep integration with something called TD amplify framework which is a front-end and mobile framework that we have here at AWS that itself is also really powerful so we can do cogeneration in a number of other good stuff like that and it also supports a concept called subscriptions and then offline sync which can be really really useful for mobile applications and being able to handle clients that come and go and data that might be between different apps and then much like API gateway it basically has a payment model that is per query and then data transfer now if we look at the three of these there's a chance that any one of these could solve the problem that you need to solve so sometimes it can be difficult to give really direct guidance on what is the right choice but what I've tried to do is give kind of a very simple what I call cheat sheet or how you could think about these so if you have a really complex rich API that maybe needs to talk to multiple data sources or support really complex queries across data sources then appsync could be a good one for you and again graph QL is becoming a really strong industry standard if you haven't looked at or not familiar with it yet if you need WebSockets that Amazon API gateway is probably your best bet so we have WebSocket support and API gateway which is really cool we see this being used in IOT applications and real time applications dashboards chat apps all sorts of things like that if you need to do anything that might involve you interpreting the request or the response doing what we consider a transform on it so adding data taking data way changing things like that if you are exposing an API out to third parties that maybe you don't control so if you're going to expose an API to customers and charge them for it and they can design clients against it where you need to care about throttling and usage tiers and advanced security controls then API gateway is definitely the best option for you you're gonna want to go with that right away however if you have a really kind of basic straightforward API you want to do more of the ownership of those things in your own code base and you potentially have a really high throughput then alb might actually be the best bet for you and we can find that at really really massive scale alb could be a little bit cheaper now this is up until the recent announcement today with a new HCP a type of endpoint for Gateway whereas now I would say the cost changes a little bit but again with alb a little bit simpler product a little bit different pricing model at scale that can be again a little bit cheaper than any peg gateway was and then lastly this is kind of the catch-all if you have again a pretty standard API it's maybe not massive scale and it doesn't have necessarily a ton of again some of these other unique capabilities that you might need then just starting with API gateway is a good place to go and again I would say with the new HTTP API support that we have this could be a really great option now for some of these other aspects to this so for my front-end here I'm gonna go with API gateway and it's going to again invoke my lambda function on my behalf when we get requests now real quick about security and this again goes for the rest and WebSockets not for the new HTTP API gateway capabilities which we just announced about two or three hours ago various different options that we have for authorization out to my client so out to my mobile or web or whoever might be consuming this API so I'm saying can leave it open probably do that but there could be use cases where I do I could use AWS identity access management or I am which probably everyone in this room knows is one of the core services that grants roles and permissions and access to services at AWS we use the service called Amazon kognito which allows me to create either a federated or a user pool to manage the users and the last day I can actually use lambda as a custom authorizer for my api gateway so i can use custom logic and lambda may be tied back to a different user management service or some sort of other way of managing my users with my api gateway now one topic that i want to touch on real quick here is something that i think is very unique to what we have here with lambda and api gateway put together and so assume that we have an api and with our api we've obviously got a number of different you know essentially routes or actions that we want to take inside of that api now for some of you this this this could mean a couple different things but one question that we often get is where should I think about doing the actual routing of how I handle this now one thing that we see increasingly is that a number of the third-party language based frameworks that are out there well actually you want to do this inside of the lambda function so if you look at things like spring boot if you look at flask a lot of those have built-in routing capabilities inside your code so you know well option here is that we could use the built-in capabilities of API gateway where we could map an individual route back to say an individual lambda function we can do this very granular we can do this on the method and the action level so we have a whole lot of lambda functions very very small focused on a very small use case of my API and then if we thought about doing this the lambda way and again this is typically done with certain language based frameworks what I would do is basically proxy all of the requests just to a single lambda function and then have all of the code and all the capabilities inside of my one function so there are a number of people who like to do this now this can work out pretty well there are some benefits to it but I also want to highlight some of the the characteristics and concerns of it now again when you do this you have effectively what I like to call the lam tool if it's a it's a large monolithic lambda function that has a lot of capabilities built into this and again for some of the frameworks that you see they will they will say this this is the way but against some of the challenges that you have here is that you you essentially end up again treating this one lambda function as the entire application so things like security and performance now apply to the whole you can't configure a per capability I am role or lambda configuration for performance I you still have the same limits around the total application size for your function so again that 250 megabyte artifact so if you end up having a really flexible or really I would say complex capable API where you have to include different libraries and the third-party packages all of a sudden you can max out that artifact really quickly the limited duration of your function so again you still max out at 15 minutes typically not that much of a concern with an API if you have a 15 minute long-running API apply do something pretty unique you probably have a really unique client for that but again these are a bunch of some of the trade-offs that you want to think about and so I really see kind of two two different types of thought processes again in this kind of like it's just like a two-team type of an option again with team api gateway you're saying i want to use the built-in capabilities of api gateway to handle basically what it's meant to do so maybe I need transforms maybe I need very granular permissions or very granular performance settings that I want to set and you only really do that with API gateway in front of lambda this is also going to have better capability with lambdas with AWS tools so things like cloud formation any W Sam amplify framework all of those things are being met more for this model however on the lambda side of things you still get some benefits so again you can make more use of the full capabilities of some of these third-party frameworks and some of them are incredibly powerful and you might have been using them for a while now and they're just ingrained to how you develop applications and we like to say that if something's working for you don't change it we les there again there's a strong benefit reason why you could find that it potentially allows you to have essentially better portability now for some folks this is a big thing that they care and they're concerned about and so if you use a framework and it allows you to pick up that code and run it in a container or run it in lambda then that could be a benefit that you care about the next is that you have fewer security constructs now I just said that this was potentially a con of this model but one of the common bits of feedback that we get about the previous model is that you end up with a lot of sprawl of I am rolls I am policies configuration that you have to manage and so with that sprawl of all of that configuration and all of those things you do have a little bit of overhead in the you know overall management and construction of that and then lastly one of the things that's been passed down out there about this is that it can lead to fewer cold starts so again for those who are familiar the cold start is basically this concept of when we get a request are we getting an invocation from an event source we have to find an available compute source that's aligned to your account that's running your application code to handle that if you don't have one we have to then take from an available pool pull your code into it bootstrap that environment and then execute it and so that period of time there is called a cold start and so one thought is that if you have all of your code inside of a single function then you would potentially have many fewer cold starts because if we just continue to reuse that same function over time and across all the various capabilities that you have however Yong Kui who is one of our community heroes focused on surplice wrote a blog post about this and he found that it's kind of a toss-up doesn't always really work out that way really depends on your application patterns but there are some folks who say that this is a big benefit for it so which which one should you choose what is the official guidance from AWS fortunately the official guidance is that it's really kind of a toss up we don't really have the ability to say always do this and again the one thing that we don't like to do is tell you I don't know stop everything that you're doing that works for you take all that development experience that you have these frameworks that you love stop using them immediately they're wrong so again if you have a framework and it works for you or you see one that's interesting and it's gonna make your life easier or you really care about portability between different types of compute environments then by all means stick with your framework if you want to make better or make better manage so the managed services be able to use more of AWS as tools and some of the other ones in the service ecosystem then you're probably gonna want to go the API gateway route so again a little bit of against some opinion into this on this but generally speaking this is what I see being the the overall kind of outcome of these types of conversations with customers okay so let's move on to the next section of about this which is taking this front-end and then connecting it back to our back-end so we're gonna talk about the number of different ways that we could do this and now again we have a couple different options right so we're gonna have API gateway talking to our lambda function on the front end and then we need to talk to this back-end land a function now we could basically just have lambda talk directly to lambda so we can have lambda call the lambda API to invoke that other function for us and today with the a DMS SDKs this is built right in so we could call any their synchronously or asynchronously but the challenge becomes that then we have to write code to handle things like failures retries across the number of different scenarios and so there could be complexity in that that we don't want to have now another thing here that we see is that people often think about this type of a model synchronously it's one of the biggest challenges we have of working with customers around application architecture is this kind of strong historical adherence to thinking about synchronous applications so talk a little about why that's not necessarily ideal so if we have a single service pretty straightforward that if we make a request to it we get a response and if for some reason something went wrong with that first request pretty traditional HDPE practice is just retry right and so we can build us into our client which people listen to our browser there's things that we can do to handle this request and be able to recover from it but now when we start talking about distributed systems or micro service based architectures we enter we end up adding a bit more complexity to this so if we take our first service the order service and we say oh when you place an order it's going to then call the invoice service and then if we were do this in a synchronous manner the invoice service would apply back to order service order service would apply back to our client and this doesn't just add one extra step pointing point where we could have failure it actually adds a couple different places where we can have failure and so we have to think about the communication between these services the communication back up to the clients where we think about where failures might be how we think about handling that idempotency tracking all sorts of stuff and so we start to have to think about well who handles that failure who travels that tracks that Ida potency what does the client see what does the client not see and so pretty quickly this again becomes a lot of complexity that we typically want to avoid so with asynchronous architectures again what we're looking to do is basically have that first service call the second service but then immediately respond back to the client and say hey I'm done here that's all good now what this means is that you have to design your application to handle this and so the solution to going again and connecting our order service to our invoice service is that what we would do is then if we client cared about the invoice they would have to go and pull that invoice service and get that information or something like that so I was looking for a good quote to kind of summarize some of my thoughts about this and so I found this and I think it's really impactful you guys are slow I know it's day three come on it's day three it's joke they give me these slides that have they call it quote slide and it was a cool kind of quote on this what are you supposed to quote but no but anyway again well we finally work with customers can tough audience I know it's day three but I we work with customers we find that when we actually stop and try to break down these workflows talk about sickness four it's asynchronous starts to really open up thoughts about how data flows through your applications how to think about micro-services the distributed systems so again pausing to think about do we really need this to be synchronous or can this be asynchronous can be a really eye-opening experience to how you do application design with distributed systems and again for us at AWS and and Amazon in general we do a sync in so many different places if you place an order off of amazon.com you very quickly see all the asynchronous aspects of the fact that we say hey yeah we're gonna process this order and then a couple minutes later you might get an email that says it's been processed we've charged your credit card we're gonna do this we're gonna do that and that's a whole lot of async that happens behind the scenes so when it comes to doing things async if we don't want to control the client ourselves well we then have our number of different options for connecting again our front end service to what we're calling our back-end service so if for kind of primary services here Amazon simple notification I'm sorry Amazon simple notification service Amazon SNS Amazon simple queue service sqs Amazon event bridge and then Amazon Kinesis data streams now these four products by themselves are super rich there's a lot of different capabilities there's a lot of things that we can go into about them when I think about working with customers through this a lot of times I come down at basically six key characteristics that we can compare them so we can think about how scale and food currency works with them how the durability of messages that are placed into them or events the persistence and persistence and durability are two different things in this case consumption models so is it push or pull based thinking about things like retries and then of course pricing and all of those matter and all of those are factors that you'll want to think about when you're designing your applications now fortunately we don't always make this easy for you in the last two weeks we've announced a whole ton of new capabilities for streaming and async events and so if you want to throw a camera at that QR code real quick here you'll see our server this pre event blog post that we put out right before Thanksgiving here in the States last week contains about 30 or so different launches from just the last two weeks that are impactful for service developers and we've got a lot of depth and a lot of material on these links to a lot of other launch blog posts and stuff like that so one is that we just announced sqs FIFO support so first in first out queue support this has been a big thing for folks that try to track transactional ordered events now directly built-in with lambda we announced something called SNS dead-letter queues so dead-letter queues basically allow you to capture when there's been a number of failures that come from SNS to a lambda function we announced a new capability of lambda called lambda destinations and this is kind of a next level of dead letter Q where after an asynchronous lambda function has finished being invoked you could capture either the success or failure of that send it on to either another lambda function an SNS topic and SQS queue or two event bridge and then further process it this is a bunch of capabilities with that as well and then for streams and async events a whole bunch of new controls bunch of controls around retries bunch of controls around phil you're handling for streamed resources we can do things like break apart the batches that we used to process and so for those of you who maybe you're familiar with Kinesis there has historically been this concept of a poison pill record and what this means is a record that for some reason you can't successfully process where because we pull on your behalf it tries to process the event it fails so it puts the message back into Kinesis and then we pull again and we get the message and it fails to process and it keeps doing this for a little while and so we actually have a kickback mechanism that says okay stop processing the stream something wrong has happened now basically you can force out poison pill events to again either destination or just fail them out with some of these controls that we have here so a whole bunch of scale patrols a whole bunch of different things that you have here all brand-new if you've looked at this stuff in the past and it's been a while I would definitely encourage you to check out some of these new capabilities and controls we also an apology this isn't that last night this is actually Monday night at the Midnight Madness also announced new capability of event bridge so event bridge now has capability for what's called schema discovery and registry again with event bridge what this allows you to do as a service is the ability to take in a message and then fan it out to a number of different services based on a really granular ruling rule capability what schema registry does is it allows you to track the messages based on the schema format and register them against the event bridge and then what else is cool is that we now also give you the ability to generate code that could process those events so the code bindings that we have here now that are integrated in most popular IDs and some of our other tooling will actually allow you to say give me the code that processes this event and we give you the ability to pull attributes out of it very easily based off of what the schema looks like so this is going to help make event processing even easier by giving you literally the code to do it yourself so again this just came out Monday night technically so again another impactful quote here so again a lot of cool stuff here in the last two weeks something that I heard yesterday was hey Andy didn't mention service at all in his keynote and yes we were a little above about that and you're gonna hear Vernors keno tomorrow you'd be like ha Vernors not talking about any big lunches for service and it's because we did so many of them in the last two weeks and then we've had a couple here yesterday and today so again a lot of this stuff is happening outside of the keynotes but definitely would encourage you to check the compute blog and a Tobias blog to read up on these because we've got content in both of those places for that so here's our cheat sheet for how to think about these again this is this is a very simplified way of thinking about it so if you have really massive throughputs taking a whole lot of data and maybe you care about the ordering of that data so there might be some sort of sequence track into it then Kinesis data stream this is really the way to go we see this being used for things like clickstream data log data or like sensor data from devices we seen it's being used in financial transactions all sorts of things if you need to do mostly unidirectional slight maybe fan-out primarily just to lambda or HTTP based targets then SNS could be the best option for you if you need to pull in a whole lot of data maybe you can't process it all at once I'm going to buffer for some period of time that's what sqs is here for and again that could be ordered or unordered now that we have FIFO support and then if you need to do fan out and reach to potentially lots of different services maybe you need to take in an event and you want to record it to s3 so you could do bi on it you want to send it to a lambda function to process it you want to pass it in to one of our AI services to do say some sort of anomaly detection on it then that's what you'd use a vent bridge form again this is a really big topic we're talking about four really big services themselves we had a lot of sessions and have a lot more sessions tomorrow that go into a lot of the details on this so if you're not already planning to attend one of the talks on synchronous events or asynchronous of ending or architectures like that then I would encourage you to check out one of these talks or at least follow up next week once they're all posted now one of the things that I really love about event bridge which we just announced over this summer this year is that it can actually talk to all these other services as well so you could take in an event in to invent bridge and then pass it to sqs SNS Lambda Kinesis and again a whole bunch of other services and so for that just given its flexibility and some of the capabilities it has now with the serve with the schema registry and discovery code generation I'm gonna put a vent bridge here between my front end and my back end so again this takes care of the front and the back end what we're kind of left with is thinking about the shared capabilities that we're gonna need to focus on so now what I'm talking about shared capabilities I'm talking about the various services that will allow us to make this be a really successful architecture and so there are things that we need to think about like secrets and configuration management simplifying ideally hopefully our code management debugging troubleshooting performance security controls as well so one thing that we have for being able to distribute out configuration information and things like database credentials or passwords or API keys feature flags stuff like that is environment variables in lambda now these are just traditional standard environment variables that you can consume directly from essentially the underlying operating system that the function runs on and so you use the normal API soar capabilities or your programming language to read those so for example with nodejs it's process dot a and B its OS dot envira on for python again whatever your language of choice is it's just the normal standard environment variable reading these are key value pairs they can optionally be encrypted with kms but the one thing you want to keep in mind then is that you then have to enable your function to read keys from kms you have to include the client to decrypt things so it becomes an extra step during the initial kind of init process of your function and so again this can be really useful for doing things like creating individual environments and adding some dynamic nough stew your code but one drawback is that it's configured per function so in the model where we have API gateway and then many lambda functions behind it you're potentially having to configure each one of those lambda functions environment variables another option that we have to centralize this is AWS Systems Manager parameter store and then a close kind of cousin product called secrets manager now parameter store as the name might sound allows you to store parameters in a centralized way supports a hierarchy which allows you to do things like create say like a per environment hierarchy so you could have dev stage and prod and then under there have individualized C is that or for certain applications or certain needs and then these can be made available not just lambda functions puts your applications running in containers or ec2 or really actually anywhere this is just an API that you connect to a whole bunch of capabilities that you see listed here and then accessing it via code is really really easy use the AWS SDKs you call the get parameters command and then you get back essentially an array of those parameters that you can parse through okay and then secrets manager which again is a close sibling product as its name might sound allows you to manage secrets now the key difference between secrets manager and parameter store is a secrets manager is really deeply integrated with the number of our database services so the RDS proxy that I mentioned earlier directly integrates with secrets manager so you can have lambda get your secrets from secrets manager to connect your database and you never need to hard-code any of your username or passwords and your functions in your configuration anywhere else and then about a year or so ago the parameter store team made it so that you can pull secrets manager secrets via the parameters for API so with just one API of just one client you get information from both of those sources so again that's how to do configuration secrets management now we start adding in all these different capabilities to your function what you find is that your function typically has what I consider to be four different types of code inside of it you have typically with most languages some sort of dependencies so third-party modules open source modules may be shared modules inside your organization you've got things like configuration information helper functions and stuff like that that you might want to call during the init process of your function you then have your handler which is where you kick off the execution of your business logic you might then again have some helper functions to pull data out of say parameter store or connect to a database or still be similar and then you're gonna have your actual business logic and we typically encourage that you separate out your business logic from your handler for for reuse and other benefits so if you take that API that we have again we're gonna use ap gateway and we're gonna have separate routes we now all of a sudden have a number of lambda functions we got four different types of you know code sections in our lambda functions and they're gonna do things like talk again a secrets manager a parameter store our database whatever it might be and so all of a sudden as we think about the complexity of our API growing we're realizing that wow you might have a whole lot of duplicated code between all these functions and so we want to simplify that so one capability that we have or I say the capability that we have for solving this is called lambda layers now lambda layers allow you to do is to create a shared artifact that can be configured across multiple functions and this becomes a artifact that lives outside of your application code but can contain all of the same types of data that your your application would so dependencies configuration files function code and then basically what happens is this gets squashed down onto the operating system with your application when you have a function be executed so it could be really a great way to share things you can share across the count's inside of an organization you could publicly publish layers there's all sorts of things you can do but it basically becomes a sharing and reuse model you know a couple things about layers with layers you have up to five of these configured port per function they do count towards the overall application artifact size so again that's a maximum of 250 megabytes today so as you add stuff to layers you potentially lose that space in your artifact and now layers are at the end of the day and we consider an onion file system what that means is that basically each layer that you configure gets squashed down on the one below it so it's one single file directory space /opt on the environment and so everything gets put into that now this has a number of again interesting characteristics again it means that you would overwrite files as you stack these on top of each other now this can be really useful if you say have one layer that has a whole bunch of shared dependencies or code in it you say I need to update one file on this well you could do was publish a layer that has that one file and basically add it to your function and it will overwrite essentially cherry pick on top of that other file that was in the original layer and so there's a number of interesting tricks that you can do with this as well and so basically this allows us to do is take all these different functions that we have and remove you know two to three of the parts of the four different types of things that we'd have in our function make them just layers make them reusable and again simplify the actual work that we're doing inside of our lambda functions now when you start talking about distributed systems and you start talking about profiling and troubleshooting across these it's gonna require a specialized tool for it so here at AWS we have a service called database x-ray a TBS x-ray is a profiling a troubleshooting tool it's directly already integrated today with lamda and API a gateway and a number of other services with a bunch more planned with lambda API gateway it's basically two check boxes you can see here I've got a little screenshots of it and then for lamda in particular and apologies if this code sample is a little harder to read in this room with the lights up but basically it's a single line to include the X 3 SDK and then another kind of little bit of code that would wrap around the AWS SDK and then this is going to capture information about every a dubious SDK call that you make you can also use this to capture database requests so things like my sequel Postgres and other databases so this gives you a whole bunch of information we could do things like capture and see actually if we would see the service map that you see here this diagram with these circles that will show us failures Layton sees and paths throughout our application we could also see basically a waterfall flow of what happens inside of our code and you can customize your code to put in certain what are called sub segments that will create even more of these blocks of information so x-ray a pretty powerful tool there's a whole bunch of other capabilities that you can do around kind of tracking performance over a long period of time seeing outliers being able to look at how various requests have been compared much like with the sync and async stuff and streams we've had a whole bunch of announcements in this space now also with lambda and API gateway and almost everything at AWS here we have cloud watch integrated so cloud watch has metrics that has logs but actually the cloud watch product space just grew pretty dramatically in the last two weeks so cloud watch just announced announced something called service lens you could think of service lens as a single pane of glass that you can use to view information about your applications so you can look at an entire service app in one window see all the metrics and everything overlaid they also announced something called cloud watch synthetics which allows you to basically create a outside of application monitoring agent or testing agent for your application really really powerful for API based workloads so there's a concept called a canary canary execute the script and that script can execute against your API or your application and test it for you and this is in preview then again we've had a whole bunch of other things that have been announced this thing called embedded metric format which allows you to create a log entry that also generates a metric for you in cloud watch something called cloud watch contributor insights which allows you to see things like top talker patterns top most trafficked endpoints and a bunch of other things like that it's pretty cool concept called x-ray trace maps which actually takes this kind of map that you see here and allows you to see it for a single request so basically give me one single request show me all of the paths that it made through my architecture and allow me to dive into how each service handled that really powerful and then lastly x-ray announced integration with synthetics so you can have these test agents that are testing your API and x-ray will report back their performance on them so you give the ability now to see how x-ray works directly with us so a whole bunch of capabilities again here this is all on the pre-event blog post that i mentioned earlier and links to Doc's and blog posts and stuff like that now one other really important capability that we have in lambda is is kind of an interesting what I consider to be safety mechanism now one thing that we see is that lambda it has the ability to scale really really large really really fast it can go from doing zero to thousands of concurrent requests kind of in the blink of an eye now one of the challenges without is that many of your downstream services can't do that and so we have definitely seen situations where people have been like deployed my awesome lambda serverless app got a bunch of traffic DDoS my database what do I do now and so you can think of basically prayer function concurrency controls as giving you kind of a balance for how large your function can scale so it puts a cap on the concurrency that your function could execute upon such that you aren't DDoS on your downstream database or you aren't maybe hitting a third party API to where they rate limit you too far and then it reports upstream to whatever is invoking it saying hey this is throttled because it's at concurrency lemaise another cool capability of this is let's say that you're doing you've deployed some code downstream or to another service and it's broke and your lambda functions hammering it non-stop because it's upstream service to sending data maybe you have say something pulling off of Kinesis or off of an SQ SQ and it's getting records and trying to talk to this HTTP endpoint that's now down you can effectively use this as a kill switch which says hey stop pulling records stop executing functions and later on you can turn it back on again and it doesn't involve you to change the configuration or break your function or do anything like that so per function for currency controls another really important part of lambda especially again in this distributed micro-services architecture cool talk briefly about security and we always talk about security being the number one priority for us here at AWS I like to say friends don't let friends to you know star actions for different services this is how you get yourself in trouble with lambda in particular we have kind of two different security constructs we have the function policy and this basically says who has the ability to invoke this function is it an API gateway that I've configured is s3 as a Kinesis is it other accounts stuff like that and then we have the execution role which similar to ec2 rolls container roles things like that it's what can the code in this function talk to or access on the behalf of the code so this means can my code write or read from DynamoDB can it store data in s3 I'm gonna call AWS api's and this is where you can kind of get yourself into the danger zone and this is where we've seen organizations in the last year or so who have had security incidents this is where it's impacted them because they've potentially had execution roles or in the case of things like ec2 again these policies that are too broad they're using star when they should really use really fine-grained policies now all this is based on I am and I am requires somewhere between a doctorate and an expertise and Dead Sea languages to completely master I would never consider myself an I am master that's like that's a scary type of knowledge I guess but it's super powerful it's super flexible there's so much you can do with it we want to make that easy for you so we have a tool aw Sam which stands for service application model this is a template driven service for building management deploying service applications with lambda integrates our API gateway integrates kind of across the board with a number of different services and so what we can do is we have here which is basically 20 lines of in this case yeah Mille and what this 20 lines annual is going to do is it's going to launch a lambda function configure API gateway configure a dynamo DB resource for us and then glue all of it together with I am and if we were to write this on rock cloud formation it would be about five or six times the amount of code so again Sam really really simplifies this now one thing that's kind of hidden in here that's hard to read given those those 20 lines how they're scrunched down is something called a policy template so with this policy template that's inside this document here I basically have two lines one line says the name of a policy so this policy is called DynamoDB read policy pretty descriptive it's going to allow me to read from dynamodb the second line here is the attribute that says which resource can I read from in this case it's a table name referring down to another table that I create inside of this template now this is behind the scenes can expand into a full iam policy that's been rated specifically just to allow me to read from the resource that's passed in and so with policy templates we've got a little over 50 different last time I checked policy templates that exist that are pre scoped for the most common use cases for service applications reading and writing from s3 from databases from queues talking to certain management API s and certain other capabilities where you want to be sure that you're scoping it down to a specific resource now even if you don't want to use Sam if you're using service framework if you're using just raw CloudFormation if using terraform one of the cool things about this document that you'll find here on this link which lives up in github is that it's basically an iam best practices cheat sheet you can go in here and say okay I'm using lambda this way what are the permissions that I need and this has it written out exactly as you would need it and you could just transfer that policy to whatever tool it is that you might be managing it from and again you can find this in the repo and github for service application models now one other part of is that we have a tool called the Sam CLI this is a local development testing management tool for service I don't have a link to all the new stuff in this but we basically have launched a whole bunch of new capabilities in this also in the last two weeks has a brand new deploy experience a brand new experience which allows you to create new applications locally a whole bunch of different capabilities for doing testing built into it so you can test and Mach lambda functions directly in your laptop or your workstation or whatever it is that you write code and we've got plug-ins for this with popular ID ease things like vs code and a number of other ones that are out there or you can just run it as a standalone tool cool so that covers kind of the full scope of profiling troubleshooting configuration sharing secrets sharing monitoring all that kind of stuff and so we've added in here now a whole bunch of stuff to these shared services that would impact across this entire architecture that we have between these two services so we're left with here at this point is our API gateway which is going to be kind of the front door of our service being able to invoke the lambda function it's got some business logic and again are above the law above the waterline public service that's going to then send messages into event bridge so an asynchronous message into an event bridge which can then invoke the lambda function on our behalf and then we've got a number of shared tools that basically make this all really easy for us now with this you're not running a single server you're not setting up a single I you know sidecar you're not setting up you know kubernetes management infrastructure or something like that all of these things are completely managed they meet kind of the four criteria that we have what we consider service at AWS and so you're going to be able to be able to build really rich applications again without having to do a lot of this other work it's kind of enclosing here and talking about building micro services the AWS lambda you know we've gone through a whole bunch of different kind of key points about this things to think about considerations that you might have again one of the biggest ones is around what lambda is right it is a service event-driven compute platform it's got a number of limitations or characteristics to it that make you think differently about how to build your application we've talked about the different ways you can expose an API publicly or privately I should say out to other applications or clients whether it be mobile web or what-have-you and talked about the various capabilities and trade-offs and how you think about them again we just announced a brand new stuff for API gateway in the last couple hours so some of this is slightly change but still mostly accurate I would say in terms of what I shared we talked about the differences between sync and async and again a lot of people have been building synchronous applications for so long that when they start building distributed applications thinking about async is a pretty big shift to them but think about those places where you can move to something asynchronous think about if it makes sense for you to have a topic a stream a queue or a bus that glues that together for you and at the end of the day with service applications we kind of have this ecosystem around is so things like x-ray all okay blue is a cloud watch Sam cloud formation and secrets manager parameter store and so on we have these new things like RDS proxy we've got the new capabilities for a lambda provision concurrency and so again this is a rapidly evolving space but in the last basically three months for lambda we've taken the top three biggest pain requests from the last year and solved them so we got rid of EPC cold start pains we made the pre-warming easier bridging concurrency and we solved the relational database issue with RDS proxy so you should feel confident to be able to build really strong applications now with lambda with that we just want to share that we created some new training that you could find at AWS dot training as a bunch of free training for service great for your organization for those of your counterparts who didn't make it out to reinvent but we're here in this room they want to learn a bunch of this stuff they could find it at the resources listed there with that my name is Chris month I'll be developer advocacy for service at AWS I really appreciate you coming to this session and I hope you're having a great reinvent hope see you at a future talk I appreciate your feedback on this talk itself and with that enjoy the rest of your day so thank you [Applause]

Channel: AWS Events

Views: 27,496

Rating: 4.9166665 out of 5

Keywords: re:Invent 2019, Amazon, AWS re:Invent, SVS343-R1, Serverless, AWS Lambda, Amazon API Gateway

Id: TOn0xhev0Uk

Length: 57min 34sec (3454 seconds)

Published: Fri Dec 06 2019