With the increase in internet availability, there is an ongoing evolution in data communication techniques. The architectural improvements have been very innovative, scalable, and adoptable across environments. There was a need for software components to be available across the internet with a common interface for communication across different platforms and programming languages.

This led to the concept of creating services easily deployable with scalability, and exposing them over the internet.

Designing functionalities in terms of service was widely adopted; it was a great idea to provide features in the form of services to heterogeneous clients. This concept of using services led to SOA (Service-Oriented Architecture).

In this chapter, we will be looking at the following topics:

• Service in SOA
• Monolithic architecture
• Introduction to Microservices

A service is a piece of software which provides a functionality to other pieces of software within your system or outside the system.

The other pieces of software (clients) could be anything from a web application (website) to a mobile app (native or hybrid), or a desktop app, or even another service which uses another service in order to carry out a particular type of functionality.

In an e-commerce website context, when a user places an order, the web application communicates with the service to carry out the create, read, update, and delete (CRUD) operations on the database.

The communication between the software components (clients) and the service normally happens over a network with some kind of a communication protocol, for example, a mobile app communicating to a service via internet.

A system which uses a service or multiple services in this fashion, is known to have a Service-Oriented Architecture.

The main idea behind this architecture is that, instead of using modules within each client application, it lets us use a service(s) to provide functionality to them. This allows us to have many client applications using the same functionality.

SOA was successful, because of its following characteristics:

• It allows us to scale our software when the demand increases by enabling it to have a copy of the service on multiple servers, so when the traffic comes in, a load balancer redirects that request to a specific instance of the service, and we can have multiple instances of the service. Thus, when the demand increases, increasing the number of instances on the servers helps us scale it.
• SOA boasts of having standardized contracts or interfaces. When a client application calls the service, it calls the service by calling a method. The signature of that method normally doesn't change when the service changes, so we can upgrade our service without having to upgrade our clients as long as the contract and the interface do not change.
• Services are, in fact, stateless, so when a request comes in from a website to our service, that instance of the service does not have to remember the previous request from that specific customer. It, basically, has all the information from the request that it needs in order to retrieve all the data associated with the previous requests within the service, so, the service does not have to remember the previous calls a client has made to that particular instance of the service.

SOA gained popularity due to its implementation of services, which are accessible over standard internet protocols that are independent of OS platforms and programming languages.

Services from a developer POV are nothing but web services hosted on a web server, and which use SOAP (Simple Object Access Protocol) or JSON for communication. It's interesting to know that a web service can be used as a wrapper for legacy systems for making them network-enabled.

Some of the popular technologies implementing services (SOA) are as follows:

• Web services based on WSDL (Web Service Description Language) and SOAP
• Messaging, for example, with ActiveMQ, JMS, and RabbitMQ
• WCF (Microsoft's implementation of Web services)
• Apache Thrift
• SORCER
• RESTful HTTP

Service-Oriented Architecture started gaining momentum when the Monolithic architectural approach experience proved to be more painful than thought earlier. Let's briefly understand what Monolithic systems are and their drawbacks that led to adoption of SOA.

Monolithic architecture-based systems existed before the SOA or Microservices movement. These types of systems are exactly the opposite of what SOA tries to achieve.

A typical Monolithic system is an enterprise-based application, and this application might be in the form of a large website with all the working modules packaged in together into one single package, or it might be in the form of a service which talks to a website. It might be packaged as a large executable that is deployed on a machine.

In these systems, we added different components to an application to keep growing; there's no restriction in size, and there's no division. There's always one package which contains everything, and therefore, we end up with a large code base.

The high-level architecture diagram of a Monolithic system would look as follows:

In the long run, enterprises faced these shortcomings when they applied Monolithic architecture to their systems:

• Due to the code base being so large, it took the teams longer to develop a new functionality within the application.
• Deployment of a large system can also be challenging, because even for a small bug fix, we have to deploy a new version of the entire system, and therefore, that creates greater risk.
• It's one large code base, so, we're also stuck with one technology stack.
• It makes the overall system less competitive, because we can't easily adopt new technologies which might give us a competitive edge.
• Since the code is in one large package, we might also have high levels of coupling, which means that if a change is made in one part of the system, it might affect another part of the system, because the code is intertwined. This kind of coupling might be present between modules, and also between different services.
• Scaling up this service to meet the demand is quite inefficient. For example, if the Orders module of the system is in demand, we would have to create a copy of the whole package, of the whole service, in order to scale up just the Orders section.
• More powerful servers need to be bought to work efficiently for a large footprint of monolithic apps.
• Unit testing for such a large code base takes time, and regression testing by QA is also a time-consuming process.

An example of a Monolithic system could be an ASP.NET MVC site where the website itself is the UI layer, and then in the Business layer, you have business logic along with the data access layer. Over the years, if we continue with the same approach, then it will become a Monolithic system.

The Microservices architecture is, basically, service-oriented architecture done well. After years of working with Service-Oriented Architecture, software developers have realized what Service-Oriented Architecture should be like, and this is basically what Microservices architecture is--it's an evolution of the Service-Oriented Architecture.

Microservices are small, autonomous services that perform one function well while working with other services as well.

Microservices introduces a new set of additional design principles, which teach us how to size a service correctly. Previously, there was no guidance on how to size a service, and what to include in a service. The traditional Service-Oriented Architecture resulted in monolithic large services, and because of the size of the service, these services became inefficient to scale up.

Let's look into the advantages of using Microservices.

Microservices provide services which are more efficiently scalable, flexible, and which can provide high performance in the areas where performance is required.

An application which is based on the Microservices architecture is, normally, an application which is powered by multiple Microservices, and each one of these provide a set of functions, or a set of related functions, to a specific part of the application. A Microservices architecture normally provides a set of related functions to applications, to client applications, and client services.

Microservices architecture also uses a lightweight communication mechanism between clients and services or between two or more services. The communication mechanism has to be lightweight and quick, because when a Microservices-architected system carries out a transaction, it is a distributed transaction which is completed by multiple services. Therefore, the services need to communicate to each other in a quick and efficient way over the network.

The application interface for a Microservice, or the way we communicate to a Microservice, also needs to be technology agnostic. It means the service needs to use an open communication protocol so that it does not dictate the technology that the client application needs to use. And by using open communication protocols, for example, like HTTP REST (JSON based), we could easily have a .NET client application which talks to a Java-based Microservice.

Another key characteristic of a Microservice is that it is independently changeable. We can upgrade, enhance, or fix a specific Microservice without changing any of the clients or any of the other services within the system.

In the Microservices architecture, each microservice has its own data storage. By modifying one Microservice, we should then be able to deploy that change within the system independently without deploying anything else.

The preceding image depicts a high-level architecture diagram for a Microservices system. This is an example of a typical e-commerce system, and as you can see on the left-hand side, there's a shopping website running in the customer's browser, or it could be a mobile app using the API gateway.

The browser connects to the demo shopping website via the internet--the demo shopping website might be an ASP.NET MVC website running on IIS. All the processing required for all the interactions with the website is actually carried out by a number of Microservices which are running in the background.

Each Microservice has a single focus, or a single set of related functions, has its own data storage, and it's also independently changeable and deployable. So, for example, we could upgrade the Orders service without upgrading any other part of this system.

There might also be multiple instances for each type of Microservice. For example, if the Orders service is in demand, we might have several instances of the Orders service in order to satisfy the demand. And in order to direct a request from the shopping website to the correct instance of an order service, we have an API Gateway which manages and routes a request to the correct Microservice within the system.

So, in this example, when a customer places an order, the shopping website might use multiple services and multiple functions within those services in order to satisfy that transaction. And this is why, in the Microservices architecture, a transaction is normally a distributed transaction, because the transaction is actually satisfied by multiple pieces of software, that is, Microservices.

The following are the benefits of Microservices:

• Microservices architecture satisfies the need to respond to change quickly. The software market is really competitive nowadays. If your product can't provide a feature that's in demand, it will lose its market share very quickly.
• It fulfills the need for a business-domain-driven design. The architecture of an application needs to match the organization structure, or the structure of the business functions within the organization.
• The Microservices architecture makes use of automated test tools. We've already seen that in a Microservices architecture, transactions are distributed, and therefore, a transaction will be processed by several services before it's complete. The integration between those services needs to be tested, and testing these Microservices together manually might be quite a complex task. Automated test tools help us to perform this integration testing, reducing the manual burden.
• Cloud-compliant Microservices can reduce the burden of deployment and release management.
• The Microservices architecture provides a platform to adopt new technology. Because the systems are made of several moving parts, we can easily change one part, that is, a Microservice from one technology stack to another technology stack in order to get a competitive edge.
• By using asynchronous communication, the distributed transaction does not have to wait for individual services to complete their tasks before it's complete.
• Microservices have shorter development times. Because the system is split up into smaller moving parts, we can work on a moving part individually, can have teams working on different parts concurrently, and because Microservices are small in size and they have a single focus, the teams have less to worry about in terms of scope.
• The Microservices architecture also offers us increased uptime, because when it comes to upgrading the system, we will probably deploy one Microservice at a time without affecting the rest of the system.

The evolution of building services has seen many changes in the past decade with improvements in the internet bandwidth, machine processing power, better frameworks, and so on.

From a developer's point of view, Microservices are REST-based Web APIs either using ASP.NET, Java, PHP, or others. In the upcoming chapters, we will learn the various aspects of developing an ASP.NET Core-based Web API application.