Hacker News Reader

Comment by aserafini | Hacker News Reader

I think the problem is that moving from Lambda/FaaS to a container-centric alternative (ECS and friends) requires a complete re-architect of your stack. Whereas starting with a simple, single container solution and organically evolving that into container-orchestration is much simpler - because the fundamental building block hasn't changed. It's all just containers.

Personally I'd like to see the industry coalesce on "serverless" containers rather than FaaS which are organised around functions being the fundamental blocks. Please just run my Docker container(s) like a magic block box that is always available, scales as necessary and dies when no longer needed.

View on HN

Aren't there abstractions to reduce the impedance mismatch between serverless offerings, e.g. Serverless (javascript framework)[1], which should allow easier portability to self-hosted solutions - openfaas or openwhisk etc - including running in containers on more traditional infrastructure, which is cheaper for this particular scale and use-case?

Sure, they're still FaaS which seems to be the unit of deployment for the serverless movement. For (hidden) managed server container deployment, Fargate is the offered solution I believe.

[1] https://serverless.com

I think the problem is that moving from Lambda/FaaS to a container-centric alternative (ECS and friends) requires a complete re-architect of your stack.

Not really. I converted a Node/Express API running in lambda using the proxy integration to a Docker/Fargate implementation in less than a couple of hours by following a Fargate tutorial. Most of that time was spent learning enough Docker to do it.

The only difference between the Docker implementation of the API and the lambda implementation was calling a different startup module.

There is nothing magical about any lambda, from the programming standpoint you just add one function that accepts a JSON request and a lambda context.

Converting it to a standalone service (outside of APIs) is usual a matter of wrapping your lambda in something that runs all of the time and routing whatever event you’re using to trigger to a queue.

> requires a complete re-architect of your stack.

Not necessarily. The reason I decided to try this was exactly because I found a tutorial showing you could easily host a bog-standard ASP.NET web app on Lambda with the serverless framework. I had to add a small startup class, and one config file to our existing app and I was up and running.

Recently we had to test a posibility of our core application being hosted in contenerized environment. It was really hard, because some tweaks we used are not really documented well. Kernel Tweaks had to be tested separately because we were not sure whether they work or not, recource management had to be done from zero level. JVM optimalizarion from zero level. Service Discovery configuration from zero level. --- Sure it works from the go for punny small apps. But when it comes to huge corporations running extrordinary workloads - no its not that easy.

Agree with you, Lambda would make a lot more sense if it was kind of a scaffold for your application.

Say you only have 1k users and don't want to spend too much time on infrastructure, lambda is a perfect fit for it. Your application is taking off and now you have 100k: just click a button and migrate it to a Fargate/ECS. That would be the perfect world.

AFAIK the only framework that supports this kind of mindset is Zappa (https://www.zappa.io). I use it in production but never had to migrate out of AWS Lambda so I'm not sure about the pain points related to it.

Reply on news.ycombinator.com