Hacker News Reader

Comment by nicodjimenez | Hacker News Reader

As much as I hate to admit it (I love my servers) I think serverless is the future for most CRUD / admin API's. API's that require lots of computation and ultra low latencies will continue to be run on servers.

I think what we need is tooling around web frameworks so that your web server code gets deployed as a series of lambda functions. I'm fine with deploying my code to AWS Lambda (or Google cloud, Azure, ...) but I hate not being able to test my code locally and I hate all the configuration stuff to be scattered around in a complex UI. I see serverless as a (sometimes) better way of deploying an API, I shouldn't have to completely change my workflow to do this.

View on HN

Don't forget kubernetes. A monolith with kubetnetes is in many ways easier to code, test, and deploy... and it is cross webhost.

I see some apps going serverless, and some going kubernetes. I cannot see a world where all apps go to aws locked in mess.

Kubernetes' cross webhost feature is not to be underestimated. Devops is the group that maintains the tooling that interacts with a company's given cloud provider, so if the order comes down from "on high" to change clouds (because negotiations with AWS end up meaning it's cheaper to move to a different cloud provider than it is to keep paying AWS), who is going to be doing the work to rewire code that talks to AWS Lambda?

If there's a big enough team to justify and support (multiple) Kubernetes clusters, many serverless pieces don't make sense.

And, at the end of the day, you gotta assume it's easier to rig-together a "serverless" solution on top of Kubernetes than it will be to make AWS Lambda driven apps into an orchestration solution...

Correct me if I'm wrong, but I get the impression Kubernetes is a somewhat expensive solution. The only reason I'd go with Kubernetes is if I was a) on Google cloud, which has first class support for Kubernetes b) a dedicated ops team deploying on premise.

You are wrong. It's not expensive.

I run it as a 1 man dev team, spend maybe a few minutes per month on it. Save about 2x over running the same workload on bare VMs, and maybe 4x over the same workload on lambda.

What platform do you run kubernetes on?

Google container engine.

But even on AWS.. all google is buying me is 1 "master" node for free (both running the node cost, and setting up the master cost). You can spin up a single reserved instance as your master node in about a day on AWS, and be good to go. So my "savings" by going google is like $50 and the setup of 1 master node. Outside of the master node, the experience is the same.

Bin packing is really nice. My app has something like 30 containers running. Using VMs, that would be 30 instances to fire up. In kubernetes, I fit it on 5 servers. Yes those 5 servers are a bit beefier, but it is still a pretty substantial savings.

> As much as I hate to admit it (I love my servers) I think serverless is the future for most CRUD / admin API's.

The pattern for CRUD is pretty straightforward, you have an API that sits in front of a memcache/redis layer and a database. There's nothing really stateful about the API, so it should be a good candidate for a lambda function.

However, since a lambda function is stateless, that means you can't maintain a connection to a caching or database layer. As far as I can tell, that means you can't actually build a scalable CRUD API with lambda?

I can't speak generally, but TCP connections stay warm between invocations with Google Cloud Functions.

I think you COULD but it's true you might end up with one DB connection per API call which might overwhelm your database server if you have too many concurrent requests that would be better off sharing a connection pool. For such scenarios you'd want more control than what serverless paradigms offer. On the other hand, most admin type API's don't get called very often.

Reply on news.ycombinator.com