BARCELONA. 2015, Amazon Web Services, Inc. or its affiliates. All rights reserved

Transcription

1 BARCELONA 2015, Amazon Web Services, Inc. or its affiliates. All rights reserved

2 From Monolithic to Microservices Evolving Architecture Patterns in the Cloud Daniele Stroppa, AWS Solutions Architect Teo Ruiz, VP Jobandtalent 2015, Amazon Web Services, Inc. or its affiliates. All rights reserved

3

4 Common Challenges and Patterns

5 Monolithic Simple deployments Binary failure modes Inter-module refactoring Technology monoculture Vertical scaling Microservices Partial deployments Graceful degradation Strong module boundaries Technology diversity Horizontal scaling

6 Common Challenges and Patterns Organization Discovery Data management Deployment I/O explosion Monitoring

7 Organization

8 Monolithic Ownership Organized on technology capabilities Web Tier UI Team App Tier App Logic Team DBA Team Organizational Structure DB Application Architecture

9 Microservices Ownership Organized on business responsibilities Login Registration Order Personalization Mobile Accounts team Personalization team Mobile team

10 Microservices Ownership Requirements Technology selection Development Quality Deployment Support

11 How to Be a Good Citizen (Service Consumer) Design for failure Expect to be throttled Retry w/ exponential backoff Degrade gracefully Cache when appropriate

12 How to Be a Good Citizen (Service Provider) Publish your metrics Protect yourself Keep your implementation details private Maintain backwards compatibility

13 Amazon API Gateway Throttling (global and per-method) Caching (with TTLs and invalidation) Monitoring (RPS, latency, error rate) Versioning Authentication

14 Discovery

15 Use DNS Convention-based naming <service-name>-<environment>.domain.com shoppingcart-gamma.example.com <service-name>.<environment>.domain.com shoppingcart.gamma.example.com

16 Use a Dynamic Service Registry Avoids the DNS TTL issue More than service registry & discovery Configuration management Health checks Plenty of options ZooKeeper (Apache) Eureka (Netflix) Consul (HashiCorp) SmartStack (Airbnb)

17 Data management

18 Challenge: Centralized Database Monolithic applications typically have a monolithic data store: Difficult to make schema changes Technology lock-in Vertical scaling Single point of failure user-svc cart-svc DB account-svc

19 Centralized Database Anti-pattern Monolithic applications typically have a monolithic data store: Difficult to make schema changes Technology lock-in Vertical scaling Single point of failure user-svc cart-svc DB account-svc

20 Decentralized Data Stores Each service chooses its data store technologies Low impact schema changes cartsvc usersvc accountsvc Independent scalability Data is gated through the service API ElastiCache RDS DynamoDB RDS

21 Challenge: Transactional Integrity Use a pessimistic model Handle it in the client Add a transaction manager / distributed locking service Rethink your design Use an optimistic model Accept eventual consistency Retry (if idempotent) Fix it later Write it off

22 Challenge: Aggregation Pull: Make the data available via your service API Push: To Amazon S3, Amazon CloudWatch, or another service you create Pub/sub: Via Amazon Kinesis or Amazon SQS

23 Deployment

24 Continuous Delivery & Continuous Deployment user-svc Build & unit tests Integration & perf tests beta Prod cart-svc Build & unit tests Integration & perf tests beta gamma Prod Create the right build pipeline for each service AWS CodeDeploy AWS Elastic Beanstalk Jenkins, CircleCI, Travis,

25 AWS CodePipeline

26 Multiple Services per Container/Instance Independent monitoring Independent scaling Clear ownership Immutable deployments user-svc cart-svc account-svc Container or instance

27 Multiple Services per Container/Instance Anti-pattern Independent monitoring Independent scaling Clear ownership Immutable deployments user-svc cart-svc account-svc Container or instance

28 Single Service per Container/Instance Independent monitoring Independent scaling Clear ownership Immutable deployments user-svc container or instance cart-svc container or instance account-svc container or instance

29 Or Just Use AWS Lambda RDS API Gateway Lambda DynamoDB

30 I/O explosion

31 Challenge: Request Multiplication cart-svc Single request checkoutsvc account-svc user-svc

32 Add Client Caching cart-svc Single request checkoutsvc account-svc cache user & account cache user-svc

33 Challenge: Hotspots single request cart-svc shippingsvc order-svc get (user x, col y) get (user x, col y) get (user x, col y) user-svc

34 Use Dependency Injection single request cart-svc (user x, col y) shippingsvc (user x, col y) get (user x, col y) order-svc user-svc

35 Monitoring

36 Challenge: monitoring Publish externally relevant metrics Latency RPS Error rate Understand internally relevant metrics Basic CloudWatch OS Application

37 Challenge: Logging Pick a common log aggregation solution Agree on log entry formats Use naming conventions Agree on correlation strategy

38 Challenge: Correlating Requests request ui-svc catalogsvc checkoutsvc paymentsvc shippingsvc

39 Use Correlation IDs request ui-svc correlation id: uuid-123 correlation id: uuid-123 shippingsvc paymentsvc catalogsvc checkoutsvc :03:24 ui-svc INFO [uuid-123] :03:25 catalog-svc INFO [uuid-123] :03:26 checkout-svc ERROR [uuid-123] :03:27 payment-svc INFO [uuid-123] :03:27 shipping-svc INFO [uuid-123]

40 What did we cover? Ownership Discovery Data management Deployment I/O explosion Monitoring

41 BARCELONA