Brainstorming de la charla

gistfile1.txt

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