‫Welcome back.
‫In this lecture, we're going to learn
‫about another very popular architectural pattern
‫which is called Microservices Architecture.
‫We will start with the motivation
‫for using this architectural pattern by comparing it
‫to the Monolithic three-tier Architecture pattern,
‫which we learned in a previous lecture.
‫And later we will talk about the advantages, best practices,
‫and challenges that come with this architectural pattern.
‫So what is microservices architecture
‫and when should we use it?
‫In the lecture about the multi-tier architectural pattern,
‫we learned about the three-tier architecture
‫which we also refer to as a monolithic architecture,
‫because all the business logic was concentrated
‫in one single service in the application tier.
‫As we mentioned earlier,
‫the monolithic three-tier architecture is the perfect choice
‫for small teams that manage a fairly small
‫and not too complex codebase.
‫However, as the size and complexity of our codebase grow,
‫it becomes extremely difficult to troubleshoot
‫and add new features to it, as well as build, test,
‫and even load the entire codebase in our IDE.
‫On the organizational scalability dimension,
‫we also start having problems,
‫because the more engineers we add to the team,
‫the more code merge conflicts we get
‫and our meetings become larger, longer, and less productive.
‫Once we start seeing those problems,
‫we need to start switching gears
‫and consider migrating our architecture
‫towards microservices.
‫So what is microservices architecture
‫and how does it solve all the problems
‫that we just mentioned?
‫In contrast to the monolithic three-tier architecture,
‫microservices architecture organizes our business logic
‫as a collection of loosely coupled
‫and independently deployed services.
‫Each service is owned by a small team
‫and has a narrow scope of responsibility.
‫This architectural style offers us a lot of advantages.
‫The narrow scope of responsibility in each microservice
‫makes the codebase a lot smaller
‫than what we had in the monolithic architecture.
‫This provides us with a wide range of benefits.
‫With a small codebase,
‫development just becomes a lot easier and faster.
‫For example, now the code base loads instantaneously
‫in our IDE.
‫Also building and testing the code becomes much easier
‫and faster simply because there are far fewer things
‫to build and test.
‫Additionally, troubleshooting or adding new features
‫also becomes much easier
‫because the code itself is much easier to reason about,
‫and new developers who join the team
‫can become fully productive a lot faster.
‫In terms of performance and scalability,
‫we also get a lot of benefits
‫from breaking the monolithic application into microservices.
‫Each instance of our microservice
‫becomes a lot less CPU intensive
‫and consumes far less memory
‫so it can run much smoother on commodity hardware.
‫And we can scale each such service horizontally
‫by adding more instances of fairly low-end computers.
‫On the organizational scalability,
‫we also get a lot of advantages.
‫Since each service can be independently developed,
‫maintained, and deployed by a separate small team,
‫we can get very high throughput
‫from the entire organization as a whole.
‫On top of that, each team is completely autonomous
‫to decide what programming languages, frameworks,
‫and technologies they want to use
‫and what kind of release schedule or process
‫they want to follow.
‫Finally, if all those benefits aren't enough,
‫we also get better security in a form of Fault Isolation,
‫which means that if we have an issue in one of our services
‫or one of our services starts crashing,
‫it's a lot easier for us to isolate
‫and mitigate the problem than if we had an issue
‫in our single monolithic application.
‫Now it's hard not to get excited
‫about this style of architecture.
‫And unfortunately, a lot of organizations jump too quickly
‫to microservices without considering two major factors.
‫The first factor is while theoretically
‫we can achieve all those benefits
‫from migrating to microservices,
‫we don't get all of them for free out of the box
‫just by splitting our monolithic codebase
‫into an arbitrary collection of services.
‫So in order for us to get the full benefit
‫of this architecture, there are a fewer rules of thumb
‫and best practices that we need to follow.
‫And if we don't follow them,
‫we can easily fall into our nemesis, the Big Ball of Mud.
‫The second factor to consider is that microservices
‫do come with a fair amount of overhead and challenges
‫which have to be taken into consideration
‫before migrating to this architectural style.
‫So first of all, in order for us
‫to achieve full organizational decoupling
‫so that each team can operate independently,
‫we need to make sure that the services
‫are logically separated in a way
‫that every change in the system can happen
‫only in one service
‫so it wouldn't involve multiple teams.
‫Otherwise, if every single change requires
‫meeting with another team, coordinating the development
‫and the release of the new feature,
‫then we don't gain much from the migration to microservices.
‫To achieve this, there are a few best practices
‫that we need to follow.
‫The first best practice
‫is the Single Responsibility Principle,
‫which means that each service needs to be responsible
‫for only one business capability, domain,
‫resource, or action.
‫For example, if we have an online dating service,
‫we can have the following microservices separated
‫by their business capability and sub domains.
‫The user profile service is responsible
‫for the business object that relates to the user's profile
‫and every way that the user can interact with it.
‫The image service takes care of the storage,
‫resizing, and presentation of the profile related images.
‫The matching service is responsible
‫for matching different users
‫based on the rules that we define
‫as well as the preferences
‫that the users define in their profiles.
‫And finally, the billing service is responsible
‫for everything related to charging the user's money
‫for the services they're consuming.
‫So now when the user wants to update their profile
‫or see someone else's profile,
‫they would simply be directed to the user profile service.
‫If they want to upload images,
‫they can be directed to the image service.
‫And when they want to get suggestions
‫for potential partners,
‫they can contact the matching service,
‫which would in turn talk to the user profile service
‫to figure out which profiles would be a good fit
‫for the current user.
‫And of course whenever the user wants to purchase
‫additional services, they can be directed
‫to the billing service,
‫which in turn may contact the user profile service
‫to unlock certain features for that particular user.
‫Let's take another example from the e-commerce space
‫and this time we will separate the microservices
‫by the actions related to the way users interact
‫with our system as well as the entities
‫we have in our system.
‫On the action side, we have the product search service
‫which given a search query from the user
‫performs a search and returns a personalized view
‫of the relevant products for that particular user.
‫But to find those products
‫it talks to the product inventory service
‫which encapsulates the products entity.
‫Another action oriented microservice we have
‫is the checkout service.
‫So when the user goes to checkout,
‫they will see what they have in the cart
‫and also see the amount of tax they need to pay
‫which we accomplish
‫by talking to another action oriented microservice,
‫the tax calculator.
‫This service will calculate the tax
‫based on the product's price, category,
‫and the user's location.
‫And finally, when the user confirms the purchase,
‫the checkout service will orchestrate the entire transaction
‫by talking to the billing service, shipping service,
‫and the product inventory service,
‫which are all entity oriented services.
‫Additionally, we can also break the API gateway
‫that used to be a monolithic service
‫into multiple microservices.
‫So depending on the type of devices or clients,
‫we can have separate API Gateway services
‫that are more specialized and therefore more lightweight.
‫Now the second best practice to make sure
‫that there is no coupling between different services
‫is to have a separate database for each service.
‫Otherwise, if two services share a single database,
‫then every single schema or document structure change
‫will require careful coordination between multiple teams.
‫On the other hand, if each service has its own database,
‫then the database essentially
‫becomes an implementation detail of each service,
‫and it can be easily updated or replaced
‫completely transparently to the rest of the system.
‫It's important to note that when we split the original
‫monolithic database and provide each service
‫with its own database, the data has to be split
‫in such a way that each microservice
‫can be completely independent and fully capable
‫of doing its work
‫while minimizing the need to call other services.
‫Of course, some data duplication is expected
‫and is the overhead that we need to accept
‫when we move to this type of architecture.
‫So in conclusion, following all those best practices
‫will definitely set us in the right direction for success
‫using this architectural style.
‫However, I want to reiterate
‫that microservices architecture provides all those benefits
‫despite the complexity and overhead
‫only when we reach a certain complexity
‫and organizational scale.
‫And it's always best
‫to start with the simple monolithic approach first
‫and only when that architecture stops working for us,
‫we should consider microservices.
‫In this lecture, we'll learn about a very popular
‫and useful architectural pattern and style
‫which is called Microservices Architecture.
‫We talked about all the benefits
‫that this architectural style provides us with,
‫especially when we reach a point of complexity and scale
‫that the monolithic three-tier architecture
‫stops being a good fit for us.
‫All those benefits result in higher organizational
‫and operational scalability, better performance,
‫faster development, better security, and so on.
‫And finally, we talked about a few considerations
‫and best practices that we need to follow
‫to achieve all those benefits when we use Microservices.
‫I will see you all in the next lecture.