Slide 1

Slide 1 text

Up in the sky Architecture and Deployment of Microservices for the Cloud AXEL FONTAINE @axelfontaine [email protected]

Slide 2

Slide 2 text

About Axel Fontaine • Founder and CEO of Boxfuse • Over 15 years industry experience • Continuous Delivery expert • Regular speaker at tech conferences • JavaOne RockStar in 2014 @axelfontaine

Slide 3

Slide 3 text

flywaydb.org

Slide 4

Slide 4 text

boxfuse.com

Slide 5

Slide 5 text

about questions

Slide 6

Slide 6 text

POLL: what type of infrastructure are you running on? • On Premise • Colocation • Root Server • Cloud

Slide 7

Slide 7 text

How did this evolve ?

Slide 8

Slide 8 text

+ = ON PREM + Challenges • Power, Network, Cooling • Physical Security • Physical Space • Procurement, Vendor Management • Capacity Planning • Financing • OS + Patches • App + Updates

Slide 9

Slide 9 text

+ = ON PREM + Our responsibility

Slide 10

Slide 10 text

+ + Our responsibility Their responsibility = COLO

Slide 11

Slide 11 text

+ = COLO + Simple, stable, standards-compliant interface: (19” Rack, AC Power, Ethernet, …)

Slide 12

Slide 12 text

Can change as long as it complies with the interface contract + = COLO + Undifferentiated Heavy Lifting Our responsibility Their responsibility

Slide 13

Slide 13 text

= ROOT SERVER + Undifferentiated Heavy Lifting Our responsibility Can change as long as it complies with the interface contract

Slide 14

Slide 14 text

= ROOT SERVER + Undifferentiated Heavy Lifting Simple, stable, standards- compliant interface Software <-> Hardware

Slide 15

Slide 15 text

Room For Innovation + Undifferentiated Heavy Lifting Simple, stable, standards- compliant interface

Slide 16

Slide 16 text

what about the cloud ??

Slide 17

Slide 17 text

Every day, AWS adds enough server capacity to power the whole $7B enterprise Amazon.com was in 2004. Weekends included.

Slide 18

Slide 18 text

"Advanced Test Reactor" by Argonne National Laboratory - originally posted to Flickr as Advanced Test Reactor core, Idaho National LaboratoryUploaded using F2ComButton. Licensed under CC BY-SA 2.0 via Wikimedia Commons - http://commons.wikimedia.org/wiki/File:Advanced_Test_Reac tor.jpg#mediaviewer/File:Advanced_Test_Reactor.jpg "RIAN archive 341194 Kursk Nuclear Power Plant" by RIA Novosti archive, image #341194 / Sergey Pyatakov / CC-BY-SA 3.0. Licensed under CC BY-SA 3.0 via Wikimedia Commons - http://commons.wikimedia.org/wiki/File:RIAN_archive_341194_ Kursk_Nuclear_Power_Plant.jpg#mediaviewer/File:RIAN_archi ve_341194_Kursk_Nuclear_Power_Plant.jpg Control Plane Data Plane

Slide 19

Slide 19 text

Control Plane Data Plane

Slide 20

Slide 20 text

 Shift to a world of abundance (no more resource scarcity)  Clean Control Plane/Data Plane split with API-based provisioning  Cost-based Architectures with the ability to turn infrastructure off benefits of the cloud

Slide 21

Slide 21 text

moving to the cloud

Slide 22

Slide 22 text

lift & shift (= the naïve approach)

Slide 23

Slide 23 text

Congratulations! You now have:  A more expense Hetzner/OVH  Lots of (too much?) trust in your cloud provider  Potential legal trouble due to data privacy laws lift & shift (= the naïve approach)

Slide 24

Slide 24 text

understanding the cloud

Slide 25

Slide 25 text

regions

Slide 26

Slide 26 text

availability zones <>

Slide 27

Slide 27 text

building blocks http://en.wikipedia.org/wiki/Lego#/media/File:Lego_Color_Bricks.jpg

Slide 28

Slide 28 text

building blocks Security Storage Network Compute

Slide 29

Slide 29 text

No content

Slide 30

Slide 30 text

The hard Truth about Security 1. Always breakable with infinite time & resources 2. Must make it more complicated/expensive to break than it’s worth (use defense in depth!) 3. Has a usability cost 4. Almost always about the data

Slide 31

Slide 31 text

the 3 states of data Data at Rest Data in Motion Data in Use

Slide 32

Slide 32 text

Trusting your neighbors is good. But it’s even better to put a good lock on the door. Werner Vogels http://en.wikipedia.org/wiki/Werner_Vogels#/media/File:Wernervogels_ddp.jpg

Slide 33

Slide 33 text

Data in Motion TLS / SSL

Slide 34

Slide 34 text

Data in Use & at Rest Client-side encryption

Slide 35

Slide 35 text

Client-side encryption  Encrypt sensitive & personally identifiable data  Use different Encryption key for each field/record  Encrypt Encryption Key using Key encrypting Key  Secure & Rotate the Key encrypting Key

Slide 36

Slide 36 text

Key Management In App € KMS €€ HSM €€€€€

Slide 37

Slide 37 text

Querying Encrypted Data Other clear text field Id Encrypted 123 #!azw\b 456 67ftf6&) Exact Match => Hmac Hmac Encrypted 5841545832 #!azw\b 0219237127 67ftf6&) Range => Lower fidelity Low Fi Encrypted 48.5 #!azw\b 37.2 67ftf6&) => Use transparent persistence layer converters!

Slide 38

Slide 38 text

the compute building block

Slide 39

Slide 39 text

POLL: which level of automation are you at? • Build • Unit Tests • Continuous Integration • Acceptance Tests • Continuous Deployment (Code) • Continuous Deployment (Code + DB + Configuration) • Infrastructure

Slide 40

Slide 40 text

Build Test

Slide 41

Slide 41 text

Build Test

Slide 42

Slide 42 text

• One immutable unit • Regenerated after every change • Promoted from Environment to Environment Classic Mistake: Build per Environment

Slide 43

Slide 43 text

Image Instance Fully Baked Provisioned on Startup ?

Slide 44

Slide 44 text

Fully Baked Provisioned on Startup Most people  Every Instance 100% identical  Fastest startup  Launch always succeeds

Slide 45

Slide 45 text

Fully Baked Provisioned on Startup Most people  One immutable unit  Regenerated after every change  Promoted from environment to environment

Slide 46

Slide 46 text

Fully Baked  One immutable unit  Regenerated after every change  Promoted from environment to environment Image

Slide 47

Slide 47 text

 One immutable unit  Regenerated after every change  Promoted from environment to environment

Slide 48

Slide 48 text

Fully Baked  One immutable unit  Regenerated after every change  Promoted from environment to environment Image

Slide 49

Slide 49 text

instances General Purpose CPU RAM Disk

Slide 50

Slide 50 text

scaling & costs vs auto-scale based on various factors => prefer smaller granularity

Slide 51

Slide 51 text

types of services sync => load async => queue depth cron => time => but also instance health!

Slide 52

Slide 52 text

high uptime is a liability The longer an instance is up, the harder it becomes to recreate exactly (and it will fail eventually!)

Slide 53

Slide 53 text

Focus shift Individual instances become disposable Instance Service

Slide 54

Slide 54 text

keep your instances stateless

Slide 55

Slide 55 text

Treat servers like cattle instead of pets

Slide 56

Slide 56 text

What are the implications ???

Slide 57

Slide 57 text

How to solve service discovery ? Use a stable entry point with an internal registry Instance Instance Instance ? Elastic Load Balancer

Slide 58

Slide 58 text

• Bake as much configuration as possible for all environments directly in the Image • Use environment detection and auto-configuration • Pass remaining configuration at startup and expose it as environment variables Key Value JDBC_URL jdbc:… ENV prod what about configuration ???

Slide 59

Slide 59 text

what about the database ??? • Keep all persistent state, including the database, out of the instance • Many good hosted solutions available like Amazon RDS or Google Cloud SQL • Use a database migration tool like Flyway to update on application startup

Slide 60

Slide 60 text

what about the logs ??? Ship logs to a central log server where they can be • aggregated • stored and backuped • indexed • searched through a nice web UI Many good hosted solutions • Loggly • Logentries • Papertrail • … => Think about data privacy!

Slide 61

Slide 61 text

what about sessions ??? Keep session in an encrypted and signed cookie • avoids session timeouts • avoids server clustering & session replication • avoids sticky sessions & server affinity

Slide 62

Slide 62 text

what about rolling out new versions ???

Slide 63

Slide 63 text

Load Balancer App v1 App v1 Logs Availability Zone 1 Availability Zone 2

Slide 64

Slide 64 text

Load Balancer App v1 App v1 Logs Availability Zone 1 Availability Zone 2

Slide 65

Slide 65 text

Load Balancer App v2 App v1 App v2 App v1 Logs Availability Zone 1 Availability Zone 2

Slide 66

Slide 66 text

Load Balancer App v2 App v1 App v2 App v1 Logs Availability Zone 1 Availability Zone 2

Slide 67

Slide 67 text

what about containers ???

Slide 68

Slide 68 text

understanding modern CPUs Both Intel and AMD have hardware support for virtualization • isolation • performance

Slide 69

Slide 69 text

Image Hardware Hypervisor Image Hardware OS+Container Runtime On Prem Container On Prem VM Image Hardware Hypervisor Cloud VM Image Hardware Hypervisor OS+Container Runtime Cloud VM + Container Only makes sense if you cannot afford $9.60/month granularity

Slide 70

Slide 70 text

Image Hardware Hypervisor Image Hardware OS+Container Runtime On Prem Container On Prem VM Image Hardware Hypervisor Cloud VM Image Hardware Hypervisor OS+Container Runtime Cloud VM + Container Only makes sense if you cannot afford 1.3 cents /hour granularity

Slide 71

Slide 71 text

summary  Put a good lock on the door (use encryption!)  Use fully baked images (build once!)  Treat servers like cattle (disposable!)

Slide 72

Slide 72 text

boxfuse.com • Fully baked images generated in seconds (not minutes or hours) • Minimal images just 1% of size of regular OS (measured in MB not GB) • Images work on VirtualBox & AWS (completely identical from dev to prod) • Zero downtime updates on AWS (fully automatic blue/green deployments)

Slide 73

Slide 73 text

Thanks ! @axelfontaine boxfuse.com