Posts from 21 December 2017
-
One victory and a couple setbacks.
I've been thinking about moving to AWS for some time, which caused me to change my billing on Dreamhost to month-to-month. (Given that I did this probably two years ago, I'm not sure the economics have really worked out.)
Per my previous journal entry, I am considering moving to a static frontend/app backend. It's just and proper that I establish my motivations and desired outcomes for this configuration:
- The ostensible purpose of all this is to have my computing resources meet some standard for stability, reliability, responsiveness and usefulness.
- Stability and reliability are a function of delivering on DevOps skills, i.e. setting up automation and so forth.
- Responsiveness means no free heroku dynos, and no Wordpress slowness.
- Usefulness means again, no Wordpress slowness, and providing a lot of the features I sketched out in yesterday's brainstorming. Basically, the personal goal here is to have all this heterogeneous content available and browsable in a sensible way.
Now, the professional goals here are a bit orthogonal. This configuration should act as proof-of-concept for a number of infrastructure skills that I intend to profit from through work. So the idea of hacking together something that just gets the job done satisfies personal goals but doesn't satisfy the larger professional goals.
For the time being, journaling in sublime and pushing via
scpwill have to suffice, then.Meanwhile, as much as I like the terms of DreamHost's happy hosting, there are some downsides. Although it looks like you can get away with installing a ~recent version of ruby and running whatever rails version you want, their knowledge base makes clear that they'd prefer you don't on shared hosting. I can move up to a VPS (which would allow me to gain some of the account controls I wanted—more on this later), at the cost of $15/month.
Here, I come to a fork in the road. A lot of the employers I've talked to are ~early stage enough that they get by running on heroku. While I'll admit heroku is a bit of a mystery to me (beyond their relatively painless ruby deploy process) I'm not sure that's the basket I want to put my eggs in.
Meanwhile, there are a couple other options. I could go with AWS because of its practical applications, or for instance DigitalOcean or Google Compute. I think I'll end up on AWS but it's probably worth considering all the alternatives.
If I go with AWS, the temptation is to proof-of-concept setting up overkill architecture to gain experience with as many technologies as I can. That's kind of the point, but I can foresee there being a lot of barriers to success there if I'm not careful. (Also, I don't much like Amazon, the company.)
Ultimately it doesn't much matter, except inasmuch as I don't rely on the crutches of one-click installs and GUIs to configure everything.
Finally, there's a lot of variability in terms of pricing, and I should really look into that a bit more before I commit to a particular infrastructure.
All this said, I have some concrete goals in mind. First, keep this site (ed: static site hosted with DreamHost) resolving as long as possible.
Second, set up an acceptable dev environment, and begin automating everything. Figure out setups/teardowns and immutable infrastructure, backups, etc. before committing significant data to it. This approach has the advantage of saving costs while the system isn't running fully.
Third, establish migration tools to move the data from middleman to the new platform.
Fourth, test everything and then close down shop and re-route DNS to the new server.
I alluded to a victory in the first paragraph. Well, it turns out that for a site like this one, rails offers pretty turn-key page caching that gets served directly from nginx or apache. Score.