4 ms·

I'm a former OpenShift (Red Hat's distribution of Kubernetes) consultant and currently I work at Red Hat in a different position and I have to disagree on the "

I'm a former OpenShift (Red Hat's distribution of Kubernetes) consultant and currently I work at Red Hat in a different position and I have to disagree on the "won't work at all without an army of consultants". While it's true that some of our customers have an army of consultants, the vast majority of our customers don't use consulting at all or that only use it very infrequently. If you don't want a lot of customization, have the right amount of people and the right people and realistic expectations you don't need consulting at all. When people want to get a highly customized experience (often, for the wrong reasons), or want to get in production after 2 months, when their people have no experience in kubernetes and didn't do adequate testing (load, fault-tolerance, etc) it will give lot of problems. But that's the case for everything, not only for kubernetes In my opinion (mine, not Red Hat's) getting someone to deploy it with you the first time, showing how it's done and why things are done, and after that and do a workshop explaining the basic concepts has great value, saves a lot of time and isn't expensive.

dkhenry 8y ago
This is the same process that was done with J2EE and Application Servers, it starts out with a _simple_ standard to have a Java application served with a standard API, and then it grows out of control. You are already seeing it with Itsio and Helm being layered on top. Today you might be able to get the stock Kubernetes up without much assistance, but give it a few years as "features" get added on.
- brozaman 8y ago
  I'm not seeing that and I'm pretty sure we won't. it's extremely hard to get new features in the core of kubernetes and in fact it's moving to a micro services architecture. Neither helm or istio are part of the core.
  - kiallmacinnes 8y ago
    I think you're making a distinction that many others wont. Specifically, a distinction that ordinary users of Kubernetes won't make. Kubernetes is more than what's in the Kubernetes core GitHub repo, it's the collection of tools that go along with Kubernetes that "average users" expect to just be there. For example, an ingress controller, helm, likely soon cert-manager and external-dns too. The split out into multiple projects actually makes the landscape harder. Where by people and distributions have to make choices about the set of expected vs set of provided features. A great example of this I saw was an internal thread here at SUSE (I work on their Kubernetes product) where ingress controllers were being compared. Despite the Ingress data model actually being in the core, features like nginx-ingress-controllers ability to do arbitrary TCP and UDP ports on the same external-IP were being seen as a reason to choose that controller over some of the others. I can't argue the feature is useless, because it's not - it's very useful - but it's a great example of how things can very easily become conflated, even for people who should know better! A feature being part of the core just means it's part of a minimal Kubernetes deployment, while a complete Kubernetes deployment includes much more than core.
mmt 8y ago
> want to get in production after 2 months [...] > it will give lot of problems. But that's the case for everything, not only for kubernetes Are you asserting that any modern production environment that takes less than 2 months to set up is bound to cause problems? Or the whole company/startup/project? If the former, I'd say there are many tech startups who would disagree, or at the very least, point out that it doesn't matter because they'd cease to exist during those 2 months without an MVP in production.
- marenkay 8y ago
  I think the two month phase is pretty accurate. Deployment itself is not that time intense and changing your applications to be container friendly is not either. The time intensive phase during the first Kubernetes deployment is changing the mindset of the engineering team and everyone involved in IT. Kubernetes IMHO is pretty much like moving from college into work life and adapting to the fact that requirements for a decent adult life are very much different from a college life.
  - mmt 8y ago
    That's as may be for Kubernetes, but the GP specifically stated "that's the case for everything, not only for kubernetes", which struck me as an extraordinarily broad claim. One might reasonably expect "everything" to include traditional deployment methods that require no changing of mindsets (not that that's likely a factor in my nascent startup example).
    - marenkay 8y ago
      Transition phases actually make sense even if you apply "everything" instead of just "Kubernetes" considering how every company transitions through stages in terms of tooling. Think being a startup where deployments most likely will be manual and undocumented, upgrading to an initial automation using some scripting, transitioning to CI/CD, etc. So from various experiences at companies of all sizes I would actually support such a broad claim, since companies are basically transitioning all the time through new phases to greener pastures. That of course assumes that the company values constant improvements and uses an iterative process for growth and change.

dkhenry 8y ago

This is the same process that was done with J2EE and Application Servers, it starts out with a _simple_ standard to have a Java application served with a standard API, and then it grows out of control. You are already seeing it with Itsio and Helm being layered on top. Today you might be able to get the stock Kubernetes up without much assistance, but give it a few years as "features" get added on.

brozaman 8y ago
I'm not seeing that and I'm pretty sure we won't. it's extremely hard to get new features in the core of kubernetes and in fact it's moving to a micro services architecture. Neither helm or istio are part of the core.
- kiallmacinnes 8y ago
  I think you're making a distinction that many others wont. Specifically, a distinction that ordinary users of Kubernetes won't make. Kubernetes is more than what's in the Kubernetes core GitHub repo, it's the collection of tools that go along with Kubernetes that "average users" expect to just be there. For example, an ingress controller, helm, likely soon cert-manager and external-dns too. The split out into multiple projects actually makes the landscape harder. Where by people and distributions have to make choices about the set of expected vs set of provided features. A great example of this I saw was an internal thread here at SUSE (I work on their Kubernetes product) where ingress controllers were being compared. Despite the Ingress data model actually being in the core, features like nginx-ingress-controllers ability to do arbitrary TCP and UDP ports on the same external-IP were being seen as a reason to choose that controller over some of the others. I can't argue the feature is useless, because it's not - it's very useful - but it's a great example of how things can very easily become conflated, even for people who should know better! A feature being part of the core just means it's part of a minimal Kubernetes deployment, while a complete Kubernetes deployment includes much more than core.

mmt 8y ago

> want to get in production after 2 months [...] > it will give lot of problems. But that's the case for everything, not only for kubernetes Are you asserting that any modern production environment that takes less than 2 months to set up is bound to cause problems? Or the whole company/startup/project? If the former, I'd say there are many tech startups who would disagree, or at the very least, point out that it doesn't matter because they'd cease to exist during those 2 months without an MVP in production.

marenkay 8y ago
I think the two month phase is pretty accurate. Deployment itself is not that time intense and changing your applications to be container friendly is not either. The time intensive phase during the first Kubernetes deployment is changing the mindset of the engineering team and everyone involved in IT. Kubernetes IMHO is pretty much like moving from college into work life and adapting to the fact that requirements for a decent adult life are very much different from a college life.
- mmt 8y ago
  That's as may be for Kubernetes, but the GP specifically stated "that's the case for everything, not only for kubernetes", which struck me as an extraordinarily broad claim. One might reasonably expect "everything" to include traditional deployment methods that require no changing of mindsets (not that that's likely a factor in my nascent startup example).
  - marenkay 8y ago
    Transition phases actually make sense even if you apply "everything" instead of just "Kubernetes" considering how every company transitions through stages in terms of tooling. Think being a startup where deployments most likely will be manual and undocumented, upgrading to an initial automation using some scripting, transitioning to CI/CD, etc. So from various experiences at companies of all sizes I would actually support such a broad claim, since companies are basically transitioning all the time through new phases to greener pastures. That of course assumes that the company values constant improvements and uses an iterative process for growth and change.