¿Qué es OpenTracing?

OpenTracing es un estándar abierto y neutro para traceo distribuido.

En la actualidad con el paso de los sistemas monolíticos a las arquitecturas de microservicios un sistema en producción está compuesto de un buen número de servicios, lo que hace que tareas que antes eran sencillas como análisis de errores en backend se complican.

Por suerte existen un buen número de sistemas de traceo distribuido (Zipkin, Dapper, HTrace,…) que resuelven esto, aunque cada una usa su propia API. OpenTracing ofrece un API consistente y expresiva para que los desarrolladores puedan añadir trazas (o cambiar la implementación) a través de configuración.

OpenTracing ofrece librerías en 8 lenguajes: Go, JavaScript, Java, Python, Ruby, Objective-C, C++, C#

Existen bastantes librerías que soportan el estándar OpenTracing, como

· Zipkin que soporta OpenTracing en varios lenguajes

· Jaeger ˈyā-gər (el Sistema de trazas distribuido de Uber)

· LightStep en varios lenguajes

· Hawkular APM en Java

· Instana lo soporta en Java, Node y Go.

· sky-walking para aplicaciones Java

· inspectIT para aplicaciones Java

· Stagemonitor para aplicaciones Java

Componentes básicos de una Arquitectura de Microservicios

Para dar respuesta a los retos de una Arquitectura de microservicios:

Los componentes principales de una Arquitectura de Microservicios son:

  • Servidor de configuración central: se encarga de centralizar y proveer remotamente la configuración a cada microservicio.
  • Servicio de registro / descubrimiento: es el encargado de proveer los endpoints de los servicios para su consumo.
  • Balanceo de carga (Load balancer) permite el balanceo entre distintas instancias de forma transparente a la hora de consumir un servicio.
  • Tolerancia a fallos (Circuit breaker): permite que cuando se produzca un fallo este no se propague en cascada por todo el pipe de llamadas, y poder gestionar el error de forma controlada a nivel local del servicio donde se produjo.
  • Servidor perimetral / exposición de servicios (Edge server): gateway en el que se expondrán los servicios a consumir.
  • Centralización de logs: Se hace necesario un mecanismo para centralizar la gestión de logs. Pues sería inviable la consulta de cada log individual de cada uno de los microservicios. Adicionalmente, también son interesantes los dos siguientes componentes
  • Servidor de Autorización: Para implementar la capa de seguridad (recomendable en la capa de servicios API)
  • Monitorización: mecanismos y algún dashboard para monitorizar aspectos de los nodos como, salud, carga de trabajo…

How to Choose the Right Technology for Your Project

Me ha encantado este artículo  (supongo que por eso de coincidir en las conclusiones):

Conclusion

  • Choose what the team is familiar with.
  • Don’t be cool — play in your free time.
  • Choose the right tool for the job.
  • Prefer principles of good software design over the latest hype.
  • Don’t overload the number of languages.
  • Educate yourself and the team on foundations of computer science.

Infografía The 12-Factor App

Esta infografía de DZone resumen visualmente esta (ya no tan nueva) aproximación al desarrollo: The 12-Factor App (ver post)

1. Codebase One codebase, many deploys, strict version control

2. Dependencies Explicitly declare and isolate dependencies

3. Configuration Store config in each deploy environment, preferably using environmental variables

4. Backing Services Treat backing services as resources (neutral as to local vs. third-party) located via config

5. Build, Release, Run Strictly separate build, release, and run; never change code at runtime

6. Processes Keep all processes stateless and share-nothing; store state (with other persistent data) in a stateful backing service

7. Port Binding Bind every service to a port and listen on that port; don’t rely on runtime server injection

8. Concurrency Distinguish process types (e.g. web, background worker, utility) and scale each type independently

9. Disposability Make processes start up quickly (<4s from launch to ready) and shut down safely (for web process: stop listening, finish current requests, exit; for worker process: return current job to work queue)

10. Dev/Prod Parity Maximize dev/prod parity by minimizing gaps in time (between deploys: hours), personnel (authors=deployers), and environment (use adapters for backing services)

11. Logs Log by writing all output streams to stdout; rout streams using non-app services

12. Admin Processes Run one-off/admin processes (db migration, REPL , one-time scripts) in same environment as normal processes

Ver Infografía completa

The Twelve-Factor App

The Twelve-Factor App es una metodología (conjunto de recomendaciones para ser más exacto) para construir aplicaciones Software-As-A-Service.

Estas normas aplican a cualquier lenguaje de programación y a cualquier combinación de Backend Services (Base Datos, colas, caché,…):

Aparte de los 12 factores me parece muy interesante las recomendaciones:

· Usar formatos declarativos para automatizar el setup

· Reducir el tiempo y coste para que los desarrolladores empiecen a trabajar en el proyecto (fundamental!)

· Ofrecer portabilidad entre entornos de ejecución

· Estar preparadas para el despliegue en entornos Cloud

· Minimizar las divergencias entre desarrollo y producción

· Habilitar el despliegue continuo para maximizar la agilidad

· Escalar sin cambios significativos en las herramientas, arquitectura y prácticas de desarrollo

Van aquí los 12 Factores:

I. Codebase

One codebase tracked in revision control, many deploys

II. Dependencies

Explicitly declare and isolate dependencies

III. Config

Store config in the environment

IV. Backing services

Treat backing services as attached resources

V. Build, release, run

Strictly separate build and run stages

VI. Processes

Execute the app as one or more stateless processes

VII. Port binding

Export services via port binding

VIII. Concurrency

Scale out via the process model

IX. Disposability

Maximize robustness with fast startup and graceful shutdown

X. Dev/prod parity

Keep development, staging, and production as similar as possible

XI. Logs

Treat logs as event streams

XII. Admin processes

Run admin/management tasks as one-off processes

¿Qué es una Arquitectura Serverless (y AWS Lambda)?

Las Arquitecturas Serverless reemplazan a las máquinas virtuales de larga duración con una capacidad de computación efímera que se crea para resolver una petición y desaparece después de su uso.

Ejemplos de estas Arquitecturas son Firebase y AWS Lambda.

Estas Arquitecturas mitigan preocupaciones de parches de seguridad, control acceso,… y hacen un uso muy eficiente de los recursos de computación, además estos sistemas son fáciles de operar y ofrecen características integradas de escalado. Por el contrario el despliegue, gestión, testing y compartición de código entre servicios es más complejo.

Un ejemplo de esta Arquitectura podría ser una Aplicación Javascript con asset estáticos servidor por un CDN o S3 junato a llamadas AJAX servidas por el API Gateway y AWS Lamdda.

Veamos cómo se define AWS Lambda:

“AWS Lambda le permite ejecutar código sin aprovisionar ni administrar servidores. Solo pagará por el tiempo de cómputo que consuma – no se cobra nada cuando el código no se está ejecutando. Con Lambda, puede ejecutar código para casi cualquier tipo de aplicación o servicio back-end – y todo sin administrar nada. Usted solo tiene que cargar el código. Lambda se encargará de todo lo necesario para ejecutar y escalar el código con alta disponibilidad. Puede configurar el código para que se active automáticamente desde otros servicios de AWS o puede llamarlo directamente desde cualquier aplicación web o móvil.”

Y funciona así:

Veamos algunos ejemplos de uso de AWS Lambda como Arquitectura Serverless:

O: