3 ms·

To be fair, it also can get overwrought: it's far from impossible to end up using a programming language to emit a templating language that emits a configuratio

by wcarss 5y ago

To be fair, it also can get overwrought: it's far from impossible to end up using a programming language to emit a templating language that emits a configuration language that itself describes configuration files. Sometimes, for simple things, those could have written by hand at the bottom without the extra tools. But even when writing them by hand would have been very hard or not the right choice, the devops stack is a daunting thing to reckon with! A developer coming from "jenkins invokes a script that runs npm install && npm start", or even the mildly more modern "jenkins invokes docker-compose on a file" has a lot of very abstract and difficult-to-play-around-with context to pick up. It's hard to learn fully even if you're at a shop with an established approach where someone knows what they're doing, but imagine moving yourself from Rackspace or Heroku onto AWS or GCP, and having to figure out IAM permissions and private VPC networking ingress configurations while also deciding if you really need to use helm. Especially if you're doing this because the team "doesn't have time to spend on ops". At the end of the day I of course agree that using k8s to manage moderately complex things can melt a lot of toil right off. In the right scenarios, more abstraction can help for more complex stuff too. But there's also a lot of marketing out there for tools-on-tools, and businesses that would love for folks to adopt solutions to problems which few people have, let alone really deeply understand.

outworlder 5y ago
> A developer coming from "jenkins invokes a script that runs npm install && npm start", or even the mildly more modern "jenkins invokes docker-compose on a file" has a lot of very abstract and difficult-to-play-around-with context to pick up. Let's see. If you are deploying this on a physical machine: you have to connect to the machine somehow. You have to setup the correct permissions. You need auditing. You need to configure logging (and log rotation). You need to ensure your npm start script will be able to be restarted if needed. You may need cronjobs for various housekeeping chores. And then suddenly you need to run more instances of your app. What to do? Are you going to setup a proxy now and a bunch of different ports? Is your script picking them up or are they hard-coded? Are you instead doing network namespaces and iptables trickery? How do you upgrade your service without downtime? Are you going to write scripts to do that? What if your app need storage. And what if you now need more machines. How are you going to spread the workloads around? And how do you automate the above? One team prefers Ansible, the other goes with Chef, a third one likes to embed shell scripts inside a Terraform provisioner. These things are _hard_. There is a whole lot of context. It's just that we have got used to the way things have always been done. It does not help that K8s development is very fast and there are far too many people and companies jumping on the bandwagon, each with their own unique spin. The ecosystem is becoming big enough to the point of being unmanageable. Also, Kubernetes joins some of the work that was done by the development team or release teams with work that was traditionally done by the operations teams, and makes it all visible. Suddenly you have to _know_ what the heck a liveness probe is. You could get by with not knowing this in a standard deployment, your app would simply lack the check(and cause issues in production). You need to know what exactly your app needs to persist. Previously it would just dump data in whatever directory it had permissions to, and this became tribal knowledge. But K8s by itself? My heuristic is: am I running containers? Do I need to spread said containers across machines? Just use K8s. Trying to replicate this with homegrown scripts will be very painful. It may not seem like it's painful now, but trust me, it will be. Will K8s exist in 15 years? Hard to say. Probably but, for the reasons you describe, it's likely that there will be, at least, a high level abstraction to hide decisions most people don't need to make.
- wcarss 5y ago
  I'll clarify that I'm on board with what you're saying. Definitely if you need N machines to split the traffic load, or an application that will auto-restart under certain conditions, you ought to just use kubernetes. It's a lot easier than rolling it all yourself. What I was trying to target above was more tooling built atop the tooling -- complex instances "the devops stack", rather than _just_ kubernetes. Take for instance, Dhall[1] -- just look at the kind of places that goes[2]! A person coming from a "run docker-compose" world maybe wasn't ever thinking about log rotation, let alone audits, and maybe they should have been. But after they read a marketing blogpost somewhere that's convinced them it is "modern best practices" to use something like Dhall, as the saying goes... now they have two problems. When the person up above mentioned the devops resume madness, that's what I was thinking of and felt it's worth noting does exist, while agreeing that vanilla k8s can be great. 1 - https://dhall-lang.org/ https://dhall-lang.org/ 2 - (shudder) https://docs.dhall-lang.org/howtos/How-to-translate-recursive-code-to-Dhall.html https://docs.dhall-lang.org/howtos/How-to-translate-recursiv...

by wcarss 5y ago

outworlder 5y ago

> A developer coming from "jenkins invokes a script that runs npm install && npm start", or even the mildly more modern "jenkins invokes docker-compose on a file" has a lot of very abstract and difficult-to-play-around-with context to pick up. Let's see. If you are deploying this on a physical machine: you have to connect to the machine somehow. You have to setup the correct permissions. You need auditing. You need to configure logging (and log rotation). You need to ensure your npm start script will be able to be restarted if needed. You may need cronjobs for various housekeeping chores. And then suddenly you need to run more instances of your app. What to do? Are you going to setup a proxy now and a bunch of different ports? Is your script picking them up or are they hard-coded? Are you instead doing network namespaces and iptables trickery? How do you upgrade your service without downtime? Are you going to write scripts to do that? What if your app need storage. And what if you now need more machines. How are you going to spread the workloads around? And how do you automate the above? One team prefers Ansible, the other goes with Chef, a third one likes to embed shell scripts inside a Terraform provisioner. These things are _hard_. There is a whole lot of context. It's just that we have got used to the way things have always been done. It does not help that K8s development is very fast and there are far too many people and companies jumping on the bandwagon, each with their own unique spin. The ecosystem is becoming big enough to the point of being unmanageable. Also, Kubernetes joins some of the work that was done by the development team or release teams with work that was traditionally done by the operations teams, and makes it all visible. Suddenly you have to _know_ what the heck a liveness probe is. You could get by with not knowing this in a standard deployment, your app would simply lack the check(and cause issues in production). You need to know what exactly your app needs to persist. Previously it would just dump data in whatever directory it had permissions to, and this became tribal knowledge. But K8s by itself? My heuristic is: am I running containers? Do I need to spread said containers across machines? Just use K8s. Trying to replicate this with homegrown scripts will be very painful. It may not seem like it's painful now, but trust me, it will be. Will K8s exist in 15 years? Hard to say. Probably but, for the reasons you describe, it's likely that there will be, at least, a high level abstraction to hide decisions most people don't need to make.

wcarss 5y ago
I'll clarify that I'm on board with what you're saying. Definitely if you need N machines to split the traffic load, or an application that will auto-restart under certain conditions, you ought to just use kubernetes. It's a lot easier than rolling it all yourself. What I was trying to target above was more tooling built atop the tooling -- complex instances "the devops stack", rather than _just_ kubernetes. Take for instance, Dhall[1] -- just look at the kind of places that goes[2]! A person coming from a "run docker-compose" world maybe wasn't ever thinking about log rotation, let alone audits, and maybe they should have been. But after they read a marketing blogpost somewhere that's convinced them it is "modern best practices" to use something like Dhall, as the saying goes... now they have two problems. When the person up above mentioned the devops resume madness, that's what I was thinking of and felt it's worth noting does exist, while agreeing that vanilla k8s can be great. 1 - https://dhall-lang.org/ https://dhall-lang.org/ 2 - (shudder) https://docs.dhall-lang.org/howtos/How-to-translate-recursive-code-to-Dhall.html https://docs.dhall-lang.org/howtos/How-to-translate-recursiv...