Bringing Partners, Teams & Systems Together through APIs

Bringing Partners, Teams, and Systems Together Through APIs Oliver OggProduct Owner of APIs, M&S

1 Andrew BraithwaiteLaterooms.com

mandsdigital.com

3

We have a complex landscape

4 ©2016 Apigee. All Rights Reserved.


APIs

3rd parties Clouds Data centers

Why an API Team?

6

How do we evangelise?


How do we help other teams?


Developer Experience

9

How do we get good Developer Experience?



github.com/interagent/http-api-design

github.com/paypal/api-standards

API Team

15

Thank you

17

Bringing Systems Together with APIs at Laterooms !Andrew Braithwaite

Solutions Architect, laterooms.com

About Laterooms.com


•  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.

A Big Ball of Paint


LateRooms Ball of Pain(t)


We Love APIs…


We like Apigee as well…


Thank you

24

IT Agility is No Longer an Oxymoron Matthew Newton

Enterprise Architect, glh. Hotels

IT Agility is No Longer an Oxymoron Matthew Newton Enterprise Architect glh. Hotels

25

The views expressed in this presentation are those of the presenter, and not necessarily those of Apigee Corporation or the presenter’s employer.

26

who are we?

27

Who are glh. Hotels

28

London's largest owner-operator hotel company with over

4,800 bedrooms

©2016 Apigee. All Rights Reserved.

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


A Challenging Marketplace


constraints

31

Our Enterprise Scale Team


disrupt

33

disrupt: Vision

34

Deliver the best guest centric

experience in the industry


status quo: glh ICT (formal)

35

Corporate ICT Strategy : TCO reduction

Unfinished business need specification

Internal 1st ICT delivery


status quo: glh ICT (actual)

36


SHADOW IT: speed-to-market & innovation



disrupt: Mandate

37

{ lead the industry in guest facing technology, infrastructure and decision sciences }


status quo: glh ICT (actual)

38


SHADOW IT: speed-to-market & innovation



disrupt: glh ICT HYBRID delivery

39

Corporate ICT Strategy Performance Improvement

SHADOW IT: Ship Alongside Hybrid ICT

delivery


disrupt: glh Technology CLOUD 1st philosophy

40

Corporate Technology Strategy Time to Value, innovation

Ship Alongside Requirements: Principles, BDD, roadmaps

Cloud 1st delivery

SaaS


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


decouple

42

microservices now at work

43

Mon

olith

ic M

icroservices


Guest Centric = a Digital Center


developing people

45

Evolving Our Skills


develop: Technology Culture


develop: Time to Value with microservice projects


develop: Enterprise Scale Team 2016

49

Technology

15

15% increase in permanent team. 100% increase in development team. ©2016 Apigee. All Rights Reserved.

feedback loop

50

Employee Feedback: “one thing I would change”


In the 2015 Survey,

1.7%

responded SYSTEMS/TECH

a matter of weeks after glh. fully cut over to

Lessons learned so far….

56

IT Agility is No Longer an Oxymoron

embrace constraints disrupt: change CHANGE

decouple simply

Develop all Operators

57

Need correct heart

Matthew Newton Enterprise Architect @ glh. Hotels [email protected] linkedin: https://uk.linkedin.com/in/matthewjnewton

Thank you

Thank you

59

Using Containerization to Enable Your Microservice Architecture!Jonathan Bennett, Zooz

Greg Brail, Apigee

Have you Heard of Docker?

What are Containers? •  Just lighter-weight virtual machines, right? •  Not exactly?


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


Virtualization O/S-level isolation Proven; Secure; Resource-intensive

Containerization Process-level isolation Fast; Compact; Developer-friendly

Virtualization vs Containerization


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

What is Docker? •  Built on core Linux stuff •  CLI •  API •  Layered filesystem •  “Docker Hub” of images


By User:Maklaan (Based on a Docker blog post) [Public domain], via Wikimedia Commons

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


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”


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…


Who I am

Jonathan Bennett VP Architecture & Data @ Zooz

@jldb http://me.jldb.co.uk/linkedin http://me.jldb.co.uk/github


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


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


Our code base…


Tactus Tactus+ Tactus+++++++

And this is what we ended up with…


Tactus.ear

Something needed to change…


Source: https://ruxit.com/

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.


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”


Things we tried Agile will solve all of the problems. AUTOMATE ALL OF THE THINGS!


“Traditional” Continuous Integration The single .ear file deployment was cumbersome and impossible to properly introspect Large amount of running infrastructure with large overlap


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



https://ilovemicroservices.com/

Microservices

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)


µ 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


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


Our new architecture


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


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!)


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


What we look like now


What we learned


90

“If I had asked people what they wanted, they would have said faster

horses.” - Henry Ford

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


More emphasis on monitoring Emphasis on monitoring tightly coupled with the container integral to continued success


More automation


If you haven’t already automated - make it a priority

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


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


Bringing Partners, Teams & Systems Together through APIs

Technology

Transcript of Bringing Partners, Teams & Systems Together through APIs