Microservices, a bittersweet symphony
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Title of Series | ||
| Part Number | 31 | |
| Number of Parts | 94 | |
| Author | ||
| License | CC Attribution - ShareAlike 3.0 Unported: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal and non-commercial purpose as long as the work is attributed to the author in the manner specified by the author or licensor and the work or content is shared also in adapted form only under the conditions of this | |
| Identifiers | 10.5446/30683 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
00:00
Range (statistics)TwitterCommutatorSet (mathematics)MereologyRight angleComputer animationLecture/Conference
00:34
Multiplication signService (economics)CognitionGroup actionLimit (category theory)Cartesian coordinate systemWeb serviceSubsetBitInformationDisk read-and-write headSemiconductor memoryStructural loadCodeMaxima and minimaProcess (computing)NumberRule of inferenceType theoryTouchscreenFormal languageLine (geometry)BuildingPoint cloudMereologySet (mathematics)Theory of relativitySoftware developerContext awarenessUniverse (mathematics)Point (geometry)Enterprise architectureSoftware testingCausalityArithmetic meanPlanningQuicksortVector spaceSystem callSign (mathematics)Graph (mathematics)Medical imagingException handlingComputer animation
05:51
Data managementChemical equationStructural loadGame theoryPhysical systemInternetworkingMedical imagingProcess (computing)Hydraulic jumpOrder (biology)Context awarenessForm (programming)Direction (geometry)Point (geometry)Perturbation theoryCuboidCognitionControl flowCoefficient of determinationPhysical lawComputer animation
07:58
Level (video gaming)Physical systemRule of inferenceLink (knot theory)Single-precision floating-point formatBitCartesian coordinate systemBit rateMobile appComputer animation
09:00
Extension (kinesiology)Cartesian coordinate systemPersonal digital assistantServer (computing)Electronic mailing listLine (geometry)Physical systemSingle-precision floating-point formatArithmetic meanComputer animation
10:12
Structural loadCartesian coordinate systemMereologyPhysical systemComputer animation
10:41
Physical systemDataflowSurgeryDifferent (Kate Ryan album)Cartesian coordinate systemGoodness of fitService (economics)BitStatisticsMobile appSingle-precision floating-point formatComputer animationLecture/Conference
11:51
PressureArithmetic meanService (economics)Cartesian coordinate systemServer (computing)BlogFormal languageBuildingSoftware testingPhysical systemDegree (graph theory)Point (geometry)Web servicePlanningExtreme programmingRight angleEnterprise architectureDirection (geometry)Multiplication signDot productLogicScaling (geometry)MathematicsStability theoryFeedbackLatent heatFrequencyDivisorAreaForcing (mathematics)MereologyProduct (business)Sign (mathematics)Sound effectDemosceneHadamard matrixSoftware bugPlotterSummierbarkeitSoftware developerMarginal distributionSource codeDependent and independent variablesWaveDecision theoryStress (mechanics)Row (database)DampingRewritingWritingDifferent (Kate Ryan album)CodeSoftwareStack (abstract data type)Single-precision floating-point formatMobile appComputer animation
19:23
Physical systemPartition (number theory)Service (economics)Multiplication signWeb serviceComputing platformIdentifiabilityLoginSingle-precision floating-point formatSoftwareEnterprise architectureProduct (business)Fiber bundleTelecommunicationWordRight angleData loggerSet (mathematics)Dependent and independent variablesServer (computing)Information overloadCartesian coordinate systemWell-formed formulaExecution unit1 (number)Reduction of orderMeasurementSelectivity (electronic)Type theoryExistenceDifferent (Kate Ryan album)BitAtomic numberProcess (computing)Client (computing)Computer configurationEvent horizonReal numberInsertion lossCentralizer and normalizerFigurate numberTracing (software)QuicksortObject (grammar)State observerQueue (abstract data type)Computer animation
26:39
Well-formed formulaService (economics)Physical systemDisk read-and-write headMultiplication signComputer animation
27:16
Multiplication signCausalityPhysical systemPlanningWordWeb serviceConsistencyType theorySoftwareField (computer science)Theory of relativitySet (mathematics)Service (economics)Validity (statistics)Online helpOffice suiteEvent horizonComputer animation
28:34
Food energyPhysical systemMereologyWage labourModel theory1 (number)File formatSynchronizationContext awarenessBuffer solutionConvex setMedical imagingWordService (economics)Maxima and minimaRight angleProduct (business)ConsistencyDifferent (Kate Ryan album)Type theoryLatent heatString (computer science)DistanceSoftware testingWeb serviceDesign by contractSpherical capAverageMultiplication signWhiteboardPartition (number theory)CuboidBound stateTheoremCommunications protocolBitSoftware bugService-oriented architectureMessage passingCartesian coordinate systemRepresentational state transferComputer animationProgram flowchart
33:06
Physical systemService (economics)MathematicsFile formatValidity (statistics)Computer animation
33:39
DatabaseShared memoryGoodness of fitRankingEncapsulation (object-oriented programming)Reading (process)QuicksortObject (grammar)Computer animation
34:54
State of matterDatabaseRoundness (object)Service (economics)Complex (psychology)Interactive televisionSelf-organizationData structurePhysical systemWordMultiplication signPosition operatorControl flowWeb servicePoint (geometry)System on a chipPhysical lawContext awarenessConservation lawCAN busSign (mathematics)BuildingMathematicsSoftwareCartesian coordinate systemMeeting/InterviewComputer animation
37:40
NumberComputer animation
Transcript: English(auto-generated)
00:12
So hello. My name is Sebastian. I live in Bogota. That's the capital of Columbia in South America. You can find me as sevasoga in Twitter and GitHub. I work for a startup
00:27
called Ride. We are reinventing the way people commute to work, so you should definitely check us out. Today, we're going to talk about microservices. So I want to give a lecture about microservices.
00:41
There's a bunch of them out there. They're really good. You should check them out if you haven't. Today I want to talk about why I think sometimes microservices are a bad idea, and not sometimes, like a lot of the times. So let's start by defining what microservices are. So microservices are like a particular
01:05
way of designing software, basically. And by designing software, we are creating a lot of small applications that can be independently deployed. So a lot of people have discussed, like, is a microservice just a service or inter-architecture?
01:26
And it kind of is. Microservices are just like a subset of service or inter-architecture. It's just like with a set of, it's just a piece of it with a set of really well-defined rules. And you could say that microservices are service architecture, what like Scrum is
01:48
too agile, basically. And microservices are not just like a new thing that hipster developers like to talk about. There's probably people that have been doing microservices for ten years. It's
02:01
just like a name that was given to the subset of rules in the service or inter-architecture, like cloud or definition. So there has been a lot of controversy to how big a microservice should be. So the
02:25
problem with that is that microservices have a failure by design. And that failure, it's in its name. It includes the size of the service in its name. And it's kind of confusing because like micro says that they should be really small.
02:46
And the size here is not the most important thing. It's just part of what microservices are. But they could have probably been, been given a better name. So a lot of people like to say that microservices, I mean, that a service can be considered
03:03
a microservice depending on how much lines of code it has. That, I don't know, that can be confusing. It changes a lot depending on the language you're using, probably. Some of, some people say that you can consider a service a microservice based on the size
03:21
of the team that's building that microservice. For example, in Amazon they have like the two-pitch rule, and that makes sense, but I don't really like those approaches. There's another type of approach, which are like really arbitrarily defined rules.
03:40
For example, Chad Fowler likes to say that microservices have to be this big, and this big being like basically like how big your hand is on your screen. So if it's bigger, if the code you wrote is bigger than that, it's not a microservice. That's kind of arbitrary, and I don't know, I don't really like that definition. So to present the definition, I think that we should all like have in mind when talking
04:10
about microservices, I'll talk a little bit about cognitive psychology. So there's another concept in cognitive psychology called cognitive load, which refers to the amount of information a person is trying to process at any given time. And there's another concept
04:26
I want to introduce that's called cognitive limit, which refers to the maximum number of chunks of information a person can process in working memory at any given time. So these are really related. So basically, I think that you can say that a service is a microservice
04:44
if the cognitive load that microservice represents is lower than the cognitive limit. So let's talk a little bit more about the cognitive limit. So basically, the cognitive limit refers to how much information you can hold in your head at a given point
05:00
in time. So if you're able to completely wrap your mind around a service, totally understand what it's doing without the need to look into code or documentation, you could call that service a microservice. But you have to keep something in mind. And it's that when talking about a group of people, cognitive limit tends to decrease as the team grows.
05:26
So basically, the bigger the team, the lower the cognitive limit is. This is a totally made-up graph, so don't look for numbers or X and Y limits. But it's basically, I think, really, really explains what I'm trying to say.
05:42
So before we go into more details about microservices and related stuff, I want to tell you a personal story. So that personal story will give us a little bit of context. So the story is about the first job I had. And that job was at a baseball stadium.
06:04
My job consisted on selling hot dogs on game days, and it turned out I was good at it. So my manager asked me to sell, to also sell foam fingers. So it went OK. But when my manager asked me to make some public announcements during, I mean, between innings,
06:24
it sounded a little crazy. But OK, I now had to also do that somehow. Weirdly enough, I was able to do all that. So my manager asked me to mow the law before each game. So I was basically doing that, also, too, before each game.
06:43
Surprisingly, my manager lost an employee. So he asked me to help him accommodate people on their seats after mowing the law and while people was, like, getting into the stadium for the game. By the way, I'm sorry I couldn't find, like, a better image of a ticket
07:02
on the internet, and I had to use one that's, like, from One Direction. So because things weren't bad enough already, One Direction showed up for the game, and I had to accommodate them. That was definitely my last day at job. I had to quit.
07:22
OK. That's the story. I don't know, but probably by this point you already realized that this is not a true story. I'm just trying to make a point here. So in that order of thought, I want to ask questions to everyone. Please raise your hand if you have a system that's probably going over your team cognitive load and you
07:45
want to break it up, break it down into other systems. OK. Cool. Thanks. So this is not uncommon. And this happens a lot, like, we get into this situation when we have a monolithic application. So the HH talked about this earlier today.
08:09
And I kind of disagree with his concept of what a monolithic application is, so let's look at it a little bit. Let's look at it, basically. So I think that, like, a single Rails application, like having a system, basically,
08:25
that's a single Rails application, doesn't make that system or doesn't make that application a monolithic application. So what makes a single Rails application a monolithic application is basically poor object-oriented design. So let's, like, separate those concepts.
08:45
Given the fact that your system is only composed but one Rails app, doesn't make that Rails app a monolithic. A single Rails app can be, like, well designed and well built. And there's actually, like, a talk that was given recently, I think on Ruby
09:05
Nails, but Akira Matsuda, where he gave a really, I mean, which was really interesting, and he talked about how Cookpad, which I think is a Japanese company, built what's probably the world's largest Rails application. He gives, on the talk, he gives, like, really
09:26
good insight of how they achieved it and, like, the amount of traffic they can handle with one Rails application that's, like, running on, I don't, I don't, I might be lying, but I think it's like three hundred servers.
09:40
So if you have an application, so although, like, I think they probably, like, do too much to keep their system being, like, a single Rails application, and I don't know if I go, I will go to that extent, you could do it. And if that's the way you like to roll, that's fine. And that doesn't mean that your application is a monolith.
10:04
So you can call the integrated systems you want. That's fine. You can give it the name you want to them. But let's be honest. A monolith doesn't look like this. Like, what's that? A monolith really looks like this. That makes more sense. That's
10:24
how a monolith looks. That's how you feel when you're working with a monolithic application. When you're working with a monolithic application, you probably, you normally, like, can't reuse a part of your system without basically, like,
10:42
reusing the whole system. Or you can, like, easily change the flow without having to do shotgun surgery, which is really bad. So now, like, that we know, like, the difference between what's a really, what's
11:01
a really good application and what's not, when should you go for microservices? I don't know. Let's think a little bit about it. It's an interesting topic.
11:22
So should you go for a monolith, I mean, should you go for microservices when you realize that you have, like, a monolith, that your single Rails app is no longer a well-defined, a well-designed app, but it's like monolith? Well, I would say
11:44
no. This is a fallacy that a lot of people believe in. When you have, I mean, everyone knows that when you have a banana and you smash it, you just get a bunch of little bananas. That's all you get. So the fact that you have
12:01
a monolithic application doesn't mean that you have to go for microservices. I found this on Twitter, which is something I really like, and basically it says that if you can't correctly design a single application, you won't be able to, like, design a microservice or a system that's based on a microservice architecture. And I totally agree with that.
12:23
You first need to be able to nail a single Rails application before thinking about even going for microservices. So when should you really, like, use microservices? I mean, it's clear when not to, but so when should you do it?
12:44
So one good reason to go in that direction is when you have a part of your system that needs to be escalated differently from the rest of the system. So this has happened to us on Brite, where we started with a kind of like a brain application that was coordinating
13:06
a lot of things, and we realized that some parts of that system needed to have a better performance. So we had to deal with the decision of do we want to scale the whole, like, brain application, which is one of our microservices, or do we, or can we like
13:24
just extract this and escalate it differently, because that's the specific need for this. So this is a really good reason to go towards microservices. Another one is when a part of your system needs to be easily replaceable. So what happens
13:40
when you have monoliths, and what has happened, like, in a lot of really big companies that have been building, yeah, producing software for a lot of years, is that some systems are like twenty years old or ten years old, are built on languages that probably
14:00
no one in the, like, the team at a given time knows how to write code in, and it's running on a server that hasn't been touched for a lot of years, and no one wants to change because they're really scared about breaking stuff. So when you have stuff, I mean, when you have, like, your business logic, basically,
14:24
spread about, spread in different small microservices, this is really, it's really difficult for this to happen, because if you have microservices that it's failing, it's not scaling as it should, has a bug or whatever, and it's not technology or
14:42
a server that no one in the team understands, you can easily replace it. Like, just building in whatever language you want, in whatever you think is best, and replace it. And you don't have, like, to replace it right away. You can do it gradually, and testing, and testing, and, like, in every step that the
15:00
new service will really be able to replace the old one. And this is really cool. This is great, because you don't need to do a big rewrite. You don't have to, like, throw the 20-year-old service in the garbage, and start from scratch, and probably create all the bugs that were already fixed on a huge application.
15:24
Okay, so let's talk about another reason, like, when you should think about going for microservices. And this is when you want to be able to, like, deploy some parts of your system more often than others.
15:40
And this is really common. Like, when we have a big Rails app, you notice that there's some tools that actually allow you to check this, and you notice that there are some parts that have a greater, like, churn. That you're changing all the time. Probably because, like, business logic is changing a lot. Probably because it's harder to understand,
16:03
or there are a lot of bugs on the specific part. It can be also because, I don't know, there's a lot of reasons. But sometimes you have to change parts of your system more often than others. And when you have, like, a big single app, this means that you have to deploy your
16:23
app every time you change a small part of your system. And this costs a lot. And also, like, the bigger the app, the more you're afraid to deploy it to production. So you tend to, like, accumulate more changes for each deploy, and then when you accumulate a lot of changes for each deploy,
16:43
there's a lot of more possibilities of deployment to go bad, than when you just, like, deploy constantly smaller changes. So when this happens to you, it's also a good idea to think about microservices. Okay, so another, like, reason why you should look at microservices,
17:05
it's when you don't want to use the same technology stack for every part of your system. You have to be aware that this can be taken to an extreme. So there's a blog post out there by SoundCloud, I think, where they explain that when they moved to a microservice architecture,
17:25
they allowed anyone to write a new microservice, a new microservice in any language they wanted to. And this ended up being a huge problem for them, because there were microservices on, like, basically any, like,
17:41
living language out there, any language that's still under development. Everyone wanted to, like, learn a new language, so they're basically, like, creating a new microservice on that language, which can be really cool, but can be also really hard to handle. So for example, at Ride, what we do is,
18:02
when we need to create a new service, whoever's going to work at, or work on it, or whoever's going to be responsible for it, basically creates, like, a proposal, and says, okay, I'm going to create new microservices, this is, like, a contract, it's responsibilities,
18:21
and I want to use this tech stack to build it. And then we open it for proposals, sorry, for comments. So we do an RFC, a request for comments, and basically everyone in the engineering team has a period of time when they can give feedback in that proposal.
18:40
And that feedback is, I mean, it's on design too, it has to do with, like, the business value that each microservice is. Each microservice adds to, like, the whole problem we're solving, but it's also around the technology stack we're going to use, because the whole team is going to be responsible
19:03
of maintaining that new microservice that's going to be created. So we probably want it to be really something that makes sense for the problem we're fixing, but also something that we are, I mean, yeah, that we want to maintain, something that we think makes sense,
19:22
and that it's not, like, a new creative language, something just someone just wants to learn and experiment with. So that's called technology et terro yay inicity. I know, that word's confusing too. So last but not least, the most important thing is that
19:45
the team that's working on building your system has to be ready to support this type of architecture, and it's key. I mean, this is, like, really important, and it's what a lot of people moving towards microservices miss.
20:02
The skill set of your team has to be ready to support what moving to microservices means, which we'll talk about a little bit further during this talk, and also, like, the team has to be big enough to be able to work on different services
20:21
on basically a distributed system, and sometimes people overload a really small team with this type of architecture, and that's when they start to see a lot of problems with it. So you have to be really aware of this. So how do you know if your team is ready to go towards
20:43
some microservice architecture? There's basically, like, three things that are key. The first thing is that you have to be able to, like, easily provision new servers to, yeah, basically provision new servers whenever you need to. The second one is that you need to be able to set up
21:03
basic monitoring for every new microservice you create and the existing ones, and also you need to be able to respond to failures that monitoring that you set up decks. And last is that you need to be able to, like, rapidly deploy new applications.
21:22
So if you have a new microservice that you need to get into production, like, the team should be able to get it into production in a few minutes, not a few hours, not a few days, not a few weeks. So that's really important. If your team is not there yet, you're probably better off not going
21:40
towards microservice architecture. So now that we, I mean, let's say that your team is ready to handle all of this as we just saw, which is great. You could say, okay, I'm ready. Let's go for microservices. I really love the idea of it. I think we gave it a really long thought
22:03
and discuss about it, so let's do it. But you have to consider the downsides of it. And they're not trivial. So let's get to, let's see what, like, the most common downsides of microservices are. So first of it is that DevOps intensive.
22:23
So as I mentioned before, teams need to be good at DevOps, need to be ready to support a lot of services running all the time. And this can kind of be mitigated by using a platform as a service, which will probably do a lot of the work for you.
22:42
And that's good. If that's the way you decide to go, I think that's fine. Another downside of, I mean, more than the downside, that's like something you need to be aware of. But let's talk about this. So you have log files for every service that's running.
23:02
And this can make really, I mean, this can make debugging really complicated and hard. So you need to have, like, centralized logs for your whole system so that you can, like, watch what's going on there. And also, something that's really important is that you probably want to have unique identifiers
23:20
for every request that's being, that's going throughout your system so that if something goes wrong, you can easily trace it and figure out where things are going wrong and how to fix them. This is really important, believe me. So another downside of microservices
23:42
is that you have to be prepared for failure. So I know, I mean, this is not, this is something that you shouldn't only worry about when you have microservices. Like, you should also be prepared for failure when you have, like, a single app,
24:00
if it's Rails or not, it doesn't matter. But the thing is that when you have microservices, this is harder to manage. You need to have a lot more stuff into consideration to be prepared for failure. So let's look at what are the most common failures when you are dealing with a microservice architecture.
24:24
So the first one is network partitions. So this is something that we'll inevitably, inevitably, you, I mean, sorry, this is something that you will inevitably have to deal with when working with distributed systems, even if they're not microservices.
24:44
So this is really important because there is no such thing as a network that doesn't fail or services that never goes down. We all know that sometimes, like, sometimes these things fail. So we need to be prepared for it.
25:00
So for example, let's say we have a system that looks like this. And let's say that communication between Node or service A and B goes down. And then we get a request on Node 8. So Node 8 has to decide between basically two options.
25:22
Node 8 can respond to the client, telling them like, hey, there's like something wrong going on. I can't really process your request right now. Or Node 8 can also say, okay, I'm gonna deal with this. I'm gonna respond to you something. And then I will internally deal with the consequences
25:44
that having no communication to Node T will bring to the system. So this is something that's not trivial and something that you need to plan ahead of. Okay, so the thing is that this is not the only problem.
26:04
You can also have services that are sometimes unavailable. So even if you have the perfect network that never goes down, services will eventually be unavailable. So there's a formula for this.
26:23
Says that basically like the probability of a failure occurring on your system is equal to one minus the probability of a node or a service not failing powered to how many of those are. This is like, wow, I don't know.
26:41
It's complicated. When I first saw this, it was really hard to get my head around. So let's just see an example. Let's say you have a bunch of microservices. All of them have an uptime of 99.9%, which is great.
27:05
But you have four microservices. Sorry, 14 microservices. This means that your system, applying this formula we just saw, yeah, this one, the system will have an availability of 96.1%,
27:26
which in other words means that you have around 4%. I mean like most of the time you have a probability of 4% of something going wrong in your system. And this is only considering like
27:41
that if a node fails or a service fails, only that service will fail. But depending on how you design your system, if a node fails, a lot of other related fails can fail too. So this can get really bad. You need to be prepared to handle this type of failures.
28:01
So let's look at another one. Data inconsistencies. So when the network is partitioned or a service is unavailable, they will most probably, this will most probably, sorry, cause data to be inconsistent. And this requires planning. You need to know how you're gonna deal with this
28:21
so that data is eventually consistent. Or if you don't care about consistency, like maybe even like how to deal with this, how to deal with data not being consistent in your system. And this is not trivial because it can really, it can really make your system like not work as it should.
28:44
Okay, and like these two problems we just talked about are basically part of something that's called the CAP theorem or CAP theorem, which talks about like dealing with this type of failures in distributed systems and really explains
29:02
like not only how they can affect your system but also probably how you can deal with them depending on your business requirements. That's the most important thing. So basically, CAP stands for consistency, availability and partition tolerance. And when you have distributed systems
29:20
such as a microservice architecture, you have to deal with partition tolerance because your system is partitioned. It's not something you can choose off. But you have to balance how to, how to be available and also like have consistency of data at the same time.
29:44
So this is really important if you're thinking about microservices. If you haven't heard about the CAP theorem before, you should really read about. I recommend, really recommend it to you. It's really interesting. But this is a topic big enough to do another talk about it.
30:05
So let's talk a little bit about like what to do like when you want to build microservices. Let's say your team is ready. You can deal with all the downsides of it. You're ready for it. So how to start?
30:20
So first of all, when you're trying to be, to break a big application into small, small services, use the bounded context pattern, which basically deals with large models by giving them the ability to have specific behavior based on their context or the context they're on.
30:41
So like in this image, you see that we have the customer model and the product model in two different contexts. One of them is like the sales context and the support context. Depending on the context each of these models is, they'll probably have a different behavior and you probably want to have access
31:01
to different data that's related to it. Check it out, it's really useful. So also, something you really need to do that I found is really useful, it's having a specification for each microservice and being able to run that specification as executable tests.
31:21
So one of the, it can be a pain in the ass basically to do testing with microservices. So one way you can handle this and make it easier to work with is by having specs that you can run as executable contracts. So that when you test each microservice,
31:42
you can test it again, that executable contract and make sure that when everything's running together, when everything's deployed, it will work fine together. And you won't like only realize you have bugs until you go to production, which is really bad. And it doesn't mind if you're using
32:01
like a HTTP RESTful API or if you're using like for communicating, you're using a message broker or RPC. This is something you really need to do that will save you a lot of headaches. So you should also be aware that
32:21
you should go for a synchronous communication over synchronous communication whenever you can. This will make it easier to deal with any type of failure, the type of failures we just saw the CAP theorems talk about. And another thing that I found really useful and that we've learned in Riot
32:42
is that you should use schema-based formats over schema-less ones. So there's, so like to give you a little bit of context for example, like a schema-less format is JSON and a schema-based format can be protocol buffers or Captain Proto
33:03
or I don't know, there's probably a bunch of them out there. So the good thing about this is that schema-based formats allows you to extend data that you pass between systems as you need to as your system grows and changes. And it also have some validations
33:26
and will also allow you to be backward compatible as you grow. And this is something that's really important and we'll talk about something called the golden rule of microservices in a few minutes. So what should you do to start?
33:43
Create a new microservice when you need it. Be aware that the perfect is the enemy of the good. So you don't need to have the perfect design before going to microservices. Just start and don't be afraid to iterate on your solution. So what should you do now that we know how to do it?
34:04
So it's really important that you don't share databases between microservices. Sharing databases is like calling another object private methods. That's really bad. Something you don't want to do. It's solely breaking encapsulation. So don't do this.
34:21
There's a lot of ways around this. And if you're doing it, it's probably because you don't want to think hard enough on how to fix the problem. And if you see yourself in a situation where you temporarily, hopefully, have to deal with this, just make one microservice in charge of writing
34:41
to the database and the rest of them just reading from it. But still, you'll have a lot of coupling because if the schema changes, all of these microservices that are reading from it will have to change too. When you share a state or when you share a database, you'll feel like this.
35:00
You'll feel like you're moving on dangerous grounds. So something we saw before today is to avoid being biased by Conway's law. And this is basically, this law was coined by something
35:20
that Marvin Conway said in 1968. He said that organizations produce systems whose design is a copy of the structures of the organization. So you should be really aware of this and not try to just replicate the way your organization works into how your system works because that's probably gonna have you
35:45
creating microservices you shouldn't or designing them the way you shouldn't. And most importantly, don't break, I've mentioned this before, don't break the golden rule of microservices. And this basically says that you need to be able to deploy any service, any time,
36:01
without changing any other service. And this is not trivial to achieve. Because if you fail to achieve this, you're losing most of microservices benefits. If you find yourself in a position where you are doing lockstep deployment, where you have to deploy more than one service at a time
36:21
so that the system doesn't break, it doesn't really make sense to have microservices. It doesn't really make sense to have things that you should be able to deploy independently, change as much as you want without the rest of the system knowing. So be aware of this. If you find yourself in this situation,
36:40
you have to fix it real quick or maybe think about going back into a single big application. So to wrap everything I've been saying up, I would like to bring two quotes by Michael Feathers. And the first one says that he strongly,
37:02
like he strongly believes that there's a lot of complexity conservation software. Which means that, for example, in microservices, we need to be aware that when we go towards that direction, we're pushing complexity
37:20
into the interaction of our services. And we need to be prepared to deal with that. So my recommendation is go for microservices if they allow you to better manage the complexity of the system that you are building. That's all I've got for today.
37:42
Thanks a lot.