© 2014 IBM Corporation

DevOps @ HiscoxJonathan FletcherEnterprise Architect Technology & Platform Lead

Me

• Jonathan Fletcher• Architect in Hiscox Group IT since 2012• Ex Dev• Ex Ops

http://enterprisedevops.blogspot.com

http://www.devops.com

@FletcherJofanon

jonathan.fletcher@hiscox.com

2

3

Who are Hiscox?

• International specialist insurer• $3.0B in GWP • 2,000 employees• 28 Offices across 13 countries• Pioneered online direct selling of business insurance• Insuring nearly 8,000 IT professionals in the USA

Agenda

• What does DevOps means to Hiscox?

• Brief history of DevOps at Hiscox

• Patterns and practises of implementing DevOps at Hiscox

• How are IBM helping Hiscox?

• Demo

• Q&A

4

5

Start demo

DevOps – classical definition

Development Operations

Culture of shared goals that reduces the friction between Development and Operations

6

DevOps friction

More process review

s M

ore change control reviews

More deploym

ent freezes M

ore standards control boards

Mor

e fr

eque

nt c

hang

esLo

wer

tole

ranc

e fo

r ou

tage

Mor

e co

mpl

ex a

pplic

atio

nsM

ore

com

plex

dep

loym

ents

Do more! Do less!

RFC’sCABDeployment guideRollback guideDaily status callsStaff availabilityIssue trackingEnvironment bookingEscalation processesEmergency processesSmall change processesetc etcMr. Dev Mr. Ops

7

DevTestBizThingyOps

• Why do we think the issue of working well together and aligning goals is limited to Developers and Operations?

• Shouldn’t everyone involved in the change process work together to accomplish shared goals?

• DevTestBizThingyOps should be the real name © J.Fletcher

8

BermudaUS Europe London MarketsUK

Hiscox yesterday (ish!)IT

cap

abili

ty

Groupdevelopment

Group support

Group infrastructure

Group testing Group DBAGroup

release and deployment

Group architecture

9

Hiscox tomorrow (ish!)

Europe

Dev

Support

Testing

DBA

Release and

deployment

Architecture

UK

Dev

Support

Testing

DBA

Release and

deployment

Architecture

London market

Dev

Support

Testing

DBA

Release and

deployment

Architecture

USA

Dev

Support

Testing

DBA

Release and

deployment

Architecture

Bermuda

Dev

Support

Testing

DBA

Release and

deployment

Architecture

10

Hiscox Model

• Federated

• Cross skilled teams

• Cradle to grave responsibilities

• Shared goals and incentives

• Underpinned by the Platform Services Group

• What started out as an ambition to increase the pace of change has evolved into “rebooting” the IT team

11

Shared goals – a DevOps example

12

Platform Services

• Growth of the business is challenging IT to find new and better ways to do things

• Means worker smarter not harder. Doesn’t mean an ever increasing head count

• Platform Services helps break down silo’s between teams by providing a change platform that is re-usable between multiple teams

• Help others use the platform (they don’t implement themselves!)

13

Core platform capabilities

• Source code management• Artefact management • Automated application

deployment• Automated server configuration• Load performance test • Automated functional test• Continuous Integration and

automated code build• Application Performance

Management• Agile planning • Defect management• More...

14

Be careful...

You don’t solve a silo issue by creating another silo! BAD

Having a team that evangelises DevOps ideas, concepts and tooling is GOOD

15

How are IBM helping?

• Selected IBM UrbanCode Deploy as our application deployment engine

• Help deliver the 1st phase of the biggest change program Hiscox has ever undertaken

• Risky? Couldn’t deliver it any other way!– 50 releases last week in 1 application alone– 17.5 man days of effort reduced to about 10 minutes– Help enable changing a 10 week change cycle down to 2 weeks– We went from 1 person knowing how to do to do a release to

thousands (kind of!)

• Investigating proof of concept with IBM Rational Test Virtualisation Server

16

17

Extreme sports deployments....

Continuous Delivery change approach

Dev

Version control(SVN)

1. Check in changes

Build(Maven)

3. Build

Artefact repository

(Artefactory)

4. Store artefacts

Regression test

(Selenium)

8. Test

Performance test

(JMeter)

9. Load testSysTest

UAT

Production

10. Deploy

CI Test servers

7. Deploy

CI(Jenkins)2. Monitor for changes

Continuously automated On demand – click button to deploy

Deployment(uDeploy)

5. Instruct deployment

Server config

(Puppet)

18

19

Convergence and divergence

ConvergeN

DivergeN+1

UrbanCode Deploy

• Move to the next release (diverge from current state)

Puppet

• Ensure that the environment is at a known state (converge towards a known state)

Characteristics

• Lower frequency of change

• Activities with little reliance on being done in a certain order

• Activities that can be safely re-run

• More infrastructure-centric

Characteristics

• Higher frequency of change• Short lived configuration changes

(i.e. take this server out of load, add it back in)

• Activities that are sequenced and dependant on one another

• Activities that may rely on human intervention

• More application-centric

Back to the demoEeeeek...

Convincing your boss

• Do a PoC – let people see stuff – a picture sells a thousand words

• Avoid lots of $$$ ROI calculations - management take these with a pinch of salt

• Instead focus on time to market, avoided effort etc

• How are you going to do it otherwise?

• Multi-releases a day?• Availability of resources?• Cost of those resources?• Geographic location?• Morale• Consistency• etc

21

Thank YouYour Feedback is

Important!

Access the InterConnect 2015 Conference CONNECT Attendee Portal to complete your session surveys from your smartphone, laptop or conference

kiosk.