I recently created a private cloud infrastructure on Digital Ocean. It would have been easier and faster (and more polished) if I'd gone with AWS, but then I would know how to use AWS, and would not know how to do these things myself.
Why learn about HAProxy, keepalived, tinc, etc when you've got AWS to handle it all for you?
Answer: Because relying on a service to abstract the inner workings for you is a path to the dark side.
I'm stealing this. I love it!
Given a non leaky abstraction, ignorance of whats under the hood is just fine.
It is unthinkable right now, but what will happen with Amazon/AWS goes bankrupt and no longer exists? All these AWS Certified Engineers who are not actually devops will suddenly be lost.
On the flipside, if you learn everything from the ground up and then jump on AWS or whatever service is available, you will be in a much better position when the day comes to move away and to something else.
Abstractions in something like programming languages is fine because the language won't simply disappear one day - you'll evolve as a programmer and will be stronger for it.
But I really believe someone will figure this problem out, and at that point Dev Ops will be done. There is just to much money to be made.
Or they could just read this document and move to GCP.
https://cloud.google.com/docs/google-cloud-platform-for-aws-...
Know the fundamentals, and you'll be fine. Everything else is rhinestone marketing.
Minus vendor lock-in. Once you have your infrastructure dependent on ELB, S3, Redshift and all the other AWS niceties, you are effectively locked into Amazon. Locked, in the sense that migrating out has a relevant knowledge cost (deprecation of knowledge of AWS, need for gain in alternative knowledge).
It's not a dumb choice, but it's also not clear for either side. Running your own iron is much much cheaper. For my case (email service provider), our bill estimate on AWS would be about 300k€/year, while running our own servers costs 84k€/year (split at 48k€ depreciation and 36k€ operational costs).
Something to note about US orgs: New depreciation rules allow you to depreciate $500K/year in hardware, in that year. That means that gear is yours, forever, whereas that $500K/year in opex to AWS is recurring forever.
I also like to think of using a cloud service as "hiring" the entire staff working on that product + benefiting from all of the accumulated knowledge that's been baked in. That makes a cloud service a huge bargain to me.
The solution that worked well for me was using tinc to set up a VPN so all my servers, no matter what datacenter they're sitting in, can communicate with each other using private IP addresses (tinc has added benefit of encrypting, which DO's private network does not).
If you're needing help, I'm currently looking for more contract work :) Check my profile for contact information.
This is a case of the wrong tool/service for the job. You need advanced networking and spent all this time duct taping it together on DO when you could have a real VPC on aws with security groups, subnetting etc. Not to mention locked in to DO's limited instance types.
Don't get me wrong, DO fills a niche for quick one-off type applications but it is absolutely no substitute for a real IAAS like aws, gcp, azure... Investing time in trying to turn it in to one is a waste and way worse than perceived "lock-in".
You also could have just as easily rolled your own setup the same way on AWS, so i'm not sure what argument is other than cost. (btw t2.nano instances are $4.75 a month) http://www.ec2instances.info/?cost=monthly