13 ms·

Serverless Docker Beta

595 points by Rauchg 8y ago

ransom1538 8y ago
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.
- grezql 8y ago
  this wont be popular but I always felt like docker was a step backwards in order to regroup and take a giant leap forward. I went from right clicking and deploying from visual studio to SSH and configuring dockerfiles, docker compose, even nginx.conf to loadbalance. You do get more bang for the buck with such setup but its too much work on infrastructure and less time for development. edit: add kubernetes to it, although AKS and GKE being free lessens the burden its still too much for a software dev like me.
  - deleted 8y ago
    [deleted]
  - k__ 8y ago
    Well, this is probably to find common ground between FaaS people and DevOps, haha. Being a FaaS proponent, I still think this could be a good idea, because of the kinda standardized workings of Docker. I mean, AWS also uses Docker for local testing.
  - DelightOne 8y ago
    > although AKS and GKE being free I‘m a developer too and I feel the burden too. Can you tell what you mean here?
    - grezql 8y ago
      Setting up and maintaining a kubernetes cluster on my own would probably kill me desire to touch a computer again. Azure and Google provides free Kubernetes-cluster-management-as-service. But you are right, its still a hassle.
      - _asummers 8y ago
        Been going through that process the past few days on Scaleway, as they don't have a hosted K8. It's... tough... but I'm learning a lot and have a much deeper understanding of K8s clusters from an operational perspective now. I have a much deeper understanding of the magic happening behind the scenes to keep everything talking to each other, and even if I wind up on a hosted solution in the end, it's been invaluable.
        grezql 8y ago
        thats what I told myslef too when I invested hours after hours learning Knockout then AngularJS. Only for reactjs to dominate a year after. I skipped learning react and stuck with angular. Now I hear rumours theres a new sheriff in town named Vue.js. Careful with filling your brain with domain-specific knowledge. :)
        esistgut 8y ago
        There is an early access program for they hosted kubernetes service https://www.scaleway.com/kubernetes/ https://www.scaleway.com/kubernetes/
        _asummers 8y ago
        Yeah I signed up months ago but haven't gotten an invite yet =(
      - grosjona 8y ago
        Deploying to a Kubernetes cluster is easy. You just have to learn a few key concepts to write your own .yaml definitions. Also, some open source frameworks come with the .yaml definitions already.
- crgwbr 8y ago
  I don’t think that’s likely or desirable. VPCs and the ability to make a service that’s not in the public internet are hugely valuable from a security standpoint. And Ansible, Terraform, etc are great for automation and managing configuration and architecture. It’s unwise to discard everything that came before you when hopping in the shiny new bandwagon. Even if it is the future, last generations tools can still teach you a lot.
- EGreg 8y ago
  Actually, even better: You use dat or MaidSAFE to write client side apps. The back end is end to end encrypted, secure, automatically rebalanced, uncensorable, permissionless, and people install your app and use a cryptocurrency to pay for resources. And of course you use public key cryptography to maintain your app and upgrades propagate without needing to select a domain or host for them.
- aequitas 8y ago
  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 you, hard.
  - some_account 8y ago
    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.
    - jarym 8y ago
      Yup. I’ve seen this - customers who insist every package has to be installed in some special place because /opt is ‘reserved’ - have to have non-standard ports for everything because it might slow down attackers - have to have an Apache proxy in front of everything, always - even internal components. ‘Cos. - won’t invest in trusted SSL certificates for internal services. - every sql query has to be wrapped in a stored procedure - no exceptions. ... list goes on
      - laumars 8y ago
        There is actually a reasonable arguement for the stored procedure one. It means you can have different permissions for tables as you do for stored procedures so your application doesn't have permission to directly query your passwords. The benefit there is if an attacker gains access to your application and/or the DB authentication credentials they cannot then export users passwords or other sensitive information.
        phil21 8y ago
- peterwwillis 8y ago
  You still need all that, you're just paying someone else to do it for you. As the app gets more complicated you will have to do more. It is impossible to remove complexity by adding abstraction. You've only hidden it.
  - weberc2 8y ago
    True, but like every thing else there are economies of scale to having a few specialists managing the abstraction that everyone else can depend on.
    - deleted 8y ago
      [deleted]
- artursapek 8y ago
  If you're working on anything with above-average security requirements you will still be managing your entire stack...
- meritt 8y ago
  Those things are still required. You're just paying for the abstraction and hoping your host is competent enough to keep things running smoothly.
- um_ya 8y ago
  dokku is pretty close to this.
- deleted 8y ago
  [deleted]
- laumars 8y ago
  Half the stuff you described there solve different problems to docker. Not to mention that docker doesn't solve all problems in infrastructure. I like to think of docker like git. It solves some problems with distributing data but it doesn't solve the problem of developers writing code, writing tests, pipelines, etc. Nor even problems with 3rd party APIs etc. Obviously this isn't a perfect analogy but my point is docker isn't a magical silver bullet. I've worked in places where their solution to everything was "docker" and it honestly caused more complexity problems than it solved. That's not to say I don't like docker; in fact I've been a big advocate for containerisation long before docker was a thing. However like with any tech, the key is using the right tool for the right job instead of attacking every screw with the same hammer.
- grosjona 8y ago
  Whenever a solution offers you simplicity, you're giving up flexibility. That's why I'd prefer to use a more advanced but standardized open source platform like Kubernetes.
- tw1010 8y ago
  It feels so amazingly depressing for so much sunk knowledge to just go away and be worthless. Feels like I could have learned so many more things that I could have had gotten joy out of today and still extract useful things out of, or build things on top of, long into the future if I'd just focus on the time-invariants of knowledge space.
netcraft 8y ago
My biggest problem with serverless functions is development and testing. Can I run these locally? even better offline?
- k__ 8y ago
  AFAIK at least AWS Lambda has a Docker based CLI that lets you run functions locally. I guess since the Zeit solution is based on Docker something like this should also be possible...
  - netcraft 8y ago
    ah, I didnt know that. I assume you mean this? https://github.com/lambci/docker-lambda https://github.com/lambci/docker-lambda
    - k__ 8y ago
      I mean this: https://github.com/awslabs/aws-sam-cli https://github.com/awslabs/aws-sam-cli
- Rauchg 8y ago
  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 https://github.com/zeit/now-examples
  - wereHamster 8y ago
    > 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.
  - e12e 8y ago
    So, I'm not running the same docker image, just something somewhat similar built from the same Dockerfile?
mirceal 8y ago
I did not play with it, but this actually looks pretty cool. The documentation seems to be sane/good quality. 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?)
- Rauchg 8y ago
  For the duration of the warm phase (i.e.: while the process is running), we ascertain healthfulness via `SYN` packets as a baseline. Because you give us your code under the constraint that it will expose data over a port, we have a much better safety baseline than stock schedulers, that operate under the assumption that the process describe by `CMD` is a black box. We will describe this in more detail in coming weeks. One of our priorities is to minimize the cognitive load on the developer necessary to run a healthy service at scale.
watty 8y ago
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.
- Rauchg 8y ago
  Most databases are quite unfit for the serverless world that's becoming a reality, where the needs shift towards global replication, flexible horizontal scalability (sharding) and vertical (provisioned QPS). We like and use CosmosDB because it fits this criteria. We anticipate that Google Spanner, CockroachDB and similar databases will become the go-tos in combination with ZEIT Now.
  - skrebbel 8y ago
    So what do most of your current customers do for data storage? I mean, I doubt they all use CosmosDB? (simply because it's not particularly mainstream)
    - lykr0n 8y ago
      You are going find most people still are using Master-Slave databases at some central datacenter. Spanned databases are great, but most of the time performance is not there (It's getting there, but it needs to be there for a year before people start to care)
    - arunoda 8y ago
      We don't have insight on what our customer's use mostly. We use existing technologies. Anyone can use any cloud Database service. We've datacenters on San Fransisco and in Belgium. So, based on those users can choose where they need to deploy their DBs. Usually we recommend to configure databases via env variables. Users can also use our [now secrets](https://zeit.co/docs/getting-started/secrets https://zeit.co/docs/getting-started/secrets) service as well to avoid hard-coding secrets.
  - 8y ago
unixhero 8y ago
My biggest concern with serverless is pricing. How does it fare when compared to regular Docker hosting and vps hosting?
- Rauchg 8y ago
  We will be announcing very clear pricing when it goes into GA. Needless to say, serverless makes for a much much cheaper (and robust) operation than VPS and traditional clusters.
- k__ 8y ago
  If you can leverage caching solutions (client, CDN, etc.) it could be a good chunk cheaper. Maybe it simply leads to smaller teams and you save in employee costs.
- tfolbrecht 8y ago
  If you pull an application apart and squeeze it into managed services, your costs can drop by an order of magnitude depending on your availability requirements, engineering related costs, etc. A good article written by Spotinst's CEO [1] Not trying to shill, not everything should be serverless, and I should work to be more platform agnostic, but AWS has been great to and for me, AWS marketing material [2] [1] https://medium.com/@amiram_26122/the-hidden-costs-of-serverless-6ced7844780b https://medium.com/@amiram_26122/the-hidden-costs-of-serverl... [2] https://aws.amazon.com/serverless/ https://aws.amazon.com/serverless/
orf 8y ago
Shout out to the RCE I found in the zeit.now deploy button: https://github.com/zpnk/deploy.now/issues/27 https://github.com/zpnk/deploy.now/issues/27 Hopefully someone from Zeit reading this can get my fix merged, it seems to be quite a popular service
- Rauchg 8y ago
  This is not supported nor maintained by us. Thanks a lot for bringing it to our attention. We will do our best to reach out!
  - orf 8y ago
    Sure, but I reached out nearly a year ago to the maintainers with no reply. It seems anyone can now execute anything on your infrastructure (for free!), which isn't great.
    - simonw 8y ago
      That's the case already: anyone can sign up for a free Zeit account and deploy code (wrapped in a Docker container) that then executes on Zeit's infrastructure.
      - orf 8y ago
        And now someone can do it without signing up, using someone else's account, possobly disabling a widely used and quite cool service.
newscracker 8y ago
> “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 that ultimately concludes in a faulty application. > Serverless means never having to "try turning it off and back on again" > 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. > How Does Now Ensure This? > 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. 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. 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.
- agency 8y ago
  Really brings to mind that Rasmus Lerdorf quote: > I'm not a real programmer. I throw together things until it works then I move on. The real programmers will say "Yeah it works but you're leaking memory everywhere. Perhaps we should fix that." I’ll just restart Apache every 10 requests.
  - gfodor 8y ago
    It's funny when I was reading this part of the article I thought "that sounds exactly like how PHP works!"
- Rauchg 8y ago
  > 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) The crucial difference is that the activation cost of booting up a full OS (like Windows 2000) is massive (typically involving a chain-reaction of CPU and IO-intensive init services), whereas that is not the case for our serverless infrastructure. What you do point out is one of the most important engineering challenges we had to solve (and continue to be focused on).
robrtsql 8y ago
I'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. Looking at Now, it looks like you are billed by the 'plan' that you choose, and that decides how many deployment instances you are limited to. What does a deployment instance mean for something that is 'serverless'? EDIT: Whoops, I see that there are 'on demand' prices for deployment instances too--now I just need to figure out how deployment instances map to serverless.
andrewtorkbaker 8y ago
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.
- symlock 8y ago
  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.
  - TomMarius 8y ago
    Hello, I'm building a serverless platform. Could you please expand your "It's long-running processes, message systems, stream processing, and reporting" bit?
    - stingraycharles 8y ago
      Not parent, but I have the same question; I worked in adtech and video analytics before, now with social media. It's usually a mix of some REST APIs, which already are very easy to scale and manage without using serverless, with long-running backend processes, such as: * video encoding; * ETL processes; * other analytical workloads; * long-running websocket connections with Twitter/Facebook/etc APIs. From my perspective, serverless solves the "boring" part of making REST APIs easier to manage, which were already very easy to manage. How would serverless be applies to, say, a python script that streams Twitter tweets using websockets?
nickik 8y ago
There is no 'hype' word in history I hate more then serverless. I was fine with microservices and all those other hype words but serverless is terrible.
- SamLevin88 8y ago
  mind elaborating a bit?
  - icedchai 8y ago
    He's probably mad because with serverless, there are servers. You just have no control over them. "Serverless" is just "shared hosting" reinvented...
  - nickik 8y ago
    There are still servers involved. Serverless sounds like its peer to peer. What it really is is VM less.
    - Drdrdrq 8y ago
      Well, as a developer I don't need to concern myself with servers, so in a way the term is fitting.
      - nickik 8y ago
        The interface it gives you is the functionality that the server provides. A server does not mean 'operating system'. you don't have to deal with the OS, but you still have you app running on the server.
    - collinmanderson 8y ago
      There's still a VM, too. Can we call it "stateless"? Because there's theoretically no server state between requests?
jgh 8y ago
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.
- rdallman 8y ago
  Hey there, fn dev here. Cool to hear about folks testing the graal images! We have done some experimental work and made some discoveries in the container cold start time dept. which we've documented https://blogs.oracle.com/developers/building-a-container-runtime-in-rust https://blogs.oracle.com/developers/building-a-container-run... (see: Fast Container Startup). The main things are optimizations around pre-allocating network namespaces, we've built some experimental code to skirt around this https://github.com/fnproject/fn/blob/master/api/agent/drivers/docker/docker_pool.go https://github.com/fnproject/fn/blob/master/api/agent/driver... (which can be configured & tested) and we're testing approaches like this to attempt to get start times down to as low as we can. <100ms still seems like a lofty goal at this point, but this is becoming a pain point for various FaaS platforms that are container based and some optimization work should come out of all this. A few layers up, it's a little easier to speed things when throughput increases for a given function, but devs do seem to want the 0->1 case to be almost as fast as the 'hot' case so we FaaS people need to answer this better in general, it isn't something we want users to have to think about!
- jacques_chester 8y ago
  There are a lot of low- and medium-hanging fruit in this space. I take the view that there is a "warmth hierarchy" (an idea I spitballed with other folks in Knative before Matt Moore took it and filled it out a lot). You have a request or message. You need to process it. The hierarchy runs CPU > Memory > Disk > Cold. CPU-warm: immediately schedulable by the OS. Order of nanoseconds. Memory-warm: in-memory but can't be immediately scheduled. Our reference case is processes that have been cgroup frozen. Order of tens of milliseconds. Disk-warm: the necessary layers are all present on the node which is assigned to launch the process. Order of hundreds of milliseconds. Cold start: nothing is present on the node which is assigned to launch the process. It will need to fetch some or all layers from a registry. Order of seconds to minutes. Some of these problems can't be solved by Kubernetes (it doesn't know how to freeze a process), some of them can't be solved by Docker (it doesn't know about other nodes that might have warmer disk caches). Then there's the business of deciding where to route traffic, how to prewarm caches and based on what predictive approach, avoiding siloisation of processes due to feedback loops. As these are knocked down they will pay dividends for everyone.
virtualritz 8y ago
Serverless n00b here: I'm just playing with serverless Rust, via Apex, which works great so far. Why would I want to switch to this? What are pros/cons of having Docker in there?
- iampims 8y ago
  You don’t need a shim on top of Rust. You can run your docker image anywhere it is supported, like Heroku for instance…
manigandham 8y ago
Great announcement. 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/Kubernetes, and there should be a good bit of announcements this year as other providers follow. 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.
gamegod 8y ago
Finally, I can have left-pad as a service.
ingenieroariel 8y ago
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). Currently I have to make sure to set min instances to 1 on the 'production' version of the API and set min instances = 0 to older versions. Will have to try before knowing for sure but I seems like switching to serverless docker would mean I don't have to make the distinction between 'old production' and 'new production' anymore and keep servicing requests to very old versions of my API without an expensive (7 seconds) cold boot. Nice!
- arunoda 8y ago
  You can alias your deployment and try to add a scaling rule to the alias. So, you don't scale up and down as you deploy. Once you call the `now alias` it'll take care of the scaling.
Sujan 8y ago
Am I the only one having problems to follow .gif "demos"? When I get to the image, it is in the middle of everything and I don'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. Or is it because I just don't know enough about this stuff?
- Sujan 8y ago
  Oh, and to make this more than a simple rant/whine, some constructive suggestions that could possibly solve the problem: - Normal video with playback controls? - Add a clearly distinguishable "this is where it starts" screen. - Is there maybe a way to control playback of a gif via JS/HTML? Add a "restart" button. - Add a timeline into the .gif that shows where I am (similar to usual video player).
  - piyh 8y ago
    Make it a webm. Then you can right click from pretty much any browser and click "show controls". See Gyfcat.
    - marzell 8y ago
      You can view controls on GIFs in many cases as well, I believe. Also, nobody seems to make use of these features, but GIFs do not have to loop, nor do they have to loop by going back to the very beginning of the animation as well. In particular, I find it extremely ineffective where there are GIFs that only show a "final product/scene" for like 1 frame before looping back to the beginning.
      - TheDong 8y ago
        > You can view controls on GIFs in many cases as well, I believe I don't think that's true. Twitter and imgur do convert gifs to mp4, and you can see controls there, but that's because they're not gifs. Do you have a citation or example of controls on actual gifs in any commonly used web browser?
lxe 8y ago
I've never been more excited about a cloud platform than I am about Zeit/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.
- iampims 8y ago
  I suggest you use something like DynamoDB, it fits this paradigm quite well.
StanAngeloff 8y ago
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'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/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's something to consider carefully.
fake-name 8y ago
"Serverless" So where do your functions execute?
- gregknicholson 8y ago
  I think “serverless” doesn't actually mean no server (a distributed system, like Dat); it means “don't worry about the server; we'll take care of it for you”. …or maybe that's “Cloud”. Is there a clear explanation of what “serverless” means, and how it's different from “Cloud”, suitable for semi-technical non-developers?
  - collinmanderson 8y ago
    It's usually called "serverless" when the "servers" are created on demand when a request comes in, cold server start-up takes less than a second, and there's theoretically no server state between requests. I think "stateless" is a better term.
  - dx87 8y ago
    From what I understand, "Cloud" basically means that you still have to deal with servers, whether they be VMs or physical devices, but all of the networking and loadbalancing aspects are abstracted away. "Serverless" takes it a step further and makes it so you don't even have to deal with setting up VMs, you just give the provider the code you'd normally run on a host, and they'll automatically handle all of the infrastructure stuff, like spinning up extra hosts under heavy load.
  - fake-name 8y ago
    Sure: Serverless - "Re reimplemented/packaged a code runtime, and jerked off about marketing a bunch" My Butt - "Run your shit on someone else's computer" TBF, if the 'serverless' shit was sold as "run functions without needing to fiddle with an os", that's a decent selling point. It's not server-less, tho.
SamLevin88 8y ago
Documentation is good. Post is informative. Interesting indeed.
tango12 8y ago
So this is different from running docker containers on heroku because heroku has 1 to n autoscaling but not 0 to n? What are the other fundamental differences?
- tfolbrecht 8y ago
  It's actually pretty similar to the Heroku free tier dyno "sleep" till there's a trigger, but it's stateless. Different pricing, different ways of conceptualizing but from a user perspective that's a pretty good comparison.
  - jacques_chester 8y ago
    My running joke has been that a FaaS is a PaaS with the round bit of "P" rubbed out.
  - tango12 8y ago
    Should be very easy for heroku to add serverless containers then. Their cold-starts for their free tier is a few seconds and works quite well.
  - collinmanderson 8y ago
    > it's stateless. Can we use "stateless" instead of "severless"? That seems like a better term.
gigatexal 8y ago
What magic will they come up with next? Sheesh. Cool stuff, looking forward to having some time to play with it all.
danpalmer 8y ago
> Serverless > 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) 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't in practice. Is "serverless" the right level of abstraction? I'm not sure.
- arunoda 8y ago
  Whether it's serverless of not choice of hardware is very important. For an simple web app, you might not need special CPU and Memory requirements. But for a video encoding/decoding serverless app may needs different CPU/Memory requirements (and GPU). That's what this `slot` configuration property does. The default is good enough for all the general purpose apps. But if you need more, you can control it.
  - danpalmer 8y ago
    I agree that one-size-fits-all doesn't work with hardware requirements, but I still think this is a leaky abstraction. The promise of Serverless is not having to care about servers, but this is an option to specifically control that. A better abstraction would auto-optimise hardware spec for the software's performance characteristics - that would be much more "serverless".
tfolbrecht 8y ago
Awesome! While I was at AWS Summit in NY, I asked a round circle of AWS ECS/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's used infrequently and too costly to decompose but works fine Dockerized. Looking forward to using your product!
- deleted 8y ago
  [deleted]
- TheDong 8y ago
  I'm amazed no one knew of one. Off the top of my head, services which let you run docker containers without dealing with any servers yourself: 1. AWS Fargate 2. Joyent Triton (which was as simple as DOCKER_HOST=<joyent-ip> docker run back in 2015) 3. hyper.sh (available since 2016 I think?) 4. OpenFaaS cloud (though you have to go through a couple more steps, you can bring a custom docker image as your 'function'). 5. A metric ton of hosted kubernetes offerings
  - tfolbrecht 8y ago
    Maybe I didn't form the question correctly. Appreciate the list of services!
  - tapsboy 8y ago
    Also ACI (Azure Container Instances)
fru2013 8y ago
Is there support planned for using this in combination with docker-compose? If so would be sweet to see this integrated with Prisma - https://www.prisma.io/ https://www.prisma.io/
williesleg 8y ago
It looks like they run commands on a server.
gitgud 8y ago
A couple of questions for Zeit: 1. Once your docker container is built, am I paying to store it on Zeit? 2. How is a Dockerfile versioned? Can I update it? Or do I need to redeploy. 3. Is pricing for containers granular by time or per request to a container? 4. How can these Dockerfiles talk to each other? Is there an API or method to fetch specific url's for each container? Looks like a great idea, am curious to try it out sometime.
- arunoda 8y ago
  > 1. Once your docker container is built, am I paying to store it on Zeit? No. You don't need to pay to store containers. > 2. How is a Dockerfile versioned? Can I update it? Or do I need to redeploy Once the Dockerfile is built, you'll get a URL for that. It's a immutable URL and you don't need to re-deploy again. It'll sleep if there are no HTTP requests. If there are it'll start again. > 3. Is pricing for containers granular by time or per request to a container? It's based on the container running time. But we'll have a another blog post on this soon with more info. > 4. How can these Dockerfiles talk to each other? Is there an API or method to fetch specific url's for each container? There's no internal API to communicate with each other. But every docker container has a URL. You can use our [alias](https://zeit.co/docs/features/aliases https://zeit.co/docs/features/aliases) feature and communicate with each other via HTTP.
tapsboy 8y ago
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/egress costs? As it does sound like I am using a different cloud as far as AWS is concerned
daveheq 8y ago
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?
- mildweed 8y ago
  Long story short, there's a server somewhere, but most of the configuration is abstracted away. Instead of thinking of servers, they want you to think about endpoints (which they manage somewhat efficiently for you).

595 points by Rauchg 8y ago

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.

grezql 8y ago
this wont be popular but I always felt like docker was a step backwards in order to regroup and take a giant leap forward. I went from right clicking and deploying from visual studio to SSH and configuring dockerfiles, docker compose, even nginx.conf to loadbalance. You do get more bang for the buck with such setup but its too much work on infrastructure and less time for development. edit: add kubernetes to it, although AKS and GKE being free lessens the burden its still too much for a software dev like me.
- deleted 8y ago
  [deleted]
- k__ 8y ago
  Well, this is probably to find common ground between FaaS people and DevOps, haha. Being a FaaS proponent, I still think this could be a good idea, because of the kinda standardized workings of Docker. I mean, AWS also uses Docker for local testing.
- DelightOne 8y ago
  > although AKS and GKE being free I‘m a developer too and I feel the burden too. Can you tell what you mean here?
  - grezql 8y ago
    Setting up and maintaining a kubernetes cluster on my own would probably kill me desire to touch a computer again. Azure and Google provides free Kubernetes-cluster-management-as-service. But you are right, its still a hassle.
    - _asummers 8y ago
      Been going through that process the past few days on Scaleway, as they don't have a hosted K8. It's... tough... but I'm learning a lot and have a much deeper understanding of K8s clusters from an operational perspective now. I have a much deeper understanding of the magic happening behind the scenes to keep everything talking to each other, and even if I wind up on a hosted solution in the end, it's been invaluable.
      - grezql 8y ago
        thats what I told myslef too when I invested hours after hours learning Knockout then AngularJS. Only for reactjs to dominate a year after. I skipped learning react and stuck with angular. Now I hear rumours theres a new sheriff in town named Vue.js. Careful with filling your brain with domain-specific knowledge. :)
      - esistgut 8y ago
        There is an early access program for they hosted kubernetes service https://www.scaleway.com/kubernetes/ https://www.scaleway.com/kubernetes/
        _asummers 8y ago
        Yeah I signed up months ago but haven't gotten an invite yet =(
    - grosjona 8y ago
      Deploying to a Kubernetes cluster is easy. You just have to learn a few key concepts to write your own .yaml definitions. Also, some open source frameworks come with the .yaml definitions already.
crgwbr 8y ago
I don’t think that’s likely or desirable. VPCs and the ability to make a service that’s not in the public internet are hugely valuable from a security standpoint. And Ansible, Terraform, etc are great for automation and managing configuration and architecture. It’s unwise to discard everything that came before you when hopping in the shiny new bandwagon. Even if it is the future, last generations tools can still teach you a lot.
EGreg 8y ago
Actually, even better: You use dat or MaidSAFE to write client side apps. The back end is end to end encrypted, secure, automatically rebalanced, uncensorable, permissionless, and people install your app and use a cryptocurrency to pay for resources. And of course you use public key cryptography to maintain your app and upgrades propagate without needing to select a domain or host for them.
aequitas 8y ago
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 you, hard.
- some_account 8y ago
  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.
  - jarym 8y ago
    Yup. I’ve seen this - customers who insist every package has to be installed in some special place because /opt is ‘reserved’ - have to have non-standard ports for everything because it might slow down attackers - have to have an Apache proxy in front of everything, always - even internal components. ‘Cos. - won’t invest in trusted SSL certificates for internal services. - every sql query has to be wrapped in a stored procedure - no exceptions. ... list goes on
    - laumars 8y ago
      There is actually a reasonable arguement for the stored procedure one. It means you can have different permissions for tables as you do for stored procedures so your application doesn't have permission to directly query your passwords. The benefit there is if an attacker gains access to your application and/or the DB authentication credentials they cannot then export users passwords or other sensitive information.
      - phil21 8y ago
peterwwillis 8y ago
You still need all that, you're just paying someone else to do it for you. As the app gets more complicated you will have to do more. It is impossible to remove complexity by adding abstraction. You've only hidden it.
- weberc2 8y ago
  True, but like every thing else there are economies of scale to having a few specialists managing the abstraction that everyone else can depend on.
  - deleted 8y ago
    [deleted]
artursapek 8y ago
If you're working on anything with above-average security requirements you will still be managing your entire stack...
meritt 8y ago
Those things are still required. You're just paying for the abstraction and hoping your host is competent enough to keep things running smoothly.
um_ya 8y ago
dokku is pretty close to this.
deleted 8y ago
[deleted]
laumars 8y ago
Half the stuff you described there solve different problems to docker. Not to mention that docker doesn't solve all problems in infrastructure. I like to think of docker like git. It solves some problems with distributing data but it doesn't solve the problem of developers writing code, writing tests, pipelines, etc. Nor even problems with 3rd party APIs etc. Obviously this isn't a perfect analogy but my point is docker isn't a magical silver bullet. I've worked in places where their solution to everything was "docker" and it honestly caused more complexity problems than it solved. That's not to say I don't like docker; in fact I've been a big advocate for containerisation long before docker was a thing. However like with any tech, the key is using the right tool for the right job instead of attacking every screw with the same hammer.
grosjona 8y ago
Whenever a solution offers you simplicity, you're giving up flexibility. That's why I'd prefer to use a more advanced but standardized open source platform like Kubernetes.
tw1010 8y ago
It feels so amazingly depressing for so much sunk knowledge to just go away and be worthless. Feels like I could have learned so many more things that I could have had gotten joy out of today and still extract useful things out of, or build things on top of, long into the future if I'd just focus on the time-invariants of knowledge space.

netcraft 8y ago

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

k__ 8y ago
AFAIK at least AWS Lambda has a Docker based CLI that lets you run functions locally. I guess since the Zeit solution is based on Docker something like this should also be possible...
- netcraft 8y ago
  ah, I didnt know that. I assume you mean this? https://github.com/lambci/docker-lambda https://github.com/lambci/docker-lambda
  - k__ 8y ago
    I mean this: https://github.com/awslabs/aws-sam-cli https://github.com/awslabs/aws-sam-cli
Rauchg 8y ago
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 https://github.com/zeit/now-examples
- wereHamster 8y ago
  > 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.
- e12e 8y ago
  So, I'm not running the same docker image, just something somewhat similar built from the same Dockerfile?

mirceal 8y ago

I did not play with it, but this actually looks pretty cool. The documentation seems to be sane/good quality. 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?)

Rauchg 8y ago
For the duration of the warm phase (i.e.: while the process is running), we ascertain healthfulness via `SYN` packets as a baseline. Because you give us your code under the constraint that it will expose data over a port, we have a much better safety baseline than stock schedulers, that operate under the assumption that the process describe by `CMD` is a black box. We will describe this in more detail in coming weeks. One of our priorities is to minimize the cognitive load on the developer necessary to run a healthy service at scale.

watty 8y ago

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.

Rauchg 8y ago
Most databases are quite unfit for the serverless world that's becoming a reality, where the needs shift towards global replication, flexible horizontal scalability (sharding) and vertical (provisioned QPS). We like and use CosmosDB because it fits this criteria. We anticipate that Google Spanner, CockroachDB and similar databases will become the go-tos in combination with ZEIT Now.
- skrebbel 8y ago
  So what do most of your current customers do for data storage? I mean, I doubt they all use CosmosDB? (simply because it's not particularly mainstream)
  - lykr0n 8y ago
    You are going find most people still are using Master-Slave databases at some central datacenter. Spanned databases are great, but most of the time performance is not there (It's getting there, but it needs to be there for a year before people start to care)
  - arunoda 8y ago
    We don't have insight on what our customer's use mostly. We use existing technologies. Anyone can use any cloud Database service. We've datacenters on San Fransisco and in Belgium. So, based on those users can choose where they need to deploy their DBs. Usually we recommend to configure databases via env variables. Users can also use our [now secrets](https://zeit.co/docs/getting-started/secrets https://zeit.co/docs/getting-started/secrets) service as well to avoid hard-coding secrets.
- 8y ago

unixhero 8y ago

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

Rauchg 8y ago
We will be announcing very clear pricing when it goes into GA. Needless to say, serverless makes for a much much cheaper (and robust) operation than VPS and traditional clusters.
k__ 8y ago
If you can leverage caching solutions (client, CDN, etc.) it could be a good chunk cheaper. Maybe it simply leads to smaller teams and you save in employee costs.
tfolbrecht 8y ago
If you pull an application apart and squeeze it into managed services, your costs can drop by an order of magnitude depending on your availability requirements, engineering related costs, etc. A good article written by Spotinst's CEO [1] Not trying to shill, not everything should be serverless, and I should work to be more platform agnostic, but AWS has been great to and for me, AWS marketing material [2] [1] https://medium.com/@amiram_26122/the-hidden-costs-of-serverless-6ced7844780b https://medium.com/@amiram_26122/the-hidden-costs-of-serverl... [2] https://aws.amazon.com/serverless/ https://aws.amazon.com/serverless/

orf 8y ago

Shout out to the RCE I found in the zeit.now deploy button: https://github.com/zpnk/deploy.now/issues/27 https://github.com/zpnk/deploy.now/issues/27 Hopefully someone from Zeit reading this can get my fix merged, it seems to be quite a popular service

Rauchg 8y ago
This is not supported nor maintained by us. Thanks a lot for bringing it to our attention. We will do our best to reach out!
- orf 8y ago
  Sure, but I reached out nearly a year ago to the maintainers with no reply. It seems anyone can now execute anything on your infrastructure (for free!), which isn't great.
  - simonw 8y ago
    That's the case already: anyone can sign up for a free Zeit account and deploy code (wrapped in a Docker container) that then executes on Zeit's infrastructure.
    - orf 8y ago
      And now someone can do it without signing up, using someone else's account, possobly disabling a widely used and quite cool service.

newscracker 8y ago

> “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 that ultimately concludes in a faulty application. > Serverless means never having to "try turning it off and back on again" > 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. > How Does Now Ensure This? > 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. 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. 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.

agency 8y ago
Really brings to mind that Rasmus Lerdorf quote: > I'm not a real programmer. I throw together things until it works then I move on. The real programmers will say "Yeah it works but you're leaking memory everywhere. Perhaps we should fix that." I’ll just restart Apache every 10 requests.
- gfodor 8y ago
  It's funny when I was reading this part of the article I thought "that sounds exactly like how PHP works!"
Rauchg 8y ago
> 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) The crucial difference is that the activation cost of booting up a full OS (like Windows 2000) is massive (typically involving a chain-reaction of CPU and IO-intensive init services), whereas that is not the case for our serverless infrastructure. What you do point out is one of the most important engineering challenges we had to solve (and continue to be focused on).

robrtsql 8y ago

I'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. Looking at Now, it looks like you are billed by the 'plan' that you choose, and that decides how many deployment instances you are limited to. What does a deployment instance mean for something that is 'serverless'? EDIT: Whoops, I see that there are 'on demand' prices for deployment instances too--now I just need to figure out how deployment instances map to serverless.

andrewtorkbaker 8y ago

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.

symlock 8y ago
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.
- TomMarius 8y ago
  Hello, I'm building a serverless platform. Could you please expand your "It's long-running processes, message systems, stream processing, and reporting" bit?
  - stingraycharles 8y ago
    Not parent, but I have the same question; I worked in adtech and video analytics before, now with social media. It's usually a mix of some REST APIs, which already are very easy to scale and manage without using serverless, with long-running backend processes, such as: * video encoding; * ETL processes; * other analytical workloads; * long-running websocket connections with Twitter/Facebook/etc APIs. From my perspective, serverless solves the "boring" part of making REST APIs easier to manage, which were already very easy to manage. How would serverless be applies to, say, a python script that streams Twitter tweets using websockets?

nickik 8y ago

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

SamLevin88 8y ago
mind elaborating a bit?
- icedchai 8y ago
  He's probably mad because with serverless, there are servers. You just have no control over them. "Serverless" is just "shared hosting" reinvented...
- nickik 8y ago
  There are still servers involved. Serverless sounds like its peer to peer. What it really is is VM less.
  - Drdrdrq 8y ago
    Well, as a developer I don't need to concern myself with servers, so in a way the term is fitting.
    - nickik 8y ago
      The interface it gives you is the functionality that the server provides. A server does not mean 'operating system'. you don't have to deal with the OS, but you still have you app running on the server.
  - collinmanderson 8y ago
    There's still a VM, too. Can we call it "stateless"? Because there's theoretically no server state between requests?

jgh 8y ago

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.

rdallman 8y ago
Hey there, fn dev here. Cool to hear about folks testing the graal images! We have done some experimental work and made some discoveries in the container cold start time dept. which we've documented https://blogs.oracle.com/developers/building-a-container-runtime-in-rust https://blogs.oracle.com/developers/building-a-container-run... (see: Fast Container Startup). The main things are optimizations around pre-allocating network namespaces, we've built some experimental code to skirt around this https://github.com/fnproject/fn/blob/master/api/agent/drivers/docker/docker_pool.go https://github.com/fnproject/fn/blob/master/api/agent/driver... (which can be configured & tested) and we're testing approaches like this to attempt to get start times down to as low as we can. <100ms still seems like a lofty goal at this point, but this is becoming a pain point for various FaaS platforms that are container based and some optimization work should come out of all this. A few layers up, it's a little easier to speed things when throughput increases for a given function, but devs do seem to want the 0->1 case to be almost as fast as the 'hot' case so we FaaS people need to answer this better in general, it isn't something we want users to have to think about!
jacques_chester 8y ago
There are a lot of low- and medium-hanging fruit in this space. I take the view that there is a "warmth hierarchy" (an idea I spitballed with other folks in Knative before Matt Moore took it and filled it out a lot). You have a request or message. You need to process it. The hierarchy runs CPU > Memory > Disk > Cold. CPU-warm: immediately schedulable by the OS. Order of nanoseconds. Memory-warm: in-memory but can't be immediately scheduled. Our reference case is processes that have been cgroup frozen. Order of tens of milliseconds. Disk-warm: the necessary layers are all present on the node which is assigned to launch the process. Order of hundreds of milliseconds. Cold start: nothing is present on the node which is assigned to launch the process. It will need to fetch some or all layers from a registry. Order of seconds to minutes. Some of these problems can't be solved by Kubernetes (it doesn't know how to freeze a process), some of them can't be solved by Docker (it doesn't know about other nodes that might have warmer disk caches). Then there's the business of deciding where to route traffic, how to prewarm caches and based on what predictive approach, avoiding siloisation of processes due to feedback loops. As these are knocked down they will pay dividends for everyone.

virtualritz 8y ago

Serverless n00b here: I'm just playing with serverless Rust, via Apex, which works great so far. Why would I want to switch to this? What are pros/cons of having Docker in there?

iampims 8y ago
You don’t need a shim on top of Rust. You can run your docker image anywhere it is supported, like Heroku for instance…

manigandham 8y ago

Great announcement. 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/Kubernetes, and there should be a good bit of announcements this year as other providers follow. 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.

gamegod 8y ago

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

ingenieroariel 8y ago

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). Currently I have to make sure to set min instances to 1 on the 'production' version of the API and set min instances = 0 to older versions. Will have to try before knowing for sure but I seems like switching to serverless docker would mean I don't have to make the distinction between 'old production' and 'new production' anymore and keep servicing requests to very old versions of my API without an expensive (7 seconds) cold boot. Nice!

arunoda 8y ago
You can alias your deployment and try to add a scaling rule to the alias. So, you don't scale up and down as you deploy. Once you call the `now alias` it'll take care of the scaling.

Sujan 8y ago

Am I the only one having problems to follow .gif "demos"? When I get to the image, it is in the middle of everything and I don'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. Or is it because I just don't know enough about this stuff?

Sujan 8y ago
Oh, and to make this more than a simple rant/whine, some constructive suggestions that could possibly solve the problem: - Normal video with playback controls? - Add a clearly distinguishable "this is where it starts" screen. - Is there maybe a way to control playback of a gif via JS/HTML? Add a "restart" button. - Add a timeline into the .gif that shows where I am (similar to usual video player).
- piyh 8y ago
  Make it a webm. Then you can right click from pretty much any browser and click "show controls". See Gyfcat.
  - marzell 8y ago
    You can view controls on GIFs in many cases as well, I believe. Also, nobody seems to make use of these features, but GIFs do not have to loop, nor do they have to loop by going back to the very beginning of the animation as well. In particular, I find it extremely ineffective where there are GIFs that only show a "final product/scene" for like 1 frame before looping back to the beginning.
    - TheDong 8y ago
      > You can view controls on GIFs in many cases as well, I believe I don't think that's true. Twitter and imgur do convert gifs to mp4, and you can see controls there, but that's because they're not gifs. Do you have a citation or example of controls on actual gifs in any commonly used web browser?

lxe 8y ago

I've never been more excited about a cloud platform than I am about Zeit/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.

iampims 8y ago
I suggest you use something like DynamoDB, it fits this paradigm quite well.

StanAngeloff 8y ago

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'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/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's something to consider carefully.

fake-name 8y ago

"Serverless" So where do your functions execute?

gregknicholson 8y ago
I think “serverless” doesn't actually mean no server (a distributed system, like Dat); it means “don't worry about the server; we'll take care of it for you”. …or maybe that's “Cloud”. Is there a clear explanation of what “serverless” means, and how it's different from “Cloud”, suitable for semi-technical non-developers?
- collinmanderson 8y ago
  It's usually called "serverless" when the "servers" are created on demand when a request comes in, cold server start-up takes less than a second, and there's theoretically no server state between requests. I think "stateless" is a better term.
- dx87 8y ago
  From what I understand, "Cloud" basically means that you still have to deal with servers, whether they be VMs or physical devices, but all of the networking and loadbalancing aspects are abstracted away. "Serverless" takes it a step further and makes it so you don't even have to deal with setting up VMs, you just give the provider the code you'd normally run on a host, and they'll automatically handle all of the infrastructure stuff, like spinning up extra hosts under heavy load.
- fake-name 8y ago
  Sure: Serverless - "Re reimplemented/packaged a code runtime, and jerked off about marketing a bunch" My Butt - "Run your shit on someone else's computer" TBF, if the 'serverless' shit was sold as "run functions without needing to fiddle with an os", that's a decent selling point. It's not server-less, tho.

SamLevin88 8y ago

Documentation is good. Post is informative. Interesting indeed.

tango12 8y ago

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

tfolbrecht 8y ago
It's actually pretty similar to the Heroku free tier dyno "sleep" till there's a trigger, but it's stateless. Different pricing, different ways of conceptualizing but from a user perspective that's a pretty good comparison.
- jacques_chester 8y ago
  My running joke has been that a FaaS is a PaaS with the round bit of "P" rubbed out.
- tango12 8y ago
  Should be very easy for heroku to add serverless containers then. Their cold-starts for their free tier is a few seconds and works quite well.
- collinmanderson 8y ago
  > it's stateless. Can we use "stateless" instead of "severless"? That seems like a better term.

gigatexal 8y ago

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

danpalmer 8y ago

> Serverless > 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) 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't in practice. Is "serverless" the right level of abstraction? I'm not sure.

arunoda 8y ago
Whether it's serverless of not choice of hardware is very important. For an simple web app, you might not need special CPU and Memory requirements. But for a video encoding/decoding serverless app may needs different CPU/Memory requirements (and GPU). That's what this `slot` configuration property does. The default is good enough for all the general purpose apps. But if you need more, you can control it.
- danpalmer 8y ago
  I agree that one-size-fits-all doesn't work with hardware requirements, but I still think this is a leaky abstraction. The promise of Serverless is not having to care about servers, but this is an option to specifically control that. A better abstraction would auto-optimise hardware spec for the software's performance characteristics - that would be much more "serverless".

tfolbrecht 8y ago

Awesome! While I was at AWS Summit in NY, I asked a round circle of AWS ECS/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's used infrequently and too costly to decompose but works fine Dockerized. Looking forward to using your product!

deleted 8y ago
[deleted]
TheDong 8y ago
I'm amazed no one knew of one. Off the top of my head, services which let you run docker containers without dealing with any servers yourself: 1. AWS Fargate 2. Joyent Triton (which was as simple as DOCKER_HOST=<joyent-ip> docker run back in 2015) 3. hyper.sh (available since 2016 I think?) 4. OpenFaaS cloud (though you have to go through a couple more steps, you can bring a custom docker image as your 'function'). 5. A metric ton of hosted kubernetes offerings
- tfolbrecht 8y ago
  Maybe I didn't form the question correctly. Appreciate the list of services!
- tapsboy 8y ago
  Also ACI (Azure Container Instances)

fru2013 8y ago

Is there support planned for using this in combination with docker-compose? If so would be sweet to see this integrated with Prisma - https://www.prisma.io/ https://www.prisma.io/

williesleg 8y ago

It looks like they run commands on a server.

gitgud 8y ago

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

arunoda 8y ago
> 1. Once your docker container is built, am I paying to store it on Zeit? No. You don't need to pay to store containers. > 2. How is a Dockerfile versioned? Can I update it? Or do I need to redeploy Once the Dockerfile is built, you'll get a URL for that. It's a immutable URL and you don't need to re-deploy again. It'll sleep if there are no HTTP requests. If there are it'll start again. > 3. Is pricing for containers granular by time or per request to a container? It's based on the container running time. But we'll have a another blog post on this soon with more info. > 4. How can these Dockerfiles talk to each other? Is there an API or method to fetch specific url's for each container? There's no internal API to communicate with each other. But every docker container has a URL. You can use our [alias](https://zeit.co/docs/features/aliases https://zeit.co/docs/features/aliases) feature and communicate with each other via HTTP.

tapsboy 8y ago

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/egress costs? As it does sound like I am using a different cloud as far as AWS is concerned

daveheq 8y ago

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?

mildweed 8y ago
Long story short, there's a server somewhere, but most of the configuration is abstracted away. Instead of thinking of servers, they want you to think about endpoints (which they manage somewhat efficiently for you).