Moving from traditional monolithic architecture to microservice architecture is a journey. There are many challenges moving towards the microservice culture and design. Microservices is an architectural style where a system is divided into a set of small services. As Conway’s law suggests, architecture and teams structure go in pairs. Microservice design pattern expects some organizational changes , culture and changes in design approach .
To start design a microservice architecture we must think about the following. These are not the exhaustive list.
- IT Team Structure.
- Discovery of Microservices
- Service Design (Domain driven design) and CI/CD (Continuous Integration/Continuous Delivery)
- Data Management
- Data Ownership
- Monitoring
- Security &
- Accountability
Let’s take one by one and go through these.
- IT Team Structure: Two pizza team
Traditional Organizations team are aligned vertically with technology divisions.
Example: A typical IT Team are distributed as UI Team , Middleware Team, DBA Team. They are smart people know technology in deep. Microservices team structure is more on the complete ownership of a service. For a typical online shopping company this team could look like OrderCapture team, Advertisement team, Search Providers, Shopping Cart, and Predictive Sales. The individual team would own the entire technology stack, DevOps and Support.
“Two pizza team”: Amazon’s “Two pizza team” is a formula to build a microservice team. The idea behind “Two pizza team” came from Amazon CEO Jeff Bezos. Ideally, microservice team shouldn’t be larger than what two pizzas can feed, 6-8 developers. If the team gets bigger communication becomes poor.
- Discovery of Microservices
With the Microservice architecture, the number of services increases. It’s become an increasing challenge to track services, versions and endpoint locations.
One way of defining service endpoint could be with Simple Naming Conventions like :
“<ServiceName>_<version_N#>.<env>.<domain_name>.<org>” .
But as the number of services grows over the time “Dynamic Service Registry” like ZooKeeper (Apache), Eureka (Netflix) is needed. Let’s talk few lines about dynamic service discovery. It’s very similar to Instant Messenger application where I really don’t care if the person on other side logged in from home or office. As long as the person is available on messenger I can continue my business. The point is end point location is discoverable. It is not coded or configured in the code. Similarly, for microservices services should be discoverable and every time a service gets activated, it’s get registered in the “Dynamic Service Registry” and the service should be marked as offline once it goes out of service. Remember a microservice always will have multiple instances and all services are designed for failures.
- Fine Grained Service design (DDD) and CI/CD
Microservice service design follows Domain Driven Design (DDD) model. Microservice defines a small problem domain. The concepts of Aggregate Roots and Bounded Contexts are used to breaking Enterprise services into Microservices.
Following are the Microservices design strategy:
- Fine Grained Noun Services (Not Verb)
Services should be at the Noun level. Example: Accounting Services, Shopping Cart, Discount. Anti-Pattern for the same could be: getAccountNumber, getAccountBalance etc.
- Loose coupling
Back to the basics of software design. Microservice follows basic principles of object-oriented design. Services should follow the design principal of “loosely coupled” and high in cohesion.
- Light weight Messaging
Use messaging service only for transport. Core responsibility of messaging infrastructure should be only trasnportation of messages. But it must be robust and highly available.
- Design for failures
It’s an architectural style to design microservice. Every service should handle failures and it should be able to service independently even if other services are not available. The application should also be able to service network latency or loss of communication.
- Circuit Breaker pattern:
As per Wikipedia “Circuit breaker is used to detect failures and encapsulates logic of preventing a failure to reoccur constantly (during maintenance, temporary external system failure or unexpected system difficulties)”. Microservice should implement Circuit breaker pattern to design for failures. Otherwise, it could potentially bring down multiple services.
- Design for 99% transactions.
- Design your system for optimistic transactions which is 99%. For other 1% bad transactions, handle failures asynchronously.
- Design for Throttling.
- Design for Elasticity. Expect a sudden workload increase and requirement of auto scaling of Application.
- Design for Retry
In case a microservice observes any network latency or loss of communication, microservice should have the ability to reprocess the transaction.
- Design with caching
Microservices are network chatty. Use a cache database to improve performance.
- Design with API versioning
Any new version of microservice can be released with a new version. All clients can gradually migrate to new versions. Backward compatibility is an important aspect of microservice DevOps.
- Devops:
Devops a must for Microservices. The primary goal of microservices is business agility. Microservices should be elastic in nature and should response to business agility.
- Data Management
Typically in traditional software architecture data are stored in RDBMS. Where all services connect to same database and databases is designed with Relational structure. For any new business requirement if there is a need of database schema change then all services connected to that database could be affected. The challenge with this model, individual services are very tightly coupled and they cannot change independently. This creates a longer time to market for any new ideas.
Microservices promote individual database for each service and they are individually owned and governed by the service owner. This micro database could scale up independently as needed and they can change independently without affecting other services.
- Data ownership
Ideally, every Microservice should own and govern own data. Microservice should be able to change its own datastore even data structure or model. Each microservice can have different variations of databases may be polyglot persistence.
What about System of Record? : This is the tricky part of design. Microservice should also own its own data as “System of Record” for the “aggregate root(DDD)”.
- Monitoring
Microservices architecture promotes high numbers of fine-grained services. It is very important to monitor each microservice individually not only from availability perspective but also from the SLA perspective. If a microservice is not able to meet a defined SLA, dynamically it should be able to scale up. On the other side, rogue microservice should go offline because it could potentially bring the whole system down. Following parameter are important to monitor to take necessary auto actions.
- Service Latency
- Rate per Second (RPS)
- Error rate
Last a microservice should also publish metrics. Be a transparent service in the organization.
- Security
In monolith architecture, the security requirement is for a single service.
For microservices, each service team owns security model of the service. This creates additional complexity layer to microservice layer. A common gateway can help to resolve this issue. It also addresses other problem.
API gateway has the following benefits:
- Common Gateway Authentication
- Transport layer security (SSL/TLS)
- Load-balancing across multiple instances of Microservices
- Request forwarding using discoverable service pattern.
- Transformations of data
- Accountability
If anything goes wrong with a microservice, that particular microservice team is accountable to fix it.
Final Thoughts: Microservice design is not a simple refactoring. It is very important to design well a fine grained distributed service. Think more on how to: a) Design with Remote calls, b) Eventual consistency model c) an operational DevOps team d) a new team structure.
References:
http://www.businessinsider.com/jeff-bezos-two-pizza-rule-for-productive-meetings-2013-10
http://en.wikipedia.org/wiki/Domain-driven_design#Building_blocks_of_DDD
http://martinfowler.com/articles/microservice-trade-offs.html
