Date post: | 14-Jan-2015 |
Category: |
Technology |
Upload: | eberhard-wolff |
View: | 3,472 times |
Download: | 1 times |
Eberhard Wolff - @ewolff
DevOps &Continuous
Deliveryin the Enterprise
Eberhard Wolff - @ewolff
I am an Enterprise &
Java guy
…so I know the Enterprise side of things.
And at least I know the technical side of
Continuous Delivery
and I had my share of DevOps stuff
2
Eberhard Wolff - @ewolff
#1 Enterprises are about to
adopt DevOps and Continuous
Delivery
Eberhard Wolff - @ewolff
It’s ofcially a buzz word
now
Lots of products in this space
Advertisements
etc
4
Eberhard Wolff - @ewolff
Lots of DevOps and Continuous Delivery
In Karlsruhe (not Berlin)
Audience were “traditional” German
companies
Quickly sold out
5
Eberhard Wolff - @ewolff
W-JAX – Java / Enterprise Conference
Continuous Delivery track was in the largest
room at the conference
Significant change from JAX 2013 – just half
a year ago
6
Eberhard Wolff - @ewolff
#2 Enterprises are di#erent
DevOps and Continuous Delivery were
established in Startups
…or at least the web business
So they solve problems typically
encountered there
But enterprises are different
7
Eberhard Wolff - @ewolff
My IT is more complex than
Amazon!
Some enterprises say their issues by nature
are more complex than everybody else’s
Even Amazon’s
That is a bold statement
Often this is an excuse not use approaches
such as DevOps or Continuous Delivery
Because they cannot possible work for them
This might even be true – because Amazon
has been using this approach for quite a
number of years.
So Amazon’s systems are adapted to
DevOps and Continuous Delivery
While most enterprise systems are not
8
Eberhard Wolff - @ewolff
Dev – featuresOps – cost
Dev and Ops are not just separate
They are even driven by different objectives
These different objectives are a very basic
assumption in enterprises
To some extend it is true:- Ops for desktop PCs should be cost
efficient – that is all that matters- Dev should of course be concerned with
features
So how do you get Dev and Ops to join?
How do you get Ops people to even join a
project then? It won’t help them to save costs.
9
Eberhard Wolff - @ewolff
Dev builds it-
Ops runs it
There is a barrier between those two
divisions
So usually you end up in this situation
10
Eberhard Wolff - @ewolff
You build it-
you run it
This is one of the cores of DevOps
But it is very alien to enterprise organizations
Shared responsiblities
11
Eberhard Wolff - @ewolff
#3 DevOps=
organization
Eberhard Wolff - @ewolff
Need to change the
organization
Dev and Ops people need to collaborate
Ideally Dev and Ops are in the same team
This means you have to change the
organization
b/c you need teams for certain functions
13
Eberhard Wolff - @ewolff
Changing the organization
is hard
People have all kinds of issues- Fear of losing their jobs- Fear of losing privileges- General unease about any changes
So implementing DevOps in an organization is
hard
14
Eberhard Wolff - @ewolff
DevOps=
Culture
At the end DevOps is about collaboration
So it is “just” a culture
So a new organization is not necessarily
needed
15
Eberhard Wolff - @ewolff
Do you need change the
organization?
There are different ways to deals with this
problem- Colocate team consisting of Dev and Ops
At the end matrix organizations where line
management and project are two different
issues are quite common
Separation might be needed because of
regulations and
Common goal still needed?
Shared pain
16
Eberhard Wolff - @ewolff
DevOps teams
How can you get started?
I believe a team that pioneers the approach
for its application is not a bad idea
This is not creating another silo – it is
eliminating the silo for one specific project
17
Eberhard Wolff - @ewolff
#4 Time-to-Market is not
that important
Startups cannot succeed if they are unable
to put new features in the face of the
customers quickly
Enterprises are different
They do just a few releases for a reason- The market is not that competitive- Other parts of the organization cannot keep
up (e.g. training)
Enterprises are doing just one release a
quarter or so for a reason.
It is not entirely obvious that releasing more
frequent is always needed.
However, releases and feature can be
decoupled – so it is not always necessary to
train the user or even introduce new features.18
Eberhard Wolff - @ewolff
Sometimes time-to-market is
paramount
As soon as enterprises compete against
other companies on the web they switch over
other principles
I know several examples from my own
experience
But those cases are not that interesting to
me
- because they are not fundamentally
different to established approaches
19
Eberhard Wolff - @ewolff
Enterprises can also deploy quickly
If it is really necessary – an Enterprise can
roll out a change in a matter of minutes
As a quick fix
It is just without any tests
And without sophistication
So the value must be somewhere else
20
Eberhard Wolff - @ewolff
#5 Benefts in the Enterprise are di#erent
So – if time to market is not always a good
motivation to adopt DevOps and Continuous
Delivery - why would enterprises care?
21
Eberhard Wolff - @ewolff
Automation=
Reproducible=
Reduced Risk
The Automation Continuous Delivery
advocates means that the delivery process
can be reproduced.
So risk can be reduced – you are just doing
the same thing over and over again.
No more high risk releases on weekends
No more “point of no return”
Reducing risk appeals to entperises
22
Eberhard Wolff - @ewolff
Small batches=
Reduced risk
Continuous Delivery at its core reduces the
amount of code that is put into production at
a release
So the batch size is reduced
This is essentially lean – smaller batches,
less waste
It reduces risk: In a smaller batch it is much
less likely to introduce an error
23
Eberhard Wolff - @ewolff
Paradox: Enterprises’Infrequent releases =
Reduced risk
Why are enterprises releasing less often?
This is a strategy to reduce risk
A release might fail and it is hard to do.
Therefore enterprises release less frequent.
So there are just so many occasions when
releases might fail
So releasing more often seems risky to them
But it is really a higher risk: Changes pile up
and deployments are more likely to fail
----- Besprechungsnotizen (04.12.13 19:42)
-----
Quality = risk?
24
Eberhard Wolff - @ewolff
DevOps = customer-oriented IT
The IT must still have separate
organizational units
They are not around Development or
Operations
So they are concerned with services and
functions of the IT
This has a lot benefits for enterprise ITs- A competitive advantage over external IT
provider- Better service
This might be a good reason to do DevOps in
my experience
25
Eberhard Wolff - @ewolff
Test in Production
Using Feature Toggles allows you to test
new features in production.
Therefore the need for test environments is
reduced.
Having a production-like test environment is
often not an option, anyway.
A/B testing is also easily possible
26
Eberhard Wolff - @ewolff
#6 DevOps will be
adopted like Agile
Agile and DevOps are about similar topics- Culture & values- Faster time to market
27
Eberhard Wolff - @ewolff
Step 1:Resistance
DoubtOrthodoxBottom up
This is agile around 2000
When agile originally started it faced
resistance
People didn’t want to use it
People thought it could not possibly work
They were teaching the concepts in an
orthodox ways – because otherwise people
would not follow it
Mostly technical people were introducing it
It was not on the agenda of the management
This is the state of DevOps and Continuous
Delivery right now28
Eberhard Wolff - @ewolff
Adoption:OrthodoxBottom up
This is agile around 2000
When agile originally started it faced
resistance
People didn’t want to use it
People thought it could not possibly work
They were teaching the concepts in an
orthodox ways – because otherwise people
would not follow it
Mostly technical people were introducing it
It was not on the agenda of the management
This is the state of DevOps and Continuous
Delivery right now29
Eberhard Wolff - @ewolff
Problem:Buy-In from Management
Eberhard Wolff - @ewolff
Step 2:Accepted in Mainstream
Most developers and technical managers
agree this is the way to go
No need to discuss the need for it any more
Project start implementing it en masse
This is Agile after 2005
31
Eberhard Wolff - @ewolff
Adoption: Just get a Coach
There are many coaches – and you just have
them implement the technique for you
32
Eberhard Wolff - @ewolff
Problem:Hard to
actually make it work
But it is still hard to really make agile work.
There are too many
33
Eberhard Wolff - @ewolff
Step 3:Everybody
claims he is doing it
Scrum has replaced Waterfall as a the
defauilt
This is the current situation
34
Eberhard Wolff - @ewolff
Problem: Core values
are often not understood
The agile core values are often still not
followed and understood.
Sometime they are not even shared by the
organization.
Agile fits only specific organizations
35
Eberhard Wolff - @ewolff
Disillusion
It is obvious now that Agility won’t solve all
problems
36
Eberhard Wolff - @ewolff
How can DevOps and Continuous Delivery avoid
this?
Eberhard Wolff - @ewolff
Customize Continuous Delivery & DevOps for Enterprises
The real problem are values and the
environment agility is used in
38
Eberhard Wolff - @ewolff
#1 Enterprises are about to adopt DevOps and Continuous Delivery
#2 Enterprises are different
#3 DevOps=organization
#4 Time-to-Market is not that important
#5 Benefits in the Enterprise are different
#6 DevOps will be adopted like Agile
Eberhard Wolff - @ewolff
Thanks!
----- Besprechungsnotizen (04.12.13 20:21)
-----
Incremental bringing it in
show value
40