Looking for books & other references mentioned in this video? Check out the video description for all the links! Want early access to videos & exclusive perks? Join our channel membership today: ua-cam.com/channels/s_tLP3AiwYKwdUHpltJPuA.htmljoin Question for you: What’s your biggest takeaway from this video? Let us know in the comments! ⬇
An episode on data ownership, pull vs push and how to work with data that you cannot store, but only access on demand from external services would be cool.
the fact that the main benefits of microservices should be that you can scale delivery by making teams autonomous is rarely covered in any presentation or blog. this video should be required viewing for teams attempting microservices. 👍🏻
Microservices are more than just splitting code into "services" running in Docker containers: It is a way of continuously developing and organizing a system consisting of services. The rest about message queues etc is just infrastructure. As someone said: It is about ownership.. If you don't understand separating concerns and responsibilities both in code (the boundaries of the services) and team, then it is just a glorified service-based architecture. If one team is responsible for developing and testing everything then it is not really microservices. You cannot successfully implement Micro Servcies without some kind of Domain Driven Design in mind.
"Microservices are more than just splitting code into "services" running in Docker containers" Things can be even worse: just copy the bad written, clumsy legacy code to several servers, wrap some http-FooBar around it, and call it microservices. And insist to make that Microservices-thing being developed in a one-person-plans-and-deicdes-everything (of course it's the person with the lowest quality standards, but the one who is in the project for the longest time, which gives authority), while the new developers with the higher quality standards and with the mind against the cathedral, will just be stopped and possibly even mobbed. "We are doing it since 20 years that way". I think many people here are complaining on a high level. There are companies where things are much worse. Conway's Law is my witness, that those people (in our company) who always talk about microservices and other 'gadgets', while insisting that the brokenb legacy code is untouchable, will not succeed. First write good quality code (it is cleanly seperated anyway), then think about 'microservices'. This talk was so great, because it pointed to the "copy our intricated spaghetty code to all servers and wrap REST (or anything else) around it - then we have implemented Microservices" is bogus!
@@smallsnippets This is EXACTLY what my last company did. They had a monolith application and the developers told management that they could move this to a microservice architecture in 2 weeks. It took them 4 weeks, but they basically just split the code up by API calls into separate services. All of which used the same database, and were coupled together. They had no clue what they were doing. As a developer, I warned management, but they didn't understand. Management thought they had a much better product that could be scaled easily. I left after this (and other awful practices they chose to do). They'll find out soon.
Thank you for clearly explaining what many people I work with say we need to be doing, but then don't expect any time or effort to be spent putting it in to practice.
I really like that you highlight the costs in addition to the benefits. This makes you appear credible and not just as a software methodology salesman.
@@ContinuousDelivery Sorry, I didn’t mean to offend. I just think that too many techtalks in general are delivered in order to make you believe that OOP, or functional programming or nosql is The Solution to every possible problem :)
@@krumbergify No offence, I meant it. I have my preferences, but my goal is to find ways to build better software faster, and if that meant that I had to drop all of my opinions, I would do so happily if I found somethin better. I am starting to think of myself as a "Software Engineer" in some specific definitional ways. What that means to me is that I don't want to, ever, play only lip-service to an idea. I will express my opinions as clearly as I can, and hope to be corrected where I am wrong. Strong opinions, weakly held 😁 😎 So no offence taken at all!
Excellent presentation that communicates the concepts in a easy to understand style digestible to Executives who may have grown from a technical background, but not necessarily hands on today because of their job responsibilities now. This is awesome
Well articulated. It has gotten to the point where you start to cringe when you hear that microservices is an ask in an opportunity. One aspect that I would like to hear more about is the complexity of interactions between microservices.
Lots of great advice here, Dave, but the idea that a service should be able to be rebuilt in 2 weeks needs to go in the bin. It's at odds with the idea that a service should encapsulate a subdomain of the business, and it's been the cause of many orgs building far, far too many services that are all heavily coupled to each other.
As feedback for the video: It would be excellent if you could please add some examples. Abstract concepts without proper examples can't be difficult to visualize and understand the meaning.
As with nearly all things in software development - there are a ton of approaches to solving any problem. And applying the correct approach in the correct way to the appropriate problem, makes everyone happy. Unfortunately there is no "one way" that is best. It is therefore great to hear your views on the pros and cons of an approach - in this case Microservices - as the cons are often swept under the rug by any proponents of a technology. So they are fitting in some circumstances for some organisations in some projects. It is therefore extremly important to identify if these circumstances apply before jumping on that technology.
I think that it is a feature of 'engineering' to assume that there is always a 'trade-off' somewhere, there are always "pros & cons" what ever tech or approach you pick. The skill of engineering is to pick a balance of pros & cons that fit your situation.
I think "bounded context" is one of those big words/phrases that is trying to grasp (poorly) at a simple concept. A "bounded context" is an important "noun" in your solution... Inside that noun, and its constellation of related nouns, you choose to use terms (both nouns and verbs) consistently. In an ideal world we would have one bounded context for a business solution (an agreed upon monolith). In the real world, we will typically have several, because different stakeholders see the world differently (finance sees the world differently than operations, and operations sees the world differently than marketing). The less you understand about the business domain you're working in, the less qualified you are to know which nouns are important and which aren't. If you're in that situation, you need to lean on someone who _does_ understand the business domain well to help you figure out the bounded contexts. However, this isn't a matter of their _title_ (business analyst, business architect, etc.). It's how well they can channel the thinking of a customer. So I think that's why a lot of teams miss bounded context. First, it's unnecessarily vaguely defined. Second, even if you grok it, you either have to be really in tune with the business domain you're working in, or you have to be closely tied to someone who can channel your customers' mental picture of the business domain. Although it's becoming more common, we're still in an era where technical people aren't completely versed in the businesses they support.
I am afradi that I disagree. Eric Evans, the inventor of the term, defines Bounded Context as "a defined part of software where particular terms, definitions and rules apply in a consistent way". So it is a lot more than just a collection of "nouns and verbs". I think that Eric is pointing to an idea that is more subtle than that and that is kind of the opposite assumption to your claim that "In an ideal world we would have one...". We will never have "one" in a real system because in the real world the noun "Customer" means different things in different contexts. In the context of dispatching orders, I probably need customers with addresses and contact details, in the context of evaluating sales, I need just need the idea of customer so that I can count them. In the context picking what products to show my customer, maybe I need their interests, but not their address, and so on. As the context changes, my understanding of what customer means changes too. I could build systems with one big cannonical "CUSTOMER" that included everything that I am ever interested in of a Customer, but that is a bad idea because it couples different parts of the system that are otherwise un-related, for no good reason. One of the other, key pieces of advice, that Eric offers on Bounded Context, that I refer to in the video, is "Always translate between Bounded Contexts" so I can pass my "Customer" from the "picking products" context to the "Order Management" context and at that point I will map the, separate, distinct "Picking products" representation into my local "Order Management Customer". I like this idea a lot and think it really helps design better systems.
@@ContinuousDelivery Your reply more or less restates what I said. Monoliths would be ideal if we could get everyone to agree to terms (nouns and verbs). Since we cannot, "bounded contexts" are what we fall back to. Monoliths are NOT inherently evil. They are an unachievable ideal. I've literally discussed this with Eric, and he laments how his book has been dumbed down to "destroy all the monoliths." We should not be on missions to "find" subtle distinctions and use them to break up "imagined" evil monoliths. It should be something we are coerced into doing because it is impossible to get areas to agree. Healthy data governance isn't something to give up on at the first sign of an application domain problem. Customers NEED data coherence, even if they don't always realize it at design time.
At the company for which I work there has been a move to compartmentalize software development. I know that what we have now is not a microservices architecture (though I have heard it referred to as such); for one, the database is still a huge shared resource. That, by itself, compromises any attempt at "autonomy". On the other hand, there are some aspects of our software solution that puzzle me as to what would be the "right way" to approach it with a microservices mindset. One such aspect is that there is a central conceptual entity that is way too pervasive, i.e. around 80% of the business logic depend on that entity. Now, what do you do? Do you come up with a situation where you have (very) unbalanced bounded contexts; a huge one hosting that big entity and smaller, sattelite contexts for housing the rest? Or should you invest time in trying to rearrange and break up that big entity and its many related operations so as to reduce coupling. Sure, at first glance, choosing the latter option seems like a no-brainer. But what if the cost is too high? Are there realistic situations where sticking with the monolithic architecture might be the best alternative? P.S. Sorry about my rambling... Just felt like writing after watching the video.
I guess that, pragmatically, it is a matter of how stable that big shared concept is. If it never changes, then sharing it between different services can work. The trouble is that any change at all to that shared concept, means chaning EVERYTHING in lock-step, a bad idea! Wether Microservices or not, I like Eric Evans advice to "Awlays translate when crossing the boundary between two bounded contexts" that reduces the blast-radius of change, and so the coupling.
Very informative session, I have a question How we can manage chatty conversations between microservices for better latency, for eg. I want to return kart items to a customer with product details using two microservices KartManagement and ProductDetail? Should I fetch all kart item first then fetch all the product list details by passing the List of product Ids to ProductDetail microservice. What iff I have one more microservice ProductInventory that manages count and availability, should I fetch availability details through passing list of product id to ProductInventory service? There is high demand of performance in my feature, How should I manage that?
If you are serious about high performance then the route to go is towards more asynchronous services. You may want to take a look at this www.reactivemanifesto.org/ If you did that then you could implement your interactions as a series of 'events'.
What is the relationship between “service” and executable application? One-to-one? One to many? Can my team build, deploy, and own a distributed monolith and still think of it as one “logical” microservice that is autonomous and independently deployable from an outsider perspective? (Even though its pieces aren’t-they must be upgraded in lockstep with each other)
An issue I find interesting is dependencies, both testing of a service which have dependencies to other services and what deploying indepently actually mean.
@@nickpearce2968 Not sure what you mean by the service boundary isn't correct. An interesting example would be Identity and Access Management, if we consider an order service with a REST API that supports CRUD functionality. A user updates an existing order via a frontend application which sends a JWT belonging to the user as an authentication header, there is both a need to validate the provided credentials as well as the access. Would it then be incorrect for the order service to depend on another service for Identity and Access Management?
My criticism of this kind of presentation and written articles like it, is that without concrete examples in code, everyone interprets it themselves using their existing mental models. So no new profound insight is made. For example. The last point is the most important, autonomy and compatibility, i.e. consumers don't know the service is changing. It might even be written in a different language one day. But to do this means working in very unorthodox ways, like no branches, committing to main all day, branching in code, perhaps running entire copy pasted versions of the codebase or large parts of the code and then migrating consumers onto the new paths and retiring the old, perhaps within hours, so duplicate code only exists for a short time. Keeping many small changes going out while not breaking contracts or behaviour calls for going against decades of mantra, like DRY. But once people see it, it clicks and becomes obvious in hindsight.
trunk-based development and CI/CD are not unorthodox practices. They are uncommon insofar as most software development is done in crappy ways. State of DoRA, Continuous Delivery book, DevOps handbook all show these are good and common practices, and are not limited to tech organisations
@@askingalexandriaaa Hello. I didn't say CI/CD was unorthodox, though I did say trunk-based development is. I think it's unusual to work directly on trunk/main or have strictly short-lived branches. To be clear, by unusual, I mean it's uncommon. I think it's uncommon because working directly against trunk in frequent small changes doesn't afford the developer the freedom to break a bunch of stuff, as they would in a week old private feature branch. Instead, the new and the existing logic must coexist in parallel in production and be lit-up when ready. So a whole bunch of other practices must be adopted, many of which involve a lot of extra effort, and/or go against mantra, for example, parallel implementation (code duplication) vs. DRY. In IT, it's common to run parallel copies of infrastructure or servers or data and cut-over with the users being none-the-wiser, then decommission the old. In an app, we might use the same technique to run near identical copies of, say, a controller class for 24h and then route execution onto the new one, monitor it for a bit, then delete the old, all over the course of a few production deployments within the same day. It's this kind of thing which is unorthodox. I think many developers need reassuring that creative ways to get new code deployed and lit is normal. I cut my teeth in stressful trade-floor IT where downtime was avoided "at all costs", and that really meant "at all creative solutions" :)
Didn't get it why Ports and Adapters are a mistake. Consider BC1 will consume BC2 through an adapter which will *translate* BC2 response to BC1 model before passing the response back. What violation is there?
@@nathanhughes8354 Yes, thank you that is what I said, and what I meant - I think that decent microservices demands ports and adaptors, pretty much by definition. The definition of a Microservice is that it should be aligned with a Bounded Context in the problem domain. In 'Domain Driven Design' Eric Evans says "always translate when crossing between Bounded Contexts". So "Always translate when crossing between Microservices".
I understand that microservices should be loosely coupled and autonomous. In an event driven system isn't each service coupled to an event ? So when the event schema changes it potentially changes all consumers (depending on type of change I.e extension vs. Modification). Isn't that just exchanging coupling from a service to service interface to one with an ever growing event schema and collateral changes in a blast radius? My point being that autonomy and loose coupling isn't entirely possible.
"Loose-coupled" is not the same as "de-coupled". If two parts of the system need to communcate, then they will be coupled to the degree that they agree on the protocol through which they exchange information. So yes you are right, services are coupled through the messagages that they send to each other. The trick, as I try to explain in the video, is to reduce the coupling by trying to make this protocol more stable than the internals of a service. Think about something like the Amazon AWS S3 API for a moment. That is pretty abstract and has been pretty stable over a few years. Meanwhile the implementation has grown in sophistication without exposing those changes in a way that breaks old code. That is the kind of thing that you have to do for Microservices.
This is all good. But what if the downstream APIs are consuming our service and we change the response of our microservice, in this case a communication is a must.
@@ZuvioxArts I think that depends on how you approach it. I was involved in a creaing a reasonably well-know system based on event-driven architecture and it was the best tested big system that I have ever seen. You can read some stuff about it here: martinfowler.com/articles/lmax.html
@@ZuvioxArts I think that depends on where you deal with concurrency. If you ensure that each service is internally sychronous, testing is simple, send a message, and verify the response.
The problem often is that microservices are not microservices. If you are running parts of your system in kubernetes pods, it doesn't it mean you are running microservices :)
@@EGTGUYI think people are focusing only on this separate deployments, and think that it is enough to say that they are running microservices. They completely forget about loose coupling or one business purpose of the service. Engineers often forget about business perspective of their product, and focus only on technical part - that I why I think many believe that kubernetes is enough to have microservice architectures.
How should the associations be handled in micro services?? This is one question I am looking for. If you could pls put some light on it would be great.
Good stuff - related to Thomas Holme's question is the questions of data and system security in such a model. At first glance (it looks to the traditionally minded) a microservice architecture increases attack surface. It seems to me that this only matters if the surface is "in one place", to whatever degree. Perhaps also it doesn't, actually - it seems to me that reduces attack surfaces if the data stores are (as they should be) autonomous, so the "bad guy" or the inadvertent mishap has to "do them all" to have the same effect as the attack or mishap on a monolith.
As you say I think it is really kind of orthogonal to the choice of Microservices. I think that you win on some things and lose on others. The distributed data store approach means that the blast-radius of an attack is probably more limited, but the distributed nature of dev means that either every team has to independently worry about, and be knowledgable enough, to do a good job of security, or you have to constrain the teams to some degree and provide some kind of secure 'service mesh' to provide base-levels of protection.
I jumped around in this video so i'm not positive, but did it ever mention a problem with microservices? It mentioned people doing microservices wrong, but that's not a problem with microservices.
Dave, I love your videos but the voice audio gives me a headache due to your voice being distant and microphone picking up a great deal of noise. I would hope you’d consider switching to a lapel microphone.
Well, they are small, but yes, if we assume that that means they are simple, we are misunderstanding them. One of my themes is that I think that software development is difficult, and touches on some fairly deep, fairly intractable ideas. Microservices surfcases a couple of these, which is organisational and through that, technical, coupling. If I am honest, I like that SW dev is difficult and needs us to think hard about it, but I think that we sometimes fool ourselves by seeking overly simple solutions.
All this philosophy is useless. Microservices are about developing with Node because Node is capable to run only "micro" and then everybody followed this approach because it's also comfortable for devs.
Micro services fall into the distributed systems problems when they become dependent on each other. Folks need to start to think in vertical slices.. not horizontal (ie, tiers), not graphs. Microservices become almost trivial to implement and maintain when you fire the architects :) and stop having services calling each other. Autonomous services do not call other services.
Perhaps, Dave, the microservices fail for many, maybe even most, organizations because it just isn't the correct approach for them and by implementing it they try to fit a square peg into a round hole, so to speak? For anyone else, don't waste your time watching this, it won't tell you what the microservices are or what's wrong with them. It only tells you that if you have problems with your microservies (whatever it means), then you don't have them or you are doing them wrong, so try harder. Buy a book. Or even better hire a consultant or two.
Well you can use it for both, which is what orgs like Amazon and Netflix do. It seems to me that the key trade-off is between consistency and scaling. If you want to geuninely scale up, you have to distribute development, and decision-making and so relax consistency. If you want consistency, that ultimately imposes a limit on scale.
I wanted to dislike it, because I spend 12 minutes before I realized, that I saw this content year ago. But I don't want to break youtube's algorithms, so I set like. But really, it is repetition.
Well that is my title so my fault, if fault it is. I think that it is a problem that most people who think that they are building Microservices are not, by any of the common definitions of what that means. I see many orgs struggle because they have chosen an approach that doesn't fit their needs. I think that is a problem, and the intended topic of the video.
Looking for books & other references mentioned in this video?
Check out the video description for all the links!
Want early access to videos & exclusive perks?
Join our channel membership today: ua-cam.com/channels/s_tLP3AiwYKwdUHpltJPuA.htmljoin
Question for you: What’s your biggest takeaway from this video? Let us know in the comments! ⬇
An episode on data ownership, pull vs push and how to work with data that you cannot store, but only access on demand from external services would be cool.
the fact that the main benefits of microservices should be that you can scale delivery by making teams autonomous is rarely covered in any presentation or blog. this video should be required viewing for teams attempting microservices. 👍🏻
Microservices are more than just splitting code into "services" running in Docker containers: It is a way of continuously developing and organizing a system consisting of services. The rest about message queues etc is just infrastructure. As someone said: It is about ownership.. If you don't understand separating concerns and responsibilities both in code (the boundaries of the services) and team, then it is just a glorified service-based architecture. If one team is responsible for developing and testing everything then it is not really microservices. You cannot successfully implement Micro Servcies without some kind of Domain Driven Design in mind.
"Microservices are more than just splitting code into "services" running in Docker containers"
Things can be even worse: just copy the bad written, clumsy legacy code to several servers, wrap some http-FooBar around it, and call it microservices.
And insist to make that Microservices-thing being developed in a one-person-plans-and-deicdes-everything (of course it's the person with the lowest quality standards, but the one who is in the project for the longest time, which gives authority), while the new developers with the higher quality standards and with the mind against the cathedral, will just be stopped and possibly even mobbed.
"We are doing it since 20 years that way".
I think many people here are complaining on a high level. There are companies where things are much worse.
Conway's Law is my witness, that those people (in our company) who always talk about microservices and other 'gadgets', while insisting that the brokenb legacy code is untouchable, will not succeed.
First write good quality code (it is cleanly seperated anyway), then think about 'microservices'.
This talk was so great, because it pointed to the "copy our intricated spaghetty code to all servers and wrap REST (or anything else) around it - then we have implemented Microservices" is bogus!
@@smallsnippets This is EXACTLY what my last company did. They had a monolith application and the developers told management that they could move this to a microservice architecture in 2 weeks. It took them 4 weeks, but they basically just split the code up by API calls into separate services. All of which used the same database, and were coupled together. They had no clue what they were doing. As a developer, I warned management, but they didn't understand. Management thought they had a much better product that could be scaled easily. I left after this (and other awful practices they chose to do). They'll find out soon.
Thank you for clearly explaining what many people I work with say we need to be doing, but then don't expect any time or effort to be spent putting it in to practice.
I think my ears are still ringing after that 🔔
Learn a lot from you, thank you Dave for your videos
Thanks, I am pleased that you like them.
I really like that you highlight the costs in addition to the benefits. This makes you appear credible and not just as a software methodology salesman.
That is good, because I am not just a "software methodology salesman". 🤣
@@ContinuousDelivery Sorry, I didn’t mean to offend. I just think that too many techtalks in general are delivered in order to make you believe that OOP, or functional programming or nosql is The Solution to every possible problem :)
@@krumbergify No offence, I meant it. I have my preferences, but my goal is to find ways to build better software faster, and if that meant that I had to drop all of my opinions, I would do so happily if I found somethin better. I am starting to think of myself as a "Software Engineer" in some specific definitional ways. What that means to me is that I don't want to, ever, play only lip-service to an idea. I will express my opinions as clearly as I can, and hope to be corrected where I am wrong.
Strong opinions, weakly held 😁 😎
So no offence taken at all!
@@ContinuousDelivery Great attitude! Thanks a lot and take care!
Excellently summarized both the value and the cost of independent deployment.
Thanks
Excellent presentation that communicates the concepts in a easy to understand style digestible to Executives who may have grown from a technical background, but not necessarily hands on today because of their job responsibilities now. This is awesome
Thanks
Well articulated. It has gotten to the point where you start to cringe when you hear that microservices is an ask in an opportunity.
One aspect that I would like to hear more about is the complexity of interactions between microservices.
Yes, I think that there is some scope to discuss that, thanks for the suggestion.
Developers tend to spend their energy on the micro when they should be thoroughly understanding what the service boundaries should actually be.
Lots of great advice here, Dave, but the idea that a service should be able to be rebuilt in 2 weeks needs to go in the bin. It's at odds with the idea that a service should encapsulate a subdomain of the business, and it's been the cause of many orgs building far, far too many services that are all heavily coupled to each other.
As feedback for the video: It would be excellent if you could please add some examples. Abstract concepts without proper examples can't be difficult to visualize and understand the meaning.
As with nearly all things in software development - there are a ton of approaches to solving any problem. And applying the correct approach in the correct way to the appropriate problem, makes everyone happy. Unfortunately there is no "one way" that is best.
It is therefore great to hear your views on the pros and cons of an approach - in this case Microservices - as the cons are often swept under the rug by any proponents of a technology.
So they are fitting in some circumstances for some organisations in some projects. It is therefore extremly important to identify if these circumstances apply before jumping on that technology.
I think that it is a feature of 'engineering' to assume that there is always a 'trade-off' somewhere, there are always "pros & cons" what ever tech or approach you pick. The skill of engineering is to pick a balance of pros & cons that fit your situation.
I think "bounded context" is one of those big words/phrases that is trying to grasp (poorly) at a simple concept. A "bounded context" is an important "noun" in your solution... Inside that noun, and its constellation of related nouns, you choose to use terms (both nouns and verbs) consistently. In an ideal world we would have one bounded context for a business solution (an agreed upon monolith). In the real world, we will typically have several, because different stakeholders see the world differently (finance sees the world differently than operations, and operations sees the world differently than marketing).
The less you understand about the business domain you're working in, the less qualified you are to know which nouns are important and which aren't. If you're in that situation, you need to lean on someone who _does_ understand the business domain well to help you figure out the bounded contexts. However, this isn't a matter of their _title_ (business analyst, business architect, etc.). It's how well they can channel the thinking of a customer.
So I think that's why a lot of teams miss bounded context. First, it's unnecessarily vaguely defined. Second, even if you grok it, you either have to be really in tune with the business domain you're working in, or you have to be closely tied to someone who can channel your customers' mental picture of the business domain. Although it's becoming more common, we're still in an era where technical people aren't completely versed in the businesses they support.
I am afradi that I disagree. Eric Evans, the inventor of the term, defines Bounded Context as "a defined part of software where particular terms, definitions and rules apply in a consistent way". So it is a lot more than just a collection of "nouns and verbs". I think that Eric is pointing to an idea that is more subtle than that and that is kind of the opposite assumption to your claim that "In an ideal world we would have one...". We will never have "one" in a real system because in the real world the noun "Customer" means different things in different contexts. In the context of dispatching orders, I probably need customers with addresses and contact details, in the context of evaluating sales, I need just need the idea of customer so that I can count them. In the context picking what products to show my customer, maybe I need their interests, but not their address, and so on.
As the context changes, my understanding of what customer means changes too. I could build systems with one big cannonical "CUSTOMER" that included everything that I am ever interested in of a Customer, but that is a bad idea because it couples different parts of the system that are otherwise un-related, for no good reason.
One of the other, key pieces of advice, that Eric offers on Bounded Context, that I refer to in the video, is "Always translate between Bounded Contexts" so I can pass my "Customer" from the "picking products" context to the "Order Management" context and at that point I will map the, separate, distinct "Picking products" representation into my local "Order Management Customer".
I like this idea a lot and think it really helps design better systems.
@@ContinuousDelivery
Your reply more or less restates what I said. Monoliths would be ideal if we could get everyone to agree to terms (nouns and verbs). Since we cannot, "bounded contexts" are what we fall back to. Monoliths are NOT inherently evil. They are an unachievable ideal. I've literally discussed this with Eric, and he laments how his book has been dumbed down to "destroy all the monoliths." We should not be on missions to "find" subtle distinctions and use them to break up "imagined" evil monoliths. It should be something we are coerced into doing because it is impossible to get areas to agree. Healthy data governance isn't something to give up on at the first sign of an application domain problem. Customers NEED data coherence, even if they don't always realize it at design time.
@@Calphool222 Yes, I certainly agree with that. Monoliths are IMO the best answer for most orgs, because they are simpler.
At the company for which I work there has been a move to compartmentalize software development. I know that what we have now is not a microservices architecture (though I have heard it referred to as such); for one, the database is still a huge shared resource. That, by itself, compromises any attempt at "autonomy". On the other hand, there are some aspects of our software solution that puzzle me as to what would be the "right way" to approach it with a microservices mindset. One such aspect is that there is a central conceptual entity that is way too pervasive, i.e. around 80% of the business logic depend on that entity. Now, what do you do? Do you come up with a situation where you have (very) unbalanced bounded contexts; a huge one hosting that big entity and smaller, sattelite contexts for housing the rest? Or should you invest time in trying to rearrange and break up that big entity and its many related operations so as to reduce coupling. Sure, at first glance, choosing the latter option seems like a no-brainer. But what if the cost is too high? Are there realistic situations where sticking with the monolithic architecture might be the best alternative?
P.S. Sorry about my rambling... Just felt like writing after watching the video.
I guess that, pragmatically, it is a matter of how stable that big shared concept is. If it never changes, then sharing it between different services can work. The trouble is that any change at all to that shared concept, means chaning EVERYTHING in lock-step, a bad idea!
Wether Microservices or not, I like Eric Evans advice to "Awlays translate when crossing the boundary between two bounded contexts" that reduces the blast-radius of change, and so the coupling.
Very informative session, I have a question How we can manage chatty conversations between microservices for better latency, for eg. I want to return kart items to a customer with product details using two microservices KartManagement and ProductDetail?
Should I fetch all kart item first then fetch all the product list details by passing the List of product Ids to ProductDetail microservice.
What iff I have one more microservice ProductInventory that manages count and availability, should I fetch availability details through passing list of product id to ProductInventory service? There is high demand of performance in my feature, How should I manage that?
If you are serious about high performance then the route to go is towards more asynchronous services. You may want to take a look at this www.reactivemanifesto.org/
If you did that then you could implement your interactions as a series of 'events'.
This video reflects my understanding of microservices. Kudos.
What is the relationship between “service” and executable application? One-to-one? One to many? Can my team build, deploy, and own a distributed monolith and still think of it as one “logical” microservice that is autonomous and independently deployable from an outsider perspective? (Even though its pieces aren’t-they must be upgraded in lockstep with each other)
An issue I find interesting is dependencies, both testing of a service which have dependencies to other services and what deploying indepently actually mean.
If a service depends on another service, it's tightly coupled and not autonomous and therefore the service boundary isn't correct.
@@nickpearce2968 Not sure what you mean by the service boundary isn't correct.
An interesting example would be Identity and Access Management, if we consider an order service with a REST API that supports CRUD functionality.
A user updates an existing order via a frontend application which sends a JWT belonging to the user as an authentication header, there is both a need to validate the provided credentials as well as the access.
Would it then be incorrect for the order service to depend on another service for Identity and Access Management?
My criticism of this kind of presentation and written articles like it, is that without concrete examples in code, everyone interprets it themselves using their existing mental models. So no new profound insight is made.
For example. The last point is the most important, autonomy and compatibility, i.e. consumers don't know the service is changing. It might even be written in a different language one day.
But to do this means working in very unorthodox ways, like no branches, committing to main all day, branching in code, perhaps running entire copy pasted versions of the codebase or large parts of the code and then migrating consumers onto the new paths and retiring the old, perhaps within hours, so duplicate code only exists for a short time.
Keeping many small changes going out while not breaking contracts or behaviour calls for going against decades of mantra, like DRY.
But once people see it, it clicks and becomes obvious in hindsight.
trunk-based development and CI/CD are not unorthodox practices. They are uncommon insofar as most software development is done in crappy ways. State of DoRA, Continuous Delivery book, DevOps handbook all show these are good and common practices, and are not limited to tech organisations
@@askingalexandriaaa Hello. I didn't say CI/CD was unorthodox, though I did say trunk-based development is. I think it's unusual to work directly on trunk/main or have strictly short-lived branches. To be clear, by unusual, I mean it's uncommon.
I think it's uncommon because working directly against trunk in frequent small changes doesn't afford the developer the freedom to break a bunch of stuff, as they would in a week old private feature branch. Instead, the new and the existing logic must coexist in parallel in production and be lit-up when ready. So a whole bunch of other practices must be adopted, many of which involve a lot of extra effort, and/or go against mantra, for example, parallel implementation (code duplication) vs. DRY.
In IT, it's common to run parallel copies of infrastructure or servers or data and cut-over with the users being none-the-wiser, then decommission the old. In an app, we might use the same technique to run near identical copies of, say, a controller class for 24h and then route execution onto the new one, monitor it for a bit, then delete the old, all over the course of a few production deployments within the same day. It's this kind of thing which is unorthodox.
I think many developers need reassuring that creative ways to get new code deployed and lit is normal. I cut my teeth in stressful trade-floor IT where downtime was avoided "at all costs", and that really meant "at all creative solutions" :)
Best explanations I've seen ever!
Didn't get it why Ports and Adapters are a mistake. Consider BC1 will consume BC2 through an adapter which will *translate* BC2 response to BC1 model before passing the response back. What violation is there?
I think you misheard. What he said was, “ if you’re not using ports and adapters you’re probably making a big mistake.” This was at 8:10.
@@nathanhughes8354 Yes, thank you that is what I said, and what I meant - I think that decent microservices demands ports and adaptors, pretty much by definition.
The definition of a Microservice is that it should be aligned with a Bounded Context in the problem domain. In 'Domain Driven Design' Eric Evans says "always translate when crossing between Bounded Contexts". So "Always translate when crossing between Microservices".
Amen.
"Microservices" has become a useless term, just like "Agile". Everyone claims they are doing it and everyone is doing it wrong.
Good points
Good video, thanks!
I understand that microservices should be loosely coupled and autonomous. In an event driven system isn't each service coupled to an event ? So when the event schema changes it potentially changes all consumers (depending on type of change I.e extension vs. Modification). Isn't that just exchanging coupling from a service to service interface to one with an ever growing event schema and collateral changes in a blast radius? My point being that autonomy and loose coupling isn't entirely possible.
"Loose-coupled" is not the same as "de-coupled". If two parts of the system need to communcate, then they will be coupled to the degree that they agree on the protocol through which they exchange information. So yes you are right, services are coupled through the messagages that they send to each other. The trick, as I try to explain in the video, is to reduce the coupling by trying to make this protocol more stable than the internals of a service.
Think about something like the Amazon AWS S3 API for a moment. That is pretty abstract and has been pretty stable over a few years. Meanwhile the implementation has grown in sophistication without exposing those changes in a way that breaks old code.
That is the kind of thing that you have to do for Microservices.
Very Informative
This is all good.
But what if the downstream APIs are consuming our service and we change the response of our microservice, in this case a communication is a must.
Brilliant and answered some of the criticisms I have of what people call their “micro services”
very helpful, thanks
I would like you to talk about which is the best way to communicate with another microservice
Again, like everything, it depends on your problem domain.
My prefered style is asynchronous, event-driven. This minimises the coupling and so makes it easier, IMO, to achieve the inpdendnce of deployment,
@@ContinuousDelivery bare in mind that with event driven architectures toy being complexity of testing with it.
@@ZuvioxArts I think that depends on how you approach it. I was involved in a creaing a reasonably well-know system based on event-driven architecture and it was the best tested big system that I have ever seen. You can read some stuff about it here: martinfowler.com/articles/lmax.html
@@ZuvioxArts I think that depends on where you deal with concurrency. If you ensure that each service is internally sychronous, testing is simple, send a message, and verify the response.
I'm trying to figure out the comment about ports and adapters, why that's a bad idea for microservices
The problem often is that microservices are not microservices. If you are running parts of your system in kubernetes pods, it doesn't it mean you are running microservices :)
Hehe, not a criticism, but why does everyone think that running any piece of software in Kubernetes suddenly makes it a 'microservice'? 😂
@@EGTGUY because it is the easiest way of thinking. "I am running kube, so I have ms architecture". So wrong!
@@DarthVader250 Hmmm I still don't get it.
@@EGTGUYI think people are focusing only on this separate deployments, and think that it is enough to say that they are running microservices. They completely forget about loose coupling or one business purpose of the service. Engineers often forget about business perspective of their product, and focus only on technical part - that I why I think many believe that kubernetes is enough to have microservice architectures.
@@DarthVader250 I see, ok. 👍
How should the associations be handled in micro services?? This is one question I am looking for. If you could pls put some light on it would be great.
I may do a video on contract testing which would talk about one approach.
@@ContinuousDelivery thanks..I will be waiting!!
Good stuff - related to Thomas Holme's question is the questions of data and system security in such a model. At first glance (it looks to the traditionally minded) a microservice architecture increases attack surface. It seems to me that this only matters if the surface is "in one place", to whatever degree. Perhaps also it doesn't, actually - it seems to me that reduces attack surfaces if the data stores are (as they should be) autonomous, so the "bad guy" or the inadvertent mishap has to "do them all" to have the same effect as the attack or mishap on a monolith.
As you say I think it is really kind of orthogonal to the choice of Microservices. I think that you win on some things and lose on others. The distributed data store approach means that the blast-radius of an attack is probably more limited, but the distributed nature of dev means that either every team has to independently worry about, and be knowledgable enough, to do a good job of security, or you have to constrain the teams to some degree and provide some kind of secure 'service mesh' to provide base-levels of protection.
Excellent explanation. Thank you.
respect
I jumped around in this video so i'm not positive, but did it ever mention a problem with microservices? It mentioned people doing microservices wrong, but that's not a problem with microservices.
Dave, I love your videos but the voice audio gives me a headache due to your voice being distant and microphone picking up a great deal of noise. I would hope you’d consider switching to a lapel microphone.
I have imporved the sound in more recent videos, this one was recorded in October last year.
Excellent
half of the video was more than enough to tell me I don't know anything about microservices.
So the name “micro services” - is a bit confusing. 🤔
Well, they are small, but yes, if we assume that that means they are simple, we are misunderstanding them. One of my themes is that I think that software development is difficult, and touches on some fairly deep, fairly intractable ideas. Microservices surfcases a couple of these, which is organisational and through that, technical, coupling.
If I am honest, I like that SW dev is difficult and needs us to think hard about it, but I think that we sometimes fool ourselves by seeking overly simple solutions.
It’s extremely chaotic.
All this philosophy is useless. Microservices are about developing with Node because Node is capable to run only "micro" and then everybody followed this approach because it's also comfortable for devs.
Micro services fall into the distributed systems problems when they become dependent on each other. Folks need to start to think in vertical slices.. not horizontal (ie, tiers), not graphs. Microservices become almost trivial to implement and maintain when you fire the architects :) and stop having services calling each other. Autonomous services do not call other services.
🌹🌷💝✅🙏🥂🍨🤯🤯🤯🤯🤯terrific lecture as always!!!!
Thank you
Perhaps, Dave, the microservices fail for many, maybe even most, organizations because it just isn't the correct approach for them and by implementing it they try to fit a square peg into a round hole, so to speak? For anyone else, don't waste your time watching this, it won't tell you what the microservices are or what's wrong with them. It only tells you that if you have problems with your microservies (whatever it means), then you don't have them or you are doing them wrong, so try harder. Buy a book. Or even better hire a consultant or two.
Whoever said you can't fit a square peg into a round hole?? Or even vice versa? I do it all the time! 😆
RIP my ears.
Microservices are a way to scale teams, not software.
Well you can use it for both, which is what orgs like Amazon and Netflix do. It seems to me that the key trade-off is between consistency and scaling. If you want to geuninely scale up, you have to distribute development, and decision-making and so relax consistency. If you want consistency, that ultimately imposes a limit on scale.
Yeah everybody aims for the scaling with software for max 100 concurrent users and a dev team of 2-4 people.
I wanted to dislike it, because I spend 12 minutes before I realized, that I saw this content year ago. But I don't want to break youtube's algorithms, so I set like. But really, it is repetition.
Why would a reputable organizaiton/person publish such good content with a title that has nothing to do with the topic?
Well that is my title so my fault, if fault it is. I think that it is a problem that most people who think that they are building Microservices are not, by any of the common definitions of what that means. I see many orgs struggle because they have chosen an approach that doesn't fit their needs. I think that is a problem, and the intended topic of the video.