Although we discussed different aspects, what we have made is a RESTful web service for a simple blog in this book. We took that example to keep things simple in terms of business logic so that we can focus on our actual subject in detail. This was helpful, but in the real world, things are not that simple and small. There are big systems with different parts, which are difficult to maintain. These parts are also difficult to debug and scale. Scaling is different from just maintaining something and optimizing it for better performance. In scaling, optimization of both code and deployment environment matter. Scalability, maintainability, and performance have always been challenges that we have faced.
To handle this, we have an architectural style, known as microservices. So, in this chapter, we will discuss this. Microservices are not an essential thing to use. However, they solve some challenges that we often face while making RESTful web services for bigger systems...
Introducing Microservices
Let's first define architecture and then go into the details of microservices. Microservices architecture became a hot term, but there wasn't any formal definition. In fact, to date, there is no official consensus regarding its properties or definition. However, different people have tried to define it. I found a definition on Martin Fowler's blog very convincing. He and James Lewis defined it this way:
The microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable by fully automated deployment machinery. There is a bare minimum of centralized management of these services, which may be written in different programming languages and use different data storage technologies. -- James Lewis and Martin Fowler
It seems very formal...
Motivation towards microservices
There are several motivations towards microservices. However, the one that I want to start with is when we are dividing it into components having single responsibilities, we are abiding by the SRP (Single Responsibility Principle). Single responsibility is actually one of the first five Object Oriented Principles, also known as SOLID (https://en.wikipedia.org/wiki/SOLID_(object-oriented_design) ). This single principle, even if it is at architectural level or low level, it makes things simple and easy. Here, in the case of microservices, separates components from each other. So, the reason for modifying a component will be related to one single functionality. Other components and functionalities of the system will work as they were working before. This is how being separated and being independent as microservices makes them easier to modify without affecting others.
Here are some of the other reasons why it is necessary to separate microservices.
How it is different from SOA
SOA stands for Service Oriented Architecture. By name it seems that this architecture depends on services just like micro-services. Service Orientation is a design paradigm in computer in the form of services. Its principles stress the separation of concerns (the same as SRP). Until now, it seems similar to microservices. Before understanding difference, we need to know that what is SOA. Although there is no one clear official definition of SOA. So let's take this basic definition from wikipedia:
A service-oriented architecture (SOA) is a style of software design where services are provided to the other components by application components, through a communication protocol over a network. The basic principles of service-oriented architecture are independent of vendors, products and technologies.
If you look at this definition then you will find that SOA is very similar to micro-services but its definition is not that concise and clear. One reason can be that SOA...
As per Conway's law:
"Organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations."
So, in order to produce designs based on architecture and to gain its benefits, we also need structured teams working on this accordingly.
Normally, in a monolithic application, we have teams such as the following ones:
- Dev-ops team
- Backend-developer team
- DB administrator team
- Mobile application developer team
However, in the case of distributed architecture such as microservices (if we are developing an e-commerce application), we will have teams such as the following ones:
- Products catalog
- Inventory
- Orders
- Coupons
- Wishlist
All these teams will have members, including Dev-ops, Backend-developer, DB administrator, and mobile app developer. So, in the case of microservices, we will have a team per service.
Size of team:
There is no hard and fast rule, but it is recommended that team size should be as per Jeff Bezos' 2 pizza...
Challenges of micro-services
Nothing comes free. Everything has its downside or at least some challenges that need to deal with. If we go for microservices, it has its own challenges. So, let's look at them and discuss how they can be minimized if there is trade-off.
Infrastructure maintenance
Although you don't have to update your infrastructure every day, it still needs to be maintained and it needs more effort. Technology freedom comes with microservices, but without any cost. You have to maintain different server instances using different technologies. This will need better infrastructure and people with experience of more technologies.
Actually, you don't always need better infrastructure and people with knowledge of all those different technologies. Normally, every team working on different services will have its own infrastructure or Dev-ops-related people. However, in that case, you need more people because now, you are not sharing Dev-ops or infrastructure-related people across different...
As this chapter is just an introduction to microservices, we will not go the details of implementation. However, we will just have an overview of how we will implement different things in microservices. We have already discussed RESTful web service implementation in this book. However, here are some other pieces that come with microservices. So, we will just get idea of what is involved in implementing these parts.
We will have deployments automated. We will continuous delivery tools. Continuous delivery is a process in which there are frequent deliveries with short cycles, and it ensures that software can be released at any time. It aims to release software faster and minimize risk with a build, and test and release software frequently approach.
Continuous delivery takes automation from source control all the way through production. There are various tools or processes that help in accomplishing a continuous delivery process. However, two important things in this...
In this chapter, as the last chapter of this book, I tried to introduce microservices, an architecture style getting a lot of attention nowadays. We looked into it because we needed an architecture in which we can use RESTful web services to achieve better performance and scalability in complex and bigger systems.
The focus of the book was RESTful web services in PHP7, and we looked at other topics that were connected with building RESTful web services or PHP7 in someway. We looked at some of these topics in detail, whereas we just touched upon some others. Many of these topics are too broad to be contained in one chapter. Some of these topics can have a complete book dedicated to them. That's why, I provided different URLs towards learning material or suggested reading, which you can refer to if you are interested.
There are two important things:
Practice:
Actual learning starts when you start practicing something. When you practice, you sometimes face problems and learn...
