Saturday, May 26, 2018

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:

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:

Sunday, May 20, 2018

Good talks/podcasts (May 2018 I)

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

Wednesday, May 09, 2018

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):

Related posts:

Monday, May 07, 2018

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 includes 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.




Team Topologies: To have a common vocabulary and organize the different types of teams that suit the business needs. The recommended team organizations try to optimize for end to end flow.

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:

Saturday, May 05, 2018

Good talks/podcasts (April 2018)

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