5 ms·

How the heck did we get here as an industry. The complexity is ridiculous.

cobookman 8y ago
Reminds me of the JavaScript craze of 2010-2015. With a new framework each week on HN. Give it time it'll mature and people will be burnt out from all the changes
- hinkley 8y ago
  It’ll be something else then. We can’t tell motion from progress so we just keep moving and moving.
drdaeman 8y ago
Not just complexity, but quantity of tools that do the same thing. Helm, Forge, Ksonnet, Operators, now this Skaffold (haven't heard of it before)... Sure, there are some differences, but still... I'm currently moving one app from GAE to GKE and saw recipes for using all of those to describe the infrastructure. Quantity itself is not an issue - it's great to have options. Incompatibility, segmentation and uncertainity about the future are issues, though. E.g. ksonnet and Forge are dying. Some say Helm isn't particularly healthy, too - is it just speculations or would it die in next year or two, leaving all those charts repos a dead code for archeologists? Maybe that's just me, but modern DevOps feels like JavaScript world from a few years ago. Things are born in abundance, promise lots, and die before they're even v1.0.
- _bxg1 8y ago
  https://xkcd.com/927/ https://xkcd.com/927/
- gtaylor 8y ago
  I have the opposite impression of Helm. I'm seeing vendors and other companies cranking out and sharing Charts at a rate I've never seen before. There are some review issues in the main upstream Helm Chart repo, but that's due to volume (which is now higher than ever).
  - drdaeman 8y ago
    While true, I also read about Helm v3 (that's said to be something different) and that maybe Helm is not the way to go but CRDs and Operators are... Well, at the very least, my point was - it's all confusing.
    - geerlingguy 8y ago
      Helm is fun for demoing complex things the first time, but in production use, it’s a mixed bag. Lots of great alternatives that feel more ‘clean’ to me.
      - dayglo 8y ago
        What are the cleaner alternatives?
        ksajadi 8y ago
        Cloud 66 Skycap is a good alternative without most of the issues of Helm
        dayglo 8y ago
        This seems like a full-fat Build and Release management hosted solution (good job by the way, this looks great and I'll try it out). I was more specifically asking Jeff which similar tools are cleaner, and why? Are there any helm drop-in replacements that anyone would recommend? Or is it really a shift to other ways of deploying, like these hosted solutions, or is everyone building their own k8s operators now...? Or something else?
        ksajadi 8y ago
        Fair points and questions. I think most of the past couple of years was spent on making Kubernetes operation friendly. Now everyone has a managed k8s service so there are many solutions coming up to deal with their issues in “Day 2” like deployments or secret management
- arianvanp 8y ago
  I count more than 63 different ways to do scaffolding. I started keeping track because I wanted to write a comparison for my 64th solution, but never did because there are more than 64 competing products on this space By some people from k8s: https://docs.google.com/spreadsheets/d/1FCgqz1Ci7_VCz_wdh8vBitZ3giBtac_H8SBw4uxnrsE/edit#gid=0 https://docs.google.com/spreadsheets/d/1FCgqz1Ci7_VCz_wdh8vB... By me: https://github.com/dhall-lang/dhall-kubernetes/issues/10 https://github.com/dhall-lang/dhall-kubernetes/issues/10
- bpicolo 8y ago
  Pretty much all of these tools feel like the wrong abstraction level for app devs. Have to imagine some k8s-controller/git server that enables git deployments to k8s with just a node size config is the optimal end state. I’ve mentioned this before in related threads: app devs want heroku. They want a managed platform where they type “git push” and they have an application with all the fixings. Heroku got the UX right long ago, and the rest of the ecosystem is still playing catchup
  - drdaeman 8y ago
    Problem there is, this isn't easy and K8s doesn't do anything about that. You need a whole CI/CD pipeline to build Docker images first. However, there is https://gitkube.sh/ https://gitkube.sh/ that looks somewhat similar. Can't vouch for or against - haven't used it at all.
zebraflask 8y ago
This would be a fantastic way to expand headcount. Of course any team supporting this many languages and services will need at least one person for each, and then a few extra to coordinate the chaos, and then a few more to clean up the damage from the previous few. Only being slightly tongue-in-cheek.
eudora 8y ago
But microservices!
paxys 8y ago
When were things not this complex? Did Google or Yahoo run out of some dude's laptop back in the day? Things are simpler now, not more complex. The tools are better, more standardized, and way more broadly available. It's up to you whether you need or want them or not.
- sitkack 8y ago
  I am not sure that is true. I ran fleets of FreeBSD machines 20 years ago and we dd'd disks to spin up new hosts, PXE booted some, local and remote (NFS) storage. Even in the 90s, machines were cattle. The pieces are largely the same, but in a lot of ways, the tooling has _enabled_ more complexity than is necessary. Things have become specialized in incongruent ways that makes things harder. Simplicity is a constant struggle and a quality all of its own. Sometimes you have it by accident, where it then occupies the unknown known quadrant.
  - paxys 8y ago
    > I ran fleets of FreeBSD machines 20 years ago and we dd'd disks to spin up new hosts, PXE booted some, local and remote (NFS) storage To me all of this sounds like crazy complexity vs a basic Kubernetes cluster. It all depends on what you are comfortable with I guess.
- apta 8y ago
  > Did Google or Yahoo run out of some dude's laptop back in the day? https://www.independent.co.uk/life-style/gadgets-and-tech/33-photos-of-googles-rise-from-a-stanford-dorm-room-to-world-domination-a7354501.html https://www.independent.co.uk/life-style/gadgets-and-tech/33... Didn't Facebook also start in Harvard's dorms?
joesb 8y ago
It's the same with how people think the pasts didn't have as much crimes. It's because you didn't knew about it. All companies had their own way of hacking and making their system worked. But they didn't share it. Twenty years agoes, what big company shares their infrastructure knowledges as open sources? Now things are being shared and learned together.
MrTonyD 8y ago
As someone who was writing analysis for my CEO when we were involved with the POSIX definition, let me say that POSIX was driven by the complaints of users, who insisted that they would stop buying product if the vendors didn't stop the arbitrary fragmentation. So POSIX was forced on vendors who then had to identify areas with mature features to standardize - so that every UNIX admin and UNIX programmer wasn't using a completely different environment. We need to do the same for Linux, the same for Kubernetes, and the same for any mature technology. The vendors are striving for lock-in, and we need to fight it.
- dankohn1 8y ago
  For Kubernetes, please see the CNCF's Certified Kubernetes program: https://www.cncf.io/certification/software-conformance/ https://www.cncf.io/certification/software-conformance/ (Disclosure: I run it.)

Reminds me of the JavaScript craze of 2010-2015. With a new framework each week on HN. Give it time it'll mature and people will be burnt out from all the changes

hinkley 8y ago
It’ll be something else then. We can’t tell motion from progress so we just keep moving and moving.

drdaeman 8y ago

Not just complexity, but quantity of tools that do the same thing. Helm, Forge, Ksonnet, Operators, now this Skaffold (haven't heard of it before)... Sure, there are some differences, but still... I'm currently moving one app from GAE to GKE and saw recipes for using all of those to describe the infrastructure. Quantity itself is not an issue - it's great to have options. Incompatibility, segmentation and uncertainity about the future are issues, though. E.g. ksonnet and Forge are dying. Some say Helm isn't particularly healthy, too - is it just speculations or would it die in next year or two, leaving all those charts repos a dead code for archeologists? Maybe that's just me, but modern DevOps feels like JavaScript world from a few years ago. Things are born in abundance, promise lots, and die before they're even v1.0.

_bxg1 8y ago
https://xkcd.com/927/ https://xkcd.com/927/
gtaylor 8y ago
I have the opposite impression of Helm. I'm seeing vendors and other companies cranking out and sharing Charts at a rate I've never seen before. There are some review issues in the main upstream Helm Chart repo, but that's due to volume (which is now higher than ever).
- drdaeman 8y ago
  While true, I also read about Helm v3 (that's said to be something different) and that maybe Helm is not the way to go but CRDs and Operators are... Well, at the very least, my point was - it's all confusing.
  - geerlingguy 8y ago
    Helm is fun for demoing complex things the first time, but in production use, it’s a mixed bag. Lots of great alternatives that feel more ‘clean’ to me.
    - dayglo 8y ago
      What are the cleaner alternatives?
      - ksajadi 8y ago
        Cloud 66 Skycap is a good alternative without most of the issues of Helm
        dayglo 8y ago
        This seems like a full-fat Build and Release management hosted solution (good job by the way, this looks great and I'll try it out). I was more specifically asking Jeff which similar tools are cleaner, and why? Are there any helm drop-in replacements that anyone would recommend? Or is it really a shift to other ways of deploying, like these hosted solutions, or is everyone building their own k8s operators now...? Or something else?
        ksajadi 8y ago
        Fair points and questions. I think most of the past couple of years was spent on making Kubernetes operation friendly. Now everyone has a managed k8s service so there are many solutions coming up to deal with their issues in “Day 2” like deployments or secret management
arianvanp 8y ago
I count more than 63 different ways to do scaffolding. I started keeping track because I wanted to write a comparison for my 64th solution, but never did because there are more than 64 competing products on this space By some people from k8s: https://docs.google.com/spreadsheets/d/1FCgqz1Ci7_VCz_wdh8vBitZ3giBtac_H8SBw4uxnrsE/edit#gid=0 https://docs.google.com/spreadsheets/d/1FCgqz1Ci7_VCz_wdh8vB... By me: https://github.com/dhall-lang/dhall-kubernetes/issues/10 https://github.com/dhall-lang/dhall-kubernetes/issues/10
bpicolo 8y ago
Pretty much all of these tools feel like the wrong abstraction level for app devs. Have to imagine some k8s-controller/git server that enables git deployments to k8s with just a node size config is the optimal end state. I’ve mentioned this before in related threads: app devs want heroku. They want a managed platform where they type “git push” and they have an application with all the fixings. Heroku got the UX right long ago, and the rest of the ecosystem is still playing catchup
- drdaeman 8y ago
  Problem there is, this isn't easy and K8s doesn't do anything about that. You need a whole CI/CD pipeline to build Docker images first. However, there is https://gitkube.sh/ https://gitkube.sh/ that looks somewhat similar. Can't vouch for or against - haven't used it at all.

zebraflask 8y ago

This would be a fantastic way to expand headcount. Of course any team supporting this many languages and services will need at least one person for each, and then a few extra to coordinate the chaos, and then a few more to clean up the damage from the previous few. Only being slightly tongue-in-cheek.

eudora 8y ago

But microservices!

paxys 8y ago

When were things not this complex? Did Google or Yahoo run out of some dude's laptop back in the day? Things are simpler now, not more complex. The tools are better, more standardized, and way more broadly available. It's up to you whether you need or want them or not.

sitkack 8y ago
I am not sure that is true. I ran fleets of FreeBSD machines 20 years ago and we dd'd disks to spin up new hosts, PXE booted some, local and remote (NFS) storage. Even in the 90s, machines were cattle. The pieces are largely the same, but in a lot of ways, the tooling has _enabled_ more complexity than is necessary. Things have become specialized in incongruent ways that makes things harder. Simplicity is a constant struggle and a quality all of its own. Sometimes you have it by accident, where it then occupies the unknown known quadrant.
- paxys 8y ago
  > I ran fleets of FreeBSD machines 20 years ago and we dd'd disks to spin up new hosts, PXE booted some, local and remote (NFS) storage To me all of this sounds like crazy complexity vs a basic Kubernetes cluster. It all depends on what you are comfortable with I guess.
apta 8y ago
> Did Google or Yahoo run out of some dude's laptop back in the day? https://www.independent.co.uk/life-style/gadgets-and-tech/33-photos-of-googles-rise-from-a-stanford-dorm-room-to-world-domination-a7354501.html https://www.independent.co.uk/life-style/gadgets-and-tech/33... Didn't Facebook also start in Harvard's dorms?

joesb 8y ago

It's the same with how people think the pasts didn't have as much crimes. It's because you didn't knew about it. All companies had their own way of hacking and making their system worked. But they didn't share it. Twenty years agoes, what big company shares their infrastructure knowledges as open sources? Now things are being shared and learned together.

MrTonyD 8y ago

As someone who was writing analysis for my CEO when we were involved with the POSIX definition, let me say that POSIX was driven by the complaints of users, who insisted that they would stop buying product if the vendors didn't stop the arbitrary fragmentation. So POSIX was forced on vendors who then had to identify areas with mature features to standardize - so that every UNIX admin and UNIX programmer wasn't using a completely different environment. We need to do the same for Linux, the same for Kubernetes, and the same for any mature technology. The vendors are striving for lock-in, and we need to fight it.

dankohn1 8y ago
For Kubernetes, please see the CNCF's Certified Kubernetes program: https://www.cncf.io/certification/software-conformance/ https://www.cncf.io/certification/software-conformance/ (Disclosure: I run it.)