More Related Content Similar to Bringing Partners, Teams & Systems Together through APIs (20) More from Apigee | Google Cloud (20) Bringing Partners, Teams & Systems Together through APIs1. Bringing Partners, Teams, and
Systems Together Through APIs
Oliver Ogg
Product Owner of APIs, M&S
1
Andrew Braithwaite
Laterooms.com
4. We have a complex landscape
4
©2016 Apigee. All Rights Reserved.
7. How do we evangelise?
7
©2016 Apigee. All Rights Reserved.
8. How do we help other teams?
8
©2016 Apigee. All Rights Reserved.
10. How do we get good Developer
Experience?
10
©2016 Apigee. All Rights Reserved.
14. 14
©2016 Apigee. All Rights Reserved.
github.com/interagent/http-api-design
github.com/paypal/api-standards
18. About Laterooms.com
18
©2016 Apigee. All Rights Reserved.
• LateRooms.com was born in Salford,
Greater Manchester in 1999, starting life
as an 'on the day for the day' booking
site for unsold hotel rooms.
• Now you can book up to a year in
advance and we will help you plan all
those upcoming events, activities and
special occasions for which you need a
hotel.
• More hotels than you'll ever need. Across
the UK, Europe and Worldwide.
• Over 2 million genuine guest reviews to
help you choose
• Book 24/7 – online or over the phone.
19. A Big Ball of Paint
19
©2016 Apigee. All Rights Reserved.
24. 24
IT Agility is No Longer an Oxymoron
Matthew Newton
Enterprise Architect,
glh. Hotels
25. IT Agility is No Longer an Oxymoron
Matthew Newton
Enterprise Architect
glh. Hotels
25
26. The views expressed in this presentation are those of
the presenter, and not necessarily those of Apigee
Corporation or the presenter’s employer.
26
28. Who are glh. Hotels
28
London's largest
owner-operator hotel
company with over
4,800 bedrooms
©2016 Apigee. All Rights Reserved.
29. Who are glh. Hotels: The Vision
29
WORLD'S BEST MANAGED GLOBAL
HOSPITALITY COMPANY
Deliver the best guest centric
experience in the industry
Doubling prime value and economic
profit every 3-5 years
©2016 Apigee. All Rights Reserved.
35. status quo: glh ICT (formal)
35
Corporate ICT
Strategy :
TCO reduction
Unfinished
business need
specification
Internal 1st ICT
delivery
©2016 Apigee. All Rights Reserved.
36. status quo: glh ICT (actual)
36
Corporate ICT Strategy :
TCO reduction
SHADOW IT:
speed-to-market &
innovation
Internal 1st ICT
delivery
©2016 Apigee. All Rights Reserved.
37. disrupt: Mandate
37
{ lead the
industry in guest
facing technology,
infrastructure and
decision
sciences }
©2016 Apigee. All Rights Reserved.
38. status quo: glh ICT (actual)
38
Corporate ICT Strategy :
TCO reduction
SHADOW IT:
speed-to-market &
innovation
Internal 1st ICT
delivery
©2016 Apigee. All Rights Reserved.
39. disrupt: glh ICT HYBRID delivery
39
Corporate ICT Strategy
Performance
Improvement
SHADOW IT:
Ship AlongsideHybrid ICT
delivery
©2016 Apigee. All Rights Reserved.
40. disrupt: glh Technology CLOUD 1st philosophy
40
Corporate Technology
Strategy
Time to Value,
innovation
Ship Alongside
Requirements:
Principles, BDD, roadmaps
Cloud 1st
delivery
SaaS
©2016 Apigee. All Rights Reserved.
41. disrupt: glh Technology DIGITAL philosophy
41
Corporate Technology
Strategy
Time to Value
Product development
API first
Industry Leading
Business
Requirements:
BDD, roadmaps
Cloud delivery
IaaS
PaaS
SaaS
©2016 Apigee. All Rights Reserved.
48. develop: Time to Value with microservice projects
48
©2016 Apigee. All Rights Reserved.
49. develop: Enterprise Scale Team 2016
49
Technology
15
15% increase in permanent team.
100% increase in development team.
©2016 Apigee. All Rights Reserved.
54. Employee Feedback: “one thing I would change”
54
©2016 Apigee. All Rights Reserved.
In the 2015 Survey,
1.7%
responded SYSTEMS/TECH
a matter of weeks after glh. fully cut over to
56. Lessons learned so far….
56
IT Agility is No Longer an Oxymoron
embrace constraints
disrupt: change CHANGE
decouple simply
Develop all Operators
62. What are Containers?
• Just lighter-weight virtual machines, right?
• Not exactly?
62
©2015 Apigee. All Rights Reserved.
63. Virtual Machines
Separate kernels (any OS)
Separate device drivers
Memory isolation
Filesystem isolation
CPU usage restrictions
Boots in minutes
Tens per physical machine
Containers
Shared Linux kernel
Shared device drivers
Memory isolation
Filesystem isolation
CPU usage restrictions
Boots in seconds
Hundreds per physical machine
Virtual Machines vs. Containers
63
©2015 Apigee. All Rights Reserved.
64. Virtualization
O/S-level isolation
Proven; Secure; Resource-intensive
Containerization
Process-level isolation
Fast; Compact; Developer-friendly
Virtualization vs Containerization
64
©2015 Apigee. All Rights Reserved.
Hardware
Device Drivers
Hypervisor
Kernel
Filesystem
O/S Daemons
App
App
Kernel
Filesystem
O/S Daemons
App
App
Hardware
Device Drivers
Filesystem
O/S Daemons
App
Kernel
F/S
App
F/S
App
F/S
App
F/S
65. What is Docker?
• Built on core Linux stuff
• CLI
• API
• Layered filesystem
• “Docker Hub” of images
65
©2015 Apigee. All Rights Reserved.
By User:Maklaan (Based on a Docker blog post) [Public domain], via Wikimedia Commons
66. Docker Usability
Let’s start up Cassandra, Zookeeper, and Postgres on a host…
docker
run
–e
POSTGRES_PASSWORD=realsecret
–d
5432:5432
postgres
docker
run
-‐d
-‐p
2181:2181
-‐p
2888:2888
-‐p
3888:3888
jplock/zookeeper:3.4.6
docker
run
-‐d
-‐-‐net=host
-‐p
9160:9160
-‐p
9042:9042
-‐p
7000:7000
-‐p
7001:7001
-‐p
7199:7199
-‐e
CASSANDRA_LISTEN_ADDRESS=192.168.99.100
-‐e
CASSANDRA_BROADCAST_ADDRESS=192.168.99.100
cassandra:2.0
66
©2015 Apigee. All Rights Reserved.
67. What Makes Docker Exciting?
• Standard packaging format
– Docker image may be run on any Docker-enabled host
• Each container is self-contained
– Container has its own filesystem and files
– Contract specifies ports and persistent disks required
– Not much else
– Vastly less “versionitis”
• Standard installation process
– Specifics of packaging and installation are inside the container
• Less “versionitis”
67
©2015 Apigee. All Rights Reserved.
68. The Real Promise of Docker
• Start with those standardized containers
• Deploy them to an elastic pool of hardware
• Scale them up and down
• Switch versions without downtime
• Wire them together and to the Internet via APIs
• and more…
68
©2015 Apigee. All Rights Reserved.
69. Who I am
Jonathan Bennett
VP Architecture & Data @ Zooz
@jldb
http://me.jldb.co.uk/linkedin
http://me.jldb.co.uk/github
69
©2015 Apigee. All Rights Reserved.
70. Who we are
Online Payments Platform bringing together many financial institutions, integrating
acquirers, gateways, 3rd party solution providers all through a single integration
60 Employees in 3 locations, USA, UK and Israel
1000s of merchants globally, trading 24x7
70
©2015 Apigee. All Rights Reserved.
71. A brief history of us
Started as a “Pay at Table” restaurant service…
Pivoted to single-line integration checkout…
Pivoted again to API driven platform
71
©2015 Apigee. All Rights Reserved.
73. And this is what we ended up with…
73
©2015 Apigee. All Rights Reserved.
Tactus.ear
74. Something needed to change…
74
©2015 Apigee. All Rights Reserved.
Source: https://ruxit.com/
75. The challenge
Strict security requirements due to Level 1 PCI
Strict “no downtime” policy for API services
Lots of legacy code across the system which was hard to diagnose and find problems
Large parts of testing not automated - long regression test period (frequently 5 business
days)
Deployments to 10 app servers took over 8 hours.
75
©2015 Apigee. All Rights Reserved.
76. Our customers
Internal R&D teams
“We need to build faster”
QA teams
“We need to test faster”
Infrastructure & operations teams
“We need to test faster”
76
©2015 Apigee. All Rights Reserved.
77. Things we tried
Agile will solve all of the problems.
AUTOMATE ALL OF THE THINGS!
77
©2015 Apigee. All Rights Reserved.
78. “Traditional” Continuous Integration
The single .ear file deployment was cumbersome and impossible to properly introspect
Large amount of running infrastructure with large overlap
78
©2015 Apigee. All Rights Reserved.
79. Just break it up
Tactus was broken down into “components”
A spewing of libraries, “common.jar” and overlap happened
Everything still compiled into “tactus.ear” in the end
79
©2015 Apigee. All Rights Reserved.
81. Microservices, a primer…
• API Services are created around specific capabilities, such as front ends, proxies etc
• Typical Microservice orientated architectures may comprise of many different languages
• Architectures tend to be of a producer / consumer model
• Tends to work well in continuous development environments
Main criticisms:
• Shifts the complexity from a monolith to other things, such as network, Load balancing
and fault tolerance (Basic distributed computing problems)
• Deployment gets more complicated (as we’ll discuss later)
81
©2015 Apigee. All Rights Reserved.
82. µ all of the things
Took the basis of our common libraries and rationalised our codebase
Approached the project like an onion - taking layers off gradually - approaching the core
as we speak
82
©2015 Apigee. All Rights Reserved.
83. Our steps
1. Instated martial law on “old ways of working for new projects” - introduced bounties to
those who turned others in (for fun, of course…)
2. Refactored API Façade to be a service layer above other system APIs transparently to
customers
3. Moved onto new processor code (business logic and API integrations)
4. Refactoring internal APIs last
83
©2015 Apigee. All Rights Reserved.
85. Deployment considerations
Managing / monitoring / scaling this many “application servers” would be a nightmare
Servers needed to be identical for predictability
All deployment should be automated, and scaling should be instant
85
©2015 Apigee. All Rights Reserved.
86. That’s where containers came in
Resource and process isolation
Quick to start with little system overhead
Predictable - build once use everywhere (even for QA!)
86
©2015 Apigee. All Rights Reserved.
87. Main considerations
Monitoring
- A 24/7 system needs substantial monitoring
Deployment
- We need to be able to deploy quickly
- Need to be able to deploy reliably
- Need to move towards continuous deployment
87
©2015 Apigee. All Rights Reserved.
88. What we look like now
88
©2015 Apigee. All Rights Reserved.
90. 90
“If I had asked people what they
wanted, they would have said faster
horses.”
- Henry Ford
91. Get a scheduler
Finding a scheduler that works for us will be the key to our continued microservice-with-
container success
Experimented a lot, Lattice, Kubernetes, ECS and now running experiments with Nomad
91
©2015 Apigee. All Rights Reserved.
92. More emphasis on monitoring
Emphasis on monitoring tightly coupled with the container integral to continued success
92
©2015 Apigee. All Rights Reserved.
94. Blue/green deployments as a standard
Increase in speed of deployment gives more flexibility for partial deploy (and rollback)
Found problems in minutes that would usually surface way too late
94
©2015 Apigee. All Rights Reserved.
95. Conclusions
• Microservices are awesome
• Containers help with not only the running of the applications, but also the delivery
process as well
• Great schedulers are coming – finding one ASAP will be key
95
©2015 Apigee. All Rights Reserved.