5 ms·

I think what a lot of people forget is that this is being driven by costs. Companies don't want to pay for disaster recovery, and it's cheaper to set up a k8's

I think what a lot of people forget is that this is being driven by costs. Companies don't want to pay for disaster recovery, and it's cheaper to set up a k8's platform. The platform itself performs disaster recovery, so now that's one less cost for the company. It's all about saving money on DR. When these companies realize that developers can't handle doing ops AND complex business logic, maybe they'll rethink it. Until then I expect this trend to spread rapidly as companies look for ways to abstract away DR costs.

hodgesrm 8y ago
Can you define what you mean by disaster recovery? To me it means the ability to recover business applications from a site failure. Assuming you have a similar definition how does Kubernetes solve that problem?
- humbleMouse 8y ago
  What I mean by DR is that if a data center gets nuked, you still have a replica of your k8's platform running in your other data center(s). So k8's basically runs a replica of your whole system behind the scenes so if a physical location goes down you still have your system running.
  - hodgesrm 8y ago
    What about all the data in DBMS, file systems, object stores? Also what about BGP routes, firewall settings, SNAT/DNAT rules and the like? There's a lot more to replicate than just the bits in the apps.
    - SteveNuts 8y ago
      Those are the types of things developers simply don't have experience using. And if Kubernetes tries to replace all of those it will become the new OpenStack.
    - humbleMouse 8y ago
      Well, that depends where those resources are running and also depends if you're leveraging persistent storage in k8's. All the routes/firewall/dns etc. will be preserved in the event a data center is nuked. Like I said, k8's is replicating your entire system behind the scenes.
    - moondev 8y ago
      Yes to all. The most difficult thing is persistent volumes, but leveraging things like Heptio's ark allow you to send them to an alternative storage class. It's awesome stuff. https://github.com/heptio/ark https://github.com/heptio/ark
newcrobuzon 8y ago
Isn't that problem solved equally with VMs?
- humbleMouse 8y ago
  No, not unless you replicated the VMs accross different data centers manually. Which actually isn't that difficult using docker.
tannhaeuser 8y ago
In my experience, people are using k8s et al and microservices because "everyone is doing it", "nobody got fired for choosing microservices", "I need more cloud stuff on my resume" and a vague (and unsubstantiated, unless you're in SF maybe) hope to hire ops staff on the cheap. Frequently, it ends up in a mix of a partial k8s setup for services plus dedicated DB, logging, backup, and other proprietary persistence infrastructure services. In other words, the union of problems/risks, and the intersection of capabilities; and in particular such that moving to another cloud provider is impossible :) Cloud services is pretty much a business of huge marketing budgets and old-school lock-in strategies.

hodgesrm 8y ago

Can you define what you mean by disaster recovery? To me it means the ability to recover business applications from a site failure. Assuming you have a similar definition how does Kubernetes solve that problem?

humbleMouse 8y ago
What I mean by DR is that if a data center gets nuked, you still have a replica of your k8's platform running in your other data center(s). So k8's basically runs a replica of your whole system behind the scenes so if a physical location goes down you still have your system running.
- hodgesrm 8y ago
  What about all the data in DBMS, file systems, object stores? Also what about BGP routes, firewall settings, SNAT/DNAT rules and the like? There's a lot more to replicate than just the bits in the apps.
  - SteveNuts 8y ago
    Those are the types of things developers simply don't have experience using. And if Kubernetes tries to replace all of those it will become the new OpenStack.
  - humbleMouse 8y ago
    Well, that depends where those resources are running and also depends if you're leveraging persistent storage in k8's. All the routes/firewall/dns etc. will be preserved in the event a data center is nuked. Like I said, k8's is replicating your entire system behind the scenes.
  - moondev 8y ago
    Yes to all. The most difficult thing is persistent volumes, but leveraging things like Heptio's ark allow you to send them to an alternative storage class. It's awesome stuff. https://github.com/heptio/ark https://github.com/heptio/ark

newcrobuzon 8y ago

Isn't that problem solved equally with VMs?

humbleMouse 8y ago
No, not unless you replicated the VMs accross different data centers manually. Which actually isn't that difficult using docker.

tannhaeuser 8y ago

In my experience, people are using k8s et al and microservices because "everyone is doing it", "nobody got fired for choosing microservices", "I need more cloud stuff on my resume" and a vague (and unsubstantiated, unless you're in SF maybe) hope to hire ops staff on the cheap. Frequently, it ends up in a mix of a partial k8s setup for services plus dedicated DB, logging, backup, and other proprietary persistence infrastructure services. In other words, the union of problems/risks, and the intersection of capabilities; and in particular such that moving to another cloud provider is impossible :) Cloud services is pretty much a business of huge marketing budgets and old-school lock-in strategies.