Tras muchos años asumiendo problemas ajenos como míos siendo empleado decidí crear una empresa que se dedicara a ello. A lo largo de mi carrera he visto (y perpetrado) cosas que no creeríais pero, al final, la realidad es que la mayoría de empresas tienen problemas muy similares y se suelen cometen errores muy parecidos en todas partes, independientemente del sector, tamaño o perfiles de los equipos. En esta charla nos centraremos en los errores más comunes que se cometen al implantar metodologías DevOps y cómo intentar evitarlos. Porque DevOps no es un puesto, ni un equipo, ni un proyecto, ni algo que se pueda comprar e instalar. Porque no necesitas ser una FAANG para aprovecharte de las muchas cosas positivas de estas filosofías. Y incluso en las FAANG reconocen haber cometido muchos de estos errores.

1. DEVOPS: NO ERESTAN ESPECIAL
¡No cometas estos errores!

2. HOLAVIGO
• Consultor independiente de problemas ajenos en Rigor Alliance
• Ex-CTO Holaluz, tech lead de Hailo,Wonga, Socialpoint, Ulabox…
• Organizador devops.barcelona, php.barcelona, Creador de Ansistrano
• “Haciendo DevOps” antes de que estuviera de moda
• Empecé con Cobol hace 20 años para Banc Sabadell (corbata incluida)

3. ¿POR QUÉ ESTA CHARLA?
• Problemas similares en la mayoría de empresas
• Todo es cada vez más complicado de arrancar y cuesta ver bene
fi
cios
• Siguen apareciendo nuevos retos sin saber bien cómo afrontarlos
• No hay “silver bullets” ni todo el mundo está en el mismo momento
• Un poquito de “rant talk”

4. ¿DEVOPS ES PARA MÍ?
• Implementar DevOps al 100% es una inversión alta
• Ni todos los equipos son igual de grandes ni tienen igual expertise
• Se pueden hacer cosas para introducirlo gradualmente
• Hay muchos bene
fi
cios pero, como Agile, no es “un proyecto”, es una
fi
losofía de trabajo

5. PROMESAS ROTAS
• Desarrolladores y Sistemas / Operaciones trabajando juntos
• Deploys más rápidos y seguros, agilidad en la infraestructura
• Automatización prácticamente total con, eventualmente, No-Ops
• Entornos totalmente uni
fi
cados y iguales
• Ahorro de costes signi
fi
cativo a medio y largo plazo para la empresa

6. NO ERESTAN ESPECIAL…
O mejor dicho… todo el mundo tiene problemas similares y todo está roto

7. LA MENTIRA DE LAS CONFERENCIAS
• Todo el mundo “miente”. Spotify, Google, Facebook,AWS,
videojuegos,
fi
ntech… todo es bastante drama no os lo creeríais…
• Casi nadie cuenta los fracasos, solo los éxitos!
• ¡Son aspiraciones y para coger ideas! ¡Si no tienes un equipo grande,
no podrás hacer lo mismo que las grandes! O almenos no todo el
lunes!

8. ¿QUEREMOS HACER DEVOPS?
• Todo el mundo quiere una “infra nueva automática con dashboards”
• Casi nadie quiere estar on-call, ni mantenerla, ni mirar el monitoring
• DevOps no es meter BASH enYAML dentro de HCL2, es una
fi
losofía
de trabajo para ir más rápido
• MANAGERS: Para tener equipo efectivo, hay que contratarlos (caros)
o formarlos. Nada va realmente 100% solo.

9. SUELE (O SOLÍA) EMPEZAR SIMPLE
• Stack clásico
• Monolito en PHP (o similar)
• MySQL (o otra RDBMS)
• Se pueden ganar Millones de €
• ¡Y no hay nada malo!

10. NOS EMPEZAMOS A GUSTAR
• Nginx / CDNs
• Servidores Cache
• BBDD NoSQL
• Búsquedas texto Lucene
• Sistemas de colas y streaming

11. Y CASI SIEMPRE…
• Sobre-Ingeniería
• Difícil de mantener y usar
• Complejidad accidental
• ¡Hacemos daño a la empresa!
• Podéis iros, pero la gente habla…

12. ¡ELIJE BIENTU STORAGE!

13. NOSQL
• Los NoSQL son MUCHO más complejos que los SQL tradicionales
• Empezad probando alguno de cache, y como mucho algún K/V
• Las BBDD documentales son muy difíciles de administrar y de optimizar
• Las BBDD de grafos están todavía muy muy verdes
• ¿Realmente las necesitáis?

14. CV DRIVEN DEVELOPMENT
• Parece que si no estás haciendo Go, NoSQL y K8s no eres nadie
• Llenar de keywords en el CV solo hace perder tiempo a todos
• DDD como paradigma, ok, pero igual no necesitáis CQRS con
proyecciones el primer día. Solo es gastar tiempo y dinero.
• VIVA EL BORING STACK

15. MICROSERVICIOS

16. MICROSERVICIOS - ¿SEGURO?
• Si tenéis dudas de si los necesitáis, la respuesta es no
• Nunca simpli
fi
can, al contrario, añaden muchísima complejidad (service
discovery, orchestration, tracing, latencias…)
• Se necesita mucho tooling (platform teams), mucho monitoring y
mucha madurez como equipo
• Si no tienen su propia BBDD, felicidades, tienes un monolito distribuido

17. MICROSERVICIOS - PROBLEMAS
• Un fallo en un microservicio te puede tirar todo el sistema
• El Uptime baja exponencialmente (0,99 ^3 -> 0,97)
• Timeouts y retries en cascada. Si es lectura ok, pero… ¿en escritura?
• Es muy complicado testear correctamente un sistema con muchos
servicios y todos sus edge cases.

18. A complex system that works is invariably
found to have evolved from a simple system
that worked. A complex system designed from
scratch never works and cannot be patched up
to make it work. You have to start over,
beginning with a working simple system
John Gall, systems theorist

19. CONTENEDORES / K8S
• Parece que han venido para quedarse… veremos cómo
• Un contenedor NO es una máquina virtual, de verdad.Y encima, lleva un SO
que ocupa bastante RAM / CPU
• K8s es MUY complejo, valorad si os merece la pena o podéis usar algo más
sencillo para empezar. O almenas solo partes fáciles de la app
• POLÉMICA: Creo que K8s o desaparece o estará tan abstraído que no lo
veremos, como lasVMs.Y no es lo mejor para todos los casos.

20. RE-ESCRITURAS DE 0
• En 20 años de profesión no he visto funcionar bien ninguna aún
• Siempre se acaba con 2 sistemas rotos y un montón de
interdependencias (y doble coste de infraestructura) durante años
• El equipo que no supo hacer un monolito LAMP adecentado no
sabrá hacer una arquitectura de sistemas distribuidos

21. LIVING ONTHE EDGE
• ¿Para qué? Pregunta honesta
• Cada upgrade tiene riesgo, las versiones x.0.0 duran horas, NO
actualices continuamente a la última version
• No es buena idea usar algo que necesitas tirar de sus ramas dev
• Ojo!Tampoco dejéis los sistemas muertos, pero usad versiones que
lleven meses estables!

22. NIH SYNDROME
• Los estándares de la industria SEGURO (casi) que sirven para ti
• No escribas tu propio framework ni implementes tu propio sistema
• La mejor línea de código es la no escrita. O la borrada!
• Código revisado por miles de personas, no sabes más que la
comunidad

23. EMPRESAS PEQUEÑAS
<10-15 departamento técnico

24. KISS /YAGNY
• Si no tienes >1 millón de requests al día, ni necesitas NoSQL ni tienes
ningún problema de escalabilidad. DEVERDAD.
• Cualquier sistema simple de colas te sirve, hasta usar una tabla!
• PostgreSQL / MySQL aguantan mucho, no necesitas Aurora, Redshift ni
nada similar hasta por ej 10Tb. Ni MongoDB, eso 99% seguro que no.
• No tengas más de 1-2 lenguajes en el backend

25. MICROSERVICIOS / K8S
• Probablemente no los necesites, o no más de 3-4 servicios
• Los microservicios son MUCHO más difíciles de orquestar, manejar y
mantener que un monolito. Intentad adecentar el legacy antes!
• Si no hay gente que sepa de contenedores, no os liéis y usadVMs
• Si no hay gente que sepa K8s, usad ECS o almenos un K8s managed

26. LOS COSTES
• MUCHO cuidado con el caramelo de los créditos del cloud
• Tener entornos idénticos vale dinero… igual no necesitas todo
• Cada pieza nueva vale dinero, sobretodo si es managed
• MANAGERS: ¿Os vale la pena que gente con poca experiencia pase
semanas peleándose? ¿No iría mejor un experto para acelerar?

27. EMPRESAS QUE CRECEN
>25 departamento técnico y budget

28. EQUIPOS DE PLATAFORMA / SRE
• Mucho cuidado con esto, suelen generar fricción
• Se requiere gente con mucha experiencia para estos equipos
• Hay que incluir a los equipos de producto desde el comienzo, o hacer
proyectos de implementación con equipos mixtos
• De
fi
nir MUY bien los boundaries, quién mantiene qué, etc… DIFUSO a veces
• Comité de sabios para decidir la arquitectura, solo SRE

29. MICROSERVICIOS / K8S / NOSQL
• Te pueden ayudar a acotar responsabilidad, ojo con las interfaces entre
servicios (equipos) cada uno con su roadmap
• Puedes tener múltiples lenguajes de backend y facilitar un poco la
escalabilidad de la plataforma
• Sigue siendo recomendable usar un K8s managed
• Ojo con los “technology gang-bang”, intentad uni
fi
car

30. LOS COSTES
• Ojo con los múltiples entornos, coste exponencial, invertid en infra-
as-code tanto como podáis (test environments on demand)
• Reservas, spot instances, auto escalado agresivo, …
• Apretad a vuestro account manager, van locos por retenerte
• IDEA: Bonus por ahorro de infra (muy fácil de pervertir)

31. MI NAVAJA SUIZA (I)
• Packer + Ansible para imágenes,Ansible paraVMs
• Terraform para infra-as-code (tanto como se pueda)
• Cada vez menos fan de Elastic, Datadog / NewRelic van muy bien
• Containers con moderación, K8s con equipos maduros, ECS (solo AWS)
• Todas las herramientas más usadas suelen funcionar bien

32. MI NAVAJA SUIZA (II)
• CI/CD cada vez menos Jenkins y Github / Gitlab / Bitbucket por igual
• Grafana + Prometheus (In
fl
uxDB parece quedarse atrás)
• PostgreSQL, Redis, Kafka, RabbitMQ, SQS
• PHP, Python, Java, Go (seguimos en el bar…)
• Insisto: MUCHO CUIDADO CON LOS NOSQL

33. OJO CON LAS MODAS

34. LEED BIEN LA DOCUMENTACIÓN

35. ESCOGED LA HERRAMIENTA ADECUADA

36. ¿PREGUNTAS?
• @ricardclau
• ricard.clau@gmail.com
• https://github.com/ricardclau
• hello@rigoralliance.com