[MUSIC] Before we learn about what microservices are, let's look back through time to see where the idea came from. In the early days of software development, developers made large, monolithic applications. These applications usually were developed by a large team, all working on the same code base, and were made of code, written from the ground up, specifically for the application. Large monolithic applications were hard to maintain and scale. They took a long time to develop, and as their complexity increased, they often suffered from performance issues. As a response to this issues, service-oriented architecture, SOA would introduced. SOA provides principles to guide developers to break down the functionality of their monolithic enterprises into smaller more manageable, modular services. These services are loosely coupled and strictly encapsulates. Each service is intended as a tool that the organization or external organization can neutralize to perform some task. SOA encourage the users remove services as well as local services, they comprise the enterprise. Microservices can be thought of as a variation of SOA applied on an application scale rather than enterprise scale. Additionally, some SOA principles have been refined to better support application scale systems. The microservice architectural style is the way of composing microservices to produce complex applications. A microservice is the process that is responsible for performing a single independent task. A microservice typically is built to perform a specific business capability. For example in an application, one microservice can be responsible for implementing a search feature. Another microservice can implement a recommendation feature. And yet another microservice can be responsible for implementing a rating feature. Microservices are developed and exist independently. But ultimately, they are composed together to provide the overall functionality of an application. Often each microservice does not obey a full layered architectural style because microservices are composed with other microservices and not always intended for end users. Presentation and application layers may not always be present, that being said, usually each microservice controls and manages its own data. As a result, the overall application will not generally follow a layered architectural style. Take for example, an online library application compose of the following microservices. Each microservice has a well define interface or API that informs other microservices how it can be use and communicated with. Most microservices communicate with each other over the web, using communication standards and protocols such as HTTP or XML. REST interfaces are use to keep communication between microservices stateless. It's desirable for each request response to be independent of any other request response. There's a growing trend in the software industry towards the use of microservices in web applications. Why are microservices so appealing? A benefit of communication between microservices being independent of the implementation of each microservice is that microservices can use languages, frameworks and architectures that are best suited to the service. In other words, this means that different microservices can use different languages, frameworks and architectures, independent of what other microservices within the same application are using. The benefits of this are two-fold. First, it allows developers to create a service using the most appropriate tools for the job. And second, it provides the opportunity for developers to try out new technologies, without making an application-wide commitment. They make applications easier to scale and maintain due to their loose coupling. A particular microservice can easily be scaled by replication. Introducing multiple copies of the same microservice allows several request of the original microservice to be handled in parallel by the other instances of the microservice. For instance, a microservice responsible for processing orders could be replicated to increase the throughout of processing large volumes of orders. Each order, to be processed, could be distributed evenly among instances to balance the work. Introducing multiple copies of the same microservice also has the effect of making the application more resilient to failure. If one instance of the microservice fails, the other instances can continue functioning. Sticking with our previous example of a microservice responsible for processing orders. If this microservice has been replicated several times and if all of a sudden one of the instances is no longer functional, the remaining instances of the microservice can continue handling the orders. The throughput of the system would decrease, as there would be one less microservice instance processing. But users of the system would not be aware of the failure. Not all microservices within an application need to scale at the same rate. Due to their loose coupling, microservices can be scaled independently. When the application needs to be updated, repaired, or replaced, this can be achieved with one microservice at a time, without effecting the rest of the application. Each microservice is developed, deployed and maintained by a small independent team. Each team is responsible for a small piece of functionality of the entire application. So they don't necessarily need to be familiar with the whole application to be able to do their jobs. This allows for microservices to be developed quickly and in parallel. Although many advantages come along with the microservice architectural style, there are also some drawbacks to consider. An application composed of microservices is the distributed system enabled through asynchronous communication. This means some centralized management of all microservices will be required to coordinate all the microservices. Databases will likely be distributed over multiple microservices, and transactions may span multiple microservices. Without some central management, the overall application state could become inconsistent and result in errors. Testing a distributed system is more complex, due to changing test conditions. Difficult to reproduce bugs can be introduced from the complex interactions between microservices. Another thing to consider is how the application will cope when a microservice fails and there's not another instance of the microservice to take its place. The other microservices in the application must be robust enough to handle the failure gracefully as they may rely directly on the failed microservice. The microservice architectural style can be used to create entirely new applications. It's a style relevant for applications that can be broken down into a collection of tasks or business capabilities. Since most applications can have their functionality separated like this, microservices have a wide reach of applicability. The exception maybe older monolithic applications that rely on precompiled binaries. Replacing these could potentially be more challenging, because the code base has become rigid and brittle in the sense that it is very easy to introduce bugs when making seemingly small or simple changes. Modernizing a code base like this may require much of the application to be wrapped. Another nice property of using microservices in your application is that microservices can be local, remote, or some combination of both. Microservices are ideal for promoting and facilitating code reuse. By separating all tasks into compartmentalized microservices, the functionality of these services can be easily composed and recomposed to suit the needs of the application. This makes microservices ideal for large applications. Microservices help keep code understandable and manageable. Another point to consider is the amount of communication that will be required between microservices in an application. The messaging between microservices, be that through HTTP, XML or some other communication standard and protocol have an overhead cost associated with their use. Also, communication between microservices is stateless. Depending on the application, however, it may be desirable to track the behavior of a user interacting with your application. For a web application, you can do so with web cookies. But your application will now potentially have more data to transfer between microservices. Again, this will lead you to consider the overhead cost of communication. Now that we have a better idea of what kind of applications benefit from microservices, let's take a look at an example. Consider a restaurant guide that allows users to find nearby restaurants, place a reservation, and review a restaurant all using the same web application. To provide these features, we can break up this application into the following microservices. A user interface microservice that allows the user to interact with the application. A restaurant catalog microservice that provides all restaurants in the system. A restaurant reservation microservice that places a reservation with the selected restaurant. And a restaurant review microservice to access and make restaurant reviews. Assume all communication between microservices is HTTP and REST base. When you visit the website for this application, the user interface microservice, prompt you to enter your location. When the address is entered the user interface microservice communicates with the restaurant catalog microservice to determine nearby restaurants. Then, this information is communicated back to the user interface microservice and displayed to you. When you click to view more details about a particular restaurant, the user interface microservice communicates with the restaurant review microservice to access the reviews of this restaurant, and then displays them to you. It also gives you the option to write a review. Also when you review more details about a restaurant, you are given the option to place a reservation at a particular time. When you click to place a reservation, the user interface microservice communicates with the restaurant reservation microservice to inform the restaurant. Then it displays a confirmation message provided by the reservation microservice. If you choose to review the restaurant, the user interface microservice communicates the review to the restaurant review microservice so that it can be saved. To stay relevant, businesses need to adapt to the ever changing technological landscape. The microservice architectural style allows developers to make applications that can be easily updated and scaled. In this lesson, we've explored some of the benefits and disadvantages of using microservices, learned what makes an application well-suited for the microservice architecture style and explored how this style can be applied to an example application. >> Congratulations, if you made it to the end of the video content in the specialization, you should be proud of yourself for making it this far. But you're not done yet. You still have a few more assignments to complete the fourth module before you earn that specialization certificate. So go on and show us all this new knowledge that you've obtained. It's been a pleasure having you join us, and wish you the best of luck in your future endeavors. So what are you waiting for? Go on and earn the certificate.
