Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Architecture and Deployment of Microservices fo...

Axel Fontaine
September 10, 2015

Architecture and Deployment of Microservices for the Cloud

The case for running an own datacenter is vanishing rapidly. The cloud seduces with a low barrier of entry and full flexibility. Infrastructure can be spun up almost instantly in a fully automated way through an API. All this with no upfront costs and the ability to decommission it just as fast. But what does this mean for our applications and their architecture? Can we just lift and shift them to the cloud?

Everything comes at a price. To be able to fully leverage the potential of the cloud, new challenges must be mastered: from data privacy and security to cost-based architectures, dynamic provisioning, service discovery and efficient deployment models.

This talk provides architects and developers clear answers and battle-tested solutions for a successful journey to infrastructure heaven.

Axel Fontaine

September 10, 2015
Tweet

More Decks by Axel Fontaine

Other Decks in Technology

Transcript

  1. 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
  2. POLL: what type of infrastructure are you running on? •

    On Premise • Colocation • Root Server • Cloud
  3. + = ON PREM + Challenges • Power, Network, Cooling

    • Physical Security • Physical Space • Procurement, Vendor Management • Capacity Planning • Financing • OS + Patches • App + Updates
  4. Can change as long as it complies with the interface

    contract + = COLO + Undifferentiated Heavy Lifting Our responsibility Their responsibility
  5. = ROOT SERVER + Undifferentiated Heavy Lifting Our responsibility Can

    change as long as it complies with the interface contract
  6. Every day, AWS adds enough server capacity to power the

    whole $7B enterprise Amazon.com was in 2004. Weekends included.
  7. "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
  8.  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
  9. 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)
  10. 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
  11. 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
  12. 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
  13. 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!
  14. POLL: which level of automation are you at? • Build

    • Unit Tests • Continuous Integration • Acceptance Tests • Continuous Deployment (Code) • Continuous Deployment (Code + DB + Configuration) • Infrastructure
  15. • One immutable unit • Regenerated after every change •

    Promoted from Environment to Environment Classic Mistake: Build per Environment
  16. Fully Baked Provisioned on Startup Most people  Every Instance

    100% identical  Fastest startup  Launch always succeeds
  17. Fully Baked Provisioned on Startup Most people  One immutable

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

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

    Promoted from environment to environment
  20. Fully Baked  One immutable unit  Regenerated after every

    change  Promoted from environment to environment Image
  21. types of services sync => load async => queue depth

    cron => time => but also instance health!
  22. high uptime is a liability The longer an instance is

    up, the harder it becomes to recreate exactly (and it will fail eventually!)
  23. How to solve service discovery ? Use a stable entry

    point with an internal registry Instance Instance Instance ? Elastic Load Balancer
  24. • 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 ???
  25. 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
  26. 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!
  27. what about sessions ??? Keep session in an encrypted and

    signed cookie • avoids session timeouts • avoids server clustering & session replication • avoids sticky sessions & server affinity
  28. Load Balancer App v2 App v1 App v2 App v1

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

    Logs Availability Zone 1 Availability Zone 2
  30. understanding modern CPUs Both Intel and AMD have hardware support

    for virtualization • isolation • performance
  31. 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
  32. 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
  33. summary  Put a good lock on the door (use

    encryption!)  Use fully baked images (build once!)  Treat servers like cattle (disposable!)
  34. 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)