3 ms·
in production is fast startup really such a boon outside of serverless? especially if you're already doing blue/green deployments, doesn't seem like it'll have
by guitarbill 7y ago
in production is fast startup really such a boon outside of serverless? especially if you're already doing blue/green deployments, doesn't seem like it'll have much impact.
(depends what "fast" vs "slow" means - are we talking about milliseconds vs a second or two, or startup times so horrendous they cripple your devs' ability to iterate and tests?)
- dangoor 7y agoWe essentially run in a serverless environment (App Engine), so fast startup does matter to avoid some unlucky users hitting the cold start.
- guitarbill 7y agofair enough. you say in the blog App Engine has worked well for you and you're sticking with it, so i'm assuming you considered moving to traditional servers but found it unappealing?
- dangoor 7y agoYes. Google Cloud now has multiple options for autoscaling servers (App Engine Standard, App Engine Flex, and Cloud Run) with the biggest differences being how they're deployed and specifics around the scaling. We _could_ manage our own Kubernetes clusters and such, but Cloud Run is pretty similar to that and takes away all of the management headache. There is essentially zero code difference, should we decide to change our deployment strategy later. We're using Google Cloud Datastore for persistence, and that automatically scales in both servers and storage, so it has worked out nicely for us as well.
- tybit 7y agoLocal iteration is most important to me, but serverless is a great example too, as are CLIs (slow CLIs have recently become my pet peeve). The nice thing about Go is it performs well in each of these use cases by ensuring nothing in its tool chain is slow, or produces slow code. Slow is in the eye of the beholder I suppose, but I guess I’m using it here to mean within an order of magnitude of its peers.