Note that there are some explanatory texts on larger screens.

plurals
  1. POTricks to make an AWS spot instance "persistent"?
    primarykey
    data
    text
    <p>My client uses AWS for his VPSes. One thing he is having a problem with is that if the bids for the spot instance go above his bids, then his instances are terminated. Not such a big deal, it would seem, except that spot instances aren't persistent, so we have to restore from an image every time this happens.</p> <p>What he is wanting me to do is write something that will check for terminated instances every X amount of time, and restart them automatically. More importantly, he wants some sort of way to feign "persistence". The best idea I have is to simply create an image from each server every Y amount of time and then boot from that image (if/when that instance is terminated).</p> <p>Any other ideas would be nice to hear. I guess my question is, am I on the right track here, and do you guys know of any solutions for this that may already exist?</p> <p><strong>UPDATE:</strong> Almost a year later, I come back here to find all these wonderful responses and much more attention to the topic than I'd ever anticipated. A lot of the below answers, while informative and helpful, question my reasoning. I want to state that, even at that time, I agreed 100% that this was not a wise idea, but was what my client demanded, despite any attempt on my part, to turn things in a better direction.</p> <p>Thank you all very much for your help. I did end up figuring out how to do exactly what I wanted, and was able to write some code that automatically relaunches terminated instances. It was never easy, but it worked well by the time I moved on to a new client.</p> <p>Good luck to any of you with the same problem, you're undertaking (possibly by force, as was my case) something that won't be easy. Spot requests are cheaper, as some folks here alluded in their responses, specifically <em>because</em> persistence is not offered. Otherwise, I imagine the "spot request" market would be priced much differently.</p> <p>All the same, it <em>is</em> possible, I did it, and it was a great experience. When there isn't a way, you have to forge it! If you don't, someone else will.</p> <p><strong>UPDATE II:</strong> I just want to remind everybody that this is something I was essentially tasked with. While many people just dismissed the entire concept at the time, I ended up with an more-or-less functional SaaS allowing one to easily manage and monitor all of ones' spot instances, including the ability to enable/disable auto-persistent relaunch per instance, schedule times for individual instances (that they should or should not ever be started,) etc.</p> <p>While I absolutely agree that, from a developer's point of view, it is an inelegant demand, and at the time, I did <em>not</em> want to do it, I'd still say that it was kind of nice in a way, being demanded to work on it, because not only did I learn a <em>lot</em>, not only did I gain a lot of confidence in my ability and my code, but I produced a really useful and, as far as I know, very valuable piece of software for my client (even if they were asking for the wrong things because they didn't know better).</p> <p>I tried to talk him out of it, but he insisted, and since he was the one paying, I focused my attention there and not only accomplished what many here dismissed as silly but made it <em>profitable</em> for someone.</p> <p>If it were <em>that</em> silly, it wouldn't have saved anyone money.</p> <p>Look, I read this post now and cringe a little. I was a lot more naive, then. I know AWS a <em>lot</em> better, now, I code a <em>lot</em> better now, etc. Naturally.</p> <p>But I am still proud of solving this one, especially since it was these fellow, older, and much more experienced, undoubtedly <em>great</em> programmers who were the ones telling me it couldn't or shouldn't be done. You were the ones who made it a challenge to me, so thank you!</p> <p>What if it can be done profitably? Are you sure that it shouldn't?</p>
    singulars
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload