Roland -- Great spiel -- esp. on how other approaches on how other
approaches come up short. Thx, --Peter
On Sat, Jun 6, 2015 at 6:02 AM, Roland Moriz rmoriz@gmail.com wrote:
Am 06.06.2015 um 01:14 schrieb Torben Knerr mail@tknerr.de:
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
MonolithFirst and
MicroservicePremium).
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:
There are unknown unknowns - Wikipedia), I’m usually walking
away to prevent further waste of time.
best regards
Roland
--
Peter Burkholder — Customer Success Engineer
Unavailability: May 19, Training. June 11-12, DevOpsDays DC
301-204-5767 – pburkholder@chef.io – *my: *Linkedin
http://www.linkedin.com/in/pburkholder Twitter
http://www.twitter.com/pburkholder Cal
https://www.google.com/calendar/embed?src=pburkholder%40chef.io&mode=WEEK
endar
CHEF
CHEF.IO http://www.chef.io/
TM
chef.io http://www.chef.io/ Blog http://www.chef.io/blog/ Facebook
https://www.facebook.com/getchefdotcom Twitter
https://twitter.com/chef Youtube https://www.youtube.com/getchef
