He estado trabajando desde hace un rato en la arquitectura del nuevo sistema de Becual.com (excelente emprendimiento, les recomiendo pasar a mirar el modelo de negocio, les conviene…) y últimamente he estado tirando líneas para hacerlo más escalable horizontalmente (pensando en cuando seamos una empresa multimillonaria sin rostro y yo nade en dinero como rico mac pato), es por eso que he estado revisando apuntes de sistemas distribuidos y leyendo para retomar la forma de pensar en los mismos, y como hace tiempo que no escribo nada dije, ya que estamos en esto mejor le damos.
Bueno, rescatando la definición de wikipedia, un sistema distribuido es una colección de computadores conectados entre sí por una red de comunicación y por simplicidad en el post, para nosotros estos computadores son nodos de la red. Como este post no tiene por propósito hablar de la definición de un sistema distribuido ni mucho menos, pasamos de inmediato a lo interesante, ¿Qué es esto del teorema CAP? y ¿Qué tiene que ver con sistemas distribuidos?, han escuchado la expresión «Bueno, Bonito, Barato… elija sólo dos», esta expresión caracteriza muy bien al teorema CAP (por sus siglas en ingles) o Teorema de Brewer (por Erick Brewer, el primero en enunciarlo), básicamente lo que el teorema indica es que un sistema distribuido tiene 3 característica fundamentales para cumplir, estas son:
- Consistencia (Consistency): Todos los nodos que participan en un proceso distribuido, tienen acceso a la misma información, por lo que si actualizo la información en un nodo y consulto otro, el sistema debe asegurarme que la información que me entrega sea la mas nueva, en este caso, la información que acabo de actualizar.
- Disponibilidad (Availability): Esto quiere decir, que se garantiza que toda petición aun nodo, como por ejemplo una lectura, responda en un tiempo acotado y sin responder un error, en simple, que siempre te responda no te deje esperando para siempre y jamás te tire un time out.
- Tolerancia al particionado (Partition Tolerance): Que dice que el sistema debe seguir funcionando pese a que entre ellos los nodos no se puedan comunicar.
Y como partimos postulando, no se puede tener todo en la vida, por lo que estamos restringidos a asegurar dos de ellas, el teorema tiene una muy buena y fundada explicación teórica que no explicaré para no quedar en vergüenza… pero les tengo aún más malas noticias, las restricciones que tenemos son aún mayores, pero eso lo revisaremos en otra ocasión, cuando analicemos las ocho falacias de la computación distribuida… estamos aún más atados de manos de lo que creemos.
noviembre 25, 2015 at 2:24 am
Hola Seba,
Contento saber que estas escribiendo sobre cosas complejas para que todos puedan entender. Excelente ejemplo del «bueno, bonito y barato»
Un par de preguntas que me surgen son:
¿Cómo están enfrentando el desafío de desarrollar para una start-up (donde típicamente el requerimiento del CEO es para ayer) y lo complejo del diseño/implementación de un sistema que realmente escale? (me refiero más a la parte práctica del día a día)
¿Qué tecnologías están actualmente usando (invirtiendo?) para este sistema pensando en escalarlo?
Saludos
Claudio
Pd: El link hacia becual no está funcionando.
noviembre 25, 2015 at 1:28 pm
Hola Claudio, gracias por lo del link, ya lo solucioné, estaba mal puesto, tus preguntas están interesantes y son super buenas, les voy a dar una vuelta y voy a escribir otro post para contestarlas, porque creo que amerita tener su espacio, hemos tomados decisiones super interesantes y no quiero que sea una respuesta a medias.
Pero no sientas que estoy diciendo «te llamamos», te prometo que voy a escribir, saludos y abrazos.
noviembre 26, 2015 at 8:17 pm
Buena Sebastián, justo toy trabajando con algunas cosas de sistemas distribuidos, respecto a esto me gusta el dibujo de Martin Fowler, aunque no sé si lo hizo él xD, en que en realidad tu elección se reduce a dos opciones, hay un video de NoSQL Distilled donde lo explica. Se supone que puedes escoger dos de tres, pero en realidad solo puedes escoger entre Availability y Consistency, y como no puedes tener totalmente las dos ni tampoco dejar de lado totalmente una de las dos, va a depender de tus necesidades, del negocio, etc. de como te mueves entre estos dos elementos, no puedes tener los dos, pero puedes considerar darle más importancia a uno según lo que necesites. Por ejemplo, ahora estoy en un proyecto en que la consistencia es realmente importante, tal vez más que tener alta disponibilidad, por lo que las herramientas a utilizar y decisiones a realizar consideran mucho este elemento. Muy interesante todo esto, y con la llegada hace un rato de herramientas como Docker es relativamente fácil levantar estas arquitecturas, aunque es realmente difícil implementarlas bien :).
noviembre 26, 2015 at 8:53 pm
Buena Claudio, que bueno escuchad de ti y que estés en proyectos tan interesantes, pero básicamente te mandaste el espoiler del siguiente post Jajajaja, la idea era analizar las ocho falacias y llegar a las mismas conclusiones, sin gráfico eso sí, el vídeo de NoSql distiller no lo he visto voy a buscarlo y verlo, porque creo aún estar a tiempo de volver en mis desiciones si es necesario, bueno eso y que rico saber de ti, espero más comentarios en futuros post y si es que te animas incluso un aporte voluntario en algún artículo sería tremendo. 😉