Live data from Hacker News

Going Serverless with AWS Lambda and API Gateway

blog.ryankelly.us

21–30 of 55 posts

Re: Going Serverless with AWS Lambda and API Gateway

#21
post #2

Are serverless and container based architectures really that popular in the real world, or is it yet another HN bubble? I'm still happy using virtual/cloud servers for anything/everything.

In my experience, they are steps towards the future. VM's are now the baseline; containers are better; server-less is even more so; something like Urbit is a step further.

However, the level of maturity is reversed. Docker is usable now, but you will run into many quirks and inefficiencies. On top of that, it's not standardised in a meaningful way. Only starting this year would I choose it for a new project.

Server-less is even less standard and efficient, but in five years I expect tooling to be usable, though still rough around the edges.

For some reason, we can't just jump to the most ideal architecture but have to evolve there step by step. That's what I would say is the essence of the "worse is better" philosophy.

Re: Going Serverless with AWS Lambda and API Gateway

#22
post #17

If anyone is not interested in vendor lock-in to Amazon for Lambda and API Gateway, I just released an open-source multi-language microservice backend today. https://github.com/Stackvana/stack Cheers!

Is it feature-compatible with Lambda? Like can I take a Lambda and run it via this stack? As a Lambda user the reality is, sure, at the moment there is a bit of vendor lock-in, but I don't think at all about hardware, which is the point.

Re: Going Serverless with AWS Lambda and API Gateway

#23
> There seems to be some issue applying privileges that I can't seem to figure out. Your lambda function will fail to execute because API Gateway does not have permissions to execute your function.

This stuff is definitely confusing. I think I "reverse-engineered" from applying things via the web interface and then looking at the policy when I created Gimel[0] - an AWS Lambda A/B testing backend. Take a look here[1] for the policy. I think that's what you're looking for, but I can't say I'm confident it is... (it's confusing).

There are some more general-purpose tools to help you deploy to Lambda. Kappa[2] and Apex[3] are worth looking into.

[0] https://github.com/Alephbet/gimel

[1] https://github.com/Alephbet/gimel/blob/master/gimel/deploy.p...

[2] https://github.com/garnaat/kappa

[3] https://github.com/apex/apex

Re: Going Serverless with AWS Lambda and API Gateway

#24
post #7
post #6

aka "Going towards total vendor lock in by basing your system on a proprietary, non portable infrastructure service"

Migration between infrastructures is always painful, so I don't think vendor lock in is that big a deal, if you keep APIs small and their I/O well documented (and designed).

Migration between a OVH VPS, a local server, or a Hetzner rootserver is not really painful.

I choose a preinstalled distro, deploy my script to automatically handle dependencies and set up the container infrastructure, pull the containers, and I have a server set up and able to run my containers in about 3 minutes, and connected to a central server so it can be provisioned containers to run.

The entire infrastructure can obviously be moved to another hoster in days, because the hoster is just providing a machine.

Re: Going Serverless with AWS Lambda and API Gateway

#25
post #17

If anyone is not interested in vendor lock-in to Amazon for Lambda and API Gateway, I just released an open-source multi-language microservice backend today. https://github.com/Stackvana/stack Cheers!

What else does it support other than Lambda? GCP?

Re: Going Serverless with AWS Lambda and API Gateway

#26
post #7
post #6

aka "Going towards total vendor lock in by basing your system on a proprietary, non portable infrastructure service"

Migration between infrastructures is always painful, so I don't think vendor lock in is that big a deal, if you keep APIs small and their I/O well documented (and designed).

> Migration between infrastructures is always painful, so I don't think vendor lock in is that big a deal, if you keep APIs small and their I/O well documented (and designed).

hmm, not if the only thing you have to do it upload an image on a server, there is nothing difficult with it. And yes the vendor lock in is a big deal unless all you write is throw away code. But it looks like it's the purpose of "Serveless servers", throw away apps ...

Re: Going Serverless with AWS Lambda and API Gateway

#27
post #25
post #17

If anyone is not interested in vendor lock-in to Amazon for Lambda and API Gateway, I just released an open-source multi-language microservice backend today. https://github.com/Stackvana/stack Cheers!

What else does it support other than Lambda? GCP?

This is a tool for running your own "serverless" backends.

Re: Going Serverless with AWS Lambda and API Gateway

#28
post #22
post #17

If anyone is not interested in vendor lock-in to Amazon for Lambda and API Gateway, I just released an open-source multi-language microservice backend today. https://github.com/Stackvana/stack Cheers!

Is it feature-compatible with Lambda? Like can I take a Lambda and run it via this stack? As a Lambda user the reality is, sure, at the moment there is a bit of vendor lock-in, but I don't think at all about hardware, which is the point.

This specific tool `stack` has a minimal feature-set for taking a function in any language and putting it on an HTTP endpoint. Nothing else included ( by design ).

It supports the same style of coding microservices as Lambda, except `stack` also provides actual HTTP streaming interfaces.

Check out the echo examples here: https://github.com/Stackvana/stack/tree/master/examples/serv...

An additional interface over `stack` could be used to support any cloud function style ( including Lambda's )

Re: Going Serverless with AWS Lambda and API Gateway

#29
How in the world is this considered something new? It was in fact the default mode of operation for small to midscale webhosting that rendered pages dynamically in the dotcom bubble burst era (late 1990-ies).

You'd upload your HTTP attached executables to cgi-bin or similar, register other stuff in crontab and usually also got access to a MySQL or PostgreSQL. Some hosters were actually fancy and deploy your stuff on a MOSIX cluster; but simply load balancing toward the httpd machines and your application talking to a dedicated DB machine worked as well.

Re: Going Serverless with AWS Lambda and API Gateway

#30
post #2

Are serverless and container based architectures really that popular in the real world, or is it yet another HN bubble? I'm still happy using virtual/cloud servers for anything/everything.

In my experience, they are steps towards the future. VM's are now the baseline; containers are better; server-less is even more so; something like Urbit is a step further. However, the level of maturity is reversed. Docker is usable now, but you will run into many quirks and inefficiencies. On top of that, it's not standardised in a meaningful way. Only starting this year would I choose it for a new project. Server-l…

Why do you define containers as better? Server-less even more so?
Post reply on HN