|
|
|
|
|
|
by purvis
3250 days ago
|
|
|
> Terraform is basically this tool, but I want an even easier interface, terraform still feels somewhat too specific to me -- I don't want to even have to write config or specify some "aws" adapter that will make my config work on some provider. I want instant, multi-cloud (possibly) heroku, using only the network, hard-drive-space, ram, and lxc "primitives". This sounds very similar to some ideas I've been stewing on over the past few months. One of them being a multi-cloud terraform-like tool which abstracts away the low level details of which provider an instance is provisioned onto (whichever is currently cheapest). It could also automatically determine how firewall/security groups/networking should be configured. If you happen to create two instances in two different providers that need to communicate privately over say port 443, the security groups would be updated automatically to account for this, bridging the two providers. One major thing to consider in doing this is the bandwidth. If you look at the fine print in these providers, the outgoing bandwidth is where they really get you. So if your backup server is in a different provider than your database, you might see some hefty data transfer fees while performing a daily backup. Just curious, what's your background? Are you an infrastructure type, or are you a general developer who just wants a tool like you've described? Sometimes I can't tell if this is something people really want or if I've just drank too much of the infrastructure automation koolaid. |
|
|
Sorry for the delay -- I've definitely had this at the back of my mind too, but with every advance made by cloud providers, I wonder if I could ever possibly get into that fight, especially since I'm not an expert at any of the cloud computing platforms -- Hashicorp seems to be doing amazing work in this area also, field seems to be full.
My background is basically that I really enjoy computers/programming and like to be self sufficient so I prefer a shallow (working) knowledge of all parts of the stack. I maintain a few VPSes and use them to host n-tier (where n is usually 2) projects. I'm always interested in the best way to do stuff and I use new projects to try stuff out.
Ops is particularly interesting to me because I've gone through a lot of iterations of how I did ops for my apps -- from SSH-in-and-do-stuff -> use-fabric-to-ssh-in-and-do-stuff -> dockerize & ship containers -> dockerized + systemd -> dockerize & registry (thanks to gitlab) + systemd + ansible. I've also used dokku and of course it blew my mind (I never used/wanted to pay for heroku), so while I stayed relatively low level, I was cognizant of what was happening a few levels up.
I saw kubernetes a few years ago and wasn't sure whether I wanted to go with it, but I've taken a fresh look over the last week and think it might be time to give it a try.
Side (controversial?) note - I think the time where it's acceptable for junior/mid-level developers to only know one part of the stack is dead. The only thing keeping these roles possible are the fungibility requirements for large corporations. Smaller, hungrier (almost literally) corporations can't afford to have some developer that is only an expert at writing python but never works on frontend code or deals with the database.