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

Architecture and Deployment of Microservices for the Cloud

2d505d3fd867e284a384986533c2e5f8?s=47 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.

2d505d3fd867e284a384986533c2e5f8?s=128

Axel Fontaine

September 10, 2015
Tweet

More Decks by Axel Fontaine

Other Decks in Technology

Transcript

  1. Up in the sky Architecture and Deployment of Microservices for

    the Cloud AXEL FONTAINE @axelfontaine axel@boxfuse.com
  2. 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
  3. flywaydb.org

  4. boxfuse.com

  5. about questions

  6. POLL: what type of infrastructure are you running on? •

    On Premise • Colocation • Root Server • Cloud
  7. How did this evolve ?

  8. + = ON PREM + Challenges • Power, Network, Cooling

    • Physical Security • Physical Space • Procurement, Vendor Management • Capacity Planning • Financing • OS + Patches • App + Updates
  9. + = ON PREM + Our responsibility

  10. + + Our responsibility Their responsibility = COLO

  11. + = COLO + Simple, stable, standards-compliant interface: (19” Rack,

    AC Power, Ethernet, …)
  12. Can change as long as it complies with the interface

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

    change as long as it complies with the interface contract
  14. = ROOT SERVER + Undifferentiated Heavy Lifting Simple, stable, standards-

    compliant interface Software <-> Hardware
  15. Room For Innovation + Undifferentiated Heavy Lifting Simple, stable, standards-

    compliant interface
  16. what about the cloud ??

  17. Every day, AWS adds enough server capacity to power the

    whole $7B enterprise Amazon.com was in 2004. Weekends included.
  18. "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
  19. Control Plane Data Plane

  20.  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
  21. moving to the cloud

  22. lift & shift (= the naïve approach)

  23. 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)
  24. understanding the cloud

  25. regions

  26. availability zones <<IMAGE GERMANY + two small clouds with racks>>

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

  28. building blocks Security Storage Network Compute

  29. None
  30. 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
  31. the 3 states of data Data at Rest Data in

    Motion Data in Use
  32. 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
  33. Data in Motion TLS / SSL

  34. Data in Use & at Rest Client-side encryption

  35. 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
  36. Key Management In App € KMS €€ HSM €€€€€

  37. 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!
  38. the compute building block

  39. POLL: which level of automation are you at? • Build

    • Unit Tests • Continuous Integration • Acceptance Tests • Continuous Deployment (Code) • Continuous Deployment (Code + DB + Configuration) • Infrastructure
  40. Build Test

  41. Build Test

  42. • One immutable unit • Regenerated after every change •

    Promoted from Environment to Environment Classic Mistake: Build per Environment
  43. Image Instance Fully Baked Provisioned on Startup ?

  44. Fully Baked Provisioned on Startup Most people  Every Instance

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

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

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

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

    change  Promoted from environment to environment Image
  49. instances General Purpose CPU RAM Disk

  50. scaling & costs vs auto-scale based on various factors =>

    prefer smaller granularity
  51. types of services sync => load async => queue depth

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

    up, the harder it becomes to recreate exactly (and it will fail eventually!)
  53. Focus shift Individual instances become disposable Instance Service

  54. keep your instances stateless

  55. Treat servers like cattle instead of pets

  56. What are the implications ???

  57. How to solve service discovery ? Use a stable entry

    point with an internal registry Instance Instance Instance ? Elastic Load Balancer
  58. • 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 ???
  59. 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
  60. 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!
  61. what about sessions ??? Keep session in an encrypted and

    signed cookie • avoids session timeouts • avoids server clustering & session replication • avoids sticky sessions & server affinity
  62. what about rolling out new versions ???

  63. Load Balancer App v1 App v1 Logs Availability Zone 1

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

    Availability Zone 2
  65. Load Balancer App v2 App v1 App v2 App v1

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

    Logs Availability Zone 1 Availability Zone 2
  67. what about containers ???

  68. understanding modern CPUs Both Intel and AMD have hardware support

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

    encryption!)  Use fully baked images (build once!)  Treat servers like cattle (disposable!)
  72. 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)
  73. Thanks ! @axelfontaine boxfuse.com