Hacker News Reader

Comment by geggam | Hacker News Reader

Infrastructure as code.

Terraform using AMIs plus chef recipes that work in the cloud and bare metal. Dont use AWS specific services.

This would allow you to spin over to another cloud provider , vsphere or bare metal with minimal work

Totally impractical for any small business and of questionable usefulness for large ones. You'd be giving up the largest benefit of platforms like AWS--ready to use services for common tasks--to avoid the infinitesimally small chance of AWS having some doomsday global outage.

To answer the original question: It looks like this issue was just a UI bug that affected the console, the service itself wasn't impacted. Events that do impact the service will be contained to a region, meaning you can mitigate it with proper redundancy across regions, no zany multi-cloud solution required.

Evidently you dont know how to do this well

That’s not how Terraform works. Each provisioner has separate syntax depending on the cloud provider. The template for AWS wouldn’t work on GCP or Azure.

Correct. However written properly you get 90% of the way there.

Disaster recovery by switching to another provider is simple when minimal centos/rhel images are used.

Then struggle like hell for the other 90%

Assume I’m not fully informed here. What does “written properly” mean? Sure I can move over route53 to cloud DNS easily but Firehose to PubSub? Lambda to Cloud Functions? DynamoDB to BigTable and moving the data?

The syntax for provisioning these doesn’t work that well for some find and replace to work. Are you using a templater to generate cloud-specific HCL from a template or something? Sounds like a pretty big problem to solve to me and not just something where you can win via discipline.

Quit using vendor lock in resources then asking why its hard to leave that vendor.

You’re always “locked in” to your infrastructure. People have this brilliant strategy of thinking they have this brilliant strategy of avoiding “lock in” and again they get the worse of both worlds. They end up spending more to avoid lock-in and they aren’t taking advantage of what thier provider has to offer.

At the end of the day, changing your underlying infrastructure is so risky and usually not worth the cost benefit analysis, it’s rarely done.

Oh, I see. You intend to use purely EC2 or GCE instances and just run everything one would run in a colo on them. All right.

That's a pretty manpower intensive way of operating. I think the fact that you get cloud agnostic this way is probably not worth it.

The requirement was to be cloud agnostic. This is one of the few ways possible.

In that case, why be in the cloud at all? I still think it would be cheaper to have a colo in two geographically dispersed areas on bare metal.

If all you are doing with your cloud provider are a bunch of VMs, you’re wasting money. There are much cheaper and simpler ways just to host a bunch of VMs than to use one of the major cloud providers.

Are you not using any of thier managed services and are you maintaining your own on VMs? If so, you have the worse of both worlds. You’re spending more on hosting and you’re not saving money on letting someone else do the “undifferentiated heavy lifting”.

Going to the cloud thinking you are going to save money is silly. It is more expensive to run things in the cloud, what you are paying for is the ability to scale up and down without a logistics problem.

It’s only silly if you’re not changing your processes. If you’re keeping the same people doing everything manually instead of automating, or honestly if you’re keeping the same headcount and if you’re not developing and depending on services provided by your provider and instead you’re self hosting services on VMs, of course you’re going to spend more.

But I blame most of the cost overruns when using cloud providers on “consultants” who think they are “moving to the cloud” when all they really know is how to setup a little networking infrastructure and know nothing about how to use the developer, Devops, or other hosted solutions.

Most ”consultants” I’ve run across only know how to do a lift and shift and do a one to one mapping of the on prem VMs and networking infrastructure to the cloud. They know nothing about automation, transforming Devops practices, or transforming development practices and architecture.

A lift and shift should only be the first phase.

If your company culture isnt devops no consultant will fix that.

Thinking that is the reason for consultants is a problem

Note : I worked directly for companies as an employee when building these stacks

I think you are downplaying minimal

I don't think OP was intending "minimal" to mean it would be easy to get to the stage where it's possible, just that once you've got all your infrastructure-as-code stuff set up correctly, you ought to be able to just be pressing buttons / running scripts and have your infrastructure up and running in another cloud provider.

Even when working in small companies with small infrastructure, I've kept recreation of infrastructure as one of my high priorities (one reason it really bugged me in one job to have to depend on Oracle Databases that I couldn't automate to the same degree.)

In my mind, it's not different from the importance of having, and testing restoration of, backups. If your infrastructure gets compromised somehow, or you find yourself up the creek with your provider, you've got to be able to rebuild everything from scratch.

The infrastructure has always been the easy part, as long as the company is willing to pay for multiple datacenters.

Then you realize a lot of software and databases can only run from a single instance, zero support for multi regions, and you're not gonna to rewrite everything and resiliency just can't happen.

No, with over 20 years experience and having done exactly this for several different companies and startups I pretty much have this process down.

And this is the reason that people end up spending so much more in the cloud - treating AWS like a glorified colo.

Reply on news.ycombinator.com