[hardwaresofton]

What's really got me excited lately is the combination of Ansible (for dirty work) and container orchestration systems like Kubernetes/Rancher/etc (also, tools that go from one orchestrated host to many like dokku and flynn).

While I appreciate the competition from GCE and Azure, what I really want is a tool that will run in any one of their clouds, but offers the same ease-of-management, and lets me go from one cloud to another or to a private cloud without breaking a sweat. I want the competition to be 70% on price and 20% on added-management-value and 10% on bundled services.

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".

Someone (maybe me if I ever find time) just needs to get to work making F/OSS versions of all the bundled tech (ex. blob storage, cloud function runners, dynamically configurable DNS resolvers, simple alerting, etc) that runs in a container, and then the question just becomes "where can I get the cheapest most performant VPS that will host my containers".

[purvis]

> 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.

[hardwaresofton]

tl;dr - "Fullstack" developer who does my own ops for my own projects which are very varied (I've done small-time deploys/management for projects in/with python, node, go, haskell, ruby, postgres, rethinkdb). I try to iterate my infra as well as my technology stacks to find the best way to do things.

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.

[purvis]

Your story sounds so familiar, someone could read what you wrote above and think it's me.. though I like to think of myself as a generalist rather than "fullstack". I tend to believe "fullstack" is a marketing term for acquiring slave labor. You're right though, it's required at this point for smaller startups.

> I wonder if I could ever possibly get into that fight

I wonder this too. I've been using AWS for 4+ years at my day job(s). The main pain point for almost all users, including myself is the cost. I think a product/tool that helps companies save on cloud costs would be invaluable. The difficulty is convincing crusty old ops people that the product is something worth trying.

Anyway, after my current employer runs out of money, I'm going to do a startup of some sort. While one of my many idea was like the one we outlined above, I'm actually starting to shy away from the infra/op verticals lately.

My email's in my profile, if you ever want to bounce ideas.

[hardwaresofton]

Agree -- "Generalist" is the word I'm going to use now instead of fullstack -- that's the way better term, I put "fullstack" in terms because I dislike the term.

Email incoming!

[philips]

This is part of the vision that we have with CoreOS Tectonic. Checkout the Tectonic Installer which helps to install to various cloud platforms[1] using Terraform and then Tectonic[2] helps to automate operational toil like upgrades, etc.

[1] https://github.com/coreos/tectonic-installer [2] https://coreos.com/tectonic

[hardwaresofton]

Just a heads up -- some parts of the coreos site really make it seem like tectonic is only for enterprise -- it actually turned me off it while I was reading the documentation at https://coreos.com/kubernetes/docs/latest/

Right now my plan is to start with bare kubernetes just to cement understanding and then add rancher, before looking at any other higher level system (I mean there's stuff like helm out there, but it just seems to be too many levels above the ground for me at this point). I'm also using ansible right now (and relatively new to that too, but it's basically just fabric on steroids so I'm not too stressed about it), so I haven't started using terraform yet (but want to).

[lvangool]

Hey @hardwaresofton check out Cloud 66 https://www.cloud66.com/containers - Caveat... I work there :)

[hardwaresofton]

Hey thanks for the link! However I don't think Cloud66 is for me -- out of my price range for the small projects I build.

With respect, from what I can tell, most of the features of cloud66 are already included in Gitlab, and when I convert my current infrastructure to Kubernetes I can even start taking advantage of the auto-deploy-to-kubernetes features.

$49 / Month is a bit too much for me, but I don't think I'm the target anyway!

I'm also the kind that likes to run my own infrastructure and spend time on things I maybe shouldn't be spending time on :)

[sytse]

Yep, this is exactly the vision we have for GitLab, for more information see https://about.gitlab.com/2017/06/29/whats-next-for-gitlab-ci...

[thockingoog]

I hear what you're saying, but don't under-estimate the value of "someone else runs it and gives me an SLA", which is a large part of what public clouds are really selling. :)

[hardwaresofton]

Yup, I definitely hear that! 20% is naive in the value breakdown I gave, the peace of mind is probably worth so much more.

[convolvatron]

the clear end goal here is that you have to deal with things like 'provisioning virtual disks' and 'doing ubuntu updates'. this whole virtualization thing received you of the burden of buying pci ethernet nics and rack mount brackets and provisioning cooling.

but really this whole business of writing chef recipes and provisioning harnesses is really the same kind stuff. it seems important because you can't run without it, and thats what your whole day is...but really its pretty secondary to what you're actually trying to accomplish (run a service)

its interesting to think about what that world might look like...someone is going to make something like that stick at some point. so...why are people provisioning their own containers/vms instead of using the higher level services right now?

[hardwaresofton]

For me at the very least it's cost -- I can purchase a cheap VPS and run a bunch of stuff on it, with full control for much cheaper than what an AWS EC2 instance costs monthly (with better specs).

Compare this: http://www.ec2instances.info/?cost_duration=monthly

To VPS hosting from providers like: https://www.packet.net/bare-metal/ https://cc.delimiter.com/cart/dedicatedcore-vps/

The value provided by the services being managed is large, but honestly, for a lot of well-built infrastructure pieces, there is a lot of trust already for the services to not go down. Most startups/lifestyle companies/small businesses/whatever couldn't bring down a Postgres instance on a reasonably-provisioned machine if they tried (and the app is written with at least a smidgen of thought towards performance)

[cjsuk]

This. Also the cost advantage of your typical t2.micro instance disappears when you run out of CPU credits instantly running updates in...

[justincormack]

One of the aims of LinuxKit https://github.com/linuxkit/linuxkit is to show that you absolutely can do without the "doing ubuntu updates" and "writing chef recipes" stuff - you just write a single config file that specifies the whole OS config and the applications you want to run, test on your laptop, build in Ci and then deploy to cloud or bare metal, with just your service (or Docker/K8S for dynamic services).