Next, we will look at the key elements of a microservice architecture:
Ready to fail: Microservices are designed to fail. In a web application, microservices communicate with each other and if one of them fails, the rest should work to avoid a cascading failure. Basically, microservices attempt to avoid communicating synchronously using async calls, queues, systems based on actors, and streams instead. This topic will be discussed in the subsequent chapters.
Unix philosophy: Microservices should follow the Unix philosophy. Each microservice must be designed to do one thing only, and should only be small and independent. This allows us as developers to adjust and deploy each microservice independently. The Unix philosophy emphasizes building simple, short, clear, modular, and extensible code that can be easily maintained and repurposed by developers as well, in addition to its creators.
Communication layer: Each microservice communicates with the others through HTTP requests and messages, executing the business logic, querying the database, exchanging messages with the required systems and, at the end, returning a JSON (or HTML/XML) response.
Scalability: The main reason to choose a microservice architecture is that it is possible to scale the application easily. The bigger an application is and the more traffic the application has, the more sense the proper selection of choosing microservices makes. A microservice can scale the required part without any impact on the rest of the application.
The best way to understand how important microservices are in real life is knowing some platforms that decided to evolve and use microservices thinking about the future and making the maintenance and scalability easier, faster, and more effective:
Netflix: The number one application for online video streaming turned its architecture into microservices a few years ago. There is a story about the reason they decided to use microservices. Making changes on a review module, a developer forgot to put the
;at the end of the line and Netflix was down for many hours. The platform gets around 30% of the total traffic from the USA every day, so Netflix has to offer a stable service to its customers who pay every month. To get this, Netflix makes five requests to its different servers for each request that we make and it can get requests from 800 different devices using its streaming video API.eBay: In 2007, eBay decided to change its architecture to microservices; it used a monolithic application on C++ and Perl, later they moved to services built on Java, and finally they implemented their architecture using microservices. Its main application has many services and each one executes its own logic to be used by the customers in each area.
Uber: Microservices allowed this company to grow quickly because it allowed it to use different languages (Node.js, Go, Scala, Java, or Python) for each microservice and the process of hiring engineers was easier because they were not limited by the language code.
Amazon: Maybe Amazon is not the king of Internet traffic, but it moved to microservices a few years ago, being one of the first ones to use live microservices. The engineers said that it was not possible to provide all the services they offer, such as the web service, using the old monolithic application.
Spotify: The need to be faster than its opponent was a must for Spotify. The main engineer, Niklas Gustavsson, said that being fast, automating everything, and having smaller teams of development is really important for the application. This is the reason Spotify uses microservices.
Next, we will look at the disadvantages of the microservices architecture. When asking developers about this, they agree that the major problem with microservices is the debugging on the production server.
Debugging an application based on microservices can be a little tedious when you have hundreds of microservices in your application and you have to find where a problem is; you need to spend time looking for the microservice that is giving you the error. Each microservice works like an individual machine, so to look at a specific log you have to go to the specific microservice. Fortunately, there are some tools to help us out with this subject by getting the logs from all the different microservices in your application and putting them together into a single location. In the subsequent chapters, we will look at these kinds of tools.
Another disadvantage is that it is necessary to maintain every single microservice as an entire server; in other words, every single microservice can have one or more databases, logs, different services, or library versions, and even the code can be in a different language, so if it is difficult to maintain a single server and doing it with hundreds will waste money and time.
Also, the communication between microservices is very important---they have to work like clocks, so communication is essential for the application. To do this, the communication between the development teams will be necessary to tell each other what they need and also to write good documentation for each microservice.
A good practice to work with microservices is having everything automatized or at least everything possible. Maybe the most important part is the deployment. If it is necessary to deploy hundreds of microservices, it can be difficult. So, the best way is to automatize these kinds of tasks. We will look at how to do this in the subsequent chapters.