As someone in software for a while that has been the...

As someone in software for a while that has been the most surprising thing that Open Source did: In massively increased complexity even for small projects because "that's how Google/Amazon/etc do it".

Yes Amazon does Microservice architectures. They also have a few people for every service that knows the ins and outs. You have a team of 5 that now not only has to understand the problem but juggle dependency chains from here around the moon and back so your React App that should have been plain HTML doesn't fail while showing a basically static page.

You won't grow to Google/Amazon scale. It's fine. Just build a simple solution you can maintain.

Working on React/K8s or whatever is mostly you training yourself on your own dime and time to be a potential hire for some Big tech company that will fire you to juice the numbers at he end of the next quarter.

Like 29 January at 15:02 | Open on tldr.nettime.org

35 comments

Markus Feilner :verified:

@tante Agreed, that's the old KISS principle of Unix. But on the other hand, isn't microservices architecture also exactly KISS?
Not asking for a friend, but dragging him in here... :-)
@dragotin

29 January at 15:05 | Open on mastodon.cloud

tux0r :openbsd:

@mfeilner Microservices are the opposite of KISS as soon as the number of "micro" services exceeds 1. @tante @dragotin

29 January at 15:07 | Open on layer8.space

Markus Feilner :verified:

@tux0r @tante @dragotin
... interesting view ... plz elaborate ... I'm really interested in the arguments...

29 January at 15:08 | Open on mastodon.cloud

tux0r :openbsd:

@mfeilner

Not complex:
- One service.

Complex:
- Twelve services which communicate over sophisticated APIs with each other.

I wonder how this is an "interesting view". Just try to draw a map of both models.

@tante @dragotin

29 January at 15:11 | Open on layer8.space

Markus Feilner :verified:

@tux0r @tante @dragotin

Well, I guess the server underneath isn't adding much to the complexity any more. I thought modern admins do that through config management, thus that's no overhead anymore and necessary anyhow. The APIs you will need if you want to scale, anyhow.
But I'm only the journalist, not an expert.

29 January at 15:17 | Open on mastodon.cloud

Markus Feilner :verified:

@tux0r @tante @dragotin

does "one service" instead of 12 mean the one does the tasks of 12 ? Then complexity is only hidden inside, isn't it? I agree about the APIs, but how do you replace those "inside" the one blob server?

29 January at 15:18 | Open on mastodon.cloud

Markus Feilner :verified:

@tux0r the map is simple, you have the same layout, just internal or external, so there's only one square that is resized to fit the model ...

29 January at 15:19 | Open on mastodon.cloud

Callionica

@mfeilner @tux0r A call across a network and a call from one function to another in the same process don’t have the same level of complexity. Or just consider uptime monitoring and the visual complexity of a UI that has to show 12 pieces of information vs 1.

29 January at 16:43 | Open on mastodon.social

Markus Feilner :verified:

@callionica @tux0r Yeah but as size & scalability comes in, complexity becomes a beast... I totally agree that ms dont seem best for small tasks.

29 January at 16:44 | Open on mastodon.cloud

Callionica

@mfeilner @tux0r The OP was talking about small projects. But also there’s different ways of looking at scalability. For example, you can scale an app on a single machine to meet a workload of thousands of requests per second by writing efficient code within a single process and buying more RAM/disk/CPU whatever. Start going to out-of-process or cross-machine too early and you limit the capability of your dev org as they spend more time working on infrastructure and ops than feature code.

29 January at 16:56 | Open on mastodon.social

Callionica replied to Callionica

@mfeilner @tux0r If there’s no security boundary and there’s no resource contention and there’s no way your app can still run if one of your services goes down, these are indications that you don’t need to separate out your services. Plus when you do need to scale out, routing/sharding based on user or user group or geography works for a bunch of apps/services and is simple to implement.

29 January at 17:06 | Open on mastodon.social

tux0r :openbsd:

@mfeilner

You don't need to replace APIs if your server only needs to talk to itself. One server that performs 12 tasks is still less complex than 12 servers with one task each. "Readable code" and "low complexity" are not the same thing.

@tante @dragotin

29 January at 15:22 | Open on layer8.space

tux0r :openbsd:

@mfeilner

"Config management" is not required if you don't have oversized environments. That said, overhead won't go away if you add more overhead to mask your overhead. ;-)

@tante @dragotin

29 January at 15:19 | Open on layer8.space

Markus Feilner :verified:

@tux0r @tante @dragotin

what is "oversized" ?

29 January at 15:20 | Open on mastodon.cloud

tux0r :openbsd:

@mfeilner "Oversized" is what @tante described. ;-)

If you only need a website, you won't need a server farm. If you only have two servers, you won't need orchestration, "config management" ...

@dragotin

29 January at 15:23 | Open on layer8.space

Markus Feilner :verified:

@tux0r @tante @dragotin
I guess that depends on the website, doesn't it? I dont need microservices for mine, because I hardly hit 20k visitors a month. Even LAMP can do that :-P

29 January at 15:24 | Open on mastodon.cloud

Markus Feilner :verified:

... but big portals might differ, am I wrong?

29 January at 15:24 | Open on mastodon.cloud

tux0r :openbsd:

@mfeilner Chances are that most people who don't run a tech company won't need microservices. @tante @dragotin

29 January at 15:25 | Open on layer8.space

Christoph Petrausch

@mfeilner @tux0r @tante @dragotin with micro services, every service call is networked. You have to build mitigations for that. That's nothing your administrator or the underlying platform can safe you from.
Also your architecture/business must be eventually consistent. With every micro services having their own database you can't have one single classic SQL transaction.
I have written something here how to start your small setup and still be able to shift to cloud native https://www.inovex.de/de/blog/low-ops-cloud-native-architecture/

Expand text...

29 January at 16:12 | Open on norden.social

Christoph Petrausch

@mfeilner @tux0r @tante @dragotin From a developer perspective, with microservices calling each other or communicating via a message queue, you loose the ability to make a call and step through the code in your local debugger.

29 January at 16:14 | Open on norden.social

maarten brouwers

@tux0r @mfeilner @tante @dragotin KISS is not a unix principle by my understanding. “Make each program do one thing well” is. That would be an argument for microservices. However, the problem is with it is that it also assumes a generic interface (unix uses text-streams). And while these microservices typically interface using HTTP, that protocol is still too ill defined to make the complex interactions work that most APIs have; like are we talking JSON on a REST interface, GraphQL?, perhaps some find SOAP still interesting?

Expand text...

29 January at 15:50 | Open on todon.nl

Markus Feilner :verified:

@murb @tux0r @tante @dragotin

you're right. "one tool one job" is not "KISS". I was wrong there...

29 January at 15:50 | Open on mastodon.cloud

maarten brouwers

@mfeilner @tux0r @tante @dragotin some might argue it is. On other levels :)

29 January at 15:52 | Open on todon.nl

Markus Feilner :verified:

@murb @tux0r @tante @dragotin

... just a matter of where to draw the rectangle on the map ... and how much you zoom in or out. Like in Physics. Quantum rules dont apply here.

29 January at 16:01 | Open on mastodon.cloud

Graham

@tux0r I feel this so much especially since on my team we have all our models in a private NPM package we have to update in every...damn…microservice when we make a change.

Thankfully we're in the process of migrating to a monorepo but we're still going to be using TEN microservices. 🥴

29 January at 15:51 | Open on mastodon.social

tux0r :openbsd:

@ghalldev @tux0r Monorepo(sitorie)s solve the wrong problem on my opinion. NPM itself is an architectural challenge.

29 January at 16:59 | Open on layer8.space

tux0r :openbsd:

@tante I can hardly count the number of times I've been laughed at because my servers can't even run Docker (OpenBSD doesn't have Docker).

"What am I supposed to do with Docker?"
"EVERYONE IS DOING IT!!!"

29 January at 15:06 | Open on layer8.space

jeremiah

@tante I'm happy I learned k8s at work. My personal time is spent using HTML, CSS, and as little JavaScript as possible.

29 January at 15:07 | Open on tldr.nettime.org

Vex Machina

@tante this, always this

29 January at 15:07 | Open on mastodon.me.uk

Achim Domma

@tante My personal experience with K8s seems to be much more positive than for most other people. 😉 For the rest I fully agree.

29 January at 15:18 | Open on social.saarland

jack

@tante :icant: cart, horse

29 January at 15:27 | Open on status.sexyferret.science

kfet

@tante Monoliths and monorepos are really really bad for rapidly evolving software, where you want clear lines of responsibility separation.

Whether that means processes or modules is a choice, and usually depends on how it needs to scale. Yes, scale is a very real problem to solve, it is not imaginary at all.

TLDR; mono* just results in overpriced spaghetti

29 January at 15:50 | Open on fosstodon.org

beaiouns :verified:

@tante I know! Instead of react, I'll make a static page in node.js!

29 January at 15:53 | Open on is.nota.live

Large Format Projectionist

@tante

Gawd, I wish my employers would grasp this.

29 January at 16:25 | Open on mastodon.social

Aeon.Cypher

@tante Frequently leadership at orgs are composed of people that never really had to get their hands dirty.
So, they make decisions based on a cargo-cult mindset.

29 January at 16:40 | Open on lgbtqia.space

Go Up