4 ms·

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 d

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)

noir_lord 8y ago
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.
- existencebox 8y ago
  "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) has caught so much on my end.

noir_lord 8y ago

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.

existencebox 8y ago
"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) has caught so much on my end.