spinner

Caso de uso: Servicios AWS

DynamoDB es una base de datos NoSQL del tipo clave-valor, es decir, está pensada para persistir información no relacional y sin un esquema definido y ofrecer un acceso rápido a la información.

 

VENTAJAS

  • Se engloba dentro de los recursos que AWS ofrece a nivel de Software as a Service, que permite desvincularse de la gestión y mantenimiento de la infraestructura donde se ejecuta y de intentar optimizar el rendimiento de la herramienta así como gestionar la seguridad, ya que son los ingenieros de AWS los que lo hacen por nosotros.
  • Escalado por defecto, con lo cual no hay límite de almacenamiento de datos ni el rendimiento se va a ver afectado por este hecho.
  • Alta disponibilidad de serie, con lo que los datos son replicados de forma automática en espacios geográficos distintos, con lo que si hay una pérdida de servidores en un Data Center, por la cuestión que sea, nos garantizamos el tener un respaldo constante y actualizado, siendo la recuperación de estos datos transparentes para nosotros.
  • Flexibilidad, al ser una base de datos NoSQL la estructura de datos no está ligada a ningún esquema, con lo cual nos tener registros con estructuras distintas en la misma tabla.
  • Rapidez acceso a datos, al ser una base de datos del tipo clave-valor, está dotada de un sistema de indexación que permite una respuesta rápida y constante ante peticiones de acceso a datos.
  • Soporta documentos de tipo JSON, pero sin olvidarnos de que su motor está basado en clave-valor
  • Pago por uso, realmente esto es un estándar en el modelo de facturación de AWS, en concreto este servicio se basa principalmente en la cantidad de datos almacenados y el throughput que se ofrezca en los canales de lectura y escritura, permitiendo esto tener una gran flexibilidad a la hora de establecer una estrategia de ahorro de costes levantando y bajando el throughput ante momentos de picos y valles en la demanda del servicio
  • Posibilidad de control de acceso de grano fino, ya que permite definir políticas de acceso a nivel de usuario nominal, controlando la interacción de éste con los datos a nivel registro o de atributos.
  • Migración sencilla de datos entre éste y otros servicios de AWS.

LIMITACIONES

  • No hay transaccionalidad ni relación entre tablas de forma nativa (se pueden gestionar con determinadas estrategias a nivel de software). Más que una desventaja es una característica propia de las bases de datos NoSQL
  • Datos eventualmente consistentes. Al tener que replicarse en varios Data Centers, la consistencia que obtenemos es parcial por defecto, esto implica que al escribir un dato puede que no lo tengamos disponible al instante. Existe una opción que dota al sistema de una consistencia fuerte, penalizando la recuperación de datos. No obstante en ambos casos estamos hablando a nivel de milisegundos, por lo que si no se trata de un escenario concreto donde en intervalos muy reducidos a esa escala, haya que escribir y leer, no encontraremos ningún problema
  • Límite de 400KB por registro. El alto rendimiento al recuperar los datos tiene sus sacrificios y uno de ellos es la capacidad de almacenamiento por registro
  • Acceso a datos fuertemente dependiente del modelado, al tratarse de un sistema basado en clave-valor, toda query hay que hacerla a través de las claves, para consultas por otros campos habría que utilizar índices secundarios o bien las lecturas se verían muy penalizadas en rendimiento. Esto hace que tengamos que pensar muy bien el modelado que vamos a implementar para el almacenamiento de los datos y que éste esté muy orientado al uso final que se le va a dar a la base de datos.

CASOS DE USO

  • Aplicaciones donde se necesite un acceso rápido y con un tiempo de respuesta constante a los datos, teniendo en cuenta que:
    – Los datos deben estar uniformemente distribuidos en una o varias tablas mediante su clave.
    – No puede haber registros de más de 400KB, es decir, a grandes rasgos nos olvidamos de almacenamiento de ficheros multimedia, o de texto extensos (hay estrategias que junto con otro servicio, S3, nos permite implementar estos sistemas).
    – No se necesite relación entre tablas ni transaccionalidad en las operaciones.
  • Aplicaciones con necesidades puntuales de picos y valles en las operaciones de entrada y salida.
  • Escenarios donde nos queremos ahorrar el coste de tener una infraestructura propia y una persona o equipo dedicado al mantenimiento y la optimización del servidor de base de datos.
  • Situaciones con necesidades de control de acceso de grano fino a nivel de usuarios nominales.
  • Aplicaciones de IoT con una ingesta y/o consumo de datos constantes.

 

AWS define este servicio como un almacén de datos rápido y totalmente administrado a escala de petabytes y que permite una integración fácil y rentable con las herramientas de Business Intelligence. Es una base de datos de columnar con un motor MPP. Almacena los datos de forma continua a nivel de columna y permite en procesamiento masivo paralelo.

 

VENTAJAS

  • Se engloba dentro de los recursos que AWS ofrece a nivel de Platform as a Service, permitiendo la desvinculación de la gestión y mantenimiento de la infraestructura donde se ejecuta y de intentar optimizar el rendimiento del software así como gestionar la seguridad, ya que son los ingenieros de AWS los que lo hacen.
  • Pago por tiempo de uso. Permite levantar una infraestructura de analítica de datos sólo cuando sea necesario, pagando sólo por el número de horas que ésta esté activa.
  • Cifrado de datos almacenados en reposo y en tránsito mediante AES-256.
  • Compresión de datos para aumentar el rendimiento. Además, Redshift dispone de un mecanismo que aconseja cuál es el mejor tipo de compresión para cada campo.
  • Fácil conexión establecida mediante JDBC u ODBC y operativa ya que es 100% compatible con SQL.
  • Backups fáciles y automatizados. Se pueden establecer políticas de realización de snapshots para guardar el estado actual de un clúster y poder recuperarlo posteriormente.
  • Fácil escalabilidad pudiendo cambiar tanto la cantidad como el tipo de máquinas utilizadas para aprovisionar los nodos del clúster, adaptándose así a la demanda de carga que se nos pueda dar en cada momento. Además, una opción interesante es la posibilidad de establecer un clúster como “maestro” para la actualización de datos, y gracias a la realización de snapshots poder levantar distintos clúster para que sean utilizados con los datos del clúster maestro, pudiendo adaptar cada uno de estos clústers a las necesidades de cada grupo de trabajo, sin que nadie interfiera en la consistencia de los datos ni el rendimiento del clúster maestro. Esto es muy útil para sistemas de analítica de datos, con una fuente de datos centralizada.
  • Incluye Redshift Spectrum, que permite ejecutar directamente consultas SQL sobre exabytes de datos no estructurados en Amazon S3.
  • Conexión directa con AWS Quicksight, para generar dashboard interactivos con visualizaciones de nuestros datos.

LIMITACIONES

  • Requiere un mínimo mantenimiento continuo por parte de los usuarios/administradores, tales como no dejar tablas ni datos temporales almacenados en los snapshot ya que esto puede demorar los tiempos de recuperación de los snapshots.
  • No recomendado para escenarios donde se necesite dar soporte a muchos usuarios/queriesconcurrentes, ya que tiene un sistema de encolado de queries para poder optimizar el rendimiento y esto hace que los tiempos de ejecución de queries se dilaten, además de permitir una concurrencia mínima si queremos queremos tener un sistema óptimo.
  • No recomendado procesos de ETL o Machine Learning.
  • No recomendado para sistemas de inserción de datos constantes.
  • Se echa en falta bidireccionalidad con DynamoDB ya que desde DynamoDB sí se pueden cargar datos a Redshift, pero el camino inverso no está disponible (aunque se puede llegar mediante scripts y utilizando S3 de pasarela).
  • Relación fuerte entre la capacidad de almacenamiento y la cantidad/tipo de nodos, lo que hace que muchas veces se tengan que añadir máquinas sólo para que los datos quepan en el clúster en lugar de porque se necesite más potencia de cómputo. Parece que una solución a este problema puede ser Redshift Spectrum.

CASOS DE USO

  • Cualquier escenario donde se necesite un Data Warehouse para analítica de datos, siempre y cuando el número de usuarios y/o queriesconcurrentes no sean demasiados (2 ó 3 es un número aceptable).
  • Escenarios donde se necesite disponer de clústers con distinta capacidad de cómputo pero con los mismos datos, de forma que se pueda tener un clúster maestro donde se escriba y recuperar los datos en distintos clúster de diferentes capacidades de cómputo dependiendo de los usuarios a los que vaya destinado
  • Escenarios donde las necesidades de almacenamiento y cómputo pueden variar de forma imprevisible.

 

AWS Elastic MapReduce ofrece un ecosistema de procesamiento masivo de datos basado en la tecnología de sistema de ficheros distribuidos. Actualmente se puede trabajar con estos marcos: Hadoop, Spark, Hbase, Presto, Flink, pudiendo interactuar con otros servicios de almacenamiento de datos de AWS, como pueden ser DynamoDB y S3.

 

VENTAJAS

  • Se engloba dentro de los recursos que AWS ofrece a nivel de Platform as a Service, permitiendo la desvinculación de la gestión y mantenimiento de la infraestructura, donde se ejecuta y se intenta optimizar el rendimiento del software así como gestionar la seguridad, ya que son los ingenieros de AWS los que lo hacen por nosotros.
  • Facilidad a la hora de montar un clúster para procesamiento de datos con tecnología MapReduce distintos marcos de trabajo.
  • Ahorro de costes, ya que es posible seleccionar el tipo de instancias deseadas así como la cantidad de nodos. Además, en este servicio se ofrece la posibilidad de adquirir instancia en modo de subasta (instancia Spot) lo cual resulta muy útil para pequeñas pruebas de concepto.
  • Buena integración con otros servicios de AWScomo son DynamoDB, S3, Data Pipeline.
  • Flexibilidad, ya que el usuario tiene el pleno control del clúster, además de poder instalar software adicional.
  • Posibilidad de recuperar de forma rápida una configuración de un clúster anterior gracias a la opción de clonar clústers.
  • Comparado con otros proveedores, EMR es bastante rápido a la hora de sacar nuevas versiones (suelen sacar cada 1-2 meses).
  • Capacidad de procesamiento diferente en función del escenario. Se pueden, por ejemplo, usar las instancias de la familia R para optimizar el procesamiento en memoria con Spark e instancias de la familia C si quieres mayor rendimiento de cómputo puro en un mapreduce.

LIMITACIONES

  • Si se eligen instancias spot, se puede arrebatar la instancia en cualquier momento, impidiendo así que se terminen los procesos. En este caso, es un riesgo que se puede correr si prima el ahorro de costes.
  • No recomendado para sistemas donde se necesite una respuesta rápida, ya que está pensado para procesos batch.
  • No recomendado para sistemas productivos 24/7.

CASOS DE USO

  • Procesamiento batch de gran cantidad de datos, donde el tiempo de procesado no es demasiado importante.
  • Pruebas de concepto relacionados con procesamiento de datos, en los que no se sabe muy bien cómo va a responder el sistema. Para esto viene muy bien utilizar instancias Spot.
  • Extracción, transformación y carga de datos.
  • Transferencia de datos entre cuentas de AWS combinado con S3. Es en loq que se basa la opción de import/export de DynamoDB
  • Para recorrer gran cantidad de datos en DynamoDBy hacer una misma modificación a esos datos.

 

Amazon Kinesis es una plataforma de ingesta y consumo de datos en tiempo real. Permite crear aplicaciones cuyo propósito sea almacenar, procesar y consultar información en streaming. Kinesis ha evolucionado desde su lanzamiento como servicio gestionado por parte de Amazon en 2013, desde ese momento, la “familia Kinesis” se ha especializado en diversas necesidades, dando lugar a diversos producto, a saber: Kinesis Streams, Kinesis Firehose y Kinesis Analytics.

Kinesis Streams: Sirve para recolectar y procesar grandes streams de datos en tiempo real.
Kinesis Firehose: Permite volcar en tiempo real streams de datos a otros destinos de AWS tales como S3, Elasticsearch Service o Amazon Redshift.
Amazon Analytics: Podemos procesar y analizar los streams de datos utilizando SQL estándar.

 

VENTAJAS

  • Servicio gestionado. Como parte de los servicios gestionados de AWS, Amazon se encarga de escalar y mantener siempre disponible la infraestructura subyacente, sin que haya que hacer nada a este respecto por parte del usuario. La única labor de gestión es la de decidir es la cantidad de shards(divisiones lógicas internas del clúster) que queremos tener en cada momento.
  • Tiempo real. El servicio está preparado para ingestar una gran cantidad de eventos por segundo con una latencia muy baja. Esto permite que una aplicación escriba del orden de miles de eventos por segundo y otra los pueda leer y procesar prácticamente en tiempo real.
  • Facilidad de uso. Amazon no solo facilita la creación del clúster, el cual en unos pocos minutos y con unos pocos clics estará funcionando, sino que también proporciona unas librerías para facilitarnos la interacción con el clúster. Estas librerías son la Kinesis Producer Library (KPL) y la Kinesis Consumer Library (KCL).
  • Coste. El coste es directamente proporcional al número de shards que se hayan configurado en el clúster, así como el tiempo de retención de la información dentro del clúster para poder consumirla (por defecto 24 horas). Es posible empezar con el clúster más sencillo, compuesto por un único shard, con un coste del orden de centavos de dólar por hora.
  • Agentes simultáneos. Amazon Kinesis permite que múltiples aplicaciones estén leyendo y escribiendo de manera simultánea sobre el mismo clúster. En el caso de las aplicaciones de lectura, cada una podrá estar leyendo desde distintas partes del clúster paralelamente al resto de aplicaciones.

LIMITACIONES

  • Lectura y escritura. Los límites como tal no son un “inconveniente”, pero es importante tenerlos en cuenta para que no den lugar a dolores de cabeza el día de mañana. Las limitaciones en Kinesis a nivel de lectura y escritura vienen dadas a nivel de shard. Cada sharddel clúster tiene una capacidad de hasta 1.000 operaciones de escritura por segundo y de hasta 10 MB de escritura. Asimismo, el límite de shards por región es de 50 en las regiones principales (Virginia, Irlanda y Oregón) y de 25 en el resto. Para más información sobre límites se puede consultar la siguiente documentación.
  • Tiempo de retención. El tiempo en el que los datos se mantienen en el clúster por defecto es de 24 horas. Este límite se puede ampliar, pero hay un hard limit en 7 días. Es decir, como mucho, los datos podrán estar alojados en el clúster 7 días antes de que caduquen y se pierdan para siempre.
  • Escalado de Shards. En caso de que se desee incrementar o disminuir el número de shards para hacer frente a un cambio en la carga de trabajo, se deberá hacer dividiendo un shard en 2 o fusionando dos shards en uno. Es decir, si hay 20 shards y se prevee la necesidad de tener 30, habría que hacer la operación de “split” sobre un shard 10 veces. Cada vez que se realiza una operación de este tipo, el clúster adquiere el estado “UPDATING” y no es posible realizar otra operación hasta que el cluster vuelve a estar en estado “ACTIVE”. Es recomendable tener una aplicación de administración, independiente al resto de aplicaciones, que se encargue de la gestión de este tipo de necesidades.
  • Tamaño de los eventos. El tamaño máximo de los “blobs” que se pueden leer por shard es de 2MB/s y 1MB/s para escrituras. A nivel de clúster, como mucho se pueden leer 10MB/s. En caso de que los volúmenes sean superiores, será necesario buscar una alternativa.

CASOS DE USO

  • En general, el patrón de uso de Kinesis es el de aplicaciones que generan una gran cantidad de eventos de manera muy frecuente, pero dichos eventos deben tener un tamaño reducido.
  • Agregación y análisis de logs. La ingesta y procesamiento de logs que producen ciertas aplicaciones (tales como servidores web, servidores de aplicación o incluso logs propios de AWS tales como CloudTrail o S3 Access Logs) son un patrón muy claro de uso de Amazon Kinesis. Además, desde que Kinesis Firehose cuenta integración nativa con AWS ElasticSearch Service, este patrón de arquitectura se simplifica aún más. Un detalle interesante a tener en cuenta es que Kinesis sirve la para la ingesta y y el procesamiento de los logs, pero habrá que buscar un almacén de datos para almacenar la información de forma permanente, puesto que, como se indicó anteriormente, los datos en Kinesis caducan.
  • Analítica en tiempo real para proyectos Big Data. Siempre ha habido muchas herramientas relacionadas con el Big Data que tienen que ver con la ingesta de información, para posteriormente tratarla a través de procesos batch. Pero cada vez se hace más evidente la necesidad de usar servicios que nos permitan almacenar y procesar esta gran cantidad de información que se genera en tiempo real. Kinesis integra, gracias a sus librerías KCL y KPL la posibilidad de usar el servicio junto con otras herramientas, tales como Spark o Samza.
    De forma nativa, Kinesis Analytics posee un motor de analítica SQL que analiza la entrada de datos en ventanas de tiempo. Utilizando Kinesis Firehose es posible canalizar la salida de este análisis hacia un almacén de datos permanente como puede ser S3 o ElasticSearch.
  • Integración con servicios móviles. Debido a la naturaleza de Kinesis, tener múltiples dispositivos enviando información a nuestro clúster de manera simultánea permite realizar analítica en tiempo real del contenido que están generando los usuarios. De esta manera, se pueden tomar decisiones automatizadas en tiempo real que afecten al contenido, a la calidad o a la publicidad que los usuarios visualizan en cada momento.

 

AWS Lambda es un servicio que permite ejecutar código como respuesta ante eventos (eventos tales como modificaciones de objetos en S3 o nuevas inserciones en tablas de DynamoDB) y que, además, no require de la administración manual de servidores por parte del usuario. Este producto forma parte del conjunto de servicios gestionados que ofrece Amazon que dan lugar al paradigma conocido como Serverless. Este tipo de servicios son gestionados, escalados, mantenidos, securizados, parcheados y monitorizados por parte de AWS. Lo único que se necesita para trabajar es proporcionar el código que se desea ejecutar.

 

VENTAJAS

  • Servicio gestionado. Amazon se encarga de la administración de los servidores a todos los niveles. El usuario únicamente debe proporcionar el código y decidir cuándo debe ejecutarse. Todo lo demás será gestionado por AWS.
  • Integración con otros servicios de AWS. Las funciones Lambda se disparan de forma reactiva ante determinados eventos de AWS, a saber: acciones con objetos en S3, elementos en tablas de DynamoDB, nuevos eventos en Kinesis, acciones en las Edge Locations del servicio de CloudFront y otros. En caso de que el uso que le va a dar a su código no cuadre con esta forma de funcionar, siempre puede usarse la función “schedule” de Lambda para ejecutar el código de forma programática, como si de un cron se tratara.
  • Tolerancia a fallos integrada. Lambda se ejecuta en distintas zonas de disponibilidad. En caso de que la función Lambda falle por cualquier motivo que no tenga que ver con un error de código, la función será reintentada nuevamente hasta que funcione. Únicamente parará en caso de que los datos que está intentando leer caduquen (caso de Kinesis).
  • Coste. El precio de cada ejecución de Lambda es extremadamente bajo. El coste de cada millón de solicitudes es del orden de centavos de dólar. La principal ventaja es que el coste está directamente relacionado con la demanda real del uso y se factura por cantidad de llamadas y en franjas de 100 milisegundos de tiempo real de ejecución, con lo que hay un detalle de grano fino de las ejecuciones del código.
  • Dentro y fuera de VPC. Las funciones Lambda que hacen uso únicamente de servicios accesibles a través de Internet (como otros servicios de AWS, otros proveedores de nube, etc.) se pueden desplegar de la forma habitual, pero si en caso de que se quiera acceder a elementos de dentro de la VPC (instancias, RDSs, Redshift…) también se puede, desplegando la función dentro de VPC.

LIMITACIONES

 

  • Uso de librerías externas. Por defecto, las librerías con las que cuenta Lambda no son demasiadas. En caso de que se quiera usar librerías externas es posible, pero el desarrollo y testeo de las funciones es más complicado. En este caso, es recomendable utilizar algún framework de aplicaciones serverless, que ayude al desarrollo y despliegue de las aplicaciones.
  • Versionado. El versionado del código dista de cómo se hace las herramientas de versionado de código más conocidas (Git, Mercurial, SVN, etc).
  • Lenguajes permitidos. Actualmente solo permite programar funciones en 3 lenguajes: Java 8, Python 2.7 y Node 4.3.
  • 5 minutos máximos. Una función lambda no puede tardar más de 5 minutos en ejecutarse. En caso de que el tiempo de ejecución supere este tiempo, AWS matará la función sin dejar que termine de forma ordenada.

CASOS DE USO

  • Análisis de logs al vuelo. Una posible función lambda podría dispararse cada vez que se crearán nuevos ficheros de log en S3. Esta función analizaría el contenido de esos ficheros y realizaría acciones (envío de notificaciones, almacenamiento de mericas, compresión de ficheros, etc) sobre los logs.
  • Backups automáticos. Utilizando las funciones programadas de AWS Lambda, se podría programar una función para realizara una copia de seguridad de ciertos datos en caso de que el tiempo de backup sea de menos de 5 minutos. En caso de que la función de backup tarde más tiempo, lo que haría la función es otro proceso (EMR) que sería el que finalmente haría el backup durante el tiempo que necesite. Esto permite planificar eventos sin destinar una infraestructura física para alojar servicios de programación de eventos como cron o similares.
  • Procesamiento de imágenes. Teniendo un bucketdonde se suben imágenes o videos, una función Lambda se podría utilizar para procesar las imágenes / videos que se subieran. La función se dispararía una vez por cada fichero que se sube, generaría un thumbnail con una miniatura de cada fichero y la alojaría en otra carpeta o en otro bucket diferente.
  • Implementación de API sin infraestructura. A través del servicio de API Gateway se pueden interceptar peticiones REST y ejecutar código a medida en respuesta a dichas llamadas tal y como hace cualquier servidor de aplicación, con la salvedad de que se trata de un servicio sin infraestructura propia y con escalabilidad virtualmente infinita.

 

Amazon SageMaker es una plataforma que facilita desarrollar y poner en producción modelos de aprendizaje automático de forma rápida e integrada. Se trata de un servicio completamente administrado que cubre cada una de las etapas de un proyecto de aprendizaje automático desde la recopilación y almacenamiento de datos, limpieza y preparación de datos, entrenamiento y la optimización de modelos hasta la puesta en producción. Este tipo de servicios son gestionados, escalados, mantenidos, securizados, parcheados y monitorizados por parte de AWS. Lo único que se necesita para trabajar es proporcionar el código que se desea ejecutar.

 

VENTAJAS

  • Permite integrar el pipeline completo de un proyecto típico de ciencia de datos: obtención, preparación y limpieza de los datos, entrenamiento de un modelo y predicción, puesta en producción y monitorización.
  • Al tratarse de una plataforma autogestionada no es necesario realizar la instalación de los principales lenguajes, paquetes o herramientas.
  • Jupyter Notebooks como estándar para la exploración y análisis de los datos. Incluidos diferentes kernels a seleccionar dependiendo de los requisitos del proyecto.
  • Variedad en los tipos de instancias a seleccionar en las diferentes etapas del pipeline: exploración de datos y entrenamiento/inferencia.
  • Principales algoritmos de ML incluidos: K-means, PCA y XGBoost entre otros.
  • Varias opciones a la hora de entrenar modelos: a través del propio notebook, con los modelos que SageMaker provee o bien con modelos propios.
  • Tuning de hiperparámetros incluido en el caso de seleccionar los modelos de SageMaker.
  • Front web de AWS bastante intuitivo donde se muestra de manera sencilla el estado actual del proyecto en SageMaker: jobs de entrenamiento ejecutándose, tiempo en ejecución, modelos desplegados…
  • Permite realizar inferencia sobre el modelo a través de endpoints de manera sencilla.

 

 

LIMITACIONES

  • Aún existen muchos algoritmos por añadir si se desean utilizar los que AWS provee.
  • Todo input/output del modelo se realiza a través de buckets en S3. Puede llegar a resultar una limitación importante dependiendo del proyecto.
  • Poco tiempo de vida. Existen ciertos detalles por mejorar de la plataforma, como la gestión de errores.
  • No permite el acceso a la instancia vía ssh.
  • En caso de no utilizar los modelos que AWS provee, no existe ventaja con respecto a usar directamente EC2.

CASOS DE USO

  • Pruebas de concepto relacionadas con la ciencia de datos, en las que se necesita iterar de forma rápida sin poner mucho detalle a la infraestructura.
  • Proyectos pequeños que no requieran la inclusión del código en arquitectura propia del cliente.
  • Análisis de datos (EDA) y entrenamiento de modelos de complejidad baja-media

 

Amazon CloudFormation es un servicio de AWS que nos permite definir stacks de infraestructura y servicios como archivos JSON o YAML y, posteriormente, gestionar la vida de estos stacks permitiéndonos desplegarlos, modificarlos y eliminarlos teniendo total control sobre el ciclo de vida de la infraestructura y versionar nuestras plantillas como si de código de software se tratara.

 

VENTAJAS

  • Totalmente integrado con los servicios de AWS permitiéndonos customizar todos los parámetros existentes dentro de la plataforma.
  • Funcionalidades como la validación de parámetros, funciones y mapeos, template nesting, … hacen de CloudFormation la herramienta perfecta para gestionar infraestructura como código dentro de AWS
  • Simplifica la gestión de grandes stacks de infraestructura y la administración de su ciclo de vida.
  • Permite replicar stacks de forma sencilla para desplegar entornos de testing (reduciendo los costes) o incluso, replicar entornos existentes en nuevas regiones como estrategia de Disaster Recovery en caso de que la región principal se vea afectada.

LIMITACIONES

  • Desde BBVA Next Technologies, echamos de menos una herramienta más ágil que CloudFormer, que permita, desde una infraestructura existente, generar las plantillas de CloudFormation.
  • Los nuevos servicios y funcionalidades de AWS deberían de publicarse siempre con la actualización de CloudFormation asociada ya que, ocasionalmente, nuevos productos y/o funcionalidades no han estado disponibles de forma inmediata dentro de este servicio.

CASOS DE USO

  • Entornos de testing
  • Estrategias de DR
  • Cualquier proyecto o workload dentro de AWS
  • Plataformas de provisión de servicios implementadas sobre AWS.

Utilizamos cookies propias y de terceros para mejorar nuestros servicios, brindarle una grata experiencia y mostrar a los usuarios publicidad relacionada con sus preferencias mediante el análisis de sus hábitos de navegación. Si continúa navegando por este sitio web, consideramos que acepta su uso. Puede cambiar la configuración u obtener más información accediendo a nuestra política de cookies aquí.