9 ms·

I mean, good on the author, but this isn’t what Kubernetes is really for. Kubernetes is basically a way to run a Java-like application server that can run thin

I mean, good on the author, but this isn’t what Kubernetes is really for. Kubernetes is basically a way to run a Java-like application server that can run things other than Java. If that sounds like an appealing prospect to you, the complexity of Kubernetes may be a good fit. Kubernetes is complex because sometimes you need to be able to do complex things. Sometimes you operate at a scale where spending 12 hours writing a deployment script is ok, because it will save you hundreds of hours in the near term. Kubernetes expects you to write a bunch of custom integrations to tie your k8s clusters into whatever ITSM / ITIL process you use. But complaining that running a blog on Kubernetes is too complex is like complaining that a semi is a terrible vehicle because it’s hard to park at the grocery store.

arethuza 7y ago
Where would you draw the dividing line between where you think it does make sense to use something like Kubernetes and where it doesn't?
- wayoutthere 7y ago
  There isn’t a dividing line per se; every operating model is going to have different breakpoints. In general though, I would consider Kubernetes an “enterprise technology”. If you’re a startup you’re going to be better off paying AWS/Heroku for one of their more managed services than hiring someone to build / manage a Kubernetes cluster.
  - falcolas 7y ago
    A note on this - AWS (or any other host's) managed k8s will not reduce the need to understand what's going on under the hood. It's still k8s, you're just not running the daemons to make it work (which is, arguably, the easy part).
- bryanlarsen 7y ago
  You've signed an > 99.9% availability SLA with a customer and a service like Elastic Beanstalk or Heroku isn't sufficient for your needs.
  - falcolas 7y ago
    Technically, the cloud in general probably isn't for you, since none of them guarantee more than 3x9's on any of their services.
    - bryanlarsen 7y ago
      Yup, meant to say >= 99.9%. Of course most businesses operate more like what Cloudflare makes explicit with it's "100%" SLA. Architect for 3 nines and then just pay the penalty when the 3 nines architecture doesn't hit 4 nines.
- cies 7y ago
  If you need your workload to span over an (possibly growing) number of server hardwares, you may want to use k8s. There are other options that are good contenders in case of such a workload.
- xemdetia 7y ago
  I'm starting to feel that the whether or not you need Kubernetes is closer to old conversations related to whether or not you need a dedicated DBA. Can your organization survive and recover with hourly/nightly backup restores to recover from an incident? Is your replication so complex that you really need a guy to ensure that's never getting into a bad state? Worse case scenario can most people working on the project restore the database to a valid state if something does go wrong? I feel like these questions have similar representatives in whether or not Kubernetes is right for an organization. Kubernetes also makes more sense if you look at it as a common way for an organization to run applications among disparate teams with a shared operations infrastructure. It provides a standardized model for things to work the same enough to work the same. If you are only delivering one kind/whole organization thing and it all looks and quacks like a duck maybe you should just deliver a duck instead of putting a duck hat on Kubernetes and asking it to quack. I don't think there is anything wrong with designing an application that would transition easily into Kubernetes but I feel like many of the proposals/PoC I have seen in the last few years are either fresh systems that get consumed by Kubernetes complexity or are poor replacements to systems that already exist and only seem to serve as resume padders for the team architecting the replacement which gets a viking funeral as soon as they leave. Often the latter case is because the underlying architecture and goal of the system is pre-Kubernetes and doesn't fit the model well of having mostly stateless/replaceable pieces.
- moduspol 7y ago
  Kind of implicit in the other responses here are use cases that call for a full cluster and all the complexity that goes along with it. But running a single node cluster is totally valid. I use one at home to run arbitrary containers (a DNS-over-TLS proxy, VPN server, radius server, network AP / switch manager, etc.). I don't use load balancers and just use host-based persistent storage, which removes the vast majority of the complexity. I've seen a lot of people get wrapped up in the complexity of wanting to be able to have a persist storage-backed process go down on one node and come back up on another, and that's not unreasonable, but that's a lot of stuff to figure out early on. If I weren't using this as a single node k8s instance, I might use it to manage VMs, which might be easier to understand but much heavier and more work to maintain. With what I have now, I've got a folder of YAMLs that defines everything to run on my node, and I'm able to easily put all their persistent data in the same top-level dir for easy backup. I think the perception of k8s might change over time once people realize that it provides a lot of value even if you completely rule out the tougher stuff to do on bare metal (like load balancers and shared persistent volumes).
grenoire 7y ago
Completely valid points, and I agree to all of them. Alas, as other commenters have pointed out, the issue is devs at smaller companies deploying smaller products buying into the idea that they need k8s. I believe that it is the community's duty to educate these devs on what k8s is and when it is needed.
- gambler 7y ago
  They are probably scared that when they need to change jobs, the next company will require "5 years of Kubernetes experience". So they convince everyone at their current company to jump into a complexity clusterfuck to see how it works "in production" and can put it on their resume. This is how the entire IT industry works today. I am fucking appalled writing config files is a noteworthy skill is 2019. So should you.
  - cameronbrown 7y ago
    K8S is hardly just "writing config files" is it? You've still got to understand a ton of moving parts underneath before you're able to.
    - falcolas 7y ago
      K8s is writing config files just like Python is writing Python Syntax. If you don't understand the underlying mechanism, either with Python or K8s yaml files, you're going to have a very bad time. Somewhat ironic side note - Asking folks to write K8s config files is exposing too much complexity for some developers I work with. And I kind of get it. Properly setting up a service with changing environment variables, secrets, ingress, API Roles, AWS IAM roles, and horizontal autoscaling can get a bit nuts.
      - wayoutthere 7y ago
        Yeah, fully integrated “DevOps” at scale is a pipe dream. You will always have some segregation of dev and ops because the scope of knowledge is so different, especially today where “Ops” often means “expert in XXX cloud vendor’s product portfolio and how our operating model uses the features”. What we call “DevOps” is really a delicate balance of giving the dev teams enough rope to hang themselves while child-proofing the gallows.
zemo 7y ago
> complaining that running a blog on Kubernetes is too complex think you're really missing the point here. Why do you think this was included in the post? https://twitter.com/dexhorthy/status/856639005462417409 https://twitter.com/dexhorthy/status/856639005462417409
- wayoutthere 7y ago
  Oh I get the author’s point, but her use case was “basically a Heroku replacement for easy deployment”. It’s just the wrong use case for Kubernetes and it is well known that deploying to Kubernetes is a bit of a nightmare.
  - parasubvert 7y ago
    Except Kubernetes has sucked all the oxygen up in the industry and has had a subset of adherents that trash the alternatives such as Heroku, Cloud Foundry, etc. As such, people do expect it to replace Heroku.
    - root_axis 7y ago
      Anyone who suggests k8s as an alternative to Heroku is wrong. Heroku is a product that manages infrastructure so that the programmer doesn't have to, k8s is a solution for operational engineers that want a code-driven approach to managing their own infrastructure. Suggesting k8s as a replacement for Heroku is like suggesting docker as a replacement for EC2.
      - parasubvert 7y ago
        And yet, they both fight for the same budget. They're absolutely alternatives in that sense. Not necessarily the right tool for the job, but alas, that's not stopped the wave. And eventually, even Heroku will be based on K8s, as they see the writing on the wall. Also note that most adherents view K8s as a replacement (more accurately new API) that replaces EC2. the fundamental unit of computing becomes the Pod, not a VM.
  - 7y ago
rcarmo 7y ago
Well, maybe it isn't _only_ what it's for, but I have thought of doing largely the same and "bundle" a bunch of assorted projects onto a single 3-node cluster, including my blog. The only thing that's really prevented me from doing so is that I have my own micro-PaaS (https://github.com/piku https://github.com/piku) that makes it trivial to run a bunch of different apps/services on the same VPS, and the added complexity isn't really necessary. But since I deal with k8s practically every day at customers, attrition might be compensated by not having to switch tooling. YMMV within this sort of scope.
- wayoutthere 7y ago
  I mean, that’s kind of my point. It’s just not designed for that use case. Someone could build a simplified fork / derivative of Kubernetes designed for this purpose. That would be pretty rad actually, but it would cease to be Kubernetes because the complexity is the point.
  - rcarmo 7y ago
    k3s.io is great, and I use that as well - is to be what I will eventually run in "production" for my personal stuff.
  - wikibob 7y ago
    k3s? https://k3s.io https://k3s.io
- cameronbrown 7y ago
  > The only thing that's really prevented me from doing so is that I have my own micro-PaaS (https://github.com/piku https://github.com/piku) that makes it trivial to run a bunch of different apps/services on the same VPS, and the added complexity isn't really necessary. How does it fare in production? I've got a tiny app with two containers (a frontend an a batch job) - it seems like a decent use case.
  - rcarmo 7y ago
    My website (https://taoofmac.com https://taoofmac.com) is exactly that (web and batch workers) and has been running on it for almost 3 years now, but bear in mind that it does not use containers - it merely deploys relatively isolated services in virtualenvs (or equivalent). Since I use CloudFlare (hi jgrahamc!), it's been peachy.
surbas 7y ago
Kubernetes is basically a way to run a Java-like application server that can run things other than Java. If that sounds like an appealing prospect to you, the complexity of Kubernetes may be a good fit. I do not agree with your assessment of Kubernetes. It is not equivalent to something like WildFly or TomEE. Kubernetes runs/manages application servers (and not just java once), along with a whole host of other things devops things at Scale... Kubernetes is great for setting up a blog, and the 11 other applications the author is trying to run.
shanemhansen 7y ago
The best way I can desct K8s is language agnostic J2EE.
dkhenry 7y ago
Kubernetes is the new Java Application Server for people who didn't realize that Java Applicaiton Servers were a terrible idea. Despite a long track record of failure individuals are trying to introduce the complexity of J2EE onto kubernetes. It doesn't need to be that way. Kubernetes can be very simple and it has been up until recently. Once the Enterprise Architects got their hands on it and decided everything needs to be a plugin and nothing should work out of the box the complexity started to creep up. You should be able to run your small blog on kubernetes without requiring a team of consultants to set it up or manage it. Just waving your hands and saying well it needs to be complex to scale is a total lie.
- meowface 7y ago
  Odds are someone / some people will create some kind of simpler solution with an easy default setup within the next ~5 years. Maybe as a wrapper over Kubernetes, or maybe as something new and interoperable with it. Maybe it'll involve a bunch of "serverless" buzzwords or some newly invented buzzwords. That's how things usually go historically. A lot of value can still be extracted if you're careful to ignore the cult-y bits. Containers, serverless/FaaS, and Kubernetes can be pretty great if you're the plane pilot dropping the cargo on the island rather than the cult living on it, and future stuff will probably be even better.
  - wayoutthere 7y ago
    Oh they have and are; but what is the business case open source such a wrapper? Wouldn’t you just host it on your own hardware and basically be another Heroku? This kind of software is complex enough it would take corporate backing (either an industry group or VC backing) so it’s probably not getting built unless there’s a business case. Even Google only released K8s because they thought it would push people towards GCP — which it didn’t because it was too easy for AWS to implement a similar service using Google’s open source tech. The open source freemium model for infrastructure tech is pretty much dead as a result of this kind of activity.
    - meowface 7y ago
AlphaSite 7y ago
I’m not sure I agree. K8s’ primary benefit is that it strings together the IAAS abstraction into a single api. It allows you to deploy multiple replicas, automatically setup a load balancer and handles maintaining the link between the LB and the backend. While also replacing any failed replicas.
auvrw 7y ago
> this isn’t what Kubernetes is really for. i'm guessing that writing dyson in Nim is a tacit acknowledgement of that: if this were something geared toward production ecosystems, it would be in golang like kubernetes? although there is the helm luafication, so perhaps dyson is part of a fringe of non-golang k8s auxilliaries. another way to implement this is with a 'static CMS' where there are still static pages except built into a situated deploy. the 'cultish' (cultic? anyway) aspect of k8s appears to be to phrase all the things in terms of k8s constructs rather than using k8s constructs as a foundation and abstracting out. i learned about 'rollout' from the CI portion of this post, although initial attempts to search for a comprehensible description of it fail.
- xena 7y ago
  Honestly dyson is just something I wrote for myself to see how difficult it would be to write. I don't expect anyone else to use it. The tool is also a punny name, because you'd need to terraform a dyson sphere before you(r apps) can live in it. I just wanted something with easy templating syntax like this: https://github.com/Xe/within-terraform/blob/master/dyson/src/dysonPkg/deployment_with_ingress.yaml https://github.com/Xe/within-terraform/blob/master/dyson/src... The fact that cligen (https://github.com/c-blake/cligen https://github.com/c-blake/cligen) exists too makes it super easy for me to define subcommands of the thing: https://github.com/Xe/within-terraform/blob/master/dyson/src/dyson.nim#L127-L128 https://github.com/Xe/within-terraform/blob/master/dyson/src...
asdfman123 7y ago
The main problem is that smaller shops are adopting the fads of very large tech companies, but the large tech companies usually adopted those tools to deal with the kinds of scale that the smaller shops just don't have.
gerbilly 7y ago
Kubernetes is WebSphere reinvented then, along with all the management complexity and the expensive consultants? Great analogy.
tolmasky 7y ago
Context is always key with these kinds of reactions. Few people feel that hex editors are unnecessary, they probably don't know they exist. The reason you see this sort of thing with Kubernetes is that for whatever reason its hype over-extends its problem domain and many times people who do not need them receive the suggestion (or insistence) to use them. If someone were to tell you to use a hex editor to edit your JavaScript, you might very well reach the conclusion that hex editors are a cult, and useless. Someone might then point out that there are actual completely justified use cases for them. That's what I see happening here: whether it be indirect (tons and tons of blog posts and articles about moving to Kubernetes), or direct (an employee insisting that the company's infrastructure be moved to Kubernetes), or a mix (starting to see Kubernetes experience as a requirement for jobs that probably doesn't need it), all of a sudden you have the backlash against the perceived "Kubernetes for everything" culture (which in turn looks like a weird straw man to people who actually know what its for).

arethuza 7y ago

Where would you draw the dividing line between where you think it does make sense to use something like Kubernetes and where it doesn't?

wayoutthere 7y ago
There isn’t a dividing line per se; every operating model is going to have different breakpoints. In general though, I would consider Kubernetes an “enterprise technology”. If you’re a startup you’re going to be better off paying AWS/Heroku for one of their more managed services than hiring someone to build / manage a Kubernetes cluster.
- falcolas 7y ago
  A note on this - AWS (or any other host's) managed k8s will not reduce the need to understand what's going on under the hood. It's still k8s, you're just not running the daemons to make it work (which is, arguably, the easy part).
bryanlarsen 7y ago
You've signed an > 99.9% availability SLA with a customer and a service like Elastic Beanstalk or Heroku isn't sufficient for your needs.
- falcolas 7y ago
  Technically, the cloud in general probably isn't for you, since none of them guarantee more than 3x9's on any of their services.
  - bryanlarsen 7y ago
    Yup, meant to say >= 99.9%. Of course most businesses operate more like what Cloudflare makes explicit with it's "100%" SLA. Architect for 3 nines and then just pay the penalty when the 3 nines architecture doesn't hit 4 nines.
cies 7y ago
If you need your workload to span over an (possibly growing) number of server hardwares, you may want to use k8s. There are other options that are good contenders in case of such a workload.
xemdetia 7y ago
I'm starting to feel that the whether or not you need Kubernetes is closer to old conversations related to whether or not you need a dedicated DBA. Can your organization survive and recover with hourly/nightly backup restores to recover from an incident? Is your replication so complex that you really need a guy to ensure that's never getting into a bad state? Worse case scenario can most people working on the project restore the database to a valid state if something does go wrong? I feel like these questions have similar representatives in whether or not Kubernetes is right for an organization. Kubernetes also makes more sense if you look at it as a common way for an organization to run applications among disparate teams with a shared operations infrastructure. It provides a standardized model for things to work the same enough to work the same. If you are only delivering one kind/whole organization thing and it all looks and quacks like a duck maybe you should just deliver a duck instead of putting a duck hat on Kubernetes and asking it to quack. I don't think there is anything wrong with designing an application that would transition easily into Kubernetes but I feel like many of the proposals/PoC I have seen in the last few years are either fresh systems that get consumed by Kubernetes complexity or are poor replacements to systems that already exist and only seem to serve as resume padders for the team architecting the replacement which gets a viking funeral as soon as they leave. Often the latter case is because the underlying architecture and goal of the system is pre-Kubernetes and doesn't fit the model well of having mostly stateless/replaceable pieces.
moduspol 7y ago
Kind of implicit in the other responses here are use cases that call for a full cluster and all the complexity that goes along with it. But running a single node cluster is totally valid. I use one at home to run arbitrary containers (a DNS-over-TLS proxy, VPN server, radius server, network AP / switch manager, etc.). I don't use load balancers and just use host-based persistent storage, which removes the vast majority of the complexity. I've seen a lot of people get wrapped up in the complexity of wanting to be able to have a persist storage-backed process go down on one node and come back up on another, and that's not unreasonable, but that's a lot of stuff to figure out early on. If I weren't using this as a single node k8s instance, I might use it to manage VMs, which might be easier to understand but much heavier and more work to maintain. With what I have now, I've got a folder of YAMLs that defines everything to run on my node, and I'm able to easily put all their persistent data in the same top-level dir for easy backup. I think the perception of k8s might change over time once people realize that it provides a lot of value even if you completely rule out the tougher stuff to do on bare metal (like load balancers and shared persistent volumes).

grenoire 7y ago

Completely valid points, and I agree to all of them. Alas, as other commenters have pointed out, the issue is devs at smaller companies deploying smaller products buying into the idea that they need k8s. I believe that it is the community's duty to educate these devs on what k8s is and when it is needed.

gambler 7y ago
They are probably scared that when they need to change jobs, the next company will require "5 years of Kubernetes experience". So they convince everyone at their current company to jump into a complexity clusterfuck to see how it works "in production" and can put it on their resume. This is how the entire IT industry works today. I am fucking appalled writing config files is a noteworthy skill is 2019. So should you.
- cameronbrown 7y ago
  K8S is hardly just "writing config files" is it? You've still got to understand a ton of moving parts underneath before you're able to.
  - falcolas 7y ago
    K8s is writing config files just like Python is writing Python Syntax. If you don't understand the underlying mechanism, either with Python or K8s yaml files, you're going to have a very bad time. Somewhat ironic side note - Asking folks to write K8s config files is exposing too much complexity for some developers I work with. And I kind of get it. Properly setting up a service with changing environment variables, secrets, ingress, API Roles, AWS IAM roles, and horizontal autoscaling can get a bit nuts.
    - wayoutthere 7y ago
      Yeah, fully integrated “DevOps” at scale is a pipe dream. You will always have some segregation of dev and ops because the scope of knowledge is so different, especially today where “Ops” often means “expert in XXX cloud vendor’s product portfolio and how our operating model uses the features”. What we call “DevOps” is really a delicate balance of giving the dev teams enough rope to hang themselves while child-proofing the gallows.

zemo 7y ago

> complaining that running a blog on Kubernetes is too complex think you're really missing the point here. Why do you think this was included in the post? https://twitter.com/dexhorthy/status/856639005462417409 https://twitter.com/dexhorthy/status/856639005462417409

wayoutthere 7y ago
Oh I get the author’s point, but her use case was “basically a Heroku replacement for easy deployment”. It’s just the wrong use case for Kubernetes and it is well known that deploying to Kubernetes is a bit of a nightmare.
- parasubvert 7y ago
  Except Kubernetes has sucked all the oxygen up in the industry and has had a subset of adherents that trash the alternatives such as Heroku, Cloud Foundry, etc. As such, people do expect it to replace Heroku.
  - root_axis 7y ago
    Anyone who suggests k8s as an alternative to Heroku is wrong. Heroku is a product that manages infrastructure so that the programmer doesn't have to, k8s is a solution for operational engineers that want a code-driven approach to managing their own infrastructure. Suggesting k8s as a replacement for Heroku is like suggesting docker as a replacement for EC2.
    - parasubvert 7y ago
      And yet, they both fight for the same budget. They're absolutely alternatives in that sense. Not necessarily the right tool for the job, but alas, that's not stopped the wave. And eventually, even Heroku will be based on K8s, as they see the writing on the wall. Also note that most adherents view K8s as a replacement (more accurately new API) that replaces EC2. the fundamental unit of computing becomes the Pod, not a VM.
- 7y ago

rcarmo 7y ago

Well, maybe it isn't _only_ what it's for, but I have thought of doing largely the same and "bundle" a bunch of assorted projects onto a single 3-node cluster, including my blog. The only thing that's really prevented me from doing so is that I have my own micro-PaaS (https://github.com/piku https://github.com/piku) that makes it trivial to run a bunch of different apps/services on the same VPS, and the added complexity isn't really necessary. But since I deal with k8s practically every day at customers, attrition might be compensated by not having to switch tooling. YMMV within this sort of scope.

wayoutthere 7y ago
I mean, that’s kind of my point. It’s just not designed for that use case. Someone could build a simplified fork / derivative of Kubernetes designed for this purpose. That would be pretty rad actually, but it would cease to be Kubernetes because the complexity is the point.
- rcarmo 7y ago
  k3s.io is great, and I use that as well - is to be what I will eventually run in "production" for my personal stuff.
- wikibob 7y ago
  k3s? https://k3s.io https://k3s.io
cameronbrown 7y ago
> The only thing that's really prevented me from doing so is that I have my own micro-PaaS (https://github.com/piku https://github.com/piku) that makes it trivial to run a bunch of different apps/services on the same VPS, and the added complexity isn't really necessary. How does it fare in production? I've got a tiny app with two containers (a frontend an a batch job) - it seems like a decent use case.
- rcarmo 7y ago
  My website (https://taoofmac.com https://taoofmac.com) is exactly that (web and batch workers) and has been running on it for almost 3 years now, but bear in mind that it does not use containers - it merely deploys relatively isolated services in virtualenvs (or equivalent). Since I use CloudFlare (hi jgrahamc!), it's been peachy.

surbas 7y ago

Kubernetes is basically a way to run a Java-like application server that can run things other than Java. If that sounds like an appealing prospect to you, the complexity of Kubernetes may be a good fit. I do not agree with your assessment of Kubernetes. It is not equivalent to something like WildFly or TomEE. Kubernetes runs/manages application servers (and not just java once), along with a whole host of other things devops things at Scale... Kubernetes is great for setting up a blog, and the 11 other applications the author is trying to run.

shanemhansen 7y ago

The best way I can desct K8s is language agnostic J2EE.

dkhenry 7y ago

Kubernetes is the new Java Application Server for people who didn't realize that Java Applicaiton Servers were a terrible idea. Despite a long track record of failure individuals are trying to introduce the complexity of J2EE onto kubernetes. It doesn't need to be that way. Kubernetes can be very simple and it has been up until recently. Once the Enterprise Architects got their hands on it and decided everything needs to be a plugin and nothing should work out of the box the complexity started to creep up. You should be able to run your small blog on kubernetes without requiring a team of consultants to set it up or manage it. Just waving your hands and saying well it needs to be complex to scale is a total lie.

meowface 7y ago
Odds are someone / some people will create some kind of simpler solution with an easy default setup within the next ~5 years. Maybe as a wrapper over Kubernetes, or maybe as something new and interoperable with it. Maybe it'll involve a bunch of "serverless" buzzwords or some newly invented buzzwords. That's how things usually go historically. A lot of value can still be extracted if you're careful to ignore the cult-y bits. Containers, serverless/FaaS, and Kubernetes can be pretty great if you're the plane pilot dropping the cargo on the island rather than the cult living on it, and future stuff will probably be even better.
- wayoutthere 7y ago
  Oh they have and are; but what is the business case open source such a wrapper? Wouldn’t you just host it on your own hardware and basically be another Heroku? This kind of software is complex enough it would take corporate backing (either an industry group or VC backing) so it’s probably not getting built unless there’s a business case. Even Google only released K8s because they thought it would push people towards GCP — which it didn’t because it was too easy for AWS to implement a similar service using Google’s open source tech. The open source freemium model for infrastructure tech is pretty much dead as a result of this kind of activity.
  - meowface 7y ago

AlphaSite 7y ago

I’m not sure I agree. K8s’ primary benefit is that it strings together the IAAS abstraction into a single api. It allows you to deploy multiple replicas, automatically setup a load balancer and handles maintaining the link between the LB and the backend. While also replacing any failed replicas.

auvrw 7y ago

> this isn’t what Kubernetes is really for. i'm guessing that writing dyson in Nim is a tacit acknowledgement of that: if this were something geared toward production ecosystems, it would be in golang like kubernetes? although there is the helm luafication, so perhaps dyson is part of a fringe of non-golang k8s auxilliaries. another way to implement this is with a 'static CMS' where there are still static pages except built into a situated deploy. the 'cultish' (cultic? anyway) aspect of k8s appears to be to phrase all the things in terms of k8s constructs rather than using k8s constructs as a foundation and abstracting out. i learned about 'rollout' from the CI portion of this post, although initial attempts to search for a comprehensible description of it fail.

xena 7y ago
Honestly dyson is just something I wrote for myself to see how difficult it would be to write. I don't expect anyone else to use it. The tool is also a punny name, because you'd need to terraform a dyson sphere before you(r apps) can live in it. I just wanted something with easy templating syntax like this: https://github.com/Xe/within-terraform/blob/master/dyson/src/dysonPkg/deployment_with_ingress.yaml https://github.com/Xe/within-terraform/blob/master/dyson/src... The fact that cligen (https://github.com/c-blake/cligen https://github.com/c-blake/cligen) exists too makes it super easy for me to define subcommands of the thing: https://github.com/Xe/within-terraform/blob/master/dyson/src/dyson.nim#L127-L128 https://github.com/Xe/within-terraform/blob/master/dyson/src...

asdfman123 7y ago

The main problem is that smaller shops are adopting the fads of very large tech companies, but the large tech companies usually adopted those tools to deal with the kinds of scale that the smaller shops just don't have.

gerbilly 7y ago

Kubernetes is WebSphere reinvented then, along with all the management complexity and the expensive consultants? Great analogy.

tolmasky 7y ago

Context is always key with these kinds of reactions. Few people feel that hex editors are unnecessary, they probably don't know they exist. The reason you see this sort of thing with Kubernetes is that for whatever reason its hype over-extends its problem domain and many times people who do not need them receive the suggestion (or insistence) to use them. If someone were to tell you to use a hex editor to edit your JavaScript, you might very well reach the conclusion that hex editors are a cult, and useless. Someone might then point out that there are actual completely justified use cases for them. That's what I see happening here: whether it be indirect (tons and tons of blog posts and articles about moving to Kubernetes), or direct (an employee insisting that the company's infrastructure be moved to Kubernetes), or a mix (starting to see Kubernetes experience as a requirement for jobs that probably doesn't need it), all of a sudden you have the backlash against the perceived "Kubernetes for everything" culture (which in turn looks like a weird straw man to people who actually know what its for).