Your DevOps agility starts with your dev environment

IT projects is what I do for living and I’ve to admit that I’ve done quite a few. What is more, I’m proud to...

5 years ago

Latest Post Mixing warsaw.ex by Sebastian Gebski

IT projects is what I do for living and I’ve to admit that I’ve done quite a few. What is more, I’m proud to tell that whenever I was somehow involved in technical architecture, there was some kind of automated build & deployment set up: I may be a bit dogmatic here, but for me a project with fully manual build & deployment is more a student lab project than a professional work. Anyway, even if we decided to spend a more serious effort on that, we’ve never got really close to something called "Infrastructure-as-a-Code" (http://www.somic.org/2012/09/28/concise-introduction-to-infrastructure-as-code/).

Why … What part did we miss?

Most likely - the hardest one :) Everything that was below the level of application itself and its custom configuration. To be precise: OS installation and configuration, non-artifact setup (for instance: web server, RDBMS, network), etc. There were quite a few reasons:

  1. We had a strong resistance against virtualization (which is a key factor in keeping all levels of environments 100% corresponding) - mainly because of  three reasons: performance “tax”, license costs and full regression test necessity while moving from physical to logical machine.
  2. We usually were lacking deep DevOps skills in terms of OS configuration automating - as deployment automation was usually done by hardcore Devs only. Market lacks experienced DevOps (at least in Poland) so these roles are usually filled as most junior people (and treated as boring and pain in the … neck).
  3. We didn’t really ever had developers commitment - they were as accustomed to their traditional way of work, that they were very reluctant to changes. And sometimes we sticked ourselves to our “Ivory Tower” and we didn’t see some tiny details that were a key game-changers / showstoppers for them.

But … is that really a problem? What’s the benefit of doing IaaC?

Based on my experience it’s the only way to achieve the following benefits:

And the gain multiplies with increasing complexity (homogenous OSes and platforms) of your environments.

What is the key to do real IaaC then?

  1. Reasonable virtualization - I’m giving a go to Vagrant (http://www.vagrantup.com/ - virtualization abstraction layer that works great with provisioning software) and so far I’m very happy with the outcome.
  2. Proper dependency mgmt - not only in runtime, but also in the build time, so Continuous Integration runs efficiently and build cycle is as concise as possible.
  3. Abstracted configuration - you need to strictly separate the variables from non-variable part of configuration. Non-variable part is the one that doesn’t really change between the environments (so is a code artifact, not a true configuration artifact).
  4. Environment automated provisioning - using tools like Chef (http://www.opscode.com/chef/) or Puppet (http://puppetlabs.com/puppet/what-is-puppet) - they are absolutely critical to provide 100% compatibility between environment setup and eliminate space for human errors.

Point #1 and #4 are by far the hardest for us to achieve at the moment. Keep the fingers crossed, we’re quite likely to give it another go in the nearest future.

Sebastian Gebski

Published 5 years ago

Comments?

Leave us your opinion.

Subscribe our newsletter

Recieve news directly to your email.

No Kill Switch © 2018.