Pitfall - something that was never a good idea, even from the start
Grains of Sand
Creating services that are too fine-grained.
Service should be single purpose and have high cohision. To determine we should list all the service functions.
For example if we have a service which do the following:
Create customer
Update Customer
Delete Customer
Notify Customer
Accept Customer comment
It’s easy to see that from above functions we could move Notify and Comment to separate services
If it’s required to use ACID transaction in some case between two microservices - we should consider to consolidate these services.
We should minimize choreography between services (communication with REST)
we have network latency between microservices
the more services we coordinate withing a single request the less level of choreography we have
James Lewis: Application that fit in your hand
Sam Newman: Start out more roarse-grained and move to fine grained as you learn more about the service.
Analysis
Map out the communication paths between services. How much communication is there between services (especially within one request)?
List the operations for each services. Is there high cohesion (the degree and manner to which those operations of each service are related to one another) between operations for each service? Does the service do to much and should be split?
Goal
Minimize inter-service communication
Strive for high cohesion between operations in a service
Developer without a cause
Making programming and design decisions without taking the business drivers into account
Microservices architecture style have pros and cons, as any other style. So we should take into account them when we choose the style for our applicaiton
Analisys
Identify and document the business drivers and reasons for using a microservices architecture.
Answer the following questions:
Why are you doing microservices?
What are your primary business drivers?
What characteristics are most important?
performance
deployment and change control
scaleability
robustness
Goals
Always make design and programming decisions withing the context of business drivers
Jump on the Bandwagon
Embracing microservices before analyzing capabilities, drivers and business needs.
Advantages:
Deployment (we could deploy single service)
Testability (we don’t need to test the whole application while deploying single service)
Change control (minimizing the number of people we need to coordinate to deploy service)
Modularity (app is moduled by default)
Scalability
Development
Disadvantages:
Performance
Complexity
Devops
Org change (we should change our organization according to our services)
Relaiability
Feasibility
Analyze your technical and business needs and goals
What are your goal?
what are you trying to accomplish?
What are your pain points?
What are your primary architecture drivers?
Does microservices fit these needs?
Analysis
List the technical and business pain points in your current application and environment
List the reasons why you are considering using microservices.
why do we use\don’t use microservices
whe do we use\don’t use event sysstem
Do the characteristic and advantages of microservices address your pain points and buiseness needs?
Goals
Make sure microservices it the right arthitecture style for your situation and business needs
Logging Can Wait
Addressing distributed logging concerns late in the development lifecycle
We should generate correlation/context id
Analysis
Identify the context of each request(e.g. order number, customer id, confirmation number, etc.)
Create a logging API wrapper around you current logging tool
Goals
Consolidate logs from multiple services to identify the request flow of a specific request
Using Too Much ACID
Relying too much on ACID transactions when using a microservices architecture
Analysis
Create a mapping of business requests to microservices calls.
Identify those requests that require multiple services. Are ACID transactions required? If so consolidate services.
List the services databases requiring eventual consistency. Come up with a pattern to do eventual consistency (event based, request based, batch based)
Goals
Identify which requests require an ACID transactions
Identify how and when you will do eventual consistency
Static Contract
Not versioning your service contracts from the very start (or not at all)
There are two ways of doing service contract versioning:
Where is the version documentation for each contract?
Document the procedures for communicating contract changes
How many versions for each contract do you support?
Do you have procedures defined for deprecating older versions?
Goals
Support backwards compatibility with your services
Ensure effective communication when contract changes are made
Service Orphan
Not designating a specific owner for a service (or a class of services)
Analysis
Identify each service owner and the services they own (have service owners attached to a specific domain)
Document the communication procedures between service owners
Goals
Associate service with specific service owners
Ensure service owners effectively communicate with one another
Are We There Yet
Not accuratly knowing how long the remote access portion of the request will take
In many cases remote access part of the job would take a big percent of the request time, so it’s good to know how long does it take to implement and optimize between-services communication.
Analysis
Establish the average latency time for your remote access call
Deternime which requests need to be optimized based on multiple network hops
Goals
Understand your network latency for service access and make corresponding ajustments
Give it a REST
Using restful web services throughout your entire microservices architecture without fully analyzing your remote access needs
In many cases it’s better to use Message Queues instead of REST.
Analysis
Identify requests that can leverage asynchronous processing
Determine if you have broadcast capability needs
Determine if you have remote request transaction needs
Goals
Understand your remote processing capabilities needs
Improve performance through messaging capabilities
Dare to be Diffeernt
Not using a common service template or common custom base image
It’s great to implement service template for new service. It solve a lot of issues new developer will meet in implementing new microservice/
Things to put inside service template
call to authentication service
hook for authorization
hook for contract validation
common error handling
common logging
Analysis
List the operations and hooks within your service template. Are there operations that can be added to the template?
Are development teams using the same base image and service template?
Goals
Encapsulate as much common framework code as possible in your service templates and base images to increase productivity and consistency when creating services.