7 ms·

My problem with Kubernetes is my problem with with front-end web frameworks - they introduce too much complexity to the point of being esoteric for simple syste

by umvi 4y ago

My problem with Kubernetes is my problem with with front-end web frameworks - they introduce too much complexity to the point of being esoteric for simple systems. If you have a simple website built on boring technologies like HTML, CSS, and vanilla JS, then nearly anyone can read, understand, and make changes to it, even backend developers. If you instead wrote it in React/Webpack/etc. then suddenly only frontend experts can understand and contribute and debug. Same with k8s. If you make a cloud backend using boring technologies like plain old programs calling APIs then nearly anyone can read, understand, and make changes to it. But if you instead make it use a big pile of configuration files with a million switches then suddenly only k8s experts can understand and contribute and debug. I'm not saying don't use ReactJS or Kubernetes, I'm just saying make sure that the benefits you get from switching to it outweigh the new complexity and therefore expertise required to understand and debug it.

initplus 4y ago
K8s provides a cloud-agnostic solution for (mostly stateless) configuration management. You have to record which ports your applications listen on, which subdomains are used for what, how to access that storage bucket with the data files in it etc. somewhere. The moment you have more than a couple of individual services managing this all by hand becomes a nightmare. You need a really strong culture of good practice to make sure that the exact production config actually ends up in source control. You can be a k8s expert, or an expert in your own home-spun configuration management/git-ops workflow. But not having any workflow here just isn't an option in my opinion. You too easily end up with spaghetti infrastructure that everybody is too scared to touch. With k8s I can take my repo of yaml and change cloud providers in an afternoon.
- XorNot 4y ago
  The problem is kubernetes doesn't include any notions of obvious things I'd like to do like parameterizing my deployment - even though all the providers want to sell me kubernetes clusters as a service.
  - FridgeSeal 4y ago
    Out of curiosity, what kind of things are you looking for here? “Parametrising what” I guess is the question.
    - XorNot 4y ago
      Off the top of my head? Namespaces, base images, configMaps (this should be pretty obvious), monitoring. Now all of this can be done, but Kubernetes does this thing where it talks extensively about applications and then goes "oh so anyway, um, like, I guess just put that stuff in git?" Which you can but with what separation? The way my configuration mounts to my applications is probably somewhat application determined, but "where" stuff runs is infrastructure. None of it matters because K8S doesn't have an answer for any of it: no standard for emitting state from clusters to allow self-configuration, no system to define axes of freedom in configuration shape, no well defined system for say, plugging your applications network requirements into perhaps a clusters policy of what networking should be. No way to expose a set of permissions for reconfiguring my infrastructure to the cluster so RBAC can define a sensible ops model. K8S is essentially a platform-for-platforms which is why it feels complicated: the moment you have it setup, you realize just how much is actually missing if you try to use it like it bills itself as.
joshmanders 4y ago
> If you have a simple website built on boring technologies like HTML, CSS, and vanilla JS, then nearly anyone can read, understand, and make changes to it, even backend developers. If you instead wrote it in React/Webpack/etc. then suddenly only frontend experts can understand and contribute and debug. The problem with this thinking is you assume that the backend developers know HTML, CSS and vanilla JS, but don't make that assumption for React/Webpack/etc because then your argument wouldn't be valid.
cogman10 4y ago
In my opinion, the complexity is something that's entirely your own making. k8s can be as simple or as complex as you like it to be and really isn't any more complex than setting up a VM (provided, you are using cloud provided k8s). Want to run an application? Write a deployment file. Want to expose that application to other applications? Write a service file. Want to expose the application to people outside the k8s cluster? Write an ingress. Want some configuration? Write a config file. With that, you've got the basics of k8s. None of this would be made easier without k8s. If you had just a VM, well, now you need to figure out how to get your deployable in the image. If you want to expose your app to others, you need to configure the routing. If you want it private, you need to configure the VPC correctly. If you want to configure the app, now you need to figure out how to set that up. After the initial learning curve, k8s ends up being, frankly. What I've listed here is like 90% of what any dev needs to learn or use in k8s. Everything else can be learned on the fly based specific requirements.
- svachalek 4y ago
  How do you make Kubernetes as simple as you'd like it to be? Even trying to deploy simple apps is several times more complicated than any other similar system I've used.
  - ckdarby 4y ago
    Expired cert, but that is how simple it can be: https://k8syaml.com/ https://k8syaml.com/ Fill out web form,and apply yaml to cluster via CLI. It is really that simple for simple apps.
  - Adiqq 4y ago
    It depends on your requirements, for basic development setup, you just need modern computer with installed Docker, k3d that runs in Docker containers and Tilt to build/deploy your docker image to local k3d docker registry and little k8s configuration. You can just use basic concepts, so if all you need is container that exposes your application, you can just prepare Dockerfile, Tiltfile and k8s yaml file with deployment, service (LB) and use Tilt to automatically apply it to cluster, when you make any source code changes. Do you need to run some script once or periodically? Single k8s yaml file with Job/CronJob might be enough. Often that's all that is needed, but maybe you need to additionally provide some env variables, use some secret values, create/mount volume to your container or deploy supporting infrastructure (databases/messages queues/authentication server/ci/cd/monitoring/tracing/alerting) or get into advanced use cases like chaos engineering, service mesh, serverless, workflow engine (CI/ML). Kubernetes requires knowledge and experience to use all of its features and ecosystem, but you don't need to know it all from the start at expert level. However you need to actually learn Kubernetes, if you want to scale your solution, because eventually more people/teams might get involved, need for cooperation increases and non-functional requirements become more important and that's when you really start to appreciate Kubernetes.
jljljl 4y ago
The article makes a similar point in the section titled “A Dictionary Date” — There’s a lot of new concepts and resource types to learn with Kubernetes that force you of your application in a different way. It’s pretty powerful and logical once you learn it, but it does take a different mind set. Fortunately, the API is programatic, so it’s possible to build abstractions on top to make dealing with those concepts easier. But that can also take a lot of work to build from scratch…
chpmrc 4y ago
> My problem with Kubernetes is my problem with with front-end web frameworks - they introduce too much complexity to the point of being esoteric for simple systems. I used to think the exact same thing but came to the realization that the complexity doesn't come from the tools, it comes from the people who misuse them. Having a set of basic config files for Kubernetes is very easy, there are a few concepts to understand but it's something anyone can learn in a matter of hours (images, containers/pods, deployments, services, volumes and ingress) and the power of abstracting your whole infrastructure in a bunch of reusable YAML lines is pretty damn cool. The same goes for things like React, once you understand the basic semantic blocks (components, props, state and more recently effects) you're 80% of the way there. Problems arise when the "I'm so smart and look what I can do!" kind of dev starts telling you that using basic boilerplate is not good enough and that you should specify all the optional values as well because "cOnTrOl", or that `create-react-app` is not good enough because "you don't really understand what happens behind the scene", but guess what? I don't care what happens behind the scenes, the same way I don't care what cc and ld do to compile and link my C code. `create-react-app` is more than enough for 99% of production grade apps. Problems arise when frontend devs need (or feel the need) to become experts in the build systems (one of the reasons why bun has become popular so quickly, standardized, included build system) or to introduce unnecessarily verbose conventions. There are two keywords in your comment that perfectly describe what I'm talking about: "Webpack" and "big pile of configuration files". Neither of those things are necessary when using K8s or React. It's overzealous devs who think micro-optimizing 5 ms off of the build process is worth writing 15 more YAML files that contribute to this false sense of "complexity". But when you think about how much you need to write in K8s (for most SQL DB backed web APIs we're talking about 3/4 files of 10 lines each) vs what you get in return (you can spin up a 1:1 copy of your entire infrastructure in a few seconds on any K8s compatible cluster, without worrying about the underlying hardware, to an extent) the tradeoff is clearly in favor of using it. As an example I'm working on a project where if I needed another worker I could just add a few lines to the K8s configuration, commit, push and magically have that worker up and running in the cluster in no time. Whereas traditionally you'd have to contact someone from the infra team, specify the characteristics of the machine, operating system, set it up, connect it to the network etc. with K8s everything is handled in those few files. IMO it's better than magic.
rektide 4y ago
> My problem with Kubernetes is my problem with with front-end web frameworks - they introduce too much complexity to the point of being esoteric for simple systems. Having seen all the ages of the web, I wouldnt support the attempt to shame frameworks like this. Fiddling the DOM is slow & causes bugs- the quasi-immediate mode version of the web we get so often now kicks ass. But to the discussion at hand- the fact that you are comparing something as singular & without peer as Kubernetes to web frameworks of which there are many many many betrays the insolidity of your argument. Web frameworks have their own style & choices, many of which are indeed fairly arbitrary. Kubernetes is nothing more than a single control loop pattern, applied again & again & again. It's opionion is simpler than most critics dare to understand. It's also a very very small pile of configuration to launch a webapp, typically. And this practice & understanding will scale not just "zero to one" but also "one to many". The time spent trying to avoid good useful tools & convince oneself to be selective & narrow in focus seems like a waste to me.
- deleted 4y ago
  [deleted]
schwartzworld 4y ago
> If you have a simple website built on boring technologies like HTML, CSS, and vanilla JS, then nearly anyone can read, understand, and make changes to it, even backend developers Ehhhh, or it could be a pile of shit and be unmaintainable. The upside of the ubiquity of react is that once you learn it well, dropping into a react based project is much simpler. How simple of a website are you talking about? Something so simple not to need a framework could also be equally simple in React, maybe more so because of the ecosystem, dev tools, testing, etc.
- umvi 4y ago
  To use a concrete example - Swagger UI 2.0 was plain old html, css, and JS. I was able to easily navigate the code and customize it for my previous company with some extra features we wanted. Swagger UI 3.0+ was completely rewritten in React, and I had a super hard time navigating the new source code and trying to figure out how to achieve the same basic things I did with 2.0 with some minor JS tweaks. I'm sure if I invested a few days/weeks becoming a React expert I would be able to do it. But I wasn't willing to do that, so as a result, we are still on Swagger UI 2.0. Judge for yourself: Swagger UI 2.0: https://github.com/swagger-api/swagger-ui/tree/2.x https://github.com/swagger-api/swagger-ui/tree/2.x vs Swagger UI 4.0 https://github.com/swagger-api/swagger-ui https://github.com/swagger-api/swagger-ui
  - schwartzworld 4y ago
    I finally got to look at the source code. There's a lot going on, and it's pretty well organized into components and small files. The worst thing is the flat file structure. Diving into a React codebase definitely requires some process and familiarity with dev tools, common patterns and React in general, but the upside is that the process is repeatable. Doesn't do you a lot of good for diving into a random codebase, but as a pro React dev, I can hit the ground running much faster than with a project of similar complexity.
deleted 4y ago
[deleted]
cortesoft 4y ago
See, I find the most compelling part of k8s being that it makes it a lot easier to integrate different systems. It provides a standard way to define your system/service, which allows easy interoperability.
ggregoire 4y ago
Quite frankly, the only difference between a developer who can understand React and a developer who cannot: one read the doc and the other didn't.
vbezhenar 4y ago
If you're using docker, then your project is already complex enough to migrate to k8s. You can install kubernetes on a single node, without any clustering, just to get its API and run your workloads there. It'll cost you 2GB of RAM. It won't be HA, but it'll be much more sane than docker. I'm saying it as a person who avoided k8s as much as I could, but in the end I loved it. Yes, it has some learning curve, but after that it's good.
nazka 4y ago
I am a full stack and I use React for the front-end and for me React is not hard. Why? Hear me out. All this talk about k8s being hard is real but not a bad thing. Why? Because our tech and our jobs are hard. Like you said to a non front-end person React from your POV is hard. As much as k8s is hard for a back-end or front-end guy. And that's how you have so many articles about X and Y being so complex and hard, and 90% of the time they are written by people that never really used it and it's not even their job. But then if you ask a front-end dev if he love React and if it's hard for him? At the beginning maybe but now? No. A back-end with Spring/Rails/Next.js... All the same maybe at the beginning but now? No. But try to cross the bridges without being already good at the other stack and this being your daily job; it's always hard. As a side example I played fighter jet simulators (Falcon BMS, and DCS) and I stopped to play them for a year. Before I could fly and do a full cold start of the F14 [1], the F16, the KA-50, the SU-27 (ok this one is super easy), and I was learning the A10. Now I am looking at all these buttons and I am like: how was I able to do this?? Dang! But when I was into it, it was super easy. That's really the same here. You have the opposite of a honey moon period. At first it's (super) hard, and then it gets super easier and easier and it looks like you are a wizard to others. And it was the same for me back in the day where people were doing crazy stuff with Mesos. They looked like wizard to me. Then I dived into Mesos, Raft, Peloton, etc... And now it no longer looks so crazy and scary. I am sure you are doing stuff that look so easy to you but are super hard to others who work on a different part of the stack. [1] https://www.youtube.com/watch?v=i7oC_Qwq0-w https://www.youtube.com/watch?v=i7oC_Qwq0-w (because it's so cool)

by umvi 4y ago

initplus 4y ago

K8s provides a cloud-agnostic solution for (mostly stateless) configuration management. You have to record which ports your applications listen on, which subdomains are used for what, how to access that storage bucket with the data files in it etc. somewhere. The moment you have more than a couple of individual services managing this all by hand becomes a nightmare. You need a really strong culture of good practice to make sure that the exact production config actually ends up in source control. You can be a k8s expert, or an expert in your own home-spun configuration management/git-ops workflow. But not having any workflow here just isn't an option in my opinion. You too easily end up with spaghetti infrastructure that everybody is too scared to touch. With k8s I can take my repo of yaml and change cloud providers in an afternoon.

XorNot 4y ago
The problem is kubernetes doesn't include any notions of obvious things I'd like to do like parameterizing my deployment - even though all the providers want to sell me kubernetes clusters as a service.
- FridgeSeal 4y ago
  Out of curiosity, what kind of things are you looking for here? “Parametrising what” I guess is the question.
  - XorNot 4y ago
    Off the top of my head? Namespaces, base images, configMaps (this should be pretty obvious), monitoring. Now all of this can be done, but Kubernetes does this thing where it talks extensively about applications and then goes "oh so anyway, um, like, I guess just put that stuff in git?" Which you can but with what separation? The way my configuration mounts to my applications is probably somewhat application determined, but "where" stuff runs is infrastructure. None of it matters because K8S doesn't have an answer for any of it: no standard for emitting state from clusters to allow self-configuration, no system to define axes of freedom in configuration shape, no well defined system for say, plugging your applications network requirements into perhaps a clusters policy of what networking should be. No way to expose a set of permissions for reconfiguring my infrastructure to the cluster so RBAC can define a sensible ops model. K8S is essentially a platform-for-platforms which is why it feels complicated: the moment you have it setup, you realize just how much is actually missing if you try to use it like it bills itself as.

joshmanders 4y ago

> If you have a simple website built on boring technologies like HTML, CSS, and vanilla JS, then nearly anyone can read, understand, and make changes to it, even backend developers. If you instead wrote it in React/Webpack/etc. then suddenly only frontend experts can understand and contribute and debug. The problem with this thinking is you assume that the backend developers know HTML, CSS and vanilla JS, but don't make that assumption for React/Webpack/etc because then your argument wouldn't be valid.

cogman10 4y ago

In my opinion, the complexity is something that's entirely your own making. k8s can be as simple or as complex as you like it to be and really isn't any more complex than setting up a VM (provided, you are using cloud provided k8s). Want to run an application? Write a deployment file. Want to expose that application to other applications? Write a service file. Want to expose the application to people outside the k8s cluster? Write an ingress. Want some configuration? Write a config file. With that, you've got the basics of k8s. None of this would be made easier without k8s. If you had just a VM, well, now you need to figure out how to get your deployable in the image. If you want to expose your app to others, you need to configure the routing. If you want it private, you need to configure the VPC correctly. If you want to configure the app, now you need to figure out how to set that up. After the initial learning curve, k8s ends up being, frankly. What I've listed here is like 90% of what any dev needs to learn or use in k8s. Everything else can be learned on the fly based specific requirements.

svachalek 4y ago
How do you make Kubernetes as simple as you'd like it to be? Even trying to deploy simple apps is several times more complicated than any other similar system I've used.
- ckdarby 4y ago
  Expired cert, but that is how simple it can be: https://k8syaml.com/ https://k8syaml.com/ Fill out web form,and apply yaml to cluster via CLI. It is really that simple for simple apps.
- Adiqq 4y ago
  It depends on your requirements, for basic development setup, you just need modern computer with installed Docker, k3d that runs in Docker containers and Tilt to build/deploy your docker image to local k3d docker registry and little k8s configuration. You can just use basic concepts, so if all you need is container that exposes your application, you can just prepare Dockerfile, Tiltfile and k8s yaml file with deployment, service (LB) and use Tilt to automatically apply it to cluster, when you make any source code changes. Do you need to run some script once or periodically? Single k8s yaml file with Job/CronJob might be enough. Often that's all that is needed, but maybe you need to additionally provide some env variables, use some secret values, create/mount volume to your container or deploy supporting infrastructure (databases/messages queues/authentication server/ci/cd/monitoring/tracing/alerting) or get into advanced use cases like chaos engineering, service mesh, serverless, workflow engine (CI/ML). Kubernetes requires knowledge and experience to use all of its features and ecosystem, but you don't need to know it all from the start at expert level. However you need to actually learn Kubernetes, if you want to scale your solution, because eventually more people/teams might get involved, need for cooperation increases and non-functional requirements become more important and that's when you really start to appreciate Kubernetes.

jljljl 4y ago

The article makes a similar point in the section titled “A Dictionary Date” — There’s a lot of new concepts and resource types to learn with Kubernetes that force you of your application in a different way. It’s pretty powerful and logical once you learn it, but it does take a different mind set. Fortunately, the API is programatic, so it’s possible to build abstractions on top to make dealing with those concepts easier. But that can also take a lot of work to build from scratch…

chpmrc 4y ago

> My problem with Kubernetes is my problem with with front-end web frameworks - they introduce too much complexity to the point of being esoteric for simple systems. I used to think the exact same thing but came to the realization that the complexity doesn't come from the tools, it comes from the people who misuse them. Having a set of basic config files for Kubernetes is very easy, there are a few concepts to understand but it's something anyone can learn in a matter of hours (images, containers/pods, deployments, services, volumes and ingress) and the power of abstracting your whole infrastructure in a bunch of reusable YAML lines is pretty damn cool. The same goes for things like React, once you understand the basic semantic blocks (components, props, state and more recently effects) you're 80% of the way there. Problems arise when the "I'm so smart and look what I can do!" kind of dev starts telling you that using basic boilerplate is not good enough and that you should specify all the optional values as well because "cOnTrOl", or that `create-react-app` is not good enough because "you don't really understand what happens behind the scene", but guess what? I don't care what happens behind the scenes, the same way I don't care what cc and ld do to compile and link my C code. `create-react-app` is more than enough for 99% of production grade apps. Problems arise when frontend devs need (or feel the need) to become experts in the build systems (one of the reasons why bun has become popular so quickly, standardized, included build system) or to introduce unnecessarily verbose conventions. There are two keywords in your comment that perfectly describe what I'm talking about: "Webpack" and "big pile of configuration files". Neither of those things are necessary when using K8s or React. It's overzealous devs who think micro-optimizing 5 ms off of the build process is worth writing 15 more YAML files that contribute to this false sense of "complexity". But when you think about how much you need to write in K8s (for most SQL DB backed web APIs we're talking about 3/4 files of 10 lines each) vs what you get in return (you can spin up a 1:1 copy of your entire infrastructure in a few seconds on any K8s compatible cluster, without worrying about the underlying hardware, to an extent) the tradeoff is clearly in favor of using it. As an example I'm working on a project where if I needed another worker I could just add a few lines to the K8s configuration, commit, push and magically have that worker up and running in the cluster in no time. Whereas traditionally you'd have to contact someone from the infra team, specify the characteristics of the machine, operating system, set it up, connect it to the network etc. with K8s everything is handled in those few files. IMO it's better than magic.

rektide 4y ago

> My problem with Kubernetes is my problem with with front-end web frameworks - they introduce too much complexity to the point of being esoteric for simple systems. Having seen all the ages of the web, I wouldnt support the attempt to shame frameworks like this. Fiddling the DOM is slow & causes bugs- the quasi-immediate mode version of the web we get so often now kicks ass. But to the discussion at hand- the fact that you are comparing something as singular & without peer as Kubernetes to web frameworks of which there are many many many betrays the insolidity of your argument. Web frameworks have their own style & choices, many of which are indeed fairly arbitrary. Kubernetes is nothing more than a single control loop pattern, applied again & again & again. It's opionion is simpler than most critics dare to understand. It's also a very very small pile of configuration to launch a webapp, typically. And this practice & understanding will scale not just "zero to one" but also "one to many". The time spent trying to avoid good useful tools & convince oneself to be selective & narrow in focus seems like a waste to me.

deleted 4y ago
[deleted]

schwartzworld 4y ago

> If you have a simple website built on boring technologies like HTML, CSS, and vanilla JS, then nearly anyone can read, understand, and make changes to it, even backend developers Ehhhh, or it could be a pile of shit and be unmaintainable. The upside of the ubiquity of react is that once you learn it well, dropping into a react based project is much simpler. How simple of a website are you talking about? Something so simple not to need a framework could also be equally simple in React, maybe more so because of the ecosystem, dev tools, testing, etc.

umvi 4y ago
To use a concrete example - Swagger UI 2.0 was plain old html, css, and JS. I was able to easily navigate the code and customize it for my previous company with some extra features we wanted. Swagger UI 3.0+ was completely rewritten in React, and I had a super hard time navigating the new source code and trying to figure out how to achieve the same basic things I did with 2.0 with some minor JS tweaks. I'm sure if I invested a few days/weeks becoming a React expert I would be able to do it. But I wasn't willing to do that, so as a result, we are still on Swagger UI 2.0. Judge for yourself: Swagger UI 2.0: https://github.com/swagger-api/swagger-ui/tree/2.x https://github.com/swagger-api/swagger-ui/tree/2.x vs Swagger UI 4.0 https://github.com/swagger-api/swagger-ui https://github.com/swagger-api/swagger-ui
- schwartzworld 4y ago
  I finally got to look at the source code. There's a lot going on, and it's pretty well organized into components and small files. The worst thing is the flat file structure. Diving into a React codebase definitely requires some process and familiarity with dev tools, common patterns and React in general, but the upside is that the process is repeatable. Doesn't do you a lot of good for diving into a random codebase, but as a pro React dev, I can hit the ground running much faster than with a project of similar complexity.

deleted 4y ago

[deleted]

cortesoft 4y ago

See, I find the most compelling part of k8s being that it makes it a lot easier to integrate different systems. It provides a standard way to define your system/service, which allows easy interoperability.

ggregoire 4y ago

Quite frankly, the only difference between a developer who can understand React and a developer who cannot: one read the doc and the other didn't.

vbezhenar 4y ago

If you're using docker, then your project is already complex enough to migrate to k8s. You can install kubernetes on a single node, without any clustering, just to get its API and run your workloads there. It'll cost you 2GB of RAM. It won't be HA, but it'll be much more sane than docker. I'm saying it as a person who avoided k8s as much as I could, but in the end I loved it. Yes, it has some learning curve, but after that it's good.

nazka 4y ago

I am a full stack and I use React for the front-end and for me React is not hard. Why? Hear me out. All this talk about k8s being hard is real but not a bad thing. Why? Because our tech and our jobs are hard. Like you said to a non front-end person React from your POV is hard. As much as k8s is hard for a back-end or front-end guy. And that's how you have so many articles about X and Y being so complex and hard, and 90% of the time they are written by people that never really used it and it's not even their job. But then if you ask a front-end dev if he love React and if it's hard for him? At the beginning maybe but now? No. A back-end with Spring/Rails/Next.js... All the same maybe at the beginning but now? No. But try to cross the bridges without being already good at the other stack and this being your daily job; it's always hard. As a side example I played fighter jet simulators (Falcon BMS, and DCS) and I stopped to play them for a year. Before I could fly and do a full cold start of the F14 [1], the F16, the KA-50, the SU-27 (ok this one is super easy), and I was learning the A10. Now I am looking at all these buttons and I am like: how was I able to do this?? Dang! But when I was into it, it was super easy. That's really the same here. You have the opposite of a honey moon period. At first it's (super) hard, and then it gets super easier and easier and it looks like you are a wizard to others. And it was the same for me back in the day where people were doing crazy stuff with Mesos. They looked like wizard to me. Then I dived into Mesos, Raft, Peloton, etc... And now it no longer looks so crazy and scary. I am sure you are doing stuff that look so easy to you but are super hard to others who work on a different part of the stack. [1] https://www.youtube.com/watch?v=i7oC_Qwq0-w https://www.youtube.com/watch?v=i7oC_Qwq0-w (because it's so cool)