2 ms·

Serverless is really just a specialized niche of PaaS. Smaller lighter functionality akin more to scripts rather than full applications, with more billing and s

Serverless is really just a specialized niche of PaaS. Smaller lighter functionality akin more to scripts rather than full applications, with more billing and scaling flexibility, and typically leveraging other cloud services to get things done. Another big reason it's stalled is because PaaS has rapidly improved and now deploying a Docker container running whatever you want is just as fast and easy. No need for all the vendor lock-in, frameworks, complex environments and everything else when you can just package up a typical webapp and run it anywhere, even with the same billing (like GCP Cloud Run). In return you get a much better dev environment with all the existing tooling and best practices.

dijit 6y ago
I tend to agree. This is not helped by the fact that cloud providers are approaching (and even in some cases surpassing) the complexity and price of running standard compute instances again. It can be a lot trickier to navigate the nuances of ECS+Lambda than it is to run standard EC2 instances. Even GCP is not immune, though I find it better in these areas, a common problem I have with cloud run for instance; is container instances which don't have permissions to talk to their linked/associated database, instead you have to instantiate a credentials file programatically inside the container.. which seems superfluous when you're the platform provider and you control both resources.
- spankalee 6y ago
  Are you sure you don't have something misconfigured? By default Cloud Run services their project's GCE service account, which has permissions to everything in the project: https://cloud.google.com/run/docs/securing/service-identity https://cloud.google.com/run/docs/securing/service-identity I've never had to do anything special to access Firestore for instance.
jillesvangurp 6y ago
Exactly, your software is still running on servers but you no longer worry about managing those. The problem with PAAS and serverless until recently is that they still required a lot of devops activity. Most of that is pure drudgery: setting up networking, dealing with vendor specific weird shit (e.g. amazon's IAM makes everything harder than necessary), micromanaging instance types and trading off overpriced vcpus vs small chunks of memory, etc. Lots of things that you can do wrong, lots of subtlety, lots of poorly documented gotchas, lots of potential bugs, etc. And all of that is needed so you can say "go run this over there" where this is your packaged up docker application and there is months of work by some poor devops person to turn a large amount of poorly integrated tools into a vaguely coherent deployment experience. It's never simple. It's never cheap I had a decent experience with Cloud Run recently. I was not in a mood or position to reserve 3 months out of my schedule to terraform myself a new server environment (which I actually know how to do). I already had the software and I wanted it running ASAP. So, I felt slightly dirty when I did this but got the job done in a few mouse clicks in their UI. This was shockingly easy after basically spending months piecing together arcane crap in AWS in my previous project. This got me a cloud run deployment, a build pipeline against my github repository for continuous deployment, and a running service. I tuned the build file afterwards to do more than just docker build & deploy but that was relatively easy (similar to how most CI systems work these days). They charge for cpu/memory used by requests. The whole thing has been running for a few months now. Less than 4 hours of work to figure it all out from me knowing absolutely nothing about Cloud Run to me having a service up and running. I reconfigured the deployment via the UI a couple of times to fiddle with memory and CPU settings. I suppose I could sit down and terraform this at some point but I don't feel the need to do that right now. I have more interesting things to do. And technically me spending a day to do that would cost more than running the whole thing has cost so far. That's the point: the cost of devops is out of wack with the running cost for a lot of this stuff.

dijit 6y ago

I tend to agree. This is not helped by the fact that cloud providers are approaching (and even in some cases surpassing) the complexity and price of running standard compute instances again. It can be a lot trickier to navigate the nuances of ECS+Lambda than it is to run standard EC2 instances. Even GCP is not immune, though I find it better in these areas, a common problem I have with cloud run for instance; is container instances which don't have permissions to talk to their linked/associated database, instead you have to instantiate a credentials file programatically inside the container.. which seems superfluous when you're the platform provider and you control both resources.

spankalee 6y ago
Are you sure you don't have something misconfigured? By default Cloud Run services their project's GCE service account, which has permissions to everything in the project: https://cloud.google.com/run/docs/securing/service-identity https://cloud.google.com/run/docs/securing/service-identity I've never had to do anything special to access Firestore for instance.

jillesvangurp 6y ago

Exactly, your software is still running on servers but you no longer worry about managing those. The problem with PAAS and serverless until recently is that they still required a lot of devops activity. Most of that is pure drudgery: setting up networking, dealing with vendor specific weird shit (e.g. amazon's IAM makes everything harder than necessary), micromanaging instance types and trading off overpriced vcpus vs small chunks of memory, etc. Lots of things that you can do wrong, lots of subtlety, lots of poorly documented gotchas, lots of potential bugs, etc. And all of that is needed so you can say "go run this over there" where this is your packaged up docker application and there is months of work by some poor devops person to turn a large amount of poorly integrated tools into a vaguely coherent deployment experience. It's never simple. It's never cheap I had a decent experience with Cloud Run recently. I was not in a mood or position to reserve 3 months out of my schedule to terraform myself a new server environment (which I actually know how to do). I already had the software and I wanted it running ASAP. So, I felt slightly dirty when I did this but got the job done in a few mouse clicks in their UI. This was shockingly easy after basically spending months piecing together arcane crap in AWS in my previous project. This got me a cloud run deployment, a build pipeline against my github repository for continuous deployment, and a running service. I tuned the build file afterwards to do more than just docker build & deploy but that was relatively easy (similar to how most CI systems work these days). They charge for cpu/memory used by requests. The whole thing has been running for a few months now. Less than 4 hours of work to figure it all out from me knowing absolutely nothing about Cloud Run to me having a service up and running. I reconfigured the deployment via the UI a couple of times to fiddle with memory and CPU settings. I suppose I could sit down and terraform this at some point but I don't feel the need to do that right now. I have more interesting things to do. And technically me spending a day to do that would cost more than running the whole thing has cost so far. That's the point: the cost of devops is out of wack with the running cost for a lot of this stuff.