Microservices by Examples Using .NET Core: Using .NET Core

CHAPTER 1

An Introduction to Microservices

Microservices is a new buzzword and is getting more popular day-by-day. In this chapter, we will focus to understand microservices.

To better understand what Microservices is, it is an architectural style generally used to develop large software applications loosely coupled with bounded contexts. Loosely coupled means each service are modular, small, and Independent runs on its process, each service is independently manageable and deployable.

In this chapter, you will get the understanding of all the necessary terms required to understand microservices. We will cover the following:

Understanding Microservices Concepts

To know more about microservices, we should know what it is and the history behind it. The microservice architecture is a pattern to develop an application containing a set of smaller services. Microservices are independent of each other and run in their own processes. A significant advantage of these services is that, it can be developed and deployed independently on their own process. In other terms, we can say that microservices are a way to isolate our services so they can be handled entirely independent of each other in the context of designing, development, deployment, and upgrades.

Companies like Netflix, Amazon, and Spotify have a Microservices Architecture serving their resource and requests-intensive business services that, in the average case, have to scale at the scale.

What are Microservices

Let us understand what microservices mean; Microservices is an architecture pattern, offer a better way to build to decouple components within an application boundary. Microservice architecture is a style of designing software systems which divide significant software applications into many small services that can run independently. Each of the microservices has its own team working on it, so they are entirely separated from each other. This allows every service to run its own unique process and communicate autonomously without having to rely on other services or the application as a whole.

History of Microservices

Term microservices came in contact in mid of 2011.

The principle behind microservices is often just good architecture principles.

Microservices principles have been with us since decades; just the implementations are new. Understand the philosophy behind microservices, what microservices are, what they replaced. In the beginning of1980s with the introduction of the first significant systems distribution technology: Remote Procedure Calls (RPC). RPC was the concept behind Sun Microsystems’ initial ONC RPC as well as the basic idea behind DCE (1988) and CORBA (1991).

The microservices style of architecture develops complex application software from small, individual applications that communicate with each other using language-independent interfaces (APIs). Companies run into trouble if they are unable to scale monolithic architecture that has developed over time if their architecture is difficult to upgrade or maintenance becomes too complicated. Microservices can be the answer to this problem, as they break down complex tasks into smaller processes that work independently of each other.

In 2014, James Lewis and Martin Fowler came together and provided a few real-world examples and presented microservices (refer to: https://www.martinfowler. com/articles/microservices.html) in their own words and further detailed it as follows:

The term Microservice Architecture has been quite popular over the last few years to explain an appropriate way of designing software applications as components of autonomously deployable services. While there is no precise definition of this architectural style, there are particular common characteristics around organization around business capability, automated deployment, intelligence in the endpoints, and decentralized control of languages, and data.

The world is moving towards the next generation of HTTP, forging strategies to create small, cross-platform containers that host independent microservices. It is very essential to know all aspect Lewis and Fowler defined above.

Microservices are Modular and Independent

When we say, Microservices have loosely coupled; it means each service is small and designed to solve specific business function. Microservices are broken down into multiple service components by design, which can be developed by a small development team so that each of the services can be developed and deployed independently without compromising the integrity of the application. In a microservice architecture-based approach, each microservice owns its process and data so that it will be independent of a development and deployment point of view. Typically, a tiered approach is taken with a back-end store, middle-tier business logic, and a front-end user interface (UI). Microservice has evolved over the past couple of years to build distributed applications that are for the cloud. Any programming language can write it and use any framework.

Microservices are Decentralized and Cross-functional

The ideal organization for microservices has small, engaged team where each team is in charge of a business function made out of various microservices which can be independently deployed. Teams handle all parts of development for their microservices, from development to deployment, and hence all level of team members required to deliver Microservices from developers, quality engineers, DevOps team and Product architects. This organization design is consistent with Conway’s law, which says that the interface structure of a software system will reflect the social fabric of the organization that produced it. The code is organized around business capabilities.

Microservices are Resilience

Application developed as microservices are better for fault isolation, if one service fails, others will continue to work. This is one of the benefits of building distributed systems like microservices, that is the ability of the system to resist faultsTand unexpected failures of elements, networks, computer resources, etc. These systems are resilient even within the face of errors. The concept behind this resiliency looks simple: if our Monolithic application fails, everything that it’s accountable fails at the side of it; therefore let’s break things into smaller modules so we can withstand individual pieces of our app failing without affecting the entire system. Dealing with fault isolation in a distribution system is not very straightforward; that is the main reason microservices needs orchestrator for high availability. It is essential to choose a better cloud computing infrastructure for microservices to orchestrate microservices because the various parts of the application are segregated. A problem could happen in one section without affecting other areas of the application.

Microservices are Highly Scalable

In the previous section we read about several benefits of adopting Microservices, Scalability is the utmost importance of any distributed system and Microservices are designed for scaling. Scaling permits applications to react to variable load by increasing and decreasing the number of instances of roles, queues, and alternative services they use. It is easy to quantify the efficiency of a monolithic application but evaluating and quantifying the ability of a broad ecosystem of Microservices are quite tricky because Microservices are partitioned into thousands of small services. When it comes with the scalability of any system, it can be scale-in or scale out. We will learn about Scalability (both scale-in and scale-out) in Microservices with examples in the next chapter.

Discussing Monolithic and History Behind it

In monolithic software, we mainly built as a single unit. The monolithic software is designed to be self-contained; components of the program are interconnected and interdependent rather than loosely coupled as is the case with modular software programs. In a tightly-coupled architecture, each component and its associated components must be present in order for the code to be executed or compiled.

The monolithic architectural style is a traditional architecture type and has been widely used in the IT business. The term monolithic is not new and has come from the UNIX world. In UNIX, most of the commands exist as a standalone program whose functionality is not dependent on any other program.

Enterprise applications are built in 3 layers: A data access layer, Business layer / Service layer and UI/Presentation layer. It is a single layered software application in which the presentation layer and data access layer are consolidated into a single program on a single platform.

In a traditional web application, client (a browser) posts a request. The business tier executes the business logic, the database collects/stores application-specific persistence data, and the UI shows the data to the user.

A monolithic app which is designed without modularity, each layer is tightly coupled. If the changes are required in one business function, entire application needs to be rebuilt and deployed. The major problem with this design is it’s not designed for scalability and fault tolerance. If an exception occurs in one module, then the entire system will fail to function. Technical debt from a monolithic code base is a measurable reality in traditional DevOps. With monolithic code, even isolated components receive the same memory, as well as sharing access to the program itself. While that may present it a little easier to code interfaces and execute applications, it ultimately takes away the adaptability that should be a part of the agile development process.

Deploying such a monolithic application will become another hurdle. During deployment, you will have to make sure that each and every component is deployed accurately; otherwise, you may end up facing a lot of problems in your production environments.

Demo Application – Monolithic Web App

Let’s imagine that you are building an app of an online hotel booking application. The application takes request from the user, search for a room and book it. The application is deployed as a single monolithic application in IIS server.

Now the requirement got changed to validate an identity of a user before booking the room, in this scenario to make the necessary changes in Booking module, we need to make the entire system down and do a proper impact analysis of dependent modules. This is not scalable as well, though we know most of our user come to our website, search for a room on a vacation season and the load on Room search module are very high still we cannot scale a particular module using monolithic architecture. We will read more on how easy to adopt this type of changes in microservices architecture in upcoming chapters.

Use-Case of Our Demo Application

Online hotel booking application is taken as an example to make you understand Microservices architecture in this book. Using the same application we will learn the challenges of the Monolithic application, then how SOA made it better and Microservices made it most accessible.

This is an online hotel booking system where a user can search a hotel in a given city with the different category of rooms, check the hotel availability, Price, facilities and Book it.

Requirements

Main modules are as follows:

Pre-requisite

To build above demo Online Hotel Booking Web Application using monolithic architecture we need Visual studio With ASP.NET, C#, and SQL.

Overview of the Architecture of Our Demo Application

Presentation Layer (UI): UI layer has all client-side components, and validations, e.g., Username not blank and must be a valid email.

Business Logic Layer: BL layer contains all the business functionalities in a single assembly, e.g., Rom inventory, Facilities, Booking, and so on.

Data Access Layer: DL layer has all the backend related functionalities, e.g., all the CRUD operations, maintaining Booking transactions, and so on.

In this section, we have discussed our monolithic demo application. In the following sections, we will discuss what the challenges this application can face:

Challenges in Monolithic Application

There are a lot of challenges to make a simple change because all the components are tightly coupled, though they are separated into 3 different layers of extensibility and maintainability point of view, it is quite tricky. Let’s take a use case to see the real world challenges we can face on Monolithic.

Now we need to add a functionality to extend the requirement further to build a mobile app for our online Hotel Booking system. The pain is, we need to redevelop each and every module again because we can’t offer a single business logic layer as it is tightly coupled with Data access layer and UI layer.

Scalability: A monolithic architecture is the one which can only scale in one dimension. It can scale with an increasing transaction volume by running more instances of the application. Some clouds can automatically create the number of instances dynamically based on load elastically . This architecture can’t scale with a growing data volume. Each instance of application will access all of the data, which makes caching less effective and increases the memory consumption and I/O traffic. Also, different application components have different resource requirements - one might be time intensive while another might be memory intensive. With a monolithic architecture, we cannot scale each component independently. In order to scale the application, we just need to create more instances of that component. It is quite impossible to scale the components separately.

Spiraling development time: A monolithic application is also an obstruction to scaling development. Once the application gets to a specific size, it’s useful to divide up the engineering unit into teams that focus on specific operative areas. For example, we might want to have the UI team, backend team, testing team, and so on. The challenge with a monolithic application is that it prevents the teams from working independently. The teams must regulate their development efforts and redeployments. It is quite difficult for a team to make any change and update application which is in the production environment.

A monolithic architecture forces you to be master to the particular technology stack (and in some cases, to a specific version of that technology) you chose at the start of development. If your application uses a platform framework that consequently becomes obsolete, then it can be stimulating to migrate the application to a newer and better framework incrementally. It’s possible that, in order to adopt a newer platform framework you have to rewrite the entire application, which is definitely risky.

Codebase complexity: This result in a higher chance of code-breaking due to the fix requirement in other modules or services. Over time the monolith grows larger as business needs change and as new functionality is added. It becomes increasingly difficult to keep an excellent modular structure, making it harder to keep changes that ought to only affect one module within that module. Even a small change to the application requires that the entire monolith is rebuilt and deployed.

Discussing SOA

In the previous section, we discussed the monolithic architecture and its limitations. We also addressed why it does not meet into our enterprise application requirements. To defeat these issues, we should take a modular method where we can separate the components.

Service-Oriented Architecture (SOA) is basically the group of services. Service-Oriented Architecture describes a set of principles and patterns for designing and developing software in the form of interoperable services. It is an architecture pattern where services are the logical representation of a repeatable business activity that has a specific business outcome. These services interact with each other. These services are generally business functionalities that are built as software components. The communication can comprise either simple data passing, or it could connect two or more services regulating some activity. SOA architecture presents a connection between the implementations and the consuming applications, creating a logical view of sets of services which are ready for the use, invoked by a standard interface and management architecture.

Understanding Service in Service-oriented Architecture

To make SOA more effective, we need a clear understanding of the term Service. Service, in this case, is an essential conception of SOA. It can be a part of the code, program, or software that gives functionality to other systems. This piece of code can communicate directly with the database or indirectly through different service. Moreover, it can be used by clients directly, where the client may be a website, a windows app, mobile app, or any other device app.

Services are what you connect together using Web Services. Service is the endpoint of a connection. Also, service has some type of underlying computer system that supports the connection offered. This section provides information on the specification of services. Typically, services interact with other systems via some communication channel, generally the HTTP protocol.

Service is a logical design of a repeatable business activity that has a specified outcome (e.g., Booking Service, Provide Hotel information, reports). A service is self-contained and may be composed of other services. It has three components: an interface, a contract, and implementation. The interface defines how a service provider will fulfill requests from a service consumer, the contract outlines how the service provider and the service consumer should communicate, and the implementation is the actual service code itself. Because the interface of service is separate from its implementation, a service provider can execute a request without the service consumer knowing how it does so; the service consumer only worries about consuming services.

SOA - Architectural Principles

As a Service Oriented Architecture, it adheres to few principles, in this section; we will discuss SOA Architectural Principles.

Discussing SOA Based Demo Application

Let’s take the same online Hotel booking application as a demo and see how it works in SOA architecture.

The main advantages of SOA based architecture are, it is 3 layer and 3-tier application, and each layer/tier can be deployed in the different server for better scalability.

Presentation Layer / UI: UI layer is same like monolithic architecture but not tightly coupled with middle layer / service layer.

Service layer: Middleware can be hosted as an independent layer and can be consumed by any other client. Service layer exposes proxy or