There is no industry accepted definition or consensus yet regarding the definition of microservices. But there are some properties or characteristics that all the teams practicing the trade has agreed on. Here’s what I found on the internet and decided on the important ones based on my experience so far with microservices - the common characteristics that defines a microservice.
https://en.wikipedia.org/wiki/Microservices- Microservices is a specialization of and implementation approach for service-oriented architectures (SOA) used to build flexible, independently deployable software systems.
http://martinfowler.com/microservices/ - In short, 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.
http://samnewman.io/books/building_microservices/ - Small autonomous services that work together, modelled around a business domain. (this is the most short and sweet definition that I found)
https://www.ibm.com/devops/method/content/code/practice_microservices/ Microservices are a modern architecture that was created for systems where continuous integration and DevOps are practiced. In its core, the microservice architecture advocates partitioning large monolithic applications into smaller independent services that communicate with each other by using HTTP and messages. The architecture pattern is a child of the continuous integration revolution and is designed for deployments that use a DevOps-based continuous delivery model.
Microservices is an architecture style which prescribes building large complex software applications using many fine grained services. These microservices are narrowly focused, independently deployable, loosely coupled, language agnostic services fulfilling a business capability. These multiple microservices communicate with each other using language-agnostic APIs such as REST.
Let’s look at some common characteristics that is true for every microservice.
Modelled around the business domain
In the world of SOA, the services had to business aligned and the economics of funding determines what services actually get funded to be developed. (Service Litmus Tests & Economics). In the SOA world, each service had to be aligned to the business to be called a service. It is same guideline for a a micro-service as well– focused on accomplishing a small unit of work modelled around the business domain. Services are organized around capabilities, e.g., user interface front-end, quotes, logistics, reservation, billing, etc.
Small and Focused
Microservice granularity are based on the business needs and focused on accomplishing a small unit of work. There are no written rules on how small a microservice must be. The focus should really be on keeping the interface small. These microservices are applications in themselves and are often owned by small teams. Unlike the normal practice, the team which coded the microservices is also responsible for its support. But with the fast adoption of cloud based deployment and continuous delivery processes like Dev-Ops, the preferred approach is keep the service small. Small enough to be developed and maintained by a smaller team (2 pizza teams).
Autonomous & Bounded Context
A microservice needs to be treated like a separate application or a product with well defined interfaces, implementing a business capability. It generally does not need to know anything about underlying implementation of other microservices surrounding it. In the architect’s terminology, the system context defines the IT landscape and the boundaries. So for a microservice in a system context diagram, should encapsulate the details of a single domain and define the integration with other services /domains. It should have its own source code management repository, and its own delivery pipeline for builds and deployment
Each of the microservices can be independently deployed and scaled, updated, and then redeployed independently without having to redeploy the entire application or compromising its integrity. This means there is a means to deliver continuous business value by each microservice teams.
Microservices are platform agnostic and may be developed or implemented using different programming languages, databases, hardware and software environment – the idea is to reuse as much as possible and deliver the capability required by the customer at the earliest. The application is made of composing together several microservices. So each of the microservices may be written using any programming language that meets the task requirements but can be combined to delivered the complex solution.
Designed for Failure
In the cloud world, probably trying to fix a failed instance is costlier than spinning up a new instance and using the same. So in a microservices world, it is expected that when you have several moving parts, few of them might develop issues on the run for one reason or other. In such situations, the overall system should be able to still server the intended client when the failing service can take a graceful exit or join back the system as a new instance. So the design should account for such situations. Probably this is one of the difficult characteristics to meet.
De-centralized governance and data management
Given each smaller teams are working hard to solve the problem in hand, each of them would find different tools that meets their purpose. You don’t want to rally them against a common tool and practices. Whichever practice and tool that saves time and meets the purpose is encouraged and best practices shared. So mostly smaller teams favour decentralized governance.
As we know monolithic systems mostly uses a single database or systems of record across various services. In the microservices world, just as like decentralized governance, the community prefers each service managing its own database or data of/for engagement and records..
The above are the key common elements or defining characteristics of a microservice that I could relate to from my experience and/or that’s the common denominator across a range of articles and guides that I referred to (See list below).
Some great resources or references on the topic
Principles Of Microservices by Sam Newman https://www.youtube.com/watch?v=PFQnNFe27kU
Microservices - Martin Fowler
IBM Cloud Architecture Center
Microservices from Theory to Practice
Creating Applications in Bluemix Using the Microservices Approach
What’s Microservices Architecture?