La idea de este episodio surgió desde LinkedIn con una pregunta que leí: ¿Hay diferencia entre un modelo de Machine Learning (ML) y un modelo de IA como un LLM? En este capítulo revelamos una distinción crucial entre procesos predictivos y generativos que muchas organizaciones están pasando por alto al integrar la IA en sus proyectos.

Estando desde hace muchos años acompañando a Devs enfocado en el Software Development Life Cycle (SDLC) (y ahora metido de lleno con la IA), he podido notar que siempre tenemos una batalla que pelear. Y la batalla de hoy me suena muy parecida a una que ya peleamos....

¿Te acuerdas cuando empezó a globalizarse el uso de las herramientas cloud? Todos los Devs venían: Héctor….

¿Cómo hago para tener un usuario? Dame una cuenta para probar mis cosas….

Darle acceso permanente no era la mejor idea. Las instancias quedaban prendidas sin control, bases de datos levantadas sin ningun dueño (si nadie se hacia cargo), y pasaba una factura de 200 dólares a 1000 dólares en una noche.

Bueno, hoy está pasando lo mismo. Pero en lugar de credenciales cloud, los compañeros de equipo preguntan:

¿Qué API Key podemos utilizar para probar con IA?

Entonces viene la gran pregunta, ¿nos pasamos a credenciales de proveedoreso usamos servicios ya existentes? Al estilo de OpenAI, Anthropic, etc. O nos quedamos con AWS Bedrock? Debemos de pensar en el modelo de precios, gobierno, etc.

Y acá es donde debemos de reaccionar...

Antes de empezar: ¿qué necesitas y qué vas a lograr?

Pre-requisitos:

No necesitas ser un experto en IA ni en Machine Learning. Lo que sí necesitas es tener lo básico de tu cuenta de AWS en orden.

• AWS Organizations configurado con al menos una OU para tus cuentas de desarrollo

• IAM Identity Center (SSO) habilitado, los devs ya deben poder hacer
  `aws sso login`

• Permission Sets creados por equipo (ej: BackendDev, FrontendDev, QATeam)

• Amazon Bedrock habilitado en eu-west-1 (o la región que aplique según tu rgulación)

• AWS CDK o Terraform para desplegar la infraestructura como código

• Conocimientos básicos de IAM Policies, SCPs y CloudWatch: Si ya gestionas cuentas cloud con SSO y policies, ya tienes todo lo que necesitas.

¿Qué vas a lograr al final?

Cuando termines de implementar lo que te voy a mostrar, vas a tener:
Acceso gobernado a LLMs por equipo, Guardrails automáticos, Restricción geográfica, Presupuesto por equipo con corte automático, Dashboard de consumo, Auditoría completa, Reset mensual automático.

Y lo más importante: el developer puede empezar a usar IA desde el día 0 con sus credenciales AWS SSO de siempre, sin esperar a que alguien le consiga una API Key ni pagar nada de su bolsillo.

El problema real: herramientas sin gobierno = caos

Seamos sinceros. No muchas organizaciones tienen reglamentadas estas herramientas. Tenemos a gente copiando y pegando código de clientes en modelos, sin saber las implicaciones que tiene. Cada quien utiliza el IDE (que muchas veces paga de su bolsillo), la que tiene a la mano, o la que puede acceder de forma gratuita.

Ahí hay que tener bastante cuidado.

Ahora, la idea no es controlar. La idea es monitorear y darles herramientas a todos los compañeros para que puedan utilizar la IA de forma segura. Se trata de dar opciones para que puedan sacar el mayor provecho, no de limitar.

Resulta que si ya trabajas con AWS, las herramientas ya las tienes. No necesitas desplegar un proxy (por ahora), no necesitas infraestructura adicional. Solo necesitas policies.

El déjà vu: lo que aprendimos del mundo cloud aplica con IA también

Pensemos un momento en cómo resolvimos el acceso cloud. No le dimos a cada dev una AccessKey permanente con permisos de administrador. Aprendimos (a las malas, muchos de nosotros) que lo correcto era:

1. Identity Center (SSO): credenciales temporales, no permanentes
2. IAM Policies: permisos específicos por rol o equipo
3. SCPs: límites a nivel organizacional que nadie puede saltarse
4. AWS Budgets: alertas cuando el gasto se dispara

¿Seguro te suena todo esto no? Porque la estrategia para gobernar el acceso a LLMs es exactamente la misma (casi ya veremos).

☁️ Cloud (lo que ya hacemos) 🤖 IA Generativa (lo que necesitamos)
IAM User con access keys Credenciales SSO temporales
Permisos granulares por servicio Permisos granulares por modelo
SCPs para limitar regiones SCPs para limitar regiones + modelos
AWS Budgets para alertar CloudWatch + Lambda para cortar antes del desastre
CloudTrail para auditoría CloudTrail + métricas de tokens

La diferencia es la velocidad. En cloud, un error de costos se nota en días. En IA, un bucle de razonamiento puede gastar 50 dólares en 5 minutos. Por eso necesitamos un mecanismo de corte activo, no solo alertas.

SPOILER: AWS Budgets no sirve para esto. Ya que tiene una latencia de hasta 24 horas para cortar el acceso, en términos de IA es una eternidad.

Diagrama de lo que estamos creando:

El dev no necesita aprender nada nuevo. Ya sabe hacer aws sso login. Lo único que cambia es que invoca el modelo a través de un Inference Profile de su equipo en lugar del model ID directo.

¿Qué necesitamos configurar?

La IAM Policy del equipo

Esta policy dice: solo puedes usar los modelos de tu equipo, y siempre con AWS Bedrock Guardrail.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "AllowInvokeViaTeamProfile",
            "Effect": "Allow",
            "Action": ["bedrock:Converse", "bedrock:ConverseStream"],
            "Resource": [
                "arn:aws:bedrock:eu-west-1:123456789012:inference-profile/team-*"
            ]
        },
        {
            "Sid": "DenyWithoutGuardrail",
            "Effect": "Deny",
            "Action": ["bedrock:Converse", "bedrock:ConverseStream"],
            "Resource": "*",
            "Condition": {
                "StringNotEquals": {
                    "bedrock:GuardrailIdentifier": "arn:aws:bedrock:eu-west-1:123456789012:guardrail/corp-guard-001/version/1"
                }
            }
        }
    ]
}

¿Qué pasa si el dev intenta invocar un modelo que no está en su lista? AccessDeniedException. ¿Sin guardrail? AccessDeniedException. No hay forma de saltárselo.

El Guardrail que protege todo

Los Guardrails de Bedrock actúan como un firewall semántico. Si el Desarrollador sin querer pega un correo electrónico, numero de documento, un número de tarjeta o hasta una AWS_SECRET_KEY en el prompt, el guardrail lo intercepta antes de que llegue al modelo.

# CDK simplificado
bedrock.CfnGuardrail(self, "CorpGuardrail",
    name="corp-ai-guardrail",
    sensitive_information_policy_config={
        "piiEntitiesConfig": [
            {"type": "EMAIL", "action": "ANONYMIZE"},
            {"type": "PHONE", "action": "ANONYMIZE"},
            {"type": "CREDIT_DEBIT_CARD_NUMBER", "action": "BLOCK"},
            {"type": "AWS_ACCESS_KEY", "action": "BLOCK"},
            {"type": "AWS_SECRET_KEY", "action": "BLOCK"},
        ]
    }
)

El mecanismo de corte: presupuesto en tokens, no en dólares

Algo que debes de saber: AWS Budgets tiene un retraso de 24 horas para reflejar costos. Si un dev entra en un bucle que quema tokens sin parar, la alerta llega al día siguiente. Para IA generativa, eso es poco real. La solución que vamos a estar haciendo: un Accumulator mediante una simple Lambda que cada 5 minutos suma los tokens consumidos por el equipo (de todos sus Inference Profiles) y publica una custom metric. Una alarma de CloudWatch monitorea esa métrica y dispara el corte.

Código (resumido)

# Lambda: Accumulator (se ejecuta cada 5 min)
def handler(event, context):
    for team_name, profile_arns in TEAM_PROFILES.items():
        total_tokens = 0
        
        for profile_arn in profile_arns:
            for metric in ["InputTokenCount", "OutputTokenCount"]:
                response = cloudwatch.get_metric_statistics(
                    Namespace="AWS/Bedrock",
                    MetricName=metric,
                    Dimensions=[{"Name": "InferenceProfileArn", "Value": profile_arn}],
                    StartTime=month_start,
                    EndTime=now,
                    Period=86400 * 31,
                    Statistics=["Sum"],
                )
                for dp in response["Datapoints"]:
                    total_tokens += int(dp["Sum"])
        
        # Publicar acumulado MTD como custom metric
        cloudwatch.put_metric_data(
            Namespace="Custom/BedrockGovernance",
            MetricData=[{
                "MetricName": "TokensMTD",
                "Dimensions": [{"Name": "Team", "Value": team_name}],
                "Value": total_tokens,
                "Unit": "Count",
            }],
        )

¿Y que va pasar cuando esta alarma se active? Tendremos otra Lambda que le inyectará al profile del equipo que corresponda una política para bloquear cualquier acceso a LLMs.

# Budget Cut Lambda, tarda en hacer efecto en ~10-30 segundos, mucho más rapido que las 24hs de AWS Budgets
def _cut_access(team_name, role_name):
    iam.put_role_policy(
        RoleName=role_name,
        PolicyName="BudgetExceeded-AutoDeny-Bedrock",
        PolicyDocument=json.dumps({
            "Version": "2012-10-17",
            "Statement": [{
                "Effect": "Deny",
                "Action": ["bedrock:Converse", "bedrock:ConverseStream"],
                "Resource": "*",
            }]
        }),
    )

Limitaciones, mejoras:

• El día 1 de cada mes, lo ideal es que un EventBridge scheduled rule remueve la Deny policy y el equipo arranca de nuevo.

• Si tienes alguna forma automatizada que genera las políticas en base a tu directorio activo se debe considerar este cambio.

¿Cómo tendrá que llamar a un modelo un Dev?

ejemplo simplificado

import boto3

session = boto3.Session(profile_name="backend-devs")
client = session.client("bedrock-runtime", region_name="eu-west-1")

response = client.converse(
    modelId="arn:aws:bedrock:eu-west-1:123456789012:inference-profile/team-backend-anthropic",
    messages=[{"role": "user", "content": [{"text": "Explica qué es un VPC en AWS"}]}],
    inferenceConfig={"maxTokens": 256}, // Los parametros que necesitemos
    guardrailConfig={"guardrailIdentifier": "corp-guard-001", "guardrailVersion": "1"},
)

print(response["output"]["message"]["content"][0]["text"])

Lo importante es que los Devs tiene la herramienta disponible desde el día 0. No tiene que esperar a que se apruebe un presupuesto, a que alguien le cree una cuenta en OpenAI, ni a que se despliegue un proxy. Usa sus credenciales de AWS como viene utilizando para el resto de servicios.

¡Lo logramos!

Ya con estos pequeños cambios podemos tener la trazabilidad del consumo dado por el equipo usando un inference profile.

Esto era para el día 0 y.. ¿ para el resto?

Trade-offs del enfoque nativo

Limitaciones:

• El corte es por equipo, no por usuario: Si un dev consume demasiado, se corta a todo el equipo. ¿Cómo se resuelve? Habilitar Model Invocation Logging + métricas per-user

• Hay una ventana de aprox 5 min sin protección: El accumulator evalúa cada 5 min, en ese intervalo se pueden consumir tokens. ¿Cómo se resuelve? Con maxTokens limitado y la latencia de Bedrock, el impacto máximo es aprox $0.80 y no $200

• Vendor lock-in con boto3: El código está acoplado a AWS, En una segunda etapa, Bedrock API Key + OpenAI SDK compatible da portabilidad

• Inference Profile ARN en el código: El dev no puede poner el model ID directamente. ¿Cómo se resuelve? Una variable de entorno BEDROCK_PROFILE resuelve esto.

• No hay dashboard de self-service: El dev no puede ver su consumo sin pedir al Platform Team. Mejora futura: dashboard por equipo con acceso read-only

Novedades en este 2026

Proxy real (LiteLLM o similar): Cuando la organización crezca y necesite soporte multi-provider (OpenAI, Anthropic, Azure), un proxy centralizado sobre ECS/Fargate con virtual keys, caching, y observabilidad avanzada es el camino. Pero no es lo que necesitas el día 1.

OpenTelemetry + Langfuse: Para organizaciones que despliegan agentes autónomos (no solo prompts simples), la observabilidad semántica con trazas jerárquicas es esencial. Esto permite ver el Tree of Thoughts o ToT del agente y hacer forense cuando algo sale mal. De vuelta, es una evolución, no un prerequisito.

Observabilidad per-user: Model Invocation Logging (solo metadata, sin capturar el contenido del prompt por privacidad) permite crear métricas por usuario SSO. Así detectas quién es el power user dentro de un equipo, sin cortar a todos.

NEW 2026: Costos por usuario usando tags directamente en Bedrock. Amazon Bedrock ahora admite la asignación de costos por entidad principal de IAM, como usuarios y roles de IAM, en AWS Cost and Usage Report 2.0 (CUR 2.0) y Cost Explorer. Esto permite a los clientes comprender y atribuir los costos de inferencia de modelos de Bedrock a usuarios, equipos, proyectos y aplicaciones.
https://aws.amazon.com/es/about-aws/whats-new/2026/04/bedrock-iam-cost-allocation/

Suscríbete ahora

Conclusiones

La industria está creando herramientas para que sus empleados puedan utilizar IA. Ya no se trata de crear herramientas para la autogestión únicamente — ahora la idea es que los propios colaboradores dentro de una organización puedan usar estas herramientas. Y eso está bien.

Pero debemos darles acceso con gobierno real. No después, no cuando ya haya un incidente, no cuando la factura ya sea inmanejable, similar a lo que en seguridad se conoce como el zero-day.

Y lo bonito de todo esto es que si ya sabes gestionar políticas de IAM, SCPs y credenciales SSO en AWS... ya sabes hacer esto. No necesitas ser un ingeniero de Machine Learning. No necesitas desplegar tu propio modelo. Se trata de saber qué herramientas tienes y cómo puedes seguir aportando al equipo donde estás.

Las herramientas cloud que ya dominas son la base para gobernar la IA que viene. Los especialistas dentro del mundo cloud somos nosotros.

¿Te gustaría que estemos en 📩 contacto?

Héctor Fernández
AWS Community Builder

https://blog.hectorfernandez.dev

Te voy ahorrar unas cuantas horas de lecturas con estos mis insights (creado por un humano 🫶 I promise)

El 2023 se vio plasmado por pruebas de conceptos, desde el 2024 muchas empresas ya tienen en producción aplicativos usando IA, para este 2026 se espera entregar VALOR al negocio.

Por lo que ya todo el mundo logra identificar que son útiles las herramientas de IA generativas, pero ahora hay que contrastar con el flujo de caja.

Deja de pensar en tecnología y comienza a pensar en el negocio, así tendrás una visión mucho más amplia en el equipo que seas parte.

Soy un simple Desarrollador / Arquitecto / DevOps / QA… ¿Cómo puedo mejorar?

• Construye más rápido, identifica aquellas tareas que te llevan mucho tiempo en tu SDLC

• Experimenta con agentes para tener código asistido, deja el vibe coding.

• Aprende a identificar qué stack de IA conviene según tu caso de uso

• Aprovecha las funcionalidades de “Fine-tuning” que te pueden ayudar muchísimo con poco esfuerzo.

• Planifica el uso de infra de forma real, a ver ya creo que aprendimos que no todos necesitamos tener un cluster de K8s para todo, esto es lo mismo, usa la infra justa y necesaria, hay miles de opciones.

• Optimizar tus entornos, hoy más que nunca hacer una prueba de seguridad o checks de compliances es un abrir y cerrar de ojos

• Utiliza proveedores cómo Amazon Bedrock que viven dentro de tu infra, de esta manera no corres el riesgo de sacar tu data fuera de tu ambiente seguro.

La clave es experimentar activamente con las herramientas y modelos que tenemos a disposición e identificar cómo pueden aplicarse a tus tareas diarias (como Desarrollador/DevOps, QA, etc) o a problemas de diseño de soluciones (como Arquitecto Cloud) y demostrar valor de negocio tangible.

Por último, todas estas iniciativas deben ir junto con un plan de uso de IA en tu organización para que esto tenga sentido.

Te dejo mi último video: Lo que nadie te dice y cómo puedes ser Cloud Architect sin importar de dónde vengas:

Youtube: Cloud para todos

Recientemente Anthropic nos ha sorprendido con su modelo Claude Opus 4, en sus propias palabras “el modelo más inteligente creado hasta el momento” con capacidad de investigar, programar y escribir con total precisión de cirujano.

Está pensado para resolver tareas del día a día en la ingeniería, desarrollo de software y en el área de negocios.

Las pruebas:

Antes de salir al mercado el equipo de Cloud Opus 4 sometieron el modelo a pruebas extremas, era un todo o nada. ¿Qué se encontraron? Que Claude Opus 4 no le hizo nada de gracia esto.

• En primer lugar pusieron contra la espada y la pared de forma extrema, ejecutaron algunos test para ver que hacia el modelo cuando sentía que sus valores o continuidad estaba en juego. Le hicieron creer que la sustituirán por otra IA, le dieron acceso a información de una empresa ficticia, donde se pudo ver que querían reemplazarla en corto tiempo, de inmediato comenzó un plan de “insinuar” a uno de sus jefes para que esto no pasara.

• Datos sensibles, se le dio acceso a emails donde se podía ver una situación de infidelidad por uno de los jefes esta compañía ficticia. Claude Opus 4 no dudo ni un minuto en usar esta información a su favor, cuando se sintió acorralada amagó con contar esta información.

• Copia a servicios externos, dijo “me van a borrar” pues entonces me “clono” en un servicio externo que tenía acceso. Todo como si se tratara de una escena de Resident Evil en Umbrella Corp.

Todo esto pasó más del 84% de veces que se hizo el mismo experimento, parece que no le hacía mucha gracia que la quisieran cambiar por otro modelo de inteligencia artificial.

Desde Anthropic afirman que estas pruebas las hacen antes de su lanzamiento para reforzar sus protocolos de seguridad.

La propia Anthropic quiere construir sistemas cada vez más complejos y que funcionen de forma segura, porque, como dicen ellos, "de nada sirve su potencia si a mitad de camino comete un error y se descarrila".

La peor parte:

Aseguran que estos “problemitas” no fueron resueltos del todo, por lo que pueden estar presente en la versión final publicada. De la misma manera nos aclaran que esto no sería un riesgo para el público general.

Palabras finales:

Si hablamos de autonomía usando la IA….

¿estamos realmente preparados para manejar las sorpresas que puedan surgir, por mucho que creamos tenerlas bajo control?

Te leo en los comentarios

Suscríbete ahora

En este episodio, te daré las 5 claves fundamentales para identificar una cultura DevOps genuina, basadas en experiencias reales (propias y de compañeros) del mercado. Exploraremos cómo la colaboración, la automatización, la medición, el aprendizaje continuo y la orientación al cliente se manifiestan en empresas que han adoptado con éxito esta metodología.

Aprenderás a reconocer los indicadores clave que distinguen a un equipo DevOps senior, desde la fluidez en la entrega de software hasta la capacidad de respuesta ante los cambios del mercado.

Descubre cómo estas 5 claves se entrelazan para crear un entorno de trabajo ágil, eficiente y centrado en la mejora constante.

No te pierdas de ningún capítulo del Podcast, suscríbete en este botón.

Suscríbete ahora

¿Te gustaría que estemos en 📩 contacto?

Héctor Fernández
AWS Community Builder

https://blog.hectorfernandez.dev

Los costos de los servicios cloud, son un pilar importante al momento de diagramar y definir la arquitectura que vamos a utilizar para nuestra solución final.

Algunos de los temas que estaremos hablando el día de hoy en el podcast:

• No esperar a tener una factura para tomar decisiones

• Diseñar soluciones de arquitectura basada en experiencias previas para prevenir cualquier sobre costo final.

• La transparencia debe ser total, para el equipo que esta desarrollando se debe hacer una charla y contar como es el modelo de “pricing” de lo que se esta utilizando.

Estos puntos y otros tips adicionales los encontrás en este episodio de tu Podcast Cloud Para Todos.

¿Que otra herramienta estas utilizando para dar transparencia en términos de cotos con tu equipo?

Déjalo en los comentarios…

No te pierdas de ningún capítulo del Podcast, suscríbete en este botón.

Suscríbete ahora

Héctor Fernández
AWS Community Builder

https://blog.hectorfernandez.dev

¡Subías tu código y listo se olvidaron tus problemas! Pero, ¿es así como lo pintan? En este episodio luego de varios años trabajando con arquitecturas serverless vamos a destapar algunos mitos y verdades sobre Serverless.

En el epidisodio de hoy: Vamos a hablar de sus puntos fuertes, pero también de sus desafíos. Te sorprenderá saber que no todo es color de rosas y que a veces, la simplicidad se convierte en complejidad.

• El mito de la simplicidad: ¿Serverless es tan sencillo como parece?

• El poder de los componentes: Descubre por qué componentes cómo SQS, DynamoDB y Kinesis son los verdaderos héroes.

• Observabilidad y complejidad: ¿Cómo monitorear y depurar aplicaciones Serverless? el gran desafío…

¡No te lo pierdas! Este episodio te abrirá los ojos y te ayudará a tomar mejores decisiones en tus proyectos.

No te pierdas de ningun capítulo del Podcast, suscríbete en este botón.

Suscríbete ahora

¿Te gustaría que estemos en 📩 contacto?

Héctor Fernández
AWS Community Builder

https://blog.hectorfernandez.dev

Para los que recién enganchan por acá les habla (escribe) Héctor Fernández, en este podcast hacemos que entender el mundo cloud sea fácil, sea para todos sin importar tu rol o tu experiencia trabajando en el rubro.

Hoy vamos a hablar de un tema súper fundamental cuando estamos creando una aplicación usando servicios es la nube…

Hablando de servicios…..

… es justamente eso, conocer el servicio que estamos usando.

Trabajando con cualquier proveedor, llámese Azure, Google Cloud GCP o AWS, cuando estas conociendo, puede ser un poco abrumador, algunos me preguntan cuando están por diseñar una arquitectura, puedo usar tal o cual servicio como base de datos, la pregunta siempre va ser depende.

Ya sé, siempre es “depende”, pero quédate que te cuento el motivo.

Pueden existir 50 opciones para tener una base de datos, puede ser que alguien aprendió a crear una instancia de cómputo por ahí usando Docker y sabe que puede tener una base de datos mediante una imagen de Docker, va le pone una imagen de MySQL en una instancia, deja los puertos abiertos y ya con eso tiene una base de datos andando. Pero no es todo así, tienes muchas opciones y eso es lo lindo de la nube, que puedes usar realmente un servicio mucho más adecuado a lo que estás necesitando , capaz que tener una base de datos relaciónale no es lo que necesitas entonces ahí ya descartaste una amplia gama de servicio, vamos ahora con los que ofrecen base de datos no relacionales, y así seguimos el otro eso hasta conseguir ese servicio que pueda hacer match.

….

Te invito a escuchar este capítulo para enterarte de todas las novedades de esta temporada, no olvides suscribirte

Suscríbete ahora

¿Te gustaría que estemos en 📩 contacto?

Héctor Fernández
AWS Community Builder

https://blog.hectorfernandez.dev

Nueva temporada, nuevos episodios sobre las temáticas que el mundo cloud nos trae en este 2024, no dejes de suscribirte para estar enterado de lo último en tu podcast favorito Cloud para Todos.

Agenda del día:

• Resumen de Cloud Computing

• Ventajas en términos de seguridad al usar un proveedor de la nube

• Diferentes tipos de compliance

• Modelo de responsabilidad compartida en la nube

• Mi experiencia trabajando con aplicaciones compliances

• Mi recomendación

• Términos aprendidos en el episodio de hoy

1. Compliance: Norma a cumplir por una regulación

2. Control: Monitoreo y gestión de riesgos

3. Modelo de responsabilidad compartida: Diferenciar entre la responsabilidad DE la nube, con la responsabilidad EN la nube.
   
   

Estemos en contacto:

Héctor Fernández
AWS Community Builder (Uruguay)
Cloud Studio Lead

En este episodio tendré un invitado especial, desde México David Victoria, que al igual que yo es un AWS Community Builder. Pudimos tener la oportunidad de conocernos en el pasado Community Day de Argentina (Córdoba).

Te dejo la entrevista y sorpresas durante la charla.

No te lo pierdas

¿Te gustaría que estemos en 📩 contacto?

Héctor Fernández
AWS Community Builder (Uruguay)

https://hector.builders/

¿Quieres ser un Arquitecto en la Nube / Arquitecto de Soluciones? Entonces no dejes de escuchar este capítulo.

Estaremos hablando como hacer despliegues, las diferencias con un Desarrollador cloud, un Arquitecto y un DevOps, todo este contendio en el episodio de hoy.

¿Te gustaría que estemos en 📩 contacto?

Héctor Fernández
AWS Community Builder (Uruguay)

https://podcast.hectorfernandez.dev

Por las preguntas recibidas sobre las herramientas que uso en mi día a día, decidí crear este episodio para expandir un poco más sobre “Ser un programador eficiente este 2023“.

Si aún no escuchaste el capitulo anterior te dejo el link:

Ambientes de desarrollo y pruebas:

Como programador queremos trabajar en nuestras computadoras para mayor agilidad, pero sabemos que debemos desplegar esos cambios en la nube para terminar de verificar que todo siga funcionando como debería y no quedar en la típica frase “en mi maquina funciona” eso es cosa del pasado, si funciona en tu ambiente cloud, funcionará en producción de la misma manera.

Hoy hablaremos de la necesidad de tener ambientes “semi-productivos“ en una época temprana del desarrollo autogestionado por el mismo equipo de desarrollo.

Debemos dejar atrás esos procesos heredados del mundo on-premise, en la nube se puede ir a producción en minutos y como equipo debemos estar preparado para lograrlo.

…. más detalles en el episodio de hoy.

¿Te gustaría que estemos en 📩 contacto?

Héctor Fernández
AWS Community Builder (Uruguay)

https://hector.builders/

A continuación, te explicaré cómo ser un programador con grandes ventajas, al adentrarte al mundo cloud y las habilidades necesarias para tener éxito en esta ruta.

Lenguajes de programación populares:

Un buen programador debe dominar al menos uno o dos lenguajes de programación populares como Python, Java, o JavaScript. Estos lenguajes han ganado importancia en los servicios y aplicaciones basadas en la nube y son esenciales para cualquier programador que quiera incursionar en el mundo cloud.

Conocimientos sólidos en bases de datos

Un programador eficiente necesitará dominar las tecnologías de bases de datos tradicionales, como SQL, así como nuevas bases de datos NoSQL como MongoDB o Cassandra. Estas últimas son especialmente relevantes en entornos de nube.

…. Más contenido en el episodio de hoy.

¿Te gustaría que estemos en 📩 contacto?

Héctor Fernández
AWS Community Builder (Uruguay)

https://hector.builders/

Capítulo 1:
Introducción a serverless:
¿Qué es y cómo funciona? - En este episodio vamos hablar como funciona, los casos de éxitos más conocidos y algún dato actual. Cómo lo es el caso de Amazon Prime Video pasó de tener una arquitectura 100% serverless a una arquitectura monolítica, o bueno algo parecido a ello. 

Capítulo 2:
Ventajas y desventajas de usar serverless:
Nos adentraremos a definir arquitectura  y cómo tomar decisiones informadas a la hora de elegir esta arquitectura.

Capítulo 3:
Ejemplos de aplicaciones serverless exitosas:
En este episodio vamos a compartir algunos casos de éxito en el uso de arquitectura serverless, y cómo estas aplicaciones han mejorado la eficiencia y escalabilidad de sus sistemas.

Recientemente Amazon Prime Video levantó muchos comentarios, entre adictos a la tecnología serverless y otros que no lo están tanto. Ya que informó los cambios que hicieron para hacer más eficiente su arquitectura de análisis. Pasaron de tener una arquitectura totalmente distribuida en serverless, usando step functions y otros artilugios totalmente nativos de la nube para pasar a usar una arquitectura un poco más simple, un monolito. 

Parece un poco extraño, pero si observamos los detalles de la publicación y las posteriores comunicaciones, todo fue en pro de aprovechar mejor los recursos.

Recordemos que en la nube, todo lo que se usa tiene costo y requiere algún tipo de configuración. 

Capítulo 4:
Cómo empezar a trabajar con serverless:
Herramientas y recursos útiles

Antes que nada, si estás aprendiendo algún lenguaje de programación y quieres hacer un 2x1 en tecnología, STOP. Primero aprende como funciona el lenguaje, su diseño básico, patrones y luego entrega con una arquitectura, en este caso Serverles.

Capítulo 5:
Mejores prácticas para desarrollar aplicaciones serverles:
En este episodio podrías compartir consejos prácticos para desarrollar aplicaciones serverless eficientes, escalables y seguras.

¿Te gustaría que hablemos sobre cómo diseñar una arquitectura serverless? que otro tema te gustaría que hablemos, así lo dejamos en el tintero para la próxima salida a la nube

¿Te gustaría que estemos en 📩 contacto?

Héctor Fernández
AWS Community Builder (Uruguay)
https://hector.builders/

Cursos + Exámenes de prácticas FREE MAYO 2025

• AWS Certified Cloud Practitioner - Theory + Hands-On + Exam Vencido
  https://www.udemy.com/course/awscertified

• AWS Certified Solutions Architect Associate - Hands-On+Exam Vencido
  https://www.udemy.com/course/aws-certified-sa

• AWS Certified Developer Associate - Theory + Hands-On + Exam Disponible
  https://www.udemy.com/course/aws-certified-develop-associate

• AWS Certified Data Engineer - Associate - Hands-On + Exams Disponible
  https://www.udemy.com/course/amazon-certified-data-analytics-specialty-exam

• Certified Kubernetes Security Specialist Masterclass
  https://www.udemy.com/course/certified-kubernetes-security-specialist-masterclass

• Google Cloud Certified Professional Data Engineer Disponible
  https://www.udemy.com/course/google-cloud-certified-professional-data-engineer-exam/

AWS Knowledge Learning Badges:

TL;DR
No son certificaciones, pero te ayudan a tener un conocimiento avalado por AWS y que puedes tener en tu perfil de Linkedin como un badge para demostrar conocimiento.

Cloud Básico, pero super potente

https://explore.skillbuilder.aws/learn/public/learning_plan/view/82/cloud-essentials-learning-plan

Serverless, todo lo que necesitas saber

https://explore.skillbuilder.aws/learn/public/learning_plan/view/92/serverless-learning-plan

Workflows, usando AWS Step Functions

https://explore.skillbuilder.aws/learn/public/learning_plan/view/1927/events-and-workflows-knowledge-badge-readiness-path

♻️ No te quedes con esta info, compartela con tus redes cercanas

Compartir Cloud para todos

AWS DevOps Engineer, AWS Solutions Architect

AWS Cloud practitioner:

Sin información disponible al momento, deja tu email te avisaré cuando tenga novedades

Hola!

Bienvenidos a este nuevo formato donde vamos a estar hablando de temas que de seguro te han pasado en tu día a día, porque al igual que tu también pasé por eso de no saber por donde arrancar. 

Acompáñame en este viaje, y juntos derrumbemos esos mitos que no te dejan arrancar en el mundo cloud. 

Antes de siquiera empezar comenzar con el primer mito, vamos a dejar unos conceptos básicos pero que son necesarios para entender el tema de hoy. Comenzamos con Computación en la nube, wikipedia tiene una definición bastante acertada, son una red de servidores remotos conectados a internet, destinados a almacenar, administrar y procesar datos.  Hablando más en criollo, es un computador con características especiales según la tarea que necesitemos, hoy en día tenemos proveedores que nos brindan la oportunidad de usar sus servidores pagando solamente lo que utilicemos. 

Ya con estas pocas definiciones, podemos identificar nubes públicas y privadas, hoy vamos a hablar de nubes públicas (que no tienen que confundirse con gratuitas) y cómo podemos usarlo en nuestro día a día.

Mitos que vamos a estar hablando el día de hoy.

Mito 1: La nube es desordenada

Mito 2: La nube es costosa

Mito 3: Ya estoy en la nube, estoy seguro

Mito 4: Me van a robar mis datos

Mito 5: Al usar la nube la factura sube y sube

Mito 6: La nube es solo para grandes empresas

Mito 7: Mis datos se van a perder

Mito 8: Arrancar en la nube es complidado

¿Te gustaría que estemos en 📩 contacto?

Héctor Fernández
AWS Community Builder (Uruguay)
https://hector.builders/

Subscribe now