What makes a good microservice framework?
This is of course an entirely subjective opinion for most people however whilst I have been thinking about this and how it could be possible to score and rank the various frameworks I thought I would share a mind map I have made.
Ease of use?
The first category I wanted to look at was the Ease of use, any good framework should be easy to use, this category has been broken down into the following sub categories.
The framework should be fast to setup and with the minimum number of steps and dependencies.
It should support code generation templates to scaffold an initial service and possibly extend the service.
There must be adequate tooling.
- CI/CD: Must integrate and work well with Continuous Integration and Continuous Deployment pipelines. The tooling must be scriptable from bash.
- Cross platform: The tools must work cross platform, Mac and Linux as a bare minimum.
The framework must be maintainable with the minimum of effort.
- Easy to update: It must be easy to update with the minimum of code changes.
- Well versioned: The framework must be well versioned with breaking changes to the API mainly restricted to Major version updates.
Ideally the service will support good standards in one of the following formats.
If the framework implements REST it must take full advantage of semantic API design with appropriate use of HTTP verbs and Status Codes.
If the framework is RPC based it must use a standard and open messaging protocol.
The framework must implement the standard patterns of microservice architecture.
Client calls to downstream services must implement circuit breaking.
It must be capable of registering with a dynamic service registry and capable of querying the same registry to locate connected services.
- DNS SRV records
- Proprietory: Proprietary service registries must be open and usable from other clients which do no implement the framework or its SDKs.
Downstream client calls must be equipped with a user configurable timeout.
The framework must create an automatic health check endpoint.
The framework must support multiple routes with an easy to use pattern based matching.
The framework must support middleware to allow the user to create shared code for handlers.
Downstream client connections should be capable of load balancing.
The framework needs to be language independent to enable cross team polyglot workflow.
At a minimum it should be possible to create client SDKs in multiple languages.
Ability to interface with other frameworks
It must be possible to interact with any service built with the framework by clients who are not built using the same framework.
A standard message protocol should be used to maximize interaction.
The framework should be open in both the source code and the roadmap.
When required the user should be able to extend the framework.
A pluggable software architecture to be able to create generators and templates.
Extension through handler middleware.
A good support network is incredibly important throughout the lifecycle of the service.
The framework should be well maintained with:
- Regular updates
- Accepts pull requests
- Corporate sponsor: Whilst this option is not essential a corporate sponsor can extend the lifecycle of a framework as there is less likelihood of a [leftpad] situation.
The framework should be well documented with clear and concise examples and comprehensive API documentation.
- Easy to follow: Documentation should be accessible and easy to read.
- Code samples: Adequate code samples should be provided to support a developer using the framework.
The framework will ideally have community contributed tutorials in both blog and video formats.
There should be a good community using and supporting the framework with at least one of the following channels of communication.
- Mailing list
- Stack Overflow
The framework should be secure and implement the latest industry standards.
It should be possible to secure the endpoints of the framework using TLS.
The framework should implement OWASP advisory.
Requests should be automatically validated based on rules implemented by message annotation.
Security vulnerabilities should be regularly assessed and patched.
The framework should be open sourced and released on a license which allows forking and modification.
There should be good open source community following and contribution for the project.
The framework should be popular and commercially used.
The code quality of the service should be visible and of a high standard. Community contributions should follow a published process and standard.
High test coverage
Test coverage should be high and monitored, pull requests should ensure adherence to coding standards.
- Unit High number of fast running unit tests is essential for both the framework and the generated code.
- Behavioural / functional: Ideally the framework should implement behavioral and functional tests in terms of the generated code and the build process.
Automated builds of the source code should be present and visible. Pull requests should run an automated build and the state reported on the request.
Automated code quality tools should be used and the results visible.
- Code climate
Standard language patterns
A standard method of writing the code taking account of the language level idioms is essential.
The framework must produce code which is efficient when run.
The code must execute quickly and be designed for performance.
Requests should be low latency.
The service should be memory efficient.
Supports large number of connections
It should support a large number of concurrent connections.