A Beginner's Guide to a Microservices Architecture | Idan Gabrieli | Skillshare

Playback Speed

  • 0.5x
  • 1x (Normal)
  • 1.25x
  • 1.5x
  • 2x

A Beginner's Guide to a Microservices Architecture

teacher avatar Idan Gabrieli, Pre-sales Manager | Cloud and AI Expert

Watch this class and thousands more

Get unlimited access to every class
Taught by industry leaders & working professionals
Topics include illustration, design, photography, and more

Watch this class and thousands more

Get unlimited access to every class
Taught by industry leaders & working professionals
Topics include illustration, design, photography, and more

Lessons in This Class

23 Lessons (1h 54m)
    • 1. Microservices Promo

    • 2. Welcome!

    • 3. Course Objectives and Structure

    • 4. Monolithic Applications- Overview

    • 5. What is a Monolithic Application?

    • 6. #1 – Complex Release Cycles

    • 7. #2 - Scaling the Team

    • 8. #3 – Scaling the System

    • 9. Monolithic Application- Summary

    • 10. What are Micro services?

    • 11. Looking inside a Micro-service

    • 12. The Concept of a Microservices Architecture (MSA)

    • 13. Small Size and Loosely Coupled

    • 14. Organised around Business Capabilities

    • 15. Managed as Products

    • 16. Smart Endpoints and Dumb Pipes

    • 17. #1 - Independently Developed and Deployed

    • 18. #2 - Frequent and Faster Delivery

    • 19. #3 - The Best Tool for the Job

    • 20. #4 - More Granular Scaling

    • 21. And also few Challenges

    • 22. Netflix - Industry Case Study

    • 23. Quick Recap and Thank You!

  • --
  • Beginner level
  • Intermediate level
  • Advanced level
  • All levels
  • Beg/Int level
  • Int/Adv level

Community Generated

The level is determined by a majority opinion of students who have reviewed this class. The teacher's recommendation is shown until at least 5 student responses are collected.





About This Class


DATA IS THE NEW GOLD. It is gold for companies that can harness the power of technologies and use it while transforming their business models into the digital age and become much more data-driven. It is an amazing journey fueled with new technologies, but we need to remember that data by itself is just one part of the equation.

What about the complex software around it? That is supposed to do something useful with the data. To be able to interface with many data sources, to store massive data volumes, to provide a great user interface and automatically analyze, and find useful patterns.

Software is the Engine, and data is the Fuel.

Until recently, many enterprise-level applications were designed, developed, and maintained as one giant monolithic applications. With a once in a year software release cycle, maybe two times in a year. Every small update required to build, test, and deploy all application modules as one package.

Today more than ever, this traditional development approach is not good enough. It is not supporting the required agility of a fast-changing business landscape. Software updates should be released and deployed in weeks, days, and even hours.

MICROSERVICES is a new innovative development style, already being used by companies like Netflix, Facebook, Amazon, and others. Micro-services are the building blocks for creating cloud-native applications, and therefore we will see more companies following this direction.

This training is designed to provide you a solid theoretical understanding of the micro-services concept.

  • The challenges with the old-school development style

  • The industry definition of micro-services and the building blocks of a single micro-service

  • Then we will be able to move to the macro level and talk about the concept of a microservices architecture

  • What are the key benefits of this approach

  • Review some interesting case studies

Would you like to join the Microservices Revolution?    

Meet Your Teacher

Teacher Profile Image

Idan Gabrieli

Pre-sales Manager | Cloud and AI Expert


Class Ratings

Expectations Met?
  • Exceeded!
  • Yes
  • Somewhat
  • Not really
Reviews Archive

In October 2018, we updated our review system to improve the way we collect feedback. Below are the reviews written before that update.

Why Join Skillshare?

Take award-winning Skillshare Original Classes

Each class has short lessons, hands-on projects

Your membership supports Skillshare teachers

Learn From Anywhere

Take classes on the go with the Skillshare app. Stream or download to watch on the plane, the subway, or wherever you learn best.


1. Microservices Promo: one off. The main goals off business companies and many organizations worldwide is to become much more data driven to be able to harness the power off up to date. So fritters, big data technologies and cloud computing services. It's a combination off great software tools, interesting and useful data and cost effective ultralight, eerie sources. Now to be able to move in that direction. Legacy software tools that I used to be deployed in private data centers are expected to utilise cloud services and become cloud native applications. However, those existing applications were designed, developed and maintained. Is one giant more analytic applications with once in a year software release cycle maybe two times in you? Every system upgrade is like a big project. This traditional development approach is not good enough. It's not supporting the required agility off a fast changing business. Netscape Softer updates for enterprise application should be released and deployed in weeks , days and even hours. If a new software feature is needed right now, why should we wait six months for the next big software upgrades? So over the last couple of years and you saw for development approach called Micro Services emerged as a solution to cross that gap. Micro services are one of the big guest revolutions in the software industry, as they are the building blocks for creating cloud native applications. My name is either, and I'm teaching multiple courses related to the topic off cloud computing. This training is designed to provide you a solid theoretical understanding off the micro services concept. We are going to talk about the challenges with the old school development style, which is called in a negative way. More analytic applications. They industry definition, off micro services and the building blocks off. A single micro service then will be able to move to the Marco level and talk about the concept off a micro services architecture. What are the key benefits and business value when using it will also review some challenges to keep in mind while considering this new approach, and lastly will review an interesting case. That thing is our plan. Let me know if you have any questions. Thanks for watching, and I hope to see you Insight 2. Welcome!: Hi and welcome. Thanks for joining. My name is Don and I will be your teacher. We are ready to start. Ah, well up. Awfully interesting journey with the main lettering topic in this course meaning Micros Services is some off. You already know me for my other courses. I like to explain a technical concept for multiple angles and specifically try to understand together the business case. What is the problem we are trying to solve, and only then move to the actual solution in the getting started with cloud computing A training cause. We talked about the business case off moving enterprise application into the cloud which is happening everywhere. Worldwide. There are multiple global cloud service provider like Amazon AWS and Microsoft Zoo, Google Cloud and others. We can pick one of them and in a few minutes. Allocate whatever needed visual resource is for a specific application. It could be by using their classical infrastructure as a service model. A platform as a service and also function is a service practically is speaking almost any application. Can Iran somehow in a cloud environment, especially while using the infrastructure as a service model which is actually running application on virtual machines that are in the cloud in opinion, public cloud service That's great and useful. But there is a big question mark about the business benefits off moving a legacy application into the cloud. In most cases, those existing application are not cloud native application. They were not designed to reside in a cloud environment and fully utilize the features and options that are available in such environment. We will, of course, digging toe that a problem later. The good news is that there is a solution to that application design, a problem or challenge based on the concept off Micro Services Micro Services is a software development style, or software architectures that is supposed to be used by developers when they develop complex, large scale application but not regular application. Michael Services are the foundation off cloud native application, which means there's a crucial topic to anyone that would like to understand the emerging new world of cloud computing. Looking from the application point off you now, please don't worry. If you're not a software developer, I'm not a software developer. And anyway, the main course objective is to understand the concept off micro services, so people coming from a variety of backgrounds will be able to understand it without losing the big picture. Let's review the course objectives and structure. 3. Course Objectives and Structure: We will start a this training by talking about the traditional monolithic software development style, dominating the software industry until recently, and the challenges associated with such old school design in the context of the cloud, I'm going to use a simple example. Often, airline is innovation system. It will be an essential background to understand the nature off the problem. Why we are moving in that new direction. Then we'll start to talk about micro services. What are micro services? What are the building blocks off a single micro service like we have a P I get ways, application logic and data store. Then we'll move toe the micro service architectural form a Marco viewpoint, and we'll define it, using some common in the strait characteristics like loosely coupled services independently a place, a bell and upgradable and more. Next section will be about the key advantages off using this development style, making this approach very appealing toe more than a cloud based application and also the challenges when using this new approach. As we all know, nothing is perfect. There also this advantage A to a new method Still, over the last couple off years a the market adoption off micro services is impressive. So definitely there is something interesting in this new approach. And finally we will review the interesting A. Netflix A case study in the context Off micro services. At the end, off each section, you can test your understanding with a quick quiz just to set expectations in advance. The objective off the course is to teach student the micro service a new approach off the whole architecture and main benefits. It's not the training on how to develop Michael service application. Now, practically speaking, I highly recommend you to follow the lectures in the right order. If something is not clear, then remember that you can always drop me question and I will do my best to help you. I wish you a useful and interesting landing. See you in the next section. 4. Monolithic Applications- Overview: our story. We begin by talking about the dominating traditional way to develop applications application that are called more analytic applications. And in a few minutes we will talk about the meaning off the world more analytic. This monolithic software development style was used for many years in the software industry and still being used today. Now, to be clear, I'm not talking about a desktop applications like PowerPoint. It's about the development off enterprise level applications, meaning applications that are used by multiple and users over the network to perform some complex business logic. Those applications are running on some back and I T infrastructure. While using multiple software components and a variety off technology layers, it can be an internal private corporate application access by thousands off end users in some company. Think about an airport application, used Eddie Gates or check in counters to schedule and manage incoming and outgoing flights . It is an enterprise level application, performing multiple functions and accessed by people walking in that specific L boat. This application will be connected to thousands off real time data sources. Oh, it can be a public software as a service application, like we're using day by day. Think about services like mobile, Netflix ways, Facebook, Google search engines and many others. Each one off them is a global service with millions off customers. You can imagine that the beckoned, softer, running this kind off service, the global scale is quite complex, with many building blocks, a variety of technologies interface with other system and so one. So this the type off application we will discuss while moving forward in this same training course. 5. What is a Monolithic Application?: Let's start to define the concept off monolithic applications. Think about an online airline reservation system to book flights via the Web, every airline companies using such a ticketing system and multiple customers and agents A can access age such website at any given time, it will process the request. Display updated prices. A check it gets, say inventory status while making sure that two people will not order the same sit off course posts, payments and so one again. It's a complex application. The software architectures off such a flag Tickets application will look like a three tier system. There will be a layoff, a phone and Web servers, toe get request form and users, for example, using Apache Web Server. The second, we will be the learning environment for the Application Business Logic, which is usually a centralized application server. This application server will Iran all the needed models off that application, like getting requests, checking inventory display prices, process payments, update, customer profile and so one. This application server will process the request coming from the front end Web server, execute some logic and retrieving update data from the database. In most cases, the application business logic is developed using a unified language with a single base code. Let's assume, in our example, that it was developed using Java, which is a very common language, A for beckoned application. So all required functions and models in that application are done using single Java base coat. And this is the terribly ill. This centralized data based is the application data store holding any needed information like the available tickets, a flight number and use a profile purchasing history, etcetera, all software models learning in application server basically sharing and using the same centralized a database if you're walking today as a software developer, or maybe it's a system that mystery toe deaf, up engineers and so on, I assume you're quite familiar with, say, such until architectural. This very common software architectures is called monolithic applications. They would more analytic refers to something constructed a off a single piece off stone, like when looking at some interesting a sculpture that you are amazed by the fact it was created from one piece off stone. You know, a few 100 years ago, in the context off software development, this name monolithic application has started to be used to describe in a negative way, one large piece off program that is performing multiple functions. In our example, this application server is a monolithic entity. All the logic for handling a request to book a ticket and tow end runs in a single application server, even if the application is divided into models. As we can see here, those models are sharing the same Java development language and the same running framework and also the same centralized database. Now this kind off an tears. Architecture is very popular and still useful. When a software project is starting very small. It makes sense to use a unified development framework because the system and in most cases , used the same components like the same database, the same application server and so one. As I said, this kind off software architectures was useful decades in the software industry and still being used today. So what is the problem with such kind off architecture? In a typical monolithic application, different immortals inside that application may share the same court or share the same data . When I'm saying shared code, it means that some function libraries off piece off code are used in multiple models and As a result, those models are what we called strongly interconnected. If we change something in one model or in some place somewhere in the application, like in a shared function, it can influence other models. We saw that the Cretier Fly Tickets application has a unified application server, which means that different models are developed using the same language like Java. And this is very useful because different models can easily share in access the same code, the same function, the same libraries. The code is usable and also unify the cause application. The same Java language is used to develop all needed models, so the developers skill set can be focused on Java. Also, those models will communicate with each other using in memory calls because they are running on the same server as a function calling another function. And the big advantage Hill is that those in my movie calls between processes running on the same server are very fast, which is useful in many applications, however, and there is a big, however here if we change one off those interconnected models, several other models can be affected. There are no clear cut boundaries between models and Therefore, it's not so easy to change the application base coat. It is a shared code. The same is true for shared data. For example, two or more models are accessing some customer profile tables from the same database. In our example, the booking fright model is accessing customer profile, and also the payment models is accessing the same customer profiles. They are using the same data store. If we change the structure off the data store, meaning the meta data off the database, it can affect those two models. Now, just imagine a simple scenario off adding another filled to the customer profile database. Someone should go over the application code and check which models because the application are using this specific customer data. Otherwise, there will be, you know, unexpected result in the next a couple off lectures. Let's talk about the specific challenges off such a shell code and share data in a minority complications 6. #1 – Complex Release Cycles: any software application is good for a while until something is changing. New business Lee Kwan Mints are coming. New request from the end Users New technologies We all know that all software application are supposed to be updated one way or another. The key issue is about the time intervals between those updates. You can imagine that the concept off shared code and share data being used in a monolithic applications is gating a tightly coupled connection between models so they own going. Software releases will be for the whole application. Okay, all models together is a single block as a single mom analytic using our flight tickets system as an example. Let's imagine that the new feature is required in a specific model, and the development team you know, quickly created that feature. In a couple of days, there were very quick, but this model is walking and interconnected with other models. For example, all components are using the same database, and if we change the database structure the meta data off the data, then it can influence multiple components. In that scenario, the application should be tested and to end to see that everything is still forking and functioning as expected, even though this is a very small feature. Also, we have toe redeploy the entire application in the production environment, which means small system downtime for ongoing upgrades, more complaints from end users when the system is not available and high risk to break something. Doing their system are great if you will ask, you know, any system and mystery toe. It is a huge headache toe upgrade, a large a complex, its software. That's the reason that ongoing software releases for such enterprise level applications will be one. See Neil, maybe two times in you release cycles are tied together because it makes sense to package many small changes. Many features a group off back fix in a multiple models and wait for the next big software release cycle. The key, a drobnic is that a large, monolithic application? We be an obstacle toe frequent deployments. Every ongoing deployment will be a complex to schedule complex to perform and with a higher risk on impacting the usage off that system, which at the end will discourage people from performing frequent updates. And in the software business, frequent updates are not nice. Tohave there must wave is things are changing very fast. Cos they would like to use the concept off. Continuous delivery off software updates such an approach off once a years off the release cycle is becoming less effective for many companies, an organization that would like to move much more quickly with their software tools. If a new, important features is needed now, why wait? One hell for that new features. Companies would like to use the concept off continues delivery off software updates and monolithic application are not really designed to handle such frequent updates. 7. #2 - Scaling the Team: Let's talk about another scenario. Imagine a new developer just joined the company, and he'll she would like to perform some change and add a new, amazing feature. Well, it's not going to be easy. This new developer must spend a huge amount of time to understand what's going on. Explore unknown dependencies between models before even touching the application called otherwise, he'll she can easily break something. The situation is even more complicated when the amount off developers that are walking on the same application is going. Each developer is having another piece of code, and it's getting bigger and bigger now because there are no specific and clear boundaries between models. Eventually, the overall system with duality would break down over time. Going back to our example, let's assume that would like toe ed aerating capability that will enable a customers to provide feedback about the ticket purchase process. And Self is doing the flight suggestion from from customer etcetera. We saw that our application is divided into models is main functional building blocks. One a model will be day use the renter phase. The second model will be the booking flight process, time in process and other model will be will handle the rating and feedback form and usual , it said. So the development him will open the Application Java code and develop the needed features , maybe as a new model still to be able to develop the features in time. We estimated that another development team should be added to the project. Let's assume each team is around 10 people. Now. We have 20 people walking on that application now, fast forwarding a year or two in the into the future. As more and more features will be added to that application, more people will be involved in that ongoing project, meaning more developers, more product managers, mochi way engineers, mo operation engineers develop engineers, etcetera. As the complexity off the application is growing, more people are joining and much more complex coordination between them will be needed. The problem with a monolithic application is that it prevents the teams the development teams, from walking independently. The teams must carefully coordinates their development efforts. Imagine an application started with 10 developers and now going into 100 development. It is a completely different story, so this is the second important a drawback related toe, a monolithic application. At some point, it will become a challenge to scale the team and still be effective 8. #3 – Scaling the System: the term major challenge about a monolithic application is related to scalability or better call it limited scalability. Scalability is the ability to increase and decrease availability resources to better much the actual load requirement on a specific walk load. In case there is a bottleneck in a monolithic application, the solution could be divided into two main options. The 1st 1 is called Vertical Scaling, or so called scale up, which means adding more resources to an existing note. Imagine a Web server is earning in on a specific virtual machine size we can in large David . Actual machine resource is like a big mo memo. A sip you power storage capacity network spare, etcetera. It is called Scale up or skill down. Still, at some point of time, we will reach some limitation like a maximum amount off memory or maximum amount off network bend with. It cannot scale forever, so we have another options for scaling. The second option is gold or resentful scaling, also called scaling out. Oh, in In that case, it will handle the bottleneck by creating another parallel instance off the same note. If we had one Web server, let's have two Web server or maybe more and balanced. They traffic between them using a component like a load balancer. Now not all components. It will support such scaling options, but it's getting very popular and useful options. We're talking about automatic and dynamic scaling in a cloud environment, so everything is perfect with those two scaling options. Well, not really in a monolithic application. The main problem is that the scaling granularity is limited. Imagine that we have five models sparked off some application running in the same application. Silver. Let's say that one model like a Model B, is creating a very high load on that server, which impacts all models running in that server. Even if the problem is just related toe, only one specific model we still need to scale. The all application server is one entity in case we want to use a result of scaling, then another full replica off that application server should vacated. It is a solution, but not an optimized solution. This kind of scalability is basically a waste off computing resources in the world off elastic cloud computing. If we could break the system into smaller components that are learning on separated ICTY resource is the scaling could be much more focused or specific. Localised bottleneck. Okay, so if we can on Onley model B or any on a separate item resources, then we have the options to scale. Only that resource is also cloud native application. Okay, Now are moving a little bit into the future are supposed to run inside containers. OK, not virtual machines. Okay. Set off using virtual machines. And again, a more analytic application is not really a good candidate to use such kind of fertilization technology. Many containers 9. Monolithic Application- Summary: as a quick Rick up. I want you to remember that a monolithic architecture ER is still a very useful development method for small medium size software projects, and many software project will still use this development style in the future. For many use cases, however, there are some major drawbacks when we are talking about large scale, complex application that are supposed to be a change more frequently, and to be able to effectively utilize a cloud environment, it is difficult to quickly deploy new features in an existing system, which is a critical business requirement in the digital data driven business landscape. A change we made in a small part of replication requires the entire application Toby tested and deployed. It is also a challenge. Toe coordinates their own going task off a large group off developers because they dependency between models and layers in that application and releasing new features one time or twice a year in a production system is no longer fulfilling the business requirement off many companies. Those companies are looking for much faster software really cycles okay, This is like the innovation, velocity and and better capability to use elastic, a cloud infrastructure now this limited ability toe quickly add and change softer features in a big, monolithic application. Is driving companies to find an alternative a better way or a new approach develop and maintain applications? Finally, coming back toe our main topic. This new approach is called micro Services, and in the next section we start to talk about this interesting concept. 10. What are Micro services?: in the previous section. We talked about the disadvantages or challenges associated with more analytic enterprise level application. It was an introduction for understanding a little bit better than nature off the problem, so we'll be able to move on to the solution. Now we are ready to talk about an interesting new approach to develop application, meaning micro services. Okay, so what? All those micro services? Let's define this concept at the high level as the first step before diving into the details. Micro services at the basic level is a software development architectural. That's it. It's not a new technology. Oh, a new market product. It's a new architecture on how to design, develop and maintain applications. In this new approach, a large application is broken into smaller model of pieces, and those small pieces are called micro services. Each micro service is a single function model, meaning it is supposed to perform a single main activity. And this is where the name is coming from micro services, a lot off small services that communicate with each other and each service. He's supposed to do one thing and do it well at the Marco level. We have a complex application that is performing multiple functions while using a group off micro services. A simple analogy Toe Micro Services is again we usedto playas kids, meaning Legos. Each piece off a Lego is stand alone entity. We can take those little pieces as building blocks and put them together somehow to create a bigger model. Each piece can be replaced if needed, and a specific piece can be used to build a variety off models. If you are a software developer today, you can jump back and say, What's the big deal here? Every big software is divided into smaller motors, and every model is divided in tow functions or objects. So what is so special with micro services? The answer to that question is that those micro services are completely standalone. Entities decoupled from each other with an explicit bone. The Reaper, each service each micro service is like a micro application. Imagine many small boxes. Each books is a stand alone Michael service one Micro Services holding a unique content inside, which cannot be accessed directly by other micro services. It has a what we call control boundary. Each books is developed independently and deployed in the production system independently. They are like, as I said, many application that communicate with each other it to provide the functionality off a complete and went complex application. Now, usually, Michael services are talking to each other using well defined rest. AP eyes will touch that a later. Let's use Ah well, airliners. Ovation System is an example. In a more analytic architectures application is divided into models, but all those models are usually developed using the same framework. They are running on the same application silver and are using the same centralized database in a micro service architecture. We're taking the application and break it down into multiple services. Michael Service Want to tree etcetera? All micro services will be used together to create a more complex business logic in the context off our example that will be a micro service like booking flight, checking inventory, allocate seats, update customer profile, manage rewards, etcetera. Services will be organized around business domains, and each service is supposed to be a stand alone unit that should be developed and deployed by the same team. Let's take a look at the building block off a single micro service in the next lecture 11. Looking inside a Micro-service: we can think about a single micro service as a small black box that is doing something specific, getting input or request from outside, perform some logic inside the box and then return. That is all this output. It is similar to the concept of functions in programming and function can get viable XYZ input. Perform some logic inside this, using the same put and can also eaten something is output, but I like functions that are based on the same code, the same language, the same running framework. Here, the services can be based on a completely different language. Those services are separated each Black Books does not know anything on the inside off another black books, but they can communicate with each other over the network. The books analogy is usedto emphasize that the micro service as a defined boundary. Also the inside off the books can be basically a mini system that is based on multiple components. Now, if we'll open is an example of single micro service, black books and take a look inside will be able to see three main building blocks. The 1st 1 is a P. I get way. The 2nd 1 is application logic, and the last one is data store. Let's talk on each of those building blocks. The first building block is the a P. I get way AP Eyes are interfaces o access endpoints toe a specific Michael Service and micro service AP Eyes receive a certain input as a request from outside, perform some logic and then deliver a certain output using the A B I gateway. It is how the micro service box is communicating with other Michael services. I'm sure you're familiar with the concept off Internet communication when I'm typing a u R L in my browser, basically the browser Translate this your girl to a simple HDP request being sent over the Internet. Where remote Web Server This Web server is providing a Web AP I that enables to access the Web pages in that Web server. This Web server is waiting and listening on a specific port numbers, forgetting request and response according to the content off each request. It's called rest based communication. The famous http protocol running inside the rest based communication is using a group off methods such as get post and put all the complex Internet communication that we're using day by day is based on this simple but very useful concept. One side is exposing an A P I as an access point, and others can send requests over the network. Toe this excess point toe. Get something Now. Michael Services took this Web collectivity concept and put that inside the micro service. Each micro service has some A p I get way that acts as a fundo as a front door to the micro service, and it's waiting and listening to request from other micro services. As we say, the micro Service black books should get and return data. So every micro service includes an A P I or maybe Cooper Phoebe eyes written in a specific way and impose the set off walls on how toe access it. Let's use oil Flight ticket application. Example. Let's say we have a Michael service, which I locate a seat inside an airplane, the specific ticket so as input it is expecting toe, get few parameters like the customer details, flight number and the type off airplane. Those parameters will be the input today p i. The output will be the allocated seat number toe that specific customer looking at the following diagram. Another thing to keep in mind is that the single micro service can expose one or even multiple AP eyes. And maybe some micro service will not expose P, I told meaning it is just consuming AP eyes off other micro services. So in the context off a P I gateways, multiple combination are possible. Let's move to the next building block. The next building block is the application logic, which is the brain off the micro service that is supposed to do something useful. The A P I get way we already covered will trigger the inside application logic as an example. Think about micro service that is supposed to get a picture as an input and return a text with the type off objects identified. In that picture. They peer will be used to trigger this micro service with a picture file as an input parameter, and application logic will be used to process the picture and identify objects in that specific pictures. That's the complex forces encapsulated inside a specific Michael service. Finally, the micro service will send the identified objects as output through the A P. I get way now one off the greatest benefit ill is that the code developed for the application logic inside a specific Michael service is completely independent. The thing that developed this Michael Service confess Terfel select the best language to do the job to fulfill the task. In our example, the task is toe identify objects in a picture, okay, And for they selected, the pie tone is the best language to fulfill that job. And then they can change the code bases needed without wooing about other micro services that can that are using this specific Michael service the only thing that should always be consistent with, you know, other micro. So this is the way toe access the A P I gateway. Now, as a side note, this approach is also called a polyglot programming, which means the practice off writing code in multiple language to capture additional functionality and efficiency that is not available in a single language. The last building block is about the data. The gold mind off many applications. In most cases, the application logic will use some data stored in a database while performing the needed logic. If the micro service is, for example, check flight inventory than the application logic should quay some database and maybe also store something that's clear now. In some cases, we may assume that multiple services Multiple Micro Services can use the same data store as models in a monolithic application that are using the same database. However, the situation is not aligned with the micro service approach. The best practices for Michael Service Architectural will be that micro services should not share data store with other micro services, meaning each micro service should encapsulate its own data store, and other micro services will not be able to access that data store directly. They can off course access that data stow indirectly while using the micro service AP I get way again. If you're a development today, you can say, Are you crazy? For each Michael service, we will now manage a separate data store. Instances we will end up with too many data stores. So why we should consider this approach? Okay, there There are two main reasons for doing that. The 1st 1 is related to the capability off developers off a specific micro service to change the data store without affecting other micro services. They can develop test and change things in the Micro Service data store, which can help to speed up the process off. Updating the micro service capabilities, Secondly, is that each development team can decide what will be the best database technologies to be used for a specific service or a group of services. One service can use a relational SQL database for particular use. Case and another service under the same application can use a distributed big data solutions going back to the Tree Micro Service building blocks, meaning the A P. I get Weight Application Logic and the data store. We're getting a stand alone services. Each service is like a separated many application. They don't need to know anything about the underline implementation or the architectural off other micro services. That's the reason why a single team can manage the complete lifecycle off a specific micro service. So that was an overview at the micro level, meaning the building blocks off a single micro service as a reminder. If you would like toa, ask something or share your own experience, please use the course. Dashboard in the next section will move on, toe the Marco level and talk about the micro service architecture 12. The Concept of a Microservices Architecture (MSA): In the last lecture, we saw the building blocks off a single micro service. Now we can move on and talk about the architecture off Multiple micro services, walking together to form a complex and to end application. The micro service architecture is a method off developing application as independently deployable, small model of services. Each service has its own unique and well defined all. It's supposed to do something specific. Each service runs as a singular maybe group off unique processes. Those services communicate a everywhere, well defined AP eyes over the network. Each micro service is supposed to be deployed, upgraded, skate and restarted independently. Now the more low level definition off a micro service architecture is a spectrum. There is no clear cut definition for such architectural. Still, there are some best practices used in the industry today that we will use to describe this meddled. And that's the goal off this section 13. Small Size and Loosely Coupled: Let's say some company has a new, fantastic, interesting application to develop. How sure they divided into micro services. Should they use then 20 100 services, maybe 200 services. That's a good question. Now, I'm not planning to make you a developer, but it is an essential to understand what that one of the main challenges when moving Toe Micro Services is the decision on how to divide an application into services. What are the fundamental principle to slice up the application? So one of them is the size off a Michael service? What is the leading business domain Toby covered by this Michael Service? What kind of functions will be covered? How many people will be part of the team that will develop and maintain it, trying to figure out how big an individual micro service has to be in the context off defining the size off the team that will be responsible to a single micro service? Some companies, like Amazon, invented the concept off, limiting the size off a team that can eat to pizza boxes. Okay, sound like a joke, and I'm not sure it is a good you know. All off Tom toe all cases. But still, it is usedto emphasize that the team should be small, which also means that the complexity off a micro service will be limited. The scope off a single micro service should be Nello and focused on some single business domain in a small set of capabilities. In simple worlds, a service should do one thing and do it well, keeping in mind that those small services are walking together as a group to create more complex and toe and application in a monolithic application, we can divide, of course, application into model components. However, most development language used to develop those monolithic application do not have a suitable mechanism for defining a clear, explicit interface between components. Basically, it's up to the developers to keep those boundaries as much as possible and prevent breaking the components in caps elation. Eventually, it will lead to tight coupling tight connection between components. One things we change in one part can affect multiple other parts in a micro service architecture. Each micro service component is designed as a black box. It is like a black box because it is hiding the details off the internal complexity off that box from other micro services. There is an explicit boundary between the micro service black box toe to the outside. Each micro service will be developed with its own base code. As a self contained entity, it will not refer toa any code outside the micro service boundary, so there are no hidden dependency. Any communication between micro services is on Lee happening via a remote cold mechanism with a well defined AP eyes using the A P I gateways. In other words, we can say that micro services are loosely coupled between themselves and this loose coupling is the greatest advantage off a micro service architecture, different components. In a micro service, architecture can be changed, upgraded and replaced independently without affecting the functioning off other micro services. Other components. More than that, services can be shared and combined easily with other applications. So there could be a situation that two different applications are using the same micro service. Okay, think about a simple analogy, like an electric bike with a battery. Okay. It makes sense to design the bike in a way that the battery will be easily extracted and replaceable as a separate component from the bike body the same concept is essential in micro services. An application that was designed using micro services can by definition be broken down into multiple services and multiple components. Those components can be independently replaceable and upgradable without having toe redeploy the entire application and basically compromise the integrity of that application . It is like a Lego game. 14. Organised around Business Capabilities: in the traditional monolithic development approach. The development department is usually divided into teams that are like a meal off the multiple tiers or multiple technologies in the application architecture they develop. Let me explain that a little bit more, we will see a team which is focused on the application user interface you esteem. Like HTML Web developers, a separated team related to the database infrastructure like big data experts and other team maybe organized around a P eyes for that application, a team for several side logic and so on. The focus is on technologies and layers. It's looking like, for example, like the following diagram. There is a You I specialist, Middle will specialist and DB Ace. The most significant disadvantage here is that when there are multiple teams, every change in the application can lead to a costing project that will be orchestrated very carefully involving several different teams walking on that specific change if you think about it for a second, the organization structure is organized according to the monolithic software architectures . Now, this stone linkage between the organization structure and the software created by a specific organization was actually captured many years ago by a person called Melvin a. Conway, saying that any organization the design assist them will inevitably produce a design whose structure is a copy off the organisation Communication structure. Now, over the last few years, multiple organization understood this stone linkage between their internal structure and the software they produce and decided to embrace new structure. Companies like Netflix and Amazon were really the industry pioneers. And, yes, it's based on micro services and micro services. Architectural is changing the monolithic application approach entirely. Okay, in this context, instead, off looking on technology or people skill sets as a way to organize, deems Let's first off all organized. The building blocks often application around basis capabilities what kind off business capabilities the company is trying to create. And based on the required capabilities, the application will be divided into services. But not just that. I mean, such services can utilize at the end of broad stack implementation off software for a specific business area. Okay, the same Michael service can includes user interface, some database storage technologies, some business logic and so one. So, as a result, the teams that are divided according to a services will be actually course functional, including the full range of skills required to design, develop and deploy each service. Each team will be responsible for a small part of the overall system. Each team will have multiple skill sets, so they will be independent. For example, a. You a developer at back and developer a DB, a expert and operation engineer on the same team. If something should be changed in the u I or the database there, our team members with the needed skill sets. As a result, such independent teams can own the whole life cycle off the services they create managing services as small products and with a higher degree off autonomy, compared to a large team with more monolithic base called. 15. Managed as Products: I'm walking A as a solution manager, also called pre sales manager for many years in the software industry, and when talking about software models, Aziz products it is usually connected to the commercial side, meaning each model it's off softer model will have a license cost and will be presented to customers as a product. Now, when managing a model as a poor, that it actually helps to create the important linkage toe the business requirements instead. Off Looking at a model is just a set of functionalities that is a ongoing air forts toe adopt and also enhance the software model according to some road map. Now the same approach off managing products in a monolithic applications and dealing big models is also useful at a smaller scale with small micro services. When each services operated as an internal product, it will have a dedicated road map enabling a separated, evolving pet with stone linkage toe the business requirements. Each micro service team will be focused on making the service useful and continuously a updated according toa own going new requirements. The second issue is related TOE develops in traditional application development. There is a clear line between the team responsible for the application, development, meaning or kind of developers on one side and the team responsible for the actual deployment and daily operation off that application In the production environment, any update to the suffer is at the end. Like a mini project, it is starting with assembling. The needle resource is meaning the project team and the first milestone will be off course , developing the new features in that application that performs some testing. And finally, when it is ready, it will be handed over to the operation organization. OK, take it and deployed in the production system. And probably after a while, the project team will be re allocated again. Toe other project. It's the structure off a most organization now. The micro service architecture is aiming tow. Avoid this one time project approach and use a new model that each team will be responsible for specific Michael service and manage it as an internal product over its full lifetime. As Amazon coined the notion you built your on it a emphasising that a development team should I take full responsibility for the sofa in the production environment? Maybe you heard about it, but this principle is also known as dead drops development and operation Walking together. So the developer will also be involved in a daily interaction with end users and ongoing A production issues many companies that are actually adopting this organizational structure as a critical prerequisite to use a the Michael Service architecture. 16. Smart Endpoints and Dumb Pipes: Another critical aspect when moving to a microservices architecture is how to implement they inter-communication between them. Now, this lecture is a little bit more complicated. So try to stay with me as much as possible and don't worry so much if it's not 100% a clear. I tried to simplify that as much as possible so we can get the, the main concept. We already talked about it. If you remember from previous sections, that in a traditional monolithic application, different software components will be in the same process. So maybe in multiple processes running on the same Silver. And the communication between them will be based on in-memory calls like function a is calling function B. Now, on the other hand, microservices are supposed to be separated between each other with a clear boundary. And in some cases, each micro service will be maybe also distributed across multiple instances. So it is raising a fundamental question, how micro services should communicate with each other? What is the best way to exchange messages between them? Now del, two main message exchange patterns that can be used. The first one is called request response, and the second one is called Observer pattern with a message broker, Let's see each one of them. Starting with the first one, request and response. When looking at the structure of a micro service, we saw that each micro service expose access endpoints that can be used by other microservices. It is similar to the famous client-server model being used to deliver Web content in the internet. The micro service endpoint are used to process information and apply the internal logic in each micro service. All the smart part is happening at the endpoint. Inside the micro service. Each micro service can call any other micro service. It is these centralized communication. The communication channels are just dump pipes used to deliver the input and output of each micro service. Using this request response model, one service send that request and expects immediate response. The response can be acknowledgment like telling yes, I got your request. Thank you. Or it can be specific expected output from that service, like the name of the customer is Joan. Now, in real-life scenario, some micro services will need to handle high traffic load. So maybe few instances of this same micro service will be created. And then some load balancer component will be used to balance the incoming traffic between them. We have there. Originating service that is sending something. And then a load balancer is getting the requests and decide where to route it based on the load of the backend instances of the same service. It's very simple approach. Keep in mind that every communication here is always based on expected response, meaning one side is asking or sending something, and then the same side is expecting to get the response from the other side. Meaning side a is waiting for that response before moving on. This approach is of course widely used. Think about a user interface for an application, almost every action that is performed by end user is expected to be handled. This way. Some user is trying to login to the system. Then the service that is sending the user credential for validating a test is expecting to get the answer right now, waiting for the response so it can be reflected back to the user that is trying to look right now. However, there are some cases that this synchronized method is less effective. Not every action or use case in a software application should be handled as you know, as a workflow. Step one, step two, step three, there are some cases that process should be a parallel workflow. Now we're getting to the second approach of handling communication between micro services that is called observer. Observer pattern with a message Balkan. The observer pattern is used to implement a distributed event handling system. This is the message broker and the concept is very simple. The message broker is used to create multiple data pipelines. To which data pipeline we can connect. Producers, which will be the data sources gating the messages in that specific pipeline. And on the other side would be consumers, which will be listening to new messages coming in that specific pipeline. Maybe you heard about it. For example, the Apache Kafka, a solution can be used as a message broker that is used to implement event-driven system between component in a complex architecture. Now going back to microservices, if I will explain the process here. So micro service will send the message. Are there specific topic to a message broker? Other micro services will subscribe to the message broker to automatically get notification that there's message is waiting for them and their specific topic. Okay? When implementing such Message Broker, multiple microservices will subscribe to one or may be more event, uh, topics that they need to respond to. There are, of course, multiple advantages for such event, a driven system. First of all, the micro service that is producing a message does not need to know which services should handle this message. It basically published the data to the message broker, and that's it. Secondly, the message broker will manage those messages in a dedicated accuse. If the micro service that should process the message is busy right now, the message will wait in the queue until it will be less busy. And also the producer is also not handling failure and retries. It is just simple mode, fire and forget. And all the such problem will be handled in the message board kills a layer. And in addition, this is the third one. New types of consumers can be added easily without the need to change anything in the producer side. And the last one is that the consumers don't need to query the message broker for messages as the system will automatically notify them. So those are the two options to implement the communication between micro services. 17. #1 - Independently Developed and Deployed: Until this point, we mapped in great detail, say the building. Look off a single micro service as well as the key characteristics off a micro services architecture. In this section, I would like to talk about the value off micro services, meaning what are the benefits While using this development a metal. We saw that the micro services architecture is based on the approach off decomposing or breaking an application into different smaller models called Michael Services. Those micro services are the coupled from each other, each micro service as a clear business domain boundary and a specific scope organized around basis capabilities. They are like black boxes models with well defined interfaces. The first key benefits off micro services is that they can be independently developed and independently deployed. And this is a killer advantage compared to the one big monolithic application old school approach. Different teams okay handling different micro services can walk in parallel to each other, according TOA ongoing requirements and with different velocity. One service may have many development. It oration because off a major functionality gap, while another service may have fewer changes because it's more mature. Those services are managed as almost as separated many products, each one with a dedicated road map. This approach is letting each team to be more agile in minimize their required coordination between a large group of people. Now looking from the developer perspective, an application written using Microsoft offices will be just as complex as a morality complication. The key point here is that because a monolithic application he's handled is one big entity , each developer must understand this application is a hole and to end which is, of course, much more complex. On the other end, with micro services, the developers can focus on smaller components. Smaller chunks. Think about the process off the bugging. A single micro service. It would be much easier compared toa finding bugs, Finding problems in one big application if I would summarize. One of the major benefits off micro services is the speed and parallel development capability. Development teams can walk on different parts off the same application at the same time in a different spit. The next important benefit is related to deployment, meaning the process off upgrading an existing system in production in monolithic application. It is usually a nightmare for a system of misstate ALS first of four. They need toe allocate something that is called maintenance window toe power down the system for the upgrade process, which is not an easy task when many and users are using the system. Secondly, when doing a full system upgrade, usually you know bad things will happen as the reality is always more complex than a set off pre defined testing scenarios. In a micro service architecture, the ongoing deployment is supposed to be more simple. It's service can be deployed in its own timeline without complex dependencies, when some change is required in a certain part of the application on Lee, the related services can be modified and redeployed. We doubt that he deploying the entire application. 18. #2 - Frequent and Faster Delivery: putting aside for a second the capability to deploy Michael Services independently. As we saw in the previous lecture, let's talk about the business benefits. We're in the middle off a huge revolution in many industries right now. All of them understand the power off, controlling and managing the data much better. There are a growing amount off business models that are completely digital driven. They are based on data and data is collected and managed by software. Software is everywhere. Customers and I o T machines are sharing data and accessing products and services from a going amount off access points toe. Be competitive in this digital driven market. Organization must be able to respond faster, toe new requirements you market's needs and ongoing changes in the business landscapes thinks are moving faster. Micro services is a solution to the challenge. Micro services were developed is a way to divide and conquer. Each micro service based code is managed by small and agile T. The dependency between micro services having on one another is the AP eyes. And as long as the teams are maintaining backward and forward compatibility, each team can walk in release cycles that are the coupled form other teams. There are, of course, some scenarios will. Those release cycles are actually coupled when one surveys depends on another or depends on a new feature in another service. But this is not the usual case. By using Micro services, organization can perform much frequent and faster delivery off software changes by releasing application much first. Still different, you know, basis owner Inside, each company can get quick feedback from customers or end users and make you know faster adjustments adjustment off course to the software called. But it also can be to the business model or the you know, target audience and so on. It is a faster closed loop scenario. More than that, because the application is divided into micro services and each micro services directly driven from the business domain, it may be possible to measure the cost and revenue off each. Micro service, like the cost off development resource, is ideally sources in the production system. Etcetera. Business owners can better truck where the money is going and how to better allocate. Resource is moving them from low impact business domains to hire or better business domains with a monolithic one big application any changes will require a full built and deployment off the entire application, which will slow down the alley cycles With micro services we need to re deploy on Lee the service or services that will modified. It is more granular, really spells service or small group of services. This approach speeds up the ongoing release process. The downside is that they're more release cycles to manage and orchestrate. And, of course, this process must be automated. Somehow this is moving us toe. The next topic in this lecture, which is continues delivery Toby ableto effectively manage the release cycles off a large number off micro services. We have the option toe automate their own going process off integration and deployment off software releases. It is called C I and CD okay continues integration and continues a deployment a instead, off releasing versions every few months. As we saw in a monolithic application, let's look on that as a continuous process, releasing new software features every few weeks, days and even a few hours if needed. The key benefit off Micros Ellis is is that they work really well with continuous integration and deployment in a complex application comprised off many services. Different services evolved at different rates, so it makes sense that each service will have a unique continuous instigation in developed very pipeline week. Ongoing upgrades Okay, like service A version to service be version six service see version tree. Each service is continuously developed and separately maintained and independently deployed in the production environment. Continuous interrogation is also aligning toe the concept off end Elling and Micro service as a product, a product that will be improved and optimized quickly, which will have its own a so scored management repository and its own delivery pipeline for ongoing bills and deployment. Developer can implement back fix an announcement at any time without waiting for major application upgrades, something that is not really possible in the monolithic approach where the speed off each release is basically reduced toe the rate off the slowest moving part 19. #3 - The Best Tool for the Job: in a monolithic involvement. The court for the application is typically developed in a single language. The developer will select some uniforms technology framework. If the development team selected Java as the unified development framework, they're probably most off. The models in that specific application will be developed in Java. They are expert in that language, and they will keep using it. It will be always a compromise between capabilities and the desire to unify the framework as much as possible. This is true not just for the development language. Of course, it's can be for any other unified component this part off the application. For example, if we selected Oracle is the main database, then it will not be so easy to replace it in the future for handling new requirements. Because many models are using the same database technology, it is a centralized data store. In a micro service architectural, there is no centralized components. Being used by multiple micro services is the other way alone. Michael services are decentralized in the way they are developed, deployed, managed and operated. Each micro service has its own business logic and its own data store. They are off course composed together to form a complex application. This decentralized approach as a huge benefit for developers because micro services do not need Toby written using the same programming language. One team that is handling a specific micro service can select. For example, Java is the language, and my sequel, Relational Database, is a data store. Another team handling completely different micro service under the same application can select, for example, pie toned, combined with the mongo DB no sequence. Each one off those teams has the freedom or flexibility to use the best feet technology for the required functionality, helping to solve their specific problems or, in other words, select the best tool for doing the job. There is no stand arised technology. Parton Unified for all Micro services. It is also called the Centralized A governments, and the fact that small teams can almost autonomously select the best appropriate A technologies, frameworks and tools for their domains is basically essential. Dorival for innovation 20. #4 - More Granular Scaling: The next benefit I would like to talk about is related to the concept off scalability. Scalability is the ability to rapidly and continuously change resources. According toe. The current capacity depends if the load on some application is going enriching at at some point in time, the maximum capacity off the allocated. If he sources, then the system performance will be negated. Think about the website that is designed to handle one K users per minute, and suddenly 100 K users are trying to access the same site. Probably most of them will not be able to access the specific site. It is a scalability challenge, and it is happening everywhere in many software application. Can you imagine that Amazon site Google Maps Service will be down because off a performance issue in today business landscape, it is almost unacceptable. Online services are expected to be available 24 hours, seven days a week. With minimum downtime. Companies are putting a lot of focus on user experience, and performance issues are a critical factor to consider. Monitor and manage. The good news is that visual ITV sources provided over the private over public cloud service changed completely. The way we tackled a show off scalability. And today, more than ever, cloud native applications are expected to be able to utilize the elastic capability off. Cloud Resource is in the monolithic approach. We have multiple models learning on the same application. Silver. Let's take a simple example often application with only three models A, B and C. All of them are based on Java and are running on a Web logic application. Silver. If the load on Model A is going, then we need to do something. And we already talked about it in previous sections. There, too, well known options scale up or scale out. Now those scaling options are very useful. However, if you think about it, it's not an optimum best solution. First of all, we need to select a virtual server that will handle all three models A, B and C. Now, if Model A is based on CPU intensive war clothes and on the other side, Model B is more memory intensive walk load that the all the whole virtual server can be quite expensive or maybe less optimized for both of them. Another issue is that a load on one model can influence the performance off other models because they are sharing the same resources. However, if the load is only related to Model A, for example, why should we scale the sources that are elected to other models? It's basically a waste off. Vital resource is all those issues are solved when using micro services, since in micro services architectural, an application is divided into several different services. Each Micro service Kameron on Dedicated Resource is providing the capability to scale in the vigil micro services according to a specific localised bottlenecks in that specific service. The individual micro sizes can be individually skilled. It is more granular scaling and therefore more optimized scaling, which is making an application more cloud native. Let's use our example off the airline reservation system. We will have multiple services when using micro services, and each one is responsible for a specific function or business domain. For example, one service might handle an online chicken when another service will manage their own line booking OK, but each service will have multiple instances according toe the required capacity. Each instance off the same micro service. It is created when it's required, and when the extra instances become redundant or underutilized, and they can be destroyed. To save resource is in a cloud environment. Everything is monetized. It is usually a service we are paying for according to the actual allocated resources. So if we pay for each instance, it is not making sense to keep them when they're not needed anymore, it is also useful for better isolation and overhaul system resiliency. If a specific component in some micro services malfunction, we can quickly spinoff another instance off the same cell vis using containers, while the rest off the application continues to functions. The most important thing I would like you to remember is that micro services based architecture can better leverage the power off a cloud environment and effectively handle less predictable workloads. 21. And also few Challenges: we all know that nothing is perfect. Micro services architecture has excellent advantages, and it's useful approach for complex, cloud native applications. Still, there are some challenges. Problems and trade offs associated with a such approach. Let's talk about the main challengers when moving Toe Micro Services. The first challenge is related to the overall software architecture. On one side, the services are becoming most simple and smaller. Smaller models are easier to design and code. However, the overall architecture is getting more complex as the number off services goes. It's a trade off smaller places, but much more pieces. Also don't services are walking in a distributed architecture, so it is an additional complexity off a distributed system In a monolithic architecture, the complexity and the number off dependencies between models reside inside application base code. Why Microsoft uses architecture. The complexity moves to the external interaction off multiple services. Developers have to put additional effort into implementing the best mechanism off communication between the services. If you remember, we talked about it in the smiled, endpoints and dump pipes, a lecture. Let's say we have to services, so it's a and so always be and the selected communication channel. Between them should be direct integration, meaning not using a message broker in the middle. Each service can be based on multiple instances that are created automatically by the cloud environment, according to ongoing changes in the traffic demand. Okay, this is or resentful scaling kating More instances off the same service now to the question when a new instance off the same cell VC skated or destroyed how other services will know which instances relevant when they are trying to call that specific service service instances. We live dynamic locations. Think about arrest AP. I request Service A. Would like toa call some a p. I get way off a service Be now what will be the I. P address and port number off the remote instance without going to the low level details? The answer is that Selves discovery mechanism should be used or a message Brocail DNS or load balancer component. And so on. The off course, Several options to consider services are communicating with each other over the network. Those remote calls between services actually more expensive in terms off resource is than in process calls in irregular, monolithic application, so network bandwidth and latency is something to take into account. Think about a situation off to services that are located in different two data centers. When they communicate, there will be some latency between those data center, so this is something to take into account. Morning. Towing a software application in a production environment is an extremely important practice collecting logs, metrics and alarms for multiple layers. Now, when using micro services that can be hundreds off micros Elvis components. In instances, some of those services may not be in the same several or the same cloud environment. It is a distributed as well as dynamic involvement in the context off money towing it is becoming more complex toe. Analyze telemetry data being collected from such dynamic distributed environment and, for example, pain point on faulty services or identify potential performance problems. A monitor, the over or system health and how to debug interaction. Because the system, if you have so many micro services okay, it's a challenge. The last challenge I would like to mention is related to resiliency. Failures will happen one way or another. Okay, this is the reality. It can be. Some hardwell fail. Oh, it can be corrupted data some external Selves, downtime and so want, though many situation and the application should be designed. Toby something that is called fault tolerant as much as possible, for example, making shoe that if one services down, it will not cause a cascading fellow off multiple services. Now, probably it will be smiled. Toe. Identify well. All the core services in a specific system in specific application that are basically are used like a main junctions with high trophic going into them and make sure that those specific cold services are not a single point of failure. Well, kid, these are important consideration while designing and using micro services architecture. There are, of course, small things to consider when moving to Michael Services, and I assume more things will pop up as more companies are experienced. This in New Path. Nevertheless, it seems that for many companies, the benefits off a micro service architectural overcome completely. The challenges associate ID when using this new approach 22. Netflix - Industry Case Study: hi and welcome back to our last section in this training as a nice industry example, I would like to talk about the Netflix case study in the context off Michael Services. As you probably know, Netflix is a media service provider in a production company. The main business model is a subscription based streaming service, which offer online streaming off films and television programs. According to Wikipedia, as off 2000 and 19 they ever over 148 million paid subscribers worldwide, including myself. It is a global service, and I would like you to think for a second about the software application and underlined infrastructure Netflix is using to operate and maintain it to be able to provide such a high quality service worldwide in the context off micros Elvis's Netflix was one of the first companies that identified that their existing Morneau Politic application architecture is not the best solution for handling the streaming services. This is the main data centre back to 2000 give or take. In this diagram, we can see a classical traditional software architectures er, and we have and uses like customers request coming from the Internet that are going into a load balance cell, which access and evil spoke. Seafront and Web Ceval Here It's based on Apache, and then this Web seven is accessing a job application server, which is based on Tom Cut Java In my environment in this application server, they had a single big application called Java Web, developed by Netflix, a team that was handling all required functions for their services. Application server was connected toe a centralized Oracle database using J D B C and then interconnected using a D billing toe another or collect the base for handling billing information. As you probably guessed, by now they had several challenges. With this architecture, the 1st 1 is more analytic code. This is the Java Web application. They developed all development teams. Netflix. We're walking on the same base code, and when some change caused the problem, it was very difficult to trace and troubleshoot the problem. And because of that, slowing down their capability to keep adding features and upgrade the code is needed. Okay, Classical example. Secondly, it was a monolithic database, something that is very common for many application. In their case, it was one piece off Hardwell running one big Oracle database. You can imagine that when this database went down, everything went down. It was a single point of fellow. Also, it was a challenge to scale. It's such database. Those days, the only A options was to perform vertical skinning being scale up by finding a big hardware machine, which is very expensive approach, they add. Also problems to match the resource is toe the growing demand and usage bottoms, and the last thing was that it was tightly coupled. Architecture. Everything was deeply interconnected. For example, many application models were referring to the same database schemers because they used a centralized database. Toe models were connected in many in process connections, making the base code one big spaghetti. Every change was a huge effort for the engineering team, and as a result, Netflix as a company, was suffering from Slope August's and lack off agility when it comes to releasing new soft of features. Because off those four main problems, they decided eventually to build a completely new software architecture based on micro services, they decided to create small services that handle separated business functions. Each function has a self contained service with a well defined interface This diagram representing high level how customers are accessing a very large age, layer it with smart load balancing and traffic Kulti capabilities and then Netflix AP eyes gateways are usedto access a variety off micro services to fulfill the request. For example, Recommendation Micro Service is used to provide a personal recommendation, but each subscriber like a movie list. They are also infrastructure services, like shouting. So Michael services confined each other and so one. So this is about Netflix. There are off course, more example of companies that are already using micro services or paving their way in that direction. Overall, I think that fixes very interesting a nice case study. 23. Quick Recap and Thank You!: my course services. Architecture is a huge step in the sort of development industry it started with the big players like Netflix, Amazon, Google and others. Over the last couple of years, it is getting spread around as smaller size companies. On adopting this new approach. I'm walking in a company that develops software products and solution for the telecom industry, and I can see how customers are pushing soft of Vandals to support micro services in the off the shelf products those customers are looking force off the products that can be implemented in a cloud environment. So this trend is coming for multiple directions. In this training, we talked about the old school software development style called in a negative way, more analytic applications, meaning application that, AH, one giant base code written in the same language, and specifically, the challenges and limitation that companies are facing while using those application for multiple use cases. All those problems created the right conditions for using a new approach. Many Micro Services Michael Services are the foundation for cloud native application, so cloud computing and micro services are two trends strongly connected. A single micro service is like a black box with three main components. AP I get way Business logic and data store. Each service has a specific function in cups, elated inside that service, and a group off services is used together to form a complex application. Those services are the capital form each other okay, separated and therefore introduced multiple advantages while using them in a soft architecture. They can be developed, deployed, skilled and maintained as almost separated. Many applications each Michael service can handle a specific business domain, and a dedicated team has the option. Oh, advantage to manage the complete lifecycle off a particular service. This new approach supports the market demand for frequent software release cycles and also the requirement to implement application in a dynamic cloud environment applications that are more cloud native. That's a quick recap. Two things we learned doing this training. I want to thank you for watching this course. I hope that you enjoyed it on land a few things along the way. It is important for me if you can spend a minute to raise polls and shell you experience, that will be also and useful. I hope to see you again in my next training post. Bye bye.