In Defence of Monoliths • Hacker News Board

Re: In Defence of Monoliths

#21

Post by wvenable » Fri, Oct 23, 2015, 7:25 PM UTC

vonmoltke wrote: post #14

optimuspaul wrote: post #6

Earlier quoted context omitted.

I've actually found overhead to increase significantly when using micro-services vs a monolithic codebase. Automated integration testing is far more complex. Ensuring that a change in one micro service doesn't break things in another can be daunting. But when you have a common codebase dependencies are far more clear. Of course if you have tons of cash and resources to throw at it then that isolation could be benefic…

> Ensuring that a change in one micro service doesn't break things in another can be daunting. That is what I was referring to when I mentioned nebulous APIs. In a properly-designed system, each component (be it a module of a monolithic system or service in a microservice system) should be a black box with known APIs and no side effects. Part of defining the API is defining the acceptable values that can come across…

The more your system is broken down into smaller components the more you have to break an API to make a change. Unless all change consists of nothing but bug fixes and performance enhancements, changes to the API is as common as anything else.

If your need is respond quickly to changing requirements this setup falls flat.

Re: In Defence of Monoliths

#22

Post by Thaxll » Fri, Oct 23, 2015, 7:25 PM UTC

DanielBMarkham wrote: post #18

Being a new "convert" to microservices, and coming from a classic OOA/D/P background, I read these critiques with great interest. I keep waiting for one that shows me what I'm missing. What I'm finding, however, is that many of these authors have such a broad understanding of microservices are that they miss any benefit. Then, of course, they complain about there not being any benefit, natch. I suspect -- and what I…

"- Each microservice has less than 150LOC"

Sounds like a nightmare, you know how much instances / vms you need if you spawn one thing for 150LOC?

Re: In Defence of Monoliths

#23

Post by vskarine » Fri, Oct 23, 2015, 7:29 PM UTC

DanielBMarkham wrote: post #18

Being a new "convert" to microservices, and coming from a classic OOA/D/P background, I read these critiques with great interest. I keep waiting for one that shows me what I'm missing. What I'm finding, however, is that many of these authors have such a broad understanding of microservices are that they miss any benefit. Then, of course, they complain about there not being any benefit, natch. I suspect -- and what I…

don't you think 150LOC is a bit extreme on the low side? I don't see how this is possible unless you compose services out of other services... and in that case it's probably a nightmare to debug anything. Can you elaborate a bit on types of things that this worked great for you?

Re: In Defence of Monoliths

#24

Post by DanielBMarkham » Fri, Oct 23, 2015, 7:32 PM UTC

Thaxll wrote: post #22

DanielBMarkham wrote: post #18

Being a new "convert" to microservices, and coming from a classic OOA/D/P background, I read these critiques with great interest. I keep waiting for one that shows me what I'm missing. What I'm finding, however, is that many of these authors have such a broad understanding of microservices are that they miss any benefit. Then, of course, they complain about there not being any benefit, natch. I suspect -- and what I…

"- Each microservice has less than 150LOC" Sounds like a nightmare, you know how much instances / vms you need if you spawn one thing for 150LOC?

Nobody said anything about 1 VM per microservice. You're using the term "service" in a way I did not intend (and which is a carryover from other kinds of services)

This is illustrative of the point I was making.

One of the big benefits of microservices is the total decoupling of the code from the underlying hardware. Things are glued together by Ops, not by code. So you might have all the microservices in one VM -- or spread copies of one critical microservice across a thousand vms. It's all configurable.

Re: In Defence of Monoliths

#25

Post by cpitman » Fri, Oct 23, 2015, 7:37 PM UTC

optimuspaul wrote: post #6

vonmoltke wrote: post #5

Earlier quoted context omitted.

I don't see how microservices makes that overhead go away. That overhead is really a matter of proper systems engineering. With well-defined interfaces and properly-sectioned functional components teams can work just as independently on a monolithic application as they can on a microservice application. Similarly, a poorly-sectioned application with bad or nebulous interfaces will be a planning and coordination night…

I've actually found overhead to increase significantly when using micro-services vs a monolithic codebase. Automated integration testing is far more complex. Ensuring that a change in one micro service doesn't break things in another can be daunting. But when you have a common codebase dependencies are far more clear. Of course if you have tons of cash and resources to throw at it then that isolation could be benefic…

In most environments systems are already distributed, it's just that each "component" is a massive monolith. Sometimes, it's the cobol monolith, the .Net monolith that partially replaced it, and the NodeJS monolith that is going to replace everything (for sure, this time we mean it).

Integration testing is already complex in these environments, regardless of whether the components are monoliths or microservices. BDD style integration tests should be almost equivalent, regardless of the architecture, since they are driven by the business domain.

Re: In Defence of Monoliths

#26

Post by Thaxll » Fri, Oct 23, 2015, 7:37 PM UTC

DanielBMarkham wrote: post #24

Thaxll wrote: post #22

Earlier quoted context omitted.

"- Each microservice has less than 150LOC" Sounds like a nightmare, you know how much instances / vms you need if you spawn one thing for 150LOC?

Nobody said anything about 1 VM per microservice. You're using the term "service" in a way I did not intend (and which is a carryover from other kinds of services) This is illustrative of the point I was making. One of the big benefits of microservices is the total decoupling of the code from the underlying hardware. Things are glued together by Ops, not by code. So you might have all the microservices in one VM -- o…

I don't understand properly the term micro service if services aren't separated in a "network" way.

Re: In Defence of Monoliths

#27

Post by cpitman » Fri, Oct 23, 2015, 7:40 PM UTC

DanielBMarkham wrote: post #18

Being a new "convert" to microservices, and coming from a classic OOA/D/P background, I read these critiques with great interest. I keep waiting for one that shows me what I'm missing. What I'm finding, however, is that many of these authors have such a broad understanding of microservices are that they miss any benefit. Then, of course, they complain about there not being any benefit, natch. I suspect -- and what I…

Do you subscribe to the idea that services should correspond to "bounded contexts", ie a business domain? And if so, what do you do when a bounded context is too complex to fit into 150LOC?

Re: In Defence of Monoliths

#28

Post by Walkman » Fri, Oct 23, 2015, 7:46 PM UTC

unoti wrote: post #12

There's a dangerous, contagious illness that developers of every generation get that causes them to worry about architecture and getting "street cred" even more than they worry about solving business problems. I've fallen victim to this myself, because street cred is important to me. But it's a trap. An important meta-idea that encapsulates all of this is remember to solve your business problems as your first priorit…

I agree with you, but the opposite of this is also horrible. I'm working for a company where they only focused on business needs, and the result is horrible. Terrible, unwieldy codebases, full of bugs, have no security at all. It's hard to develop features, it suffers from feature creep, have absolutely no test coverage at all.

It's important to find balance.

Re: In Defence of Monoliths

#29

Post by rcconf » Fri, Oct 23, 2015, 7:48 PM UTC

We've had a lot of issues with micro services. They're extremely difficult to debug and end up being too generic. I argue the reasons why we introduced microservices has merit (massive code base) but does not mean they are simple to use/maintain.

Here are some examples:

1. A chat service (race conditions, synchronization issues between the game server and chat service that had to be debugged using sequence diagrams)

2. A payment service that handled Facebook, PayPal, and other payment methods. (race conditions, complicated integration, difficulty upgrading for different products, complicated code base to handle multiple use cases)

3. An authentication service (complicated protocol, hard to integrate)

4. A worker service for handling bcrypt (because blocking a single threaded server for 0.5 seconds is not acceptable, race conditions)

5. A tracking service (could have probably just been a library you included instead of hitting an API)

Core issues:

- Race conditions

- Synchronization issues

- Complicated to upgrade/maintain for multiple products

- Become too generic and solve multiple problems (services tend to be used for multiple products in the company)

- Extremely difficult to debug

- Complicated error handling for when a service is not reachable

pro-tip: don't share databases between multiple products for each service, deploy a new service for every product with its own database.

I think I'm scratching the surface here, but I would be really careful with introducing this kind of architecture when you can do it all in one server.

Re: In Defence of Monoliths

#30

Post by brianmcc » Fri, Oct 23, 2015, 7:49 PM UTC

unoti wrote: post #12

There's a dangerous, contagious illness that developers of every generation get that causes them to worry about architecture and getting "street cred" even more than they worry about solving business problems. I've fallen victim to this myself, because street cred is important to me. But it's a trap. An important meta-idea that encapsulates all of this is remember to solve your business problems as your first priorit…

Ha, so true. Learned that lesson with Rational in my case :-)

Plus the compulsory EJB pain. I found it quite liberating to be able to just abandon EJBs once it became clear what a disaster they were without having to do do the Emperor's New Clothes bit.

I kind of share the scepticism about shiny new paradigms now, but one does have to be mindful not to inadvertently reject good new things because they're new.