應用開發新思維

1. © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved. Time to Application-First New features for developers, serverless and containers Kim, Kao Solutions Architect Amazon Web Services

2. Agenda Containers on AWS Infrastructure First Application First with ECS Capacity Providers EKS on Fargate More new features update

3. AWS container services orchestration and compute Deployment, scheduling, scaling, and management of containerized applications Where the containers run Amazon Elastic Container Service (Amazon ECS) Amazon Elastic Kubernetes Service (Amazon EKS) Amazon Elastic Compute Cloud (Amazon EC2) AWS Fargate Orchestration Compute Engine *Now available with ECS and EKS

4. 150%+ growth in container services usage year-over-year 80%+ of all containers on the cloud run on AWS* *Nucleus research: https://nucleusresearch.com/research/single/guidebook-containers-and-kubernetes-on-aws/

5. 5X Number of containers launched per hour by Amazon ECS compared to VMs launched by Amazon EC2

6. Amazon ECS powers Amazon

8. Amazon ECS terminology ECS cluster ECS task ECS service

9. ECS Cluster ECS Cluster with Amazon EC2 Auto Scaling groups EC2 Auto Scaling Group EC2 Instances ECS Tasks

10. Task Placement: How RunTask Happens

11. Placement Constraints

12. Placement Strategies Availability Zone 1 Availability Zone 2 Availability Zone 1 Availability Zone 2

13. Scaling the Cluster EC2 Auto Scaling Group EC2 Instances ECS Tasks ECS Cluster

15. Application First Tenets for Application First: • Applications own their requirements. • Infrastructure responds to application requirements.

16. Amazon ECS Capacity Providers: The Missing Link ECS Cluster ECS Capacity Provider EC2 Instances EC2 Auto Scaling Group

17. Amazon ECS Capacity Providers: The Missing Link ECS Cluster ECS Capacity Provider EC2 Instances ECS Tasks EC2 Auto Scaling Group

18. Amazon ECS Capacity Providers: AWS Fargate ECS Cluster ECS Capacity Provider ECS Tasks

19. Running Tasks with Capacity Provider Strategies ECS Cluster ECS Capacity Provider: CP1 ECS Capacity Provider: CP2

20. Splitting Across Capacity Providers: OD and Spot Loadmetric Time 3 3 3 3 3 4 8 8 8 #Replicas 6 6 6 6 6 8 16 16 16 Overprovision by 50%: Reduce metric target value by 1/3 Run 2/3 On-Demand, 1/3 on Spot. +50% capacity for +5-10% cost

21. AZ Balance With Capacity Providers ECS Cluster ECS Capacity Provider: CP3 EC2 Auto Scaling Group (AZ1) ECS Capacity Provider: CP2 ECS Capacity Provider: CP1 EC2 Auto Scaling Group (AZ2) EC2 Auto Scaling Group (AZ3)

23. The EC2 flow at 33,000 feet Amazon EC2 Customer AccountAWS VPC PodService You have to manage this capacity (e.g., with ASGs) Run a container on EC2 for me, please EC2 Control Plane ENI

24. The Fargate flow at 33,000 feet Customer AccountAWS Control Plane VPC AWS Fargate Run a container on FARGATE for me, please You don’t have to manage capacity FARGATE PodService ENI

25. Fargate Managed nodes Unmanaged nodes Units of work Pod Pod and EC2 Pod and EC2 Unit of charge Pod EC2 EC2 Fargate Vs. (Un)Managed Nodes

26. Fargate Managed nodes Unmanaged nodes Units of work Pod Pod and EC2 Pod and EC2 Unit of charge Pod EC2 EC2 Host lifecycle There is no visible host AWS (SSH is allowed) Customer Host AMI There is no visible host AWS vetted AMIs Customer BYO Fargate Vs. (Un)Managed Nodes

27. Fargate Managed nodes Unmanaged nodes Units of work Pod Pod and EC2 Pod and EC2 Unit of charge Pod EC2 EC2 Host lifecycle There is no visible host AWS (SSH is allowed) Customer Host AMI There is no visible host AWS vetted AMIs Customer BYO Host : Pods 1 : 1 1 : many 1 : many Fargate vs. (Un)Managed Nodes

28. EKS data plane options Worker nodes only Amazon EKS Availability Zone 1 Auto Scaling group Availability Zone 2 Auto Scaling group Worker node Worker node Worker node Worker node Amazon EC2 Auto Scaling Traditional container data plane Pods

29. EKS data plane options Mixed mode Serverless container data plane NEW AWS Fargate Amazon EKS Availability Zone 1 Auto Scaling group Availability Zone 2 Auto Scaling group Worker node Worker node Worker node Worker node Amazon EC2 Auto Scaling Traditional container data plane PodsPods

30. EKS data plane options Fargate only Serverless container data plane NEW AWS Fargate Amazon EKS Pods

31. Kubernetes and EKS: Objects and constructs KubernetesAmazon EKS Amazon EKS

32. Kubernetes and EKS: Objects and constructs KubernetesAmazon EKS aws eks create-cluster aws eks update-cluster-version … kubectl apply kubectl autoscale Kubectl expose …aws eks create-fargate-profile NEW

33. Fargate profile template Subnets to pick for the Pod deployment Parameters to “catch” the pod deployment IAM Role to be associated to the kubelet

34. { "name": profile-a, "clusterName": mycluster, "podExecutionRole": iam-role-xyz, "subnets": subnet-0ad888345, "selectors": [ { "namespace": prod, "labels": { stack: blue } } ] } Fargate profile Simplified deployment flow Availability Zone 1 Auto Scaling group Availability Zone 2 Auto Scaling group Worker node Worker node Worker node Worker node Amazon EC2 Auto Scaling AWS Fargate KubernetesAmazon EKS Fargate Scheduler Pod 4 Mutating/ Validating Webhooks namespace: prod labels: - stack: blue - profile = profile-a - schedulerName = fargate- scheduler Pod 3 2 namespace: prod labels: - stack: blue 1 Pod

35. { "name": profile-a, "clusterName": mycluster, "podExecutionRole": iam-role-xyz, "subnets": subnet-0ad888345, "selectors": [ { "namespace": prod, "labels": { stack: blue } } ] } Fargate profile Simplified deployment flow Availability Zone 1 Auto Scaling group Availability Zone 2 Auto Scaling group Worker node Worker node Worker node Worker node Amazon EC2 Auto Scaling AWS Fargate KubernetesAmazon EKS Fargate Scheduler Pod 4 Mutating/ Validating Webhooks namespace: test 1 Pod 2 3

36. Need a custom pod spec to deploy to Fargate? No You can configure EKS to deploy to Fargate… without touching your pod spec See the pod restart on Fargate Kill the podCreate a Fargate profile that matches the pod namespace (and optionally, labels) Example Run a pod on standard worker nodes

37. Example: Deploy to workers Availability Zone 1 Auto Scaling group Availability Zone 2 Auto Scaling group Worker node Worker node Worker node Worker node Amazon EC2 Auto Scaling AWS Fargate KubernetesAmazon EKS Fargate Scheduler Pod 4 Mutating/ Validating Webhooks 2 3 1 Pod namespace: default 1 Pod

38. { "name": profile-a, "clusterName": mycluster, "podExecutionRole": iam-role-xyz, "subnets": subnet-0ad888345, "selectors": [ { "namespace": default } } ] } Fargate profile Example: Re-deploy to Fargate Availability Zone 1 Auto Scaling group Availability Zone 2 Auto Scaling group Worker node Worker node Worker node Worker node Amazon EC2 Auto Scaling AWS Fargate KubernetesAmazon EKS Fargate Scheduler Pod 4 Mutating/ Validating Webhooks namespace: default labels: - profile = profile-a - shchedulerName = fargate- schedulerPod 3 2 namespace: default 1 Pod Same pod spec

39. Load Balancers considerations ALB Ingress works as it normally does Latest version includes the required code changes to make it work NLB support is coming soon Stay tuned CLB will not work because it must target EC2 instances There are no EC2 instances with EKS/Fargate

40. Storage options with EKS for Fargate Fargate provides a local storage space for containers to share This space is ephemeral and only lives for the time the pod lives Persistent storage for Fargate is a frequent ask from customers We are investigating the possibilities

41. EKSCTL support EKSCTL supports Fargate and EC2 worker nodes Make sure you use the latest version It is possible to create a Fargate-only cluster Or a combination of Fargate and managed node groups EKSCTL takes care of some undifferentiated heavy lifting Such as creating the Fargate profiles and more > eksctl create cluster --fargate

42. Things you can’t do (for now) Deploy Daemonsets Use service type LoadBalancer (CLB/NLB) Running privileged containers Run stateful workloads Recap: EKS for Fargate introduces UX changes Things you no longer need to do Manage Kubernetes worker nodes Pay for unused capacity Use K8s Cluster Autoscaler (CA) Things you get out of the box VM isolation at pod level Pod level billing Easy chargeback in multi-tenant scenarios

44. Event-driven benefits

45. Event-driven models

47. Why do you need a router?

50. Amazon EventBridge Native integrations with SaaS providers 17 target services Easily build event-driven architectures Fully managed, pay-as-you-go Amazon EventBridge

51. Event Source TargetsAmazon EventBridge event bus Rule 1 Rule 2 Rule 3 Amazon EventBridge overview

53. Types of event buses Default Custom Partner

54. Event bus domain alignment

55. Event bus provisioning shared services consumer a AWS Step Functions workflow Amazon DynamoDB Amazon Simple Email Service consumer b Amazon EventBridge shared event bus Amazon CloudWatch alarms Amazon CloudWatch Logs Amazon Kinesis Data Firehose

57. Strangling legacy applications with events Event-driven servicesInbound events Outbound events Credit: Forrest Brazeal - https://aws.amazon.com/blogs/aws/building-serverless-pipelines-with-amazon-cloudwatch-events/ event generator Amazon EventBridge

59. How do you manage event types?

60. Schema Registry and Discovery Explicitly published and auto-discovered Integrations for VS Code and JetBrains Language bindings for Java, Python, or TypeScript Source of truth for sharing schema Amazon EventBridge

62. AWS Step Functions Express Workflows Introducing: Orchestrate AWS compute, database, and messaging services at rates up to 100,000 events per second, suitable for high-volume event processing workloads such as IoT data ingestion, microservices orchestration, and streaming data processing and transformation Faster: greater than 100K state transitions per second

63. Standard vs. Express Workflows Standard Express Executions Executions are persisted and have ARNs Executions are not persisted except as log data Execution history Stored in Step Functions, with tooling for visual debugging in the console Sent to Amazon CloudWatch Logs Service integrations Supports all service integrations and activities Supports all service integrations. Does not support activities. Patterns Supports all patterns Does not support Job-run (.sync) or Callback (.wait For Callback)

64. Preview: HTTP APIs for Amazon API Gateway Achieve up to 70% cost reduction and 50% latency reduction compared to REST APIs. HTTP APIs are also easier to configure than REST APIs, allowing you to focus more time on building applications. Amazon Confidential Reduce application costs by up to 70% Reduce application latency by up to 50% Configure HTTP APIs easier and faster than before

65. Provisioned Concurrency for AWS Lambda INTRODUCING Provisioned Concurrency keeps functions initialized and hyper-ready to respond in double-digit milliseconds. Customers fully control when or how long to enable Provisioned Concurrency. Taking advantage of Provisioned Concurrency requires no changes to your code.. Amazon Confidential Serverless LEARN MORE CON213-L: Leadership session: Using containers and serverless to accelerate modern application development. Wednesday, 9:15am Ideal for latency-sensitive applications

66. The Amazon Builders’ Library Architecture, software delivery, and operations By Amazon’s senior technical executives and engineers Real-world practices with detailed explanations Content available for free on the website

67. The Amazon Builders’ Library

應用開發新思維

Du liest eine Vorschau.

Hier ansehen

應用開發新思維

Weitere Verwandte Inhalte

Diashows für Sie (20)

Ähnlich wie 應用開發新思維 (20)

Weitere von Amazon Web Services (20)