This document summarizes Lush's migration of their e-commerce platform from their previous cloud provider to Google Cloud Platform (GCP) on an accelerated timescale due to concerns about the previous provider. It describes why they chose GCP due to its alignment with Lush's ethics and capabilities. It then outlines the architecture implemented on GCP using infrastructure as code with Terraform templates, ready-made images, autoscaling, and Stackdriver monitoring. Benefits included cost savings, simplified infrastructure, and preparing for future cloud-native capabilities.

1. Lush E-Commerce
Migration
Google Cloud in a crazy timescale

2. ● Why did we do this?
● What did we do?
● How we did it
● What were the benefits?
● What’s next?
Agenda

3. Why?
Ryan Kerry, Lush

4. Who are Lush?

5. Why Move?
● Not aligned to Lush’s Ethics
● Blackbox / Closed Solution
● No Flexibility Inside the
Platform
● Poor Support
● Limited Capabilities
● Excessive Costs
● Poor Billing Model
● Vendor Lock In

6. Why GCP?
● Future Proofing Lush’s
Technology Stack
● Aligns to Lush’s Ethical Approach
● No Vendor Lock-in (Open Cloud)
● Full Control over Infrastructure
● Fast Network and Robust
Backbone
● Per minute billing
● Sustained Use Discounts
● Preemptible VM Instances
● Brilliant Support

7. Timescales
November December
11th November
Project kicks off
18th November
Contract signed
17th - 20th December
Go live period
22nd December
End of service from
previous supplier

8. Architecture
Marcus Johansson, Google

9. Warehouse
SOLSOL
SML QMS
OS OSA
SOLR SOLR
WEB SOLR
UK SITE
Warehouse
SML
QMS
SOL
OS OSA
SOLR SOLR
WEB SOLR
UK SITE NEW COUNTRY
CUSTOMER
SERVICES
SINGLE SIGN ON
CONTENT REPO

10. Lift and shift + select managed services
Compute Engine
Cloud SQL
2nd generation
Cloud Load
Balancing
Google
Stackdriver

11. Memcache
Compute Engine
Memcache
Compute Engine
Memcache
Compute Engine
Varnish
Compute Engine
Memcache
Compute Engine
Cloud SQL
Cloud SQL
Cloud SQL
Cloud SQL
Solr (Search)
Compute Engine
Frontend
Compute Engine
Content Repo
Compute Engine
Order Store
Compute Engine
SSO
Compute Engine
Varnish
Compute Engine
Cloud Load
Balancing

12. europe-west1
UK and EMEA
asia-east1
India, HK, JP, and
APAC
us-central1
US and LATAM

13. Production Infrastructure
● 3 Locations, 3 Regions, 9 Zones
● 175+ Instances (Autoscaler)
● 36 Cloud SQL 2nd generation Instances
● More of the same for non-production, i.e.
development and staging

14. How we did it
Sam Bashton

15. Philosophy

16. MVC: Minimum Viable Cloud
● Any machine can be terminated at any time and will
self heal
● Infrastructure active/active in at least two zones
● Infrastructure defined as code
● Use drop-in replacement services where available
● Automated deployments

17. Infrastructure as Code
● Modern sysadmin (‘devops’):
○ 60% dev
○ 40% ops
● Don’t build infrastructure - build templates that build
infrastructure

18. Infrastructure as Code
● Pre-built ‘building block’ templates - Terraform
modules
● 80/20 rule - 80% of the work is standard
● Allows us to concentrate of the interesting 20%
● Massively reduces time to deliver

19. Reducing Repetition
● Templates heavily re-used:
○ Multiple environments
■ Dev
■ Stage
■ Production
○ Multiple Regions
■ APAC
■ EMEA
■ US

20. Terraform
● Build infrastructure
across multiple
regions
● One set of templates
● Variables for
differences between
environments
module "sso-instance-template" {
source = "git::ssh://git@foo/tfmodules/instance-tmpl.git"
machine_type = "${var.sso_machine_type}"
preemptible = "${var.preemptible}"
envname = "${var.envname}"
service = "sso"
domain = "${var.envname}.${var.domain}"
fw_tags = ["global", "sso", "gluster-client"]
needs_nat = "natted"
startup_script =
"gs://${var.bootstrap_bucket}/lush-sso-bootstrap.sh"
disk_image = "${var.disk_image}"
gcp_region = "${var.gcp_region}"
}
module "sso-group-manager" {
source =
"git::ssh://git@foo/tfmodules/tf-gce-instance-group-manager.git"
service = "sso"
instance_template = "${module.sso-instance-template.link-subnets}"
}

21. Production Infrastructure Code
● 3 Locations, 3 Regions, 9 Zones
● 175+ Instances (Autoscaler)
● 36 Cloud SQL 2nd generation Instances
● < 2200 lines of Terraform code

22. Ready Meal Images
● Part-baked images created
with Packer
● Boot time configuration with
Puppet

23. Autoscaling

24. Production
Stage
Development
Github
Branch: develop
Jenkins
.deb build
Multiple Regions
Jenkins
.deb install
GCS Bucket
Deb Repository
Multiple Regions
Jenkins
.deb install
Multiple Regions
Jenkins
.deb install
GCS Bucket
Deb Repository
GCS Bucket
Deb Repository
Jenkins
.deb promote
Github
Branch: stable
Or master
Jenkins
.deb build
Deployments

25. Logging and Monitoring
● Stackdriver
○ Agent installed on every instances, exports logs
and metrics

26. Difficulties Faced
● Poor Terraform support for Cloud SQL 2nd Generation
○ Yay for Open Source - we could fix this ourselves
(PRs awaiting merge)
● Old PaaS used MySQL - but no mechanism for database
replication available
○ Required a full dump and restore, meaning multi-hour
downtime

27. Money Saving
● Autoscaling ensures we only run the infrastructure
necessary for the current levels of traffic
● Switching dev/staging to Preemptible VMs has saved
£££
● Right-sizing recommendations saved more ££
● 40% saving

28. Key Improvements
● Global network
● Simplified Infrastructure
● Cheaper!
● Autoscaling

29. What’s Next?
Ryan Kerry, Lush

30. What’s Next?
Now:
● Service Orientated Architecture
Transformation
● Containerisation of Application
(GKE)
● Data Warehouse
(Big Query & Data Proc and
Dataflow)
● Cloud Native Components
(Pub/Sub & Dataflow).
Future:
● No-ops approach - Cloud
Functions.
● Machine Learning and AI
Capabilities.
● Speech, Vision and Video
APIs.

31. Thank you

32. Lush E-Commerce
Migration
Google Cloud in a crazy timescale