The course is part of this learning path
Store2008 Review - Overview of the .Net Monolithic Code
Store2018 - Refactor and Redesign
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
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
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
- Welcome back! In this lecture, we're gonna take a closer look at the source code that makes up our Monolithic application for our e-commerce store. Recalling that in the previous lecture, we explained how we were building an ASP.Net MVC styled application using the .Net Framework. Before we jump into our development environment, let's quickly remind ourselves of the key points of our Monolithic application. So again, on the front end, we're going to display a number of products. These products come from the inventory service. We're also going to display the shopping cart, which represents the items the consumer has chosen. This data comes from the shopping service component. And finally, we have the consumer. This piece of data comes from the Account Service. Okay, let's now jump over into our development work station. For that, I'm running a Windows 2016 server, cloud hosted on AWS.
So, I'm going to connect. And, I'm now on my Windows 2016 box. So, next thing we need to do is get a copy of the source code for our 2008 Monolithic application. So, searching for "github cloud academy". I then navigate to the devops repository. And, in this, we want a copy of this folder. So, I'll clone the whole repository, taking a copy of this. Okay, I'm now gonna do a git clone of this, so I'm gonna jump into C: drive Projects, do a direct relisting, okay that's empty, so now I'm gonna clone the URL. Okay, that's gotta copy of it locally. So next, I'm going to fire up Visual Studio. In this case, I'm running Visual Studio 2017. But for all intents and purposes, this would be Visual Studio 2008, running on Windows 2008 R2 as it was 10 years ago. So, let's now open up the project solution. So we'll navigate into C Projects, devops, the Monolithic Migration folder, 2008, and we'll open up the solution. And here we can see the basic structure of our 2008 Monolithic e-commerce store application. So there are 4 projects in total. There are the 3 service projects. We've got an Account Service, Inventory Service, and Shopping Service.
These are C Sharp projects. And, if we take a look at the properties on each of these, we can see the assembly name as Account Service, and that the Target Framework is 4.6. We mentioned that we were gonna be building with the framework 4.5, but because I'm running on Windows 2016, it comes preloaded with 4.6. But again, that shouldn't matter to us in terms of explaining a Monolithic setup. Now the key point here again about our Monolithic architecture, is that our presentation UI has references directly to our business services. So we've got an Account Service, Inventory Service, and Shopping Service. And these are imported into our presentation layer. So we've got the Inventory Service, Account Service and Shopping Service. So, we have this direct coupling between the projects, and that allows the presentation UI to make use of our business services, and nothing else outside of this can make use of those services.
So, taking a closer look at the Account Service, if we drill into the AccountSVC.C Sharp file. What are we doing in here? Well, this particular class represents the data specific to the consumers of the application. So, any consumer who logs into our e-commerce store would end up making database calls via this class. Now, for this demonstration we've stubbed out the back-end sequel calls. So we're not actually using a database, we're actually hard-coding the data, which is okay, it still allows us to to get our point across as to how a Monolithic architecture would be set up.
So, for the account service, we have a get method, and that get method is returning a set of consumers, or in this case, a list of consumers. So we have 4 hard-coded consumers. First one is Jeremy Cook, second one is Bob Smith, third one is John Doe, fourth one is Mary Doe. We also expose a get consumer by ID method, which takes an ID parameter. This would end up being a sequel read, or sequel query on the database with a where clause on the ID. In this case, we just hard-code a value, or a consumer, and we set the ID to be the passed on ID. We have a Save Consumer call, again, the stubs will represent a sequel write where we would do a sequel insert into our database.
In this case, we are passing in a consumer and setting up the response to be that consumer's first name, and surname and age. And, with an ID of 100. We also have an update consumer, and likewise a delete consumer. So overall, this Account Service class represents our CRUD: Create, Read, Update and Delete operations. Similarly, we have the same setup for Inventory Service, which represents the products we're selling on our front end. So if we drill into the class inventory SVC file, again, we've the same CRUD methods. We've got Get Products, which returns a list of product, and we've got a number of products. So if we look at our front end, these are the products. The next thing we'll do is we'll look at the shopping service.
This represents our shopping cart, and if we drill into the shopping SVC class, again we can see our CRUD Operations: Create, Read, Update and Delete. We have a GetCardIds, which returns a list of card IDs, or an array of card IDs I should say. We have a GetCart method, which takes a Cart ID, and then returns the shopping cart for that ID. If we take a closer look back on the front end, we will see these data attributes. So down on the bottom, we have three items in our shopping cart: laptop, iphone and jacket, which represents these individual products. Okay, the next thing we'll do is we'll take a closer look at the presentation layer component encapsulated in the Store 2008 ASP.net MVC Project. This project consists of our models, our view, and our controller.
So taking a look at the models, we have a single model called Commerce Model. And that has three properties, a user property, a list of products property, and a cart property. With getters and setters on each of these. So the user is the person who is logged in. The products are the products that are sold, and the cart represents the shopping cart, or the selected products that the user is likely to purchase. The controller sets up our commerce model by making a call to each of the individual services. So, we establish a user by calling Account Services, get consumer by ID, and passing in an ID.
We establish a list of products by calling InventoryServices.GetProducts, and we establish a cart, which represents the products in the shopping cart by calling ShoppingServices.GetCart, and a Cart ID. Finally, the commerce model is passed into the view, and the in the view is rendered, as seen by our homepage. So again, we have the products, we have the cart, and we have the consumer. And finally, before we deploy this, let's take a closer look at the view source code. So navigating into the views directory. If we expand the shared directory and look at layout, here we can see that this is the common layout structure, and that's using ASP.Net razor templates to do service side rendering, effectively.
So in here, we're passing in our commerce model. The UI is making use of bootstrap for the visual aspects of the html. And, we're simply rendering out, in this case, in the layout, the user's first name and the user's surname. Now, the layout is shared by other templates. So if we open up the index.cshtml razor template, we can see here that again we're passing in our commerce model, and that we're doing a couple of things. The first one is that we're here to writeover the Model.Products list. And for each product we render out a div element, and in the div element we put the product name, the product skew, and the product regular price.
Further down, we do the same thing again, but in this case we render out a table element where the rows represent each of the cart items found in the model. So that is, in essence, using razor as a service side templating solution to build the html for our e-commerce store. So jumping back to our commerce store, the output is this html, which represents each of those components as rendered by the razor templating system. Okay, let's now just do a quick build of this. So we'll do a clean solution, and then we'll call rebuild solution. So you can see here that we've done a rebuild on all projects and everything has succeeded. The next thing we will do is we'll package this.
So selecting the presentation component, if we right click and we go to publish. We can then select a number of options. In our case, we'll go with folder, and we'll browse to our releases directory, which is empty. And we'll publish to the file system for starters. Okay, so the packaging and publishing to the file system is completed. Now, let's take a look to see what's actually happened. And we're doing so again just to see from the point of a Monolithic application, what's being put into the releases directory. So, drilling into the bin folder, as expected, we've got each of our business services. So we've got out Account Service, our Inventory Service, and our Shopping Service along with our Presentation Service.
So again, this is symptomatic of how a deployment occurs for a Monolithic application. You effectively rebuild all components and redeploy all components. So this is a characteristic of a Monolithic application. Okay, the last thing we're gonna do is we'll do a deployment to the local IIS server. So if we bring up II Service, you'll see that we have a, under sites, a default website. Okay, going back to Visual Studio, we'll do new profile on the publish, and we'll target IIS. Then we'll click publish. And, here under server we'll type localhost.
We'll specify the default website as the location. Don't need to worry about username or password. Click the validate connection button. We got the green tick so we're all good to go. We'll go next. And the configuration we'll choose is release. We'll save and you can see here that we've done a rebuild and then a publish, and everything has succeeded. So going back to IIS, if we now do a refresh on the default website, you can see that we've deployed our application. So if we select the content view, navigate into bin, again we can see our assemblies.
And, final validation of this is us browsing to the website. Jumping into Chrome. We can see that indeed we have successfully built, published IIS, and that we're browsing. So we can see our e-commerce store for our Monolithic application. So that concludes this lecture. Go ahead, and close it, and in the next lecture, we'll begin our migration away from Monolithic to a Microservices architecture.
About the Author
Jeremy is the DevOps Content Lead at Cloud Academy where he specializes in developing technical training documentation for DevOps.
He has a strong background in software engineering, and has been coding with various languages, frameworks, and systems for the past 20+ years. In recent times, Jeremy has been focused on DevOps, Cloud, Security, and Machine Learning.
Jeremy holds professional certifications for both the AWS and GCP cloud platforms.