Last Friday, I got a meeting invite at work to discuss creating a new microservice as part of our application.
Whether it is Unix style programs, Domain Driven Design bounded contexts, classes and objects that adhere to the Single Responsibility Principle, I have been a supporter of small focused applications that have a single job to do, and do it well. This is one of the things that has appealed to me about Erlang as I have been digging ever deeper into it.
I will be first to step forward and promote the idea of microservices, but I will also be the first to come across like I don’t support them.
These questions are to make sure that proper thought is given to the implications of creating a microservice architecture, so that we don’t shoot ourselves in the foot and become the case study of why microservices are just a bunch of hot air, instead of being a case study for why and how it can work.
These questions are likely applicable to any new application, and not just microservices, and are inspired by the 8 Fallacies of Distributed Computing, the book Enterprise Integration Patterns, Domain Driven Design, my learning path with Erlang, and too many more to be named.
In no particular order at this point, but the general order at which they came into my head, here are the questions we should ask ourselves to help determine if a microservice is a good idea.
- What other information do this service need from other parts of the system? Is this truly a vertical slice of a domain?
- What other outside systems do we depend on for this service?
- What happens if one of the services dependencies is unavailable?
- How do we know if this service is running? Generating errors?
- Which parts of the system will be consuming the service?
- How to we abort without taking down the consumers of this service?
- What does the size of the request look like?
- What does the size of the response look like?
- What is the latency of this service?
- What is the latency of just returning a
200 OKwith a hardcoded return value. - What is the expected latency of processing a full request?
- What is the latency of just returning a
- What is the expected SLA of the service?
- How do we expect to meet that SLA?
- What is the SLA for uptime?
- What is the SLA for response time? Average response time? 95th percentile? 99th percentile? Worst case?
- What is our default response to return if we are about to break the SLA?
- Are we expecting this service to be exposed to the outside world? Live within an isolated network?
- Do we need authentication?
- Who would be authorized to consume this service?
- How are we expecting to manage access to this service?
- Do we need to encrypt the data exchange?
- What internal storage/persistance mechanism(s) do we need as part of this service to keep it isolated?
- How many Requests per Second are we expecting this service to need to serve?
- How do we expect this service to be deployed? What deployment dependencies are we expecting to need?
- How frequently do we expect this service to need to be updated after deployment?
- How many instances of this service do we think we will need to have running?
- How do we coordinate information exchange between multiple instances of the service?
- What is the expected time between a change notification and a consistent view of the system?
- If any one instance of the service in a cluster fails, do the rest fail?
- How do we keep the other instances from failing?
- How does an instance of the service catch back up to the latest state once it has recovered?
- If part of the service cluster fails, can we safely and automatically restart that part of the cluster?
- How many failures in a time period do we allow before escalating a larger issue?
- What is that time period?
- How do we escalate issues?
- How do we expect these larger issues to be addressed?
- What does it take to start the service from an empty slate?
- What does it take to stop the service?
- Can we have multiple versions of the service deployed and serving requests at the same time?
- How do we know what instance of the service served a request?
- What is the strategy to resolve the service endpoint from a blank
- What is the expected communication medium/protocol/payload we expect to be using to communicate with this service?
- Message bus channel subscriptions? HTTP requests? REST “proper” with Hypermedia? “Dumb” REST? JSON payload? XML payload? Protobuff payloads?
- How do we expect load to be distributed between any instances of this service?
- When making a request to an outside service, what do we do when awaiting a response?
- Block? Start processing another request? Do something that is not I/O based?
- How are we expecting to manage versioning of the APIs that this service is expect to provide?
- Does this service need to respond to incoming calls/notifications?
- If this service does need to respond, it is expected to be synchronous, “appear” synchronous, or be completely asynchronous style of response?
- If asynchronous responses are expected, how does the service get the information it needs to know to where to send the response to?
- How do we expect to trace a flow between work and the requests and responses that triggered that work? Is there a way to trace causality?
- What is the minimum infrastructure/frameworks that is needed to provide the service?
- Is this a service? Microservice? Additional monolithic application?
- What is the problem domain (bounded context) of this service?
- How do we know when we are adding features that should belong in other services?
- How many requests are we expecting are needed to complete a business use case?
- Is there any way to shrink that number? Can requests be combined?
This is by no means a complete list of questions we should be asking ourselves, but the start of a conversation to understand the scope of what it takes for a new service to be created and deployed. These are my brain dump of questions that help a team know if they know how to swim, and how deep the water is, before diving head first into the sea of microservices.
Let me know what other questions you think are missing.
–Proctor