Download Distributed Systems with Python

“Distributed Systems with Python”
Compartiendo mi experiencia
Martin Alderete
@alderetemartin
malderete@gmail.com
Sistemas Distribuidos - Introducción
“A distributed system is a software system in which components located on
networked computers communicate and coordinate their actions by passing
messages.The components interact with each other in order to achieve a common
goal”
Sistemas distribuidos - Características
●
●
●
●
●
●
●
●
Transparencia
Escalabilidad
Tolerancia a fallos
Consistencia
Abiertos
Concurrencia
Cuestion economica
siempre algo me olvido….
Sistemas Distribuidos - Bienvenidos
Arquitectura basada en Microservicios
Arquitectura de desarrollo de sistemas que intenta descomponer los
componentes de un sistema monolítico en sub-sistemas más pequeños y
autónomos que colaboran utilizando un protocolo de comunicación.
●
●
●
●
Autónomos
Independientes
Mantenibles
Pequeños
Sistema Monolítico vs Microservicios
Sistema actual con el que trabajo...
Todos los
servicios están
escalados
Herramientas Python que usamos… (algunas)
Python 2.7.x
Gevent
Django 1.3, 1.7
Multiprocessing
Django Rest Framework
PIP (Self-hosted)
Haystack
Celery
PySolr
tweepy, wikipedia
MongoEngine
pycrypto
MySql-Python
uWSGI y MAS….
Mucha tecnología!! Esto esta buenisimo :)! NO?
Nada de que quejarse!
Ponele…
Houston: “Tenemos varios problemas/desafíos”
●
●
●
●
●
●
●
●
●
●
●
●
●
Repetición de código
Boiler plate
Bases de datos en “Shard”
Comunicación entre servicios
Comunicación entre lenguajes (Python, C++, Java)
Pasaje de mensajes (HTTP, Publish/Subscriber, AMQP, DB-queue, SOAP)
Incremento de trafico de red
Documentación
Monitoreo
Reporting/Logging
Testing (unittest, integration test)
DevOps
y algo me debo olvidar...
Detallando
El acceso a Redis es “Copy/Paste”
Muchos servicios usan los mismos Models
Muchos servicios usan los mismos Documents
Testing: Unit-test e Integration-Test
Definición de protocolos entre servicios
ffmpeg y amigos son feos… (Ni hablar el DRM con SOAP)
Cómo sabemos si el servicio X está “bien” ? Mucha carga debemos escalar?
Monitoreo de Brokers
Nada de que quejarse!
Servicio: “Arquitectura elegida”
Servicio X
I
N
T
E
R
F
A
C
E
API Monitoreo (HTTP)
Scripts Customizados
Que hicimos
●
●
●
●
●
Repositorio PIP propio
Redis
MongoDB
Modelos de Django
Descarga concurrente
Threading es caro, Gevent rules!
Daemons
Parent-Child
Haystack
Comandos customizados (update_solr, reiondex_solr)
Subprocess
“Parseamos a pelo” la stdout
Que hicimos continuación
●
Django (MySQL Master/Slave)
Database router
●
MongoDB shard
MongoEngine + MongoDBProxy
●
FileSystem Distribuido
Programar pensando en concurrente/distribuido (Race-Condition)
●
Monitoreo/Health Check y Documentación
Cada Servicio provee una API de monitoreo y scripts que la consumen
Que hicimos continuación DevOps
libvirt (Virtualización)
SaltStack (Orquestacion)
Jenkins (Integracion Continua)
Nagios (Monitoring)
“Conclusiones”
Siempre debemos evaluar antes de hacer (TRADE-OFF)
El Stack se va a las nubes!
Microservicio no significa “cantidad de lineas de codigo = X” (filosofia UNIX)
Intentar escalar no es tarea fácil nunca, pero es divertido
Se DEBE monitorear y mantener vivo cada servicio
Deploys aislados
Integracion continua
Unittest MUCHO mock no olvidarse de IntegrationTests
Definir estrategias de Logging
Documentar cada servicio!
Evitar Copy/Paste entre servicios
Programar es divertido y es lo que nos gusta!
Muchas Gracias!
¿Preguntas?
while not manos.dormidas:
aplausos()
Martin Alderete
@alderetemartin
malderete@gmail.com