Microservices are a plague on the industry. It's just as bad when OOP was introduced. I wish they would go away.
Don't start with microservices – monoliths are your friend
441–450 of 468 posts
Re: Don't start with microservices – monoliths are your friend
#442Monolith and Micro-services at different times during the progression of a business can have their places. I have experienced the pains of having to work with both within the same company over 9+ years and here is what I think are forces that can pull you in either direction. A monolith makes developing initially a lot easier. Over 15 years though, you are bound to have developers of various calibre leave their mark…
> Eventually, your team will flip the table and start thinking how to avoid the problems they are having with the monolith and decide to do down the micro-services way. So, yet another comment saying that modularity requires a distributed system.
That's not what I was saying. I'm saying your team is likely to want to do something drastic and is likely to go down the micro-services path. This is not a comment on correctness. This is a behavioral prediction.
Re: Don't start with microservices – monoliths are your friend
#443Earlier quoted context omitted.
Because there is no newly invented architecture called "modular monolith" - monolith was always supposed to be MODULAR from the start. Micro services were not an answer to monolith being bad. Something somewhere went really wrong with people's understanding and there is bunch of totally wrong ideas. That is also maybe because a lot of people did not knew they were supposed to make modules in their code and loads of m…
> Micro services were not an answer to monolith being bad Micro services today are mostly used for one purpose: to be able to ship your corporation's org chart.
Not really. You could do the same by having different organisational units being responsible for different libraries. And the final monolith being minimum glue code combined with N libraries. Basically the same way your code depend on libraries from other vendors/OSS maintainers.
Re: Don't start with microservices – monoliths are your friend
#444I wonder why no one ever talks about architectures in the middle between those two - modular monoliths. The point in time where you're splitting your codebase up in modules (or maybe are a proponent of hexagonal architecture and have designed it that way from the beginning), leading to being able to put functionality behind feature flags. That way, you can still run it either as a single instance monolith, or a set o…
> hexagonal architecture Tried it twice, never pulled its weight. It introduces abstraction layers everywhere, as a premature optimisation, even though they might never be needed, and its a bad fit for more verbose and statically typed languages due to all the ceremony thats required. Anyone made similar experiences?
I use it all the time. It is my default architecture choice. It works great in my opinion. I wonder why you think there is a lot of ceremony needed? The core idea doesn’t require much. The Hexagonal Architecture idea can be implemented in many ways. I recommend Googling “Elm Architecture” to see an example. It isn’t described as being a Hexagonal Architecture but I will argue that it is one of the best ways to implement it I have seen. It has zero ceremony (a few functions define the whole architecture).
Re: Don't start with microservices – monoliths are your friend
#445Earlier quoted context omitted.
In some languages, you can enforce boundaries within a monolith nicely using the build system. The key is to break the build up into a hierarchically structured set of libraries somehow where each library only gets to use those libraries it is allowed to depend on architecturally. Independent bits of business logic would need to go into libraries that cannot "see" each other when they are compiled. Everything would s…
I think you didn't quite get the point of engineers of different levels of quality, talent and opinions working on the same monoliths. Eventually they tear down any boundary, even those in the build system. Developer discipline is something that eludes many companies for lack of enough high quality engineers and awareness for the problem in upper management. It's easier to quibble over formatting guidelines.
So your argument is that bad developers will mess things up. I am sure most would agree with that argument. What does that have to do with monolith vs. micro-services? Bad developers will make a mess of micro-services as well.
Re: Don't start with microservices – monoliths are your friend
#446Former Netflix engineer and manager here. My advice: Start a greenfield project using what you know (unless your main goal is learning) keeping things as simple as possible. Microservices is more often an organization hack than a scaling hack. Refactor to separate microservices when either: 1) the team is growing and needs to split into multiple teams, or 2) high traffic forces you to scale horizontally. #1 is more l…
What would stop you from splitting the monolith into libraries and having different teams maintain those libraries? It seems to give you the organisational advantages you want without paying the added networking complexity cost. The way I see it, a micro-service is a library + networking. Remove the networking and you have a library that can be compiled into a monolith.
Re: Don't start with microservices – monoliths are your friend
#447Microservices requires lots of forethought, design, and highly qualified engineers.
You spent the same amount of forethought, design, and talent on monoliths - you’d might not need microservices.
The real issue is scale.
A well designed micro service mesh will scale. A well designed monolith might scale.
Re: Don't start with microservices – monoliths are your friend
#448The previous button does not work on mobile to read the Java interview article
Re: Don't start with microservices – monoliths are your friend
#449> If you’re going with a microservice: A Kubernetes cluster A load balancer Multiple compute instances for running the app and hosting the K8S cluster Try running a high-traffic high-functionality website without something equivalent to this. What's this magical single computer you'll be running it all on? You'll need a cluster of servers on a rack somewhere, managed the old fashioned way. You'll need equivalent tool…
does stackoverflow count as high-traffic, high-functionality? pretty sure most people here would be very happy for their startup to have that level of traffic. it's no longer a single computer, sure, but, last time I read about it, it was monolithic.
Stack Overflow is an example of a website with predictable traffic patterns. There's no Black Friday for Stack Overflow.
Re: Don't start with microservices – monoliths are your friend
#450Earlier quoted context omitted.
> Micro services today are mostly used for one purpose: to be able to ship your corporation's org chart. And, this is not necessarily a bad thing.
The problem is that orgs are not set in stone. Teams get merged and split in reorgs, buyouts and mergers happen, suddenly your microservices designed around "cleanly defined boundaries" no longer make any sense. Sure you can write completely new microservices but that is a distraction from delivering value to the end customer.
So? The solution is that services travel with teams. I've been through more than one reorg. That's what always happens. The point is to have clear ownership and prevent conflicts from too many people working on the same code.