61–70 of 140 posts
I hate the term serverless. It involves a server. AWS Lambda is a service bound to a port therefore a server. It runs user defined functions, true. But it is a server.
If you are worried about latency or you want lambda on your own servers it may be worth to take a look.
Feedback welcome
I love lambda's, but api gateway was far from mature the last time I used it (6 months ago). Unless they have made serious updates to the deployment workflow, feature set, and documentation I would not recommend building your products on it.
They released proxy resources to API Gateway. Lets you specify a route like /foo/{path+} and all requests are forwarded as-is.
Wherein "serverless" basically means more computers in more places just doing different tasks.
Earlier quoted context omitted.
A cluster of? servers. Again, server. server, server, server. Repeat with me: server.
It's just semantics, point is, you don't have to worry about spinning up servers, provisioning them, or maintaining them; just write code.
Earlier quoted context omitted.
I'm in the same boat. I have 4 microscervices set up with API Gateway + Lambda and now actively guide people away from API Gateway.
Do you have any feedback that I can pass along to the team? Post it here or email it to me (email in profile).
If I would have to name one thing, it's that the configuration of API Gateway via the UI is unbearable if you have a nontrivial amount of routes (> 3). I need to configure Authorization, Error code mappings etc. for every route, although they are exactly the same. If there would be per-gateway defaults I can set with per-route overrides, that would cut down the setup time by 95%, which is the main thing holding me back from using API Gateway for projects that would suit it.
Right now the only option I seem to have is using a tool like Terraform to automate it, which is a pain to adopt if you already have a running API Gateway.
I hate the term serverless. It involves a server. AWS Lambda is a service bound to a port therefore a server. It runs user defined functions, true. But it is a server.
Earlier quoted context omitted.
You break the entire model of an oversubscribed multi-tenant container system if you want every lambda hot all the time. If that's what you need...you need a server.
"If that's what you need...you need a server." We want micro-services that are available as we need them, at any scale, and we never want to deal with a 'server' again. "You break the entire model of an oversubscribed multi-tenant container system" - we don't care that much about how it's implemented, or what underlying model is used, as long as it is secure, robust, and reliable.
Earlier quoted context omitted.
It's just semantics, point is, you don't have to worry about spinning up servers, provisioning them, or maintaining them; just write code.
Write code to run on? a server.