Infrastructure as a Code is still not popular as it should be.

In 2010, when I have joined the London 2012 Olympic IT core team, I have started dealing with a new way of managing, building, deploying and supporting environments, I am not sure if the definition of Infrastructure as a code was already there at that time, but now, seven years later, all looks more clear to me, at the Olympic Games, the only way to build a huge integrated infrastructure, in a very short timescale was to consider all our assets the same as code elements, with a large media library, a cmdb, a naming convention, and a full end to end validation & release process to allow an organised and scalable pipeline that minimises errors and provides great scalability. It was a great project to be part of, and surely a milestone of my career, and mostly it was a great way to give some contribution to the birth and the end of life of a huge integrated infrastructure and all its services.

After the games I have been working in other two companies, and every single time I haven't seen such cleaver approach implemented, despite that in other companies, mainly startups, Infrastructure as a Code has been introduced since day 1, for a company that is already developed as business is always more challenging to embrace such approach, but in 2017 we have a set of new tools and management frameworks that can help a lot to jump into one of the last seats of the train that goes in that direction.

I start a new role from tomorrow, and this is one of my main personal targets for the next 12 months: to allow the senior management to truly understand the business benefits of having the infrastructure pipeline managed as a Code.