Hacker News new | past | comments | ask | show | jobs | submit login

Until there is a genuinely portable way to move from one to another I'll stick either bare metal or running my own KVM instances on bare metal.

From a business risk point of view I don't trust the cloud at all and don't feel comfortable suggesting it to my boss.

Long term kubernetes or its three successors might fit the bill but for now running my own stuff has worked out fine.




I've taken the middle path: Typically I find I can build my apps using standard OSS tooling and just keep it CI'd into a self-contained container or packaged deployment. If I need to roll it out to GCE? Sure. AWS? Sure. Azure? Sure. All 3 at once? no problem.

The need to shim common things like "make image, deploy VM, set up VNET" is a pain and does marginally limit portability, but perhaps by nature of my only needing a small set of their IaaS style offerings (compute, networking, MAYBE blob storage/cache if I'm feeling fancy) I've found it rather straightforward to maintain portability through very minimal abstraction.

(Disclaimer since I'm talking about cloud stuff, MSFtie, opinions are my own etc)


Pretty much the same for us, the heavy lifting is done on in house servers but some of our external services are running on linode.

In either case everything is done via ansible/repeatable deploys (and some python and bash scripts).

Even our development instances are done using basically the same ansible setup as production (it catches more than I'd expect in terms of "that would have hurt in production").

For now it's a practical solution that leverages the skills I have and our projected scalability needs from year to year are low enough that I don't worry about it.


"Even our development instances are done using basically the same ansible setup as production (it catches more than I'd expect in terms of "that would have hurt in production")."

At the risk of a glib comment, the essence of your statement would be VERY high up on my "biggest lessons I've learned over the last decade" list, if such a thing existed.

The benefits of having your develop look as close as naturally possible to your production (and then abusing it in every way imaginable as one tends to during dev) are innumerable, and the strategy has caught so much on my end.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: