Welcome to the micro-services wiki!

What is a MicroService?

The microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable by fully automated deployment machinery. There is a bare minimum of centralized management of these services, which may be written in different programming languages and use different data storage technologies.

• Martin Fowler

The Twelve Design Principles

I. Service should be driven by business outcome.

• Encapsulates a single business process for the consumers.
• Consumers are not aware of the behind the scene complexities and integrations.

II. Services must a return a valid response except for timeouts.

• Services must return a valid and programmatically interpretable response to success and failure cases.
• Exceptions should not be passed as-is to consumers

III. Services must be autonomous

• Work with existing applications, yet segregate service from rest of the application dependencies at run time.

IV. Service Discovery and Documentation

• Use a service registry for registering and querying service instances.
• Use a API gateway for routing the services.
• Use a service discovery method to discover the service one would like to consume.
• Service endpoints should not be hardcoded in the applications, it would limit the failover or scale up.

V. Event Streaming and Sourcing

• Cross business domain business capabilities should be designed as an aggregate of decomposed services.
• Every participating service should update only single aggregate.
• Event Queues can be used for maintaining transactional integrity between aggregates and services.

VI. Quality of Service

• Services must follow the enterprise level quality of service standards.
• Ensure consistency across the business units on quality of service standards.

VII. Security

• Establish a key management solution for managing and distribution of private keys.
• Use a key/token based authentication for single sign on, avoid password based as much as possible.
• Follow the corporate security guideline - Data Entitlements, Network ring fencing, Coding Guidelines.
• Allow the container level automated scanning.

VIII. Fault tolerance

• Single service failure must not bring down the entire application
• Both service provides and consumers should have a way of handling unavailability of services.

IX. Service Monitoring and Failure triage

• Tool based service monitoring for availability and performance.
• Ability to detect failures based scenarios defined at quality of service level and application defined levels

X. Service call traceability

• Ability to trace the data objects and services through the lifecycle of the transaction or a business process execution.
• Maintain uniform data model definition for new services to make tracing easier.

XI. Central logging and Analytics

• Have a service level minimum log format so that a tool based analysis is possible.
• Allow service owners to analyze logs using tool based visualization and queries
• Ability to create dynamic queries and visualizations on the fly.

XII. Micro Service Cluster

• Multiple services based on criticality can be grouped as a cluster to reduce deployment complexity.
• Each cluster can have different level of scaling and fault tolerance levels depending on the criticality.

The Twelve Factors for Micro Service Deployment

I. Codebase - One codebase tracked in revision control, many deploys

• All of the application code lives in one repository. Do not store code in multiple repositories.
• Ability to deploy multiple versions application/services from same repository.

II. Dependencies - Explicitly declare and isolate dependencies

• All dependant packages required are defined explicitly.
• Never expect dependencies (packages, DBs, services, etc) are available locally.

III. Config - Store config in the environment

• Separate config from code. Config values varies substantially across deploys, code does not.
• Code should rely on same config variable across environments, but values differ depending on environment.
• Environment (DEV/UAT/PROD) specific config for services are stored in environment variables.

IV. Backing services - Treat backing services as attached resources

• App makes no distinction between local and third party services.
• Never use 'localhost' for service definitions, always use network identifiable names.

V. Build, release, run - Strictly separate build and run stages

• A release activity include a build(compile source code), bundle (Package binaries and configs), and deployment.
• Every release should always have a unique release ID, and it should be traceable to a deployment distribution.
• Ability to roll back to a previous release, including the DB changes.
• Never allow code change once the codebase leave the source control for build.

VI. Processes - Execute the app as one or more stateless processes

• Processes are should run in a stateless and share-nothing model.
• There should not be any dynamic compiling of any code base, it will violate share-nothing model.
• Application code should never rely on "sticky sessions" for sharing data across different execution cycle.

VII. Port binding - Export services via port binding

• Service is accessible via simple URL, bound to a specific port and IP address.
• You may create different front end URLs for the service with different routing rules for different use cases.

VIII. Concurrency - Scale out via the process model

• Services to handle diverse workloads by assigning each type of work to a process type [web, job, etc].
• App should support scaling each "process type" horizontal or vertical.
• Avoid singleton processes, each process type should allow configurable concurrent threads

IX. Disposability - Maximize robustness with fast startup and graceful shutdown

• If a service is discoverable, it should service request. There should not be any lag in initial loading and caching etc.
• Service deployment should be planned in such a way that service is discoverable only after it is ready to serve.
• Service should be self recoverable. A service crash recovery should never involve data clean up, file clean up etc.

X. Dev/prod parity - Keep development, staging, and production as similar as possible

• Keep development and test environments as similar as possible to production.
• It is applicable to dependant software setup as well, with same versions.

XI. Logs - Treat logs as event streams

• Logs will be written to the same output stream across environments at first level. Be it console, file or DB
• Logs can be routed and aggregated to a central processing and archival destination/s from the first level output stream.

XII. Admin processes - Run admin/management tasks as one-off processes

• Administrative tasks (log clean up, data cleanup, thread dumps, enable debug, etc) should have a codebase.
• Admin tasks must be executed from the same environment as the application running.
• Admin code must ship with application code to avoid synchronization issues.