Created
September 12, 2019 18:30
-
-
Save Charlyzzz/38baf662a515bbe187810819e0488218 to your computer and use it in GitHub Desktop.
Brainstorming de la charla
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
La paciencia de los usuarios es cada ves meno | |
El negocio exige agilidad y velocidad para adaptarse | |
Crecimiento exponencial del tráfico e información | |
Renacimiento: ML, microservicios, streaming de información están trayendo cambios masivos y nos dejan cuestionando las cosas que ya veníamos haciendo. | |
Ganando tracción ultra rápido | |
El monolito | |
Sistema compuesto de código e información. Solemos enfocarnos en el código y solemos olvidar el otro. | |
Big ball of mud. Es porque en muchos casos los sistemas crecen hasta tal punto en donde existe un fuerte acoplamiento entre la gente que trabaja para el. | |
Meter un cambio puede interferir con el cambio del otro porque usan la misma api, los mismos datos, etc. Entonces empezamos a retrasar | |
el flujo de release y comenzamos a programar en "comité" | |
Pero no se confundan, el monolito es una estructura robusta que la venimos utilizando hace mucho tiempo y simplemente no se va a ir (por varios motivos) | |
Tienen cosas buenas, son confliables y los sabemos construir. Cumplen el trabajo. | |
Los sabemos escalar, tener múltiples nodos para poder responder a tiempo y soportar la carga | |
El problema es cuando tenemos que determinar el tamaño. Que tan grande va a ser este sistema cuando lo lancemos en prod? (Ejemplo de GLOUD). | |
Tenemos que adivinar. La nube un poco permitiendo cambiar el tamaño y "recalcular" en función analizar el rendimiento de un sistema desplegado; tengo que | |
añadir, tengo que sacar. No nos olvidemos del datancer inhouse o onpremise, en donde el hw lo comprás y te comprometés a mantenerlo y pagarlo por largos periodos | |
Tener el papeleo, firmar contratos, SLA´s, etc. | |
Vas a tener que tratar de manejar con la carga teniendo suficiente capacidad, pero no mucho ($$$), y siempre soportando los picos. Empezar a analizar que pasa | |
con el porcentaje de utilización -> se traduce directamente en costo | |
Amdahls law -> proporcional a la cantidad de paralelismo que podemos meter en el sistema. 9 mujeres no pueden tener un bebé en un mes. | |
El problema que empezamos a tener para paralelizar es que tenemos puntos de concentración. La DB pasa a ser el choke point. Y no va a ir mas rápido. | |
Pasa a ser un SPOF. | |
Entonces, cómo cambiamos el monolito? | |
El primer paso podría ser empezar a usar microservicios, sacándole partes al monolito y moviéndole responsabilidades a estos módulos nuevos. | |
Estamos solo stripeando código, pero no tocamos la información! En realidad pasa a ser un "monolito distribuido". La DB sigue siendo un spof y un choke point. | |
2002 Amazon API mandate | |
AKKA tiene 10 años ya. Una cosa curiosa es que akka cluster le estaba faltando un layer de orquestación. Akka es muy bueno manejando cosas a nivel actores, a nivel jvm. | |
Pero no hay nada que maneje a las jvms | |
Definición del actor model: | |
The actor model in computer science is a mathematical model of concurrent computation that treats "actors" | |
as the universal primitives of concurrent computation. In response to a message that it receives, an actor | |
can: make local decisions, create more actors, send more messages, and determine how to respond to the next | |
message received. Actors may modify their own private state, but can only affect each other indirectly through | |
messaging (obviating lock-based synchronization). | |
Modelo de computaciones concurrentes. Las empezamos a combinar y podemos lograr desde cosas simples hasta estructuras muy complejas y elegantes. | |
Es una forma muy distinta de pensar para empezar y es necesario hacer el click para comprender realmente su potencial. | |
Ejemplo de mandar mensajes por Telegram | |
Snippet de un actor que cambia de behavior | |
Ejemplo de akka typed usando behaviors | |
Crop circles | |
Descripción de jvms | |
Descripción de los circulos | |
Estos actores del borde están dedicados a realizar una acción sobre una entidad específica: | |
updatear un carrito, efectuar el rulo finacieron de Pablo Beláustegui. Cada entity-actor va a estar representando una entidad y puede ser que posean estado interno | |
sobre ese objeto. | |
Van a aparecer cuando es necesario efectuar una acción y desaparecer cuando les dejan de llegar mensajes. | |
Shards -> Su objetivo es distribuir los entity actors a lo largo de todo el cluster, adaptándose a la cantidad de nodos del cluster, rebalanceando las entidades | |
cuando sea necesario | |
También tenemos actores singleton adentro del cluster, pero son menos interesantes. | |
El efecto que vamos a ver sobre los entity actors es que se aburren y deciden apagarse porque hace mucho que no recibieron mensajes. | |
Dibujo de microservicios con muchas pelotas de cluster | |
DEMO | |
Escalar | |
Apagar un pod | |
Ver como lo levanta kubernetes y le distribuyen shards | |
Podemos ver como manejó un falló. Akka se encarga de los actores y kubernetes de las jvms | |
Si recibe mucho tráfico kubernetes podría autoescalar (mostrarlo a mano). Se suman las jvms y akka dice: | |
me quiero sumar al cluster | |
redistribuyen los shards, balanceando la carga | |
Definición de reactive sistem | |
Lightbend hizo el reactive manifesto, sobre reactive programming y systems. | |
Orientado a construir un sistema que SIEMPRE responde al sistema. Si el tráfico sube o baja, el sistema siempre responde. | |
ActorRef | |
Diagrama mostrando como distintas entidades llegan a distintas entradas debido al load balancer de la entrada y mostrar como se routea | |
Los actores se van a delegar entre si el envio del mensaje para que sea transparente a los emisores. Akka es muy buena intercambiando mensajes, pero cuando | |
se trate de un hop que viaja por la red estamos a merced de la misma | |
Podríamos llegar a necesitar como desarrolladores requerimientos especiales sobre los actores, o necesitar | |
interactuar con actores que sean conscientes del cluster. Otro caso, por ejemplo, necesito que exista uno solo adentro del cluster | |
ActorRef | |
Referencia local totalmente transparente que nos permite "ubicar" al actor | |
Desacoplar la referencia lógica de la física nos permite desentendernos completamente del routeo del mismo | |
tomaron la idea de transparencia al límite en este sentido: no exite una api especial para hacer clustering ni remoting (instanciar actores en otras máquinas) | |
está completamente manejado por configuración | |
Complejidades | |
8 falacias de los sistemas distribuidos | |
CAP theorem | |
Siempre es necesario utilizar P, entonces solo podemos elegir C o P. | |
Clustering ABC | |
Nodo, cluster y lider | |
Membership | |
CRDT | |
Gossip (push pull) | |
Convergencia (en cuenta el ciclo de vida) | |
Elección de lider | |
Failure detector y Split brain resolver | |
actores | |
Intro | |
Remoting | |
Address | |
Definir sistema distribuido | |
Analizar para | |
Slider aumentando la carga de a poco | |
Suele haber mas lecturas que escrituras, en RDBMS las lecturas suelen ser mas "baratas" que las escrituras | |
Read replication -> rompemos consistencia (lectura de datos no propagados) | |
Peor aún, shardeamos por key. Ejemplo analizando la complejidad de elegir una buena clave. | |
-> Bases independientes que no me permiten hacer joins entre distintos shards. A veces sirve, a veces no. | |
Que pasa si no performa? Podemos agregar un índice (analizar que va a pasar con los writes), pero nos damos cuenta que en realidad el problema es que | |
estamos haciendo joins, entonces empezamos a desnormalizar. | |
Consistent hashing. | |
Ejemplo |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment