2 ms·

lift & shift = move your instances, which are expensive and not at all competitive cloud native = use more serverless products (pay as you go with no base pric

lift & shift = move your instances, which are expensive and not at all competitive cloud native = use more serverless products (pay as you go with no base price) For instance, one could implement internal DNS using instance which run bind, and connect everything through some VPC, and put a load balancer in front of the instances. One could also rework its DNS architecture and use route53, with private hosted zones associated with all the appropriate VPCs Another real example: one could have hundreds of instance running gitlab runners, running all day, waiting for some job to do. One could put those gitlab runners into an autoscaled kubernetes, where nodes are added when there are lots of jobs, and deleted afterwards. One could even run the gitlab runners on Fargate, where a pod is created for each job, to run that job and then exit. No job = no pod = no money spent. Of course, some work is required to extract the best value of cloud providers. If you use only instances, well, surprise: it costs a lot, and you still have to manage lots of stuff.

maccard 2y ago
I ran our CI on fargate at my last job. It was a mess. The time from api request for an instance to it being ready to handle a job was minutes. It was about 50x slower than running on a mid range laptop that I occasionally used for development, and in order to work around that we kept hot EBS volumes of caches around (which cost $$$$ and a decent amount of developer time). Just before I left I was investigating using hetzner instead - our compute bill would have been about 15% cheaper, we would have had no cache storage costs (which was about 5x our compute costs), and the builds would have finished before fargate had processed the request. Our numbers were small fry, but we spent more on that CI system than we did on every other part of our infra combined.
kjellsbells 2y ago
Of course, while this move to cloud native, along the path from IaaS to PaaS to SaaS, saves money on one dimension, it also binds the customer more and more immovably to the cloud vendor...

maccard 2y ago

I ran our CI on fargate at my last job. It was a mess. The time from api request for an instance to it being ready to handle a job was minutes. It was about 50x slower than running on a mid range laptop that I occasionally used for development, and in order to work around that we kept hot EBS volumes of caches around (which cost $$$$ and a decent amount of developer time). Just before I left I was investigating using hetzner instead - our compute bill would have been about 15% cheaper, we would have had no cache storage costs (which was about 5x our compute costs), and the builds would have finished before fargate had processed the request. Our numbers were small fry, but we spent more on that CI system than we did on every other part of our infra combined.

kjellsbells 2y ago

Of course, while this move to cloud native, along the path from IaaS to PaaS to SaaS, saves money on one dimension, it also binds the customer more and more immovably to the cloud vendor...