Creación de aplicaciones basados en los 12 factores.

Una arquitectura de microservicio exitosa requiere un sólido desarrollo de aplicaciones y prácticas de DevOps. Uno de los resúmenes más sucintos de estas prácticas se puede encontrar en el manifiesto de la aplicación TwelveFactor de Heroku. Este documento proporciona 12 prácticas recomendadas que siempre debemos de tener en cuenta al crear microservicios.

1. Base de código: todo el código de la aplicación y la información de aprovisionamiento del servidor deben estar en control de versiones. Cada microservicio debe tener su propio repositorio de código independiente dentro de los sistemas de control de fuente. 
2. Dependencias: declara explícitamente las dependencias que usa tu aplicación mediante herramientas de compilación como Maven (Java). La dependencia de JAR de terceros debe declararse utilizando sus números de versión específicos. Esto permite que su microservicio siempre se compile utilizando la misma versión de bibliotecas.
3. Config: almacene la configuración de su aplicación (especialmente la configuración específica de su entorno) independientemente de su código. La configuración de su aplicación nunca debe estar en el mismo repositorio que su código fuente.
4. Servicios de respaldo: su microservicio a menudo se comunicará a través de una red con una base de datos o un sistema de mensajería. Cuando lo haga, debe asegurarse de que, en cualquier momento, pueda cambiar su implementación de la base de datos de un servicio administrado internamente a un servicio de terceros. 
5. Cree, publique, ejecute: mantenga las partes de la implementación de la aplicación, compiladas, publicadas y ejecutadas completamente separadas. Una vez que se crea el código, el desarrollador nunca debe realizar cambios en el código en tiempo de ejecución. Cualquier cambio debe volver al proceso de compilación y volver a implementarse. Un servicio construido es inmutable y no se puede cambiar.
6. Procesos: sus microservicios siempre deben ser sin estado. Se pueden eliminar y reemplazar en cualquier tiempo de espera sin temor a que una instancia de pérdida de un servicio provoque la pérdida de datos.
7. Enlace de puertos: un microservicio es completamente autónomo con el motor de tiempo de ejecución para el servicio empaquetado en el ejecutable del servicio. Debe ejecutar el servicio sin la necesidad de un servidor web o de aplicaciones separado. El servicio debe iniciarse por sí mismo en la línea de comando y se debe acceder a él inmediatamente a través de un puerto HTTP expuesto.
8. Simultaneidad: cuando necesite escalar, no confíe en un modelo de subprocesos dentro de un solo servicio. En su lugar, lance más instancias de microservicio y escale horizontalmente. Esto no excluye el uso de subprocesos dentro de su microservicio, pero no confíe en él como su único mecanismo para escalar. Escala horizontalmente, no hacia arriba.
9. Desechabilidad: los microservicios son desechables y se pueden iniciar y detener a pedido. El tiempo de inicio debe minimizarse y los procesos deben cerrarse correctamente cuando reciben una señal de interrupción del sistema operativo.
10. Paridad desarrollo / producción: minimice las brechas que existen entre todos los entornos en los que se ejecuta el servicio (incluido el escritorio del desarrollador). Un desarrollador debe usar la misma infraestructura localmente para el desarrollo del servicio en el que se ejecutará el servicio real. También significa que la cantidad de tiempo que se implementa un servicio entre entornos debe ser de horas, no de semanas. Tan pronto como se confirme el código, debe probarse y luego promoverse lo más rápido posible desde Dev hasta Prod.
11. Registros: los registros son una secuencia de eventos. A medida que se escriben los registros, deben poder transmitirse a herramientas, como Splunk (http://splunk.com) o Fluentd (http://fluentd.org), que recopilarán los registros y los escribirán en una ubicación central. El microservicio nunca debe preocuparse por la mecánica de cómo sucede esto y el desarrollador debe mirar visualmente los registros a través de STDOUT a medida que se escriben.
12. Procesos de administración: los desarrolladores a menudo tendrán que realizar tareas administrativas en sus servicios (migración o conversión de datos). Estas tareas nunca deben ser ad hoc y, en cambio, deben realizarse a través de scripts que se administran y mantienen a través del repositorio de código fuente. Estas secuencias de comandos deben ser repetibles y no cambiar (el código de la secuencia de comandos no se modifica para cada entorno) en cada entorno en el que se ejecutan.

Dejo link: https://12factor.net/