Pamplona Software Crafters 2018

This post is in Spanish because this conference and all the content was in Spanish.

Otro año más (y van tres), he tenido la gran suerte de poder asistir a la conferencia Pamplona Crafters. Esta conferencia mezcla charlas preestablecidas con open space y este año, muy acertadamente, también han incluido una serie de talleres.

Aunque en todas las conferencias a las que voy, aprendo y disfruto mucho, tengo que confesar, que en estos últimos dos años, la Pamplona Software Crafters es la que más me gusta. Supongo que es la combinación de la gente que vamos, las charlas y la tematica, con que me gusta Pamplona y por supuesto la impecable organización de los amigos de 540.

En cuanto a la conferencia en si, he asistido a las siguientes charlas/talleres:

• Modelos mentales, complejidad y software (Arturo Herrero) (Video) Esta es una de las charlas que más me gustaron de toda la conferencia. Es un tema que me interesa, puesto que al igual que a Arturo he descubierto que el tema de interesarme por la complejidad y los modelos mentales me permite entender y relacionarme mucho mejor. Arturo ha escrito un muy interesante blogpost al respecto, incluyendo las slides que utilizo: https://arturoherrero.com/mental-models-complexity-and-software/ 
• One Page Product Design (Jorge Barroso flipper83) Interesante charla sobre las ventajas de compactar, visualizar, gran cantidad de información mediante diagramas, screenshots, diseños en una única página/diagrama de forma que la podamos pegar por las paredaes, poner en alguna zona de paso, y la riqueza de conversaciones e impacto que esto genera… Una imagen vale más que mil palabras, y esa imagen pegada al lado de la máquina de café 
• Sobreviviendo en producción. Construyendo una cultura de aprendizaje. (eferro) A petición de Modesto San Juan, propuse esta sesión para el Open Space. En ella, hable de como generar una cultura de aprendizaje comenzando a partir de la gestión de las inicidencias y usando como el Blameless Incident Report como medio. Esta aproximación la he usado en TheMotion y ahora en Nextail y la verdad es que ha funcionado muy bien. Tengo pendiente un blog post al respecto.
• Taller Refactoring, aprendizaje y economía (Luis Artola, Guillermo Galmazor). Disfrute mucho en este taller, puesto que por necesidad temporal no le estoy pudiendo dedicar mucho tiempo al desarrollo, asi que cualquier oportunidad de hacer algo técnico lo disfruto muchisimo. El taller en si pretendia resolver la kata trivia de Jbrains (https://github.com/jbrains/trivia) aplicando Golden Master o Subclasses.  Como siempre con Luis y Guille, el disfrute viene de lo didacticos que son. Me gusto mucho y me quede con varias notas sobre la estrategia Golden Master para cuando tienes código legado cuyo compartamiento sólo puedes observar viendo su salida por consola.
• El código como una forma de expresión (patxangas) Divertidisima e interesante charla sobre el uso creativo del código como medio de expresión. Muy impactante. Me trajo muchos recuerdos e ideas a la cabeza (Demoscene, videoarte, música experimental, etc). Además del contenido, siempre me encanta como se expresa y trasmite @patxangas sobre los temas más variopintos. Slides: https://slides.com/interzonas/el-cdigo-como-una-forma-de-expresin#/
• Mide más y sufre menos (Modesto San Juan) Charla introductoria sobre la necesidad de instrumentar nuestro software de forma que dispongamos de información real para tomar decisiones. Quizás se me quedo algo corta, pero por lo que comente con Modesto, yo no era el público objetivo puesto que ya estoy convencido. En cualquier caso es importante que se mande de forma continua este mensaje ya que muchos de los desarrolladores se centran sólo en la parte funcional sin tener en cuenta que eso es sólo una parte de su trabajo.
• Evolutionary Architecture (María Gómez) Esta charla me gusto mucho en contenido. Complementa desde un punto de vista algo más práctico a las charlas relacionadas de algunos de sus compañeros de ThoughtWorks. La charla se basa en lo descrito en el libro Building Evolutionary Architectures  (http://evolutionaryarchitecture.com/).
• Cómo no ser un tech lead (Gamarra). Esta sesión de open space se organizó como una charla abierta en la que se comentó algunas ideas sobre cómo incentivar una a tus compañeros a formarse, crecer, etc. Cogi algunas ideas interesantes de lo que estaban haciendo en Tuenti y en Liferay, que espero poder poner en práctica.
• ¿Arquitectura sin arquitectos? (German Del Zotto) Esta sesión planteo varias decisiones y balances que se tienen que tomar cuando estamos deciendo temas de artquitectura. German los describio como desciones a tomar, no por un arquitecto, sino como un habilidad que deberian poseer cualquier desarrollador. Me quede con ganas de más, pero seguro que puede quedar con German y profundizar en el tema. :)

Como siempre lo que más me ha gustado y lo que más me ha enriquecido han sido las grandes converaciones. Me vienen a la cabeza unas cuantas:

• Con cataflu durante uno de los desayunos (además es una gran desvirtualizacion). 
• Con nabaroa durante las cervezas del jueves (otra genial desvirtualización). Además hizó una impresionante lightning talk  acerca de las subidas y bajadas que experimentamos durante nuestra carrera y de cómo las ha gestionado ella.
• Con Arturo Herrero sobre el mercado para desarrolladores de software en UK y sobre el value investing.
• Con Helder y Marco Alacot sobre aprender/enseñar a programar, agilidad, y otras hierbas.
• Con bberrycarmen  después de la sesión de Arturo sobre modelos  mentales. Con luisrovirosa sobre la charla que dio Martin Fowler en Madrid la semana anterior y de cómo “hemos sido engañados” con el tema de la agilidad, puesto que podemos resumirla en XP+DevOps.

Me resulto gracioso que rafaoe y algún que otro “milenial” tuviese curiosidad de cómo desarrollabamos en los 90s. :)
También disfrute de largas e interesantisimas conversaciones con jacegu,  zigiella, y mucha más gente…

Por supuesto disfrute como un enano con tejones como Saski, Fran Ortiz, amigotes de Alea como Apa, Ruben y Nestor y con muchisima gente más (sharpbites, alfredodev, Toño, jorgeuriarte, alfredocasado, ...)
Me quedé con pena por no haber podido hablar y disfrutar con todos, pero llega un punto en el que es prácticamente imposible.

He estado repasando la lista de asistentes (https://twitter.com/pamplonaswcraft/lists/asistentes-2018) y he estado tentado de pegarla por aquí, puesto que compartir tiempo con todos ellos ha sido un autentico placer...


Bola extra:
Este año no he podido ir con familia, lo que por un lado me da algo de pena, pero que por otro lado me ha permitido aprovechar el viaje de otra forma. Me he organizado para poder ir con Alberto Paz, Modesto San Juan y Jerolba. La verdad que ha sido como tener dos dias más de confencia…  Grandes conversaciones y mucho aprendizaje.

Foto de @benjymontoya (usada con autorización)

Muchas gracias a los organizadores (@wricka69, @pabloalbizu, @gorkma, Mikel Ros) … Sois muy Top!!!

PD: Iré actualizando el post según vaya recopilando recursos.

Immutable infrastructure (tech pill)

Immutable infrastructure is a pattern to change/evolve processes without modifying the running code, actual configuration, and the base components (library, auxiliary processes, SO configuration, SO packages, etc).  In summary, avoid any manual or automatic configuration change to the running systems.
But if we don't allow changes, how can we evolve our application and service?  Easy, change the whole piece (function, container, machine) in one shot...

So to make any kind of change (code, configuration, SO) we don't connect to the target box to execute commands, we "cook" a new artifact (container image or machine image) and use it to create a new instance (container or machine) with the changes. In the past, the cost/time to create a new instance was huge, so in order to optimize the process, we tend to execute the minimal change needed to run the new version. I mean, use a manual or automatic process to ssh to the box, install the needed packages, change the configuration, update the code, etc.

But...
¿What happens when the ssh dies in the middle of an update?
¿And if we have a problem installing a package?
¿How can we be sure about the actual state of a machine?
¿How can we calculate the changes to execute if we are not sure about the actual state of a machine?

Making changes in a machine using ssh, is not a transactional operation so we can have a failure in the middle of the process.

The solution, Immutable Infrastructure...
Create a new artifact and run it. Without intermediate states. Only "Not Ready" or "Ready". Simple.  And if something is wrong, destroy the artifact and try again.

This pattern is at the core of the principals container-orchestration systems and PaaS (kubernetes, swarm, mesos, heroku, open shift, Deis, etc).

Why is a good idea

• Simplicity. Is an order of magnitude easier to destroy a resource and create a new one from scratch than to calculate the deltas to apply and execute them. 
• If we need scalability we need to support this patter anyway.
• Right now is easy to implement with the help of the different clouds and PaaS providers.
• Very easy to return to the previous version.
• Very easy to troubleshoot a problem, because there are no intermediate states. You can know the exact content of a running version (the SO state, the concrete conf, the concrete code, etc).
• With this approach, there is no difference between languages and running environment (python, jruby, java, all the same...).  Is a general solution for all the technology your systems requires.

What are the downsides

• In some cases, the bootstrapping/setup time to use a new machine is larger than modifying an existing one. But the time is improving continuously and if we have a scalable architecture we already are dealing with it. Another solution is to use the patter at a different level, for example, functions or containers instead of at the machine level.
• This pattern requires more and longer steps that the classic approach so it is not practical to do it without automation. But not automatize this kind of task is shooting in your foot anyway.

Implementation Samples

As a general implementation strategy we need to be capable to make the following steps:

1. Start a new running process (without processing workload).
2. Detect when this running process is ready to accept real workload.
3. Connect the running process to start processing workload.
4. Disconnect the old running process to stop receiving new workload.
5. The old running process completes the workload that already has.
6. Detect that all the pending workload of the old process is completed.
7. Destroy the old process.

If we talk about web servers the steps can be:

1. Start a new machine/container running the web server in an internal endpoint.
2. Detect when the web server is ready using the health check endpoint.
3. Connect the new web server internal endpoint to the load balancer with the external endpoint.
4. Inform the old web server to stop processing new traffic and disconnect from the load balancer.
5. Detect when the old web server finished.
6. Destroy the old web server.

If we talk about a background queue job processor the workflow can be:

1. Start a new machine/container running the background queue job processor.
2. Detect that the new machine is processing jobs from the queue.
3. Inform the old background queue job processor to not get new jobs.
4. Detect when the old background queue job processor has completed its pending work.
5. Destroy the old background queue job processor.

We can think similar steps for other kinds of processes.

Design Notes

As we can see, this pattern requires collaboration from our code and support from the platform, but I assume that this is part of designing scalable systems that make great use of the capabilities of the cloud. For a good reference about designing applications for the cloud, please read The 12 Factor Apps

We can apply the same pattern at different levels. Virtual machines, Containers, Functions... The ideas are the same but the granularity is different.

Using Infrastructure as Code is recommended prerequisite to implement this pattern.

Conclusions

• The platforms are going in this direction so they have a lot of help to implement it.
• This is the fundamental pattern for:
• Scale up and down in the cloud.
• Advance patterns for deploy with zero downtime (blue-green deploy, rolling deploy, canary releasing, etc).

Other tech pills:

• Infrastructure as code IaC
• Pub-Sub the swiss army knife
• Scalable design pattern sample
• Queues vs Distributed logs

References:

• Trash Your Servers and Burn Your Code: Immutable Infrastructure and Disposable Components Chad Fowler.

Notes:

Thanks to @Fortiz2305 and @cesarob for the feedback.

Infrastructure as code IaC (tech pill)

Infrastructure as code (IaC) is the practice of defining/declaring the infrastructure we need for a system using some kind of machine-readable source files. These source files are used by a tool to provision, create or maintain in a defined state our infrastructure.

These definitions help to provision/create a different kind of resources, compute, storage, communication services, network

For cloud-based infrastructures, we can use these definitions to create "virtual resources" and to configure them to be in a certain state. For example, we can create a virtual machine with an initial  OS image and later install some software and configure it.

In a bare-metal environment, we can use the definition to configure a fixed number of machines and devices already defined in an inventory.

The goals of this practice are:

• Avoid server configuration drifting
• Avoid proliferation of Snow flake Servers.
• Reduce drastically the maintenance cost and the total cost of ownership.
• Allow easy and infrastructure evolution.

As a collateral effect, this practice also allows:

• Use development practices for the infrastructure (version control, testing, audit, collaboration, live documentation...).
• Create on-demand systems for development, QA, testing, and experimentation.
• Developers collaboration.

Cons:  really, it's 2018... no, seriously I don't find a good reason to not to create infrastructure as code. And when the problem is that these resources are difficult or impossible to define using code or some kind of definition, we should avoid them as much as possible.

General Approaches and styles

• Push. We execute a tool that parses the definitions, calculate the changes to do and execute them.
• Pull. Each node/device have its definition and execute all the time in a loop executing the needed changes.
• Push + Pull. A combination of the previous ones, so we can push a change (when we need to be sure or force some changes) or wait until each node/device update its configuration 

Sometimes we can restrict the IaC to provision the low-level infrastructure. For example, we can use this practice to create a PaaS (using Kubernetes, or similar), so the rest of elements are dynamically provision inside the PaaS we have created.

Related Tools:

• Terraform
• Puppet
• Chef
• Ansible
• SaltStack
• Cloudformation
• https://cloud.google.com/deployment-manager/

In summary, IaC is a core DevOps practice and is the base for a lot of the innovations and evolution that the cloud brings us. It is a must for modern development in the cloud and also very recommendable for on-premise deployments.

Other tech pills:

• http://www.eferro.net/2017/08/scalable-design-pattern-sample-tech-pill.html
• http://www.eferro.net/2017/09/pub-sub-swiss-army-knife-tech-pill.html
• http://www.eferro.net/2017/07/queues-vs-distributed-logs-tech-pill.html

Good talks/podcasts (May 2018 I)

These are some interesting talks/podcast that I've seen/heard during the past month:

• Cloud Native related:
• Anatomy of a Production Kubernetes Outage Oliver Beattie A great example of a complex outage and the learning derived from it.
• Altitude NYC 2018: Observability workshop Peter Bourgon Good workshop to understand how to instrument our applications for good telemetry, logging, and tracing.
• Kubernetes: Finally...A True Cloud Platform Sam Ghods A good description of kubernetes as a base abstraction for the cloud platforms.
• CraftConf 2018. Always a great content at this conference.
• Test-Driven: The Four-Step Dance Tim Ottinger Very interesting detail for improving our TDD practice.
• What is this cloud native thing anyway? Sam Newman A good summary of the topic.
• Five key challenges for software quality tomorrow Gojko Adzic This talk help us to understand the new challenges to test our systems in this new and changing world (ML, AI, cloud services, etc).
• Scaling Your Architecture with Events and Services  Randy Shoup New version of a classic talk from Randy. You can use as a map for dealing with data in microservices and to design using events.
• Simplify the stack  Matt Aimonetti Good talk about simplicity and how you can use "Requests For Comments" to discuss design ideas.
• Other
• The death of Agile Allen Holub (Related with the interesting blog post "Developers Should Abandon Agile") Thanks Fran Reyes for the reference.
• Computers for Cynics [full version] Ted Nelson. General historic information and deep ideas about technology.
• The Formula for Happiness from Solve for Happy An interesting interview with Mo Gawdat.
• The Next Generation of Data Products Hilary Mason. A good introductory talk for newbies like me.
• Old Is the New New Kevlin Henney Very interesting remainder about the bases and about how to identify these core ideas and the new improvements based on them. Understanding this process can help us to improve even faster if we learn and go deep in the bases.

DevOps talks

As a complement of the previous post DevOps concepts and learning path and in case that you prefer watching talks, these are some great talks about DevOps:

Bases for DevOps (Lean / Flow):

• The Efficiency Paradox Niklas Modig. Only 18m to understand the efficiency of flow vs efficiency of resources.
• Competing On The Basis Of Speed Mary Poppendieck
• The Value of Flow 14 09 17 Dan North 27m Great explanation for flow efficiency for soft delivery

DevOps:

• Devops and Dr Deming’s 14 Points John Willis' Ignite talk (Velocity NY 2014) 5mins to understand the relations between DevOps and the ideas of Dr. Deming.
• The (Short) History of DevOps Damon Edwards. 12m
• DOES17 London - The Key to High Performance What the Data Says

Related:

• Continuous Delivery Sounds Great But It Won’t Work Here Jez Humble. A new version of a classic one. A great talk.
• How Netflix Thinks of DevOps
• Fail Better: Radical Ideas from the Practice of Cloud Computing Tom Limoncelli
• Evolutionary Architecture and Fitness Functions
• The Virtuous Cycle of Velocity: What I Learned About Going Fast at eBay and Google Randy Shoup

Related posts:

• DevOps concepts and learning path

DevOps concepts and learning path

As Jez Humble said at leading a devops transformation DevOps is:

A cross-functional community of practice dedicated to the study of buildings, evolving and operating rapidly changing, secure, resilient system at scale. 

DevOps involves and enhance the ideas of the Agile Software Development giving a more end to end vision of the value stream for a technology-based company. And, you know, Every Company Is A Tech Company.

In summary, I think that DevOps should be the core of any technology-based company and the only option to reach/pursue the necessary business agility.

Main characteristics of DevOps culture:

• Collaboration between development and operations (avoiding SILOs and conflicting goals).
• Organize around the value stream optimizing for the flow efficiency (not resource efficiency). Learning to work in small batches.
• Remove waste (Non-Value Adding Activities).  Of course, we talk about value from the customer point of view.
• Build quality in.
• Create fast feedback loops.
• Maximize organizational learning (making safe to fail and learn).

Common practices:

• Infrastructure as code.
• Developers are involved in operations of the system (you build it, you run it).
• Operations involved in the development from the beginning (introducing/facilitating specific, nonfunctional requirements to create a system easy to operate and monitor).
• Automation (to avoid errors and to facilitate short iterations).
• Continuous Delivery.

Books / Learning path:

If you are interested in learning about this culture and you like reading books, this is the learning path I recommend:

The Phoenix project: As a great and easy to read an introduction to Lean in an IT environment. (My review)

The DevOps handbook: The complement for The Phonix Project that explains step by step the typical practices and the strategy to introduce DevOps.  A short of practitioner’s guide.

Continuous Delivery: To learn the principles and technical practices that enable rapid and incremental delivery of high-quality, valuable software to our customers.

Accelerate: To understand how to build and scale high performing technology organizations creating this DevOps culture.  This book is also an analysis of the data from the State of DevOps reports that give an idea about the importance of these practices.









If you are involved in any technology company, do you a favor and learn about DevOps... As the State of DevOps report indicates is the key to be a high-performance organization.

Related posts:

• https://www.eferro.net/2018/05/devops-talks.html