· 6 years ago · Sep 27, 2019, 02:34 PM
1La paciencia de los usuarios es cada ves meno
2El negocio exige agilidad y velocidad para adaptarse
3Crecimiento exponencial del tráfico e información
4Renacimiento: ML, microservicios, streaming de información están trayendo cambios masivos y nos dejan cuestionando las cosas que ya veníamos haciendo.
5Ganando tracción ultra rápido
6
7El monolito
8 Sistema compuesto de código e información. Solemos enfocarnos en el código y solemos olvidar el otro.
9 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.
10 Meter un cambio puede interferir con el cambio del otro porque usan la misma api, los mismos datos, etc. Entonces empezamos a retrasar
11 el flujo de release y comenzamos a programar en "comité"
12 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)
13 Tienen cosas buenas, son confliables y los sabemos construir. Cumplen el trabajo.
14 Los sabemos escalar, tener múltiples nodos para poder responder a tiempo y soportar la carga
15 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).
16 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
17 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
18 Tener el papeleo, firmar contratos, SLA´s, etc.
19 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
20 con el porcentaje de utilización -> se traduce directamente en costo
21 Amdahls law -> proporcional a la cantidad de paralelismo que podemos meter en el sistema. 9 mujeres no pueden tener un bebé en un mes.
22 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.
23 Pasa a ser un SPOF.
24 Entonces, cómo cambiamos el monolito?
25 El primer paso podría ser empezar a usar microservicios, sacándole partes al monolito y moviéndole responsabilidades a estos módulos nuevos.
26 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.
27
28 2002 Amazon API mandate
29
30 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.
31 Pero no hay nada que maneje a las jvms
32
33 Definición del actor model:
34 The actor model in computer science is a mathematical model of concurrent computation that treats "actors"
35 as the universal primitives of concurrent computation. In response to a message that it receives, an actor
36 can: make local decisions, create more actors, send more messages, and determine how to respond to the next
37 message received. Actors may modify their own private state, but can only affect each other indirectly through
38 messaging (obviating lock-based synchronization).
39
40 Modelo de computaciones concurrentes. Las empezamos a combinar y podemos lograr desde cosas simples hasta estructuras muy complejas y elegantes.
41 Es una forma muy distinta de pensar para empezar y es necesario hacer el click para comprender realmente su potencial.
42 Ejemplo de mandar mensajes por Telegram
43
44 Snippet de un actor que cambia de behavior
45 Ejemplo de akka typed usando behaviors
46
47 Crop circles
48 Descripción de jvms
49 Descripción de los circulos
50 Estos actores del borde están dedicados a realizar una acción sobre una entidad específica:
51 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
52 sobre ese objeto.
53 Van a aparecer cuando es necesario efectuar una acción y desaparecer cuando les dejan de llegar mensajes.
54 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
55 cuando sea necesario
56 También tenemos actores singleton adentro del cluster, pero son menos interesantes.
57 El efecto que vamos a ver sobre los entity actors es que se aburren y deciden apagarse porque hace mucho que no recibieron mensajes.
58
59 Dibujo de microservicios con muchas pelotas de cluster
60
61 DEMO
62 Escalar
63 Apagar un pod
64 Ver como lo levanta kubernetes y le distribuyen shards
65 Podemos ver como manejó un falló. Akka se encarga de los actores y kubernetes de las jvms
66
67 Si recibe mucho tráfico kubernetes podría autoescalar (mostrarlo a mano). Se suman las jvms y akka dice:
68 me quiero sumar al cluster
69 redistribuyen los shards, balanceando la carga
70
71 Definición de reactive sistem
72 Lightbend hizo el reactive manifesto, sobre reactive programming y systems.
73 Orientado a construir un sistema que SIEMPRE responde al sistema. Si el tráfico sube o baja, el sistema siempre responde.
74
75 ActorRef
76
77 Diagrama mostrando como distintas entidades llegan a distintas entradas debido al load balancer de la entrada y mostrar como se routea
78 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
79 se trate de un hop que viaja por la red estamos a merced de la misma
80
81 Podríamos llegar a necesitar como desarrolladores requerimientos especiales sobre los actores, o necesitar
82 interactuar con actores que sean conscientes del cluster. Otro caso, por ejemplo, necesito que exista uno solo adentro del cluster
83
84
85 ActorRef
86 Referencia local totalmente transparente que nos permite "ubicar" al actor
87 Desacoplar la referencia lógica de la física nos permite desentendernos completamente del routeo del mismo
88
89 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)
90 está completamente manejado por configuración
91
92
93
94
95Complejidades
96 8 falacias de los sistemas distribuidos
97 CAP theorem
98 Siempre es necesario utilizar P, entonces solo podemos elegir C o P.
99Clustering ABC
100 Nodo, cluster y lider
101 Membership
102 CRDT
103 Gossip (push pull)
104 Convergencia (en cuenta el ciclo de vida)
105 Elección de lider
106 Failure detector y Split brain resolver
107
108actores
109 Intro
110 Remoting
111 Address
112
113
114Definir sistema distribuido
115 Analizar para
116 Slider aumentando la carga de a poco
117 Suele haber mas lecturas que escrituras, en RDBMS las lecturas suelen ser mas "baratas" que las escrituras
118 Read replication -> rompemos consistencia (lectura de datos no propagados)
119 Peor aún, shardeamos por key. Ejemplo analizando la complejidad de elegir una buena clave.
120 -> Bases independientes que no me permiten hacer joins entre distintos shards. A veces sirve, a veces no.
121 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
122 estamos haciendo joins, entonces empezamos a desnormalizar.
123 Consistent hashing.
124
125Ejemplo