Breaking the Monolith - Microservices on AWS

Slide 1

Slide 1 text

Slide 2

Slide 2 text

Slide 3

Slide 3 text

Definition of microservices Microservices are small, isolated services, each of which is independently deployable and owns its data

Slide 4

Slide 4 text

© 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved. Structure apps as collections of microservices When the impact of change is small, release velocity can increase Monolithic application Does everything Shared release pipeline Rigid scaling High impact of change Hard to adopt new technologies Microservices Does one thing Independent deployments Independent scaling Small impact of change Choice of technology

Slide 5

Slide 5 text

Do not break it.

Slide 6

Slide 6 text

© 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved. … so again, consider starting monolithic first and break things out when you’re stable. Many of the challenges you’re going to face with microservices get worse with scale. Sam Newman

Slide 7

Slide 7 text

#7 “…consider starting monolithic first …“

Slide 8

Slide 8 text

Slide 9

Slide 9 text

Slide 10

Slide 10 text

Slide 11

Slide 11 text

Monolith • Commit to deployment takes too long • Codebase too complex for single Developer • Development is slow (IDE, build, startup time) • Lock-in with obsolete tech stack • Scaling is difficult Hell

Slide 12

Slide 12 text

© 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved. https://martinfowler.com/bliki/MicroservicePrerequisites.html Microservices Prerequisites These capabilities imply an important organizational shift - close collaboration between developers and operations: the DevOpsCulture. Rapid provisioning Basic monitoring Rapid application deployment

Slide 13

Slide 13 text

Slide 14

Slide 14 text

Slide 15

Slide 15 text

© 2018, Amazon Web Services, Inc. or its Affiliates. All rights reserved. Options for architecting your microservices AWS Lambda Amazon EKS Amazon ECS AWS Fargate Containers Serverless AWS Services 165+ Services

Slide 16

Slide 16 text

© 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved. Requires <= 3 GB RAM? Yes Orchestration portability OR Kubernetes background? Amazon EKS Yes Manage your own infrastructure? No Amazon ECS AWS Fargate Yes No Deployment Package size <= 50MB Service runtime <= 15 minutes? Yes Yes AWS Lambda No No No Decision Tree – well, almost! @sascha242 AWS Lambda

Slide 17

Slide 17 text

© 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved. Comparison of operational responsibility AWS Lambda Serverless functions AWS Fargate Serverless containers ECS/EKS Container-management as a service EC2 Infrastructure-as-a-Service More opinionated Less opinionated AWS manages Customer manages • Data source integrations • Physical hardware, software, networking, and facilities • Provisioning • Application code • Container orchestration, provisioning • Cluster scaling • Physical hardware, host OS/kernel, networking, and facilities • Application code • Data source integrations • Security config and updates, network config, management tasks • Container orchestration control plane • Physical hardware software, networking, and facilities • Application code • Data source integrations • Work clusters • Security config and updates, network config, firewall, management tasks • Physical hardware software, networking, and facilities • Application code • Data source integrations • Scaling • Security config and updates, network config, management tasks • Provisioning, managing scaling and patching of servers

Slide 18

Slide 18 text

Slide 19

Slide 19 text

© 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved. Lambda Layers • Share code between functions (crosscutting concerns) • Promote separation of responsibilities • Upload layer once, reference up to 5 layers within any function (one can be custom runtime) • Built in support for secure sharing by ecosystem

Slide 20

Slide 20 text

Slide 21

Slide 21 text

Slide 22

Slide 22 text

© 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved. S U M M I T Amazon ECS Easiest way to deploy and manage containers at scale Integration with entire AWS platform ALB, Auto Scaling, Batch, Elastic Beanstalk, CloudFormation, CloudTrail, CloudWatch Events, CloudWatch Logs, CloudWatch Metrics, ECR, EC2 Spot, IAM, NLB, Parameter Store, and VPC Scales to support clusters of any size Service integrations (like ALB and NLB) are at container level 1 2 3

Slide 23

Slide 23 text

© 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved. S U M M I T ECS EC2 vs. ECS Fargate EC2 Fargate Managed by Customer AWS Storage Ephemeral or Persistent Only Ephemeral Sidecar pattern Yes Yes Network Mode Bridge or VPC Mode VPC Mode Daemons Yes No SSH into host Yes No Privileged Containers Yes No

Slide 24

Slide 24 text

Slide 25

Slide 25 text

© 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved. S U M M I T AWS CDK Contribute Code AWS Cloud Development Kit Define cloud infrastructure and reusable components in “real code“ and provision through AWS CloudFormation Stack(s) CDK Application Construct Construct CloudFormation template Resources

Slide 26

Slide 26 text

© 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved. S U M M I T ECS Pattern: Load Balanced Fargate Service Basic constructs: Cluster, Task Definition, Task, Service, etc. Common architecture patterns: load balanced service …this TypeScript generates 568 CloudFormation LOC

Slide 27

Slide 27 text

Slide 28

Slide 28 text

Slide 29

Slide 29 text

© 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved. S U M M I T Availability Zone 1 Availability Zone 2 Availability Zone 3 Kubectl Amazon EKS Architecture CloudWatch Container Insights for Amazon EKS and ECS

Slide 30

Slide 30 text

https://eksctl.io/ Tip: Easy way to create an EKS cluster: $ eksctl create cluster --name meshtest --appmesh-access

Slide 31

Slide 31 text

Slide 32

Slide 32 text

Slide 33

Slide 33 text

© 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved. Go • Modern language • Docker is implemented in Go • Native concurrency • Low startup time • Small, static binaries • Easy cross compilation

Slide 34

Slide 34 text

© 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved. Java – Open Source Cloud Native Stacks Polyglot, declarative, reactive, microservices frameworks like Micronaut or Quarkus based on Graal VM. • Dead code eliminiation • Aggressive Advance of Time Compliation (AOT) • Native image generation • Docker and Kubernetes YAML file generation • Startup times in milliseconds https://quarkus.io/vision/container-first

Slide 35

Slide 35 text

Slide 36

Slide 36 text

© 2019, Amazon Web Services, Inc. or its Affiliates. All rights reserved. OSSC libraries: code changes required, language specific Service Mesh: decentral, language agnostic, polyglot, light-weight https://www.infoq.com/articles/microservices-post-kubernetes Need for a Service Mesh

Slide 37

Slide 37 text

© 2019, Amazon Web Services, Inc. or its Affiliates. All rights reserved. App Mesh works across compute services Amazon ECS AWS Fargate Amazon EKS Amazon EC2 Kubernetes on EC2 Based on Envoy proxy It‘s free (you only pay for resources used) Helps to migrate from monolith

Slide 38

Slide 38 text

Mesh – [myapp] Virtual Node A Service Discovery Backend Listener Virtual router Domains action: match: / B B’ Service B Service B’ Virtual Node B’ Service Discovery Listener Backends Virtual Node B Service Discovery Listener Backends AWS App Mesh EKS EC2

Slide 39

Slide 39 text

© 2019, Amazon Web Services, Inc. or its Affiliates. All rights reserved. Demo: Install AppMesh # AppMesh Installation with Grafana/Prometheus # and Envoy, AWS X-Ray daemon sidecar # and StatsD Prometheus exporter $ helm install -n aws-appmesh \ --namespace appmesh-system \ https://github.com/PaulMaddox/ \ aws-appmesh-helm/releases/ \ latest/download/aws-appmesh.tgz https://github.com/PaulMaddox/aws-appmesh-helm

Slide 40

Slide 40 text

© 2019, Amazon Web Services, Inc. or its Affiliates. All rights reserved. Install Demo App # create namespace & enable auto-injection $ kubectl create ns appmesh-demo $ kubectl label namespace appmesh-demo appmesh.k8s.aws/sidecarInjectorWebhook=enabled # deploy the demo $ helm install -n aws-appmesh-demo \ --namespace appmesh-demo \ https://github.com/.../aws-appmesh-demo.tgz

Slide 41

Slide 41 text

Slide 42

Slide 42 text

Slide 43

Slide 43 text

Strangler Pattern Part I • Work incrementally • Law of holes: Implement new features as services • Separate presentation tier from backend • Decouple business capabilites into services, not code. -> IKEA effect • Choose services that give greatest benefit: • Accelerate development • Solve performance, scalability or reliability problem

Slide 44

Slide 44 text

Strangler Pattern Part II • Splitting the domain model (class references become PKs) • Refactoring the database (Split Table refactoring, use data replication to avoid larger changes ) • API GW or service mesh and „glue code“ • Dependencies from monolith to strangler is preferred direction (if „buy“ uses „promotion“, then decouple promotion first) • Distributed database TXs become SAGAs • Stop doing this at some point. https://microservices.io≈