"Using Service Oriented Operation and Provisioning at Financial Times" by Emeka Mosanya at PuppetConf 2012 Follow along with the video at: http://youtu.be/_li-3iNBSWo Using Service Oriented Operation and Provisioning at Financial Times Abstract: SOOP (Service Oriented Operation and Provisioning) is the model introduced at The Financial Times to provision and manage environments on its new private cloud. This presentation will describe the model, its benefits and how its has been implemented using Puppet. SOOP reduces the time to market to deliver business services by eliminating many of the bottlenecks associated with centralised infrastructure control in large organisations. In addition, by allowing to ""deploy the same way everywhere"", SOOP enables developers and testers to locally deploy environment on their workstation and progressively promote them to production with confidence. Speaker Bio: Emeka is an Electrical Engineer and holds a Ph.D. in Computer Science from the Swiss Federal Institute of Technology in Lausanne. He has been developing software for more than 20 years, designed custom processors and worked on the commodity trade floor of Goldman Sachs International. Emeka has several scientific publications. He has contributed to successful projects at Ubicall Communications S.A., Belgacom Mobile S.A., Algorithmics Inc., Royal Sun Alliance plc and is currently providing his services to the Financial Times where he is applying SOOP principles to automate their infrastructure provisioning. Emeka is a black belt judoka who loves long distance cycling and cold water scuba diving. Learn more about Puppet: http://bit.ly/QQoAP1

1. Using Service Oriented Operation and
Provisioning at Financial Times
Emeka Mosanya
emeka@mosanya.net
@EmekaMosanya

2. In case you didn't know...
“The Financial Times (FT) is one of the world’s
leading business news and information organisations,
recognised internationally for its authority, integrity
and accuracy."
… it is also one of the few newspapers making
money with online subscription!

3. Our goal: Reduce Cycle Time
Up to 6 weeks for a release
Business
Customers
Idea
We need to make this shorter!
We want to release several time
a day without stress...

4. Problem: Long Feedback Loop
Workstation CI QA INT STAGING PROD
$
$$$
●No environment like PROD
●Manual Configuration
●Not enough environments
Each deployment to PROD is an adventure...

5. Problem: Organizational Frictions
Release Management
Network
Create Machine
●Dilution of Responsibility Too Many
●Misalignment of Priority
Gates!

6. Our Vision
Release
Network
Create VM
Replace gates
Locally / VMWare / AWS / ... with automation

7. Deploy Services into Domains
membership.test.cloud.ft.com
controller-service-1.0.0
access-service-2.3.5
gateway-service-1.2.3
Service Definition = Puppet Domain
Modules and More

8. Service Definition = Puppet Modules
access-service-2.3.5
RPM
access
httpd nagios
Nodes Config
tomcat splunk
Application
Versioned Module library
Each service exists in its own Puppet environment
Everything you need to install a service is encapsulated in a
single versioned artifact excepted global configuration.

9. Puppet Master is part of a Service
membership.test.cloud.ft.com
controller-service-1.0.0 Puppet
DNS1 Nagios
Master
DNS2
●One Puppet Mater per Domain
●Contains “Mandatory” servers
No Sacred Cow!
… but we need a bootstrap

10. Bootstrap
We start with vanilla VM including a Base RPM
ftppm101-lvpr-uk-t ftcloud init standalone
controller-puppet.membership.test.cloud.ft.com
controller-service-1.0.0
access-service-2.3.5
Base RPM
gateway-1.2.3
ftaps104-lvpr-uk-t
ftcloud init client
access-app.membership.test.cloud.ft.com
ftppm101-lvpr-uk-t
Base RPM
From vanilla VM to a running environment in a
few shell commands...

11. Thin Integration with Infrastructure
controller-service-1.0.0
Automatic
during build
Vagrantfile
access-service-2.3.5
OVF
gateway-service-1.2.3 AWS Cloud
Formation

12. Module Path
● /etc/puppet/services modulepath:
RPM
● controller/ /etc/puppet/service/
– controller $environment
– httpd
– tomcat
– …
RPM
● access/
– access
– Tomcat
– ...

13. Deploy Services into Domains (2)
membership.test.cloud.ft.com
controller-service-1.0.0
Puppet
Master
access-service-2.3.5
gateway-service-1.2.3

14. Service Definition (2)
access-service-2.3.5
RPM
access
httpd nagios
Nodes Config
tomcat splunk
Application
Versioned Module library
What about Nodes and Config?

15. We don't use ENC
Service Definitions should contain everything we
need to deploy a service... so node definition
cannot be external!
ftaps123-lvpr-uk-p
ENC Meaningful name in DNS
●class A access-app-01
●class B
Node files defined at service level

16. Configuration with Hiera
Slight customization of the YAML backend to
use multiple configuration directories.
Facters:
Certname
Domain
Datacenter
Country
Environment (Dev, Test, Prod)
Domain Level
Service Level
Global Config

17. Global Configuration Install
membership.test.cloud.ft.com
global-config-1.3.4
RPM Puppet
Master
Global Config: Company Wide
Service Config: per service
Local Config: for override
Domain

18. That's all Folks
● Reducing bottlenecks:
● Everything is a service
● Team fully control service deployment
● No sacred cow: Puppet Master is a service
● Reducing Risk
● Everything is versioned
● Automatic deployment is the same everywhere
● Responsibilities well defined

19. FT is recruiting
The Team @FTcareers
"Jussi Heinonen" <jussi.heinonen@ft.com>
"Peter Hehn" <peter.hehn@ft.com>
"Pete Houghton" <pete.houghton@ft.com>
"Chris Malins" <chris.malins@ft.com>
"Nick Haddock" <nick.haddock@ft.com>
"Ashley de Souza" <ashley.de.souza@ft.com>
"David Reay" <David.Reay@ft.com>
"Richard Moran" <richard.moran@ft.com>
"Santanu Das" <santanu.das@ft.com>
"Barry Ridout" <barry.ridout@ft.com>
"Sujith Santhan" <sujith.santhan@ft.com>

20. Questions
?