Mostrando entradas con la etiqueta Database. Mostrar todas las entradas
Mostrando entradas con la etiqueta Database. Mostrar todas las entradas

lunes, 9 de abril de 2018

Los 10 principales lenguajes de programación

Hace tiempo que no echábamos una mirada a los Lenguajes de Programación, para tener una idea de cuáles son los más populares y útiles. Aquí hay un vistazo a 10 lenguajes de programación que lo harán rico, popular e increíblemente atractivo. O tal vez solo lo ayuden a conseguir o conservar un trabajo, que de todos modos es mejor.

Las preguntas sobre los lenguajes de programación simplemente no desaparecerán. Los argumentos sobre cuál es el más popular, el más útil, el de más rápido crecimiento o el más insanamente diseñado son tan comunes en ciertos rincones del mundo tecnológico, ya que los argumentos sobre la importancia de las fases lunares son para los fanáticos de las estadísticas del béisbol.

Para los programadores, sin embargo, los argumentos se reducen a una simple pregunta: ¿Qué idioma me ayudará a ganar más dinero por el período más largo de tiempo? En el lenguaje de la economía, ¿en qué idioma la inversión de tiempo y aprendizaje traerá el mayor rendimiento?

No pretendemos ser asesores de inversiones, pero invertimos más que nuestro tiempo mirando diferentes sitios web que clasifican la popularidad y el uso (tanto relativo como absoluto) de los lenguajes de programación.

Ahora podemos observar las listas con cierto desapego. Ya no nos ganamos la vida como programadores, y los lenguajes que una vez utilizamos hace tiempo que han desaparecido de todas las listas menos esotéricas. Pero estamos muy interesado en lo que dicen las listas, porque creemos que los idiomas que importan dicen mucho sobre hacia dónde van la tecnología y los profesionales de las Tecnologías de la Información (TI).

La lista que hemos reunido aquí, se creó al observar más de media docena de listas separadas en la Web. Incluyendo el índice TIOBE, que calcula las calificaciones basadas en 25 motores de búsqueda; General Assembly, una empresa de educación de TI; PYPL, que analiza la frecuencia con la que se buscan los tutoriales en Google; CodeEval, que analiza cientos de miles de puntos de datos recopilados mediante el procesamiento de más de 1,2 millones de presentaciones de desafíos; y Tech.co, que es el lenguaje de programación más popular en GitHub; entre otros.

Algunas de las listas examinaban los anuncios de trabajo, otras en las búsquedas de capacitación y otras más, sobre la frecuencia con la que se enviaban programas en determinados idiomas para las ejecuciones de control de calidad. Eso significa que algunas de las listas eran todas de hoy, algunas sobre el mañana y algunas sobre lo que sucederá un año o más en el futuro. Lo fascinante es la cantidad de idiomas que eran comunes a todas las listas.

Así que ahí es donde dibujamos nuestra lista. Si apareció un idioma en todas las listas, entonces lo incluimos en nuestra lista. Hay algunos en la lista que no aparecían en todas las listas de fuentes, y hay algunas cosas que necesitamos saber en base a esa información.

Primero, la lista no tiene ninguna clasificación. Los primeros siete idiomas son tratados por igual, aparecieron en casi todas las listas que vimos. Los últimos tres son diferentes. Son más visionarios, por lo que tendían a provenir de listas que analizaban los idiomas que crecían rápidamente en uso o los idiomas que la gente quería aprender.

Ah, y una cosa más: aquí no nos estamos metiendo en todos los lenguajes de "scripting" versus el artículo de lenguajes "reales". Estos son todos los idiomas que hacen que los sistemas hagan cosas. Eso es suficiente. Tendremos el argumento del lenguaje de scripting más tarde.

Java

Nos encanta, lo odiamos, o ambas, Java no va a desaparecer pronto. Java tiene más de 20 años y ha sido uno de los lenguajes de programación más populares, si no el más, en Universidades Empresas en los últimos años.

La promesa de -"escribir una vez, correr a cualquier parte"- es poderosa y la mayoría de las aplicaciones comerciales, no se verán obstaculizadas por la debilidad relativa de Java al alcanzar la capa "Bare Metal" para el control. Si está buscando actualizar su estado económico y aún no tiene Java en su conjunto de habilidades, ciertamente debe estar en su lista de los "lenguajes a aprender".

Structured Query Language o SQL

SQL ha existido de una forma u otra, desde la década de los 70's y no va a ningún lado en el corto plazo. A pesar de que los grandes volúmenes de datos (Big Data), con todos sus lagos de datos no estructurados y muy diversos tipos de datos se están volviendo más importantes, la mayoría de los datos del mundo empresarial aún se almacenan en Bases de Datos Relacionales muy estructuradas. Y el lenguaje para realizar altas, bajas, cambios y consultas de la base de datos estructurada, es Structured Query Language o SQL.

No va a utilizar SQL fuera del ámbito de la base de datos, pero eso aún deja muchos desarrollos que las compañías pagarán. Incluso si nunca se convierte en un Administrador de Bases de Datos (DBA) importante, saber SQL dará sus frutos cuando necesite acceder a una base de datos en busca de información, para una aplicación más grande escrita en otro lenguaje.

Python

Python es uno de los lenguajes que muchos desarrolladores adoran y muchos otros adoran odiar. Es un lenguaje muy similar a un script, que tiene la gran ventaja de ser bastante compacto y en general, rápido de escribir. Con eso viene la desventaja de ser un lenguaje interpretado, con todos los problemas de seguridad y rendimiento potencial que conlleva. Muchas empresas ven la velocidad (y la ubicuidad) como razones para superar las preocupaciones de seguridad, y hay marcos muy sólidos que se ocupan de muchos problemas.

Dado que Python no es tan complejo como algunos de los lenguajes de programación "superiores", generalmente puede ser competente con una menor inversión de tiempo. Es una inversión que puede dar grandes dividendos a la hora de buscar el próximo desarrollo.

Javascript

Si confía en que nunca se le pedirá que escriba una aplicación basada en la Web, entonces puede ignorar Javascript de forma segura. Si existe la posibilidad de que una aplicación web (o, para ser honestos, una aplicación móvil) esté en su futuro, entonces tomarse el tiempo para aprender Javascript podría ser una inversión muy inteligente.

Javascript no es el tipo de lenguaje que utilizará para la programación del sistema o para escribir aplicaciones de análisis de dinámica de fluidos en una supercomputadora, pero es increíblemente popular y útil para lo que hace para agregar peso e interactividad al HTML. Es un lenguaje que no muestra ningún signo de desvanecimiento en la próxima media década.

C++

Cuando llega el momento de la programación del sistema o aplicaciones avanzadas de cualquier tipo, C++ sigue siendo el lenguaje que con más frecuencia se necesita para el trabajo. Este lenguaje que surgió de un preprocesador orientado a objetos para C, ha existido por más de 30 años y tiene la distinción de ser un idioma heredado y un idioma que todavía se enseña en una enorme cantidad de programas de informática en todo el mundo.

No es tan fácil de aprender como algunos de los lenguajes de scripting en la lista, pero hay poco que no puedas hacer con eso. Si la programación empresarial "seria" está en su lista de carrera, entonces C++ realmente debe estar en su lista de lenguages para aprender.

C#

Antes de que Microsoft se convirtiera en un promotor corporativo de estándares abiertos y software de código abierto, siguió su propio camino para muchas cosas. Una de esas cosas era C#, un lenguaje basado en C pero optimizado para el mundo Microsoft .NET. El marco de Microsoft todavía es utilizado por cientos de miles de aplicaciones y empresas en todo el mundo.

C# sigue siendo una forma efectiva y eficiente de escribir aplicaciones en ese marco. Hay suficientes similitudes entre C++ y C# para hacer que el cambio de uno a otro sea un esfuerzo moderado (en lugar de un re-aprendizaje completo), y la adherencia de C # a la Common Language Infrastructure lo hace flexible. Si su mundo de aplicaciones incluye una infraestructura de Microsoft, vale la pena agregar C# a su conjunto de habilidades.

PHP

No hay dudas al respecto, PHP es un lenguaje de scripting. De hecho, es un lenguaje de scripting muy ligado a las aplicaciones basadas en navegador. La cuestión es que hay muchas aplicaciones basadas en navegador y la historia indica que habrá muchas más en el futuro. PHP no es un lenguaje hermoso y elegante.

Es una cosa en expansión que creció de manera orgánica a lo largo de los años. Sin embargo, el hecho de que es complicado, no hay razón para que no puedas escribir un código efectivo y poder escribir ese tipo de código en PHP, puede hacerte muy, muy atractivo.

Swift

Swift es el lenguaje de programación de Apple para iOS y OSX, un lenguaje que recientemente (en la versión 2.2) ha convertido en código abierto. Ahora hay versiones de Swift disponibles para plataformas Linux y Microsoft, e IBM ha puesto Swift disponible en su Swift Sandbox.

Swift surgió de Objective-C, lo que significa que si has pasado algún tiempo en cualquiera de las variantes del lenguaje C, deberías poder elegir Swift bastante rápido. Incluso si no eres fanático de Apple, el soporte de IBM debería hacer que Swift se utilice en más y más entornos empresariales. Tener a Swift en su cartera debería ser una de esas cosas que rinde frutos en los años venideros.

Go

Go es uno de los idiomas más nuevos en esta lista, solo tiene una década de antigüedad en este momento. Lo que hace que Go sea un candidato para un idioma que debes aprender es que salió de Google, y es un poderoso aliado para cualquier idioma.

En cierto modo, Go es un lenguaje "clásico". Está compilado y con tecleo estático, y se remonta a idiomas como Fortran y C. Go está disponible en una amplia variedad de plataformas y muestra signos de crecimiento.

Este es un poco más accesible en comparación con la mayoría de los otros idiomas en la lista, porque invertir en aprender Go es dar un salto de fe de que va a ser adoptado por más empresas. Sin embargo, dada la trayectoria de crecimiento que ha seguido Google, ese no es el salto más riesgoso del mundo. Si tiene una caja de herramientas llena de los idiomas básicos, Go podría ser una adición muy interesante.

R

Si bien la mayoría de los otros idiomas en esta lista son lenguajes de propósito general, R está diseñado para el análisis de datos. La cuestión es que el análisis empresarial y Big Data están creciendo exponencialmente, por lo que si desea prepararse para aprovechar el crecimiento, entonces R es un lenguaje que debe aprender.

R no es nuevo, ya que ha existido por más de 20 años. Durante la mayor parte de ese tiempo, sin embargo, solo se conocía dentro de los mundos de estadística y análisis numérico. El crecimiento del mercado de inteligencia empresarial impulsó el crecimiento de R y ahora aparece con frecuencia en listas de idiomas en rápido crecimiento.

Si tiene los ojos puestos en los puestos de trabajo como "científico de datos", entonces podría hacer mucho peor que agregar R a su conjunto de habilidades de programación.

Entonces, esta es nuestra lista. Diez idiomas que son grandes, están creciendo, o ambos. ¿Cuántos de estos conoce? Más importante, ¿cuántos le gustaría saber (o le gustaría que los desarrolladores que contrata lo sepan)? Durante mucho tiempo creí que los programadores completos deberían tener más de un idioma en sus manos.

Al final es cierto que debemos ser expertos en al menos un lenguaje, pero en estos días la versatilidad es algo que resulta imperativo en las áreas de desarrollo de hoy.

jueves, 15 de marzo de 2018

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í.

jueves, 4 de enero de 2018

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?

jueves, 7 de mayo de 2015

La NoSQL de Google en La Nube...

¿Cuál fue la primer Base de Datos con la que Ustedes trabajaron? De mi parte puedo mencionar que SuperBase 64 (para la Commodore 64) fue mi primera incursión en lo que después se conocería como Motores de Base de Datos.

Antes de eso, ¿necesitabas almacenar datos en un "floppy disk", en un "datasette" y/o un disco duro? entonces requerías programar lo que sería tu propia Base de Datos en archivos secuenciales, indexados o secuencial/indexados.

Cada programador tenía su propio modelo y código para crear, modificar, utilizar y/o eliminar datos.

A mediados-finales de los años ochenta, nace el concepto de las X-Bases, siendo la más famosa de todas dBase y su lenguaje compilable "Clipper". Cuántos desarrollos aún corren sobre este soberbio motor de base de datos.

Con la adopción del Structured Query Language (SQL) como todo un estándar para Altas, Bajas, Cambios y Despliegues (ABCD) de datos y su inclusión en productos como DB2 de IBM, Oracle Database y Microsoft SQL Server ahora sólo era cuestión de avocarse al código que haría de intermediario entre el usuario (u otra aplicación) y el típico ABCD.

La necesidad cada vez mayor en cuanto a bastedad de datos, así como la variedad de los mismos, han dado idea para que existan alternativas distintas a SQL. La alternativa que más ha sobresalido se denomina NoSQL. ¿Qué es entonces NoSQL? -"...es una amplia clase de sistemas de gestión de bases de datos que difieren del modelo clásico del sistema de gestión de bases de datos relacionales (RDBMS) en aspectos importantes, el más destacado es que no usan SQL como el principal lenguaje de consultas."-

En el caso de NoSQL y a diferencia de SQL, -"Los datos almacenados no requieren estructuras fijas como tablas, normalmente no soportan operaciones JOIN, ni garantizan completamente ACID (atomicidad, consistencia, aislamiento y durabilidad), y habitualmente escalan bien horizontalmente. Los sistemas NoSQL se denominan a veces "no sólo SQL" para subrayar el hecho de que también pueden soportar lenguajes de consulta de tipo SQL."-

Muchos desarrollos que requieren cantidades masivas de información, ahora utilizarn NoSQL como es el caso de Hadoop (referente para BigData), Apache Cassandra, Amazon SimpleDB y muchas más.

Google no se podía quedar atrás e inclusive ha anunciado el lanzamiento de una nueva base de datos NoSQL, activada por su sistema de almacenamiento de datos en la nube. Según el anucio, Cloud Bigtable proporciona una latencia del rango milisegundos y el doble de rendimiento en comparación con otros sistemas de gestión de bases de datos, tales como Cassandra y HBase.

Cloud Bigtable está diseñado para datos de nivel petabyte; es decir, sistemas con necesidad de gestionar millones de transacciones u operaciones por segundo.

En los últimos años, Google ha ofrecido su servicio Cloud Datastore de almacenamiento en la nube, que es una solución totalmente gestionada destinada a almacenar datos no relacionales.

El servicio, que depende de Bigtable, es descrito por Tom Kershaw, director de product management for big data, storage and networking en Google Cloud Platform como “nuestro primer asomo en el ámbito de las bases de datos NoSQL”. En este sentido, cabe señalar que Bigtable se encuentra aún en etapa beta.

Kershaw añadió que Google Cloud Bigtable “se basa en una tecnología que Google ha estado utilizando internamente durante muchos años, por lo que no se trata de una novedad, propiamente tal”.

Google afirma que su Cloud Bigtable funciona con mayor rapidez que otros servicios de almacenamiento de datos de tipo NoSQL. Una comparativa interna muestra que el Bigtable, al ser contrastada con bases de datos NoSQL de Cassandra y la versión genérica de HBase, cuenta con menor latencia, tanto para escritura como lectura de datos.

“Cloud Bigtable escala a cientos de petabyte, y millones de lecturas y escrituras por segundo, mientras manteniendo a la vez latencias de milisegundos de un solo dígito”, escribe Google en su página de Cloud Platform, agregando que “ninguna carga de trabajo es demasiado grande para el sistema”.

Cloud Bigtable es la apuesta más reciente de Google para situarse en una posición de liderazgo en la creciente industria de la nube pública, actualmente dominada por Amazon Web Services. Cloud Bigtable se encuentra actualmente en etapa beta, y Google ofrece una prueba gratuita para los usuarios interesados en el servicio. Los niveles de precio se basan en varios factores, incluyendo la cantidad de almacenamiento utilizado, el número de nodos desplegados, y el nivel de utilización de la red.

¿Qué utilidad encuentra Usted para adoptar NoSQL en La Nube?