There are several different microservices design principles available. Different terms are likely to be used in different places. In this book, we will refer to the microservices design principles as follows:

• High cohesion among services: A microservice should have one single focus and the sole responsibility for that action. It should not change as a result of other related services. Services should be easily rewritable so that we can achieve scalability, reliability, and flexibility. It should handle a single business function and domain-specific functionality.
• Autonomous service: A service should independently handle its work without the help of any other services. It should not be tightly integrated with any other service; it should remain loosely coupled in nature. By autonomous, we mean that a microservice should not change because of the external components with which it interacts. Autonomous services honor contracts and interfaces. They should be stateless, independently changeable, independently deployable, backwards compatible, and they should support concurrent development.
• Business domain-centric service: Each individual service should perform or represent a single business function. This could be a calculation of sales, tax, income tax, or any other function related to a specific area. Each service should bound or define its scope. Business-centric code can help to provide more cohesion and make services more responsive to handle any changes in the domain or business logic requirements.
• Resilience: Resilience is a standard these days when providing a service to a customer. Failure to provide resilience may result in another endpoint not providing a response to your microservices. Designing your service in micro-format helps to overcome failure. Our service should register itself during startup and de-register itself upon failure. This should be part of a dynamic discovery service, such as the auto-creation of a queue or the auto-removal of the queue in a message queue. There could be a number of problems or exceptions that a network-based service could encounter. It should be able to handle delays and the unavailability of another service.

• Observable service or functionality: Observability is another important design principle while working on distributed microservices. When a complex interconnected service breaks, it can take hours or days to isolate issues. We should design our services in such a way that we can check the health of any service by either showing its status on a health page or by sending it to a central logging service such as Splunk, Logstash, syslogd, Logentries, Datadog, or Sumo Logic. Observability is required to support reliable, scalable, and cost-effective services and metrics to scale up, metrics to scale down, and metrics to alert the team. This kind of monitoring and logging needs to be located at a central place. In a containerized environment, auto deployment should be able to auto-detect when a deployment fails so that it can be rolled back quickly to an older running version. Observability can be related to CPU usage, memory usage, network input/output metrics, disk metrics, the number of connections to a service, and so on. All these metrics are easily available and measurable through tools such as Check_MK, Nagios, New Relic, AppDynamics, StatsD, and Graphana. Observability not only helps in terms of providing a technical solution but also so that we can identify business decision-making, like the sales of a specific service or the returns for a specific product.
• Automation: Microservices also create challenges for an operation team with regard to deployment, verifying functionality, and performing various types of testing. There is now a wide range of automation tools available on market that can easily be integrated to achieve automated deployment, verification, testing, failure, and rollbacks. Some of the famous tools are Jenkins; Teamcity; Bamboo; Git workflow plugins; GitLab CI/CD; UI test tools, such as Selenium, PhantomJS, Nightwatch, BrowserStack; and many more. One important point here is that while Docker changed the container market when it was developed, it was hard to implement in a production environment, where a complete stack is required to maintain it as a production-level service. There wasn't much clarity with regard to monitoring or deployment. After that, Google released Borg in the form of Kubernetes and changed the container market again by providing easy deployment and rollback options with easy service and routing functionalities that were perfect for production-grade deployments.