Transcript
Jeremy: Hi, everyone, I'm Jeremy Daly, and you're listening to Serverless Chats. This week I'm chatting with Eric Johnson and Alan Tan. Hi Eric and Alan, thanks for joining me.
Eric: Hey, thanks for having us.
Alan: Hey, Jeremy, thanks for having us.
Jeremy: So, Eric, let's start with you. You are a senior developer advocate for serverless at AWS, so why don't you tell listeners a little bit about your background, and what it is you do at AWS?
Eric: Yeah, absolutely, my background is I've been a developer since 1995. Yes, that's right. I am an old guy. I've been doing serverless since serverless came out, the day they announced serverless I looked at it and said, "Wow, why would you do anything different?"
I've been following that trail for a long time. I now work for AWS. I've been there for almost two years. I am a senior developer advocate for serverless at AWS. I love all things automated, all things serverless, so I'm having a great time.
As far as our role, what we do, is we're kind of a two-way conversation with developers, and users of serverless, we like to teach on how to serverless and get the message out and the best way to use serverless, how to make it useful for all workloads, but we also listen.
We try to bring back what the developers are saying to the product team, to someone like an Alan Tan, so they know, hey here's what people are saying, here's what they're wanting, here are the paper cuts, here's what they're loving, that kind of thing. I love my role and appreciate you having me here today.
Jeremy: Awesome, all right, so Alan, you are a senior product manager, so why don't you tell the listeners about your background and then what you do as a senior product manager?
Alan: Yes, I started in computer science, a developer just like Eric for a long time, and then I went into product management building products for big data analytics, data analysis, and most recently, been doing this for two years now in the API Gateway team, product manager for API Gateway.
So, what I do, I'm a senior product manager, so I talk to customers directly. I talk to people like Eric. I talk to people like Jeremy, yourself as well, to get the feedback of what customers are really looking for, and then translating that back into the product. So, our customers think we're building the right thing, and they really love coming back to us and using the same product over and over again.
Jeremy: Awesome, all right, well, so you work on the API Gateway team, and just the other day, AWS released HTTP APIs, which is really, really cool. So, can you explain to listeners what that is?
Alan: Yeah, of course, so just to start with some context of where that came from, so when I talked to customers, they usually come back to us for improvements and feature requests, but there are a few things that are really core to products, so more generally, when people think of products and the things they use, whether that's an appliance, a car, a computer, there are certain things they look for.
Which is how can we get this thing faster? How can we get it cheaper and better? API Gateway is no exception to that. Our customers come back asking us the same things, so last year we started looking into how we can continuously deliver on these improvements for them. The results was HTTP APIs.
So, it offers the core functionality of REST API at a 71% lower price, that's at a dollar per million in IAD, a dollar per million requests, sub ten millisecond latency overhead at the P99 level, that's a 60% improvement, and way easier to use features. So, you can think of HTTP APIs as the next generation platform for API Gateway's API types a kind of V2.
Jeremy: Awesome, now Eric, you have done a ton of stuff with API Gateway, with the REST APIs. You had your happy little APIs show on Twitch, kind of getting into all the details. I know you love service integrations and all that kind of stuff that you've been working on.
Eric: Yes, sir.
Jeremy: But you're pretty excited about HTTP APIs as well.
Eric: I am, yeah. For me, as a developer, HTTP API brings a lot. I'm going to start with the better part, the cheaper, faster, those are great, and I love those, and those are huge to our clients, but as a developer, the better part for me is the UI, is the interface.
There's been a lot of work done on how do I, as a developer, interact with API Gateway and how do I develop against API Gateway? It just starts with something like the UI. When you get a look at the UI, and if you've seen it, we did announce it last year at re:Invent.
I've gotten in. You've seen it. Hopefully, you've seen wow, this is a lot simpler. One of the examples that I'll use is CORS. And if you've ever heard me talk about API Gateway, I like to have everybody raise their hand and say, "Who loves CORS?" There's good a surprise, nobody raises their hand except for one person, and he's a liar, so you know that's...
Jeremy: That's probably me....
Eric: Yeah, probably you.
Jeremy: No, I hate CORS as well.
Eric: Nobody loves CORS, and CORS is not easy, but it is a necessary thing, so what a lot of folks end up doing is they just put stars in their CORS. Hey let anybody get to it. Let anything happen. Let anything get to it, because configuring CORS is too complex.
Well with HTTP API, we've taken that, we've simplified that. I say we, but really Alan's team has done a lot of great work on this, but I take credit for it when Alan's not around. So, what we've done is we've made the CORS integration a lot easier to set up, so you can add, here's the domains that should be allowed to get to it.
Here's the methods, and it's all in a simple UI. We've also taken and extended that where we're able to simplify the return coming out of your Lambda or your backend, and we use heuristics, which is a big word that I've just learned recently, but we use some logic to fill in the CORS data and return to the customer.
So, a lot of the heavy lifting of configuring CORS and other items have been simplified, so as a developer, I love it. That's just one example though.
Jeremy: Yeah, and speaking of that, sort of reducing that complexity, another thing that is now available, and I should have said HTTP, while it is hard to say, it's also a great SEO keyword by the way. I think that you're going to find a lot of people finding HTTP APIs.
But it just actually went GA, so you're right, it was in preview for quite some time, but going back to this idea of reducing complexity, one of the things that you have to do with API Gateway is add in authorizers and some of these other things, but now you have like JWT authorizers built right into the service.
Alan: Yeah, that's right, so going on the same vein of things that both you and Eric have been talking about, about reducing complexity, JWT authorizer is one of those things we've heard our customers ask us a lot about from our REST API product.
So, how customers used to do it in our REST API product is that they would use a Lambda authorizer, and it would just write custom code just to do OIDC auth or Oauth2, and every customer has to do this, so what we've done with HTTP APIs JWT authorizer, is to build all this as a native feature inside the product.
So, customers don't have to write code. It's basically code-less, you just configure where your token is being issued from, what audience and what scopes will be part of it, and we will handle all of that for you.
Jeremy: Yeah, and one of the cool things that I've been seeing a lot of articles written about is this ... is using something like Cognito, obviously, as a way to do it, but also being able to use Auth0, I saw somebody write an article about using Google Firestore (correction Firebase), I think, in order to use the authorizer, anything that can process those JWT tokens you can plug that in natively into HTTP APIs.
Alan: Yeah, that's right, so we support the token regardless of where it's being issued from, ping off the Cognito, so it's really being able to ... for the customer to be able to bring any token they have, and being able to use that with API Gateway.
Jeremy: Awesome, all right, so one of the things that I found, sort of experimenting with, with the new HTTP APIs, which is really hard to say by the way, but it's hard to say it fast anyways, HTTP APIs, maybe we just shorten it, but one of the things that I found is obviously the feature set isn't quite ...
You can't do everything in HTTP APIs that you can do in API Gateway, so this is obviously something where you said you've gone back and you've rewritten this thing. Is that something that we should be looking for in the future is to be able to do more things with the service?
Eric: Yeah, with the HTTP API, we're looking to have feature parity with API or the REST API. Now, is that there right now? No, not yet, but it is ... It's top priority. It's looking. We know that as we ... People ask us, "What should I use?"
I think we'll get into this a little later, but, "What should I use?" My rule of thumb is generally start with HTTP API. If it doesn't have the service or the feature that you need, then go to API Gateway, REST API.
However, keep checking, because we are looking to do feature parity to continue to build out the features that are on REST API to build them into HTTP API or something like that, but again, at the better, cheaper, faster way of doing it.
Jeremy: Yeah, I guess I wonder a little bit, because I get that, and that's awesome, the idea of being able to continue to add features. This is what's great about serverless is just things keep getting added, and you don't need to do anything, which is pretty great.
But who is this targeted for? Because I think you see with API Gateway you have a lot of API management controls, right? So, you have everything from quota management to key management and all these other things that are built in there.
It's great if you want to build an API that allows customers to have access to a certain amount of data or a certain quota every day. You can't do that with HTTP APIs yet, so who is this really targeted for?
Alan: So, HTTP APIs is targeted for developers. We wanted to make it the easiest platform for developers to build APIs, and just to add a bit onto what Eric was saying earlier, because we built HTTP APIs from scratch, we are able to start from a clean slate.
So, a lot of these new features, we're going to be adding as part of feature parity. We're actually going back and looking at them and seeing how we can make those a lot easier to use, so it was really targeted for developers who are trying to build APIs.
Jeremy, you touched on API management as well, so this also a set of capabilities that's available in REST API today. For going forward, another request we hear a lot from our customers is they're challenging us to look into the API management space and bring some innovation and disruption there.
As you know, it's a very old space. A lot of our customers, especially when they're moving to AWS, are asking us to make this space easier, so this is a set of new capabilities we're looking into right now, probably later this year you'll see something.
Jeremy: Awesome, yeah, because that's one of those things too where as a developer, who mostly is building just APIs, I just want synchronous invocation of a Lambda to function is essentially what I want.
Adding on the CORS, and having to put extra stuff in the CloudFormation, and set up those response templates, is such a pain, and then you've got all that extra overhead of things that you just don't need, so I really, really love how this is super slimmed down. And once you get a couple more of those core features in, I think that's going to be pretty exciting stuff.
Eric: Yeah, it's interesting, as we talk to developers, and how many are saying, "Look, we just want to ... We need to proxy a Lambda or we need to do this. Now a lot of times, if you've seen anything I talked about, I talk about okay but are you looking at the full feature set?
Are you re-inventing the wheel? But sometimes they're not, but sometimes they're just look we just need a simple authentication and a proxy or an API in front of a Lambda or in front of a service. And that's HTTP API at the moment. I mean it's a great way to just do that very quickly. And then as we start, you're right, as we start to build out those features, then it's going to become for everybody.
Jeremy: Awesome, all right, so let's jump into some of the features that it has right now, because I think that'd be useful to know what exactly we can do with it, so basic features we have routes, right?
Eric: Yeah, with routes, yeah, so the way we've done ... and we've changed that a little bit, a route is just simply an HTTP API. It's simply a path and a method, right? So, look, I'm going to hit the route, and it's going to be a get a post, an any or something like that. So, routes are very simple. And then you can tie to that route. You can tie different integrations to different places going on, but yes, you have the basic concept of a route.
Jeremy: What are the integrations that exist right now?
Eric: So, currently, we have Lambda. And I'm ticking them off on my fingers, so you can't see it, but we do have Lambda. We also have an HTTP proxy, so you can front another HTTP endpoint. And then we're adding private integration. I want to expand on that, because I'm really excited about that, but those are the three integrations that we can do.
Jeremy: All right, so before we get into the integrations, because I know that's a whole ... that might take us an hour to get through.
Eric: Yeah.
Jeremy: We also have stages, similar to API Gateway, right?
Eric: Right.
Alan: Yup.
Jeremy: All right, so you can still do your dev and your prod and things like that.
Alan: That's right, and we also added a new usability feature for stages actually. We added the concept of auto-deployment, so as you change an API, your changes will automatically be deployed to the stage. This is also a big area of feedback we got from our customers, where as Eric was talking about earlier, right, some of our customers are really just looking for a basic endpoint.
They're just really looking for something to proxy traffic, and for them, having to learn more and more API Gateway concepts might not be the most customer friendly, right? So, we added auto-deployment, so that's another concept you don't have to learn about until you really need it.
Eric: Yeah, I can't tell you how many times I've been standing on stage demonstrating API Gateway, did all the changes, and then spent two minutes going, why doesn't this work?
Jeremy: Because you forgot to deploy?
Eric: Exactly, and I have actually said to the audience, "Hey, if I start getting frustrated this doesn't work, somebody yell, 'Deploy it,'" So, I'm really excited about the auto-deploy. I'm not going to lie.
Jeremy: Yeah, and actually, I think that it's subtle, but it is a really cool feature, because if you think about your average developer, who just again wants to put an HTTP endpoint in front of a Lambda function, for example.
The problem is that again you're adding on all this complexity with API Gateway, and it's just another step that you have to go through, and so having that all kind of wrap into one I think is pretty cool.
Now I personally don't like when every Lambda function has an HTTP Gateway in front of it, similar to maybe Google Cloud functions or something like that, where those all have their own endpoint, but I do love this, because it's a super simple way to kind of add that on top. So, what about logging?
Eric: Yup, we have access logging. Alan, go ahead.
Alan: Okay, yeah, we have access logging, just like REST API. We actually added a new context variable to our access log, which is integration error message, so you're able to see why you're backend is not working, for example, if you're using with Lambda it'll tell you things like hey your permissions weren't set up correctly. So, you're able to easily debug using our access logs now as well.
Jeremy: Which again is another huge, huge improvement, right? When you keep getting that internal server error coming back, and you have no idea why, and then you realize oh wait a minute my Lambda function processed correctly, but somehow my API Gateway didn't respond correctly or vice versa.
So, that's definitely a cool feature. All right, so let's get into private integrations, because this is super cool stuff, so I don't know, Eric, you want to start?
Eric: I do. I do. I'm excited. Yeah, so private integrations, a lot of times we get folks that are telling us look we've got ... hey. I know the three of us are serverless people, but apparently there are non-serverless architectures out there.
Jeremy: I don't believe it. I don't believe it.
Eric: I don't either, but that's what they're telling me, so they said, "Talk about it." No, so when we're looking at API Gateway, we deal with VPCs. When you're dealing with especially with non-serverless architectures, you deal with VPCs, and that's a good thing.
VPCs are a layer of security that, as in a past life, as a solutions architect, we talk about security, and everything goes into VPC. That's what we always hear. That's why sometimes with serverless they kind of say well it doesn't have to be, because it's already in a VPC, but that's another discussion.
But so dealing with VPCs, when you're thinking about EC2s or you're thinking about container servers, like ECS or EKS, you need a way to be able to talk, to basically front those with API Gateway. Now you can do it through some other ways, like ELB or ALB, but you want to be able to take advantage of the API Gateway features that we've got, like the JWT or the throttling that we've added, different things like that.
So, we've built private integrations, and I think we really did a great job on this, and Alan's team did an amazing job on this, because it's not just NLB like REST does, which is a great way, look, we can point to an NLB, and then we can get your stuff in a VPC, but we also added the ability to use ALB.
Which you can do path mapping. It's a level 4 versus a level 7. I don't know what that means, but there it is. It's on how the routing is done. Alan will expand on that, but the other one that I'm really excited about is AWS Cloud Map.
And if you're not familiar with Cloud Map, it gives you the ability to ... basically it's a service discovery product, so I can actually create a name space, that's going to maybe ... Maybe I'll just tie ... these are you can create a name space on however I want to be, or we can say look I've got an application that does this, I'm going to create a name space that matches that.
In the name space, I can make different services, so for instance, I may have a tier one or a tier two, or my different tiers, however, I want to break my services apart. And then finally, in the name, or in the service, I can register service instances.
So, let's take, for example, if I'm doing ECS, so I being up a cluster, it's got four different machines in my cluster, so I can register those instances with Cloud Map, so API Gateway can use Cloud Map to get to those instances, to connect to the clusters.
And so I've got a secure infrastructure, so I'm saying look API Gateway, for all intents and purposes, is in that VPC with those instances. I'm probably making Alan cringe right now, because it's not actually in there, but we're using technology to connect those.
So, with security groups, when I'm locking down my security groups, I can say hey, everything in this VPC security group, and that API Gateway, can be in there, because of Cloud Map and because of the way it connects through.
So, and Alan feel free to correct any of that if you want, because you're obviously the big brain here, but that's ... I'm excited about the way we're doing the private integrations and the ability to build those. With Cloud Map, you can iterate fast. You can build them fast. You can change them out fast. It gives you serverless flexibility in non-serverless world.
Alan: That's right Eric. I think you got it perfectly. I think it's totally fine what you said, no corrections needed.
Eric: Please do not edit that out Jeremy. That needs to stay in.
Alan: Okay, I just wanted to add on that while the Cloud Map capability is super cool, the ability to connect to a private ALB, actually that's one of our top feature request we've heard from customers from our REST API product, so it's going to be super great for customers, even if they continue using private ALBs.
Jeremy: So, what exactly is the use case for that?
Alan: So, a lot of our customers, when they're using ECS, because all the tutorials are focused around using ALBs, and ALBs, generally, itself, is easier to use than NLBs, because, like Eric said, it is a layer 7 product, so it has more features, more routing options. It's easier to set up. So, a lot of ECS customers just have a stronger affinity to use private ALBs instead of NLBs.
Jeremy: Awesome, all right, so what about migration, because now let's say I've got, I don't know, 200 API Gateways or something like that, that I probably have configured for a number of customers and other people, how do I go from API Gateway to HTTP APIs?
Alan: So, to go from API Gateway's REST APIs to HTTP APIs is actually pretty simple, because they both support the OpenAPI spec, right? You can go to REST API, export your API using OpenAPI3, and then import it using HTTP API, right?
But as we mentioned earlier, or at least you alluded to it, there are some features that are missing, so when you export from REST API and import from HTTP API, when you do that, if you look at the object, that gets returned, we actually tell you exactly which features are missing, so you can actually use that as an indicator for whether or not if there are any updates you need to make, what you should be aware of, so you can take a look at the info object that's returned.
Another thing we've done to help customers to move REST to HTTP is that we've made customer domains cross compatible, so with one custom domain name you can put a REST API, base path mapping and an HTTP API base path mapping.
So you can take a look at your current API, if it's REST API, bring it over to HTTP API, test that it works. And if it works, you can just swap the base path mapping under that custom domain, so your clients don't have to change any URLs. You don't have to update any URLs in your documentation or anything like that. Everything will just work.
Jeremy: Awesome, and I know that this is more about specifically HTTP APIs, but I do want to touch on custom domains for a second, because I really like this pattern, and maybe Eric, you can talk about it a little bit more, but I find this ability to create new services, so microservices, my billing service, or my alerting service, or whatever it is.
Create a separate group of functions and resources and things like that, front that with an API Gateway, and then use the custom domain mapping so now that it's myapi.com/billing, myapi.com/alerting, or whatever that is. And that gives me a lot of control, because now I can add endpoints, remove endpoints, add new services. I'm not worrying about a single, or a bunch of teams trying to publish to a single API Gateway and map those all over the place.
So, that's a really, really cool feature, so Eric, I mean this is just great, because now I can say look maybe I have one service that needs a service integration or it needs one of these features of API Gateway REST APIs, but if my other 10 services just need simple proxying, then I can use the HTTP APIs for that.
Eric: Yeah, no, I love it too. When you think about that ... We get a lot of questions on how do I architect serverless architectures or how should it look? Are all 300 Lambdas in one application, so they can be behind it? We say no.
We really encourage folks to find a logical breaking point for serverless applications or applications in general. It really is not just a serverless thing. It's anything. It's so being able to take and say okay I'm going to have ...
Instead of one large application, I'm going to have 10 micro-applications, and each one of those are going to be micro-service architectures, so then I can put one base path mapping right in front of it, and then I can just route that around as I need, rather than having to okay I'm going to try to do some funky routing.
I'm going to put an API Gateway in and sub API Gateways, and you can do that, you can certainly do that, especially if you're trying to maybe unify or consolidate your authentication, but base path mapping is a simple way to say you go there, you go there, you go there, you have a lot of control and it's another thing. And I don't know if you want to touch on this now or later, but it's also really helpful when it comes to the strangler pattern.
Jeremy: I was just going to say that.
Eric: Okay.
Jeremy: I was just going to say that, because I think it's a new way. It's a new way to think about the strangler pattern. Obviously ALB was a great way to do it, because you could route things right to your Lambda functions and start splitting off, like you said, that layer 7, start splitting them off at the path level, which is pretty cool stuff.
But using an API Gateway to do that, it was just expensive. There was a lot of overhead and things like that, but now, with the HTTP proxying in HTTP APIs, which is pretty inexpensive, and the custom domain capabilities, now you've got some more options there.
Eric: You do. Going forward, HTTP API will be referred to as API unless otherwise designated. Does that help?
Jeremy: Is that the official AWS stance?
Eric: Nope, that's the Eric Johnson stance who can barely speak English as it is. All right, no, so yeah, and that's an interesting idea, if you're not familiar with the strangler pattern, just so you know, the idea is let's say I've got an old legacy application that's a bunch of different services all in one.
I can actually put ... so, we'll talk about API Gateway for a minute. I can put API Gateway in front of it, and then as I start breaking out those little, little services, I can say okay now I'm going to reroute to serverless or some other type of architecture. Which should be serverless.
And I'm going to break those out, until eventually I've strangled that application until it's gone, so everything's broken out. But if you wanted to you could say I'm going to take my application, and I'm going to ... instead of breaking it into single service, I'm going to break it down into maybe 10 micro applications.
I'm going to say to my teams, I'm going to take 10 teams, I'm going to say build these 10 applications, and when you're ready, we'll just put a custom path, a custom domain path in front of it, and we'll route to your API Gateway.
And it could be a REST API if you need it. It could be a HTTP API if you need it. I have the ability to send to either and change as needed, so yeah, it's kind of a level up of the strangler pattern.
Jeremy: Yeah, that's awesome. All right, so let's talk about the practical use cases of this now. So, if I'm a developer, and like you said, Eric, first thing you do is use HTTP APIs. That'll be your defacto standard unless you need something else. But what are some of the reasons why I would use API Gateway REST APIs or maybe something like ALB over the new HTTP APIs?
Alan: So, between REST and HTTP API, I think if you're, as Eric was saying earlier, if you're bringing in new traffic, you should take a look at HTTP API and see whether that's a good fit for you, because like I said, it's going to be the next generation platform for us to build our API improvements.
If there are any feature gaps or feature parity type things, as I mentioned earlier, we're also going to bring those over, over time, so you shouldn't let any feature gaps worry you about whether or not we're going to support in the feature. We definitely are.
But going to ALB and API Gateway now, they're ... while there are some overlapping features, they're really quite different, so I think really it's similar to earlier the rule of thumb is just to pick which ever one meets your needs, and where you think your needs are going to be in the future.
So, for example, API Gateway offers throttling, authorization, publishing APIs, monetizing APIs, serverless web sockets, so you don't need to worry about these kinds of things in your backend code.
So, going back to the strangler pattern, for example, if you're using a Lambda function, and if you're using your legacy on-prem backends, for example, and there's some authorization authentication you want to add for all these APIs, API Gateway is a really good place to put that.
Because then you don't really need to worry about having an authorization library in your Lambda code and an authorization library in your backend code, and trying to keep that consistent over time. Because consistency is really hard, especially when you're talking about doing code manually, right?
Jeremy: Yeah.
Alan: So, that's the kind of the benefit that you get with API Gateway, you get a consistent layer, where you can put some of these logic in. And also being serverless, if you're not serving any traffic, you're also not being charged, so it's really good for highly variable workloads, where you need to scale up and down, so you don't need to maintain a minimum footprint.
ALB on the other hand, works really well if you have already ... if you already have all that logic, that's already handled, so you're already handling throttling, caching, authorization on your backend code, and you don't really care about having to maintain that over time, so it's really good if you already have those things.
The pricing model works really great if you have a lot of small requests, and you already serve like a very consistent level of traffic, because how ALB works is there is a base price for keeping the load balancer around, so it's really good if you already have a minimal footprint for your traffic.
Eric: I would add in also, and I completely agree with Alan, but a lot of times when we have the discussions, and I'm in the field, it's the, "I don't use any of the features on API Gateway, so why do I need to use it?" That's fair.
If you really are not, okay, that's something to look at, and maybe ALB works out, but what I encourage people is you ask them okay are you handling caching? And we get, "Yeah, yeah, we're writing to elastic cache from Lambda." I was like, "Okay, well can ... I can help you not do that, and just offload."
I really encourage people to figure out what are they doing in the Lambdas or the backend integrations that can be rolled off into API Gateway, because then you start ... I know people hear this a lot, but you start looking at the total cost, the TCO, the total cost of operating it, right?
So, and you look at how much code are we writing to do stuff that's already available? I'm a big fan of less code. If I build an application, the most dangerous part of an application is my code. There's just no two ways about it.
And so my encouragement is if you don't have to code it, and you have a service, and sometimes you look at that price factor, but you have to look at the price factor in light of how much developer time, how much operational time, how much management time is going into putting it into your code, versus rolling it out.
Especially with the drop in cost with the HTTP APIs, when you're paying at a third of the cost, as we reach feature parity, I just think it's the way to go. Like I said, rule of thumb, that's the first place I go.
Jeremy: Yeah, no, I think you hit the nail on the head there. The biggest thing for me too is why rebuild something if it already exists? It has to exist in a way that works for you, right? Obviously, caching in API Gateway in the REST API version is very good for the right use case, right? You can't always cache everything.
Eric: Right.
Jeremy: But same thing with request transformations, that's a really cool feature that I don't think a lot of people use, but you probably should if you want to limit... You can have the same Lambda function that responds to requests, and actually spit them back in different ways using different endpoints, using request transformations and things like that.
And then one thing too about authorizer, so custom authorizers, love that feature when it came out, but now ... with API Gateway, but honestly if you think you can write a better standard than JWT or oAuth2 or something like that, good for you, go give it a try, but honestly-
Eric: Good on you, yeah.
Jeremy: I think it's probably smarter, when it comes to security, to maybe use something that is a pretty good standard, like you said, there are a couple of things, like the usage plans and API key management that you can't do in HTTP API right now. There's also no x-ray integration yet, right?
Alan: That's right, yeah. That's also coming really very soon.
Jeremy: Awesome, all right. And then just some other things too. I have some notes here, just because I like to be thorough, but things like client certs, WAF, and resource policies, so those aren't supported, right?
Alan: Yeah, those aren't supported right now, but it's part of the feature parity bucket of work, so that's the buck of work we're going to be looking into bringing over and seeing how we can do those better.
Jeremy: Awesome, all right, so one more question about ALB though just in terms of ... in the scale up, so if you need to scale very quickly, is it ALB, is it HTTP APIs, is it API Gateway, what handle a fast scale-up?
Alan: That would be API Gateway, so API Gateway, for both REST and HTTP APIs, and even web socket, actually, your account is actually provisioned for 10,000 RPS, and you can scale up from zero to 10,000 as quickly as you want.
And if you need even higher than 10,000, we can easily increase that for you. We've gone with customers significantly higher than that, like way higher for sporting events and big announcement type deals, right?
Jeremy: All right, yeah, so that scaling is pretty intense. Again, I like ... I always like to say, if you have to scale that much then you've got some really good things going on with your application, so that's good stuff.
One of the other things that HTTP APIs doesn't do yet. I don't want to harp on this fact, because I know we've talked about feature parity, and I know the teams are working on it. I think that that ... the fact that it's built in a way that you started from scratch, like it's a new product all together ...
And as you mentioned, it's going to give a ton of flexibility going forward, but with the existing service integrations in API Gateway, very common pattern, and this is something, Eric, you talk about quite a bit, is this idea of taking data right from the request and putting it right into some service ...
Whether that's SQS or it's Kinesis or it's DynamoDB, being able to handle those service integrations, and I think you call it storage first, which I think is really-
Eric: I do.
Jeremy: ... interesting, an interesting way to think about it, so I know that doesn't exist yet. I know it's going to come at some point, but let's talk about that pattern, because I think that's really interesting feature of using something like API Gateway or the REST APIs and eventually HTTP APIs that lets you take that request, forget about the Lambda function, just make sure you capture it, store that data and then do something with it.
Eric: Yeah, and I do call it storage first, or sometimes I do a presentation called Thinking Asynchronously, but the idea ... Let me go back to my earlier statement. The most dangerous part of an application that I'll ever build is my code. Right?
So, when I build an application, I want to get that data stored first. That's the thing. I tend to go DynamoDB because that's what I like, that's what I use, but there's different purposes.
I know Jeremy, you and I have had this conversation before, and you're an SQS guy, so that's where you tend to go, and we do this because we look at okay what's the pattern for the retry or the DLQ or different things like that.
For me it's because I'm going to continually write back to Dynamo. On the app, I'm specifically thinking about it. But the idea is if API Gateway can directly integrate with the storage, be it S3, be it DynamoDB, something like that, then I've stored the data and I don't have to go back to the customer if my logic fails, right?
So, in an application I've stored the data, let's say I'm using DynamoDB, I do a stream, it triggers a Lambda, I start processing that data. If somewhere in there, something breaks, and again, it's going to be my code, but let's say something breaks, then I don't have to go back to the customer and say hey guess what, I blew it.
Can you give me your data again? Can you resubmit that? And continue to trust me, because I'm sure I won't lose it again. Instead, I've got that data stored, and I can write in some retry or take advantage of the retry from an SQS or an SNS or something like that.
So, I think it's a really cool pattern for building resilience into our application. Serverless comes with a lot of resilience anyway, that's how AWS has approached this on look as much as we'd like to say nothing ever breaks, let's write as if it does, right?
So, let's degrade gracefully. I think this adds even another layer of that, where I can degrade in my code and know hey I've still got the data. I can write some retry logic. I can use existing retry logic. I think it's a safer pattern.
It does require ... The storage first is the pattern I call it, but it requires asynchronously. What can I do after I've responded to the client and how do I work with them?
Jeremy: Absolutely, awesome, so Alan what do you think about that?
Alan: I think it's super powerful, and we see a lot of our customers doing that actually, especially after Eric published his blog that talks about this thinking, and showing a fully functional demo about creating ... what was it, like a ...?
Eric: A URL shortener.
Alan: A URL shortener, yeah, that's right.
Eric: I'm glad it impacted you a lot.
Alan: Yes.
Eric: Just kidding.
Alan: And as we look at HTTP APIs, we know actually setting up service integrations in REST APIs is actually kind of a pain, right? In HTTP APIs we're going to make it super simple, just as easy as it is to set up a Lambda integration today, so some background there.
In REST API if you set up a Lambda integration, super easy, paste in the ARN and you're done. If you try to set up anything else, like DynamoDB, SQS, there's a lot more setup steps, especially in writing a little transformation template.
Eric: VTL.
Alan: We're going to make all those super easy in HTTP API, so just as easy if not easier than Lambda.
Jeremy: That's awesome, all right, well listen-
Eric: That's me.
Jeremy: Yeah, no, the service integrations are not easy, which is why I typically use a plug-in to help me do those, because it's just a lot easier. But anyways, so listen, both of you, thank you so much for coming on and talking about this stuff.
Alan, honestly, great work on HTTP APIs. I think this is going to be, like Eric said, this should probably be the first thing you look at, once we get those service integrations in there, which are going to be easier, I love that idea, because that's the other thing... Learn from previous mistakes, maybe they're not mistakes, but certainly make it less friction to get that stuff in there, so that's going to be absolutely awesome, and I look forward to maybe checking back in with you two, and see when these new things come out.
So, if people do want to find out more about HTTP APIs, they can just go to the AWS site and click on API Gateway and there's information there. If they want to get in touch with you, Eric, how do they do that?
Eric: The best way is on Twitter, @EDJGeek is the best way to hit me. My DMs are open, and I'm always getting questions on that, so that's the best way to get me.
Jeremy: All right, and Alan if people want to bug you with feature requests, how do they do that?
Alan: They can also reach me on Twitter, @T_Alan. Eric's been bugging me a lot about getting a Twitter account, so I did that.
Eric: That's right.
Alan: And now people can reach out to me.
Jeremy: Awesome, and then you publish a lot on the Compute Blog, right, the ...
Eric: Yeah.
Jeremy: It's aws.amazon.com/blog/compute. There's like what, 17,000 blog posts a day across all of AWS or something like that? So if you can-
Eric: All by me.
Jeremy: Anyways, all right, well listen, I will get all of that stuff into the show notes, thanks again for being here.
Eric: Yeah, hey, thanks for having us.
Alan: Thank you Jeremy, thank you again.
THIS EPISODE IS SPONSORED BY: Epsagon