Course Summary

Description

In this advanced course we take a legacy monolithic .Net application and re-architect it to use a combination of cloud services to increase, scalability, performance and manageability.

Learning Objectives This course will enable you to:

Understand the principles and patterns associated with microservices

Understand the principles and patterns associated with Restful APIs

Understand important requirements to consider when migrating a monolithic application into a microservices architecture

Understand the benefits of using microservices and associated software patterns and tools to build microservice based applications at speed and scale

Understand tradeoffs between different architectural approaches

Become familiar and comfortable with modern open source technologies such as Dotnet Core, Docker, Docker Compose, Linux, Terraform, Swagger, React

Become familiar with Docker and Container orchestration runtimes to host and run containers, such as Docker Compose, Amazon ECS using Fargate, and Amazon EKS

Prerequisites

A basic understanding of software development

A basic understanding of the software development life cycle

A basic understanding of Devops and CICD practices

Familiarity with Dotnet and C#

Familiarity with AWS

Intended audience

Software Developers and Architects

DevOps Practitioners interested in CICD implementation

Anyone interested in understanding and adopting Microservices and Restful APIs within their own organisation

Anyone interested in modernising an existing application

Anyone interested in Docker, and Containers in general

Anyone interested in container orchestration runtimes such as Kubernetes

Transcript

Welcome back in this lecture we're going to present to you a monolithic designed e-commerce store. This represents an architecture that would have been used perhaps 10 years ago. It's gonna use ASP.Net MVC and the .Net Framework 4.5. So our e-commerce store is going to have a number of components, or a number of data sets, that are going to be rendered to the front end. The first main one, the products that the e-commerce store sells, so we have a number of products here. The second component and data set that we render to the front end is the shopping cart.

So this represents the items or products that the user has selected and put in their shopping cart. And finally we have the consumer who is the logged on user who is making these purchases. So the key point here is to present a monolithic architecture as it would have been used back in 2008. So what do we mean by monolithic? Well in our example, the architecture that we're gonna use is monolithic based on the fact that we have several components, we have the account service, inventory service, and shopping service components which make up the business logic and back end for our architecture. And then we have our Store2008 user interface component which makes up our presentation logic.

Now all of these components end up being packaged together and deployed together and that, in essence, is what a monolithic architecture is. And so in this design, in this monolithic design, the only component that can actually make use of the business logic components is the presentation logic component. The account service, inventory service, and shopping service components lose the ability to be used elsewhere in your architecture. So let's now jump over into a diagram that represents what the deployment would have looked like for a monolithic architecture 10 years ago.

So as we can see, you would have typically had a load balancer of some sort and a number of IIS web servers running behind it and then each of those web servers has an ability to make SQL server database connections to read and write data into the database. So the monolithic architecture would have been deployed in its entirety to each of those web servers running behind the load balancer.

So each and every web server has an identical copy of all of the components. And finally, if we take a look at a diagram that represents the calling for a monolithic architecture how would that work? So for the previous deployment you would have had a browser that makes HTTPS calls to a load balancer. The load balancer would have then load balanced those calls across a number of IIS web servers in this case back in 2008, we likely would have been running IIS 7.5 on a Windows server 2008 set up.

The deployment of the monolithic set up would have been made up of 4 dlls, one for each of the components. So our store2008 user interface would have been its own assembly, .net assembly, as would of each of the individual services. So the monolithic design here is deployed in an identical manner to each and every web server sitting behind the load balancer. And one of the other key points in terms of how the calling is made between the components is that the presentation UI is actually making in-memory calls to each of the service components.

So all of these components together are effectively running in a single process within IIS. Again, a key constraint of a monolithic architecture is that you lose the ability to expose services to a wider range of other services. In our example here, the account service, inventory service, and shopping service can only be called currently by the Store2008 user interface component. Okay that concludes this lecture. In the next lecture, we'll actually jump into the code base for this monolithic architecture. So go ahead and close this lecture and we'll see you shortly in the next one.

About the Author

Jeremy is a Cloud Researcher and Trainer at Cloud Academy where he specializes in developing technical training documentation for security, AI, and machine learning for both AWS and GCP cloud platforms.

He has a strong background in development and coding, and has been hacking with various languages, frameworks, and systems for the past 20+ years.

In recent times, Jeremy has been focused on Cloud, Security, AI, Machine Learning, DevOps, Infrastructure as Code, and CICD.

Jeremy holds professional certifications for both AWS and GCP platforms.