PROGRAMACION MULTIPLATAFORMA

UNIDAD Nº III
ADICION DE APIS Y DESPLIEGE EN AMBIENTES PRODUCTIVOS.

www.iplacex.cl
SEMANA 5

Introducción

Estimados alumnos sean todos bienvenidos a la semana 5, durante la cual

profundizaremos sobre que son los microservicios, Qué podemos hacer con los
microservicios, y Cómo estos nos pueden ayudar en el desarrollo de software.

Actualmente nuestra aplicación desarrollada en Ionic solamente realiza consultas y

consume APIS, en esta semana tendremos la oportunidad de crear nuestra propia API
para poder consumirla en nuestra aplicación; para esto, utilizaremos las herramientas y
servicios que nos provee Amazon Web Services (Api Gateway, Lambda, DynamoDB).

Se disponibilizará de servicios mediante api Gateway, realizaremos la lógica de consulta

mediante funciones en Lambda serverless (sin servidor) y por último registraremos data
en una base de datos no relacional como lo es DynamoDB.

www.iplacex.cl 2
 Ideas Fuerza

Microservicios

Los microservicios son una arquitectura que nos sirve para diseñar aplicaciones de
manera desacoplada, este en comparación con la arquitectura monolítica que
comúnmente conocemos se desarrollan de forma independiente, además de ser auto
escalable.

Amazon Lambda

Amazon Lambda es un servicio orientado a la arquitectura de microservicios, estos a

diferencia de la arquitectura monolítica son independientes y totalmente desacoplado,
además de fácil mantención y de gran capacidad de escalabilidad.

API Gateway

Es un servicio que nos provee Amazon web Services, con este servicio nosotros
podremos disponibilizar Apis de una forma sencilla y amigable además de forma ágil la
lógica implementada en nuestras funciones en Lambda.

DynamoDB

Dynamo DB es una base de datos no relacional dispuesta por Amazon Web Services,
en DynamoDB podemos almacenar grandes cantidades de información y procesar de
forma rápida, esta base de datos a diferencia de las relaciones está orientada a
documentos, lo que se diferencia con otros motores como mongo DB este toma una
característica de un valor como clave según sus columnas.

www.iplacex.cl 3
 Desarrollo

1. MICROSERVICIOS

Los Microservicios son un enfoque arquitectónico y organizativo para el desarrollo de

software donde el software está compuesto por pequeños servicios independientes que
se comunican a través de API bien definidas. Los propietarios de estos servicios son
equipos pequeños independientes.

Las arquitecturas de Microservicios hacen que las aplicaciones sean más fáciles de
escalar y más rápidas de desarrollar. Esto permite la innovación y acelera el tiempo de
comercialización de las nuevas características.

www.iplacex.cl 4
Arquitectura monolítica en comparación con la arquitectura de Microservicios

Con las arquitecturas monolíticas, todos los procesos están estrechamente asociados y
se ejecutan como un solo servicio. Esto significa que, si un proceso de una aplicación
experimenta un pico de demanda, se debe escalar toda la arquitectura. Agregar o
mejorar las características de una aplicación monolítica se vuelve más complejo a
medida que crece la base de código. Esta complejidad limita la experimentación y
dificulta la implementación de nuevas ideas. Las arquitecturas monolíticas aumentan el
riesgo de la disponibilidad de la aplicación porque muchos procesos dependientes y
estrechamente vinculados aumentan el impacto del error de un proceso.

Con una arquitectura de Microservicios, una aplicación se crea con componentes

independientes que ejecutan cada proceso de la aplicación como un servicio. Estos
servicios se comunican a través de una interfaz bien definida mediante API ligeras. Los
servicios se crean para las capacidades empresariales y cada servicio desempeña una
sola función. Debido a que se ejecutan de forma independiente, cada servicio se puede
actualizar, implementar y escalar para satisfacer la demanda de funciones específicas
de una aplicación.

Características de los Microservicios

Autónomos
Cada servicio componente en una arquitectura de Microservicios se puede desarrollar,
implementar, operar y escalar sin afectar el funcionamiento de otros servicios. Los
servicios no necesitan compartir ninguno de sus códigos o implementaciones con otros
servicios. Cualquier comunicación entre componentes individuales ocurre a través de
API bien definidas.

www.iplacex.cl 5
Especializados
Cada servicio está diseñado para un conjunto de capacidades y se enfoca en resolver
un problema específico. Si los desarrolladores aportan más código a un servicio a lo largo
del tiempo y el servicio se vuelve complejo, se puede dividir en servicios más pequeños.

2. Beneficios de una arquitectura de microservicios

A través del desarrollo distribuido, los microservicios potencian a los equipos y las
rutinas. También puede desarrollar múltiples microservicios de forma simultánea.
Gracias a ello, más desarrolladores pueden trabajar en la misma aplicación
simultáneamente para reducir el tiempo invertido en el desarrollo.

Agilidad

Los Microservicios fomentan una organización de equipos pequeños e independientes

que se apropian de los servicios. Los equipos actúan en un contexto pequeño y bien
comprendido, y están facultados para trabajar de forma más independiente y más rápida.
Esto acorta los tiempos del ciclo de desarrollo. Usted se beneficia significativamente del
aumento de rendimiento de la organización.

Escalado flexible

Los Microservicios permiten que cada servicio se escale de forma independiente para
satisfacer la demanda de la característica de la aplicación que respalda. Esto permite a
los equipos adecuarse a las necesidades de la infraestructura, medir con precisión el
costo de una característica y mantener la disponibilidad si un servicio experimenta un
aumento en la demanda.

Implementación sencilla

www.iplacex.cl 6
Los Microservicios permiten la integración y la entrega continuas, lo que facilita probar
nuevas ideas y revertirlas si algo no funciona. El bajo costo de los errores permite
experimentar, facilita la actualización del código y acelera el tiempo de comercialización
de las nuevas características.

Libertad tecnológica

Las arquitecturas de Microservicios no siguen un enfoque de "diseño único". Los equipos

tienen la libertad de elegir la mejor herramienta para resolver sus problemas específicos.
Como consecuencia, los equipos que crean Microservicios pueden elegir la mejor
herramienta para cada trabajo.

Código reutilizable

La división del software en módulos pequeños y bien definidos les permite a los equipos
usar funciones para diferentes propósitos. Un servicio escrito para una determinada
función se puede usar como un componente básico para otra característica. Esto permite
que una aplicación arranque por sí sola, ya que los desarrolladores pueden crear nuevas
capacidades sin tener que escribir código desde cero.

Resistencia

La independencia del servicio aumenta la resistencia de una aplicación a los errores. En

una arquitectura monolítica, un error en un solo componente puede provocar un error en
toda la aplicación. Con los Microservicios, si hay un error en todo el servicio, las
aplicaciones lo manejan degradando la funcionalidad sin bloquear toda la aplicación.

www.iplacex.cl 7
3. Arquitectura Serverless

Lo primero que hay que aclarar es que, a pesar de lo que diga su nombre, en las
arquitecturas serverless sí hay servidores. Y de hecho no es uno, sino muchos. La
diferencia respecto a las aplicaciones tradicionales es que no hay un servidor maestro
que controle el flujo de la aplicación, sino que los servidores simplemente hospedan
servicios que atienden peticiones de forma atómica y no están conscientes del flujo de
la aplicación, ya que éste se controla del lado del cliente. Dichos servicios pueden haber
sido implementados por nosotros (en el caso de comportamiento específico a nuestra
aplicación) o también podemos usar servicios proporcionados por terceros para resolver
aspectos comunes tales como, autenticación de usuarios, almacenamiento, mensajería.
Por último, los desarrolladores no tienen ninguna visibilidad a los servidores que
hospedan los servicios, ya que estos son administrados por terceros. Así que los
desarrolladores se pueden dedicar exclusivamente a implementar la funcionalidad de la
aplicación sin tener que preocuparse por administrar servidores.

Las aplicaciones serverless típicamente hacen uso extensivo de servicios de terceros

para cumplir tareas que no son centrales o específicas a la aplicación. Una aplicación
puede utilizar una familia de servicios terceros de un mismo proveedor (ej. Firebase) o
usar servicios de proveedor distintos, por ejemplo, una aplicación podría usar Auth0 para
la autenticación de usuarios, Azure Media Services para entregar video por streaming, y
OneSignal para push notifications.

Beneficios de Serverless

La principal ventaja de una arquitectura serverless es la posibilidad de que el

desarrollador se despreocupe de la gestión de la infraestructura sobre la que se ejecuta
su servicio (función) y centrarse en la funcionalidad: el ciclo completo de desarrollo se
simplifica.

www.iplacex.cl 8
También nos proporciona un nivel elevado de desacoplamiento entre los diferentes
servicios, favoreciendo el desarrollo de arquitecturas basadas en microservicios. Esto
facilita mucho el ciclo de vida y los despliegues continuos, además de simplificar los
rollbacks si fueran necesarios.

Por último, una arquitectura serverless nos posibilita reducir el gasto en infraestructura,
generando costes únicamente cuando se realiza una petición, y, por tanto, cuando la
función se ejecuta.

Una función que se ejecuta en una arquitectura serverless debe ser procesada por un
wrapper del lenguaje apropiado (Python, NodeJS, etc.) que es capaz de recibir los datos
de entrada, entregarlos a la función, ejecutarla y enviar los datos de salida. Cada wrapper

www.iplacex.cl 9
genérico de un determinado lenguaje se denomina entorno. Estos entornos son
instanciados en forma de contenedor cuando una función necesita ser ejecutada.

Cuando un desarrollador carga o modifica una función en la infraestructura FaaS, se crea

un contenedor que contiene el entorno necesario para ejecutar la función, junto con la
función en cuestión. El contenedor resultante se almacena en un registro accesible por
la infraestructura del FaaS. Igualmente, se crea también la entrada correspondiente en
el API gateway que se encargará de encaminar la petición (generalmente REST HTTP)
y arrancar el contenedor o contenedores (dependiendo de la concurrencia que tenemos
configurada) que alojan la función que deben procesar esa petición. Si el contenedor de
la función no está disponible, se lanza en el momento en el que llega la petición. Tras
atender la petición, el contenedor puede destruirse inmediatamente o tras un periodo
definido.

El tiempo necesario para que una función esté lista para empezar su ejecución es de
unos cientos de milisegundos, dependiendo de la tecnología usada. Este valioso tiempo
de latencia puede ser reducido mediante las llamadas hot functions, que mantienen la
instancia en ejecución para evitar el overhead de arranque del contenedor, mejorando
sensiblemente el throughput en el caso de alta demanda del servicio en cuestión.

Las infraestructuras serverless actuales usan RPC para delegar la ejecución de un REST
API Gateway sobre un conjunto de servidores.

www.iplacex.cl 10
4. Microservicios vs Arquitectura monolítica

Aplicaciones Monolíticas

Las aplicaciones monolíticas o sistemas monolíticos tienen como característica el uso de

una base de código única para sus servicios o funcionalidades.

Aunque son fáciles de desarrollar, una aplicación que aglutina toda su funcionalidad no
es la mejor opción, en el caso de que se tengan aspiraciones de crecimiento complejas,
más usuarios, más desarrolladores.

Además, debes tener en cuenta que un gran inconveniente que caracteriza a las
aplicaciones monolíticas es que en el momento que se quiera realizar un nuevo
despliegue, se debería relanzar todo el sistema de nuevo.

Otra de las dificultades que plantean los sistemas monolíticos, son la imposibilidad de
trabajar en varios ambientes al mismo tiempo (por tiempos de carga), lo que dificulta
enormemente el trabajo de los arquitectos o desarrolladores de software.

Microservicio
Frente a estas aplicaciones monolíticas, surgen los microservicios. Una opción muy
efectiva que está cautivando a muchos desarrolladores de software, ¡y no es para menos!
“La arquitectura de microservicios tiene como objetivo aislar los distintos componentes
de una aplicación, con el fin de que cada uno sea una aplicación por sí misma.”

Podríamos considerar que los microservicios son una evolución del Service Oriented
Architecture o SOA, cuya función se basa en desarrollar servicios independientes para
el negocio, estando cada uno de estos asociados o unidos a una misma aplicación.

A diferencia de SOA, los microservicios permiten que un componente específico del

mismo evolucione más allá de sus capacidades, ya sea dividiéndolo en elementos más
pequeños o dotándola de mayores recursos.

www.iplacex.cl 11
Servicios Cloud Microservicios
AWS Lambda
AWS Lambda es un servicio de informática sin servidor que ejecuta código en respuesta
a eventos y administra automáticamente los recursos informáticos subyacentes. Puede
usar AWS Lambda para ampliar la funcionalidad de otros productos de AWS con lógica
personalizada o bien crear servicios back-end propios que funcionen con el nivel de
seguridad, rendimiento y escala de AWS. AWS Lambda puede ejecutar código
automáticamente en respuesta a varios eventos, como solicitudes HTTP a través de
Amazon API Gateway, modificaciones realizadas en objetos en buckets de Amazon S3,
actualizaciones de tablas en Amazon DynamoDB y transiciones de estado en AWS Step
Functions.

www.iplacex.cl 12
Lambda ejecuta el código en una infraestructura informática de alta disponibilidad y se
encarga de la administración integral de los recursos informáticos, incluido el
mantenimiento del servidor y del sistema operativo, el aprovisionamiento de capacidad y
el escalado automático, la implementación de parches de seguridad y código, así como
la monitorización de código y los registros. Lo único que tiene que hacer es proporcionar
el código.

Funciones de AWS Lambda

Al código que se ejecuta en AWS Lambda se lo denomina "función de Lambda". Después
de crear una función de Lambda, está siempre estará lista para ejecutarse en cuanto se
active, de manera similar al funcionamiento de una fórmula en una hoja de cálculo. Cada
función incluye código y cierta información de configuración asociada, incluidos el
nombre de la función y los requisitos en materia de recursos. Las funciones de Lambda
"no tienen estado" y no tienen ninguna afinidad con la infraestructura subyacente, por lo
que Lambda puede lanzar rápidamente tantas copias de la función como resulten
necesarias para ajustar la escala al índice de eventos entrantes.

Después de cargar el código en AWS Lambda, puede asociar la función con recursos
específicos de AWS (por ejemplo, un bucket particular de Amazon S3, una tabla de
Amazon DynamoDB, una transmisión de Amazon Kinesis o una notificación de Amazon
SNS). A continuación, cuando el recurso cambie, Lambda ejecutará la función y
administrará los recursos informáticos según sea necesario para atender las solicitudes
entrantes.

www.iplacex.cl 13
5. Creación de servicios de backend

Un BaaS o mBaaS o Backend as a Service (Backend como servicio) es una plataforma

que automatiza el desarrollo del lado del backend y se encarga de la infraestructura en
la nube. Con un BaaS, subcontratará las responsabilidades de ejecución y
mantenimiento de servidores a un tercero y se centrará en el desarrollo del lado del
cliente o de la interfaz.

Además de eso, un BaaS proporcionará herramientas para ayudarlo a crear un código

de backend y acelerar el proceso de desarrollo. Tiene características listas para usar
como bases de datos escalables, API, funciones de código en la nube, integraciones de
redes sociales, almacenamiento de archivos y notificaciones automáticas.

Ejemplo: Crear un inicio de sesión de programación personalizada versus BaaS

Imagine que la configuración de su servidor está lista y desea desarrollar la primera
característica de su aplicación. Consideremos que la primera característica que
programará es un inicio de sesión social en Facebook. Esta sencilla tarea tomará
alrededor de 16 hrs.

Por otro lado, usar un BaaS le permitirá implementar la misma función en menos de una
hora. Tendrá un ahorro de 15 horas.

Razones comerciales para utilizar un BaaS

Las ventajas comerciales de un backend como servicio están relacionadas
principalmente con las ganancias de productividad y la subcontratación de las
responsabilidades de administración de la nube. En particular, para proyectos de tamaño
pequeño a mediano, se obtendrán beneficios sustanciales al utilizar una plataforma de
backend.

www.iplacex.cl 14
La otra ventaja es ofrecer un tiempo de comercialización más rápido para un proyecto de
software. Esperar varios meses para ofrecer un producto de software matará la
oportunidad del mercado o le hará empezar por detrás de la competencia. Entonces, las
ventajas comerciales de un BaaS son:

• Reducir el plazo de lanzamiento.

• Ahorrar dinero y disminuir el costo de desarrollo.
• Asignar menos desarrolladores de backend a un proyecto (mismos resultados con
menos desarrolladores)
• Subcontratar la gestión de la infraestructura en la nube.

Estos son los pros y los contras de usar un backend como servicio.

Ventajas de un backend como servicio:

• Velocidad de desarrollo: es súper veloz.

• Precio de desarrollo: es realmente económico.
• No tiene servidor y no necesita administrar la infraestructura.

Desventajas de un backend como servicio

• Menos flexibilidad en comparación con la programación personalizada

• Un nivel más bajo de personalización en comparación con un backend
personalizado.
• Dependencias del proveedor para plataformas de código cerrado.

www.iplacex.cl 15
6. AWS Api Gateway
Amazon API Gateway es un servicio completamente administrado que facilita a los
desarrolladores la creación, la publicación, el mantenimiento, el monitoreo y la protección
de API a cualquier escala. Con tan solo unos clics en la consola de administración de
AWS, puede crear API REST y API WebSocket que actúen como "puerta delantera" para
que las aplicaciones obtengan acceso a datos, lógica de negocio o funcionalidades
desde sus servicios backend, tales como cargas de trabajo ejecutadas en Amazon
Elastic Compute Cloud (Amazon EC2), código ejecutado en AWS Lambda, cualquier
aplicación web o aplicaciones de comunicación en tiempo real.
API Gateway gestiona todas las tareas implicadas en la aceptación y el procesamiento
de hasta cientos de miles de llamadas a API simultáneas, entre ellas, la administración
del tráfico, el control de autorizaciones y acceso, el monitoreo y la administración de
versiones de API. API Gateway no requiere pagos mínimos ni costos iniciales. Solo se
paga por las llamadas a las API que se reciben y por la cantidad de datos salientes
transferidos; además, con el modelo de precios por niveles de API Gateway, puede
reducir sus costos a medida que cambie la escala de uso de las API.

Ventajas de utilizar Api Gateway

Desarrollo de api eficiente

API Gateway permite ejecutar varias versiones de la misma API simultáneamente, lo que
facilita la iteración, puesta a prueba y publicación de nuevas versiones con rapidez. Solo
se paga por las llamadas realizadas a las API y la transferencia de datos salientes; no
hay pagos mínimos ni compromisos iniciales.

Fácil monitorización
Monitorice información y métricas de rendimiento sobre las llamadas a la API, latencia
de datos y tasas de error desde el panel de API Gateway, que permite monitorizar
visualmente las llamadas a sus servicios mediante Amazon CloudWatch.

www.iplacex.cl 16
Rendimiento a escala
Proporcione a los usuarios finales la latencia más baja posible para las solicitudes y las
respuestas de API sacando partido de nuestra red global de ubicaciones de borde a
través de Amazon CloudFront. Limite el tráfico de forma controlada y almacene en caché
la salida de las llamadas a la API a fin de garantizar que las operaciones de backend
soporten los picos de tráfico y no se llame a los sistemas backend de forma innecesaria.

Ahorro de costo a escala

Se ofrece un modelo de precios por niveles para las solicitudes de API en API Gateway.
Con un precio de solicitudes de API de tan solo 1,51 USD por cada millón de solicitudes
en el nivel más alto, puede reducir sus costos en función del número de solicitudes de
API que realice por región en todas sus cuentas de AWS.

Controles de seguridad flexibles

Autorice el acceso a sus API con AWS Identity and Access Management (IAM) y Amazon
Cognito. Si utiliza tokens de OAuth u otros mecanismos de autorización, API Gateway
puede contribuir a verificar las solicitudes entrantes mediante la ejecución de un
autorizador de Lambda desde AWS Lambda.

Puntos de escala de api RESTFUL

Cree API basadas en recursos y utilice las capacidades de transformación de datos de
API Gateway para generar las solicitudes en el lenguaje que esperan los servicios de
destino. API Gateway también contribuye a proteger los servicios existentes mediante la
puesta en práctica de reglas de limitación controlada para garantizar que el backend
pueda soportar los picos de tráfico impredecibles.

Api sin servidor

www.iplacex.cl 17
Con API Gateway puede crear API REST que sus aplicaciones móviles y web pueden
usar para llamar a los servicios de AWS disponibles públicamente mediante el código
ejecutado en AWS Lambda. Lambda ejecuta su código en una infraestructura informática
de alta disponibilidad, eliminando la necesidad de aprovisionar, escalar o administrar
servidores.

Api websocket
Cree aplicaciones de comunicación bidireccional en tiempo real tales como aplicaciones
de chat y paneles de streaming sin tener que aprovisionar o administrar servidores ni
preocuparse por los usuarios y los dispositivos conectados. API Gateway mantiene una
conexión persistente entre los clientes, gestiona la transferencia de mensajes e inserta
datos a través de servidores backend.

www.iplacex.cl 18
7. DynamoDB

Amazon DynamoDB es un servicio de base de datos NoSQL totalmente administrado

que ofrece un rendimiento rápido y predecible, así como una perfecta escalabilidad.
DynamoDB permite transferir las cargas administrativas que supone tener que utilizar y
escalar bases de datos distribuidas, para no tener que preocuparse del
aprovisionamiento, la instalación ni la configuración del hardware, ni tampoco de las
tareas de replicación, aplicación de parches de software o escalado de clústeres.
DynamoDB también ofrece el cifrado en reposo, que elimina la carga y la complejidad
operativa que conlleva la protección de información confidencial.

Con DynamoDB, se puede crear tablas de base de datos capaces de almacenar y

recuperar cualquier cantidad de datos, así como de atender cualquier nivel de tráfico de
solicitudes. Puede escalar la capacidad de desempeño de las tablas para aumentarla o
reducirla sin tiempos de inactividad ni reducción del desempeño. Puede usar la AWS
Management Console para supervisar la utilización de recursos y las métricas de
rendimiento.

www.iplacex.cl 19
8. Modelos de datos de documentos y de clave-valor

Los sistemas de bases de datos NoSQL como Amazon DynamoDB utilizan modelos
alternativos para la gestión de datos, como pares de valores clave o almacenamiento de
documentos. Es importante comprender las diferencias clave y los enfoques de diseño
específicos cuando se cambia de un sistema de administración de bases de datos
relacionales (RDBMS) a un sistema de base de datos NoSQL como DynamoDB.

Diferencias entre el diseño de datos relacionales y NoSQL

Los sistemas de bases de datos relacionales (RDBMS) y las bases de datos NoSQL
tienen diferentes fortalezas y debilidades:

• En RDBMS, los datos pueden consultarse de manera flexible, pero las consultas
son relativamente caras y no se escalan bien en situaciones de alto tráfico.

• En una base de datos NoSQL como DynamoDB, los datos se pueden consultar
de manera eficiente en un número limitado de formas, fuera de las cuales las
consultas pueden ser costosas y lentas.

Estas diferencias hacen que el diseño de la base de datos sea muy diferente entre los
dos sistemas:

• En RDBMS, diseña para tener flexibilidad sin preocuparse por los detalles de
implementación o el rendimiento. La optimización de consultas generalmente no
afecta el diseño del esquema, pero la normalización es muy importante.
• En DynamoDB, diseñas tu esquema específicamente para que las consultas más
comunes e importantes sean lo más rápidas y económicas posible. Sus
estructuras de datos se adaptan a los requisitos específicos de los casos de uso
de su empresa.

www.iplacex.cl 20
9. Dos conceptos clave para el diseño NoSQL

El diseño NoSQL requiere una mentalidad diferente que el diseño RDBMS. Para un
RDBMS, se puede empezar a crear un modelo de datos normalizados sin pensar en los
patrones de acceso. Posteriormente, podrá ampliar este modelo cuando surjan nuevos
requisitos sobre preguntas y consultas. Puede organizar cada tipo de datos en su propia
tabla.

El diseño NoSQL es diferente:

• Para DynamoDB, por el contrario, no debe comenzar a diseñar su esquema hasta

que sepa las preguntas que deberá responder. Comprender los problemas
comerciales y los casos de uso de la aplicación por adelantado es esencial.

• Debe mantener la menor cantidad de tablas posible en una aplicación DynamoDB.

Acercarse al diseño NoSQL

“El primer paso para diseñar su aplicación DynamoDB es identificar los patrones de
consulta específicos que el sistema debe satisfacer.”

En particular, es importante comprender tres propiedades fundamentales de los patrones

de acceso de su aplicación antes de comenzar:

• Tamaño de los datos: saber cuántos datos se almacenarán y solicitarán a la vez

ayudará a determinar la forma más efectiva de particionar los datos.

• Forma de los datos: en lugar de cambiar la forma de los datos cuando se procesa
una consulta (como lo hace un sistema RDBMS), una base de datos NoSQL
organiza los datos para que su forma en la base de datos se corresponda con lo
que se consultará. Este es un factor clave para aumentar la velocidad y la
escalabilidad.

• Velocidad de datos: DynamoDB se escala al aumentar el número de particiones

físicas que están disponibles para procesar consultas y al distribuir eficientemente

www.iplacex.cl 21
 los datos entre esas particiones. Conocer de antemano cuáles serán las cargas
de consulta máxima podría ayudar a determinar cómo particionar los datos para
utilizar mejor la capacidad de E / S.

Después de identificar los requisitos de consulta específicos, puede organizar los datos
según los principios generales que rigen el rendimiento:

• Mantener los datos relacionados juntos. La investigación sobre la

optimización de la tabla de enrutamiento hace 20 años descubrió que la "cercanía
de referencia" era el factor más importante para acelerar el tiempo de respuesta:
mantener los datos relacionados juntos en un solo lugar. Esto es igualmente cierto
en los sistemas NoSQL de hoy, donde mantener los datos relacionados en
estrecha proximidad tiene un gran impacto en el costo y el rendimiento. En lugar
de distribuir elementos de datos relacionados en varias tablas, debe mantener los
elementos relacionados en su sistema NoSQL lo más cerca posible.

Como regla general, debe mantener la menor cantidad de tablas posible en una
aplicación DynamoDB. Como se enfatizó anteriormente, la mayoría de las
aplicaciones bien diseñadas requieren solo una tabla, a menos que haya una
razón específica para usar varias tablas.

Las excepciones son casos en los que están involucrados datos de series
temporales de gran volumen o conjuntos de datos que tienen patrones de acceso
muy diferentes, pero estas son excepciones. Una sola tabla con índices invertidos
generalmente puede permitir consultas simples para crear y recuperar las
complejas estructuras de datos jerárquicos requeridas por su aplicación.

• Usar orden de clasificación. Los elementos relacionados se pueden agrupar y

consultar de manera eficiente si su diseño clave hace que se ordenen juntos. Esta
es una importante estrategia de diseño NoSQL.

www.iplacex.cl 22
 • Distribuir consultas. También es importante que un gran volumen de consultas
no se centre en una parte de la base de datos, donde pueden exceder la
capacidad de E / S. En su lugar, debe diseñar claves de datos para distribuir el
tráfico de manera uniforme entre las particiones tanto como sea posible, evitando
los "puntos críticos".

• Use índices secundarios globales. Al crear índices secundarios globales

específicos, puede habilitar consultas diferentes de las que puede admitir su tabla
principal, y que siguen siendo rápidas y relativamente económicas.

www.iplacex.cl 23
 Conclusión

En conclusión, mediante los microservicios podremos aplicar la lógica de nuestro negocio

de una manera desacoplada, fácil de mantener y escalar. Con api Gateway podremos
disponibilizar nuestras funciones hacia cualquier aplicación que estemos desarrollando,
esto nos puede beneficiar a nivel de costos debido a que se escala de forma automática.
Y, finalmente podremos almacenar y procesar grandes volúmenes de información con
DynamoDB, una base de datos no relacional auto escalable y de gran rendimiento por
transacción.

www.iplacex.cl 24
 Bibliografía
Red Red Hat. (2017). ¿Qué son los microservicios?. De Red Hat Sitio web:
https://www.redhat.com/es/topics/microservices/what-are-microservices

Amazon. (2021). Amazon API Gateway. De AWS Sitio web:

https://aws.amazon.com/es/api-gateway/

Amazon. (2021). AWS Lambda. De AWS Sitio web:

https://aws.amazon.com/es/lambda/

Amazon. (2021). Amazon DynamoDB. De AWS Sitio web:

https://aws.amazon.com/es/dynamodb/

Hat. (2017). ¿Qué sonww.redhat.com/es/topics/microservices/what-are-microservices

www.iplacex.cl 25
www.iplacex.cl 26