Using Service Oriented Operation and Provisioning at Financial TimesPresentation Transcript
Using Service Oriented Operation and Provisioning at Financial Times Emeka Mosanya email@example.com @EmekaMosanya
In case you didnt know...“The Financial Times (FT) is one of the world’sleading business news and information organisations,recognised internationally for its authority, integrityand accuracy." … it is also one of the few newspapers making money with online subscription!
Our goal: Reduce Cycle Time Up to 6 weeks for a releaseBusiness CustomersIdea We need to make this shorter! We want to release several time a day without stress...
Problem: Long Feedback LoopWorkstation CI QA INT STAGING PROD $ $$$ ●No environment like PROD ●Manual Configuration ●Not enough environments Each deployment to PROD is an adventure...
Problem: Organizational Frictions Release Management Network Create Machine ●Dilution of Responsibility Too Many ●Misalignment of Priority Gates!
Our Vision Release Network Create VM Replace gatesLocally / VMWare / AWS / ... with automation
Deploy Services into Domains membership.test.cloud.ft.comcontroller-service-1.0.0access-service-2.3.5gateway-service-1.2.3Service Definition = Puppet DomainModules and More
Service Definition = Puppet Modulesaccess-service-2.3.5 RPM access httpd nagios Nodes Config tomcat splunk Application Versioned Module library Each service exists in its own Puppet environmentEverything you need to install a service is encapsulated in asingle versioned artifact excepted global configuration.
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” serversNo Sacred Cow!… but we need a bootstrap
Bootstrap We start with vanilla VM including a Base RPMftppm101-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.3ftaps104-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...
Thin Integration with Infrastructurecontroller-service-1.0.0 Automatic during build Vagrantfileaccess-service-2.3.5 OVFgateway-service-1.2.3 AWS Cloud Formation
Deploy Services into Domains (2) membership.test.cloud.ft.comcontroller-service-1.0.0 Puppet Masteraccess-service-2.3.5gateway-service-1.2.3
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?
We dont use ENCService Definitions should contain everything weneed to deploy a service... so node definitioncannot be external! ftaps123-lvpr-uk-p ENC Meaningful name in DNS ●class A access-app-01 ●class B Node files defined at service level
Configuration with HieraSlight customization of the YAML backend touse multiple configuration directories. Facters: Certname Domain Datacenter Country Environment (Dev, Test, Prod) Domain Level Service Level Global Config
Global Configuration Install membership.test.cloud.ft.comglobal-config-1.3.4 RPM Puppet MasterGlobal Config: Company WideService Config: per serviceLocal Config: for override Domain
Thats 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
FT is recruiting The Team @FTcareers"Jussi Heinonen" <firstname.lastname@example.org>"Peter Hehn" <email@example.com>"Pete Houghton" <firstname.lastname@example.org>"Chris Malins" <email@example.com>"Nick Haddock" <firstname.lastname@example.org>"Ashley de Souza" <email@example.com>"David Reay" <David.Reay@ft.com>"Richard Moran" <firstname.lastname@example.org>"Santanu Das" <email@example.com>"Barry Ridout" <firstname.lastname@example.org>"Sujith Santhan" <email@example.com>