Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Etcd, or, why modern software makes me sad

roguelazer.com

Post reply on HN
Print view View original

531–540 of 648 posts

Re: Etcd, or, why modern software makes me sad

#531

Post by deanCommie »

013a wrote: post #328
abernard1 wrote: post #259

Earlier quoted context omitted.

> 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. 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…

I feel as if I have to repeat this during most discussions about Kubernetes and its halo technologies: Kubernetes is not developed by Google. gRPC is not developed by Google. etcd is not developed by Google. 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,…

Cloud Native Computing Foundation was spearheaded and initiated by Google as a competitive alternative to AWS's dominance.

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!

Re: Etcd, or, why modern software makes me sad

#532

Post by johnmarcus »

I stopped reading at "Kubernetes (or, as the "cool kids" say, k8s) is the worst thing to happen to system administration since systemd.". These are the best tools to happen for system administration in 20 years. Also, etcd is a terrible db. You cant back it up and can easily lose quorum (and all your data) with a network outage.

Re: Etcd, or, why modern software makes me sad

#533

Post by EdwardDiego »

yc12340 wrote: post #500
EdwardDiego wrote: post #492

Earlier quoted context omitted.

> But you can't curl the state of your infra component without creating a program and downloading the client artifacts. 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

> tool like 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.

shrug Was just pointing out that you don't need the .proto files on hand to interact with a gRPC service if you use the above approach.

Re: Etcd, or, why modern software makes me sad

#534

Post by Twirrim »

HideousKojima wrote: post #367
Twirrim wrote: post #348

Earlier quoted context omitted.

> And it isn't necessarily a benefit for the Pentagon, as much as it is for the established defense contractors. 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 thro…

If you don't mind sharing, what was the company you worked for?

Hawaii Information Consortium (I guess it's now, NIC Hawaii, https://nichawaii.egov.com/), which is a subsidiary of NIC.

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.

Re: Etcd, or, why modern software makes me sad

#535

Post by chupasaurus »

outworlder wrote: post #116
jonfw wrote: post #70

Earlier quoted context omitted.

What's wrong with the YAML? It's easy to read and write, concise, and generally has sane defaults meaning you don't have to be overly verbose.

> What's wrong with the YAML? Nothing at all. Until you start 'templateizing' it (looking at you, Helm). It's definitely better than JSON (it can even have comments, imagine that). Most people don't bother reading the spec or even examples though, and don't realize how good it actually is.

> It's definitely better than JSON

k8s API supports JSON almost exclusively, basically one could write in Whitespace then convert to it.

Re: Etcd, or, why modern software makes me sad

#536

Post by lima »

abernard1 wrote: post #327
lemmsjid wrote: post #289

Earlier quoted context omitted.

The problem, I think, is that the article presents all of its views as almost self evidently true. If you distill it down, the complaint is that etcd added gRPC. 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…

> Now I can just grab a generated client in a language of my choice. 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 on…

> 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.

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

Re: Etcd, or, why modern software makes me sad

#539

Post by jedberg »

amarshall wrote: post #444
jedberg wrote: post #260

Earlier quoted context omitted.

> Today, you can take that tiny webserver and put it in a VM, and voila, now it doesn't matter if anyone breaks in 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.

>> a VM > Containers These are not the same thing, and have different security guarantees.

Since the whole article is about containers, I assumed they were using VM as shorthand for a container.

Re: Etcd, or, why modern software makes me sad

#540

Post by dang »

einpoklum wrote: post #221
dharmab wrote: post #61

Earlier quoted context omitted.

My team ran about 50% of a Fortune 500 software company on CoreOS up until a few months ago when we migrated to Flatcar. We even paid a lucrative support contract while we ran it. I can count the number of major OS issues we had with it over several years on one hand- and we've had even better success with Flatcar so far. Calling CoreOS unsuccessful is a massive misunderstanding of the market.

Maybe you're right - it's not unsuccessful after all, it really is a bullshit project... Now _every_ part of the OS is in a container! Wheee! https://en.wikipedia.org/wiki/Container_Linux (for those who don't know, it was renamed from CoreOS to Container Linux)

Would you please stop posting flamebait and unsubstantive comments to HN? You've been doing it a lot, and we ban such accounts.

https://news.ycombinator.com/newsguidelines.html

Post reply on HN