5 ms·

K8s is a perfect weapon to drag internal IT Ops into the cloud: once good ops has been commoditized, then the economies of scale kick in and any non-enormous IT

K8s is a perfect weapon to drag internal IT Ops into the cloud: once good ops has been commoditized, then the economies of scale kick in and any non-enormous IT systems operator will eventually realize they can be a pure-play no-fixed-costs service provider. The only challenge is of course that good ops is not the same thing depending on scale, so hype is essential to bring the plebs into accepting maximal complexity of highest-scale ops.

pjmlp 6y ago
Depends pretty much on the stack. With Java and .NET, or now serverless middleware, I never felt the need for something like k8s, as there were already solutions to deploy a bunch of EAR/WAR/DLLs into some cloud based server, including having cloud based DB servers like Amazon RDS. Taken to an extreme, I don't care where and how those packages are executing, k8, jails, containers, bare metal,...
- tracker1 6y ago
  I'm not sure I completely agree... or at least disagree to the extent that docker/containerization of applications is a huge boost to being able to deploy consistent applications. The harder part is when there are byzantine libraries that tether deep into the OS. Often this is the case for some .Net on windows (and even with Java), mostly around commercial licensing models. Spent the past two years pushing for getting (most) of the applications being worked on to at least be able to containerize and two major application developments are now targeting kubernetes for deployment. It's been uphill to say the least.
  - pjmlp 6y ago
    I guess that in my case it helps that Java applications have been mostly application container based and the .NET libraries for such deployments are managed by IT's NuGET server with validated libraries. The only ones that I have had such issues with OS integration were anyway in desktop context, which were deployed via VM snapshots, for access via RDS.
    - tracker1 6y ago
      My biggest practical issues are around a few libraries with really restrictive licensing without good floss alternatives. At least short of the effort to hire and create appropriate ML models in house, which isn't a proficiency we currently have.
- harpratap 6y ago
  The API and the packaging standard is the main contract between users. Once everyone has agreed to the fact that they need to package their applications into containers, the orchestration can be done in any way. Google's Cloud Run uses Kubernetes API + Container packaging but doesn't actually run on GKE, it's running on their regular old compute engine and users don't even come to know.

pjmlp 6y ago

Depends pretty much on the stack. With Java and .NET, or now serverless middleware, I never felt the need for something like k8s, as there were already solutions to deploy a bunch of EAR/WAR/DLLs into some cloud based server, including having cloud based DB servers like Amazon RDS. Taken to an extreme, I don't care where and how those packages are executing, k8, jails, containers, bare metal,...

tracker1 6y ago
I'm not sure I completely agree... or at least disagree to the extent that docker/containerization of applications is a huge boost to being able to deploy consistent applications. The harder part is when there are byzantine libraries that tether deep into the OS. Often this is the case for some .Net on windows (and even with Java), mostly around commercial licensing models. Spent the past two years pushing for getting (most) of the applications being worked on to at least be able to containerize and two major application developments are now targeting kubernetes for deployment. It's been uphill to say the least.
- pjmlp 6y ago
  I guess that in my case it helps that Java applications have been mostly application container based and the .NET libraries for such deployments are managed by IT's NuGET server with validated libraries. The only ones that I have had such issues with OS integration were anyway in desktop context, which were deployed via VM snapshots, for access via RDS.
  - tracker1 6y ago
    My biggest practical issues are around a few libraries with really restrictive licensing without good floss alternatives. At least short of the effort to hire and create appropriate ML models in house, which isn't a proficiency we currently have.
harpratap 6y ago
The API and the packaging standard is the main contract between users. Once everyone has agreed to the fact that they need to package their applications into containers, the orchestration can be done in any way. Google's Cloud Run uses Kubernetes API + Container packaging but doesn't actually run on GKE, it's running on their regular old compute engine and users don't even come to know.