Hacker News Reader

Comment by mbesto | Hacker News Reader

Isn't this more of a comment about microservices than it is about SRE? It reads to me like "once you hit a number of microservices it ends up looking like a monolith":

http://highscalability.com/blog/2020/4/8/one-team-at-uber-is...

View on HN

It's always microservices, whatever you build. You just decide what kind of IPC you use between some of the pieces.

Forgive me but aren't 'macroservices' just... services? I don't see the difference.

unless its a gigaservice

dumb question time but what exactly makes something a micro service.

Is the separation of a specific functionality from a wider array of functions to its own vm make it a microservice?

When does something stop being a microservice i guess?

I remember asking a candidate whether they were doing microservices at her current job.

She answered "I don't know if we have microservices, but we do have services that don't do much"

It's since then that's my definition of a microservice :)

Productized class methods.

My definition is separation of infrastructure and deployment cycles. Everything that always in one deployment is one service or stuff thats part of your code-base is definitely not a different service.

> dumb question time but what exactly makes something a micro service.

This leftpad as a service, over HTTPS

I had to google that to understand the context.

What a wild story

It stops being a microservice when a developer starts saying, "oh! We can do X in service Y too! It already does ${similar work} and reads/writes from/to ${data source}, so why not?"

The intended model is to do one thing, thus enabling surgical changes to functionality without having to rebuild everything. As long as you stick to your API contracts, you can muck around with the internals without effecting anything else.

That's not really answering the question. How do you define what the "one thing" that the service handles actually is?

I have this half-serious opinion that interface design is the hard (technical) part of software development, and the rest is mostly easy.

that sounds like a corollary to Conway's law.

I remember coming to the same realization when the Google Vs Oracle court case was going on. Which decided that API’s are not copyrightable. To me it felt like the wrong decision, but what do i know.

I would definitely argue that public interfaces should not be copyrightable, since you need to be able to freely reimplement them to interoperate, which in my opinion should be preferred over granting even temporary monopolies to software interfaces.

However, public interfaces are only a small part of software interfaces in total. It's getting the system's internal interfaces right that takes most of the work.

I totally get it from the sense of avoiding monopolies for sure.

In my view, I was lumping internal/public interfaces in the same basket. I haven’t really considered public vs internal aspect of this.

That's been called "creeping featuritis" for about 25 years now. :)

I think it's the same line of thinking as RISC and CISC (reduced/complex instruction set computer). There's no such thing as a RISC machine or a CISC machine, all computer ISAs live on a spectrum that can be described as RISC-like or CISC-like.

There's no such thing as a micro service or a macro service (in terms of there being a perfect delineation). They're simply terms to describe certain design goals. Any given service might have several qualities that can be described as befitting a macro or a micro service.

It's all too easy to fall into the no true scotsman trap.

I would say its best to only think about any deployable thing as a service. "Microservices" is just the idea that those things do not have a minimum size.

Essentially, "is this enough functionality to make a new service?" is the wrong question.

A microservice is deployed independently, has its own hardware and can scale independently from the rest of the system.

If there are multiple services and they all share hardware, they're not really microservices.

> A microservice is deployed independently, has its own hardware and can scale independently from the rest of the system.

Nicely articulated

> If there are multiple services and they all share hardware, they're not really microservices.

You just described most microservice deployments on Kubernetes ;)

In this case, they run in containers, so they can actually scale independently. For this purpose, it's as if they were running on independent hardware.

Even if we had separate cloud servers - such as EC2 on AWS - for each service, technically they are not really independent hardware.

But for the purposes of deploying, hardware capacity allocation and scaling, you can see them as such. The same goes for containers orchestrated by K8s.

Don't we have a term for that — software coupling?

A microservice architecture has weak coupling.

it's coupling via network calls instead of in-memory calls

I like to think of it more of a separation of components needed to do the job.

Need a database, use a database as it's own service, don't couple the database to the app, so if you need to scale the app horizontally you can add more replicas. If you need to scale the database vertically, you can scale the database vertically. If these are coupled, you scale only whats needed.

On top of that use the language or tool that is meant for the job. If you need something written in go, build your service with go, if you need nodejs, do it with node, etc.

Microservices don't need to be micro or small

Reply on news.ycombinator.com