[chef] Re: Why InfrastructureAsCode and DevOps?


Chronological Thread 
  • From: Roland Moriz < >
  • To:
  • Subject: [chef] Re: Why InfrastructureAsCode and DevOps?
  • Date: Sat, 6 Jun 2015 12:02:35 +0200


Am 06.06.2015 um 01:14 schrieb Torben Knerr < " class=""> >:

Ohai everybody,

might be a bit off-topic / not chef specific, but for sure the people around here might be among the best ones to ask :-)

I'm looking for some high-level slides / blog posts / etc material to educate business about the value of infrastructure-as-code and devops practices and why it's vital to almost every project.

Pretty sure I could come up with some good technical arguments, but I'm lacking the economical facts & numbers.

There are probably thousands of articles about it. However, if you know some especially convincing or good ones, I'd be highly interested in it.


I like your question. This IMHO shows, that Chef might consider adding a partner program that is open to small business/indie consultants and not only enterprise customers. ;-) #hint #hint 

I’ll add my 2 opinionated, moody cents:

- It saves a lot of money. With DevOps in place you can usually reduce your Infra and HR costs related to ops. This doesn't imply layoffs but the ability to let people work on things that improve the product/the efficiency of the company more efficiently. From my limited experience 1/3-1/2 of the „snowflake-admins“ won’t have a future inside a company that adopts full infra automation. I regularly see senior admins with 10y+ experience that have trouble to use an editor of their choice (usually nano…) and they will probably quit. Also hiring good people is hard, especially because companies in Germany pay crap: In the USA you find a lot of chef-related devops jobs paying above 120k$/year while I know many DevOps and even developers in Germany who earn less than 50k€ a year. Not to speak about taxes. So either the companies will invest a lot of money in higher salaries or they will have to deal with the shortage of skilled developers, invest a lot in trainings, freelancers. That’s why keeping the headcount low (using Chef for example) is a compelling argument. Save one position, save 50k€ + 20-30% employer’s contribution. Save HR costs, save training costs. Reduce risk factors.

- It scales. While scaling is not the primary issue for most „regional“ companies that are providing specialized services and/or are only active in our country (Germany), it also reduces the lock-in to physical Infra-providers. DevOps allows you to insource everything related of provisioning nodes with very little work. Many German ISPs are ripping off their customers by selling „enterprise virtual machines“ that are crippled, don’t allow to be re-created programmatically by the customer („write a ticket so we can reset the VMware VM for the amount of xxx € in a couple of days“, „sorry we missed your ssh keys"). Even when the company is doing the hosting Infra inhouse, DevOps can help you to leverage/migrate to other solutions which may be cheaper or better in the future.

- It’s faster. "Time to market". Faster delivery of products/services, faster adaption to market changes. This is crucial in high pace environments. Usually Google and Amazon are the poster children of making German CEOs sweat, because they deliver and scale products so fast. As someone else already posted: Just show the management how fast you can create an ec2 or digital ocean instance and deploy your app. If that isn’t convincing enough, walk away. The management will kill the company anyways.

- Especially with chef you can do nearly "everything". You’re not limited to specific providers, hardware, Dockerfile, a specific operating system, a specific kernel version, a specific deployment approach, a big YAML file or some hyped language that Google pushes into the market (Golang).

I’ve seen companies walking away from Chef or not using it because they thought DevOps can be simpler. This is true for very small setups or when you only see a chef-server setup as a minimum viable solution but IMHO that lacks foresight. Changes will come. To minimize risks a company needs to be able to deal with changes quickly or someone else will take the customers away, if your current setup fits in a couple of Dockerfiles, this doesn’t have to be true in the future. Usually people and management needs to feel the pain first, then it happens in some hasty way without defining the requirements a solution needs. Docker is an awesome example: Many people don’t care about an init process inside the container, don’t do log aggregation, don’t do monitoring („docker restarts crashed containers, thats enough“), fail at virtual networking and even iptables usage with docker. I’ve seen this anti-pattern many times before in the „developer“ world, currently the „microservices“-hype is the next big thing to burn in flames (see Martin Fowler’s excellent blog posts http://martinfowler.com/bliki/MonolithFirst.html and http://martinfowler.com/bliki/MicroservicePremium.html). 

Until people understand the problem/feel the pain, they won’t be able to make the right choices and they won’t adopt tools like chef. Maybe they really don’t need it. Maybe they will downcycle their business to one virtual machine…or will get wiped out by, e.g. Amazon or Google — I don’t know. But I played chess for a couple of years so I try to imagine the future opportunities/risks. If the mindset of a client is just denial and lack of risk assessment  (see also: http://en.wikipedia.org/wiki/There_are_known_knowns), I’m usually walking away to prevent further waste of time.


best regards
Roland




Archive powered by MHonArc 2.6.16.

§