A Story for Builders
Some Case Studies
Rational? Arguments
Emotional? Arguments
A Third Way
Conclusions
Run a detailed Total Cost of Ownership (TCO) study
...
And then promptly throw it away
You may be missing
crucial factors!
Probably the most important practice in DevOps
Continuous Integration: tested on integration env
Continuous Delivery: tested on several envs
Continuous Deployment: go all the way and deploy!
A simple bash script to start
Built for (and with) Node.js packages
Held together with some custom Node.js scripts
Recently migrated to StriderCD
Now with a Graphical Interface!
Previously using Amazon's Elastic Load Balancer
Eating up to 20% of our monthly bill
Replaced by an Nginx balancer
DNS balancer in Node.js
Custom Lua logging
Peaks of 325 krps
Average of 200 krps
16 billion requests per day
30 million daily impressions
Amazon CloudWatch: CPU usage
Custom systems monitoring:
memory, disk usage, database
Custom online monitoring:
servers up, site up
Custom business alerts:
ad exchanges, CTR, revenue
Not always appreciate our custom infrastructure
Would rather prefer standard packages
Household brands:
Jenkins, Icinga, Puppet, Chef
(We have evaluated those, didn't like)
Rational thought is not "natural":
It needs to be learned and cultivated
"Rational" arguments are often emotional in disguise
Humans tend to act and then rationalize
Some deconstruction may be required
Commercial solutions are robust
Managers will probably nod wisely
Software developers will look at this with suspicion
Most commercial software is held together
with bailing wire and duct tape
Maintaining a bunch of custom code
hacked together by your predecessor is hard
Ugly code is everywhere
Companies go out of business all the time
Products are orphaned every day
Once you start a software project,
you start accruing technical debt
Good teams have less technical debt
Do you have a good team?
Better than your vendor?
Otherwise, go out and get a good team!
Even more contentious than those before
Do not expect answers! Not from me
At most, some uncomfortable questions
People build things because they love to
Starting a green field project can be exhilarating
Helps attract and keep elusive talent
Someone had to build first!
Why let them have all the fun?
"Not Invented Here":
Distrust products offered by third parties
If it is a core business function
do it yourself, no matter what.
As easy as identifying core business functions
Right?
Banks: outsourcing IT
Google: self-driving cars
Facebook: providing Internet access
Apple: music distribution, watches
Does the world really need a new testing library?
I don't know or care
If I need it, I will surely build it
The best way to learn is by building
DevOps is not just installing a package
Make infrastructure a first-class citizen
Installing a package can be simple if you know how
The best way to learn infrastructure is by building it
Software devs are artisans practicing their craft
Artisans may get carried away
and build too much
Use modules as standard parts
Maintaining software can be hard
and expensive
Middle ground between building and installing
Install product, then customize
Plugins, extensions, APIs, hooks
SAP, Siebel, Fidelity Profile
The logical continuation
Software as a community
Build custom extensions
and share them!
E.g.: send diffs by email
using StriderCD
Combine several packages into a larger entity
Continuous deployment requires:
May require glue code
There is not a universal path for all destinations
Consider:
The answer to every interesting yes/no question is: "it depends".
Must have fun
Must have profits
Try to have both!
Companion: https://alexfernandez.github.io/2016/build-or-not.html