La evolución de las Tecnologías de la Información hacia la hiperconvergencia

Las tecnologías avanzadas alteran continuamente el panorama de nuestro mundo y cada paso es una evolución incremental que lo impulsa hacia adelante. Las empresas modernas dependen en gran medida de esta disrupción positiva cíclica e iterativa para ser competitivas en el mercado e innovar, brindando nuevos servicios y productos a sus clientes más rápido que nunca.

Las empresas también exigen flexibilidad, posibilidad de elegir, agilidad y rentabilidad de estas tecnologías habilitadoras, para garantizar que las capacidades comerciales puedan cambiar con la demanda, el mercado, la misión comercial, etc.

En la última década, el auge de los servicios en la nube satisfizo la demanda de más Tecnologías de la Información y agilidad empresarial, lo que permitió que nuevas aplicaciones y servicios estuvieran en línea casi de la noche a la mañana. Sin embargo, esta capacidad creó problemas secundarios de expansión de datos y sistemas, gobernanza y estratificación del cumplimiento, costando a las empresas más que los modelos tradicionales de centros de datos, ya que carecía de controles de costos maduros.

Entonces, por estas razones y más, las empresas se dieron cuenta de que ciertas cargas de trabajo y conjuntos de datos eran más adecuados para sus centros de datos, mientras que otras requerían una arquitectura a escala "web" que llegara a una audiencia global, sin fricciones ni resistencia alguna. Así nació el modelo de nube híbrida. Ésta combina control, flexibilidad, seguridad, escalabilidad y rentabilidad, satisfaciendo las necesidades tanto de las empresas como de los clientes. Pero para comprender realmente los impulsores comerciales que llevaron a la nube híbrida, debemos analizar brevemente dónde comenzó todo esto. Y todo empezó con El Mainframe (la Primera Plataforma).

Mainframes (nace la Primera Plataforma)

Comenzando con la computación basada en Mainframes u Computadoras Centrales, los usuarios tenían la capacidad de crear estructuras de código monolíticas masivas, que residían en equipos en gran parte aislados y hechos a la medida. La potencia de procesamiento y el diseño centralizado de este sistema lo hacían muy costoso e inflexible. Utilizaban tecnología propietaria y el mantenimiento de cada sistema requería capacitación especializada y una coordinación cuidadosa, para garantizar interrupciones comerciales mínimas.

En caso de falla, se requiere forzosamente de un Mainframe Secundario, y la restauración desde las cintas de respaldo puede tardar días en completarse (Recovery Time Objective prolongado). Hablando de las aplicaciones, éstas tenían que ser escritas a medida para cada plataforma, lo que requería mucho tiempo y dinero.

Servidores Unix (nace la Segunda Plataforma)

La creación de los sistemas operativos Unix impulsó una estandarización de hardware y software en sistemas más enfocados y manejables. Esta homogeneidad permitió a los operadores de computadoras estandarizar sus habilidades y mantener los sistemas de manera similar en cualquier rubro de negocio o empresas. Sin embargo, el hardware del sistema Unix todavía está especializado por el proveedor (IBM POWER, IA64, SUN SPARC y otros), al igual que los distintos Sistemas Operativos Unix. 

Las aplicaciones (ahora en modalidad Cliente-Servidor) se desarrollan pero aún no se transfieren entre proveedores dispares, creando un bloqueo y requiriendo conjuntos de habilidades personalizados para los operadores de computadoras. Creación de Silos de Cómputo.

Arquitecturas Intel-AMD x86/X64 (se consolida la Segunda Plataforma)

En los años noventa hace acto de presencia la plataforma Intel-AMD x86/X64: un conjunto de hardware comercializado que se entrega de manera rápida, económica y estandarizada de la forma en la que se crean los sistemas de hardware en la actualidad. Al optimizar la arquitectura de hardware subyacente, los siguientes sistemas operativos en sistemas Intel-AMD x86/X64 se administran más fácilmente que sus contrapartes. Los componentes y los sistemas completos son intercambiables, las imágenes del Sistema Operativo se transfiere con relativa facilidad y las aplicaciones se desarrollan y migran más rápidamente a nuevos sistemas.

El avance de los sistemas Intel-AMD x86/X64 también hizo que la innovación de hardware supere la demanda de software, donde los sistemas multinúcleo con abundante memoria y almacenamiento quedarían inactivos o subutilizados en algunos momentos, debido a la naturaleza estática del tamaño del sistema. Los servidores Intel-AMD x86/X64 sufrieron su propio éxito y requirieron más innovación a nivel de software para desbloquear la próxima innovación: La Virtualización.

Virtualización de la Arquitectura Intel-AMD x86/X64 (cimientos de la Tercera Plataforma)

Aquí es menester hacer un paréntesis, pues el concepto de "Hipervisor" y por ende "Virtualización", ya había sido creado desde la era de los Mainframes. Pues gracias a ambos era posible poder ejecutar múltiples Cargas de Trabajo en el mismo Hardware.

La Virtualización de la Arquitectura Intel-AMD x86/X64 (como en cualquier otra plataforma) abstrae un sistema operativo de su hardware subyacente, lo que permite que cualquier sistema operativo que ya de por sí se podía ejecutar sobre la Arquitectura Intel-AMD x86/X64, ahora se pueda ejecutar simultáneamente con otros sistemas operativos en el mismo servidor "Bare Metal" (de manera nativa o a metal desnudo). Esto permitió aún más flexibilidad, ahorro de costos y eficiencia, así como portabilidad; ahora las aplicaciones se envían preinstaladas dentro de los “archivos” o imágenes de la máquina virtual. Estos sistemas virtualizados maximizan la densidad del sistema operativo al hardware, reduciendo los costos en el centro de datos y habilitando nuevas formas programáticas para implementar rápidamente nuevas Cargas de Trabajo.

Los sistemas virtualizados aún requerían cierta sobrecarga de mantenimiento y un conjunto de habilidades especializadas para operar y mantener. Con frecuencia las empresas sufrían la complejidad operativa de mantener cientos o incluso miles de máquinas virtuales a escala. Las mejoras, actualizaciones y el mantenimiento del sistema aún requerían una coordinación y planificación cuidadosas y a menudo, interrumpían las operaciones comerciales. Este modelo volvió a cambiar positivamente cuando se introdujeron "Los Contenedores".

Contenedores (consolidación de la Tercera Plataforma)

Los Contenedores son imágenes preempaquetadas de software (Microservicios), que utilizan fracciones de la capacidad informática y de almacenamiento de las máquinas virtuales, que se pueden implementar instantáneamente en cualquier ambiente de ejecución preparado para contenedores (Docker), a través de la automatización y la orquestación (Kubernetes).

Estas pequeñas unidades de cómputo (Microservicios) permitieron a los desarrolladores probar e implementar código rápidamente en cuestión de minutos en lugar de revisar los cambios de software en un repositorio en días, habilitando un ciclo de prueba y compilación de software automatizado que podría simplemente monitorearse, sin requerir grandes esfuerzos para su administración.

Los Contenedores también permitieron subdividir las aplicaciones en "Microservicios" más pequeños, donde no es necesario que una aplicación completa resida en la misma instancia o sistema operativo, sino solo una fracción que podría satisfacer una demanda comercial conocida. Esta capacidad combinada con el modelo operativo de La Nube "paga por lo que usa", permitió a las empresas pagar realmente solo por los servicios que necesitaban, cuando los necesitaban.

Arquitectura Sin Servidor (Serverless)

Atomizando las aplicaciones aún más, la computación Sin Servidor o la “Función como un Servicio” minimizó aún más la huella de los servicios de aplicaciones, al ejecutar solo pequeñas secciones de código a la vez. La computación Sin Servidor permitió a las empresas consumir fracciones de tiempo computacional y almacenamiento mínimo, simplemente ejecutando su código "bajo demanda" y sin la necesidad de poseer, administrar y dar mantenimiento al resto de la infraestructura subyacente.

En cada paso del camino, la potencia informática se mejoró, se hizo más eficiente y acercó las aplicaciones a su entorno operativo deseado siempre procurando obtener el desempeño y rendimiento correcto, satisfaciendo la demanda correcta del cliente, exactamente al costo y escala correctos.

Sin embargo, la informática Sin Servidor no es la única opción para obtener el mejor rendimiento, al menor costo y con la más óptima escalabilidad. Como ya hemos mencionado en este Blog Tecnológico, existe un riesgo inherente al entregar el control completo del hardware a un tercero y simplemente consumir recursos como un servicio. Una organización que pierde el control de sus datos no es un escenario ideal, por lo que existe una clara necesidad de una solución local que brinde los mismos beneficios que ofrece la computación sin servidor, pero sin los riesgos de seguridad y gobernabilidad.

Esa solución alternativa local es la Hiperconvergencia.

Infraestructura Hiperconvergente

La Infraestructura Hiperconvergente es aquella que gracias a La Virtualización de todos los elementos de los sistemas convencionales otrora "definidos por hardware", ahora son definidos por software. La Infraestructura Hiperconvergente (HCI por sus siglas en inglés) incluye como mínimo, recursos de cómputo (procesador y memoria) , almacenamiento y redes definidos por software . 

La Infraestructura Hiperconvergente normalmente se ejecuta en servidores comerciales listos para usar, dando como resultado los Centros de Datos Definidos por Software (SDDC por sus siglas en inglés) que permiten ofrecer a los Usuarios una Infraestructura como un Servicio (IaaS), en modalidad de Nube Privada. 

Algo muy importante a tomar en cuenta en este momento, es que la Infraestructura Hiperconvergente no sustituye ni a La Virtualización ni mucho menos a los Microservicios que vienen aparejados con Los Contenedores. Digamos que más bien aquí gracias a La Virtualización puede existir la Infraestructura Hiperconvergente, mientras que sobre una Infraestructura Hiperconvergente es posible el ejecutar Microservicios en formato de Contenedores.

Aunque se antoja pensar que la Infraestructura Hiperconvergente es el pináculo de las Tecnologías de la Información, recordemos que ésta permite que las empresas puedan gozar de Infraestructura como un Servicio en Nube Privada y Nube Híbrida (en conjunción con la Núbe Pública). Pero estamos muy seguros de que este es un escalón más a ambientes de cómputo cada vez más eficientes, flexibles y bajo demanda.

¿En qué estado se encuentran actualmente sus Tecnologías de la Información?

Cómo Sobrevivir al Apocalipsis Zombie con Microservicios sin Servidor

Reconozcámoslo, administrar servidores puede ser un dolor. La gestión de la capacidad y el escalado son aún peores. Ahora imagina dedicar tu tiempo a Sistemas Operativos durante un apocalipsis zombie: atrinchera la puerta de los comedores de carne con un brazo mientras aplicas un sistema operativo con el otro.

Esto suena como algo sacado de una pesadilla. Por suerte para ti, este no tiene que ser el caso. En AWS, se facilitan más que nunca la creación y el encendido de aplicaciones a escala con potentes servicios administrados, para que podamos centrarnos en su negocio principal, como sobrevivir, mientras manejamos la administración de la infraestructura que nos ayuda a hacerlo.

¡Únete a los "AWS Lambda Signal Corps"!

En el AWS re:Invent en 2015, pusimos a prueba un taller donde los participantes trabajaron en grupos para crear una aplicación de chat sin servidor, para supervivientes del apocalipsis zombie utilizando Amazon S3, Amazon DynamoDB, Amazon API Gateway y AWS Lambda.

Los participantes aprendieron sobre los patrones de diseño de microservicios y las mejores prácticas. Luego extendieron la funcionalidad de la aplicación de chat sin servidor, con varias funcionalidades complementarias como la integración de SMS móvil y la detección de movimiento zombie, utilizando servicios adicionales como Amazon SNS y Amazon Elasticsearch Service.

En esta publicación, mostraremos cómo nuestra aplicación de chat para sobrevivientes incorpora algunos patrones de diseño de microservicios importantes, así cómo también puede potenciar sus aplicaciones de la misma manera con una arquitectura sin servidores.

¿Qué son las arquitecturas sin servidor?

En AWS saben que la administración de la infraestructura puede ser un desafío. También entienden que los clientes prefieren enfocarse en entregar valor a sus negocios. Hay un montón de trabajos pesados ​​indiferenciados para construir y ejecutar aplicaciones, como la instalación de software, la administración de servidores, la coordinación de programas de parches y la ampliación para satisfacer la demanda.

Las arquitecturas sin servidor le permiten construir y ejecutar aplicaciones y servicios sin tener que administrar la infraestructura. Su aplicación aún se ejecuta en los servidores, pero AWS ha hecho toda la administración del servidor para usted. Las arquitecturas sin servidor pueden hacer que sea más fácil construir, administrar y escalar aplicaciones en la nube al eliminar gran parte del trabajo pesado involucrado con la administración del servidor.

Beneficios clave de las arquitecturas sin servidor:

• No hay servidores para administrar: no hay servidores para su aprovisionamiento y administración. AWS ha realizado toda la administración del servidor para usted.
  
• Mayor productividad: ahora puede centrar completamente su atención en la creación de nuevas características y aplicaciones porque se libera de las complejidades de la administración del servidor, lo que le permite iterar más rápido y reducir su tiempo de desarrollo.
  
• Escalado continuo: sus aplicaciones y servicios se escalan automáticamente hacia arriba y hacia abajo según el tamaño de la carga de trabajo.

¿Qué debería esperar aprender en un taller de microservicios Zombie?

El contenido del taller está diseñado para demostrar las mejores prácticas para arquitecturas sin servidor utilizando AWS. En este post discutiremos los siguientes temas:

• ¿Qué servicios son útiles al diseñar una aplicación sin servidor en AWS?
  
• Consideraciones de diseño para mensajería, transformación de datos y lógica empresarial o de nivel de aplicación, al crear microservicios sin servidor.
  
• Las mejores prácticas demostradas en el diseño de la aplicación de chat zombie survivor.
  
• ¡Los siguientes pasos para comenzar a construir sus propios microservicios sin servidor!

Se usaron varios servicios de AWS para diseñar la aplicación "Chat Zombie Survivor". Cada uno de estos servicios es administrado y altamente escalable. Echemos un vistazo rápido a cuáles incorporamos en la arquitectura:

• AWS Lambda le permite ejecutar su código sin aprovisionar o administrar servidores. Simplemente cargue su código (actualmente Node.js, Python o Java) y Lambda se ocupa de todo lo que necesita para ejecutar y escalar su código con alta disponibilidad.
  
  Puede configurar su código para que se active automáticamente desde otros servicios de AWS o llamarlo directamente desde cualquier aplicación web o móvil. Lambda se utiliza para alimentar muchos casos de uso, como aplicaciones de respaldo, tareas administrativas programadas e incluso, grandes cargas de trabajo de datos a través de la integración con otros servicios de AWS como Amazon S3, DynamoDB, Redshift y Kinesis.
  
• El Servicio de Almacenamiento Simple de Amazon (Amazon S3), es nuestro servicio de almacenamiento de objetos que brinda a los desarrolladores y equipos de TI, un almacenamiento seguro, duradero y escalable en la nube.
  
  S3 se utiliza para admitir una amplia variedad de casos de uso y es fácil de usar con una interfaz simple para almacenar y recuperar cualquier cantidad de datos. En el caso de nuestra aplicación de chat para sobrevivientes, incluso se puede usar para alojar sitios web estáticos con soporte CORS y DNS.
  
• Amazon API Gateway facilita la creación de "RESTful API" para sus aplicaciones. API Gateway es escalable y fácil de configurar, lo que le permite crear integraciones con aplicaciones de servicios de fondo, incluido el código que se ejecuta en AWS Lambda, mientras el servicio maneja la escala de sus solicitudes de la API.
  
• Amazon DynamoDB es un servicio de base de datos NoSQL rápido y flexible, para todas las aplicaciones que necesitan una latencia de milisegundos consistente y de un solo dígito en cualquier escala. Es una base de datos en la nube totalmente administrada y es compatible con los modelos de almacenamiento de documentos y valores clave. Su modelo de datos flexible y su rendimiento confiable lo hacen ideal para dispositivos móviles, web, juegos, tecnología publicitaria, IoT y muchas otras aplicaciones.

Descripción general de la aplicación Zombie Survivor Chat

La aplicación "Chat Survivor" representa una arquitectura completamente sin servidor, que ofrece una aplicación de chat de referencia (escrita usando AngularJS) a los participantes del taller, sobre la cual se puede agregar funcionalidad adicional.

Para entregar esta aplicación de chat de línea de base, se les proporciona a los participantes una plantilla de AWS CloudFormation, que activa el ambiente en sus cuentas. El siguiente diagrama representa una arquitectura de alto nivel de los componentes que se inician automáticamente:

• El cubo de Amazon S3 se creó para almacenar los contenidos de la aplicación web estática de la aplicación de chat.
  
• Las funciones de AWS Lambda se crean para servir como el nivel lógico de negocio de back-end, para procesar las lecturas/escrituras de los mensajes de chat.
  
• Los puntos finales API se crean utilizando API Gateway y se asignan a las funciones de Lambda. El método API Gateway POST apunta a una función WriteMessages Lambda. El método GET apunta a una función Lambda GetMessages.
  
• Se aprovisiona una tabla de mensajes DynamoDB para actuar como nuestro almacén de datos para los mensajes de la aplicación de chat.

Con la pila CloudFormation lanzada y los componentes construidos, el resultado final es una aplicación de chat totalmente funcional alojada en S3, que utiliza API Gateway y Lambda para procesar solicitudes, y DynamoDB como persistencia para nuestros mensajes de chat.

Con esta aplicación de referencia, los participantes se unen en equipos para desarrollar funcionalidades adicionales, que incluyen lo siguiente:

• Integración de SMS/MMS a través de Twilio. Enviar mensajes para chatear desde SMS.
  
• Detección del sensor de movimiento de zombies cercanos con Amazon SNS e Intel® Edison y Grove IoT Starter Kit. AWS proporciona un sensor de movimiento compartido para el taller y usted consume sus mensajes del SNS.
  
• Ayuda con botón de pánico con IoT.
  
• Integración con Slack para mensajes desde otra plataforma.
  
• Indicador de escritura para ver qué sobrevivientes están escribiendo.
  
• Análisis sin servidor de mensajes de chat utilizando Amazon Elasticsearch Service (Amazon ES).
  
• ¡Cualquier otra funcionalidad en la que los participantes puedan pensar!

Como parte del taller, AWS brinda orientación para la mayoría de estas tareas. Con estos complementos, la arquitectura del sistema de chat comienza a parecer un poco más sofisticada, como se muestra a continuación:

Inquilinos arquitectónicos del Chat de supervivientes sin servidor

En su mayor parte, los patrones de diseño que veríamos en un entorno tradicional de servidor, si también lo encontrarás en un entorno sin servidor. No hay sorpresas allí. Dicho esto, nunca está de más repasar las mejores prácticas mientras se aprenden otras nuevas. Repasemos algunos patrones clave que incorporamos en nuestra aplicación sin servidor.

El desacoplamiento es primordial

En la aplicación de "Chat Survivor", las funciones de Lambda sirven como nuestro nivel para la lógica de negocios. Dado que los usuarios interactúan con Lambda en el nivel de función, le sirve para dividir la lógica en funciones separadas, tanto como sea posible para que pueda escalar el nivel lógico independientemente de la fuente y los destinos en los que se sirve.

Como verá en el diagrama de arquitectura en la sección anterior, la aplicación tiene funciones Lambda separadas para el servicio de chat, el servicio de búsqueda, el servicio de indicadores, etc.

El desacoplamiento también se incorpora mediante el uso de API Gateway, que expone nuestra lógica de back-end a través de una interfaz RESTful unificada. Este modelo nos permite diseñar nuestra lógica de back-end con lenguajes de programación, sistemas o canales de comunicación potencialmente diferentes, a la vez que mantenemos a los puntos finales solicitantes al margen de la implementación.

Utilice este patrón y no llorará solicitando ayuda cuando necesite escalar, actualizar, agregar o eliminar piezas de su entorno.

Separe sus almacenes de datos

Trate cada almacén de datos como un componente de aplicación aislado del servicio al que da soporte. Un inconveniente común cuando se siguen arquitecturas de microservicios es olvidarse de la capa de datos.

Al mantener los almacenes de datos específicos para el servicio que admiten, puede administrar mejor los recursos necesarios en la capa de datos específicamente para ese servicio. Este es el verdadero valor en microservicios.

En la aplicación "Chat Survivor", esta práctica se ilustra con las tablas DynamoDB Activity y Messages. El servicio indicador de actividad tiene su propio almacén de datos (tabla de actividades) mientras que el servicio de chat tiene el suyo (mensajes).

Estas tablas pueden escalarse independientemente junto con sus respectivos servicios. Este escenario también representa un buen ejemplo de statefuless. La implementación del complemento de indicador de conversación utiliza DynamoDB a través de la tabla de Actividad, para rastrear la información de estado acerca de qué usuarios están hablando.

Recuerde que muchos de los beneficios de los microservicios se pierden, si los componentes todavía están pegados en la capa de datos al final, creando un denominador común desordenado para escalar.

Aproveche las transformaciones de datos

Al diseñar un servicio, la transformación de datos y la compatibilidad son componentes importantes.

¿Cómo manejará las entradas de muchos clientes, usuarios y sistemas diferentes para su servicio? ¿Ejecutará diferentes sabores de su entorno para que se correspondan con los diferentes estándares de solicitud entrante? ¡Absolutamente no!

Con API Gateway, la transformación de datos se vuelve significativamente más fácil a través de modelos incorporados y plantillas de asignación. Con estas características, puede construir transformación de datos y lógica de mapeo en la capa API para solicitudes y respuestas.

Esto resulta en menos trabajo para usted, ya que API Gateway es un servicio administrado. En el caso de nuestra aplicación de chat para sobrevivientes, AWS Lambda y nuestra aplicación de chat para sobrevivientes requieren JSON, mientras que a Twilio le gusta XML para la integración de SMS. Este tipo de transformación se puede descargar a API Gateway, dejándolo con un nivel empresarial más limpio y una cosa menos para diseñar.

Use API Gateway como su interfaz y Lambda como su implementación de back-end común. API Gateway utiliza Apache Velocity Template Language (VTL) y JSONPath para lógica de transformación.

Por supuesto, hay que considerar una compensación, ya que se podría manejar mucha lógica de transformación en su nivel lógico de negocios (Lambda). Pero, ¿por qué administrarlo usted mismo en el código de la aplicación, cuando puede manejarlo de forma transparente en un servicio completamente administrado a través de API Gateway?

Aquí hay algunas cosas a tener en cuenta al manejar transformaciones usando API Gateway y Lambda:

• Transformar primero; luego llame a su lógica común de back-end.
  
• Utilice las transformaciones VTL de puerta de enlace de API primero cuando sea posible.
  
• Use Lambda para preprocesar datos de formas que VTL no puede.

Seguridad a través del aislamiento del servicio y el mínimo privilegio

Como recomendación general al diseñar sus servicios, siempre utilice los privilegios mínimos y aísle los componentes de su aplicación para proporcionar control sobre el acceso. En la aplicación "Chat Survivor", se utiliza un modelo basado en permisos a través de AWS Identity and Access Management (IAM).

IAM está integrado en todos los servicios de la plataforma AWS y brinda la capacidad para que los servicios y las aplicaciones, asuman roles con conjuntos de permisos estrictos para realizar sus necesidades de acceso con menos privilegios.

Junto con los controles de acceso, debe implementar el registro de auditoría y acceso para proporcionar la mejor visibilidad en sus microservicios. Esto es más fácil con Amazon CloudWatch Logs y AWS CloudTrail.

CloudTrail habilita la capacidad de auditoría de las llamadas API realizadas en la plataforma, mientras que CloudWatch Logs le permite enviar datos de registro personalizados a AWS.

Aunque nuestra implementación de Amazon Elasticsearch en el chat de supervivientes se utiliza para analizar mensajes de chat, puede enviar fácilmente sus datos de registro y realizar análisis en su aplicación. Puede incorporar las mejores prácticas de seguridad de las siguientes maneras con la aplicación de chat de supervivientes:

• Cada función de Lambda debe tener un rol de IAM para acceder solo a los recursos que necesita. Por ejemplo, la función GetMessages puede leer de la tabla Messages mientras que la función WriteMessages puede escribir en ella.
  
  Pero no pueden acceder a la tabla de Actividades que se usa para rastrear quién está escribiendo para el servicio de indicadores.
  
• Cada punto final de la Pasarela API debe tener permisos IAM para ejecutar la(s) función(es) Lambda a la que está vinculado. Este modelo asegura que Lambda solo se ejecuta desde el principio que está permitido ejecutarlo, en este caso el método API Gateway que desencadena la función back-end.
  
• DynamoDB requiere permisos de lectura/escritura a través de IAM, lo que limita la actividad anónima de la base de datos.
  
• Utilice AWS CloudTrail para auditar la actividad API en la plataforma y entre los diversos servicios. Esto proporciona trazabilidad, especialmente para ver quién está invocando sus funciones de Lambda.
  
• Diseñe las funciones de Lambda para publicar resultados significativos, ya que estos se registran en los registros de CloudWatch en su nombre.

Para su información, en nuestra aplicación, permitimos el acceso anónimo a los puntos finales de la Pasarela API de chat. Queremos alentar a todos los sobrevivientes a conectarse al servicio sin registro previo y comenzar a comunicarse.

Supusimos que los zombis no son lo suficientemente inteligentes como para hackear nuestros canales de comunicación. Hasta el apocalipsis sin embargo, manténgase fiel a las claves de la API y la autorización con firmas, ¡que es compatible con API Gateway!

No abandonemos Prueba/Desarrollo

Al desarrollar con microservicios, puede aprovechar entornos de prueba y desarrollo independientes como parte del ciclo de vida de la implementación. AWS proporciona varias funciones para ayudarlo a continuar creando aplicaciones en la misma trayectoria que antes, incluyendo:

• Versiones y alias de la función Lambda: utilice estas funciones para versionar sus funciones en base y con apego a las etapas de implementación como desarrollo, prueba, puesta en escena, preproducción, etc. O tal vez realice cambios en una función Lambda existente en producción sin tiempo de inactividad.
  
• Planos del servicio Lambda: Lambda viene con docenas de planos para que pueda comenzar con el código preescrito que puede usar como esqueleto, o como una solución completamente funcional para completar su back-end sin servidor. Estos incluyen planos con enlaces a Slack, S3, DynamoDB y más.
  
• Etapas de implementación de API Gateway: Similar a la versión de Lambda, esta característica le permite configurar etapas API separadas, junto con variables de etapa únicas y versiones de implementación dentro de cada etapa. Esto le permite probar su API con los mismos o diferentes back-ends, mientras avanza a través de los cambios que realiza en la capa API.
  
• Integración de Maquetas con API Gateway: configure las respuestas ficticias que los desarrolladores pueden usar, para probar su código mientras se desarrolla la verdadera implementación de su API. Las integraciones simuladas (maquetas) hacen que sea más rápido iterar a través de la porción API de un ciclo de vida de desarrollo, mediante la racionalización de piezas que solían ser muy secuenciales y/o en cascada.

¡Manténgase atento a las actualizaciones!

Asegúrese de estar atento al repositorio de AWS GitHub. Aunque no cubrimos cada componente de la aplicación de "Chat Survivor" en esta publicación, ¡vamos a implementar este taller y código pronto para que pueda iniciarse por su cuenta! Esté atento a los Talleres Zombies que se acercan a su ciudad, o designe su ciudad para un taller aquí.

Los microservicios avanzan: reinventando la escalabilidad

Hoy la promesa de los microservicios para la empresa es la siguiente: si las partes de una aplicación se pueden organizar por separado, en cualquier plataforma en la nube o plataforma local que tenga a mano, entonces podría optimizar continuamente esa aplicación por su costo.

Teóricamente, un Sistema de Administración de Ceontenido (CMS por sus siglas en inglés), o cualquiera que sea la plataforma en la que se encuentre el contenido orientado al cliente, podría escalar ligeramente cuando el tráfico aumente levemente.

Incluso podría reducirse durante un feriado o un fin de semana, o en cualquier período estacional o regular que normalmente vea un tráfico menor.

Idealmente, podríamos automatizar el proceso de escalado, en lugar de convocar una configuración de emergencia y ejecutar una decisión crítica de programación cada vez que su contenido tenga éxito.

Esa es la teoría,  hoy. Pero algo muy grande tiene que cambiar para que esto sea factible: la arquitectura subyacente de su centro de datos, ya sea que su organización lo posea, lo arriende o lo ubique en una nube pública.

El sabor de los microservicios

Por supuesto, los vendedores en el negocio de la infraestructura estarían más que dispuestos a ayudar. Los principales nombres en el campo de la tecnología están muy contentos de adquirir dichos negocios y obtener una parte considerable de los ingresos de estas transiciones. Pero no nos engañemos ignorando el hecho de que el viaje de aquí para allá sería monumental.

Por lo tanto, los proveedores están buscando una manera de dar a las empresas una muestra de los microservicios o en ciertos casos, el sabor de algo que sabe lo suficientemente cerca de los microservicios por ahora, en un esfuerzo por construir un mercado antes de establecer una plataforma certificable para de hecho, abandona aplicaciones monolíticas y migra a algo similar a lo que usa Netflix. Sí. Netflix.

El analista de Forrester Randy Heffner contó una historia sobre un cliente que le dijo: "Cuando vi algo en la arquitectura de Etsy y lo que hay detrás o algo en Amazon, fue como, ¡oh Dios mío, eso está más allá de nosotros! ¡No podemos hacer eso!

"Pero aquí hay algo que es como, '¡Ah, lo entiendo! Y veo cómo puedo estar invirtiendo en eso, de una manera que esté en línea con los beneficios comerciales, no solo como una inversión en la gloria arquitectónica ".

Microservicios de bricolaje

Ejemplo N° 1: "Cuando toma las cincuenta cosas de Netflix en su tecnología...", dijo Richard Li, CEO y fundador de la startup con sede en Boston Datawire.io, "...y trata de descubrir cuáles son las cinco cosas con las que necesita comenzar, no es completamente obvio".

Datawire es una Plataforma como un Servicio (PaaS por sus siglas en inglés) que admite un modelo de desarrollo gradual para las características de una aplicación en etapas incrementales o incluso aleatorias.

Dado que una empresa puede desarrollar múltiples aplicaciones web orientadas a los clientes que en su mayoría hacen lo mismo, con máscaras y contenidos ligeramente diferentes, Datawire sugiere que los elementos comunes se creen primero y se integren con la implementación específica que se realice más adelante.

"Tenemos un producto de código abierto y gratuito que le permite comenzar a construir microservicios muy rápidamente...", dijo Li, "...de una manera totalmente compatible con su tecnología existente". Por lo tanto, ofrecemos un camino de transición muy sencillo para la adopción de microservicios ".

Convergencia a través de la divergencia

Ejemplo N° 2: El verano pasado, el proveedor de grandes plataformas de datos MapR presentó lo que llamó una plataforma de datos convergentes, que describe como una plataforma de microservicios para soportar múltiples tipos de fuentes de datos: bases de datos, almacenes de datos, flujos de datos.

El elemento de microservicios entra en juego en el lado del servidor, como un sistema que expone su funcionalidad a los desarrolladores que usan una Interfaz de Programación de Aplicaciones (API por sus siglas en inglés) independiente del proveedor.

De esta forma, una aplicación móvil o un front-end de CMS puede tratar los datos de una manera no específica, independiente del proveedor, mientras que la plataforma puede escalar según sea necesario para facilitar dichas solicitudes.

"Toda nuestra complejidad en la ubicación de los datos está a cargo de nuestra plataforma de datos convergentes", dijo el vicepresidente senior de MapR, Jack Norris, a CMSWire. "Y los microservicios mismos están conectados a través de este marco impulsado por eventos".

En otras palabras, el marco de back-end no está "casado" con ningún mecanismo de plataforma de datos. Más bien, se sienta y espera una señal y responde a ella, ya sea que la señal provenga de SQL Server o Cassandra o un componente de Hadoop.

Desde la perspectiva de un desarrollador, la nueva plataforma MapR invierte la pirámide proverbial, por lo que el data store ya no es un "big data" sino un único "punto de montaje" pequeño, un punto de contacto para el intercambio de datos con lo que está detrás. La aplicación del cliente o la aplicación web no necesita saber, o preocuparse, qué tan "grandes" pueden ser esos datos.

Son microservicios, al menos en un sentido. La plataforma de MapR allana el camino para un eventual sistema de back-end totalmente escalable; y apunta en la dirección general de un abandono del viejo monolito de datos.

Sin servidor

El ejemplo N° 3 involucra un concepto emergente del mundo del desarrollo de software que ha sido impulsado por los proveedores empresariales en los últimos días: la llamada arquitectura sin servidor.

No es realmente sin servidor en absoluto. Más bien es una forma de programar una función diseñada para ser distribuida a través de la Web, de tal manera que donde esa función es, o lo que está cumpliendo esa función, no tiene que ser dirigida por el programador. Un ejemplo es AWS Lambda, una plataforma de Amazon que efectivamente procesa el código sin formato.

Por supuesto si usted no es el programador, ¿cuál es el gran beneficio para usted? Rápidamente los proveedores de servicios han inventado una respuesta: -"la arquitectura Serverless es una forma de servir a la arquitectura de microservicios en "nuggets" o pepitas del tamaño de un bocado."-

Si recuerda el viejo "Hagamos un trato", donde Monty Hall abriría una colorida cortina para revelar una caja brillante y cerrada, o esa famosa "Catafixia" de Javier López "Chabelo", se entiende.

Pero al yuxtaponer estas dos consignas, ¿los proveedores de servicios realmente excluyen la porción de microservicios que le da su propuesta de valor total, es decir, los beneficios culturales y comerciales?

"Microservicios consiste en separar las preocupaciones", dijo Brandon Philips, CTO de CoreOS, "y permitir que los equipos individuales se centren en problemas específicos". CoreOS produce una plataforma basada en contenedores que compite contra Docker, llamada Rkt (se pronuncia "Rocket").

En una arquitectura estándar sin servidor como Lambda, explicó Philips, el código se distribuye al servidor (sí, hay un servidor en sistemas sin servidor) y se olvida su metodología de implementación.

En un entorno típico de microservicios por el contrario, todos los servidores son orquestados cuidadosa y sistemáticamente. Específicamente en el caso de CoreOS por un componente llamado Tectónico. Es esta orquestación y la necesidad de coordinación lo que ayuda a reunir a los equipos de desarrollo con los equipos de operaciones (DevOps).

Nación opinión

Mientras tanto, la modalidad "sin servidor" tiende a concentrarse en el trabajo principal de trasladar la lógica comercial a la producción, añadió Philips, haciéndolo más "obstinado" que los microservicios puros, en un buen sentido.

Por ejemplo, una plataforma sin servidor tiende a escalar automáticamente la implementación y distribución de un servicio, en función de las "solicitudes efímeras" que recibe (como una solicitud de carga de página). Tiene una "opinión" sobre cómo hacer eso, en lugar de instrucciones o automatización resueltas de antemano.

"Con microservicios", dijo Philips, "todavía se tiene el control de cómo esa aplicación termina siendo desarrollada e implementada". Por lo tanto, existe una filosofía general sobre los microservicios en su conjunto, que bien podría sacrificarse cuando se divide en partes, o incluso se canjee por una por completo diferente.

La filosofía de microservicios merece discusión: un ajuste de actitud completo que podría reorientar a su equipo de desarrollo lejos de los monolitos de marca como su CMS actual, hacia las funciones individuales orientadas al cliente que sus activos de TI proporcionan para ellos.

El costo de adoptar esa filosofía es bastante simple: entregue su infraestructura tal como la conoce hoy. Es ese costo lo que hace que la opción del "tamaño de un bocado" se vea mejor y mejor.

En conclusión, microservicios es ese nuevo "cómo" para los ambientes de desarrollo y operación de las aplicaciones. Los microservicios ya son esa piedra angular que, en conjunto con Contenedores, Virtualización, Plataforma como un Servicio, Administración Basada en Políticas y Automatización de los Centros de Datos Definidos por Software, se están posicionando en ambientes On-Premise, Nube Privada y Nube Pública.

¿Ya cuenta Usted con microservicios trabajando para Usted, su empresa o su organización?

Oportunidades del sector TI para 2018, según Red Hat

El 2018 está aquí. En esta ocasión son los líderes indiscutibles del Código Abierto, Red Hat, los que nos dan sus predicciones de lo que para estos doce meses, será lo que ya es o lo que vendrá a muy corto plazo.

Así pues, Red Hat presenta un análisis con 12 oportunidades que las empresas deben tener en cuenta en los próximos meses si desean desarrollar una estrategia empresarial donde la tecnología sea el elemento principal de los procesos.

1. Machine learning e Inteligencia Artificial

“El rápido crecimiento en el machine learning (aprendizaje automático) continuará a medida que las empresas se esfuerzan por obtener el mayor valor comercial y la ventaja competitiva de sus datos. A medida que el marchine learning se popularice, veremos un número creciente de mercados de datos a medida que los diferentes equipos interpreten los datos del data lake de forma diferente y generen nuevos datos desde esa perspectiva”, asegura Kim Palko, Principal Product Manager, Red Hat JBoss Middleware.

“En el espacio de la inteligencia artificial y el machine learning, en 2018 veremos el surgimiento de las aplicaciones inteligente. Una sorpresa del 2017 ha sido la constatación de que, si bien estas aplicaciones están comenzando a ser más habituales, en realidad ya están entre nosotros y solo van a seguir aumentando su presencia en nuestros procesos de trabajo. También en 2018 habrá una adopción empresarial generalizada de un flujo de trabajo estándar para la desarrollo de aplicaciones de inteligencia artificial. Esto continuará impulsando las aplicaciones habilitadas para IA hacia modelos dominantes”, añade Matthew Farrellee, Emerging Technology & Strategy, CTO Office de Red Hat.

2. Bases de Datos

“Habrá un enfoque renovado en cuanto a la seguridad de los datos, particularmente en la nube pública, impulsado por el Reglamento General de Protección de Datos de la Unión Europea (GDPR). A medida que el volumen de datos continúa aumentando, estimulados en parte por los datos generados por el Internet de las cosas, las empresas continuarán trasladando más datos a la nube para aprovechar los beneficios de la escalabilidad, la recuperación ante desastres, la flexibilidad, etc., y este movimiento requerirá más garantías de seguridad”, indica Kim Palko, Principal Product Manager de Red Hat JBoss Middleware.

3. DevOps

“Después de años de publicidad y cobertura positiva, veremos una serie de ejemplos de alto perfil de “fallos DevOps” que tendrán dos efectos paralelos. En algunas organizaciones, habrá un enfriamiento y una reevaluación de la emoción inicial. Sin embargo, las organizaciones que tengan una visión más avanzada verán estos fallos como experiencias de aprendizaje y tomarán más en serio los cambios en la cultura y el proceso, así como los requisitos sobre plataformas subyacentes y arquitecturas de software necesarias para beneficiarse de DevOps. Los vendedores que puedan trabajar con sus clientes en todo este espectro de necesidades se beneficiarán”, asegura Stephanos Bacon, Senior Director, Portfolio Strategy de Red Hat.

4. Virtualización de Servidores

“En 2018, esperamos ver el mercado de soluciones de virtualización interrumpido, ya que los clientes estarán menos dispuestos a pagar un suplemento por la virtualización y esperan que sea parte de la infraestructura que actualmente ejecutan o que planean ejecutar. La automatización, administración y coordinador de despliegues de aplicaciones basadas en la nube, remotas y en local también se convertirán en un imperativo comercial para las empresas. Veremos que los usuarios con aplicaciones heredadas de Modo 1 cambiarán algunas cargas de trabajo existentes, así como nuevas inversiones de desarrollo, a las infraestructuras de Modo 2, piense en VM híbridas que se ejecute dentro de contenedores”, indica Rob Young, manager, Virtualization Product and Strategy de Red Hat.

“Los contenedores serán protagonistas en 2018, y las máquinas virtuales que se ejecutan en contenedores ganarán impulso en el nuevo año a medida que Kubernetes continúe evolucionando. Sin embargo, es importante recordar que la virtualización y los contenedores no son competitivos, sino que se complementan entre sí. Continuaremos viendo la gran mayoría de las infraestructuras contenerizadas operando en hipervisores, y los primeros usuarios fusionarán los dos con Kubernetes”, añade Gunnar Hellekson, Director, Product Management, Linux and Virtualization de Red Hat.

5. Movilidad

“En 2018, espero que veamos empresas que adopten por completo la convergencia de la inteligencia artificial, los dispositivos móviles y el IoT. En muchos aspectos, la tecnología móvil es la más madura y muchas de estas organizaciones encontrarán que se enfrentan a desafíos similares en el desarrollo de aplicaciones para IoT e IA, como lo hicieron con los dispositivos móviles, como la integración y la seguridad. Muchas de las lecciones aprendidas con dispositivos móviles serán valiosas en términos de ayudar a las organizaciones a reconocer y superar los desafíos más rápidamente”, comenta Clare Grant, General Manager, Mobile de Red Hat.

6. Internet de las Cosas (IoT)

“En mi opinión, el mayor hecho en 2017 fue que el IoT alcanzó un pico publicitario, dando paso a nuevos ciclos de sobreexpectación para machine learning (en realidad, una rama de IoT) y para la inteligencia artificial (un área temática familiar y que requiere de datos de IoT como combustible para su inteligencia). Hemos visto una combinación de varias compañías que han realizado grandes inversiones en IoT, mientras que otras están reduciendo o reorganizando sus equipos de IoT. Esta combinación de inversiones significa que estamos en un punto de inflexión. Para el IoT, esto significa que ahora estamos en un punto donde los proyectos tienen que entregar resultados. Los proveedores de IoT invirtieron antes de la demanda, con todo tipo de reclamos. Con más oferta en el sector que demanda, veremos algunos jugadores abandonar o cambiar su enfoque”, opina James Kirkland, Chief Architect, IoT de Red Hat.

¿Qué podemos esperar del IoT en 2018?

– Resultados cuantificables. En 2018, escucharemos a las organizaciones que han implementado IoT (los primeros en adoptar), proyectos reales y que han obtenido un ROI demostrable. Hablarán de resultados exitosos y mejoras en los procesos. Hasta ahora, la mayoría de los beneficios expresados han sido teóricos, basados en los resultados deseados más que en los éxitos mensurables.

– Necesidad de un ecosistema. Los usuarios están aprendiendo que el IoT no es una tecnología; es una solución compleja de varias partes que no puede ser entregada por un único proveedor. Los proveedores con ofertas de IoT que han tratado de ir solos y no se han comprometido con socios complementarios están teniendo problemas. Se espera que los usuarios con proyectos que dependen de un solo proveedor continúen experimentando los efectos negativos del bloqueo del proveedor.

– Tenemos los datos. Ahora necesitamos el conocimiento. Muchas de las organizaciones que han comenzado proyectos de IoT descubren que no están seguros de cómo obtener valor de los datos que están recopilando. Han desarrollado la infraestructura y están recopilando datos, pero no tienen la tecnología adecuada, las habilidades (científicos de datos, por ejemplo) o el conocimiento para completar todo el ciclo de vida de la información.

– Seguir las necesidades del negocio. En el horizonte, veremos aumentar el interés en el IoT, especialmente en las industrias que necesitan reducir el costo de sus negocios. Por ejemplo, los precios más bajos de la energía están impulsando la mayor demanda de soluciones IoT en la industria del petróleo y el gas. Además, los negocios tradicionalmente de bajo margen, como el minorista, seguirán buscando formas de aumentar la eficiencia y reinventar la experiencia del cliente para aumentar la demanda. Las empresas con grandes bienes de capital que requieren mantenimiento también buscan mejoras en los procesos mediante el mantenimiento predictivo y las soluciones de aprendizaje automático.

– Transferencia de conocimiento humano al machine learning. Se verán cada vez más casos prácticos en los que el conocimiento humano se utiliza para crear modelos predictivos. Por ejemplo, un operador de maquinaria que ha sido responsable de los equipos durante muchos años puede identificar el sonido único generado por cada parte de la maquinaria. Esos identificadores de audio pueden agregarse a los modelos predictivos y usarse para activar alertas de que una parte está a punto de fallar.

– Nuevos modelos económicos. La entrega de los servicios de IoT tendrá una nueva dimensión a medida que cambien las expectativas de seguimiento, facturación, pago y contabilidad de las transacciones a medida que crezca la cantidad de dispositivos conectados.

– Seguridad y privacidad. Con cada nuevo dispositivo IoT, los vectores de ataque aumentan. Deje de buscar la perfecta seguridad (ningún proveedor ofrece una solución única) y adopte una defensa en profundidad, una estrategia de seguridad en capas para enfrentar las amenazas. Los problemas de privacidad, como el uso de tecnología de reconocimiento facial por parte de los minoristas para identificar y orientar las ofertas, seguirán aumentando.

7. Java

“Este ha sido un gran año para Java, con varios desarrollos importantes que contribuyen a la evolución continua de la tecnología. El evento más notable en 2017 fue el anuncio de Oracle de abrir más completamente Java EE moviéndolo a una base de código abierto, y el posterior anuncio de que había seleccionado a Eclipse Foundation para alojar la iniciativa como un proyecto de alto nivel llamado Eclipse Enterprise for Java (EE4J). Avanzando desde Java EE 8 (lanzado en septiembre y que ha sido otro desarrollo notable de Java este año), se espera que continúe el desarrollo de la plataforma bajo EE4J. Además, vimos un progreso continuo en el proyecto MicroProfile con las versiones v1.1 y 1.2 en 2017, avanzando aún más la evolución de Java empresarial para el desarrollo de microservicios.”, asegura Mark Little, Vice President, Engineering, Red Hat.

“Los esfuerzos alrededor de EE4J representan un cambio monumental y no sucederán de la noche a la mañana. Todavía hay muchos detalles que deben ser resueltos, sin embargo, el ritmo de desarrollo de la plataforma actualmente en comparación con el de hace un año es una como el día y noche. La comunidad ha sido revitalizada por la perspectiva de estos cambios y las partes interesadas clave participan activamente. Es un signo alentador, y anticipo que esta energía continuará cobrando impulso a medida que avanzamos hacia 2018. Red Hat ha sido durante mucho tiempo un defensor de una empresa más abierta, y estábamos desde el comienzo en conversaciones con Oracle, junto con compañeros de IBM. Juntos, y con la comunidad Java EE en general, creo que veremos que Java seguirá siendo una tecnología dominante en la empresa en los próximos años.”

8. Cloud

“En 2018, el debate sobre la nube híbrida ganarán en sofisticación en torno a la portabilidad de las cargas de trabajo. Tenemos muchas herramientas útiles en cuanto a herramientas de portabilidad: almacenamiento definido por software, administración de nube híbrida, estandarización de contenedores a través de Open Container Initiative, amplio soporte para Kubernetes y, por supuesto, Linux. Sin embargo, también debemos apreciar que los grandes conjuntos de datos creados y utilizados por el IoT, EL Machine Learning y otras cargas de trabajo nuevas pueden limitar la portabilidad “sin interrupciones”. Comprender las mejores arquitecturas y prácticas para los distintos tipos de aplicaciones emergentes debe ser una prioridad”, indica Gordon Haff, Technology Evangelist, Red Hat.

9. Contenedores en OpenStack (Cloud)


“El mundo de los contenedores y OpenStack se combinarán: una mayor colaboración entre OpenStack, Kubernetes y otros proyectos clave de open source, impulsados por la necesidad del cliente de llegar a un tejido unificado para contenedores físicos y virtuales, lo que traerá beneficios al reducir las redundancias y aprovechar el ecosistema”, comenta Radhesh Balakrishnan, General Manager, OpenStack, Red Hat.

10. La Nube Híbrida se convertirá en norma


“En 2018, los esfuerzos de la nube privada ganarán un impulso adicional impulsado por los esfuerzos de modernización de la aplicación, lo que dará lugar a que la “nube híbrida por defecto” se convierta en el procedimiento operativo estándar para las empresas”, asegura Radhesh Balakrishnan, General Manager, OpenStack, Red Hat.

11. El futuro de las Telco: Network Function Virtualization (NFV)

Veremos que la virtualización de funciones de red (NFV) se moverá hacia el Edge en 2018. Habiendo probado el valor en los sistemas centrales, el esfuerzo de NFV comenzará a centrarse en los casos de uso Edge Computing, ayudado por la comunidad de open source para abordar la latencia, el rendimiento y requisitos de manejabilidad, indica Radhesh Balakrishnan, General Manager, OpenStack, Red Hat.

12. Seguridad

“Las empresas comenzarán a prestar más atención sobre la ubicación de las cargas de trabajo y qué controles tienen sobre ellas. Esos pueden ser contractuales (SLA), arquitectónicos (colocación) o tecnológicos (controles de software o hardware). Los ejemplos podrían ser: SLA y política de privacidad, o verificación de antecedentes de los empleados (contractuales); Políticas de colocación de cargas de trabajo de Openstack u Openshift o requisitos de autenticación API (arquitectónicos); uso de HSM o entornos de ejecución de confianza como SGX o SEV (tecnológico). Ninguno de estos es suficiente por sí solo, y no sirven de nada a menos que estén coordinados. El camino a seguir es la asignación de la gobernanza a las políticas, y su incorporación a los procesos, pero incluso esto es insuficiente a menos que se pueda registrar, supervisar y auditar lo que realmente está sucediendo”.

“Los departamentos de seguridad de TI van a pasar menos tiempo diciendo “no” (y siendo ineficaces para detener los despliegues que seguirán adelante de todos modos), y más tiempo aprendiendo cómo explicar el riesgo a los dueños de negocios, desarrolladores y operaciones. Ser “nadie” no ayuda a los departamentos de seguridad ni a aquellos con quienes trabajan. Las empresas quieren opciones como “podríamos cerrar los servidores y estar totalmente seguros o podríamos correr al 75% de manera eficiente, con un uno por ciento de posibilidades de perder algunos datos”. Las herramientas para este nivel de detalle no siempre están disponibles, pero tenemos que empezar a pensar sobre lo que realmente es útil: aunque fuimos entrenados que “fail-closed es a prueba de fallos”, un sistema cerrado es un sistema inútil para el negocio. Del mismo modo, es más probable que un desarrollador acepte controles de seguridad si decimos “¿Qué pasaría si alguien usara incorrectamente esta interfaz y corrompiera sus datos?”, en lugar de “debes usar autenticación y autorización en esta API o no se podrá iniciar”, comenta Mike Bursell, Chief Security Architect, Red Hat.

En conclusión, una vez más Tercera Plataforma, Cuarta Revolución Industrial y su hija dilecta la Transformación Digital, sean en su totalidad o algunos de sus componentes fundamentales, se consolidan en el mundo cada vez más evolucionado de las Tecnologías de la Información.

¿Cuál de estas Doce Oportunidades ya está implementado o en plena implementación dentro de su Organización?

Predicciones de VMware para este 2018...

A unas horas de haber comenzado el año 2018, vale la pena escuchar, poner atención, leer predicciones para este año nuevo, de boca de los más influyentes fabricantes de la industria de las Tecnologías de la Información.

Para comenzar, esta nota es una traducción de un artículo colocado en el Blog "RADIUS" de la empresa VMware, cuyo autor es Lee Caswell, vicepresidente de la unidad de negocio de productos para almacenamiento y disponibilidad en VMware.

Comienza la transcripción:

---

La transformación digital no es solo una palabra de moda de marketing. Es una necesidad competitiva que incluso las compañías más establecidas están adoptando agresivamente: tomemos por ejemplo a General Electric con un nuevo enfoque en el software. Ahora miremos a Tesla reinventando autos con tecnología o veamos cómo los servicios financieros se están rehaciendo para los inversores del milenio.

La Infraestructura Hiperconvergente  (HCI por sus siglas en inglés) nos da a entender que el año 2018 no será lo mismo.

HCI impulsará cambios de larga duración en las Tecnologías de la Información (TI) en general, los servidores y las arquitecturas de almacenamiento. En 2018 veremos cómo estos cambios son adoptados más rápidamente por las empresas que están enzarzadas en batallas competitivas, donde HCI es la última herramienta tecnológica para acelerar la capacidad de respuesta a un entorno cambiante. Las compañías inteligentes verán a HCI como una herramienta esencial donde las TI se convierten en un servicio para las aplicaciones, en lugar de su amo.

La adopción masiva de la (HCI), liderada por VMware vSAN, está impulsando cambios trascendentales en las organizaciones de TI de todos los tamaños. A medida que los usuarios demandan que las TI ofrezcan un nuevo nivel de agilidad de adaptación rápida, los propietarios están  recurriendo a HCI para reducir los ciclos de planificación con infraestructura lista para desarrolladores (DevOps) que está disponible "a la carta" en aplicaciones tradicionales y nativas de la nube. Perfectamente disponible desde el borde hasta el núcleo de la nube.

Aquí hay tres tendencias específicas que esperamos ver a medida que la adopción de HCI avanza a un ritmo que no se había visto desde los primeros días de la virtualización. Recomendamos buscar estos cambios en el personal de TI, en las arquitecturas de servidores y los sistemas de almacenamiento, ya que la mayor parte de las implementaciones de TI cambia de la arquitectura de tres niveles (silos), a la administración flexible basada en políticas que ofrece HCI.

1. HCI consolidará al personal de TI

HCI consolida la administración de almacenamiento y computación para que TI pueda reconsiderar cómo organizarse para ser más receptivo con los propietarios de las aplicaciones. Para las organizaciones que tienen equipos de cómputo y almacenamiento por separado, HCI ofrece la oportunidad de combinar equipos para simplificar la administración, donde la capacidad de almacenamiento y el rendimiento son simplemente otro atributo de aplicaciones basado en políticas.

En 2018, esperamos ver a las organizaciones de TI fusionar los equipos de almacenamiento y cómputo en respuesta a la adopción de HCI, no para reducir los empleos o costos de TI, sino para mejorar la capacidad de respuesta al ritmo acelerado de los cambios en las aplicaciones que caracterizan los modelos comerciales actuales centrados en la tecnología digital. Los equipos de TI hiperconfigurados recién formados se centrarán en las necesidades exactas de las aplicaciones que se ejecutan en una máquina virtual o contenedor, para que las aplicaciones puedan aprovisionarse más rápidamente y/o cambiar más fácilmente, para cumplir dinámicamente con las necesidades de negocio y depurarse centralmente desde una única consola de administración.

2. El resurgimiento de los servidores en rack

Con el almacenamiento continuo que ahora se proporciona de manera eficiente en los mismos servidores que proporcionan recursos informáticos para la virtualización, HCI revertirá la tendencia del servidor "blade" de la última década. La adición de almacenamiento compartido en plataformas de servidores "rack" es posible gracias a la memoria flash de baja latencia y al nuevo software HCI, como vSAN. La economía convincente de los servidores de gran volumen alentará a los usuarios a "rehidratar" sus servidores con un flash rentable, volviendo a energizar el mercado de servidores en "rack" reemplazando a los sistemas "blade" propietarios.

En 2018, veremos cómo el almacenamiento vuelve a emerger en las plataformas de servidores con una mayor gama de opciones de almacenamiento, incluida una nueva infraestructura compuesta, que permite a los clientes ajustar la proporción de recursos informáticos y de almacenamiento para satisfacer las necesidades de sus entornos de aplicaciones.

3. Las nuevas características de HCI, sobrepasarán el almacenamiento tradicional

El mercado HCI se caracteriza por ciclos de desarrollo más rápidos comparados contra los sistemas patentados SAN y NAS, tanto para hardware como para software. Aunque ambos mercados dependen en gran medida de CPU Intel, la economía de la cadena de suministro basada en servidores para HCI, combinada con un modelo comercial que separa el desarrollo de software de los tiempos del hardware, lleva a un modelo más eficiente donde las características y funciones de HCI se entregan cada seis meses. Los sistemas de almacenamiento, por el contrario, suelen tener un ciclo de 18 meses para el software y un ciclo de 36 meses para el hardware.

Además, la implementación en la nube de HCI, como VMware Cloud en AWS, traerá beneficios adicionales a los clientes donde las nuevas características de la nube se entregan cada 90 días con un conjunto común de servicios de aplicaciones disponibles para toda la nube híbrida. Las compañías de software de HCI, incluido VMware, capitalizarán una huella de plataforma expandida que ahora se extiende desde el borde hasta el núcleo y la nube.

En 2018 podemos esperar que los ciclos de desarrollo de almacenamiento tradicionales se ralenticen a medida que el mercado de SAN se reduzca, obligando a los proveedores de almacenamiento a reducir drásticamente los esfuerzos de desarrollo, al mismo tiempo que aumenta el desarrollo de hardware del servidor debido a las oportunidades expandidas de HCI y mercados en la nube.

HCI tendrá un impacto en el personal de TI, la infraestructura y dispositivos heredados en 2018

HCI es un aspecto central del centro de datos para la nube y para este 2018, predecimos que ocupará un lugar central, especialmente porque el movimiento de datos desde el almacenamiento físico a la nube afecta la forma en que abordamos nuestra estrategia de TI.

---

Termina la transcripción.

En conclusión podemos decir que la Infraestructura Hiperconvergente, será la piedra angular sobre la que gire la estrategia de los Centros de Datos Definidos por Software, amén de convertirse en el catalizador para un crecimiento sustancial en los Servidores X86-X64 de tipo Rack.

¿Ya cuenta Usted con HCI para acelerar su negocio?