Store2008 Monolithic Application Architecture Review
Start course
2h 10m

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:

  • Learn the principles and patterns associated with microservices
  • Understand the principles and patterns associated with Restful APIs
  • Learn important requirements to consider when migrating a monolithic application into a microservices architecture
  • Master 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 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


  • 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 CI/CD implementation
  • Anyone interested in understanding and adopting Microservices and Restful APIs within their own organization
  • Anyone interested in modernizing an existing application
  • Anyone interested in Docker, and Containers in general
  • Anyone interested in container orchestration runtimes such as Kubernetes

Source Code


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
Learning Paths

Jeremy is a Content Lead Architect and DevOps SME here at Cloud Academy where he specializes in developing DevOps technical training documentation.

He has a strong background in software engineering, and has been coding with various languages, frameworks, and systems for the past 25+ years. In recent times, Jeremy has been focused on DevOps, Cloud (AWS, Azure, GCP), Security, Kubernetes, and Machine Learning.

Jeremy holds professional certifications for AWS, Azure, GCP, Terraform, Kubernetes (CKA, CKAD, CKS).