- 1 Microservice definition:
- 2 Microservices characteristics:
- 3 Componentization via Services :
- 4 Team Organization:
- 5 Use of Hybrid Cloud solution:
- 6 Scalability:
- 7 Microservices are Products not Projects
- 8 Smart endpoints and dumb pipes
- 9 Decentralized Governance & Decentralized Data Management
- 10 Automation & Design for failure:
I have another blog post here about Service Oriented Architecture (SOA). Microservice is often described as a subset of SOA and is more referred to as a style of organizing development teams rather than a technology thing.
Microservice is defined as an architectural style, an approach to develop a single application as a suit of services. Each service is defined by its characteristics some of which are:
- running in its process.
- communicating with a light weight mechanism often with an HTTP resource API.
- deployable by a fully automated machinery.
- using different programming languages/technologies/DB.
- is using different data storage technologies.
- Organized around business capability,
- Automated deployment,
- Intelligence in the endpoints rather than in service bus,
- Decentralized control of languages and data.
Componentization via Services :
A monolithic application built as a single unit. Microservices enables organizations to develop tiny modules with different security & privacy standards.
Another example of benefits of using microservices is that you can use different environments for running your different components/services. For example one piece of your software may be written in java 8 and the other piece might be runnable only in java 7. Whereas in monolithic applications you will be stuck. However, microservice gives you ability to use different runtimes for each piece of your application.
- services are out-of-process components who communicate with a mechanism such as a web service request, or remote procedure call.
- services are independently deployable
- Using services as components we need a more explicit component interface.
- We use swagger for microservice service definition.
- Remote calls are more expensive than in-process calls, and thus remote APIs need to be coarser-grained, which is often more awkward to use. (needs network/ http calls)
- Microservices are Organized (splitting up) around Business Capabilities
- Consequently the teams are cross-functional, including the full range of skills required for the development: user-experience, database, and project management. A good example of that is Amazon cross functional teams. Each team in Amazon is communicating all the way down to the end-user.
In monolith application development, we may have silo of UI developers, backend developers and DBA in separate teams.
Whereas in microservice development approach, we may divide each team around the business functionality in which case we need UI developers, backend developers and DBA(s) in each team. In amazon the size of each team is in such a way that each team may be fed by two pizzas.
Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the services’ communication structure.
Use of Hybrid Cloud solution:
Each microservice is deployable to a different cloud solution. This helps taking advantage of hybrid cloud solutions including combination of on-prem solution with public clouds such as Amazon AWS, IBM Bluemix, Microsoft Azure, or digital ocean. A microservice which is developed with microsoft technology might be deployed to Azure, whereas a linux based service may be deployed to digital ocean based on containerized technology. So, we may spread our services across multiple data-centers.
Another benefit of using different standard for security and privacy is when you are developing an application with sensitive data. For example government applications or healthcare applications cannot be physically hosted in different countries in some countries. In these applications you may divide your data into sensitive and non-sensitive data. You may host your sensitive data on public clouds while hosting non-sensitive services may be hosted in an on-prem solution hosted in an in-house datacenter.
Microservices are independently scalable. This means each service may be scaled up/down regarding to the requirement and the traffic load. Some services may be required to be scaled up with more instances due to higher traffic or sensitivity of a service. The number of instances in Monolith applications is constant and cannot be varied for different component/service which makes them either waste more resources or have a lower performance.
Microservices are Products not Projects
- team should own a product over its full lifetime. A common inspiration for this is Amazon’s notion of “you build, you run it”
- This brings developers into day-to-day contact with how their software behaves in production and increases contact with their users, as they have to take on at least some of the support burden.
Smart endpoints and dumb pipes
In a monolith, the components are executing in one process and communication between them is via either method invocation or function call.
In SOA,we’ve seen many products and approaches that stress putting significant smarts into the communication mechanism itself. A good example of this is the Enterprise Service Bus (ESB), where ESB products often include sophisticated facilities for message routing, choreography, transformation, and applying business rules as well as translation and transformation of messages and communications between different services. ESB is a very heavy and expensive platform beside all the services which makes implementation so hard. Microservices use a lightweight message bus such as RabbitMQ or ZeroMQ which don’t do much more than provide a reliable asynchronous fabric. The infrastructure chosen is typically dumb while moving the intelligence and the business logic into each service (end point).
The above picture shows this fat layer in the middle is removed and instead moved to each microservice node.
Decentralized Governance & Decentralized Data Management
Microservices are plyglot, that means each microservice may use
- Different languages
- Different DB
- Different deployment environment
- Different development lifecycle
- Different source control system
Each microservice may use different DB technologies from relational DB, Hadoop datastore to nosql or graph-DB regarding the type of the work that each microservice is doing.
Automation & Design for failure:
Since each team is responsible for development, test and deployment of its api, each team has to be notified automatically if something goes wrong. So a wide range of automation processes is required to manage APIs in this architecture such as api management, and automated testing tools.
Another concern around microservice development is design for failure. In microservice architecture we may have a mesh of communication between different services and each service might be dependent of another service. So, each service should be prepared for another service to fail due to network failure or any other reason. Hence, each service has to be designed in such a way that it responds to failure gracefully.