1

Introduction to Microservices

In this chapter, you will be introduced to microservices and the motivation behind them. You will understand the key benefits and common issues of the microservice architecture model and learn when to use it, as well as learning about some microservice development best practices. This knowledge will help you establish a solid foundation for reading the next chapters and give you some ideas on what challenges you may face with microservices in the future.

In this chapter, we will cover the following topics:

• What is a microservice?
• Motivation to use microservices
• Pros and cons of microservices
• When to use microservice architecture
• The role of Go in microservice development

Your purchase includes a free PDF copy + exclusive extras

Your purchase includes a DRM-free PDF copy of this book, 7-day trial to the Packt+ library (no credit card required), and additional exclusive extras. See the Free benefits with your book section in the Preface to unlock them instantly and maximize your learning.

What is a microservice?

Companies worldwide have used the microservice architecture model so widely that it has almost become a default way of software development. There are many companies having tens, hundreds, and even thousands of microservices at their disposal.

So, what exactly is the microservice model?

The microservice architecture model is organizing an application as a collection of services, called microservices, each of which is further responsible for a certain part of application logic, usually defined by a particular business capability.

As an example, consider an online marketplace application. The application may have multiple features, including search, a shopping cart, payments, order history, and much more. Each feature can be so different and complex on its own that it could be developed and maintained by a separate team - like search and payments in our example. In the microservice architecture model, each component would be an independent service playing its own role in the system.

Organizing each part of the application as a separate service is not necessarily a requirement. As with any architecture model or any aspect of software development, engineers need to be careful with choosing a particular approach or solution - doing an initial analysis and understanding the solution under the given conditions.

Before we proceed to the key benefits and downsides of microservices, let's see what challenges you could face when the application is not separated into multiple services.

Motivation to use microservices

In order to understand the motivation behind using the microservice architecture, it is very important to see the opposite approach - when the application is built and executed as a single program. Such applications are called monolithic applications or monoliths.

Monolithic architecture is, in most ways, the simplest model to implement since it does not involve splitting the application into multiple parts that need to coordinate with each other. This can provide you with major advantages in many cases, such as the following:

• Application logic is still loosely defined: It is very common that parts of the application or the entire system go through major structural or logical changes, especially at the very early stages of development. This might be caused by a sudden change of requirements, priorities, changes in the business model, or a different approach to development. In such cases, the ability to make quick changes to the application structure can be critical not only to the development process but also to the entire company.
• Narrow scope of the application: Certain applications can have a limited scope (for example, a photo upload service) or have their features integrated tightly (payment processing and invoice generation). Such applications might benefit from being monoliths: it is much easier to perform end-to-end testing and development without extra boundaries between the parts of the application.
• Performance constraints: There are types of applications (for example, trading systems) that can be very sensitive to the latency of each operation. Time-sensitive parts of such applications could benefit from monolithic architecture because there wouldn't be any API calls between the components.

In all of the preceding cases, monolithic architecture would be a better fit for the application. However, at some point, services get too big to remain monolithic. Developers start experiencing the following issues:

• Large application size and slow deployments: At a certain point, an application can become so big that it can take minutes or even hours to build, start, or deploy.
• Inability to deploy a particular part of the application independently: Not being able to replace a part of a large application can easily become a bottleneck, slowing down the development and release process.
• Higher blast radius: If there is a bug in a certain function or library widely used across the application code, it is going to affect all parts of the system at once, potentially causing major issues.
• Inability to scale components separately: If some part of a monolithic application requires more resources (CPU, RAM, or disk space), the entire application would need to be scaled - this could be very expensive.
• Vertical scalability bottleneck: The more logic the application has, the more resources it needs in order to run. At a certain point, it can get hard or impossible to scale the application up even further, given the possible limits on CPU and RAM.
• Interference: Certain parts of the application can perform heavy operations (for example, CPU-intensive data processing), reducing the performance of the rest of the system.
• Higher security risks: A possible security issue in the application may result in unauthorized access to all components at once.
• In addition to the possible issues we just described, different components may have different requirements, such as the following:
• Resources and hardware requirements: Certain components are more CPU-intensive or memory-intensive and may perform I/O operations at a higher rate. Separating such components may reduce the load on the entire system, increasing system availability and reducing latency.
• Deployment cadence: Some parts of the system mostly remain unchanged while others require multiple deployments per day.
• Deployment monitoring and automated testing: Certain components may require stricter checks and monitoring and can be subject to slower deployments due to multi-step rollouts.
• Technologies or programming languages: It is not uncommon that different parts of the system can be written in different programming languages or use fundamentally different technologies, libraries, and frameworks.
• Change management process: Some components may be subject to a stricter code review, deployment, or data management processes, as well as additional requirements.
• Security: Components may have different security requirements and may require additional isolation from the rest of the application for security reasons.
• Compliance: Some parts of the system may be subject to stricter compliance requirements. For example, handling personally identifiable information (PII) for users from a certain region can put stricter requirements on the entire system. Logical separation of such components helps to reduce the scope of work required to keep the system compliant.

With all the preceding issues described, we can see that, at a certain point, monolithic applications can become too big for a one-size-fits-all model. As the application grows, certain parts of it may start becoming independent and have different requirements, benefiting from a logical separation from the rest of the application.

In the next section, we are going to see how splitting the application into microservices can solve the aforementioned problems and which aspects of it you should be careful with.

Pros and cons of microservices

In order to understand how to get the best results from using microservices and which issues to be aware of, let's review the pros and cons of the microservice model.

Benefits of microservices

As previously described, different application components may have fundamentally different requirements and, at certain points, diverge so much that it would be beneficial to separate them. In this case, microservice architecture provides a clear solution by decoupling the parts of the system.

Microservices provide the following benefits to developers:

• Faster compilation and build time:...