During the development of any production-grade application based upon microservices architecture, the services might depend a lot upon the availability of the other services deployed in production. For example, a service providing functionality to the administration panel for the application might require the availability of the user authentication service to allow for administrator logins and privilege management. In case the user management service goes down, there can be severe consequences in the stability of the operations provided by the application.

To guarantee these kinds of requirements, we need to have SLAs that act as contracts between the teams delivering particular microservices. These contracts provide guarantees about the different aspects of the microservices, and cover a lot of different parts. Let's take a look at the kind of things that are covered by the SLAs, as shown in the following list:

• Uptime guarantees: If there are two services, say Service A and Service B, where Service A depends upon the functionality provided by Service B, then Service A might require an uptime guarantee from Service B. The SLAs may specify this uptime guarantee in the form of the redundant deployment of Service B so as to provide higher uptime and failure resilience. It may also specify the functionality related to alert generation in case the service goes down.
• API stability: Most of the microservices communicate through the API endpoints that are exposed through them. If these API endpoints keep changing in every other release of a particular service, then this may cause the developers of other services increased headache because of the fact that they need to keep altering their services so as to accommodate the changing endpoints of one service. SLAs provide the contract between services regarding the lifetime of the API endpoints, how frequently these API endpoints might change, and so on.
• Rate limiting: Practically, no microservice can scale infinitely. Most of the time, these services can handle only a certain number of transactions that are dependent upon the availability of the infrastructure resources on which the service is deployed. The SLAs specify the rate-limiting policies of the service. This explains at what point a particular service might start limiting the number of requests it will process from another service.
• Error rate guarantees: A service that has a high error rate might be good for nothing because most of the transactions that are being processed by the service end up in an error state. A SLA specifies the error rate guarantee, which, if breached, may flag the service as malfunctioning.

These are just a few parameters that can be covered by a SLA. These SLAs provide a kind of guarantee that the services operating in a given environment adhere to a certain set of standards, and they also lay out the information required to monitor the performance and stability of a given service.

Now that we have all the basic knowledge that is required to understand how microservices work, it's time for us to see some microservices in action.