Gareth Rushgrove, TweetWeb geek, GOV.UK
Biography: Gareth Rushgrove
Gareth Rushgrove is now a technical architect at the Government Digital Service, part of the UK Government.
He is mainly interested in configuration management, infrastructure and platform as a service, deployment and monitoring tooling and the whole devops community. He thinks when used well together these allow you to move really fast, even in tightly controlled environments like Government.
Previously he has worked as a developer and/or systems administrator for large companies, startups and things in-between, in radio, financial services, and e-commerce. Now he's a Civil Servant.
When not working, Gareth can be found blogging over on morethanseven.net or uploading code to GitHub. He also curates the devopsweekly newsletter. He's previously organised local BarCamps, technology user groups and helped out on the board of the hugely interesting Thinking Digital conference.
Presentation: TweetClouds in Government - Perils of Portability
This talk aims to ponder questions about portability in a world of Infrastructure and Platform as a Service. We'll have lots of real world examples taken from the development of GOV.UK, the recently launched single domain for the UK Government. GOV.UK went through various iterations, moving the entire stack between different cloud providers and had to deal with interesting security, legacy integration, formal accreditation and procurement processes typical in large organisations.
Lots of the talk around cloud portability focuses sorely on APIs or image formats. From our experience these are limited problems when capabilities and architectures can vary so much between providers. Differences between virtualisation layers (cloudstack, openstack, aws, vmware, xen, etc.) as well as how different vendors expose those services can lead to wide ranging incompatibilities. In the talk we'll dig into how we dealt with some of these challenges, focusing on defining Infrastructure and Networks as Code, before discussing some outstanding thorny problems. We'll try and convince you that portability is important and that a lowest common denominator approach isn't good enough.