You could just as easily level similar rants against the likes of React and it's wider ecosystem, Tensorflow, Typescript (many will disagree), Docker... I'm sure others have their own bugbears.

Much of this is subjective, of course. But to me, it feels like software development is trending towards unecessarily complicated development processes and architectures.

And the only beneficiaries appear to be the large technology companies.

I suppose in exchange, you're getting a guarantee of maintenance. But is that really worth the additional complexity associated with the common use of these tools?

JavaScript taught me to love async, then functional programming, and TypeScript taught to me to love static types. I'm now desperately wishing for a world of OCaml/Haskell, but where are you going to find teammates using those? And so I'm back at TypeScript.

I think all of these "higher order" languages that do transpiling (including Scala, Closure, Kotlin, Groovy, etc) fit this same scenario. Increased toolchain complexity for a decrease in development/test/maintenance complexity.

With any toolchain, though, it can be hard to know where to draw the line for "worth it for this project" until you're already an expert in using the toolchain, at which point, why wouldn't you use it?

The argument for simpler tool chains for simpler projects is that the time it takes to on-board should not outweigh the time saved by the toolchain’s amenities.

So the argument for TypeScript despite its complexities is that you believe its approach to type decorations on top of JS strikes the right balance for ease of on-boarding (IMO fairly straightforward) and supporting code maintainability (IMO a big improvement in 99% of the cases) despite the extra complexity of lengthening the toolchain (IMO it has some counterintuitive parts but you can mostly just forget about it once you find a working setup.)

I won’t use TypeScript if I’m whipping something up quickly, but if I anticipate open sourcing, adding unit tests and CI, etc., then TypeScript feels like a useful addition.

Unless you have to work with legacy code or libraries.

But seriously, if modern C++ has one thing going for it, it has a great backwards compatibility and forward refactoring story.

I'm not a huge fan of the "evolved" syntax, and I rarely use C++ anymore, but I like modern C++ substantially more than C++03, which was where I first cut my teeth as a programmer.

This isn't always an option. Google's C++ guidelines generally forbid using exceptions, but concede that you might have to if you're dealing with existing code, particularly on Windows.

https://google.github.io/styleguide/cppguide.html#Windows_Co...

I've written >50k LoC of TS in last few months for sure (doing a huge frontend migration for a client) and I can't remember the last time I googled anything TS related. Actually I remember - a month ago I wanted to know how to define a type with a field excluded, took 30 seconds of google.

Meanwhile the project started out as mixed TS and ES6 because most of the team was unfamiliar with it and there are a few dynamic typing evangelists - we ended up going back and just using TS all over the place, the complexity introduced is minimal and the productivity boost from good tooling on product of this scale is insane.

Which is why you use the up-to-date official documentation.

``` function partialCall<T extends Arr, U extends Arr, R>(f: (...args: [...T, ...U]) => R, ...headArgs: T) {

`

I’ve seen some JavaScript written so tersely it was nearly impossible to figure out without spending Possibly hours on unwrapping the code. That’s the value provided here.

Implementation approximate, but otherwise true story, both LHS and RHS:

`let { statefulMutatingAccessor } = require(obj["prop."+tree+".subtree"])`

But I love strong type systems; people who prefer weak type systems would likely consider things like this to get in their way.

> partialCall takes a function along with the initial few arguments that that function expects. It then returns a new function that takes any other arguments the function needs, and calls them together.

The type signature looks like:

  type Arr = readonly unknown[];
  
  function partialCall<T extends Arr, U extends Arr, R>(f: (...args: [...T, ...U]) => R, ...headArgs: T) {

Now, looking at it piece by piece:

  function partialCall

  <T extends Arr, U extends Arr, R>

This function's first parameter is:

  f: (...args: [...T, ...U]) => R

The `...` in `...args` makes it a rest parameter[1] (variadic parameter in other languages). The type of `...args` is `[...T, ...U]`, which you can think of as the concatenation of the T and U arrays. (It's a bit strange to see `...` in a type specifier, I can't recall having needed this before.)

  ...headArgs: T

I don't know if I'd call this normal or clear compared to the signatures I encounter daily, but it's pretty elegant for a higher-order function that takes a function with any signature, and some arguments that match the given function's parameters, and returns a function with the matched parameters removed. And the implementation of partialCall is just this one line!

  return (...b: U) => f(...headArgs, ...b)

[1]: https://www.typescriptlang.org/docs/handbook/functions.html#...

That said, the type system has come a very long way even in just the last year. The biggest improvements imho being around recursive types (which was one of the biggest holes for a long time imo), literal types / literal type inference, and tuple types.

It's not complete by any means, but it's improving quite rapidly.

I would assume even Array<T> is still bivariant as well...

Both of those are horribly unsound, just for convenience. Sure convenience and compatibility are Typescript's ultimate goals, but to actually praise it for its generics? That's very strange.

> TypeScript absolutely does allow you to express these relationships

How would you express a class with covariant or contravariant type params in Typescript?

[1] https://www.typescriptlang.org/docs/handbook/type-compatibil...

The same thing in TS adds at least one step (not to mention the rest of the tooling you will want)

So while a prefer it over JS, there's no arguing that it is more complex as now you require a build step for a language that only exist because people wanted a language without a build step.

It’s native typescript.

A lot of fortune 500 companies with some developers who missed the trendy stuff still do it that way. I made a medium size website (30 pages) in React with pure javascript and dependencies being script tags in index.html to vendored files.

So not even JSX. I did it that way because it was the easiest way to develop and deploy in that environment

<script type="module">

``` #!/use/bin/env node

console.log("hello cli") ```

While it does depend on node, and there are arguably better crossplatform languages for this purpose, it is a zero-tool chain use case that is very convenient for us.

And the group mentioned is (I deduce) not generally individual devs, enterprise devs building some internal thing, and so on but teams in companies doing public-facing SaaS, teams in startups, companies like Amazon/Google/Facebook/Apple all the way to AirBnB etc, and so on.

So, you don't really need stats for that.

But then if that's an option, I think Typescript will be the last language I migrate to, because Typescript development culture, tending as it does towards overcomplicated solutions to simple problems, is unpalatable to me.

I'm drawn to the idea of using Rust over WASM as a frontend language, and I think I'd rather choose that approach to develop any browser UI where type safety is critical, provided there is no discernable difference in performance (when compared to TS over WASM).

In fact, I wonder how ECMAScript will fare in a post WASM world... I suspect it would still thrive tbh. Or perhaps people will take to other flexible, expressive languages for UI development. Like Python's niche in computer graphics, or Lua in games and AI research.

I can still see myself using JS in that future. But not for everything.

One could completely forgo that, and come up with PureScript or Elm. But then one can't beverage most of the existing code.

Same tradeoffs as what Kotlin and Scala make for Java's sake.

Having walked that way I can recommend you to look at F#, and if you aren't a solo developer (or you want to get real regarding jobs and colleagues) make sure you do not have allergy to C# interop.

So complexity (in tools and process) do not necessarily serve the individual developer the way they serve larger organizations.

As with many government related procurement systems, there is so much paranoia about abuse, and desire not to repeat various disasters from the past, that the system has by perceived necessity become complicated.

Of course it makes it frightfully expensive to the degree that few companies can actually throw the resources at it to be able to navigate it. The lack of competition can result in projects costing a large amount of money, and the buyers in the agencies having no real options to look elsewhere.

At an e-government company I worked for, we a service for the state that helped companies navigate the state's procurement system. We created a centralised place for all data to be gathered by the applicant, generating all the forms they needed, and provided a way for the applicant to track the state of their application. It introduced quite a change for the state, dramatically widening the potential pool of companies that could bid for contracts. Also pissed off quite a few of the already entrenched ones :)

HIC was a great company to work for, as was NIC from the limited interactions I had with the larger corporate powers that be. Most websites/services were provided for free to the state / state agencies, instead relying on small fees per transaction on some of the stuff we did, to fund the work that didn't have transactions (I forget the amount, but we're talking something like 50c per transaction).

Being free was a key incentive to getting various agencies to come on-line.

Easy!!! No not actually easy because of all the constraints.

It had to be stowable. So a hard cover was out. It couldn't produce toxic fumes if it caught fire. So most plastics were out. Cloth was a problem because it couldn't get sucked into the intake if someone tried starting the engine without removing the cover.

He designed heavy canvas cover with metal stiffeners. And snaps. And then had to switch to a draw string because the snaps failed at -40F. And tended to get clogged with snow.

Whole thing took him three months.

Then there was the friend at college who worked on a VCR to record gun camera footage. Also a bunch of requirements. Higher video quality. And can't lose lock when the pilot does a hard pullout after firing his munitions. And the total production run? Well exactly how many fighters does the airforce have? Couple of thousand?

I think military tech has a problem that it's trying to keep up with commercial driven tech which operates on a scale that's a 1000 timers larger. Military produces a few thousand artifacts to commercials few million artifacts.

I've seen (and removed) plenty of requirements that were put in the specification just because. Because someone needed X amount of Y technology in their projects for the year. Because it seemed cool. Because other people were doing it. Because they wanted it on their resume. Because. But not because it was appropriate to the project or its purpose.

I'd say the majority of the work I do now is pruning these nonsense "just because" clauses out.

Its entertaining at least. I regularly shake my head in disbelief as I go through a specification and wonder, "who hired these people?" or "Why is the person who hired them still working?"

Fortunately for me I also get to hand these questions back, much like the good uncle who only needs to uncle and not actually parent: "Here, have them back!" I say at the end of the visit.

All is well. Go pleasantly amid the wastes.

The the hammer was waaaaay more than $1000. But that's because the military said "We'll pay you a total sum of X, but to make it easier to fund the project we'll let you break it into n parts and pay X/n per part".

The contractor decided that to make their cashflow smoother, they'd include "manual impulse force generator" as one of the deliverable parts.

The hammer was part of a larger contract that included spare parts and R&D effort linked to those parts. When the spending was reported, the same absolute amount of R&D ($420) was allocated to every item, inflating the apparent price of a $15 hammer to $435. By the same token, the engineering work on more complicated systems (e.g., an engine) was an absolute steal at $420 and since the total amount of R&D spending was fixed, nobody really got ripped off.

Those tend to be an accounting artifact, I heard. If you order a thousand different items for a million dollars total then each one of them will show up as costing exactly $1000 no matter what they are.

Not to excuse military contracting pork and cost padding, but this is a good point that a lot of people seem to miss. There's also the fact a military contract will be for a production run and follow on support.

So they buy a thousand full units and parts/tools to fix and maintain them up front. You can't just go to Autozone and pick up a new tank tread or parts for a jet turbine.

There are aircraft that were designed and created in the 1970s that are still in use today. Sure, many of the components and internal systems have been modified and upgraded, but much of the original design is still there and operating.

>> a military contract will be for a production run and follow on support.

When "follow-on support" has to last for 50 years or more, it makes a big difference.

First flight: 15 April 1952; 68 years ago

Introduction: February 1955

Status: In service

I think React itself is awesome and I've always enjoyed it. While I'm not an expert, it's conceptual foundations and core abstractions felt right, and I do think it makes lots of frontend tasks simpler, especially for non-small projects.

At the same time the frontend ecosystem is a mess, as we all know, and as my CSS skills advance I see more just how much could be done with HTML / CSS / limited use of JS and your classic REST app, that's not a single-page app, and how much complexity might be able to be avoided and thus time saved.

At the same time, I don't think it's just "trendiness" that has caused the growth of React and SPA's. I think they give us various wins that we probably take for granted because we're now used to them.

So, the short answer to my long ramble is, I don't know.

But I do think React itself, specifically, hit a sweet spot in terms of being a powerful yet understandable tool, and still remaining a tool, as opposed to a framework.

Dev A: I need an API to CRUD

Me: But we've been doing CRUD for 30 years without an API this is a small project

Dev A: But I don't know how, its not best practice, my team lead agrees, here is a medium article, get with the times, etc.

Me: Ok so you don't know how to do your job.

Dev B: Here, put the React SPA in a Docker container and run it on some cloud its easy...

Me: But all I need is still CRUD, I dont need to scale it, I dont care if its isolated, it should have been 100 lines of code

Dev B: its not best practice, my team lead agrees, here is a medium article, get with the times, Docker run everywhere, etc.

Me: But what I need to connect it to internal resources and use DNS?

Dev B: load balancer! If only you have an AKS cluster!

Me: We work in a 25 person company that needs some very basic CRUD. It will never scale past one deployment, ever, if it does, dont worry we will pay someone to do it right because we will be swimming in money.

The problem is that people are starting to not know how to do simple things. So you get grumpy admins losing their marbles over the complexity of this BS. Most of the time things could be fixed faster, easier, deployed and managed easier using simple technologies that have been around for 20+ years.

But lets wack it with the Python, Docker, React, NoSQL, GraphDB, K8S hammer because...? Not only that, the juniors don't know multiple technologies anymore they just know X. So sysadmins complain that devops is pushing more roles on them, while I have developers that have written full Node.js sites and dont know that IP or a Port, or TCP, UDP, is...

So basically, same shtick different decade.

Looks at a specification on the desk Yep. We'll keep the first and last page. Everything else is gibberish. Next!

Edit: Looks like a few people disagree. Perhaps they might like to explain why I saved a bunch of companies around 100k in AWS fees just by pruning their server requirements? No? And yes, one of the projects was a simple set of web forms that required 7 servers to run. We pruned it down to 3 and that was just for redundancy and load. That's just one example.

If you disagree state your why.

> I saved a bunch of companies around 100k in AWS fees just by pruning their server requirements. One of the projects was a simple set of web forms that required 7 servers to run. We pruned it down to 3 and that was just for redundancy and load.

EDIT

and if that thing about cutting down the specification really happened, just tell the story – no need to wrap it in a performance piece:

> I've actually had people come to me with specifications so over-engineered that the whole 20-page doc could be simplified down to a single page without loss of functionality!

EDIT 2

and i'm not saying "never use hyperbole"! just don't make it the whole point of your comment :)

Amusingly, they eventually did "scale". They started selling through WalMart in bulk, and accepted their fate as yet another nutritional drink, on the shelves alongside Ensure Plus and Muscle Milk. Their "tech stack" was irrelevant to that.

I remember working on an simple CMS site, amongst other things, for a pretty large company. When we begun the project, we were tasked with re-purposing an overworked Plesk instance to host the site. We eventually managed to do it, but then found the small amount of disk space that was left to us was getting chewed up by logs.

So I reported this to my project manager, suggesting that we procure more HD space. I think I said something about us 'running out of memory on our hard drive'. The PM promised to feed this back to the client... A week later, our PM said that he and the client had resolved the issue. The client will pay for a new server with a stonking 96GB of RAM!!!

That ought fix our 'memory' issue, right!!?

I mean, it also came with a 1TB HD, a second box for redundancy, dev time for migration, and additional dev time for a switch to Journald, or Logrotate, so I wasn't rushing to point out the misunderstanding... Working with the second box over RedHat Pacemaker was all new to us though, and a complete PITA.

But it was also another 'feature' to sell back to the client. They loved the sound of that. A site that couldn't go down... We made it work, but there was absolutely no real technical need for a Pacemaker cluster and 96GB*2 of RAM. It was just a simple CMS backed site.

Occasionally, that's where such complexity comes from. Not the developers themselves, but some loose cannon of a saleperson. That said, these 'sales people' may even be developers themselves. I often think that's a large part of how and why questionably complicated software exists...

I am not aware of why it was chosen to retire that and separate the website into its own service - maybe there was a good reason, so I won't comment on that.

However the approach they (or rather some frontend developer) chose was a React front-end (fair enough) with a Node.js backend that translated between the REST API and GraphQL (WTF).

The existing API was served on the same domain so the new React website could've directly interacted with it without any problems. But no, this guy wanted to put "GraphQL" on his resume and so introduced an unnecessary extra component and potential point of failure that the company now has to support.

The head of the company was pushing to modernize our process flow via software meant to drive manufacturing. We had contractors on site from three different companies who were each using us as a test-bed for their software/manufacturing integration. Every week or two they'd plot out some new data they'd need to move from sales to engineering, manufacturing, QC, etc.

In our case, having GraphQL as a translation layer for the sales website saved everyone involved time. However, I can also see many scenarios where that wouldn't have been the case.

It definitely comes down to using the right tool for the job. Knowing how to identify which tools fit and which don't is one of the skills it's very important to help new devs develop.

I'm a bit confused as to how it's become so popular for normal development when it seems to have a lot more boilerplate and setup than a simple REST API.

Do you really, _really_ need to support queries? 99/100, I'd guess no, and thus constraining people to a more defined interface and access pattern is simpler.

Meanwhile the API returns highly structured data perfect for a RDMS, but we dont know how to query SQL without an API in the frontend. So welcome to my hell.

The former doesn't need explaining but the latter can be explained as developers being concerned about requiring the benefits of GraphQL in some uncertain future and decide to include it from the start, even though in most cases they end up never actually reaping the benefits while still being plagued by the extra overhead of using that technology.

There's a simple solution to this kind of problem: let the resume driven developer use his skills - fire him.

I sympathize with the OP for single developers or small teams (by small, I mean a team of 5 not in a larger corporation), but whenever you have more than a single team, you want to keep system management overhead low. Unifying around a single paradigm like gRPC and Docker containers means that not every team will have their own bespoke chroot configuration and you won't have to retune an HTTP client every time you interface with a new service.

I think there's in general too little representation from small-scale or indie developers. I spend a lot of time working with the Gemini protocol outside of work and I appreciate the simpler approach that the protocol takes. I would love to see these sorts of stakeholders have a say in greater net architecture as well, but let's not pretend like this is all complexity for complexity's sake; this stuff is needed at scale.

Such bullshit. Since when we use UDP for a CRUD service ? Since when SCTP is even considered outside of the telecom world?

HTTP and Rest-like API have been able to handle properly simple CRUD API since 20 years without problems, way before gRPC was even a thing.

gRPC has its usage for large, complex API that required a proper RPC framework. But in 99% of the case, yes it's an overkill.

You're making a strawmam out of this. I'm responding to the following:

"while I have developers that have written full Node.js sites and dont know that IP or a Port, or TCP, UDP, is..."

But thank you for the insult.

> HTTP and Rest-like API have been able to handle properly simple CRUD API since 20 years without problems, way before gRPC was even a thing.

Hm, what are you talking about? Are you talking about the client? Are you talking about a load balancer? I don't think anyone is proposing that a simple static blog use gRPC to serve content to its users.

> But in 99% of the case, yes it's an overkill.

Compared to what? I'd argue that CRUD over HTTP is wrong. In fact, folks have been writing CRUD over TCP for ages. Why do we need to massage CRUD syntax over HTTP when we can just stream requests and responses over TCP? In fact, TCP predates HTTP by 20 years, so if you're using the historical argument, raw TCP is even older. How much bullshit is there around AJAX and Websockets and HTTP multipart and HTTP keep-alive when we're just trying to recreate TCP semantics?

So why are you drawing the line at HTTP? Seems arbitrary to me.

There is the problem. "Twenty years old? How can that be any good" is a common POV in my experience

It's probably acceptable to not learn the details of what you're doing, as hardware is cheap and all that, but it also constitutes a glass ceiling for how much the organization learns. That's a bigger problem in the long run.

I have 100 different devs telling me "do this thing, it's easy" and it's easy for them, but now I have 100 different things to think about and make work together and devs never think about how their tiny thing fits into the big picture.

99% of web apps could be pure HTML + CSS on the front end, and Flask or something on the back end, talking pure SQL to Postgres. Really. That's all you need. And probably 99.99% of those apps that run internally to one company.

It also enables pushback along the lines of "your container doesn't run, and it's 100% your fault, as it is supposed to contain all its dependencies". So developers have unwittingly played into the hands of ops there ;-)

Also if I was gonna complain about someone I wouldn't complain about devs, I'd complain about team leads, engineering managers - the folks who should be guiding devs - and, the people at the business level who choose the team leads / engineering managers.

The devs are at the bottom of the food chain; it's not their fault.

GraphQL is unfortunately still part of a low grade hype cycle where more and more companies are using it because "it's the next REST". But if you don't have a real need for the advantages it offers (for example a mobile app whose client side requests you can't easily change in sync with your API, or a data model that really is graph-like), it can be more cost than benefit.

React on the other hand: I've lost count of the number of small prototypes I've started in vanilla JS, thinking "this time I can just roll it myself", then ended up pulling in React. Even the simplest things are easier and simpler with it, and hugely complex applications are also easier and simpler with it. It has a fantastic API surface.

please note that what's "unnecessary" for you is not necessarily unnecessary for others.

this is an important point.

i guess what these projects need is a way to communicate explicitly the costs of maintenance and developer mind-share when adding more complex features to their product.

Because especially as small dev team it is difficult to figure out these costs during a short evaluation of the software, is not easy to pick the best tool for the job unless some members have got experience in some previous job with these tools.

Consider that "unnecessarily-complicated" and "unnecessary" do NOT mean the same thing -- particularly in this case.

most people don't mean there is a simpler implementation that has the same feature set and execution properties.

Most people mean it has features i don't need, hence it is too complicated

Redis also comes to mind.

That said, I also see the opposite when this gets some traction with "normal users". The Abseil issue was fixed, and the TensorFlow 2.0 release did make TensorFlow more usable by smaller teams in many situations.

Docker seems to be optimal for medium size teams. Configuring a server the old way is easier than docker for 1 server but less so for when you have 10 or CI/review apps.

Hah, with Google? Right.

Bear in mind the livelihood of nearly everyone participating in this conversation is impacted by the situation being lamented. It's telling that CoreOS employees felt compelled to set the record straight and casually "float ideas".

It's further curious to note the difference in HN's reaction to an extremely salty and offensive post from, say, Linus Torvalds, versus this one. People are really bad at objectively setting aside their ideology and tone is a kind excuse to get out of having to genuinely think about whether the angry individual might have a point, and when it hits close to home, well. All bets are off.

You're 100% correct on your overarching point but the less kind interpretation is "the incentives of modern software engineering value complexity to artificially strengthen a software engineering job economy". The good news is that the more Big Tech screws the pooch with user data management and software engineering, the stronger an argument I have among very receptive ears in government circles to start thinking of Big Web/FAANG as hostile to responsible computing innovation, because they never really bought what Mikey sold them, and the troupe that followed Mikey to Washington didn't hang around to explain the downsides or long-term management needs of the current landscape.

Sometimes I feel like the people who are deep down in this "full stack developer" land should come up for air and look around at the bigger picture. There's a much bigger world of software development out there and actually I think this post was kind of an attempt at that.

The web-facing industry seems to have dug itself down into a very deep rabbit hole of frameworks-on-frameworks-on-buzzwords, in a way it wasn't 10 years ago when I last played in that space.

It looks very weird over there from over here :-)

In order to deploy a web app in 2020, one must write his frontend using react and typescript that would transpile the code into a nicely bundled and minified javascript and css files along with thousands of your 3rd party dependency libs. Yes, you heard that right! I just counted the number of libs on the node_modules in one of my small side project and it's over 1000s. You might also wonder why the typescript code would produce css when transpiled. That's because in 2020 we no longer write stylesheet directly into a css file. That's so 90s! We write the css as javascript objects now, then let the transpiler generate css from that. Isn't that neat?!

For the backend, you can choose one of the many cool frameworks and languages. Heck, why not use 5? In 2020 the backend should be written as a collection of microservices that talk to each other over grpc. Of course you still need http or how else would your react frontend talk to your microservices? So your microservices now talks multiple protocols, which is very cool!

Now pack each of those service into a collection of docker images, then write 4000 lines of yaml files to orchestrate them on kubernetes, and you're ready to go! Now you have a glorious, scalable app with 99.999% sla that can withstand your show hn frontpage traffic thanks to kubernetes, until you eventually screw up that yaml config and the whole house of cards collapse, but that's on you because you're bad at kubernetes orchestration!

I think we're indeed in a deep trench but damn it's quite an impressive trench we got here!

Don't forget GraphQL on top of that, otherwise you're not really in 2020.

I am wondering why someone just hasn't forked etcd if it is truly so awful now.

I have witnessed that firsthand. Despite the anecdote being backend, I’d bet my 401(k) it’s the same up front.

When you are still trying to figure out exactly what HTML and JS should be responsible for, having React, Vue, PHP, Elm and many more as options for "just making a simple web page" can slow down the learning process by an order of magnitude.

I'm not sure what the solution is here- clearly each of these tools has a niche which requires them, but making a basic webapp without a web-engineering degree is quickly becoming an impossibility.

While I do like cheering for annoyed people to fork projects it's not always practical for a number of reason like:

- The project is large and really requires multiple people to maintain.

- It's written in a programming language that the person is not familiar with, or interested in (they might even dislike it).

- License issues.

- Their work might prevent them from working on open source projects due to intellectual property concerns.

In 5 years react and kubernetes will be considered legacy tech and we will march on to other new shiny tech.

There is a watershed coming where Big Web/FAANG will lose this mantle, and DevOps, half-baked Agile because nobody ever bakes it all the way, framework engineering, and a complete fundamental ball-dropping around security and exploitation of user data are rapidly ensuring it.

At some point, Big Web/FAANG and everybody delivering Web services of some kind got the idea that the Web was computing. I think the prototypical version of this thinking led to Rob Pike's observations about systems research in the early oughts. This forum tends to operate with that underlying assumption about the lens to view computing through no fault of anyone in particular, which is why I say that.

I'm a little confused by the reference to healthcare.gov: if Big Web is not the right paradigm to handle a... big web site, then what is?

I realize that’s an underwhelming answer, but if we asked that everyone who disagreed with the status quo simultaneously proposed a perfect solution to fix it, we would be nowhere in any sense. I assure you that thinking about the answer to your question is a significant part of my life, and talking to people who use computers to shape that thinking is key. Government was largely responsible for setting the computing agenda and spurring all of the right technologies in the beginning, and I believe there is merit to revisiting that thinking rather than ceding computing to engineers on the West coast.

There were precursors to this... GWT was an early example of abuse of the web browser stack to accomplish something very non-webby. But it's really gone full bore now.

Back in the mid-90s when I made web pages for a living when some designer came to us with a photoshop mockup in a PSD and said "make the page look like this" we felt perfectly fine saying "no, the web can't do that. design for the web, not photoshop"; no such luck now. And so here we are...

> "the incentives of modern software engineering value complexity to artificially strengthen a software engineering job economy"

Not sure I would agree. Hanlon's razor comes to mind. To me, the referred complexity is reminiscent of a number of other complex patterns that somehow found their ways in software engineering, out of possibly good intentions. Regardless, an idea needs to be sold and when the marketing is well executed the community will ingest the kool-aid. Which it then tries to digest for a few years. Then begins a game of chicken that consists in not being the first to admit that you're in pain, out of fear of being branded an infidel, or out of sunk cost bias. Eventually a few courageous and influential souls finally spit it out in disgust and scream "wtf is this shit?!?" Then the rest awakes from the common stupor and a holy war ensues. I still remember SOAP. I still remember with what verve I was sold Scrum.

As for Kubernetes, only time will tell.

It seems that systems and principles invented for some specific situations get rapidly entrenched as "best practice" due to the wild success of their root corporations. That's twisted much like fashion - "that dress looks great on that model, maybe if I wear that dress, I would look good too".

- the companies' successes are often predicated on strong ability to develop technologies

- good (well-maintained) technology requires resources and the successful tech companies have those resources.

I apologize if you just wanted to discuss the merits of a startup-minded approach to government IT, but I'm honestly skeptical of your motivations. USDS ruffled many feathers among the entrenched IT interests, and I've seen what the propaganda response looks like first hand.

If you really believe that you're fighting the good fight, then I'd welcome a direct conversation. Even a phone call if you like. I promise that I'm not in any way similar to a QAnon believer.

I don’t speak on the telephone with underhanded accusations, sorry.

And you and “a proper response to accusing you of being a conspiracy means I’m being trolled when really I have no response” wonder why I change HN accounts like I change socks. Perhaps it’s because I hold this community in the utmost contempt precisely because of you and people like you, and I have zero interest in building a reputation among the harmful, toxic people who don’t realize how wrong they have it that I am working to excise from the conversation.

Take it or leave it. The good news for you is that you’re on the comfortable side of the argument so you will never get flagged or chastised by dang. Flagrantly accusing someone of psychological defect due to not liking their opinion is okay depending on the target and beliefs.

That's not really surprising, and maybe should be a lesson to the author. If you want to make a particular point, you shouldn't make inflammatory/controversial statements about other, only-tangentially-related things. It distracts from and dilutes your point.

For my part, I know one of the CoreOS founders, and while I have no opinion on CoreOS itself, it's really off-putting to see some random armchair quarterback on the internet shitting on the work of someone you know. While I more or less agree with the actual real point of the article, the unnecessary attacks really divided my attention.

The article starts off with a cheap potshot at CoreOS, followed by a screed about Kubernetes, and then finally, more than half-way through, we get an admission that the author has "digressed", and we get to the actual point. Certainly the point required some background about Kubernetes, but I can understand why people focus on the negative CoreOS and Kubernetes aspects of the post, since they consist of more than half of the content.

I'm mostly curious about which part of devops you're skeptical about, if it's tooling, or process, or the mentalities or something else.

If anything, I hope that we can recognize that there has been advancements in computing. Back in the day you would be open to attacks left and right. It was the wild west back in the day. Today, you can take that tiny webserver and put it in a VM, and voila, now it doesn't matter if anyone breaks in. As long as you didn't add the SSH key to github or anything like that.

We can have complex programs, as long as every-man doesn't have to know the details behind it, or implement it or risk losing access he previously had.

I think new protocols that are extremely hard to implement falls under that, and I don't think Qemu or Linux does, as nobody loses anything when Linux adds new complex features.

We have to make sure, at least, that we continue to support HTTP/1. I think we already lost a lot when we moved away from IRC.

FCGI is an automatic "orchestration system" - it starts up more instances as needed, restarts them if they crash, shuts them down when they go idle, and restarts them once in a while in case they leak some resource. It's like the parts of Kubernetes you really need.

Go is an OK language. Not a great language, but an OK language. It comes with almost everything you need for server-side applications. Also, the "goroutine" model means you don't have to fool with threads vs async. If a goroutine blocks on a lock, no problem; the CPU gets redispatched. If you need a million goroutines, that works, too. None of that "oh, no, the async thread made a call that blocked and screwed up the whole system".

MySQL/MariaDB/Postgres have been around for decades, and they work pretty well. You can have replication if you need it. (NoSQL seems to have come and gone.)

Get the stuff at the bottom right, instead of piling more cruft on top. It's cheaper.

If you wrote your simple HTTP server well, then not really.

> you can take that tiny webserver and put it in a VM, and voila, now it doesn't matter if anyone breaks in.

1. It might still matter.

2. The virtualized/containerized version could well have its own security issues.

3. The virtualized/containerized version is heavy and expensive (relatively).

4. Why did you move away from IRC? Come back... :-(

There's an underlying presumption about computing progress that has weaseled its way into your thinking, and the devil of it is that there are vanishingly few people willing to question it (can hardly blame them, given this thread).

Technological Manifest Destiny:

1. Technology is value neutral and will therefore automatically lead to great outcomes for everyone.

2. If we delay the rollout of new technology than we would delay the distribution of the inevitably great impacts for everyone.

3. History is generally uninteresting because the past has nothing to teach us right now.

(https://www.zachpfeffer.com/single-post/2018/11/27/Transcrip..., ca. 37 minutes in)

Nebulous philosophical arguments do explain things. Quite readily, actually.

This is a dangerous viewpoint to hold. Containers do offer some slightly better security, but they are not a silver bullet or anything close. There are still lots of ways to cause problems whether the software is in a container or not.

> Containers

These are not the same thing, and have different security guarantees.

But let me ask the question another way. What security do you gain by being in a container instead of on a server without a container?

I'm not a container guru, but... this is obvious, right? You have to break out the container, which is an extra layer. In order to get root on the server, you need:

• Without container: application vulnerability (to gain access to the OS) + kernel vulnerability (to gain access to root)

• With container: application vulnerability (to gain access to the container) + container breakout vulnerability (to gain access to the OS) + kernel vulnerability (to gain access to root)

You make it sound like I'm missing something — what am I missing here?

Edit: are you talking about CVEs like this one (https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-3215)? I guess I'm assuming that a container vulnerability will give an attacker less to play with than a kernel vulnerability.

Most of the bad stuff you can do when you take over a web server doesn't require root access, just user level access, and you get that whether or not it's in a container.

They are not an additional shell of defence, they do not reduce your blast radius.

Could you explain what you mean by this? I'm still not getting it.

Here's the example I have in mind: I have one application listening on a TCP port, and another one listening on a different port. I don't want the first application to talk to the second application. If they're just two processes on the same machine, they can both see each other, and an attacker who manages to exploit an RCE vulnerability gets access to the port "for free"; if they're both in containers, then they can only see the ports I specify, and it's really easy for me to specify them.

This literally does seem like an additional shell of defence to me! What sort of attack would it make worse?

As for your example, there’s no difference between that and OS mediated mandatory access controls, separation of uids, chroot etc. Those capabilities are present irregardless of whether you’re using containers.

Anyone selling you on containers as a security measure is pitching snake oil. They are a resource allocation & workload scheduling tool. They may help applications avoid inadvertently treading on one another’s toes e.g. avoiding library conflicts or easing the deployment of, say, QA and showcase environments on the same metal, but it’s intrinsically a shoji wall.

There’s even a cultural downside, since developers may make exactly these flawed assumptions about runtime safety, or hard-code paths for config files rather than making them relative to deployment location, make assumptions (implicit or otherwise) about uids and so on, i.e. containers can breed sloppy dev practices.

> Anyone selling you on containers as a security measure is pitching snake oil. They are a resource allocation & workload scheduling tool.

I agree with both of these statements — and I suspect this is where it all falls down. When you put all your applications in containers, you are not done with security, no. Nevertheless, I've found great value in having one file per version per application, being able to upgrade my dependencies one-by-one, automatically rolling back in case of failure, and taking advantage of the tools in the container ecosystem. With all that, the security features such as isolating filesystems and network ports are just the cherry on top. Before containers, I was thinking about how to give my applications limited filesystems to work with, but along came Docker, and I didn't have to think about it anymore, because I'd already done it.

This is why I feel so out-of-touch with many of the commenters here. I'm surrounded by people decrying containers for security reasons, I want to defend them because of the many benefits they have given me, and I think the people preaching some kind of True Security (where everything is 100% perfectly isolated) aren't taking this into account. I feel like I could take your comment — "Trusting the isolation like this is absolutely misguided" — and apply it to any part of the stack. You have to stop somewhere.

I've seen the salespeople. They definitely exist, but I don't think they're here on HN, and they're more likely to be learning than lying.

And developers making flawed assumptions? You know this didn't start happening with containers!

Don't underestimate your responsibilities as an active participant online and operator of a globally reachable computing resource. Like driving a car, if you're not fully qualified and alert then you can endanger yourself and others. This is how PHP got such a bad rap.

The fact that the container deployment tool has helped you configure security elements (such as limited filesystem access) is nice, but those elements already existed, along with the tools to manage them. Containerized software deployment did not invent them, and if you're getting procedural benefits from containers, that's great for you, but that's all it is.

To be fair, more security by additional tooling adds a vulnerability in human error, but that's true of all the tools.

If you have an application RCE and a kernel vulnerability, what difference would a running container daemon make?

Some of this is an illusion of simplicity.

I think it was a good move for an infrastructure piece like etcd to add gRPC. Now I can just grab a generated client in a language of my choice. There's certainly valid critiques of gRPC / protocol buffers but I've found things like gRPC and Thrift to reduce complexity in applications that use them, because there's a thousand interpretations of REST out there, not to mention the crazy things people do with 'simple' HTTP, such as long polling, which introduce implicitly complex semantics into something that is on the surface quite simple.

But you can't curl the state of your infra component without creating a program and downloading the client artifacts. This is a very big step backward from an operability standpoint.

> because there's a thousand interpretations of REST out there

...but there weren't a thousand different interpretations of the etcd API out there: there was exactly one. And now there are two, and the one with the most utility (that can be used without generators and in languages where gRPC support is spotty) is being diminished.

While I agree with you that there could be design consistency arguments in the abstract for gRPC vs REST as a global architectural pattern, none of those applied to the concrete artifact of etcd client<->server communications.

You can if you enable server reflection[1] and use a tool like grpcurl[2].

[1]: https://github.com/grpc/grpc-java/blob/master/documentation/... [2]: https://github.com/fullstorydev/grpcurl

Not available in any repositories and largely unknown to general masses (much like gRPC itself).

Personally I like gRPC and sometimes use it in projects. But the author is right — attempting to gradually replace an existing HTTP API via gRPC API is like replacing horses with genetically modified cows. You need a very... corrupt mindset to ever attempt anything like that.

To reemphasize the problem with grpcurl.... it's _still_ static. You must download the artifact. It's like needing a different phone for every person you call (protobuf artifacts) instead of calling different people on the same phone (same artifact, different address and data in payload).

Especially since I believe grpc does take steps to mitigate some of the RPC issues you'd have with, say, Thrift. For example having the REST gateway so you can support the curl scenario without any extra work. (For example when building my own Thrift-type services I would do extra work to have a mini REST API for status and other operational curling uses)

As to the second part of your argument about there now being a second API, and how that is not necessarily a good thing, I quite agree and can't really speak to the etcd use case, other than that I don't think it's some property of 'Xooglers' to do such a thing to an open source component. I've spent my career using open source components: I've had lone developers who change their APIs willy nilly to fit the pet peeves of their own organization; I've had large companies own an open source component and have it be very disciplined about version migration; I've had lone developers be similarly disciplined; I've had companies make open source projects really complicated.

I would agree with you except for one thing--it's very clear that's a second class citizen. There is this totally extra thing to support the original use case of etcd, and it comes with all the extraordinary quirks of how gRPC protobuf -> JSON serialization works (a strong term in my opinion).

It is very very hard for me to not see an unintentional conspiracy to push this very bad standard of gRPC. It does NOT make 99% of real-world programs faster. It does not make operations easier. It is not even a "data" format at all: go try changing an enum in downstream systems.

The standard is bad. Objectively, terribly bad. Someone somewhere on HN said that "Google was a ball-pit for gifted children." I kinda laughed at that, but really, after k8s and protobuf3, I won't even grant "gifted".

Google is a ball-pit for autistic children who can be funded by their monopoly on search. I'm tired of dealing with their protocols that make everything worse.

This made me laugh.

You can still do this because the gRPC API is also exposed via REST.

(I use it)

But I also think that the original author has a point: for many solo developers it's an extra dependency that they have to learn, and they get virtually no benefit from using grpc because they aren't performance-bound. They are simplicity-bound.

If you're talking latency, to this day gRPC in dynamic languages is still slower than most fast json implementations in _latency_.

It is simply not correct to talk about "performance" this way.

If you care about CPU allocation and not burning 70% of your CPU on JSON parsing, then sure. Most companies don't care about that, and I/O is 3 orders of magnitude a bigger problem than in-process parsing for those problems.

Obviously these aren't hard and fast rules, but Google can't just spin up 10x more data centers to run their resource intensive stuff in something other than c++ or Java. They need the efficiency in a way solo developers or small teams usually don't.

Simplicity wise my favorite scenario is where if I'm using Python I can pip install an interface (or maven, or NPM, etc. etc) which is the versioned, supported interface for a component. REST + Swagger can help a lot there. So can gRPC. But I can also get how your favorite scenario might be to explore a REST API and build your own client.

No, you can just grab a generated client in a language of your choice if that language happens to be supported by protobuf.

This is a massive regression from the openness of HTTP REST APIs.

But it's trivially true in the case where the provider does so wish (as it would be true of any protocol with a fully-functional HTTP gateway infront of it), and it's untrue in the case where the provider doesn't.

And the provider has to do extra work:

"[offering an HTTP gateway] required adding custom options to gRPC definitions in protobufs, and add an additional container running this reverse-proxy server." ( https://wecode.wepay.com/posts/migrating-apis-from-rest-to-g... )

This still seems like a massive regression in openness to me.

Not so. The article, imho, presents all of its views as unabashedly opinionated views of the author.

The complaint that simple, lucid and well-fit functional designs are getting hijacked by large-corp vested interests has been adequately taken up elsewhere in this thread.

This person is not looking for a conversation, but looking for a fight. He seems to be angry and cannot direct his anger to "make good art" (Neil Gaiman - Make Good Art), instead trying to insult people and pushing them to a place where their emotions takes control and can be dragged into the mud.

Here is one from me with the solo-dev/small-team in mind - https://github.com/imaginea/inai . Good or not I don't know. It came out of some reading I was doing and I'm having fun with it due to the "deploy first and then dev" mindset it encourages.

Do you work with Kubernetes in a professional setting?

There are some irony on the text, but to understand this is very naive.

The critic is at malicious/dumb people who latch to technologies without understanding them.

For argument sake, see how many people are defending coreOS etc, and how they claim to have decided to like it based on their superb expertise, yet they will likely fail to explain to you chroot or anything else containers are based on. Or how they will proclaim that LXC is pure garbage and Docker is better (i will not explain the joke, let them downvote :)

Bottom line: we are being sold bad ideas from the past, in new clothing, by the incompetents/malicious people, which megacorp is made of.

Read my comment again and you will notice there's not a single comment against or in favour of tech. Not even an adjective next to tech, only to people.

The comment is exactly that some people can't tell the difference between two completely identical techs, just because they buy the marketing of one of them, despite it being a brand on top of the first.

As a solo open source developer who maintains a popular OSS project, this is 100% the case. Sometimes it feels like big corporations are actively working against us. It's almost impossible to get any coverage at all on any kind of media. No matter how much organic growth your project has.

My project has been growing steadily and linearly for almost a decade. Now it has almost 6K stars on GitHub so you'd think that this by itself would draw some attention? Not so.

It's almost impossible to find it on Google search results. Most users find the project through direct word of mouth from other users of the project. We've never received a single consulting contract from any corporation.

It sounds like you’ve built a useful piece of software. However, you don’t get handouts because you’ve built something. Those who are successful actively promote themselves and their products. There’s a reason companies aren’t comprised of just software engineers.

However, i’m not quite sure what it does (it obviously does something really well, but I’m probably not precisely the target audience)

It might help adoption and re-share value if your readme starts with some problem and shows how your tool solves it. The cadence/temporal people did this really well: https://www.temporal.io/

I think where a lot of the pain comes from, and the article hints at this, is there are a LOT of problems that do not require a distributed solution, and while you can totally solve those problems with a distributed system, it's not really useful to do so in a way that dramatically increases complexity.

This is a known issue, and there are simpler models for these simpler cases. I think the problem is all the hype around k8s has driven a lot of square pegs into round holes.

To put this another way, if you read the Jepsen reports overwhelmingly what comes across is a lot of hubris. Its overwhelmingly old stodgy technology these new systems are meant to replace (posgres for example) that are satisfying the promises being proclaimed on high by $NEW_TECHNOLOGY.

There's just a reality that we don't really build these systems on top of a distributed operating system. They're starting with an platform abstraction that is already terrible imperfect for the job. There is a ton of pressure to get something out quickly and make it accessible to a broad set of developers rather than to do it correctly (MongoDB is perhaps the most classic example of this). I was building big data systems in the early days, and the whole mentality was that you were building tools that were riddled with flaws, limitations, and outright bugs, but in the right context would make capabilities accessible to a broad set of developers that were otherwise completely off the table.

The truth is, if developers were already experts at distributed systems, they wouldn't need or want most of these tools; a LOT of the value is in accessibility and having something that is "good enough" rather than correct. The products reflect that more than they reflect hubris.

What I do see is a combination of marketing and customer ignorance that does believe in silver bullets and belief that these tools don't have to be understood to be effective. It's an unfortunate byproduct of focusing on that accessibility over correctness.

> Funding and adoption (in the extreme, some might say hijacking) of open-source projects from large corporations dictates the direction of all major software components today

This is because large corporations are the biggest users of these pieces of software. Its literally that simple; money only plays a smart part of it.

Etcd's biggest user is Kubernetes. I would estimate that 2nd place isn't even close. I would estimate that Etcd wouldn't even exist today if not for Kubernetes. The direction of open source projects is usually some approximation of a democracy; its users contribute the code they need. If they need gRPC, it gets added. gRPC wasn't added for no reason, or because politics; its a sister CNCF project, and would increase the performance of the API surface, which greatly benefits all of its users.

Lets do a little experiment: Go start an etcd clone. Just go do it! The code is still there! It would be four clicks in the Github UI. Strip gRPC, add the HTTP API, and maintain it. I'd bet a thousand dollars the author won't do it, for two reasons. First, the author hasn't actually used etcd. I know this because, as I said, startlingly few people outside of Kube use etcd directly, and the author isn't providing any substantive technical reasons why the gRPC change was bad; just philosophical ones. And Second, because maintaining large open source software projects is soul crushingingly, destructively, enormously hard. Its way too easy to armchair-quarterback decisions like these based on your own personal flavor of ethics, then cherry-pick the evidence you want to say "corporations are evil! they destroyed etcd by getting rid of HTTP!" Meanwhile, people out there do develop it, and use it, and service billions of requests, and deliver value to their users, and sometimes, turn off their computer and cry because despite all of the hard work and positive results people with no skin in the game still pipe up to say what they're doing is horrible.

Did the author join in on the discussion when these changes were made? Did they voice their concerns? Or did they just read about it after-the-fact and say "jeeze, that piece of software I played around with two years ago really took a turn, I'm going to write a post about how evil corporations are."

gRPC (Google RPC) was absolutely added because of politics. Yes, it's performant, but let's not kid ourselves that gRPC wasn't picked because it falls nicely into the orbit of Kubernetes and the Google ecosystem. It's also why etcd can even threaten to remove support for HTTP+JSON (!!!) in the API, when it costs nothing at all to keep that support. This is exactly what the post is bemoaning.

> Did the author join in on the discussion when these changes were made? Did they voice their concerns?

Did you? Did anyone outside of a few people in a SIG or an RFC? This is also the complaint the author is obliquely getting at. Google may be 95% of the etcd _volume_, but they are basically 0% of the institutional users. That a small group of people can push a project in a direction that uniquely benefits them while adding an incidental complexity tax for everyone else is worth complaining about.

These are all projects under the Cloud Native Computing Foundation; its Platinum-level sponsors include: Alibaba, AWS, Apple, ARM, Cisco, Dell, Fujitsu, Google, Huawei, IBM, Intel, JD, Microsoft, NetApp, Oracle, PaloAlto Networks, Red Hat, SAP, and VMWare. Also included are 20 Gold-level Sponsors, 415 Silver-level sponsors, 3 Academic sponsors, 13 Non-profits, and 100 End-user supporters. That's a total of 570 organizations with a vested interest, and voting rights, on the direction of their projects.

But Google does a lot of technical oversight, right? A non-zero amount. Among the eleven people of the CNCF Technical Oversight Committee, Google has ONE representative (Saad Ali. Learn their names. These aren't just faceless mega-corps we're talking about; they're real people). Microsoft has the most, at two. Also represented is Apple, Intuit, Docker, American Express, Aqua Security, Lyft, Rancher, and Alibaba.

But, ok, Google "sneaks in" a lot of code, right? They're super-evil, that's the message we're trying to convey here. Of the top ten contributors to etcd [1], there's only two people who seem like they work at Google. The top contributor, by far, works at AWS.

Alright, fine. Kubernetes was created at Google, this much we cannot deny. Started by Brendan Burns (now at Microsoft), Joe Beda (now at VMWare), and Craig McLuckie (now at VMWare), all Google engineers a decade ago. Yeah, the thought leaders behind the project sure are still making that sweet sweet Google money, sure seems like it.

Its just tremendously incredible to me that anyone still believes Google has a large say in CNCF projects.

[1] https://github.com/etcd-io/etcd/graphs/contributors

Google knew they couldn't catch up to the AWS offering by selling service alternatives, so they intelligently and astutely zagged, and went all-in on an "open source cloud" approach.

Kubernetes is the Trojan horse - it gives people hope that they can develop with open source, and be cloud agnostic. But when the complexity overwhelms and drains them, they invariably look for a "managed" kubernetes solution to take the load off. And, wouldn't you know it, Google happens to offer a managed Kubernetes solution! Sure, so does AWS, but EVERYONE KNOWS (whether you like it or not) that Kubernetes was developed by Google, so surely they would be the ones best at managing Kubernetes ops in production!

And your condescension and repetition would show that you don't know what you're talking about.

These were all--100%--developed on by Google and moved into CNCF, which is uncomfortably influenced by Google. Big providers have made peace that they lost the standards war. (And while etcd was not originated from Google, its adoption into kubernetes was obviously influenced by its use of golang.... developed at, where was that again?)

Kubernetes and gRPC started at Google, were exclusively developed by Google, and then much later moved into CNCF as a form of legitimacy.

If you have never tried to get a change into gRPC, I would encourage you to try. It took 3 years for Google to allow an upstream change that would not require rebuilding PHP protobufs from scratch on every request, because it would change the way their C library did things.

[0] https://github.com/gyuho

Are you making a case in this package that complex open source projects are impossible unless completely controlled by very large, highly opinionated companies? That can be proven wrong by endless examples.

> Did the author join in on the discussion when these changes were made? Did they voice their concerns? Or did they just read about it after-the-fact and say "jeeze, that piece of software I played around with two years ago really took a turn, I'm going to write a post about how evil corporations are."

You don't know this to be true, so why make this accusation? Why not address the argument as it is instead of inventing ad hominems?

Its startlingly easy to write five-hundred words. Its startlingly difficult to accomplish what the etcd team has; I therefore give the benefit of doubt to etcd.

I don't fully understand why etcd switched from HTTP to gRPC. It seems weird to me. I wouldn't do that for any project I run. But I'm not going to write a blog about it. I'm not going to get angry about it. I'm not going to spin a conspiracy about ex-Googlers spreading gRPC everywhere they can. Instead: there are a ton of people developing and using etcd, who aren't me, who know what they're doing, and their results speak for themselves; They probably made the right call.

> You don't know this to be true, so why make this accusation?

Those are questions. But, yes, my tone was accusatory. Generally, if you have skin in the game, you don't write posts like this. That's why having skin in the game is so important; even if you lose the fight, you're left with positive remnants of the work you've done and the people you've interacted with. There are positive ways to have a negative discussion about technology. Instead, this article goes obscenely negative about etcd based on one thing the author disagrees with, then spins it into being negative about Kubernetes, Electron, Docker, corporations, and finally goes personal by directly criticizing the "expats from a megacorp ... who just want to build big ungainly architecture"

But also, you can look at their github and see their lack of contribution to etcd, if you really wanted to go full-stalker and demand evidence.

At a (very uneducated guess) I'd imagine that the query payloads would be smaller with gRPC since it's binary which would save money when running in the cloud for things like traffic egress, cross-zone, or cross-datacentre billing. HTTP can be unbeliveably verbose.

It's also probably quicker to deserialise which means you get more bang for your buck on your machine spend.

> It's also probably quicker to deserialise

These are pretty educated guesses :-). This kind of reasoning has been behind a lot of Google initiatives, such as protocol buffers. If you're slinging enough data around, smaller payloads and faster serialization/deserialization does have a significant payoff. Once you're marinated in that mentality it probably sticks.

If you are that tied to your work you may be treating it as a child, and as a child, your moral reasoning will proceed with the underlying premise: "what is good for the child is good", leading towards a parenting of the project ahead of other needs.

But a software system is not a child, in fact. It's just an expression of ideas. "Skin in the game" signals that you've been dragged into being a parent. Is being a parent for software the right thing? Perhaps, if the software's premise draws upon a strong justification. But most of these tools have not been emerged from standalone justifications, but from solving something else, which neatly ties back into the author's argument: the corporate needs are what are complex. And here attachment-based morality recurses: if the corporation is the child and you are tending to it, once again, you will put it ahead of other needs, and hence will develop the justifications for software complexity.

But if we zoom out a bit and look at the world generally, it's operating from a point of indifference: if the output of the corporation is pragmatically convenient, it is good, if it presents an obstacle then it is bad. And ideas - and hence software - that persist in the indifferent world, outside of the attachment relationship, are the ones that survive.

Which perhaps means that all of it is wrong, which isn't a very stunning conclusion if you still have to work with it. But that is philosophy for you.

That's a VERY confusing comparison and conclusion to draw from it.

IMHO, there is a simple solution to this - release the software under the GPL license. Then no corporation will want to touch it.

As someone else mentioned, when a giant corp absorbs a free project, you can reasonably expect them to maintain it. If you GPL the project, that won't happen. But if it's a popular project, then if it's GPL it will attract more maintenance from people who can't free-ride on the corp's efforts.

(Note that the relevant measure of "popular" is not number of users, but number of people enthusiastic enough to actually contribute.)

“Under the radar” comes a new generation of better systems and components that learns from these learning vehicles of computing and will change how we deliver services fundamentally, but without k8s and Linux we would never have gotten there. Open source RISC-V co-evolved with seL4, WASI, webassembly and NATS comes to mind, but I’m sure the future will take its own path.

K8s gives us declarative infrastructure with eventual reconciliation. That's massive, and there's nothing else around that really does that.

I have a hard time taking anyone sesriously that makes the case that k8s is bad that hasn't fully grokked the above.

One is for making it easier to manage large, complex infrastructure. The other is as a quasi-OS for containerized software.

Instead of using a new technology to move infrastructure complexity away from developers we now run development environments on k8s, piling even more complexity and layers of abstraction on.

Not sure what you mean by declarative infrastructure but eventual reconciliation has been implemented in at least one other project (now retired) called Apache Aurora[1] which runs on Apache Mesos[2].

Twitter ran (and probably still runs) a combo of these to huge scale and great success so I don't think it's fair to say that there's nothing else around that does that :).

K8s is great, but we should be careful not to rewrite history.

[1] http://aurora.apache.org/

[2] http://mesos.apache.org/

>K8s is great, but we should be careful not to rewrite history.

Why's that? That's kind what tech is all about, no?

In this case, the vested interest are interested in making it as easy as possible for real world customers to reliably deploy their applications to the Cloud.

That's not an interest that favors unneeded complexity. The complexity comes from the need for a container orchestration system that satisfies the needs of large organizations. If you could satisfy those needs more simply, the incentives are to simplify.

Undoubtedly there is space to build a simpler tool with a subset of Kubernetes' features. And sure, you can pick at specific flaws in the way it's evolved.

But I'm not so convinced by the claim that the whole thing is a mess because tech employees like replicating the stack they are used to.

I think there's a big swath of people adopting fancy tools to try to solve problems they don't have and won't have for years, but I don't see that having destroyed the ability to do things the easy way.

Pulling the snark would have resulted in more people getting the main point.

However, I'll also point out that focusing on the snark and ignoring the rest of the article is also a choice made on the part of the commenters.

Given a choice, I personally prefer to take the strongest and most charitable interpretation of someones ideas before choosing to criticize them. At least the discussion is interesting that way...

Pull the snark out and there will remain any element of this post that kicks off a violent HN centithread that conveniently avoids the core issue. You know it, I know it.

In fact the author liked etcd in the time period when it was directly associated with the "bullshit" project. And even mentions "but that doesn't really matter".

Bashing K8S is at least related to the main point.

Or resulted in very few people reading it at all.

Availability heuristic: large companies get more press. Partly because they're large and therefore more likely to attract readers for stories about them, partly because their scope is vast and so journalists know about them, and partly because they intentionally seek press for their work.

The scratch-an-itch period of mass-market OSS is long gone. If indeed it ever truly existed.

Of course, you could argue that the people who made it more complicated in the first place could/should have forked instead of taking over, but that ship obviously sailed a long time ago.

I don’t agree that this is a statement about complexity, so much as it is a rant about the author being inconvenienced by technology they personally deem pointless and unnecessary. If the CoreOS comments aren’t a sufficient red flag, the HTTP/2 ones really ought to be. Also, some etcd users debate their assertions about newer versions being more complex internally. On the other hand, its difficult to argue with overly cynical type attitudes.

Over and over again.

Now that corporate interests dominate in many corners of the FOSS sphere, this benefit of FOSS is diminishing. Which is a shame, because it's a big reason why FOSS was so successful, and why so many old commercial projects collapsed under their own weight, even though they always had more features than their FOSS counterparts and thus theoretically should have only grown their user base.

Say I want to fork etcd or build a greenfield alternative - I now have to compete with (or support) the Hivemind's preferences in direction/progress. Who's to say their way is the "best" way?

I think this tension is much greater than it was 10 years ago.

The thing is that with free software the old software is almost never really long gone. It's still out there, free for your perusal. That is the beauty of free software, it's always additive process. But it does also put responsibility on the user to pick the patches they want, either themselves or by proxy. Ultimately you are responsible for the free code you are running, not some vague upstream dominated by fnaag et al.

I think, in the case of etcd, it would have been better for the k8s folks to fork the project and add whichever features they felt were needed to be able to use it for k8s. Instead, it seems like they swarmed the original project and added a ton of features that made it a behemoth of complexity rather than the simple tool it once was.

This would only make a difference if someone was willing to maintain the non-k8s fork. From what I understand, nobody was willing to take that on, so the k8s version became the only version by default.

Basically, if you want to argue for a somewhat controversial conclusion, you shouldn't back it up with even more controversial and unsupported (or weakly supported) premises. Particularly if "even more controversial" means "in disagreement with the vast majority of your industry."

4 is the problem. It's like joining a car club then keeping pushing to have petrol cars banned. It is really shitty to find a cool tool that you can use, then try to force remove features that existing users use.

Thankfully, we still have the "minor" components to ourselves.

Popularity has its downsides.

Perhaps if the author wanted their key point addressed they could have tried focusing on it, rather than on an ill-considered spray across a group of largely unrelated bugbears.

If the economics of the situation is "large teams have to maintain tools for small teams and individual users," that doesn't actually scale well, does it?

why does cmake come to my mind?

It is important to note, too, that etcd is permissively licensed and anyone can run the old version in whatever way they please.

The final, and biggest, takeaway? Hackernews apparently has drank the koolaid and will reach for any convenient justification to write off an opinion they disagree with. Stockholm syndrome all through the comments. Conservatism and pragmatism apparently are no longer current in the cloud economy.

Even if it's for the good of the quality of a product, it is not often easy telling your team mate that they wrote an unnecessary component that should just be deleted. I have done it lots in my short career (and in terms of engineering outcomes, it's been spectacular), but it's easier for me I think, since I'm more disagreeable than the average person.

"The v2 API lives on for now, but upstream threatens to remove it in every new version and there will surely come a time when it'll be removed entirely."

Because they chose to make them open-source (not out of altruistic motives but out of the same profit seeking perfectly good business motives), these solo developers (who are also profit seeking) can benefit from those projects for free and can afford to build to serve lot more users than they would be able to otherwise.

I don't get the entitled attitude of the author. If he wants a 'simple' system by his standards, he can build one easily enough with the modern tools like golang, node.js and rust.

Btw, the web development tools were never simpler than today to operate a safe and secure production web application to serve any number of users. I'm saying this with about two decades of experience doing the same.