5 ms·

Kubernetes solves a problem that most of the companies don't have. That is why I don't understand why the hype around it is so big. For the majority, it just a

by stunt 8y ago

Kubernetes solves a problem that most of the companies don't have. That is why I don't understand why the hype around it is so big. For the majority, it just adds a little value when you compare to added complexity to infrastructure and the cost of a learning curve and the ongoing operation and maintenance.

jordanbeiber 8y ago
In my experience most companies lack common conventions and automations. Kubernetes "done right" is almost a part of your application. It becomes this "machine" that you throw stuff into and good stuff happens. You'll need a team to integrate it into the pieces you require (auth, secrets, loadbalancers, permissions/app identities, monitoring and logging) but many places lack bits and pieces, and in my opinion k8s gives you a fast track to create a uniform application delivery platform. What I don't like is that it kind of is the opposite of "the unix philosophy" and in that regard I prefer the hashicorp stack.
- romeisendcoming 8y ago
  Those are your startups and web/app tier shops. Yes, they suck at sysadmin routinely and they need to be bottle fed a solution that fits the scatter/gather shape of their business. They don't want OPs discipline. They want a programmable solution that performs systems magic with a single toolset to learn.
  - jordanbeiber 8y ago
    No no, these are your enterprises I’m talking about mainly. Places entrenched in manual processes for release and change management. With true service delivery in a CI/CD fashion (including infrastructure, as it should be codified) many of these manual processes becomes obsolete. Don’t get me wrong, the processes still exist, they are just sped up by a magnitude and automated.
    - romeisendcoming 8y ago
      Who said anything about manual processes? That's not what the modern SA does...it's mostly designing repeatable processes, creating recipes and integration in my experience. The real problem with the K8s and devops world is no understanding of why there is no magic pill in 'codifying' a bad system.
      - jordanbeiber 8y ago
        I did. As I see it all to often mainly at the larger places. Modern SA is about knowing that your job to help bring business value. Most of the time this is down to automation.
        romeisendcoming 8y ago
        Did you consider that when there is a manual process it is in place to bring combined attention to what surely is (by 2019) a critical section: that needs consensus not provided by some monitoring hook. Sure, everything is about automation and it has been since 1999 in my experience.
        jordanbeiber 8y ago
        Of course. I’ve been employed and consulted enterprise IT&Dev for almost 20 years. The amount of people heating office spaces at your non-tech large enterprise is astounding in my opinion. I enjoy discussing the reasons for this, but it’s a lenghty one! In super-short: lack of competency, meaning IT support and tools are not used even remotely optimal. This lack of competency, which starts at the top, results in laughable lead times for the simplest of tasks and processes. This in turn has resulted in mass outsourcing and off-shoring of a bunch of tasks (processes) that really should have been automated years ago. Usually the incentive to improve this is 0 with these ”service providers” and things detoriate even further. The sad state of affairs is that many believe this is the way ”IT” works — slow and error prone. Awesome example: one place, one of the 500s, built an on-prem ”cloud” within a business unit. Over 2000 physical xen hosts. I wanted them to apply a patch. They refused. The last patch had taken 6 months to roll out. The process was: ssh to server, scp patch, run sudo install patch. The entire operation was bought by a renowned ”service provider”. Ouch. I could talk about this for weeks! Of course there are those that manage an awesome shop, but my experience is that this is usually isolated teams that are somewhat shielded from the crazyness of big money politics.
itronitron 8y ago
>> I don't understand why the hype around it is so big Probably because it started at Google, if it was created by IBM then we'd only hear about it on TV ads.
- deleted 8y ago
  [deleted]
threeseed 8y ago
> Kubernetes solves a problem that most of the companies don't have Actually most medium to large companies do have this problem. There are often a lot of different languages, libraries, versions, deployment methods etc. And the appeal of Docker was that you can treat them all as block boxes. And the appeal of Kubernetes is that you have this rich support infrastructure to run them all hands-off at scale. It definitely solves a problem. Just not particularly well.
manigandham 8y ago
Because you can run your apps using simple YAML files with monitoring, logging, rolling updates, load balancing, failover, persistence built in?
013a 8y ago
I disagree, almost entirely. Kubernetes solves problems that every single cloud-based software company has. What's the alternative? We spin up VMs, templated with AMIs, provisioned with an ASG? That works fine. But we want centralized logging. We want graceful restarts. We want automated rollbacks. The list goes on. These are not Google scale desires, these are "cost of doing business" asks for any cloud company. You can start building all of this on that core architecture of AMIs, or your cloud provider's equivalent, but all you're going to do re-invent what Kubernetes does, probably worse. Kubernetes' problem isn't that it solves problems most companies don't have. The problem is that these problems most companies have could be solved in a simpler way than Kubernetes, because most companies have the exact same problems.
koffiezet 8y ago
Don't agree. My current client is rather small, but I just had a meeting which would have been concluded with "we'll have to set up 15 vm's before you can start developing and have 5 alignment meetings before they're correctly set up", versus "I just created a namespace for you guys to do whatever you want in, and mailed you the link to the docs for the CI/CD and deploy guidelines". They run a self-hosted OpenShift cluster, which is managed internally by a team of 4. Not only makes this situation it a lot easier to spin up new environments, it also forces devs to include the ops team from the start for stuff they don't know, and corrections can be made early on.

by stunt 8y ago

jordanbeiber 8y ago

In my experience most companies lack common conventions and automations. Kubernetes "done right" is almost a part of your application. It becomes this "machine" that you throw stuff into and good stuff happens. You'll need a team to integrate it into the pieces you require (auth, secrets, loadbalancers, permissions/app identities, monitoring and logging) but many places lack bits and pieces, and in my opinion k8s gives you a fast track to create a uniform application delivery platform. What I don't like is that it kind of is the opposite of "the unix philosophy" and in that regard I prefer the hashicorp stack.

romeisendcoming 8y ago
Those are your startups and web/app tier shops. Yes, they suck at sysadmin routinely and they need to be bottle fed a solution that fits the scatter/gather shape of their business. They don't want OPs discipline. They want a programmable solution that performs systems magic with a single toolset to learn.
- jordanbeiber 8y ago
  No no, these are your enterprises I’m talking about mainly. Places entrenched in manual processes for release and change management. With true service delivery in a CI/CD fashion (including infrastructure, as it should be codified) many of these manual processes becomes obsolete. Don’t get me wrong, the processes still exist, they are just sped up by a magnitude and automated.
  - romeisendcoming 8y ago
    Who said anything about manual processes? That's not what the modern SA does...it's mostly designing repeatable processes, creating recipes and integration in my experience. The real problem with the K8s and devops world is no understanding of why there is no magic pill in 'codifying' a bad system.
    - jordanbeiber 8y ago
      I did. As I see it all to often mainly at the larger places. Modern SA is about knowing that your job to help bring business value. Most of the time this is down to automation.
      - romeisendcoming 8y ago
        Did you consider that when there is a manual process it is in place to bring combined attention to what surely is (by 2019) a critical section: that needs consensus not provided by some monitoring hook. Sure, everything is about automation and it has been since 1999 in my experience.
        jordanbeiber 8y ago
        Of course. I’ve been employed and consulted enterprise IT&Dev for almost 20 years. The amount of people heating office spaces at your non-tech large enterprise is astounding in my opinion. I enjoy discussing the reasons for this, but it’s a lenghty one! In super-short: lack of competency, meaning IT support and tools are not used even remotely optimal. This lack of competency, which starts at the top, results in laughable lead times for the simplest of tasks and processes. This in turn has resulted in mass outsourcing and off-shoring of a bunch of tasks (processes) that really should have been automated years ago. Usually the incentive to improve this is 0 with these ”service providers” and things detoriate even further. The sad state of affairs is that many believe this is the way ”IT” works — slow and error prone. Awesome example: one place, one of the 500s, built an on-prem ”cloud” within a business unit. Over 2000 physical xen hosts. I wanted them to apply a patch. They refused. The last patch had taken 6 months to roll out. The process was: ssh to server, scp patch, run sudo install patch. The entire operation was bought by a renowned ”service provider”. Ouch. I could talk about this for weeks! Of course there are those that manage an awesome shop, but my experience is that this is usually isolated teams that are somewhat shielded from the crazyness of big money politics.

itronitron 8y ago

>> I don't understand why the hype around it is so big Probably because it started at Google, if it was created by IBM then we'd only hear about it on TV ads.

deleted 8y ago
[deleted]

threeseed 8y ago

> Kubernetes solves a problem that most of the companies don't have Actually most medium to large companies do have this problem. There are often a lot of different languages, libraries, versions, deployment methods etc. And the appeal of Docker was that you can treat them all as block boxes. And the appeal of Kubernetes is that you have this rich support infrastructure to run them all hands-off at scale. It definitely solves a problem. Just not particularly well.

manigandham 8y ago

Because you can run your apps using simple YAML files with monitoring, logging, rolling updates, load balancing, failover, persistence built in?

013a 8y ago

I disagree, almost entirely. Kubernetes solves problems that every single cloud-based software company has. What's the alternative? We spin up VMs, templated with AMIs, provisioned with an ASG? That works fine. But we want centralized logging. We want graceful restarts. We want automated rollbacks. The list goes on. These are not Google scale desires, these are "cost of doing business" asks for any cloud company. You can start building all of this on that core architecture of AMIs, or your cloud provider's equivalent, but all you're going to do re-invent what Kubernetes does, probably worse. Kubernetes' problem isn't that it solves problems most companies don't have. The problem is that these problems most companies have could be solved in a simpler way than Kubernetes, because most companies have the exact same problems.

koffiezet 8y ago

Don't agree. My current client is rather small, but I just had a meeting which would have been concluded with "we'll have to set up 15 vm's before you can start developing and have 5 alignment meetings before they're correctly set up", versus "I just created a namespace for you guys to do whatever you want in, and mailed you the link to the docs for the CI/CD and deploy guidelines". They run a self-hosted OpenShift cluster, which is managed internally by a team of 4. Not only makes this situation it a lot easier to spin up new environments, it also forces devs to include the ops team from the start for stuff they don't know, and corrections can be made early on.