Comment by PaulHoule | Hacker News Reader

Comment by PaulHoule | Hacker News Reader

I'd say it doesn't have to be.

There is a certain kind of "freedom" that is really slavery, but people feel so free when they hear about it is they often squee and hurt themselves with uncontrolled movements.

Microservices can be that way. Now that you have 25 different services in 25 different address spaces you can write them in 11 different languages and even use 4 versions of Python and 3 versions of Java. (I got driven nuts years ago in a system that had some Java 6 processes and some Java 7 processes and it turned out the XML serialization worked very differently in those versions.)

If you want to be productive with microservices you have to do the opposite: you have to standardize build, deployment, configuration, serialization, logging, and many "little" things that are essential but secondary to the application. If a coder working on service #17 has to learn a large number of details to write correct code they are always going to be complaining they are dealing with a "large ball of mud". If those little things are standardized you can jump to service #3 or #7 and not have it be a research project to figure out "how do i log a message?"

The problem with standardizing these things is, that it makes them hard to change. A breaking change in the way you deploy must also work for all other solutions - otherwise you immediately loose your standardization. And this will happen eventually. For all this different kind of problems it is near impossible to avoid inconsistency and force rules on them.

So, imo you either have a (very) large organization with independent teams that work on independent services and give them the freedom for everything - or you develop a proper modulized monolithic software and extract services only as a last resort. I would avoid to use a microservice architecture with a small team of developers

No, standardizing these things makes them hard to change for devops. How many breaking deployment changes have you seen in reality?

You're right that microservices shift burden onto infra. But that does not make it a big ball of mud -- infra has gotten progressively easier over the past two decades. If you want me to create the 'ball of infra mud' mentioned in your article, I can do it -- and make it repeatable -- in a few hours. It will come with dashboarding out of the box.

This is why microservices have become more appealing to more businesses. The technology allowing you to provision this infrastructure and deploy your code has changed immensely, allowing you to shift some of that burden over to infra.

People don't need to be given freedom for everything. Like the parent mentioned, with this standardization, people writing application code are able to move quickly and understand how the pieces work under the hood without shifting their mental model.

Who is this devops of which you speak? Did you just mean that standardising these things makes them hard to change? Or, by 'devops', do you mean a particular group of people?

Deployment is done with Kubernetes (on our side).

If the repo builds a container and the service provides a health endpoint, we are good.

My company has 10 - 15 developers and we are at about 10 macro/microservices.

One should definitely not create a new service for every function call but some seperation works quite well on our side.

> you have to standardize build, deployment, configuration, serialization, logging, and many "little" things that are essential but secondary to the application

...so then you can go reimplementing those standards in 25 different services written in 11 different languages. Sounds like fun!

I don't think it's possible to just write a library/framework that would encapsulate all of those standards and re-use it in different services because, again: different languages.

You’d have to force everybody to use only one or two languages. For a time at Uber the direction was go/java only

It's a rational decision, to standardize on programming languages and paradigms.

Having more than two programming languages is honestly a nightmare to deal with

I worked for a company that did microservices well, and this was the norm, too. The term in my head is "golden path" or "sandbox". The languages were Go and Python, speaking protobufs over gRPC.

Developing software outside that sandbox was not disallowed, but you were "on your own" in terms of infra support if you chose to do so.

FWIW, the main "tricks" we found were (1) using a good build tool (2) use a good ci/cd tool (3) use a monorepo.

There were some minor downsides, and it took a long time for tooling capabilities to line up with our ambitions. But when I left, we had 200-300 engineers happily deploying to `main` across 100ish services every day.

Just curious, why is using a monorepo a useful trick? I would think it'd be better to have internal libraries that provide common functionality across services, and have a repo for each service. Otherwise, you're deploying code changes for one service that could, in theory, mess with another service that you don't maintain.

In a phrase, it's having a single "bleeding edge" for the entire company, vs 1 bleeding edge per service. Some benefits of this include:

You have one commit hash in one repo that tells you what version service/consumer X is expecting / providing.

If you want to understand why a service isn't working as expected, it's trivial to grep its implementation and contribute solutions.

As a service owner, you can grep for all places where your service's client is initialized, and update them in one PR (vs 12 PRs in 12 repos, that you have to manage independently).

Basically, it reduces the coordination cost of breaking changes.

---

You can get these benefits in a multi-repo setup only if you have adequate tooling around multi-repo PRs, code search, etc. It's not impossible, but the barrier to highly effective work is higher, imo.

A standardized build and deployment process can be done in a language agnostic way with containers. Every service defines its own Dockerfile. The CI/CD process just runs docker build and whatever process is needed to pull an image and run it in whatever environment.

Configuration is either done with ENVs or with some standard configuration service (which is an API call that can made on service start)

Logging is just standard out in the container. Each team uses whatever logging library is appropriate for their language. Only requirement is that it supports logging to console. There are a plethora of options for shipping those logs to somewhere centralized (fluentd/fluentbit, logstash, etc)

Some of this stuff can also be done with sidecars (see something like Dapr)

So, no, you can't write a library but you can standardize.

You don’t have to standardize build or deployment or configuration. For serialization, you can use something like GraphQL which will enforce types. For logging, you need distributed tracing which services like Sentry have good support of.

Graphql is a nightmare abstraction that hides all performance implications to convenience front end engineers. Get a dba

Reply on news.ycombinator.com