Live data from Hacker News

Serverless Docker Beta

zeit.co

31–40 of 236 posts

Re: Serverless Docker Beta

#31
And so ZEIT, my favorite serverless provider, keeps getting better. Highlights:

- "sub-second cold boot (full round trip) for most workloads"

- HTTP/2.0 and websocket support

- Tune CPU and memory usage, which means even smoother scaling

And all that for any service you can fit in a Docker container - which is also how you get near-perfect dev/prod parity, an often overlooked issue with other serverless deployment techniques.

On top of all that, ZEIT has one of the best developer experiences out there today. Highly recommend trying it out.

And for the perpetual serverless haters out there: this is not a product for you, FANG developer. I think people underestimate how well serverless fits for the majority of web applications in the world today. Most small-medium businesses would be better off exploring serverless than standing up their own k8s cluster to run effectively one or two websites.

Re: Serverless Docker Beta

#32

Yep. Pretty soon. You write code. You create a docker file. You find a place to run the docker file with your code [cheapest!]. Run it through your tests. Monitor it. The end. No vpcs,salts, puppets, sshs,chefs, horses,anisbles, cats,ec2s,devops,noops, sysadmins, kubernetes or chaos monkeys required.

Until you discover that the thing you are building requires more than a single application running in a single container and you end up building an entire "Operating System" around your containers and the circle starts all over again. Complexity is hardly ever in the solution, but mostly in the problem. Single solutions to complex problems often ignore/forget important parts of the problem and they come back to bite…

I don't know... My experience is the other extreme - tech teams that make everything super complicated to support everything that can possibly happen. As a consequence, the it environment requires six months of experience to even understand. It's really not very fun to work in those environments. Lots of unnecessary complexity.

Re: Serverless Docker Beta

#33
post #14
post #3

My biggest problem with serverless functions is development and testing. Can I run these locally? even better offline?

As we mentioned in the blog post, there is zero difference between a `Dockerfile` you execute locally and one that you give to us. [One of the differences is performance. You'll find that we can build and execute much more quickly :)] There are many examples here: https://github.com/zeit/now-examples

> we can build [...] much more quickly

Care to elaborate? Did you write your own container builder (for example like Google did with kaniko) that you use instead of docker? If not, I fail to see how you can build faster than me locally.

Re: Serverless Docker Beta

#34
post #22
post #6

Looks great for basic websites but it's missing the biggest and most difficult piece of cloud infrastructure. The DATABASE! Today you'd have to open up your cloud DB provider to the world since Zeit can't provide a list of IPs to whitelist. This is a showstopper for me unfortunately.

If you connect to your database over TLS (maybe with an extra client certificate or something), I don't see much of a problem.

No, you do not make your DB publicly available only because you are using TLS. In general you do not expose anything to the world unless it is necessary and your service is battle tested. There are probably shitloads of possibly RCE-able vulnerabilities in the public facing code of most DBS, because, the heck, they aren't built to serve the public web, but to do database magic.

Re: Serverless Docker Beta

#36

> “A very common category of failure of software applications is associated with failures that occur after programs get into states that the developers didn't anticipate, usually arising after many cycles. In other words, programs can fail unexpectedly from accumulating state over a long lifespan of operation. Perhaps the most common example of this is a memory leak: the unanticipated growth of irreclaimable memory t…

The primary benefit of serverless is that you can pay per-second for CPU usage, right when a request comes in, instead of leaving whole OSes running all the time. This other stuff is just a bonus.

Re: Serverless Docker Beta

#37

Yep. Pretty soon. You write code. You create a docker file. You find a place to run the docker file with your code [cheapest!]. Run it through your tests. Monitor it. The end. No vpcs,salts, puppets, sshs,chefs, horses,anisbles, cats,ec2s,devops,noops, sysadmins, kubernetes or chaos monkeys required.

Until you discover that the thing you are building requires more than a single application running in a single container and you end up building an entire "Operating System" around your containers and the circle starts all over again. Complexity is hardly ever in the solution, but mostly in the problem. Single solutions to complex problems often ignore/forget important parts of the problem and they come back to bite…

That's called Kubernetes

Re: Serverless Docker Beta

#38
So I've been messing with Fn + Clojure + Graal Native Image and I'm seeing cold start times around 300-400ms and hot runs around 10-30ms. TLS adds something like 100-150ms on top of that. I was excited about seeing improved docker start times, but it seems like you guys are pretty much at the same place I am with it.

Here's my question, being relatively ignorant of Docker's internals: _is it possible_ to improve that docker create/docker start time from 300-400 ms (all in) to <100ms? 300-400ms is kind of a lot of latency for a cold boot still, and people still do things like keepalive pings to keep functions warm, so it would be pretty great to bring that down some more.

Re: Serverless Docker Beta

#40

And so ZEIT, my favorite serverless provider, keeps getting better. Highlights: - "sub-second cold boot (full round trip) for most workloads" - HTTP/2.0 and websocket support - Tune CPU and memory usage, which means even smoother scaling And all that for any service you can fit in a Docker container - which is also how you get near-perfect dev/prod parity, an often overlooked issue with other serverless deployment te…

I'm not a "serverless hater", but every company I've ever worked with had backend processes that were not tied to HTTP requests. I still keep actual servers around because the HTTP gateway is not the pain point. It's long-running processes, message systems, stream processing, and reporting.

That said, I look forward to the company (or side project) where "serverless" can save me from also assuming the "devops" role.

Post reply on HN