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.

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