Using containerization to enable your microservice architecture

1
Using Containerization to Enable Your Microservice Architecture!
Jonathan Bennett, Zooz
Greg Brail, Apigee

Have you Heard of Docker?
3
©2015 Apigee. All Rights Reserved.

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

•  Not exactly?
4

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
5

Virtualization
O/S-level isolation
Proven; Secure; Resource-intensive
Containerization
Process-level isolation
Fast; Compact; Developer-friendly
Virtualization vs Containerization
6
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 ﬁlesystem
•  “Docker Hub” of images
7
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

8

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”
9

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…
10

Who I am
Jonathan Bennett
VP Architecture & Data @ Zooz

@jldb

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

http://me.jldb.co.uk/github
11

Who we are
Online Payments Platform bringing together many ﬁnancial 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
12

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
13

Our code base…
14
Tactus
Tactus+
Tactus+++++++

And this is what we ended up with…
15
Tactus.ear

Something needed to change…
16
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 ﬁnd problems

Large parts of testing not automated - long regression test period (frequently 5 business
days)

Deployments to 10 app servers took over 8 hours.
17

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”
18

Things we tried
Agile will solve all of the problems.

AUTOMATE ALL OF THE THINGS!
19

“Traditional” Continuous Integration
The single .ear ﬁle deployment was cumbersome and impossible to properly introspect

Large amount of running infrastructure with large overlap
20

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
21

22
https://ilovemicroservices.com/
Microservices

Microservices, a primer…
•  API Services are created around speciﬁc 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)
23

µ 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
24

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
25

Our new architecture
26

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
27

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

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
29

What we look like now
30

What we learned
31

32
“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
33

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

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

Blue/green deployments as a standard
Increase in speed of deployment gives more ﬂexibility for partial deploy (and rollback)

Found problems in minutes that would usually surface way too late
36

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 – ﬁnding one ASAP will be key
37

Using containerization to enable your microservice architecture

Recommended

More Related Content

What's hot (20)

Viewers also liked (20)

Similar to Using containerization to enable your microservice architecture (20)

More from Apigee | Google Cloud (20)

Recently uploaded (20)

Using containerization to enable your microservice architecture