Jekyll2020-05-06T03:25:11+02:00https://javier.dev/feed.xmlSite Reliability Engineer at Payvision. Views expressed on this blog are solely my own, not those of present or past employers.Javier Revillas2020-05-06T00:00:00+02:002020-05-06T00:00:00+02:00https://javier.dev/2020/05/06/boring-stack-y-eficacia-a-corto-plazo<p>La historia de mi equipo es muy reveladora. Empezamos como una prueba de concepto para modernizar parte del stack y mejorar la <a href="https://oreilly.com/library/view/accelerate/9781457191435/">deployment frequency</a> de algunos productos. De esto hace ya dos años, aunque el primero no fue nada fácil. <!--more--></p> <p>Payvision era una organización con diez años de <strong>.NET</strong>, <strong>SQL Server</strong> y <strong>Windows</strong> a sus espaldas; un stack bien sólido. La infraestructura —completamente on-premise— se administraba desde nuestra sede en Amsterdam. Nuestro margen de maniobra estaba muy limitado y las herramientas de las que disponíamos no resultaron efectivas fuera del mundo Microsoft.</p> <p>La estrategia no contemplaba adoptar <a href="/2020/04/27/kubernetes-a-punetazos/">Kubernetes a puñetazos</a>; sin embargo, estos fueron los cimientos de Atlas, la plataforma que operamos hoy en día. Virtualizamos sobre <strong>VMware</strong>, y <strong>Red Hat Enterprise Linux</strong> es el sistema operativo donde corren los contenedores que orquestamos a través de varios clusters de <strong>Kubernetes</strong>. Administramos nuestro propio registro de imágenes con <a href="https://goharbor.io"><strong>Harbor</strong></a> y mantenemos varios clusters de <strong>Elasticsearch</strong>. Los agentes de entrega continua y algún que otro producto de seguridad cuelgan también de nuestro backlog.</p> <p>Trabajar con un stack «manejable» es sin duda alguna la lección más valiosa que hemos aprendido. Nos movemos en un entorno donde la novedad golpea con una frecuencia casi diaria; sin embargo, nos gustaría ser <a href="https://en.wikipedia.org/wiki/Early_adopter">early adopters</a> de muchos proyectos que entran en la <a href="https://www.cncf.io">CNCF</a>. La experiencia nos obligó a concretar un <strong>budget de innovación</strong>.</p> <p>Para materializar este nuevo balance revisamos una cláusula de nuestro contrato: la que destina el 10 % de nuestro tiempo a formación. Tradicionalmente hemos podido dedicar este tiempo a jugar con nuevas tecnologías, preparar charlas o contribuir a proyectos open source. Nuestra propuesta para los <strong>viernes de proyectos</strong> se puede entender como una iteración sobre esta cláusula:</p> <ul> <li><strong>Todos los viernes.</strong> Se trata de un esfuerzo significativo para cualquier organización, ya que requiere casi un 20 % del tiempo del equipo.</li> <li><strong>Propuestas concretas.</strong> La motivación, los objetivos y el scope de cada proyecto quedan recogidos en un repositorio gestionado por el equipo. Los resultados y las conclusiones de cada proyecto también forman parte de este repositorio.</li> <li><strong>Aprobación del equipo.</strong> El visto bueno necesario para empezar a trabajar en un proyecto se otorga por unanimidad y ningún agente externo al equipo interviene en la toma de decisiones.</li> <li><strong>Solo para proyectos.</strong> Este plan se concibe con un enfoque pragmático y no contempla cursos de formación ni certificaciones.</li> <li><strong>Completamente opcional.</strong> Como estas condiciones no aparecen en nuestro contrato, cada miembro del equipo es libre de adherirse o no a ellas. No se trata de una imposición.</li> </ul> <p>Me atrevería a definir esta iniciativa como una <strong>solución de compromiso</strong>. De lunes a jueves se trabaja por y para el backlog: <a href="https://stevebate.silvrback.com/go-is-boring">boring stack</a> y eficacia a corto plazo. Los viernes, en cambio, quedan blindados para invertir en soluciones que nos permitan mejorar como equipo y ampliar horizontes.</p> <p>Dios me libre de recomendar abiertamente este modelo, ya que todavía no disponemos de métricas que respalden su eficacia. Hoy me limito a compartirlo con el mundo, libre de toda responsabilidad.</p>Javier Revillas

La historia de mi equipo es muy reveladora. Empezamos como una prueba de concepto para modernizar parte del stack y mejorar la deployment frequency de algunos productos. De esto hace ya dos años, aunque el primero no fue nada fácil.

2020-04-27T00:00:00+02:002020-04-27T00:00:00+02:00https://javier.dev/2020/04/27/kubernetes-a-punetazos<p>Organizaciones con objetivos diametralmente opuestos. De todos los tamaños, países y sectores. Todas adoptando Kubernetes. <!--more--> Existen motivos —fuera del ámbito exclusivamente técnico— que respaldan la brutal adopción de este popular orquestador. El objetivo de este post pasa por compartir algunos de los más significativos.</p> <p>Despliegues manuales. Desarrolladores accediendo a entornos productivos. Scripts que solo entiende aquel fulano que se fue de la empresa. Java. Una política de versionado pobre o inexistente. Aquella caja de Pandora disfrazada de parche de seguridad. Las <strong>historias de terror</strong> pre-Kubernetes existen y están ahí para movilizar a los managers.</p> <p>Por si fuera poco, las <strong>ofertas de empleo</strong> continúan degenerando y ahora parecen cartas a los Reyes Magos: AWS, Azure, OpenStack, Jenkins, Docker, Kubernetes, Elasticsearch, Perl, Python, Ruby, Bash, Ansible, Puppet, Terraform, Chef… El candidato idóneo está obligado a acumular experiencia sobre todas estas tecnologías.</p> <p>El mercado se ha vuelto loco y el miedo a quedarse fuera por no dar la talla es tan real como ridículo. Así pues, cada día más empresas se suman a esta agotadora tendencia por sufrir el stack más absurdo.</p> <p>No obstante, la rigidez en el stack es un lujo al alcance de muy pocas organizaciones. La ausencia de esta, en cambio, se suele disfrazar de “salario emocional”. Este problema —aunque organizacional— encaja a la perfección con una solución basada en contenedores.</p> <p>Las arquitecturas orientadas a <strong>microservicios</strong> suelen favorecen una eventual explosión del stack tecnológico. Cada pocos meses aparecerá la oportunidad de emprender nuevas aventuras con un framework o lenguaje distinto. La distancia aparente entre este nuevo juguete y el entorno de producción es un <code class="highlighter-rouge">Dockerfile</code>.</p> <p>Este esfuerzo por ampliar horizontes supone un <strong>coste operacional</strong> difícil de asumir. De ahí que Kubernetes también imponga sus propias normas con el objetivo de automatizar y simplificar las operaciones:</p> <ul> <li>Siempre son contenedores. Los artefactos, por lo tanto, siempre tienen la misma forma: imágenes de Docker.</li> <li>Los logs van a <code class="highlighter-rouge">stdout</code> y <code class="highlighter-rouge">stderr</code>. Un problema menos para la aplicación, ya vendrá alguien a recogerlos.</li> <li>Comprobar y exponer el estado de los procesos. ¿Está listo para atender peticiones? ¿Hace falta otra instancia del proceso? Responder a estas preguntas de manera programática permite a la plataforma tomar decisiones que hasta ahora eran manuales.</li> </ul> <p>El discurso de <strong>marketing</strong> de los cloud providers ha calado. Ya no importa si uno tiene la suerte de hacer negocio con un número modesto de peticiones y poco tráfico. Si la API no está preparada para recibir una bestialidad de consultas por segundo, parece que está mal diseñada. Para sorpresa de nadie, Kubernetes complace esta ambición de escalar sin coste aparente. Todos los días pueden ser como el Prime Day para Amazon, pero sin métricas.</p> <p>En definitiva, no acumular <strong>malas prácticas</strong> es imposible y las más difíciles de identificar están enquistadas en todo el sector. La falta de experiencia acumulada hace que el factor humano sea problema y solución al mismo tiempo, no existen respuestas absolutas. Amazon, Google y Microsoft marcan el ritmo, pero resulta casi imposible diferenciar entre señal y ruido cuando todo es nuevo.</p> <p>Es difícil de percibir en un primer vistazo, pero tanto Kubernetes como otras tecnologías complementarias se han diseñado con estas miserias en mente. No están limitadas a un contexto estrictamente técnico, sino que acaban forzando un modelo alternativo que obliga a rediseñar y transformar toda clase de procesos. Ya sea a puñetazos o no, vale la pena estudiar el impacto de un producto así en el entorno profesional.</p>Javier Revillas

Organizaciones con objetivos diametralmente opuestos. De todos los tamaños, países y sectores. Todas adoptando Kubernetes.