Section 1: The Basics of Microservices Architecture and NATS
This first section provides an understanding of what the microservices architecture is and the benefits of using it for application development. It also discusses different messaging technologies and how these technologies can be utilized to build microservices-based applications. Then, it introduces NATS messaging technology by covering the concepts with practical examples.
This section contains the following chapters:
- Chapter 1, Introduction to the Microservices Architecture
- Chapter 2, Why Is Messaging Important in Microservices Architecture?
- Chapter 3, What Is NATS Messaging?
Chapter 1: Introduction to the Microservice Architecture
The microservice architecture is an evolutionary approach to building effective, manageable, and scalable distributed systems. The overwhelming popularity of the internet and the smart digital devices that have outnumbered the world's population have made every human being a consumer of digital products and services. Business leaders had to re-evaluate their enterprise IT platforms to make sure that these platforms are ready for the consumer revolution due to the growth of their business. The so-called digital-native companies such as Google, Amazon, Netflix, and Uber (to name a few) started building their enterprise platforms to support this revolution. The microservice architecture evolved as a result of the work that was done at these organizations to build scalable, manageable, and available enterprise platforms.
When microservice-based platforms become larger and larger with hundreds or thousands of microservices inside them, these services need to communicate with each other using the point-to-point model before they become too complicated to manage. As a solution to this problem, centralized message broker-based solutions provided a less complex and manageable solution. Organizations that adopted the microservice architecture are still evaluating the best possible approach to solve the problem of communication among services. The so-called model of smart endpoints and dumb pipes also suggests using a message broker-based approach for this.
NATS is a messaging framework that acts as the always-on dial tone for distributed systems communication. It supports the traditional pub-sub messaging model, which is supported by most of the message brokers, as well as the request-response style communication model while supporting high message rates. It can be used as the messaging framework for the microservice architecture.
In this book, we will discuss the concepts surrounding the microservice architecture and how we can use the NATS messaging framework to build effective, manageable, and scalable distributed systems.
Distributed computing systems have evolved from the early days of mainframes and large servers, sitting in separate buildings, to serverless computing, where users do not even need to consider the fact that there is a server that is running their software component. It is a journey that continues even today and into the future. From the early scheduled jobs to simple programs written in Assembly to monolithic applications written in C, or from Java to ESB/SOA-based systems to microservices and serverless programs, the evolution continues.
IT professionals have been experimenting with different approaches to solve the complex problem of distributed computing so that it eventually produces the best experience for the consumers. The microservice architecture brings out several benefits to the distributed computing system's design and implementation, which was not feasible before. It became mainstream at a time where most of the surrounding technological advancements, such as containers, cloud computing, and messaging technologies, are also becoming popular. This cohesion of technologies made the microservice architecture even more appealing to solve complex distributed systems-related challenges.
In this chapter, we're going to cover the following main topics:
- The evolution of distributed systems
- What is a microservice architecture?
- Characteristics of the microservice architecture
- Breaking down a monolith into microservices
- Advantages of the microservice architecture
The evolution of distributed systems
The quality of the human mind to ask for more has been the driving force behind many innovations. In the early days of computing, a single mainframe computer executed a set of batch jobs to solve a certain mathematical problem at an academic institution. Then, large business corporations wanted to own these mainframe computers to execute certain tasks that would take a long time to complete if done by humans. With the advancements in electrical and electronics engineering, computers became smaller and instead of having one computer sequentially doing all the tasks, business owners wanted to execute multiple tasks in parallel by using multiple computers. The effects of improved technology on electronic circuits and their reduced size resulted in a reduction in costs, and more and more organizations started using computers.
Instead of getting things done through a single computer, people started using multiple computers to execute certain tasks, and these computers needed to connect to communicate and share the results of their executions to complete the overall task. This is where the term distributed systems came into use.
A distributed system is a collection of components (applications) located on different networked computers that communicate and coordinate their tasks by passing messages to one another via a network to achieve a common goal.
Distributing a workload (a task at hand) among several computers poses challenges that were not present before. Some of those challenges are as follows:
- Failure handling
- Concurrency
- Security of data
- Standardizing data
- Scalability
Let's discuss these challenges in detail so that the distributed systems that we will be designing in this book can overcome these challenges well.
Failure handling
Communication between two computers flows through a network. This can be a wired network or a wireless network. In either case, the possibility of a failure at any given time is inevitable, regardless of the advancements in the telecommunications industry. As a designer of distributed systems, we should vary the failures and take the necessary measures to handle these failures. A properly designed distributed system must be capable of the following:
- Detecting failures
- Masking failures
- Tolerating failures
- Recovery from failures
- Redundancy
We will discuss handling network and system failures using the preceding techniques in detail in the upcoming chapters.
Concurrency
When multiple computers are operating to complete a task, there can be situations where multiple computers are trying to access certain resources such as databases, file servers, and printers. But these resources may be limited in that they can only be accessed by one consumer (computer) at a given time. In such situations, distributed computer systems can fail and produce unexpected results. Hence, managing the concurrency in a distributed system is a key aspect of designing robust systems. We will be discussing techniques such as messaging (with NATS) that can be used to address this concurrency challenge in upcoming chapters.
Security of data
Distributed systems move data from one computer to another via a communication channel. These communication channels are sometimes vulnerable to various types of attacks by internal and external hackers. Hence, securing data transfers across the network is a key challenge in a distributed system. There are technologies such as Secure Socket Layer (SSL) that help improve the security of wire-level communication. It is not sufficient in a scenario where systems are exposing business data to external parties (for example, customers or partners). In such scenarios, applications should have security mechanisms to protect malicious users and systems from accessing valuable business data. Several techniques have evolved in the industry to protect application data.
Some of them are as follows:
- Firewalls and proxies to filter traffic: Security through network policies and traffic rules.
- Basic authentication with a username and password: Protect applications with credentials provided to users in the form of a username and password.
- Delegated authentication with 2-legged and...
