lunes, 28 de marzo de 2016

Plataformas reactivas: ¿de dónde vienen y qué son?


Organizaciones que trabajan en dominios diferentes están descubriendo y convergiendo, de forma independiente, en patrones para construir software que buscan los mismos objetivos: sistemas más robustos, flexibles y que estén mejor posicionados para cumplir las demandas modernas.

Los requerimientos de aplicaciones han cambiado dramáticamente en los últimos años. Sólo unos pocos años atrás, una gran aplicación tenía decenas de servidores, segundos de tiempo de respuesta, horas de mantenimiento fuera de línea y gigabytes en datos. Hoy, las aplicaciones son desplegadas de cualquier forma, desde dispositivos móviles hasta clusters en la nube corriendo en miles de procesadores multi-core. Los usuarios esperan tiempos de respuesta de milisegundos y que sus sistemas operen 24/7 (uptime 100%). Los datos son medidos en Petabytes. Las demandas de hoy, simplemente no están siendo satisfechas por la arquitectura de software de ayer.

Se necesita entonces un enfoque coherente para las arquitecturas de sistemas, pero en esta oportunidad  todos los aspectos necesarios ya están reconocidos individualmente: sistemas responsivos, resilientes, elásticos y orientados a mensajes. Es decir, Sistemas Reactivos.

Los sistemas construidos como reactivos son más flexibles, con bajo acoplamiento y escalables. Esto hace que sean más fáciles de desarrollar y dúctiles al momento de cambiarlos. Además, son significativamente más tolerantes a fallas y, cuando fallan, lo hacen con elegancia en vez de catastróficamente.  Los sistemas reactivos son altamente responsivos, dando a los usuarios retroalimentación efectiva e interactiva.

“Los Sistemas Reactivos son fáciles de desarrollar, resistentes a fallos, altamente escalables y distribuibles, y preparados para una gran demanda e interacción de usuarios.”

Reactive Manifest

Como mencionábamos anteriormente, los sistemas reactivos se caracterizan por ser: 

Responsivos

Los sistemas responden de una manera oportuna en la medida de lo posible. La responsividad es la piedra angular de la usabilidad y utilidad, pero más que esto, responsividad significa problemas que pueden ser detectados rápidamente y tratados efectivamente. Los sistemas responsivos se enfocan en proveer tiempos de respuesta rápidos y consistentes, estableciendo límites superiores de manera que entreguen un servicio de calidad. Este comportamiento se traduce en la simplificación del tratamiento de errores, en la construcción de la confianza con el usuario final y en una mayor interacción.

Resilientes

Los sistemas deben permanecer responsivos aún cuando enfrentan fallas. Esto aplica no sólo a la alta disponibilidad, como en un sistema de misión crítica, sino que hoy en día se espera como una característica de calidad que el sistema administre la falla en forma correcta;  eso es la Resiliencia.  Cualquier sistema que no es resiliente, no será responsivo después de una falla. La resiliencia es alcanzada con replicación, contención, aislamiento y delegación. Las fallas son contenidas dentro de cada componente, aislándolas de las demás y, de este modo, asegurando que las partes del sistema puedan fallar y recuperarse sin comprometer al mismo como un todo. La recuperación de cada componente es delegada a otro (externo) y la alta disponibilidad es asegurada por replicación donde sea necesario. De esta forma, el cliente de cada componente no es agobiado teniendo que manejar sus fallas.

Elásticos

El sistema se mantiene responsivo bajo variaciones en la carga de trabajo (e.g. cantidad de usuario concurrentes). Los sistemas reactivos pueden reaccionar a cambios en la frecuencia de peticiones incrementando o reduciendo los recursos asignados para servir dichas peticiones. Esto implica diseños que no tengan puntos de contención o cuellos de botella centralizados, resultando en la habilidad de fragmentar o replicar componentes y distribuir las entradas a través de ellos. Los sistemas reactivos soportan algoritmos predictivos, así como reactivos y de escalabilidad, proveyendo medidas relevantes de rendimiento en tiempo real. Los mismos alcanzan elasticidad de una forma rentable sobre plataformas de bajo costo (o equilibrado) tanto en hardware como software.

Orientados a mensajes

Los sistemas reactivos confían en el intercambio de mensajes asíncronos para establecer límites entre componentes, lo que asegura el bajo acoplamiento, aislamiento, transparencia de ubicación y proporciona los medios para delegar errores como mensajes. La utilización explícita del intercambio de mensajes ayuda a administrar la carga, la elasticidad y el control de flujo a través de la conformación y monitoreo de colas en el sistema y la aplicación de contrapresión cuando sea necesario. La ubicación transparente de mensajes como un medio de comunicación, posibilita a la administración de fallas el poder trabajar con los mismos bloques y semánticas a través de un cluster o dentro de un sólo nodo. La comunicación no-bloqueante permite que los receptores consuman recursos sólo desde y mientras dichos recursos estén activos, lo que lleva a una menor sobrecarga del sistema.



Los grandes sistemas están compuestos de otros más pequeños y, por lo tanto, dependen de las propiedades reactivas de sus constituyentes. Esto significa que los sistemas reactivos utilizan principios de diseño de manera que apliquen estas propiedades a toda escala, haciéndoles componibles. Los sistemas más grandes del mundo confían en arquitecturas basadas en estas propiedades y sirven las necesidades de miles de millones de personas diariamente. Es tiempo de aplicar estos principios de diseño conscientemente desde un principio en vez de redescubrirlos cada vez.
 
Herramientas: ¿cómo podemos implementar un esquema reactivo en nuestras organizaciones ?


Roadmap


  • Crear un backend con soporte de REST utilizando Play! Framework, permitiendo un mejor manejo de URLs dinámicas y aumentando la seguridad.
  • Implementar servicios utilizando el modelo de actores de Akka para separar la lógica de negocio de las acciones que puedan generar fallos, evitando el uso de operaciones bloqueantes, permitiendo mejorar la performance y estabilidad del sistema.
  • Utilizar Scala para generar el modelo de datos, permitiendo modelar estructuras complejas y relaciones entre entidades en un corto tiempo, con alta generalización y prolijidad.
  • Utilizar Slick en remplazo de un ORM, lo que permite manejar la información almacenada en una base de datos como si fueran colecciones de datos nativas de Scala, escribir consultas en Scala en lugar de SQL, y aprovechar la inferencia de tipos para garantizar consistencia entre los datos esperados y los recibidos en tiempo de compilación.


Play! Framework

Es un framework para el desarrollo de aplicaciones web escrito en Scala y Java que hace muy simple el desarrollo iterativo de aplicaciones reactivas. Play es una alternativa al conjunto de herramientas de Enterprise Java. Se enfoca en la productividad del desarrollador, aplicaciones web y Mobile modernas y en el predecible y mínimo consumo de recursos (CPU, memoria, threads) resultando en alta performance y aplicaciones altamente escalables.
Play fue creado para las necesidades de aplicaciones web y Mobile modernas, utilizando tecnologías como REST, JSON, WebSockets, Comet y EventSource para nombrar algunas. Estas tecnologías permiten la creación de interfaces de usuario ricas y altamente interactivas disponibles para cualquier web-browser moderno, mientras que, al mismo tiempo, hace más fácil renderizar porciones de la página en paralelo y hacer actualizaciones parciales o mejoras progresivas de la página.

“Encontramos que Play es uno de los pocos framworks que es capaz de mantener el delicado balance entre performance, confianza y productividad del desarrollador.”

LinkedIn


Akka

Imagine construir aplicaciones distribuidas y concurrentes con facilidad y confianza. Akka y el modelo de actores, aseguran sistemas que no se derrumban ante fallos, sino que se curan y adaptan de forma propia.
Akka separa la lógica de negocio de los mecanismos de bajo nivel, como threads, locks y operaciones de E/S no bloqueantes y libera a los programadores de los desafíos de administrar el estado y localización de servicios.
En Akka, la comunicación entre servicios es primordial. Esto se logra con mensajes primitivos que optimizan la utilización del CPU, baja latencia, alto rendimiento y escalabilidad (favorecido por los años de contribución de la comunidad open source).
Desde sus orígenes alimentando ambientes financieros con alto volumen de información, la utilización de Akka ha crecido a otros ámbitos, como juegos online, e-commerce, etc.                                                                                                                                           Hoy en día, Akka también es altamente utilizado en aplicaciones de Internet de las Cosas (IoT), en donde el manejo de fallos y mensajes entre micro-servicios, es primordial para ambientes productivos.

“Proveemos el futuro del dinero a más de 148 millones de personas en todo el mundo. Usando Scala y Akka podemos desarrollar, testear y entregar servicios que son confiables y performantes en una escala masiva.”

PayPal


Scala

Scala es un lenguaje de programación de propósito general, diseñado para expresar patrones comunes de programación de forma concisa y elegante. Scala integra características de lenguajes orientados a objetos y funcionales, posibilitando a los desarrolladores ser más productivos, mientras mantiene la interoperabilidad con Java y toma ventaja de hardware moderno multi-core. Además, hace más fácil evitar estados compartidos, permitiendo la distribución de procesos entre distintos núcleos en un servidor multi-core y entre servidores en un datacenter. Esto hace de Scala una muy buena elección para CPU´s multi-core y aplicaciones Cloud distribuidas que requieren concurrencia y paralelismo.
Gracias a su inferencia de tipos y otras características, Scala es un lenguaje sucinto, permitiendo a los desarrolladores reducir el tamaño del código fuente por un factor de 2 o 3 comparado con Java. Scala provee una gran cantidad de herramientas para desarrolladores, resultando en una productividad comparable a la de lenguajes como Ruby o Python, manteniendo las ventajas de performance de Java.
En los últimos años, Scala ha ascendido su posición en distintos rankings llegando en la actualidad al puesto 28 en el índice TIOBE, y al 14 en el índice RedMonk.

“Scala nos permite escribir mejor código y de forma elegante, haciendo de nosotros mejores ingenieros. Acierta en el balance entre concisión, expresividad y practicidad, y puedes hacer cosas increíblemente complejas con solo algunas líneas de código.”

Wix


En Baufest colaboramos con las organizaciones que requieren evolucionar en sus plataformas de servicios, recomendándoles y ayudándoles a implementar soluciones reactivas que aprovechen al máximo su infraestructura existente, sus herramientas disponibles e integrándolas con plataformas Cloud para ofrecer una alta performance.

¿Quiénes utilizan Sistemas Reactivos?








Referencias: 








Autor:
Guido Navalesi
Desarrollador Java especialista en tecnologías reactivas

miércoles, 9 de marzo de 2016

Las normas ISO y los riesgos - Parte III

Por último, para cerrar la serie de artículos sobre las normas ISO y los riesgos, consideremos algunas definiciones para introducirnos en el tema de la evolución del término “riesgo” que se produjo en las últimas versiones de las ISO.

  • Activo: cualquier recurso de la empresa necesario para desempeñar las actividades diarias y cuya no disponibilidad o deterioro supone un agravio o coste. La naturaleza de los activos dependerá de la empresa, pero su protección es el fin último de la gestión de riesgos. La valoración de los activos es importante para la evaluación de la magnitud del riesgo. Dicha valoración será realizada por los responsables.
- Este término en las nuevas normas se generaliza para denominarse «fuente de riesgo» siendo el elemento que sólo o con otros puede originar un riesgo.

  • Amenaza: circunstancia desfavorable que puede ocurrir y que cuando sucede tiene consecuencias negativas sobre los activos, provocando su indisponibilidad, funcionamiento incorrecto o pérdida de valor.
- En la evolución de las normas este concepto se amplia para denominarse «suceso»

  • Vulnerabilidad: debilidad que presentan los activos y que facilita la materialización de las amenazas.

  • Impacto o consecuencia de la materialización de una amenaza sobre un activo aprovechando una vulnerabilidad. El impacto se suele estimar en porcentaje de degradación que afecta al valor del activo, el 100% sería la pérdida total del activo. No necesariamente, pero es una forma.
- La consecuencia en las nuevas normas, es el resultado de un suceso que afecta los objetivos.

  • Probabilidad: es la posibilidad de ocurrencia de un hecho, suceso o acontecimiento. La frecuencia de ocurrencia implícita se corresponde con la amenaza. Para estimar la frecuencia podemos basarnos en datos empíricos (datos objetivos) del histórico de la empresa, o en opiniones de expertos o del empresario (datos subjetivos).Ejemplos: caídas o fallas de servicio, cortes de luz, inundaciones, errores de programación, etc.
- Este término permanece en la evolución de las normas ISO refiriéndose a un suceso en lugar de a una amenaza.


El siguiente gráfico nos ayudará a terminar de entender dichos términos:
  


Como corolario, indicaremos que las amenazas están allí y que somos los integrantes de las empresas quienes debemos evaluar cuánto y de qué forma nos impactan y tomar los recaudos necesarios para accionar calculando, en lo posible cuantitativamente, el nivel de nuestro riesgo.


 El impacto en las empresas puede ser de varios tipos:

  • Daños personales
  • Pérdidas financieras
  • Interrupción del servicio
  • Pérdida de imagen y reputación
  • Disminución del rendimiento

Los riesgos deberán gestionarse con planes ajustados a las necesidades evaluadas. Entre ellos, cada día son más comunes amenazas como: ataques informáticos, fugas de información, falta de desarrollo seguro en las aplicaciones,   y muchos más casos de los que nos gustaría reconocer a los especialistas en seguridad.

Sin decir nombres, recordemos casos públicos como los de empleados enojados o no leales, fallas de seguridad físicas y lógicas que permiten ataques simples de hacktivistas o ciberterrorismo. Todos temas que desarrollaremos en próximos artículos.


Autora:
Ing. Lic. Marcela Meyorin Lorenzo
IT Infraestructure & Security
CISA, Lead Auditor 25999/22301, ITIL v.3 Foundation/ISO-IEC 20000/AI9001         
Docente a cargo de la Diplomatura e-learning en UTN: