3 ms·

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 ar

by geggam 8y ago

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.

edoceo 8y ago
Then struggle like hell for the other 90%
scarejunba 8y ago
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.
- geggam 8y ago
  Quit using vendor lock in resources then asking why its hard to leave that vendor.
  - scarface74 8y ago
    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.
  - scarejunba 8y ago
    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.
    - geggam 8y ago
      The requirement was to be cloud agnostic. This is one of the few ways possible.
      - scarface74 8y ago
        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.
scarface74 8y ago
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”.
- geggam 8y ago
  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.
  - scarface74 8y ago
    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.
    - geggam 8y ago
      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

by geggam 8y ago

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.

edoceo 8y ago

Then struggle like hell for the other 90%

scarejunba 8y ago

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.

geggam 8y ago
Quit using vendor lock in resources then asking why its hard to leave that vendor.
- scarface74 8y ago
  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.
- scarejunba 8y ago
  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.
  - geggam 8y ago
    The requirement was to be cloud agnostic. This is one of the few ways possible.
    - scarface74 8y ago
      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.

scarface74 8y ago

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

geggam 8y ago
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.
- scarface74 8y ago
  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.
  - geggam 8y ago
    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