I built a project once where all the business logic was in modules, and each module communicated through a service which was injected at runtime. This meant I could deploy the entire codebase as a monolith, or just by changing the config files, deploy as independent services. This was done just by injecting a network based inter-module communication plugin rather than an in-memory option. Also the DB service was injected at runtime, so you could alter the config file and point each module at either the same DB or different ones, and also swap the DB drivers as well. Worked pretty well as I recall, and meant we weren't boxed into either architecture until later on down the line when we decided to deploy. Also meant the business logic could be tested independently of how the deployment was to be done.
Great.... What I see and understand after watching Martin Fowler is that many software development companies are migrating their applications to micro-services without skewing the whole context. Not with technical or sufficient discernment, then they do just by fashion. And when the decision is not technical enough, many of these projects go bad or even fail, today's developers are lazy, they do not improve, I see that if we do not have a team of seniors we must invest in the change of our culture before To move on.
If someone reads about SOA principles as of today.. they would think Microservices are just another name for it... I think when SOA came out, companies implemented SOA using current technology at that time and it gave SOA a bad name...
each service have different datastore, surely it will detoriate the app performance, because communication is happening over network, which is again a bottleneck.
I don`t see that a strong reason for using the same data store. The network communication issue can be solved, for example, by having services that communicate to each other deployed on the same data center.
So what would be the alternative? Some services can share the data store but I hear this argument over and over again that it's better if each service has its own.
I love that he points out that asynchronicity increases complexity. I think this fact is often overlooked in software architecture decisions.
I built a project once where all the business logic was in modules, and each module communicated through a service which was injected at runtime. This meant I could deploy the entire codebase as a monolith, or just by changing the config files, deploy as independent services. This was done just by injecting a network based inter-module communication plugin rather than an in-memory option. Also the DB service was injected at runtime, so you could alter the config file and point each module at either the same DB or different ones, and also swap the DB drivers as well. Worked pretty well as I recall, and meant we weren't boxed into either architecture until later on down the line when we decided to deploy. Also meant the business logic could be tested independently of how the deployment was to be done.
Great.... What I see and understand after watching Martin Fowler is that many software development companies are migrating their applications to micro-services without skewing the whole context. Not with technical or sufficient discernment, then they do just by fashion. And when the decision is not technical enough, many of these projects go bad or even fail, today's developers are lazy, they do not improve, I see that if we do not have a team of seniors we must invest in the change of our culture before To move on.
A very precise and concise introduction to microservices. Thanks Martin Fowler.
thanks to Martin with a great explanation about micro services, especially when to use, where to use, how to use & not when to use.
Microservices are good in theory, but in practice there are many problems, i dont think there are many people who know how to do it right
It always delightful to listen Martin Fowler
I feel like I could study under this guy.
I'd be willing to work for free for him for 10 straight years just to know everything he knows.
If someone reads about SOA principles as of today.. they would think Microservices are just another name for it... I think when SOA came out, companies implemented SOA using current technology at that time and it gave SOA a bad name...
Good explanation, Thumbs up!
Where I can get the slides of this presentation?
Nice explanation!!!
each service have different datastore, surely it will detoriate the app performance, because communication is happening over network, which is again a bottleneck.
I don`t see that a strong reason for using the same data store. The network communication issue can be solved, for example, by having services that communicate to each other deployed on the same data center.
that's where docker containers comes to place, in the cloud
So what would be the alternative? Some services can share the data store but I hear this argument over and over again that it's better if each service has its own.
Barely noticeable within the same network
Superlike
Hi there, if i multiple services that they work independently ( will they still be called microservice)?
Multiple services that work independently is just one small characteristic, but is not enough to call it Microservices
If they do not interact at all, I think it's not microservices.
does microservice rise means that the end of soa is coming?
Umesh Dimri i don’t think so, micro service is just a realization of soa.
He pointed microservices as being a subset of SOA. If anything SOA is being reinforced here.
Microservices are a way of implementing SOA....
No, as he mentioned Microservices are subset of SOA... so end of SOA means end of Microservices