6 ms·

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 w

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?
    - codefined 8y ago
      You would probably use something like a queue[0] that takes in data from the websocket and dishes it out to lambda functions. You might also use something like Kinesis[1] or other alternatives. [0] https://aws.amazon.com/sqs/ https://aws.amazon.com/sqs/ [1] https://aws.amazon.com/kinesis/ https://aws.amazon.com/kinesis/
      - stingraycharles 8y ago
        Yes of course, or I could send it into Kafka instead (which makes more sense to me). The point is, how would a serverless process looks like which doesn’t have a REST API and does this long term polling of websockets?
        tlrobinson 8y ago
        Some platforms like Amazon Lambda let you set up functions to consume data from a variety of event sources: https://docs.aws.amazon.com/lambda/latest/dg/invoking-lambda-function.html https://docs.aws.amazon.com/lambda/latest/dg/invoking-lambda...
        stingraycharles 8y ago
        How can I consume the Twitter stream API using that?
        k__ 8y ago
        I don't know this specific API. Either it works with web-hooks that you could lead to a Lambda via API-Gateway. Or it needs to pull the data, then you could trigger Lambda via CloudWatch intervals.
        tlrobinson 8y ago
        Unless the API can stream directly into one of those sources you'd probably need a long-running process, perhaps running on a CaaS like AWS Fargate. I guess you could argue where to draw the "serverless" line, at functions or containers, but Zeit is calling this container service "serverless" so I think Fargate would fall into the same category. I think it would make sense for Zeit to eventually support long-running containers too (looks like the current max is 30 minutes, I'm not sure how they chose that number)
- rhacker 8y ago
  I think all that is still possible in Serverless. I'm not a serverless architect or anything, but that's typically handled by various serverless queues and related event systems.
  - deskamess 8y ago
    Don't most serverless calls have a time limit?
    - bdcravens 8y ago
      Yes, but you typically build your functions to split up the work if necessary. (Create additional queued events)
  - windows_tips 8y ago
    Sounds expensive.
- saidajigumi 8y ago
  At my last gig, we were using Firebase, Google's acquired-and-increasingly-integrated serverless solution. It was straightforward to have custom GCP instances that integrated with and extended our regular serverless workflows. In that scenario, it meant the compute instances tended to be extremely simple, as they were essentially just glorified event handlers. Interestingly, as Firebase evolved during our use, nearly all of our external-instance use cases were obsoleted by more powerful native serverless support, esp. around functions. All of which is the best of both worlds for serverless: an easy escape hatch to custom instances, and an ever-decreasing need for that escape hatch.
- bdcravens 8y ago
  Functions that respond to events, where an event is triggered by some sort of message queue (ie, Lambda + Kinesis streams)
  - the_duke 8y ago
    Which usually have very low time restrictions in the order of a few minutes.
    - bdcravens 8y ago
      Break your operation into a series of discreet tasks. For 99% of use cases, if you have an discreet task that takes 5+ minutes, there's a problem. In most cases, it can be split up.
      - lmm 8y ago
        "Discrete" rather than "discreet", but yes.
nickjj 8y ago
I know of 1 large scale web application that is 100% driven by serverless technologies. The user experience (as an end user using the website) is pretty terrible IMO. It often takes multiple seconds for various areas of the site to load (bound by the network). It's also super Javascript heavy and just doesn't feel good even on a fast desktop workstation. Authentication is also a nightmare from a UX point of view. Every time I access the site it makes me click through an intermediate auth0 login screen. I really hope this doesn't become a common trend to run web apps like this. It would make the web nearly unusable. I'm not a "serverless" hater either. I want technology to move forward to make my life as a developer better. I don't care what tech it is, but right now I just don't get that impression from serverless set ups (both from the developer and end user POV).
- myrloc 8y ago
  Are you by chance referring to A Cloud Guru? I have the same auth0 and loading experience when using their site, and I suspect it's built on Lambda, but I'm not sure.
  - atmosx 8y ago
    It is indeed. They can't stop talking about it in their videos. That said, I used their resources, along with some other online resources to get my AWS Associate SA Certificate and I can say I was pretty pleased with the content.
- staticassertion 8y ago
  Confused by why those issues are tied to serverless. The only one that seems like it could even be related is the page loads being slower. But I'd be surprised if the issue were the serverless aspect of the architecture and not just that this software is apparently shoddy overall.
- jkarneges 8y ago
  Serverless doesn’t have to be slow/heavy. Here’s a chat demo I made recently using Fly: http://flychat.fanoutapp.com http://flychat.fanoutapp.com Renders server-side, loads quick, minimal JS.
celim307 8y ago
What's a FANG developer?
- dfischer 8y ago
  Facebook, Apple, Netflix, Google
  - jpetso 8y ago
    I still find Netflix a curious addition to that list.
    - carimura 8y ago
      for the acronym.
      - nkg 8y ago
        yes Netflix is definitely necessary ;)
  - crabmusket 8y ago
    No Amazon?
    - tedmiston 8y ago
      I like patio11's acronym (?) of choice better: AppAmaGooBookSoft.
      - regularfry 8y ago
        Portmanteau.
      - gregknicholson 8y ago
        AKA “GAFAM”.
    - 8y ago
justicezyx 8y ago
Where the fang devs mock come from? They are on the forefront of serverless.
- sadamznintern 8y ago
  Specifically AWS Lambda is. In terms of performance and flexibility AWS and GCP are far far behind.
- ex_amazon_sde 8y ago
  Amazon does not use docker, ansible, salt and other hipster stuff internally because they are a nightmare to maintain at that scale. Everything is deployed as immutable infrastructure.
rdslw 8y ago
Count me in as a over-engineering and selling-things-engineers-do-not-need hater. The very list of benefits on ZEIT, mentions 4 things: first two of them are clear over-engineering bloat (plus premature optimization), and second two were actually created only because of serverless. They were (and nothing more was mentioned in section benefits ;) : * Clusters or federations of clusters * Build nodes or build farms * Container registries and authentication * Container image storage, garbage collection and distributed caching I don't know why everybody can't see fakeness of argument'you need clusters, farms and hundreds of servers'. You don't. Actually you do only (contrary to your statement), if you're FANG. Why? Because look at real world HUGE examples. E.G. stackoverflow (and no, your company/startup/whatever, will not reach their level of traffic) can do everything on literally dozen of servers, while they admitted that in some scenarios 1 web server was enough. Source: https://nickcraver.com/blog/2016/02/17/stack-overflow-the-architecture-2016-edition/ https://nickcraver.com/blog/2016/02/17/stack-overflow-the-ar... Our 10x..100x smaller companies would perfectly do on 2..4. There is no need for whole over-engineering. The ultra funny thing is ZEIT selling 'deployment self-heal' as old known (windows anybody) and ridiculed recipe: it will work after restart. Right. It's better to shut off car engine, go out, go in, and start again. This is XXI engineering :)

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?
  - codefined 8y ago
    You would probably use something like a queue[0] that takes in data from the websocket and dishes it out to lambda functions. You might also use something like Kinesis[1] or other alternatives. [0] https://aws.amazon.com/sqs/ https://aws.amazon.com/sqs/ [1] https://aws.amazon.com/kinesis/ https://aws.amazon.com/kinesis/
    - stingraycharles 8y ago
      Yes of course, or I could send it into Kafka instead (which makes more sense to me). The point is, how would a serverless process looks like which doesn’t have a REST API and does this long term polling of websockets?
      - tlrobinson 8y ago
        Some platforms like Amazon Lambda let you set up functions to consume data from a variety of event sources: https://docs.aws.amazon.com/lambda/latest/dg/invoking-lambda-function.html https://docs.aws.amazon.com/lambda/latest/dg/invoking-lambda...
        stingraycharles 8y ago
        How can I consume the Twitter stream API using that?
        k__ 8y ago
        I don't know this specific API. Either it works with web-hooks that you could lead to a Lambda via API-Gateway. Or it needs to pull the data, then you could trigger Lambda via CloudWatch intervals.
        tlrobinson 8y ago
        Unless the API can stream directly into one of those sources you'd probably need a long-running process, perhaps running on a CaaS like AWS Fargate. I guess you could argue where to draw the "serverless" line, at functions or containers, but Zeit is calling this container service "serverless" so I think Fargate would fall into the same category. I think it would make sense for Zeit to eventually support long-running containers too (looks like the current max is 30 minutes, I'm not sure how they chose that number)
rhacker 8y ago
I think all that is still possible in Serverless. I'm not a serverless architect or anything, but that's typically handled by various serverless queues and related event systems.
- deskamess 8y ago
  Don't most serverless calls have a time limit?
  - bdcravens 8y ago
    Yes, but you typically build your functions to split up the work if necessary. (Create additional queued events)
- windows_tips 8y ago
  Sounds expensive.
saidajigumi 8y ago
At my last gig, we were using Firebase, Google's acquired-and-increasingly-integrated serverless solution. It was straightforward to have custom GCP instances that integrated with and extended our regular serverless workflows. In that scenario, it meant the compute instances tended to be extremely simple, as they were essentially just glorified event handlers. Interestingly, as Firebase evolved during our use, nearly all of our external-instance use cases were obsoleted by more powerful native serverless support, esp. around functions. All of which is the best of both worlds for serverless: an easy escape hatch to custom instances, and an ever-decreasing need for that escape hatch.
bdcravens 8y ago
Functions that respond to events, where an event is triggered by some sort of message queue (ie, Lambda + Kinesis streams)
- the_duke 8y ago
  Which usually have very low time restrictions in the order of a few minutes.
  - bdcravens 8y ago
    Break your operation into a series of discreet tasks. For 99% of use cases, if you have an discreet task that takes 5+ minutes, there's a problem. In most cases, it can be split up.
    - lmm 8y ago
      "Discrete" rather than "discreet", but yes.

nickjj 8y ago

I know of 1 large scale web application that is 100% driven by serverless technologies. The user experience (as an end user using the website) is pretty terrible IMO. It often takes multiple seconds for various areas of the site to load (bound by the network). It's also super Javascript heavy and just doesn't feel good even on a fast desktop workstation. Authentication is also a nightmare from a UX point of view. Every time I access the site it makes me click through an intermediate auth0 login screen. I really hope this doesn't become a common trend to run web apps like this. It would make the web nearly unusable. I'm not a "serverless" hater either. I want technology to move forward to make my life as a developer better. I don't care what tech it is, but right now I just don't get that impression from serverless set ups (both from the developer and end user POV).

myrloc 8y ago
Are you by chance referring to A Cloud Guru? I have the same auth0 and loading experience when using their site, and I suspect it's built on Lambda, but I'm not sure.
- atmosx 8y ago
  It is indeed. They can't stop talking about it in their videos. That said, I used their resources, along with some other online resources to get my AWS Associate SA Certificate and I can say I was pretty pleased with the content.
staticassertion 8y ago
Confused by why those issues are tied to serverless. The only one that seems like it could even be related is the page loads being slower. But I'd be surprised if the issue were the serverless aspect of the architecture and not just that this software is apparently shoddy overall.
jkarneges 8y ago
Serverless doesn’t have to be slow/heavy. Here’s a chat demo I made recently using Fly: http://flychat.fanoutapp.com http://flychat.fanoutapp.com Renders server-side, loads quick, minimal JS.

celim307 8y ago

What's a FANG developer?

dfischer 8y ago
Facebook, Apple, Netflix, Google
- jpetso 8y ago
  I still find Netflix a curious addition to that list.
  - carimura 8y ago
    for the acronym.
    - nkg 8y ago
      yes Netflix is definitely necessary ;)
- crabmusket 8y ago
  No Amazon?
  - tedmiston 8y ago
    I like patio11's acronym (?) of choice better: AppAmaGooBookSoft.
    - regularfry 8y ago
      Portmanteau.
    - gregknicholson 8y ago
      AKA “GAFAM”.
  - 8y ago

justicezyx 8y ago

Where the fang devs mock come from? They are on the forefront of serverless.

sadamznintern 8y ago
Specifically AWS Lambda is. In terms of performance and flexibility AWS and GCP are far far behind.
ex_amazon_sde 8y ago
Amazon does not use docker, ansible, salt and other hipster stuff internally because they are a nightmare to maintain at that scale. Everything is deployed as immutable infrastructure.

rdslw 8y ago

Count me in as a over-engineering and selling-things-engineers-do-not-need hater. The very list of benefits on ZEIT, mentions 4 things: first two of them are clear over-engineering bloat (plus premature optimization), and second two were actually created only because of serverless. They were (and nothing more was mentioned in section benefits ;) : * Clusters or federations of clusters * Build nodes or build farms * Container registries and authentication * Container image storage, garbage collection and distributed caching I don't know why everybody can't see fakeness of argument'you need clusters, farms and hundreds of servers'. You don't. Actually you do only (contrary to your statement), if you're FANG. Why? Because look at real world HUGE examples. E.G. stackoverflow (and no, your company/startup/whatever, will not reach their level of traffic) can do everything on literally dozen of servers, while they admitted that in some scenarios 1 web server was enough. Source: https://nickcraver.com/blog/2016/02/17/stack-overflow-the-architecture-2016-edition/ https://nickcraver.com/blog/2016/02/17/stack-overflow-the-ar... Our 10x..100x smaller companies would perfectly do on 2..4. There is no need for whole over-engineering. The ultra funny thing is ZEIT selling 'deployment self-heal' as old known (windows anybody) and ridiculed recipe: it will work after restart. Right. It's better to shut off car engine, go out, go in, and start again. This is XXI engineering :)