the ugly organization

desu #1 11 Mar

WE

write ugly code to solve one problem
embrace the ugly odyssey
are truth

TRUTH NOT LIES

ugly simplicity not beautiful complexity
ugly replaceable not beautiful reusable
ugly gardeners not beautiful architects

Find us here: dqk5k2hnalqa1.cloudfront.net

objectives of the diary

focus on software engineering more than code and tooling specifics
a product that works

product

first mvp
- our product will be a frontend, a link aggregator for /dev blog posts or resources
- we will have a thread in /dev that we will scrap every hour to refresh our aggregator
- we will make use of Mediavida user system and voting system to start
- our frontend will just scrap the content and show it in a ranking in a pretty way

future ideas
- add "users and voting capabilities with other mechanisms" so we do not depend on /dev only
- add features like automatic tagging for the content
- add feature to summarise content of the links and show a preview in our aggregator
- add feature to filter by tags, filter by time of contribution...
- add a search or custom chat bot to our aggregator, we could ask the question "what is a pointer?" and get relevant links
- improve TROLLING / SPAM detection mechanisms
- ... see how all of this are backend powered ideas

code

All code available under: https://github.com/uglyorganization/

aws: terraform to manage aws infrastructure.
backend: golang backend.
frontend: frontend, html and javascript.
cron: this cron-content-generator, as the name suggest generates content for our frontend, this method keeps all our code static.

context

in order to make engineering decisions we need a context, this context will evolve every iteration and is open to suggestions.

Initial context:

assume we are an early startup, 5 employees.
assume we have one end-user facing product, mobile, front-end.
assume we have \~100s daily users and growing.
assume we have an initial capital or a small equity private round to survive 1 year.
assume we use https://aws.amazon.com/startups or similar. we decided to use aws.

We will simulate events like:

What happens if we have an incident? How do we troubleshoot and fix the issue?
What happens if we receive traffic bursts?
How do we monetise? Assume an initial MMR and stakeholders feedback (you).

8

desu #2 11 Mar

day 1:

resultados

problemas que me he encontrado

notas

1 respuesta

carracho #3 11 Mar

This is a spanish forum bro... go home!

1 respuesta

crb2222 #4 11 Mar

Pero tu no vivias en China? Porque se te han configurado los buckets en EUWest

7

desu #5 11 Mar

#3 quiero tener #1 en ingles. porque me gusta como se lee el manifesto del "código feo". todos lo demas en español. y en el futuro lo quiero re-utilizar.

Sobre el diario en si, la duración sera de 1 mes con update diarios.

Por mi parte hablare poco ademas de esto. Que quien quiera pregunte o se discutid entre vosotros libremente, si algo es relevante lo tocare en código y en el siguiente update relevante. Si me gusta una idea o un fix la implementare sin problema. PR y CR bien recibidos.

Seguimos mañana.

1 respuesta

squ4r3 #6 11 Mar

#5 veo que te gusta vivir peligrosamente

run: terraform apply -auto-approve -input=false

has pensado en ejecutar un plan en cada PR a main para evitar YOLOear cambios a infra?

Normalmente yo hago plan en pr, apply en pr, y después del apply es cuando se mergea a main. Porque el hecho de que el plan funcione no significa que el apply vaya a funcionar. Hay herramientas como Atlantis que facilitan esto.

también movería la ID de tu cuenta de AWS a una env var al menos , para evitar information disclosure si el repo va a ser público.

no conocía lo del random_id de terraform, me la apunto

1 respuesta

JuAn4k4 #7 11 Mar

Terraform es una mierda (Horrorform lo llaman), usa Pulumi y así tienes todo en go.

Espero que estes usando assume role para ejecutarlo y no vayas con los root credentials por ahí pululando, que se te cuelan por algún lado y te soplan KK€ enseguida minando bitcoins

1 respuesta

desu #8 12 Mar

Resumen del día 2:

spoiler

Cuestiones destacadas:

spoiler

2

kokre #9 12 Mar

Pues con TF empieza regular la cosa. Todo en un solo fichero, sin separación por directorios y sin módulos

En cuanto crezca un poco más se hace inmantenible

1 2 respuestas

JuAn4k4 #10 12 Mar

#9 Es ugly org, no has leído el manifiesto ? Si no hace falta modulo, no hace falta.

1

desu #11 13 Mar

Resumen del día 3:

spoiler

Cuestiones destacadas:

spoiler

PS: chatgpt para spelling

Para terminar agradecer a todos los que seguis el hilo, mucha gente me pregunta, ayuda y sugiere ideas por privado tambien.

desu #12 13 Mar

Resumen del día 4:

spoiler

GaN2 #13 13 Mar Inocente

#2

al tener terraform el estado, no puedes borrar las cosas a mano, asi que he creado una acción en GitHub para destruir recursos

Entonces para usáis TF si la gestión de estados os la pasáis por el forro de los cojones? Para eso no uséis TF por amor de Dios, luego que si sobre ingeniería…

2 1 respuesta

desu #14 14 Mar

Resumen del día 5:

spoiler

cuestiones variopintas

spoiler

1 respuesta

desu #15 14 Mar

update

he pillado a mitchellangelo creador de terraform y demas q tambien lleva un tiempo que no caga con nix y me ha dicho que soy un fpero sin remedio. le he tenido que poner en su sitio. (me han echado del discord).

dicho esto, os comparto el planning para este finde y la semana que viene, va cargadito. Nuevo repo y nueva infrastructura que tenemos que montar. Creo que este sera interesante de seguir ya que literalmente vamos a hacer solo ugly code para montar todo, nada de logica de producto/negocio jaja.

Le he pedido a ChatGPT que me haga un resumen para vosotros.

spoiler

### 1. AWS Architecture: HTTP Request Flow

The diagram below illustrates the journey of an HTTP request to your Gin backend hosted on an EC2 instance, secured with an ELB (Elastic Load Balancer) that facilitates HTTPS connections through ACM (AWS Certificate Manager).

[User] --HTTPS--> [ELB (HTTPS)] --HTTP--> [EC2 Instance (Gin Backend)]

User: Initiates an HTTPS request to the domain.
ELB (HTTPS): Receives the HTTPS request. The SSL/TLS certificate provided by ACM ensures a secure connection. The ELB then forwards the request to the EC2 instance(s) as HTTP.
EC2 Instance (Gin Backend): Hosts the Gin application. It processes the request and sends back the response through the ELB to the user.

2. Deployment Architecture Using Terraform and GitHub Actions

The following outlines how Terraform and GitHub Actions work together to deploy your containerized Gin backend to AWS.

Terraform AWS Management:

Terraform: Manages AWS resources like EC2 instances, ELB, and ACM certificates through Infrastructure as Code (IaC).
AWS: Hosts the resources managed by Terraform, ensuring that the infrastructure matches the desired state defined in the Terraform configuration.

GitHub Actions Deployment Workflow:

Push to Main Branch: Triggered by a git push to the main branch.
Build Docker Image: Builds the Docker image of your Gin application.
Push Docker Image: Pushes the built Docker image to a Docker registry (e.g., Docker Hub).
Deploy Using Terraform: Applies the Terraform configuration to provision/update AWS resources.
SSH and Docker Deployment: Uses SSH to access the EC2 instance(s) and deploys the Docker container running your Gin backend.

+-------------------+    +-----------+    +-------+    +-----------+
| GitHub Repository | -> | GitHub    | -> | Terraform | -> | AWS        |
| (Gin Application) |    | Actions   |    | (IaC)   |    | Resources |
+-------------------+    +-----------+    +-------+    +-----------+
                                     \        |
                                      \       |
                                       \      |
                                        \     v
                                         \ +------+
                                          \| EC2   |
                                           | (SSH) |
                                           +------+

Deployment Flow (Table Format):

Step	Action	Tool/Service	Description
1	Push to Repo	GitHub	Trigger deployment by pushing to the main branch.
2	Build Image	GitHub Actions	Build the Docker image of your Gin app.
3	Push Image	GitHub Actions	Push the image to a Docker registry.
4	Terraform Apply	GitHub Actions & Terraform	Deploy/update AWS resources as per Terraform configuration.
5	SSH & Deploy Container	GitHub Actions & EC2	SSH into EC2, pull the Docker image, and run the container.

This setup encapsulates the flow from code push to deployment, highlighting the integration of Terraform for infrastructure management and GitHub Actions for continuous integration and delivery.

Todo esto con su role y su policy minima con AssumeRoleWithWebIdentity para github y cada repo. No se si esto es la manera mas correcta y segura la verdad. Para cada repositorio, un rol y una policy para desplegar con ssh a una o multiples instancias ec2 de ese servicio.

Los objetivos son:

tener HTTPS en nuestros servicios
tener el devops requerido para montar todo de manera segura

Futuros problemas:

tener HTTPS en multi entornos dev/pre/pro, como testear en local...
tener devops para multi entornos dev/pre/pro, escalar o reducir instancias

kokre #16 14 Mar

Lo del rol por repo es así, lo que entiendo que la policy que ha de tener es para que pueda modificar la infra en AWS. Para hacer un ssh no necesita ningún tipo de policy ya que no hace una llamada a la API de AWS.

Por otro lado, entiendo que la instancia en cuestión ha de tener una IP pública o DNS name público, sino, la GitHub Action no podrá conectar

1 respuesta

squ4r3 #17 14 Mar

lo suyo es conectarte usando SSM y dejar que AWS haga su magia, así no tienes que tener ip pública ni escuchar en el 22

https://github.com/marketplace/actions/aws-ssm-send-command

1 respuesta

kokre #18 14 Mar

#17 joder, cierto. Cómo hace poco que lo descubrí, me olvido siempre de tirar SSM que diría que todas las AMIs Amazon Linux lo traen incorporado

1

desu #19 14 Mar

#16kokre:
lo que entiendo que la policía que ha de tener es para que pueda modificar la infra en AWS.

Tenemos un rol en AWS llamado github-aws que tiene permisos para tocar la infra en el repo de aws
Este tiene una policy attached para los permisos.
Este al igual que todos los otros roles, lo puedes ver en terraform, usa AssumeRoleWithWebIdentity para que solo se pueda ejecutar desde github actions.
```
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "Federated": "arn:aws:iam::${var.AWS_ACCOUNT_ID}:oidc-provider/token.actions.githubusercontent.com"
            },
            "Action": "sts:AssumeRoleWithWebIdentity",
            "Condition": {
                "StringEquals": {
                    "token.actions.githubusercontent.com:aud": "sts.amazonaws.com"
                },
                "StringLike": {
                    "token.actions.githubusercontent.com:sub": "repo:uglyorganization/aws:*"
                }
            }
        }
    ]
}
```

Así para cada repositorio en nuestro github que interactúa con nuestra cuenta AWS_ACCOUNT_ID, tenemos el AssumeRoleWithWebIdentity en el rol para es repositorio concreto, y ademas una policy única. 1 rol = 1 repo = 1 policy.

La convencion que sigo es github-REPOSITORY_NAME.

#16kokre:

Para hacer un ssh no necesita ningún tipo de policy ya que no hace una llamada a la API de AWS.

No entiendo a que te refieres. Para el ssh necesitamos una policy con la accion ssm:StartSession. Seria algo asi, aun no lo he hecho:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "ec2:DescribeInstances",
      "Resource": "*"
    },
    {
      "Effect": "Allow",
      "Action": "ssm:StartSession",
      "Resource": "arn:aws:ec2:region:account-id:instance/instance-id",
      "Condition": {
        "StringEquals": {
          "ssm:resourceTag/Name": "YourEC2TagName"
        }
      }
    }
  ]

No se si esta completa esta policy statement, es un ejemplo que tengo preparado para manana.

#16kokre:
Por otro lado, entiendo que la instancia en cuestión ha de tener una IP pública o DNS name público, sino, la GitHub Action no podrá conectar

No hace falta, para exponer el servicio el DNS voy a usar el publico del ELB para montar el certificado SSL y tener HTTPS. La alternativa y recomendacion seria tener un dominio propio, pero de momento no pago nada.

Para la action es lo que explico arriba de todo.

kokre #20 14 Mar

Nah, ni caso. No recordaba el servicio SSM. Viejos vicios de cuando no existía esa opción

desu #21 14 Mar

no worries, todo comentario bien recibido, y si alguien quiere comentar como se hacia en el pasado es un gran punto de vista comparar ambas opciones.

porque estamos con aws y github que todo se integra fácil, pero saber como hacerlo de otras maneras nos sirve para montar cosas in-house, u otros proveedores...

la suciedad mas importante que tenemos que hacer primero es:

(done) seguridad entre componentes con oauth, roles, policies, y similares...
(wip) encriptacion con https, certificados, rotacion de certificados
logs
metricas
alarmas
(done) ci y cd (wip)

Todo esto son requerimientos mínimos antes de picar una sola linea de negocio que sirva para algo. Y y después vendrían encima los problemas operacionales típicos:

versionado de productos, rollbacks y despliegues a versiones concretas
multi entorno, sportar dev/pre/pro
escalado vertical y horizontal de recursos (i.e cambiar instancias, incrementar o disminuir instancias de un servicio)
cambiar recursos (i.e quiero cambiar una dynamodb por un s3, quiero cambiar la distribution de mi frontend)
transformación de la arquitectura (i.e quiero anadir una cache delante de mi dynamodb o quiero quitarla)

todo lo operacional de segundo nivel, debe funcionar con los requisitos de primer nivel y tenemos que tener garantizar 0 downtime de nuestros servicios.

no se si me he dejado algún requerimiento mínimo de desarrollo o producción.

1 respuesta

JuAn4k4 #22 15 Mar

#21 ¿ Lo quieres hacer todo gratis ?

1 respuesta

desu #23 15 Mar

Resumen del día 6:

tengo este repo para nuestro nuevo producto que ya explicare en que consistira: https://github.com/uglyorganization/backend-lxd
ando haciendo toda la infra y workflows que comente en #15
en el resumen de #15 veo que chatGPT se dejo de comentar el VPC y los grupos de instancias, pero bueno, se entiende.
primer paso tener el package https://github.com/uglyorganization/backend-lxd/pkgs/container/backend-lxd
cada vez que mergeo a main se crea un tag, este tag se publica, cuando se publica el tag otra action crea el package con el container
mi aws no tiene submodulos, pero si he creado ficheritos jaja menuda ostia de realidad el networking de aws, vpcs, nat, azs... pff a ver que monto

cuestiones

#22 no es ese el objetivo. tenemos dos grupos de ideas principales de exploración:

primero ingenieria en diversos escenarios:

tengo unos números hechos comparando fargate/api gateway/elb+ec2 y como evolucionan en distintos casos.
ahora estoy haciendo la solución barata, barata en dinero, pero cara en recursos humanos.
en que casos es mejor usar un producto u otro? en que tipos de empresas? para que tipos de productos?
si tu producto es un frontend y captar usuarios pues paga un api gateway y desarrolla features.
diria que para la gran mayoria de productos que quieras hacer, el primer anyo o segundo de vida te compensa no mirar el dinero y solo centrarte en ganar dinero y usuarios.
pero a la que la empresa ya esta establecida, ahi es donde empieza a importar la optimizacion de recursos.

luego juegamos con los principios fundamentales de código sucio y la jardinería obtenemos:

tenia un repo "frontend", lo cambie a otro repo "fronten-dev" porque tardaba menos en tirarlo que en adaptarlo
preferencia por el código estático, compilado, generado > codigo runtime, javascript, usar apis
- por ejemplo: frontends ligeros y estáticos que se generan, podríamos tener 1 frontend dedicado a 1 usuario todo estatico y seria gratis y rapido
- podemos ir a mas, usando github runners como lambdas, proxies, api gateways "gratis" de orquestracion, tenemos 2000 minutos gratis al mes de CPU, solo con github runners puedes montar una empresa que sirva frontends y tenga backends en cron jobs. hasta tienes github pages para el frontend.

aquí juego mucho con la idea de, para que voy a tener una api para hacer cruds? si puedo llamar de un repo a otro directamente y cambiar los datos en build time? jaja

1 respuesta

JuAn4k4 #24 15 Mar

#23 Eso lo hizo uno con su web de vender coches (miniaturas), tenia una spreadsheet con los coches que podía vender y tal, y en un cronjob generaba la web en HTML estático. El actualizaba el google sheets los coches que le iban llegando y los enviaba. Cumplí con ugly organization.

1 respuesta

desu #25 15 Mar

#24 La realidad es que para la gran mayoría de frontends de consultar datos... es la mejor opción.

ranteo random

Que datos requieren una consulta 24/7 en tiempo real de millisegundos o segundos? Datos de maquinas en una fabrica, paneles de monitorización de alarmas... Existen casos de uso claro que si. Existen casos de uso donde el tiempo real y el "near" tiempo real son importantes. He trabajado muchos anyos en ellos...

Ahora existen otros muchos casos para usuarios normales, la mayoría de datos que se consultan por humanos pueden ser refrescados cada 5 o 10 minutos por ejemplo sin percibir ningún impacto, un numero que en software y hardware no es nada, y todo iría bien. Y muchísimos datos pueden ser refrescados cada X horas. Por ejemplo, tienes una tienda de piezas de vehículos que te llegan repuestos... paginas de descuentos u ofertas... planificadores de viajes y similares... Lo que estas paginas requieren en todo caso es un sistema de PUSH, cuando haya nuevos datos frescos que me lleguen. Pero no requieren un frontend que consulte datos o sea capaz de consultar datos (AQUI EL QUID DEL ASUNTO), que el defecto es hacer lo segundo.

El problema es que hoy en día le ensenyan a los chavales que un frontend tiene que hablar con una api... hace peticiones... Pues no hace falta. Yo no lo he hecho. El primer front end, el mas básico, tiene los datos estáticos. Y tu no te preocupes como llegan estos datos, hay maneras de hacer push, y si tienes compilación incremental, tardaras menos de 1 segundo en compilar tu frontend, y tardaras pocos segundos en deployear una nueva version a prod. Cuanto tardas en integrar y mantener una API rest en constante cambio?

Pues yo hago la guarrada, el código sucio, mi frontend se genera cuando hago trigger en github, y me quedo tan pancho, y no solo eso, sino que estoy q te genero 1 frontend para cada 1 de mis usuarios y me quedo tan chill. La conclusión es que mi código pesa 5kb y va volando sin javascript, solo requeriría un simple auth. y tu estas picando cosas que no hacen falta hoy en día.

Esa seria un poco la inspiración y la filosofía detrás del primer producto, y del segundo que vamos a hacer la semana que viene. Si un frontend son 5kb, tengo 1000 usuarios, lo meto todo en un S3 y sirvo con una cdn, que coste tiene eso? Versus el coste de tener un super frontend complejo con auth, datos dinámicos, api rest, bases de datos, seguridad etc.

PS: Y claro podriamos hacer SSR, pero eso que tiene de divertido? jaja

desu #26 15 Mar

Hago update, me he peleado bastante con el networking de AWS, no tengo ni puta idea de nada de lo que hago. Creo que estoy cerca pero no veo el fallo. Este finde le dare una vueltecita, a ver si alguien me echa un cable si ve el error.

En teoria esta todo montado, y tenemos una pipeline que mediante SSM nos va a desplegar nuestro "backend-lxd" a instancias de ec2. No me va.

An error occurred (AccessDeniedException) when calling the SendCommand operation: User: arn:aws:sts::***:assumed-role/github-backend-lxd/GitHubActions is not authorized to perform: ssm:SendCommand on resource: arn:aws:ssm:eu-west-1::document/AWS-RunShellScript because no identity-based policy allows the ssm:SendCommand action
Error: Process completed with exit code 254.

Me falla algun permiso pero no lo veo.

Estos son todos nuestros recursos en AWS gestionados con terraform (terraform list), relacionados:

spoiler

no lo veo, voy a quizas sacar que mi rol solo pueda modificar las instancias de backend-lxd... he visto en un coment que daba error a otra gente, pero no entiendo xq deberia ser el motivo. creo que me falta alguna cosa sobre el ssm pero no lo veo.

desu #27 15 Mar

he estado 4 horas para esto:

aun no me funciona porque no me encuentra las instancias pero ya no dice que no tengo el permiso...

madre mia, quien entienda esto jajaja

no es lo mismo tener todo en 1 statement que en 2 statements, entiendoque por el condition... pero tio... vaya puto error de mierda me ha devuelto AWS macho. voy a crearles una issue en github para que lo arreglen.

desu #28 16 Mar

transparencia empresarial.

la factura de esta semana:

de donde viene el coste?
https://repost.aws/articles/ARknH_OR0cTvqoTfJrVGaB8A/why-am-i-seeing-charges-for-public-ipv4-addresses-when-i-am-under-the-aws-free-tier#

asi que tenemos un coste 0,120 euros al dia, * 30 dias, 3,6 euros al mes por tener una ip publica.

y ya que comparto cosas la infra que hemos montado:

3 zonas en europa, publicas y privadas, decide hacerlas chicas. para cada zona que soporta nuestra region.

una public routing table para exponer nuestro trafico de las subnets publicas a la internet gateway (IGW)

troubleshooteando launc_template y el ssm

al actualizar un launch_template para cambiar la instancia, terraform hace el plan y el apply, pero en lugar de recrear la instancia que es lo que quiero, te crea un nuevo "template", pero no lo aplica y tampoco es el default... le he metido este camp update_default_version = true
he descubierto que aunque mi output no muestre "targets".

    "Command": {
        "CommandId": "b7d0d95c-738a-40d0-9850-64f4ed85524a",
        "DocumentName": "AWS-RunShellScript",
        "DocumentVersion": "$DEFAULT",
        "Comment": "Deploying tagged release v0.1.12 to BackendLXD",
        "ExpiresAfter": "2024-03-16T12:05:59.695000+00:00",
        "Parameters": {
            "commands": [
                "docker pull ghcr.io/uglyorganization/backend-lxd:v0.1.12",
                "docker stop backend-lxd",
                "docker run -d --name backend-lxd --restart=always -p 8080:8080 ghcr.io/uglyorganization/backend-lxd:v0.1.12"
            ]
        },
        "InstanceIds": [],
        "Targets": [
            {
                "Key": "tag:Name",
                "Values": [
                    "BackendLXD"
                ]
            }
        ],
...
}

Si busco el command aws ssm list-command-invocations --command-id b7d0d95c-738a-40d0-9850-64f4ed85524a --details si que me aparecen las 2 invocaciones. Tansolo q me fallan, pero bueno, ahora funciona.

He tocado tambien el data_utils.sh para usar yum en mi maquina linux, porque el otro comando amazon-extras o algo asi fallaba.

al final he levantado los dockers a mano metiendome por ssm, todo funciona y puedo hacer curl a la dns publica pero la pipeline automatica aun no esta en su sitio. pero funcionar funciona. hacemos peticion a nuestro dns, llega al balanceador, lo reparte a nuestras instancias y recibimos respuesta. perfecto.

curl -i http://backend-lxd-XXXX.eu-west-1.elb.amazonaws.com/health
HTTP/1.1 200 OK
Date: Sat, 16 Mar 2024 11:15:32 GMT
Content-Length: 0
Connection: keep-alive

desu #29 18 Mar

Segundo sprint dia 1:

Primero disculpas que no haya podido terminar bien el primero, montar la network en AWS me ocupo mas de un día, cambio de prioridades.
Aquí es como lo tenemos, como nos gustaría tenerlo
- frontends con cdn y s3 todo automatizado, https y todo bien ok
- arquitectura con alb, security group, lb targets, ec2 etc
  - falto el deploy automático de github (lo hice a mano xd),
  - https y
  - me falto meter una db en la red privada
No tengo HTTPS aunque sea un must, porque me centre en las operaciones de deployear todo automatico y terraform.
Se podria haber hecho en paralelo si no lo hiciese solo
La DB pues es menos prioritaria que el HTTPS.

antes de terminar la segunda arquitectura, voy a montarla igual pero usando https://aws.amazon.com/es/api-gateway/
- para cosas publicas API Gateway es interesante
otra alternativa que me han sugerido, seria una opción intermedia con Fargate: https://aws.amazon.com/es/fargate/
- fargate para cosas privadas puede ser interesante, si vas a usar Fargate para exponer cosas como sugirieron no lo veo, mejor API Gateway que te lo hace todo, o hacerlo tu a mano como en la arquitectura anterior

Es una decision un poco a ojimetro, viendo los costes bases. Sin carga de trabajo real y peticiones y consumo de bandwith real no se puede hacer estimaciones buenas.

Lo que hago es para cada uno de mis escenarios suponer un numero de peticiones y usuarios:
https://blogs.perficient.com/2021/06/17/aws-cost-analysis-comparing-lambda-ec2-fargate/

En esta comparación de 2021, podéis ver que no es todo lineal y cristalino.

Y por lo que hacen los "costes operacionales" de mantener, desarrollar escalar y tal:

ec2 son los mas caros al gestionar todo a mano.
lambda mayor coste de desarrollo y acoplamiento al ser serverless.
fargate es el intermedio que quita costes de operacion de ec2 sin tener que tocar codigo.

Según el análisis de arriba: lambda > fargate > ec2
Según si necesitas 1/4 de 24h, 1/2 de 24h o 24h de cpu al día.
Pero, no tenemos en cuenta el coste operacional en esos costes, que este es el difícil de calcular.

1 respuesta

aren-pulid0 #30 18 Mar

#29 no expongas tus instancias a internet, si vas a usar ALB mete tus instancias a una private subnet, en caso de que necesites que tengan acceso a internet lee acerca de NAT Gateways

1 respuesta

the ugly organization - we write ugly code