If you can't build Microservices, what makes you think you can build a Monolith?

[@tomaszenko13]

- It is not about me, but the whole team - It is easier to fix dumb design decision in Monolith than in Microservices - Data consistency is not a problem - Tracing/debugging in not a problem. Whatever garbage code I look at, I can simply place a breakpoint and step into it.

[@mounirboudraa1515]

You can do exactly the same thing with microservices. I'm not sure how it's a monolith specificity

[@mounirboudraa1515]

@@pierre9368 that is not true. This approach is exactly why microservices end up being a nightmare to maintain. Microservices are not a solution for team scaling pb. It's a solution for scaling boundaries indépendantly. And many teams can work on a single boundary.

[@mounirboudraa1515]

@@pierre9368 Not sure if you're sarcastic or not. But I meant saying that microservices is a way to organize teams is the worst take on microservices. It's litterally the reason why microservices are a nightmare. When building a feature that has value for a company there's always multiple boundaries involved. So a single team will never be able to achieve anything if they can't change code that "belongs" to another team.

[@josersleal]

@@mounirboudraa1515 no you cant. its disconected unless if you run them all at once and place breakpoint everywhere literally. since th eteam owning the other one will never allow your dirty pawns into their code, you are fd wiseguy

[@josersleal]

@@pierre9368 what? made no sense

[@roeiohayon4501]

My team is OBSESSED with turning everything into a microservice. No matter how many times I've explained to them that there are siginifcant drawbacks they are just so fixated on that. What's worse is that our hands off team leader agrees with that approach because of a lack in experience.

[@CodeOpinion]

Yikes

[@ViniciusMiguel1988]

it sounds like you need a new job

[@thisdyingsoul666]

If you solve the coupling problem and them apply the question of monolith vs microservices, still monoliths are way easier to manage. And you still can have hybrid architectures where most of the systems are in a monolith and the heavy ones that need scaling can be microservices.

[@FilterChain]

It's not true at all, I find micros 100 times easier to manage I pop the service in vwalla the model and domain is set, I know what it's doing right off the bat don't have to worry about anything else, easy to update easy to deploy easy to debug

[@stroiman.development]

There is a strory in the book, "Building Microservices", by Sam Newman, when they set out to create new CI / Build server software based on microservices. But they failed to identify good boundaries, and as a result they merged the code to a monolith. Over time, the monolith was refactored, and sensible boundaries was discovered; and then extracted into services again. And this wasn't the first CI software they build; this was a domain with which they were familiar. p.s. I wrote this from memory, it's quite some time I read the book, but I'm fairly certain that it is a correct. That particular case did make an impression on me when reading it. (probably the only thing I actually can remember from the book, but probably also the most important lesson)

[@CodeOpinion]

Realigning boundaries can be tricky, especially if you've got a ton of coupling already. It's absolutely feasible but it's easier to pull apart than to put back together IMO.

[@JeffryGonzalezHt]

Great points. I feel like we are in a death spiral of constantly changing the definition of a "microservice" and arguing about it. We've been doing distributed applications for a long, long time and the problems don't change because of the "size" of your process.

[@phillipsma]

Derek, I've just had this very conversation tonight. It's so frustrating. Microservices no longer are cutting it, we want Modular Monolith instead. But nobody is getting to the root cause of the problem and understanding logical separation does not equate the same a physical separation. Think about minimising coupling, not about deployment is my aim. Isolate the problem domain

[@phillipsma]

What I meant is that modular monolith is no different from microservices. It doesn't isolate the problem domain properly at all. It serves deployment only

[@aleksandartrifunovic5142]

​​​@@phillipsma my experience is a bit different, they started with microservices, turned out it was too complicated, they wanted a monolith, turned out it was complicated, now, they want a distributed monolith :)

[@marcotroster8247]

I was brought into a refactoring project as a freelancer some years ago. They had a monolith with service classes. One of those services queried a list of ids, then another service provided a single item per id. And there were all kinds of services for everything. Loading a list of items in that website took about 9 minutes. This project was beyond repair. Then our PO tried to reach out to users to interview them and could hardly find one user. This user told "Oh, don't you know, everyone just calls the hotline because the website is so bad". Yeah well... I wouldn't wait 9 minutes either.

[@djglxxii]

I briefly worked at a company where we were developing an application for a client. It was a typical n-tier monolithic structure. After several months of development, the **client** came back demanding that the application be refactored into microservices. Has anyone else had a client request something like that? It was already a disaster, so I ended up moving on to another company.

[@CodeOpinion]

I feel like this isn't that uncommon.

[@Cesar-qi2jb]

Microservices are an organizational approach Accepting increased technical complexity in exchange for decreased organizational complexity (e.g. independent deployments)

[@wbiller]

Finally, someone actually asking if they can code, and not hide by running after the next hype 😂😂😂

[@UnknownSoftwareArchitect]

Great Video! Focus on the problem you want to solve, and not your technical setup. That is why I focus on what to build first and start with a simple technical setup - a modular monolith with separation by features not technical concerns.

[@FilterChain]

I think the issue is due to experience, if you havent deployed a successful micro you wont like it . But if you have you love it, man has it saved me headaches

[@UniXoiD69]

Thank you very much Derek! I think that the only reason to opt for microservices (even within a monolith, which we might call a 'citadel' architecture, making the microservices 'outposts') is when there are very specific non-functional requirements, such as data encryption/security due to legal constraints or current technological limitations (for example, integrating a Java monolith with an ML neural network).

[@barongerhardt]

Both are fine and what to use is should mostly be picked by specific situation. Past that it is just one of those things that swings back and forth in popularity; like thin vs thick client, or cloud server/client vs native. The real problem comes in when either using bad design (eg: over coupling) or not taking the domain specific requirements into account.

[@patriceroy7238]

Coupling issues in microservices architecture are always related to poor design choices. If each microservice has a clear and defined boundary that revolves around a particular domain within a system, they logically wouldn't have to speak to each other. The only cases where they have to communicate together is to run synching commands between them. And that should always be done using a pub sub system. Which creates no overhead as it's an out-of-sync command - not a query. As you say, odds are if you make a rats nest out of a microservices architecture, you'll make it even worse in a monolith system. Because as tedious this communication/http overhead is, it tends to force you to think twice before implementing a change.

[@CodeOpinion]

That's pretty much as summary of the video! 😂

[@Nots88]

Derek Coupling is back again! We just recently had a discussion are we building microservices or distributed monolith. About what you said in the video, the main reason to choose microservices is scalabilty, but you pay for with time for network calls. But in return you receive freedom of which database choose for each of the services, e.g. , thus you can take back time for network calls. In general I agree with the thought, that it doesn't matter is it application or service or 2 classes, it's all the same - coupling. But maybe it was not your point to say "go back to monolith since you can't write microservices", but it looks like so IMO

[@xilconic]

Not sure if I'd call scalability "the main reason" to opt for micro services. I'd say it can be one of the reasons. Examples of other reasons to consider opting for a (micro-)service oriented architecture, over a Monolith: * Using a particular technology/language for a particular problem space (Example: using Prolog for some reasoning solution, while using C++ for 'generic software solutions' within a company) * Security constrains where part of the application can be made available (Example: Game client vs Game server as part of anti-cheating measure) "But in return you receive freedom of which database choose for each of the services", I'd have to disagree. You probably also have that freedom within a monolith, but never considered doing it because people can be prone to thinking '1 tech stack => 1 persistence solution', which does not need to be the case. If using 2 different methods of persistence for 2 different scenarios is worth the complexity, then what's stopping you from doing it in a Monolith (or a (micro)service oriented architecture)? Especially if those persistence solutions are already running on their own remote servers from the Monolith itself.

[@Nots88]

@xilconic Well, I agree, you also have this freedom, but never considered doing it, actually nothing stops you, but limitations in your brain

[@nexovec]

"It's just a network call, how bad could it..." 💥🌩

[@nexovec]

Aaaand you now need tracing, congratulations.

[@FilterChain]

Microservices are very helpful in my domain, where we can not afford coupling to mission critical features. We are now the only team that deploys anytime. what makes the monolith seem easier is that the teams are used to it and cant design microservices correctly. They compain but i can very easily trace all of the services make changes and deploy. Microservice top tip separation of concerns

[@onaspnet]

A company's software architecture is a direct reflection of its organizational structure. For instance, if you have multiple divisions using their own CRM, you will have multiple 'Customer' entities. This is neither a microservices or a monolith problem. It is a business organizational structure that needs changes. Coupling is inevitable when you are trying to put lipstick on a pig.

[@TonyC-esw]

Agreed mostly. Just can't figure out why a damp bathrobe thrown over the chair makes it into the set 😉

[@CodeOpinion]

haha, it's a blanket!

[@qj0n]

One more benefit of the monolith is that it allows pushing the boundaries between domains much easier. Of course, both are OK, if you have your boundaries correct. But it's naive to believe that you will design boundaries well from the very beginning Monolith is what Dave Farley calls "assume you are wrong" approach

[@NickSteffen]

The problem isn't buiding the microservice the problem is building the deployment pipelines for 10 microservices and building 10 HADR and backup plans for each microservices databases and creating 10 different security, code quality scans for microservices. Updating random packages for 10 different microservices. The biggest problem of all is updating and maintaining all of the things I just mentioned because most developers hate working on those things and the one guy you've told to go figure it out is doing ten times as much work as he did on the monolith. Then boom you now have to have platform engineering in each development team instead of at the org level. You should be implementing your domain in code and not infrastructure. There is an optimal size between micro and monolith. It is most assuredly not at the far end of either spectrum. Generally speaking if the same team works on it and it's in the same product it should probably be one thing. So yeah building is fine it's everything else that is terrible. It works for larger orgs that can split ownership up but for smaller teams it's paralysis.

[@Circe-wz3kg]

Cant nvme over tcp and similar technologis fix the network latency issue?

[@iliyan-kulishev]

I'm a naive junior developer. I feel like we can just have HTTP APIs for the front end requests and everything else can be just packages that just write and read directly from databases. I still cannot grasp why making network requests for different parts of domain logic.

[@georgemdonnelly]

should architecture decisions follow organizational structure? Conway's Law says so but I think a modular monolith can help reign in some micro service headaches.

[@abogdzie]

I would ask this question the opposite direction as micro services require more discipline.

[@AlbertCloete]

What makes me think I can build a monolith? I've done it many times. Much easier than microservices.

[@FilterChain]

You probably already do microservices, database vs backend vs emails notifications vs cron jobs ... the answer to everything is it depends

[@Mancholino17]

I have a really dumb, really simple question - if need arises to, for whatever reason, identify that it's that same employee in two different places - how do we manage that? I seriously have no idea how would one go about it.

[@bernhardkrickl5197]

You define some ID of an employee that you share between different departments/modules. You then define which module is responsible for which parts of the data associated with the employee. Some of this data maybe shared with other modules, some not. You may even have redundant copies of parts of the data in different modules. You just need to be aware which module is the owner of the data and how the redundant copies are distributed, or updated. This all depends on the actual use case.

[@machadoit]

I can share my take on it, I would expect that the ownership and 'real id of the user' to be managed by the component that creates or deletes the user itself. So in this case, let's say HR would create the user with its basic info with its unique identifier. Then the IT department would store some domain specific info on IT side that would reference that unique identifier that was attributed by the HR

[@jonathangalliher4474]

If you're looking at something like authentication and authorization for company employees, I'd expect the former to be delegated to a third-party application, like Active Directory or whatever Google uses. You could probably roll your own, but doing so seems extremely likely to be a mistake, although it would be much less so if you're looking at tracking customers instead of employees. For the latter (authorization), I'd expect it to be a mix as far as where things live. Plenty should live in a User module within your app, but a common pattern is to use something like AD group membership in combination with app configuration. The User module in your app should only track whatever attributes are relevant for that app. Please note, you almost certainly don't want to have your entire business in a single, company-built-and-maintained app. Your company may functionally be a single application, but core, common business functions, like HR, managing sales pipelines (if you're a product company), work tracking, and source control should practically always be entirely separate applications and use off-the-shelf products; not be defined as modules within your app.

[@Mancholino17]

@@machadoit ok, that makes sense, but then how are we achieving decoupling when each service that has some employee data, also always has to reference some central ID so that we can know who is who? Then, there is a single source of truth for every entity, and we're back at square one - modeling our software based on data rather than business needs.

[@Mancholino17]

We really need concrete examples, or evidence of the cohesion being achieved in microservices world. The discussion alone does not cut it

[@Kabbinj]

Whatever happened to good old macroservices? Way less orchestration, while still being able to scale horizontally?

[@Eirenarch]

The fact that I have built one before and it is working in production and making money?

[@CodeOpinion]

Win

[@FilterChain]

So basically expirence, for iot it's the opposite the microservice are in multiple productions and making money

[@Eirenarch]

@@FilterChain sure but I'm not the one asking what makes you think you can build microservices :)

[@alanthomasgramont]

I see the issue as creating to micro of a micro service. Your microservice should serve all the business needs of that domain. However, you still run into an issue. If all your microservices need the user's address, each microservice will need to go get the address. That could mean 4 calls for 4 different domains. If that user service is having issues, that issue is multiplied across each microservice call.

[@marko5734]

Can redis cache help here?

[@alanthomasgramont]

@@marko5734 I think caching anywhere is helpful. We even cache within the service for often squires but rarely changing data such as a list of states.

[@All-in-on-GME]

Why can't each microservice keep its own store for this and subscribe to changes it needs? Then services that need to eventually get user information are not coupled with the actual user microservice, if user microservice goes down your microservice still has its own user data

[@alanthomasgramont]

@ because the address might be maintained by an HR service that is gated behind a micro service. HR would want to log any time any service gets user data to assure its tracking PII access, etc. the database wouldn’t be directly accessible.

[@All-in-on-GME]

Yep, exactly. Changes from HR are published. The 4 microservices are subscribed to those queues. No one goes down because HR goes down. When HR comes back up, it begins where it left off and continues to publish changes. There should be no down time related to HR failing in this setup.

[@josepgsampaio]

🤝

[@smaug9833]

It's not just about network calls between services. It's also about the developers building them. In a monolith, we are at a disadvantage because developers mainly responsible for one particular area of the application need to have good knowledge about the other parts. This can only happen if the Devs working on the monolith stay on the project for years - which is not realistic - people keep changing teams and jobs frequently. We have to face reality. In microservices (with good established contracts for communication) this problem disappears. Separation of responsibilities helps a lot. Developers of service A can go away with having a rudimentary understanding of downstream services.

[@yuriy5376]

This issue is solved for the most part by modular monoliths

[@josersleal]

as soon as you add another person to the team, it becomes tech debt and starts to wrotten. bs oppinion

[@kittipongpiyawanno315]

Yes, business logic over data structure. But data structure has much more impact on the system. Business logic can be mostly changed at ease, but not the data structure.

[@westlestrest6442]

I think the video was literally saying the opposite

[@kittipongpiyawanno315]

@@westlestrest6442 Yes and I partly disagree with the video. You start with business logic and everything else must be designed according to it. But business logic will rely on data structure not vice versa. Hence, data structure is much more difficult to modify.

[@westlestrest6442]

@kittipongpiyawanno315 you are the first person that I have heard who said this. I think it's universally accepted that data structure doesn't matter. No one gives a crap about it unless you are in academia or working on a thesis. If you try talking about data structure to your customer you'll pretty quickly see that they don't care. They just care about functionality. So I think it's pretty naive to say business will be based on data structure

[@kittipongpiyawanno315]

@@westlestrest6442 Of cause, users don't care about data structure, and it should be hidden from the users. But as a developer, I care a lot. Encapsulation with OOP can reduce the problem but not get rid of it. Data must be stored somewhere, and the data structure with them. NoSQL cannot solve but escalate the problem. You must not believe me. But from my experience, if the data structure fails, the whole project will go down. If the data structure is solid, the business logic can be changed according to the user requirements, which are unfortunately changed all the time.

[@marcom.]

I think the question of building a monolith, microservices or anything in between should mainly be a matter of deployment decisions.

[@FlaviusAspra]

I had to laugh at "you have a stacktrace". Lol. No you don't. It's all getters and setters, the wrong set was called in a completely different part of the call tree, not on your stack, and the stack trace you have is completely useless. Worse: misleading. Sure, in a well designed system it's not like that. In practice, the only system build like that was the one I build as a CTO.

[@westlestrest6442]

What are you talking about? Have you never seen a stack trace?

[@FlaviusAspra]

@westlestrest6442 have you ever seen one which points at the root cause? 99% of the time it's like this: you go there where the stack points you at, you spend a day trying to understand what happened. And it turns out a setter was called wrongly or not called in a completely DIFFERENT part of the code, which takes sometimes a few more days on top to find. Got it now? I have worked on systems not filled with setters called ad-hoc and guess what. 99% of bugs were fixed and rolled out in under an hour. That's because the root cause was 99% of the time also right there on the stack trace.

[@westlestrest6442]

@FlaviusAspra What do you mean by "setters"? can you explain? Only setter I know is the "getter" and "setter" other than that the stack trace will tell you what the problem is. Figuring out how to understand and fix that is your job as an engineer. That's part of the job. So if your experience has been different, I am sorry but that sounds like skills issue or you not understanding the language you are working in