4 ms·
Well I don't think that using spot instances is a very good thing to consider there. 1) What if all of them go down would it make application unusable? I recal
by varelaz 7y ago
Well I don't think that using spot instances is a very good thing to consider there.
1) What if all of them go down would it make application unusable? I recall one or two weeks on AWS when all spots were down because of capacity problems.
2) You cannot rely on requests to complete on spot instances they can go up and down when they need. For background jobs it's fine, you can retry, but for UX?
And if you need to choose this approach to save your costs instead of migration to bare metal, which is usually ~10 times less than AWS then something is wrong with your architecture and you are locked.
- tuananh 7y ago> save your costs instead of migration to bare metal, like i mentioned in other comments. due to our use cases, bare metal is out of question since the clients (airlines) would very much prefer we use AWS over the smaller, lesser known offering.
- varelaz 7y agoWe had recent migration from AWS to Hetzner. We used combined clusters with ondemand + spot instances. After migration to Hetzner we doubled capacity and still saved around half. AWS is very good for flexible work loads, but if load and process is constant and well defined, bare metal hosting much more effective. And there are a lot of well known bare metal hosting providers on the market.
- tuananh 7y agoif workload is constant, nothing beats baremetal in term of cost.
- f0rmatfunction 7y agoFor 2 - horizontal scaling would address this. If there are 2+ copies of the service running behind a load balancer, either can go down/be recreated as an on demand instance if the spot capacity is revoked. AWS (and I’m guessing the other cloud platforms too) has a container service that will dynamically add containers to the load balancer for you