When I quit Microsoft and joined the startup company in 2015, the first thing I learned is the concept of Microservices. It was touted as the futur...
For further actions, you may consider blocking this person and/or reporting abuse
Very informative. I could relate to the challeneges we are facing while writing microservices. We really were in a position where we started with 2 microservices but later realised they do not need to be 2 but a single service.
Please get your historic fact right. Martin Fowler isn't the father of microservices. He's not even mentioned in the history section on Wikipedia article
Then from the very article you quoted
Knowing that he his the kind of guy to say "I've been in the group who did that" it clearly refer to other people. Agree though, those people where his colleague at Thoughtworks
And lastly, even if the fact are not rights, please spell his name right, It's not Marrin Flower or Martin Flower!
That's unfortunate because outside the not so hidden self pub, it was a great article.
@cloutierjo Thanks for pointing out the mistake. Fixed it!
Ja, chances are it was simply error correction. Martin Flower (oops Fowler damn text correction) was definitely instrumental in popularizing it 😉.
You really know me well. 😆
Stop using the terms monolith and microservice.
The concepts are distributed vs remoting. You can even setup API’s to do both. And I said can. Not that it should do both.
Martin Fowler is wrong in using monolith. He should say big-ball-of-mud. Linux 1.2a kernel was the last monolith. And the famous debate changed it, to this day, from being one.
gRPC, GraphQL, and message queues/event stores are not microservices. No matter how closely you try to get it to fit. Or even by extending microservices.
These are all remoting
Distributed means a registry like npmjs, nuget, github/gitlab, local, has a copy you pull into your project and use. Or an installer you download.
The question isn’t how remoting and distributed are different. But how are they similar? How are they the same?
It a website needs to do something secure, use remoting.
If functionality needs distributed, use distributed.
If what that otherwise distributed resource needs protected, use remoting.
There is more value in discussing the type of app you are writing:
Right, and noone said it was. Instead, what the author said is these technologies help you keep headcounts small, which helps you avoiding the multi-team (and thus microservices) necessity.
That would mean blockchains / Starlink / cell service / the us postal service aren't distributed systems. I would look up the definition of distributed system again. Distrubuted systems (even distributed computing) are so much older than package registries.
How can you divide your monolith into micro pieces while all your data model and their RELATIONS defined in a one large module. The models strongly related to each other and they are defined as an exactly one big model.
If some data have a hard relationship with each other inherently, then I guess they are supposed to be together. I think the benefit of having a data model schema is that you can identify that relationship quite clearly. Therefore, if you want to split your monolith into micro pieces, you can start to do it from the schema(data layer). Martin Fowler has another post about it you could check it out:
How to break a Monolith into Microservices
This is where things get separated between monolith and microsrv. In microservices env you cannot keep it DRY. To some degree you will have data duplication.
Say you have a social network. You have 2 microsrv. When someone coments you need to notify the post owner. How you do it?
In most of the case you have the user id, right? The author id. So on the notification service you will do a query with that id to get the rest of the data: email or phone number.
The problem is that data modeling in most of the cases is done all wrong by logical scope not business scope.
It's a phone number or emal, than it should definetly stay on a service called user manager, right? No? Data should be atomic and be store where needed.
But to sync that? Well that is a different story. This is where event driven design comes into place. I will not dive into it because it a topic many people don't like because it's "hard".
I use graph whenever possible and I am happy. No tables just data types. Table border creats confusion. In my app an USER can be called to PHONE NO. and weres size X on CLOTHES, drives CARS. Done, simple and stress free :)
typos
Nicely put - but can't agree with the article.
Microservices need to be coupled with containerization, iac, ops, container orchestration, data management, deployment, service orientation, eda, and git/vc development principles (not finite). "Unless" the team identifies the right tools for each job, the task will always have "increased development complexity" and "organizational overhead". Navigating through the ocean of choices is what an architect should do; and pick the leanest tools to carry on the hipbelt.
It is "hard" for development teams who have built monoliths to "unlearn" and now "think" microservices, events, streams; i.e. after the decision has been "voted in".
Developer experiences are critcal, and when the developer is abstracted away from the underlying complexity of iac, and other base APIs/fns - writing BL with MS is then simpler.
The linked Shopify articles quotes "If no architecture is enforced, the result will likely be a monolith." :) Stunning!
MS is not a toy - but coupled with the learnings involved is super fun!
I almost agree with every statement you made. To be clear, I’m not anti-Microservices but rather wish to ensure that individuals are aware of the costs involved and have knowledge of alternative options. There is always a trade-off, but I think that’s the beauty of the software development world.