This document discusses the need for simplicity over ease in systems and tools. It advocates for taking a holistic view of systems rather than focusing on individual components in silos. Tools should be flexible and enable robustness through the ability to quickly adapt without anticipating all scenarios in advance. Data and measurement are important for facilitating collaboration between development, operations, and business.

1. Elad Rosenheim
SAP IT
January ‘13

2.  On our chosen path
 So, why are we really here?
 Along came Biz?
 Kamikaze
 Our shiny new tools are broken too
 Just two Shekels

3. The wise Jewish elders once said,
around 1.5k years ago:
“There’s a short road that is long,
and a long road that is short”
We’re through with the “short roads”,
which are really long & tedious.
These are only fitting for old-school job security.

4. There is easy, and then there is simple.
Trying to always choose the obvious easy means: hard to
evolve, hard to maintain.
However, a simple state is hard to achieve,
much harder to achieve than a complex one.
For me, simple might be: generating a whole new
running environment based on its JSON description,
and having a clearly-defined set of components and APIs
to get you there.
The desired state is then clearly evident –
no matter how hard it is to get there.

5. Don’t take it from me,
There’s this guy behind the Clojure language:
http://www.infoq.com/presentations/Simple-Made-Easy
What’s your Simple vs. Easy?

6. Sure - automation is cool,
but it’s also about knowing your system.
Like, really knowing it.
(ever debugged your own code and was really surprised by what’s really going on,
or how many times a poor function was called?)
That’s why we also talk about:
 Looking at the black hole which is your logs
 Measuring everything

7. Shock & awe: they are not that dumb!
They have a lot of user-facing experience –
which you probably DON’T have.
But there’s so much they don’t know…
They have this intricate system of hunches and gut feelings.
So give them some real KPIs.
It might be worth it, as they have them budgets in their
tricksy, tricksy pocketses ;-)

8. Ben Kepes has already said it:
It’s not just Dev & Ops in their silos. It’s also biz.
We have a new opportunity to collaborate,
with some frigging data this time around.

9. The new approach compels us to be more flexible.
We can quickly create new servers, even whole new
landscapes. We know more about what’s going on.
We should use it to make our system increasingly more
robust, without thinking of everything in advance.
True-life story coming up…

10. In the year 1274 and again in 1281,
A seemingly unstoppable huge Mongol armada tried to
invade Japan.
None could beat the Mongols at the time.
But, twice their fleet was shattered by a typhoon storm, just
along the coast of Japan. The Japanese named this a “wind of
the gods” (kamikaze).
The big-design, huge config has failed.
It could not face this single uncontrollable event.
It had no fallback… and it was all in one zone.

11. Believe me: don’t believe the hype…
After ~2 years of heavy Chef work, I think it’s awesome
and seriously f**ked up.
One case in point:
Node attributes in Chef.
Here’s their order of
precedence, a.k.a
The Spanish Inquisition.

12. Yes,
DevOps & its tools got their hype on too.
So like Ran Tavory said:
Find the tool/s that work for you.
…and don’t feel bad about not using some new & shiny
hipster.js framework.
I personally do deployment automation with Chef.
Take that, Ran! Ha!

13. I don’t mean any new-age stuff. I mean:
Chef, Cloud APIs, all these tools…
They are usually passive.
Chef doesn’t know if your cookbooks are in source
control at all. Maybe you knife’d them from c:/tmp.
Cloud API doesn’t know if your landscape is derived
declarative code, or hacked together along the way.
Nothing here enforces the whole process you want.
Nothing here gives you the whole picture.

14. Some organizations (like IT@SAP, Netflix, Wix…) can afford
to build their own “overall” tool.
It supports only the specific set of tools they use.
It supports only their own version of a CD process.
You probably can’t start using it as-is.
We at SAP built our own such tool, iteration by iteration.
When we presented it to the head of R&D at some other
department inside SAP, he said:
“so, you’re trying to build a holistic thing”.
Then I realized what we were actually building all that time.

15. So sorry - I don’t have it for you,
but I’m sure the market would get more interesting.
We’re also brewing some stuff over here at the lab,
and hopefully it would grow to help you too, some day.

16.  I think it’s worth it… ;-)
 Yes, you need to build it and then they will come,
but we could all improve in taking criticism &
listening to our grumpy potential clients
(the notorious Devs, and even more notorious Ops)
 ‘nuff said, go build it…

17. Elad Rosenheim
Software Architect@SAP IT
Also in East-Asian Studies Dept.
Regarding CD,
I can only quote the film title:
“Hate: A Love Story”
Regarding picture:
Child isn’t mine, ship design is…
(elad underscore rosenheim at yahoo dot com)