Welcome back. In this lecture, we'll provide a quick study of both monolithic and microservice based architectures. In doing so, we'll establish a foundation of theory for building large, multi-component based software applications from an architectural perspective. This background knowledge will help us understand and appreciate the monolithic to microservices migration scenario that we demonstrate in the remainder of this course and the following course. For starters, lets do a side by side comparison of monolithic versus microservice. 

As seen here, monolithic based applications tend to have a very simple layered structure of components. In this case, a typical three-tiered application exists of a user interface layer, business logic layer and data access layer. Communications passes synchronously from top to bottom, and then back in the reverse. All data resides in a single database. And access to it must be performed through the data access layer. Often, this monolithic design is implemented in a single language and is built and deployed as a single unit. 

Meaning that there is often tight coupling between components and/or layers. At the outset of any project adopting this design, implementation testing and deployment is both simple and quick. However, over time, the ability to maintain and add new features, tiers in isolation, deploy and scale the monolithic become increasingly difficult. Microservices address the problems by breaking apart the monolithic into a number of small or loosely coupled microservices. Typically, a microservice models a single distinct business function that when combined together with other microservices provides a complete business application as exposed by the user interface. 

Communication between microservices is often performed using APIs where each microservice exposes its functionality as a well defined interface. Communication is often free to happen between any two microservices, as required by the overall system to work. Each individual microservice can be developed independently of each and every other microservice allowing for polyglot style development and allowing scaling per microservice. Finally, each microservice can be paired with its own flavor of database which is best suited to the microservices specific needs.

 For example, pairing a microservice with a sequel database versus a no sequel database versus a graph based database. The following website documents additional attributes associated with both the monolithic and microservice based architectures and is highly recommended rating. In particular, take a look at the links presented here. For each style of architecture, the website provides patterned information on context, problem, forces, solution, example, related patterns and known uses. Going forward, as we begin demonstrating our Dotnet monolithic to microservices migration, we will adopt some of the components within our Store2018 application as documented and seen within the microservices pattern.

Okay, that completes this introduction of both monolithic and microservice based architectures. Go ahead and close it and we'll see you shortly in the first of several hands on demonstrations. We will walk you through a complete monolithic to microservices migration of a Dotnet C# based e-commerce store.