Serverless Docker Beta

And so ZEIT, my favorite serverless provider, keeps getting better. Highlights:<p>- &quot;sub-second cold boot (full round trip) for most workloads&quot;<p>- HTTP&#x2F;2.0 and websocket support<p>- Tune CPU and memory usage, which means even smoother scaling<p>And all that for any service you can fit in a Docker container - which is also how you get near-perfect dev&#x2F;prod parity, an often overlooked issue with other serverless deployment techniques.<p>On top of all that, ZEIT has one of the best developer experiences out there today. Highly recommend trying it out.<p>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.

Am I the only one having problems to follow .gif &quot;demos&quot;?<p>When I get to the image, it is in the middle of everything and I don&#x27;t really have an idea what is going on. Even watching it multiple times, I am not sure where it starts, ends, what the individual steps are.<p>Or is it because I just don&#x27;t know enough about this stuff?

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.

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

Shout out to the RCE I found in the zeit.now deploy button:<p><a href="https:&#x2F;&#x2F;github.com&#x2F;zpnk&#x2F;deploy.now&#x2F;issues&#x2F;27" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;zpnk&#x2F;deploy.now&#x2F;issues&#x2F;27</a><p>Hopefully someone from Zeit reading this can get my fix merged, it seems to be quite a popular service

&gt; “A very common category of failure of software applications is associated with failures that occur after programs get into states that the developers didn&#x27;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 that ultimately concludes in a faulty application.<p>&gt; <i>Serverless means never having to &quot;try turning it off and back on again&quot;</i><p>&gt; Serverless models completely remove this category of issues, ensuring that no request goes unserviced during the recycling, upgrading or scaling of an application, even when it encounters runtime errors.<p>&gt; How Does Now Ensure This?<p>&gt; Your deployment instances are constantly recycling and rotating. Because of the request-driven nature of scheduling execution, combined with limits such as maximum execution length, you avoid many common operational errors completely.<p>Somehow this sounds very expensive to me (like restarting Windows 2000 every hour just to avoid a BSoD, except that here it’s not that time consuming a process) and seems to leave aside caching, state management and other related requirements on the wayside for someone else to handle or recover from.<p>Or it’s likely that I’ve understood this wrong and that this can actually scale well for large, distributed apps of any kind. Sounds like magic if it’s that way.

Awesome! While I was at AWS Summit in NY, I asked a round circle of AWS ECS&#x2F;EKS users (Container orchestration products) about thoughts on a Docker container service that could execute like a FaaS product and there seemed to be none anyone knew of. I have a portion of a legacy application that&#x27;s used infrequently and too costly to decompose but works fine Dockerized.<p>Looking forward to using your product!

I&#x27;m confused about pricing. I come from using AWS Lambda, where you pay for the amount of memory allocated for your function, how many times it runs and how long each run is.<p>Looking at Now, it looks like you are billed by the &#x27;plan&#x27; that you choose, and that decides how many deployment instances you are limited to. What does a deployment instance mean for something that is &#x27;serverless&#x27;?<p>EDIT: Whoops, I see that there are &#x27;on demand&#x27; prices for deployment instances too--now I just need to figure out how deployment instances map to serverless.

So I&#x27;ve been messing with Fn + Clojure + Graal Native Image and I&#x27;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.<p>Here&#x27;s my question, being relatively ignorant of Docker&#x27;s internals: _is it possible_ to improve that docker create&#x2F;docker start time from 300-400 ms (all in) to &lt;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.

So this is different from running docker containers on heroku because heroku has 1 to n autoscaling but not 0 to n?<p>What are the other fundamental differences?

I am already running an API service on Zeit now using a golang container that adds the binary and a csv file to a scratch image and re-reads the csv on each request (all requests take less than 0.3 seconds so i have not optimized).<p>Currently I have to make sure to set min instances to 1 on the &#x27;production&#x27; version of the API and set min instances = 0 to older versions.<p>Will have to try before knowing for sure but I seems like switching to serverless docker would mean I don&#x27;t have to make the distinction between &#x27;old production&#x27; and &#x27;new production&#x27; anymore and keep servicing requests to very old versions of my API without an expensive (7 seconds) cold boot.<p>Nice!

Finally, I can have left-pad as a service.

I did not play with it, but this actually looks pretty cool. The documentation seems to be sane&#x2F;good quality.<p>A few questions: How would one coordinate between multiple nodes running an app? (scenario in which the nodes cooperate to find each other. is there some sort of discovery available?) For the docker case, does it support health probes? (how you you know if the app is healthy?)

This is truly amazing and has so much baked in I find myself wanting to use it. However most apps my team and I work on require some form of persistence - uploads, log ins, API rate limits, etc. These scenarios don&#x27;t fit well with the serverless world. It is technically possible to offset most of this to S3, a hosted NoSQL and perhaps even a service for dealing with a images&#x2F;thumbnails. By that time your monthly bill is in the three digits, though. For a big web shop this is fine but your average freelancer with multiple smaller and finite-resource projects it&#x27;s something to consider carefully.

&gt; Serverless<p>&gt; A new slot configuration property which defines the resource allocation in terms of CPU and Memory, defaulting to c.125-m512 (.125 of a vCPU and 512MB of memory)<p>Sure sounds like needing to be concerned about the hardware. That feels like a leaky abstraction that the serverless design pattern claims or appears to take care of, but seems like it doesn&#x27;t in practice. Is &quot;serverless&quot; the right level of abstraction? I&#x27;m not sure.

Great announcement.<p>This development was inevitable, especially since most Functions-as-a-service infrastructure was really docker (or some other) containers running in the background, spinning up on demand using a pool of servers. Azure Container Instances launched last year, and now Google Cloud Functions has serverless containers in alpha, along with the serverless addon for GKE&#x2F;Kubernetes, and there should be a good bit of announcements this year as other providers follow.<p>The max time limits still seem pointless to me, there should be an option for unlimited uptime so the full spectrum of ephemeral function to entire app can be managed and deployed using a single flow.

Serverless n00b here: I&#x27;m just playing with serverless Rust, via Apex, which works great so far.<p>Why would I want to switch to this? What are pros&#x2F;cons of having Docker in there?

There is no &#x27;hype&#x27; word in history I hate more then serverless. I was fine with microservices and all those other hype words but serverless is terrible.

A couple of questions for Zeit:<p>1. Once your docker container is built, am I paying to store it on Zeit?<p>2. How is a Dockerfile versioned? Can I update it? Or do I need to redeploy.<p>3. Is pricing for containers granular by time or per request to a container?<p>4. How can these Dockerfiles talk to each other? Is there an API or method to fetch specific url&#x27;s for each container?<p>Looks like a great idea, am curious to try it out sometime.

This is more of a question to @rauchg and others who have used now one. When I use now within the AWS realm, are the AWS services when used in conjunction with Zeit Now containers subjected to ingress&#x2F;egress costs? As it does sound like I am using a different cloud as far as AWS is concerned

Is there support planned for using this in combination with docker-compose? If so would be sweet to see this integrated with Prisma - <a href="https:&#x2F;&#x2F;www.prisma.io&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.prisma.io&#x2F;</a>

How can something be serverless if it habdles http requests? Does it just process requests and never serves responses, or is it just a hip-sounding misnomer?

My biggest concern with serverless is pricing. How does it fare when compared to regular Docker hosting and vps hosting?

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

What magic will they come up with next? Sheesh. Cool stuff, looking forward to having some time to play with it all.

Documentation is good. Post is informative. Interesting indeed.

I&#x27;ve never been more excited about a cloud platform than I am about Zeit&#x2F;Now. I wish you offered stateful volumes or key value stores or something where I can persist my data so I can keep all of my stack on Zeit.

&quot;Serverless&quot;<p>So where do your functions execute?