Show HN: A microservice framework, listed in CNCF Landscape, 1 year 10k+ stars | Hacker News Reader

Show HN: A microservice framework, listed in CNCF Landscape, 1 year 10k+ stars

github.com

65 pointspatrickevans37 comments

It would create more interesting conversation if you highlighted the merits of your design rather than superficial measures like CNCF blessings (there are thousands of such projects) and GitHub stars (easily gamed).

The description might not be good enough, but I have to write something. It's used by many companies and projects. And the design is described in github readme, it's rather long to tell here. Thanks!

Hi, are you involved with the project in a substantial capacity? If not, show hn isn't an appropriate qualifier. May be, tell hn (or, no qualifier) is.

Is getting listed in cncf landscape a big deal? Is it an official cncf project?

It is an official CNCF project, but its not very difficult to get added, see https://github.com/cncf/landscape#new-entries you need 300 github stars and to be cloud native.

Thanks for your response!

surely it has a key differentiator?

> It's used by many companies and projects

No one cares, they would care if you have contributions from many parties which indicates longivity, do tell in that case.

I do think your project is interesting, it's just the title doesn't do it justice.

Thanks for your comments!

I have been working as a programmer for 20 years, and have contributed to some popular projects, if you interested, please check it in github. And you can check my contributions at https://github.com/kevwan, 946 contributions in the last year.

Would you please give me some suggestions on the title? Thank you very much!

I didn't know what CNCF is.

https://www.cncf.io/

> Cloud Native Computing Foundation (CNCF) serves as the vendor-neutral home for many of the fastest-growing open source projects, including Kubernetes, Prometheus, and Envoy.

Does erlang and OTP count by this definition?

Did you click on the link? The README goes on great detail as to what makes it special.

I am eager to know how to game GitHub stars. Funding agencies love metrics and random KPI so I would love to deliver...

Right up to the moment your funding agency calls you out during DD and then you are in deep trouble. Would not recommend.

Why does it matter if GH stars can be gamed or not, could you tell me what it measures?

One word. Bangladesh.

That made me curious: never thought there was a real market but people really seem to pay 1$ per star. Now I have to only trick someone into giving me money for that.

Would be a fun project btw to detect gh not account and projects that obviously paid to get stars.

If I paid one cent for stars, I would close the project.

Little bit confused by the chart in the benchmark section: https://github.com/zeromicro/go-zero#7-benchmark

What is it trying to show?

Compares to the other frameworks, the test code is here: https://github.com/smallnest/go-web-framework-benchmark

The graph is unparsable for me. Typically, for what I think is trying to be shown, you would put the requests per second on the x axis, you would put the response times on the y axis, and the color coding be to assign them a label of the framework. I'd probably use a line chart too since, as we increase rps, we expect a change in response time.

What the graph reads:

If my framework is beego and I want to get 30k rps, I would need to limit my data to processing times in the 0ms bucket. I think? Or maybe gin will allow for 7.5k rps if my processing time is 500ms?

Like, I think I can get to similar information to what you are trying to show if I read backwards, upside down, and rotated 90 degrees.

Making the graph start at 5000 instead of 0 looks dishonest.

I agree. But it's plotted by the benchmark project, not written by me. I didn't spend time changing it.

I love Go to bits, but I really don't like how so many tools revolve around codegen and boilerplate. Look at Kubernetes for example: you can't write an operator without generating a bunch of boilerplate.

I think it's because metaprogramming/macros is a thing Go doesn't have that very many other languages have. Whether the Java/.NET way, the LISP way or the Python way -- most languages have ways of making DSLs and metaprogramming etc in more flexible ways than Go.

I wish Go just got something like Lisp macros that could work compile-time only. Running macros at run-time isn't really the big deal, but generating code in the same language and context as the normal code is a big deal.

Adding generics really doesn't help much here..

The irony is that Java and .NET already trailed that path 20 years ago.

You don't need any boilerplate to write an operator - you can write an operator in any language. I've written several in python and they all clock in under 300 sLoC

I had to dig in a bit to see the whole scope of this project. It seems go-zero has:

1) Go library/main that wraps gRPC handlers to build a server, like Dropwizard or TwitterServer?

2) A CLI tool "goctl" that does code generation for setting up the code layout (server and client API stubs), as well as some Docker/k8s functionality for deploying.

I'm not into Go so can't comment on aspects like the performance benchmark.

However the project documentation is quite interesting if you'd like to see how, presumably the company for which this was built for, their production environment is set up like CI/CD, logging, etc.

It could be more helpful if the architecture diagram showed the roles of the different pieces better. For example it isn't immediately clear what component does authentication so then the JWT can be used for service authorization. So the question would be is how much is the framework tied to some assumptions in a production setup.

Thanks for your comment!

go-zero is easy to use with docker/Kubernetes, we built a command line tool to generate the Dockerfile and Kubernetes deployment files. It's easy to use with ECSs as well, because Go packages it into a single executable binary, you can use tools like supervisord to manage it easily.

As the name of go-zero, I was trying to tell 2 things: 1. go from zero with microservices development 2. go from zero when you get something hard to fix, perhaps you think the problem itself in a wrong way

Also, go-zero consists of 3 main parts: 1. api gateway, along with a newly created simple API idl to describe apis 2. zRPC, with the microservices governance built on top of gRPC 3. goctl, a command line tool to make microservices development much easier

Not sure if I answered your question?

Been striving in the way of micro services for a few years. My contribution is https://go-micro.dev (17k stars)

Used this recently for something and has been very helpful. Thanks for providing this!

I think this sort of project is in short supply. Kubernetes seems to have sucked all the air out of the room, and yet we need variety and different approaches to grow.

I look forward to (trying) to replicate something similar for my own understanding. Any architecture docs will be gratefully recveied

I think the architecture of something like K8s pretty well sums up all (or most) of the components needed for a distributed system. What's really needed today is differentiation on the actual end result of that design. We need simpler technology that works better, and that's hard; it's not enough to have a fancy idea and throw together some lines of code. That's been done, and it kinda sucks. What's needed now is to focus on making it easier and simpler to do specific things.

For example: most people just want to receive infinite HTTP requests and route them to custom business logic, automatically scaling as needed. So why can't I just push a button and make that happen? AWS ECS has a command-line client now that attempts to do that, but it's clunky and unreliable. And K8s doesn't have anything like that; it's all hand-crafted YAML files and mountains of custom cluster configuration. I just want to run some code at scale. And we've implemented that (scaling web requests/business logic) a million times by now. But it's never really gotten significantly easier.

Docker is a good example of the amount of work you need to pour into a technical solution to make it a game-changing user solution. Docker is like 50 different technical solutions rolled up into one user-friendly command-line tool and a backend daemon. You could do most of what Docker does in LXC, but it was painful. Docker made it easy. That's what we need for running services at scale in general. Docker Swarm was created basically to scratch that itch, but it still hasn't really taken off. I'm hopeful it does one day.

> Docker Swarm was created basically to scratch that itch, but it still hasn't really taken off. I'm hopeful it does one day.

It never will, that ship sailed a long time ago. Docker the company is struggling to survive after making wrong bets multiple times. The "enterprise" part, including Swarm, was sold off to Mirantis after years of neglect, and got some much needed investment and big fixes. Nonetheless, Docker Swarm is basically abandonware with terrible reputation without a viable future.

Hashicorp's Nomad is much better placed to compete with Kubernetes. Shameless plug of my article on the matter:

https://atodorov.me/2021/02/27/why-you-should-take-a-look-at...

I moved from nomad to swarm recently (this is running a proxy + dbs + a few replicas of a node app + tons of long running CPU intensive jobs spanning 10 servers).

A few weird api decisions but I found the developer's workflow to be better. I got rid of some weird allocation behaviours I couldn't explain with nomad (the real motivator to get off nomad). I also don't have to install anything.

Thanks for your article, the first pic made me and my colleague laugh really hard.

> Docker Swarm is basically abandonware with terrible reputation.

Can you provide source for terrible reputation.

I agree with you. Great comment. I just want to write some code that can scale from zero to infinity. Cluster or deployment Autoscaling in Kubernetes is not exactly what I want.

Kubernetes gets some abstractions right - such as pods, statefulsets, ingress, deployments

What we now need is abstraction of endpoints, routes, request, response type/schema (to do automatic marshalling), id space sharding like vitess or logical server identifiers as part of the guid for what server the data belongs to..microservice becomes a bucket of routes/rpc calls not hardcoded to a microservice.

Envoy, linkerd and hystrix look like a nightmare to configure right. I think the configuration behind them could be more elegant. The software is probably fine but it's a nightmare to get the right data structure that does what you want - hence the mountains of YAML configuration like you mentioned.

I don't want to care if it's the storage layer or the application layer - it should all be scalable.

I want to be able to set a maximum budget in financial terms and open ended autoscaling ceilling.

Who cares about the stars

Reply on news.ycombinator.com