The Death of Microservice Madness in 2018 • Hacker News Board

Re: The Death of Microservice Madness in 2018

#121

Post by elgenie » Mon, Jan 22, 2018, 1:35 AM UTC

humanrebar wrote: post #104

shitloadofbooks wrote: post #54

I think "microservices" is so appealing because so many Developers love the idea of tearing down the "old" (written >12 months ago), "crusty" (using a language they don't like/isn't in vogue) and "bloated" (using a pattern/model they don't agree with) "monolith" and turning it into a swarm of microservices. As an Infrastructure guy, the pattern I've seen time and time again is Developers thinking the previous generat…

> In my opinion, only the extremely good developers seem to comprehend that they are almost always writing what will be considered the "technical debt" of 5 years from now when paradigms shift again. I've also seen really bad developers with that attitude: it's all crap, so just ship whatever already. The good developers write code that can be replaced, rewritten, or rescaled later. Though, charitably, both monolithi…

The critical distinction between "it's all crap, so just ship whatever already" and what the grandparent wrote is that "technical debt" doesn't reside in easily disposable code/components, but rather as may-need-to-be-rectified-but-maybe-not-right-now downsides in what is enormously useful and producing value.

Good developers create code that's prepared for the possibility of being modified repeatedly and becoming foundational; on the other hand, preparing for code/components to be thrown away is a no-op.

Re: The Death of Microservice Madness in 2018

#122

Post by cottsak » Mon, Jan 22, 2018, 1:37 AM UTC

paulddraper wrote: post #5

https://en.wikipedia.org/wiki/Law_of_conservation_of_complex... Broadly speaking, microservices make small, limited changes/update less complex, and large, sweeping changes/updates more complex. This is why generalizations like "larger, established organizations [which make mostly relative small changes] should lean more to microservices than smaller, younger organizations [which make mostly relatively large changes]…

This alone almost rules microsevices out for the majority of us from a cost-benefit point of view.

Re: The Death of Microservice Madness in 2018

#123

Post by pweissbrod » Mon, Jan 22, 2018, 1:37 AM UTC

shitloadofbooks wrote: post #54

I think "microservices" is so appealing because so many Developers love the idea of tearing down the "old" (written >12 months ago), "crusty" (using a language they don't like/isn't in vogue) and "bloated" (using a pattern/model they don't agree with) "monolith" and turning it into a swarm of microservices. As an Infrastructure guy, the pattern I've seen time and time again is Developers thinking the previous generat…

The monolith first approach has always served me well. Nascent projects benefit from portability because they need higher amounts of flux. As they mature let's assume they grow in scale and integrations and somewhere along the line it becomes sensible to break off pieces into services.

To me the big benefit of microservices is scaling out components into flexible independent release cadences but the trouble comes with employing them too early.

https://martinfowler.com/bliki/MonolithFirst.html

Re: The Death of Microservice Madness in 2018

#124

Post by adbachman » Mon, Jan 22, 2018, 1:37 AM UTC

st3fan wrote: post #108

ohyes wrote: post #97

Earlier quoted context omitted.

Jesus, 10 people on a team? What are you doing that you need 10 people to work on it? I manage like 8 services by myself.

Why was this downvoted? I think this is a valid argument. There are plenty of small teams or individuals who have been managing a bunch of small services. Before this was called microservices.

Because it's not a "valid argument", it's snark. The contempt is unnecessary and uninformed.

Re: The Death of Microservice Madness in 2018

#125

Post by wst_ » Mon, Jan 22, 2018, 1:41 AM UTC

I found out recently that people too often think about microservices in context of broader solution like it would be one app, just scattered around. I did that mistake in the past, either. The longer I work with microservices the clearer it is to me that teams implementing them should forget about the big product, just focus on the service, as it would be product itself. Assume that anyone can use it, for any purpose they like, as long as they stick to the contract that is, and you'll be fine.

I tend to have two layers of design, now. One - big picture, which treats services anonymously. Just black boxes that respond to input. The goal here is to build solution like kids are building stuff from building blocks.

Other layer depicts services, as separate beings. They treat all their clients anonymously. They have a contract to fulfill and whomever plays by the rules can be served all right. They should be treated as completely separate projects, have their own backlog, release strategies, etc.

Now, if you would have a product that utilize certain data, would you allow some anonymous guy from the internet tap to it directly? No need to answer, I guess.

Edit: typo

Re: The Death of Microservice Madness in 2018

#126

Post by daxfohl » Mon, Jan 22, 2018, 1:42 AM UTC

zenlikethat wrote: post #114

daxfohl wrote: post #109

Why is scaling independently a pro? I've heard that argument before and never understood it. If I have one api that is low throughput and one that is high, say requires 2 and 20 nodes respectively, then you need 22 nodes whether they are two independent microservices or a monolith. I'd think the monolith would actually be easier to manage as you don't have to worry about how to divvy up the resources. All 22 nodes ru…

It sounds like you're conflating a binary barrier with a service barrier here. In your example you have two cleanly defined services which happen to be in the same binary. The issue with monoliths is when they all do the same thing because the code is a big ball of mud that "cheats" by calling shared subroutines and doesn't have a clearly delineated API. Therefore you have only one knob to turn to scale. The 20+2 dis…

That doesn't answer the question though. Suppose the apis are completely independent. Say one is a chess server and the other generates haikus. Granted that's silly architecturally to put into a single binary, but that's not the question. My question is why specifically managing scalability becomes easier when deploying them independently. My thought is that it actually becomes more difficult as you have to manage each one independently, whereas if they were a single binary, all you have to care about is the net sum of your resource needs.

Re: The Death of Microservice Madness in 2018

#127

Post by mattbillenstein » Mon, Jan 22, 2018, 1:44 AM UTC

Microservices as a mechanism for mainly code organization are just a bad idea. Build a well-organized monolith first -- structure your code as in-process services so that you can factor those pieces out individually in the future.

I see smaller teams heaping in tons of complexity for no real gain; and actual measurable cost.

Re: The Death of Microservice Madness in 2018

#128

Post by cookiecaper » Mon, Jan 22, 2018, 1:48 AM UTC

bri3d wrote: post #96

meddlepal wrote: post #58

Earlier quoted context omitted.

I think it has to do with control. I've written microservices and microservices tooling now for a long time... so long when I started we were just calling it something like (isolated-responsibility) SOA and we didn't have a fancy buzzword. Developers want to own their thing. Microserivces desire springs up because of a lack of communication culture and desire for siloification in a companies organization to keep vari…

Is this truly a management failure? If a few things are true, I could see this as a win: * I can isolate my developers from outside interests using microservices. * My developers are more effective in each dimension (quality, retention/happiness, velocity) because they are isolated from outside interests. * My software is easier to operate and more reliable because it is a microservice. If any of these three things a…

Microservice architectures [usually] represent a management failure because they usually don't work well in the real world. It's easy to concoct a paper-only, theoretical version of an idealized microservice architecture, since you can gloss over all the real-world details and practicalities. Mapping that theory into the real physical world is a whole different ball game.

Conway's Law might as well be renamed "The Law of Microservices". Per Wikipedia [0], it states:

> "organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations."

"Microservices" are on a tear because they make a perfect cover for the blatant and bare expression of unbridled Conway's Law.

Such unbridled expression is much easier in the course of greenfield development, because it lets the core team of 2-3 people per service go about their development work without consulting anyone external. It lets them throw away any overriding convention or cultural concerns, and it avoids the difficulties of cross-group coordination. But it leads to a completely unmaintainable wreck when things transition into production.

This is not to say that no one will have a successful microservice deployment or that it's always a bad choice, but it usually goes way off the rails.

[0] https://en.wikipedia.org/wiki/Conway%27s_law

Re: The Death of Microservice Madness in 2018

#129

Post by Retric » Mon, Jan 22, 2018, 1:48 AM UTC

friendly_chap wrote: post #66

dvt wrote: post #62

Earlier quoted context omitted.

A side effect is by definition some mutation that's out of the scope of the function -- if the purpose of the microservice is to put stuff in a database, then (by definition) it's not a side effect. Switching a flag on top of doing some work, on the other hand (e.g. flip "processed" to true in a global database) is a side effect.

Modifying data in a database is a side effect. Since you brought up the wikipedia definition, here it is: > In computer science, a function or expression is said to have a side effect if it modifies some state outside its scope or has an observable interaction with its calling functions or the outside world besides returning a value. For example, a particular function might modify a global variable or static variable…

Technically it depends on if anything outside the service can see the database and if the state is saved after the service returns. It might seem useless to call a DB if you're not going to save state, but a Rube Goldberg architecture could do so for the lulz.

Re: The Death of Microservice Madness in 2018

#130

Post by Clubber » Mon, Jan 22, 2018, 1:48 AM UTC

HelloMcFly wrote: post #117

st3fan wrote: post #108

Earlier quoted context omitted.

Why was this downvoted? I think this is a valid argument. There are plenty of small teams or individuals who have been managing a bunch of small services. Before this was called microservices.

I downvoted because without context this just seems like the typical know-it-all statement from someone who has yet to realize how little they really know. There's no attempt to even try to appreciate how their situation may be different, just the default disdain so typical from some professionals incapable of thinking outside of their own perspective.

10 people managing a single "micro service" does raise a red flag to me as well. It may be normal based on the complexity, but my first thought is, why is the codebase require so many people to maintain and add features to? Are they just adding features like mad, or something squirrelly in there where most modifications take a lot of man hours?