Randall Hunt - AWS Midwest Community Day Keynote
•Download as PPTX, PDF•
0 likes•64 views
Randall Hunt presented at the AWS Midwest Community Day. He is a software engineer and developer advocate at Amazon Web Services. The presentation covered AWS updates, creating and leading communities, and the AWS Cloud Development Kit (CDK). The CDK is a software development framework that allows modeling cloud infrastructure as reusable components using familiar programming languages. It leverages CloudFormation under the hood to deploy cloud resources in a safe and declarative way. Randall discussed the AWS Construct Library and stages of maturity for different constructs, and provided an overview of contributing to and extending the CDK open source project.
Recommended
More Related Content
What's hot
What's hot (19)
Similar to Randall Hunt - AWS Midwest Community Day Keynote
Similar to Randall Hunt - AWS Midwest Community Day Keynote (20)
More from AWS Chicago
More from AWS Chicago (20)
Recently uploaded
Recently uploaded (20)
Randall Hunt - AWS Midwest Community Day Keynote
- 1. Randall Hunt – Some Guy From Los Angeles @jrhunt randhunt@amazon.com AWS Midwest Community Day
- 2. Randall Hunt Software Engineer and Developer Advocate Amazon Web Services @jrhunt 🖥 ❤️ 15+ years writing all sorts of software Video Games -> NASA -> MongoDB -> SpaceX -> AWS 💼 Python, C++, ML/AI, CI/CD, Serverless, Databases Skiing, Space, Making fun of javascript.
- 3. Slide thanks! Chris Fife Richard Boyd - @rchrdbyd Ricardo Sueiras - @094459
- 4. Agenda • AWS Updates (Sales pitch time! I’ll keep it short) • Creating and leading communities • CDK
- 5. © 2020, Amazon Web Services, Inc. or its affiliates. All rights reserved. Global Availability 23 Regions 73 Availability Zones Global Edge Network 216+ Points of Presence 100+ Direct Connect Locations Global computeplatformforcomputeeverywhere
- 6. © 2020, Amazon Web Services, Inc. or its affiliates. All rights reserved.
- 7. © 2020, Amazon Web Services, Inc. or its affiliates. All rights reserved.
- 8. Randall’s Completely Biased Updates • Builders Library • 2020-06-10 – AWS CodeArtifact (Maven, Gradle, npm, yarn, pip, twine, etc.) • 2020-06-03 – Cross-cluster Amazon Elasticsearch query • 2020-05-28 – CodePipeline Step Functions action • 2020-05-27 – Amplify GA for iOS and Android (+ML tools) • 2020-05-27 – SAM support for step functions • 2020-05-18 – DDB EMPTY VALUES!!!!! • 2020-05-13 – CDK for Kubernetes • 2020-05-13 – Macie 80% price reduction • 2020-04-28 – AL2 live kernel patching • 2020-04-23 – CloudWatch Synthetics • 2020-04-23 – Pinpoint Custom Channels • 2020-04-21 – TorchServe • 2020-04-08 – Fargate 1.4 (20GB volume, EFS, etc.) • 2020-03-10 – Bottlerocket • 2020-03-02 – Python3.8 for Lambda@Edge • 2020-02-26 – Faster EBS on Nitro instances!
- 9. Community?
- 11. Community!
- 12. CDK Overview
- 13. Infrastructure as Code Infrastructure is code!
- 14. AWS Cloud Development Kit (CDK) A multi-language software development framework for modeling cloud infrastructure as reusable components AWS CloudFormation
- 17. Stack(s) AWS CDK Construct Programming Model CDK Application Stack(s) ConstructConstruct aws/aws-cdk awslabs/cdk8s TerraStackIO/terrastack
- 18. IaC Reuse Paradigm Shift Parameterized Template Stack 2 Stack 1 Stack 3 Stack B Stack ATemplate A Template B CDK App </> CloudFormation: Parameters and Intrinsic Functions CDK: Leverage full power of OO programming languages (parameters, loops, conditions, inheritance, etc.)
- 19. AWS Construct Library What’s up with all the “Experimental” modules?
- 20. AWS Construct Library Serverless Containers CI/CD Application Integration / Foundational Services
- 21. Anatomy of an AWS Construct Library module @aws-cdk/aws-lambda High-level Low-level cfnAlias cfnFunction cfnLayerVersion cfnLayerVersionPermission cfnVersion Alias EventSourceMapping Function LayerVersion LogRetention Version Opinionated @aws-cdk/aws-ecs-patterns LoadBalancedEc2Service LoadBalancedFargateService QueueProcessingEc2Service QueueProcessingFargateServic e ScheduledEc2Task
- 22. Using L1 and L2 Constructs const bucket = new s3.Bucket(stack,'MyBucket',{ encryption: s3.BucketEncryption.Kms }); new kms.CfnKey(stack, ’MyBucketKey’, { keyPolicy: { ”Statement": [ { ”Action": [ "kms:Create*", "kms:Describe*", "kms:Enable*", "kms:List*", "kms:Put*", "kms:Update*","kms:Revoke*", "kms:Disable*", "kms:Get*", "kms:Delete*", "kms:Sche duleKeyDeletion","kms:CancelKeyDeletion" ], ”Effect": "Allow", ”Principal": { "aws": { "Fn::Join": [ "", [ "arn:", { "Ref": "AWS::Partition" }, ":iam::", { "Ref": "AWS::AccountId" }, ":root"] ] } }, ”Resource": "*" } ], ”Version": "2012-10-17" } }); new s3.CfnBucket(stack, ’MyCFNBucket', { bucketEncryption: { "serverSideEncryptionConfiguration": [ { "serverSideEncryptionByDefault": { "kmsMasterKeyId": Fn.getAtt('MyBucketKey', 'Arn').toString(), "sseAlgorithm": "aws:kms" } } ] }, });
- 23. Using L3 Constructs // Example of an ECS-patterns construct new patterns.ApplicationLoadBalancedFargateService(stack, 'MyFargateService',{ taskImageOptions: { image: ecs.ContainerImage.fromRegistry("amazon/amazon-ecs-sample") } }); AWS VPC Elastic Load Balancer • IAM Roles • IAM Policies • Log Group • Configuration “amazon-ecs-sample” image • Subnets • EIP • NAT Gateways • Internet Gateway • Route • Route Table • Security Group • Security Group Egress • Security Group Ingress • Task Definition • Listener • Target Group Fargate Service ECS Task Definition • image • CPU • memory • port 817 line CloudFormation template
- 24. CFN only Experimental Dev Preview Stable Stages of a CDK Construct Library module @aws-cdk/aws-lambda High-level Low-level cfnAlias cfnFunction cfnLayerVersion cfnLayerVersionPermission cfnVersion
- 25. CFN only Experimental Dev Preview Stable Stages of a CDK Construct Library module @aws-cdk/aws-lambda High-level Low-level cfnAlias cfnFunction cfnLayerVersion cfnLayerVersionPermission cfnVersion EventSourceMapping Function LayerVersion
- 26. CFN only Experimental Dev Preview Stable Stages of a CDK Construct Library module @aws-cdk/aws-lambda High-level Low-level cfnAlias cfnFunction cfnLayerVersion cfnLayerVersionPermission cfnVersion Alias EventSourceMapping Function LayerVersion LogRetention Version
- 27. CFN only Experimental Dev Preview Stable Stages of a CDK Construct Library module @aws-cdk/aws-lambda High-level Low-level cfnAlias cfnFunction cfnLayerVersion cfnLayerVersionPermission cfnVersion Alias EventSourceMapping Function LayerVersion LogRetention Version
- 30. AWS CDK Roadmap When will CDK support product foo and feature bar?
- 33. AWS CDK RFCs: feature design in the open
- 34. CDK Example
- 35. Contributing to the AWS CDK
- 36. Summary • CDK provides high-level abstractions making it easier for more developers to define IaC in familiar programming languages • CDK tools leverage the power of CloudFormation (and other provisioning engines) for safe deployment of cloud resources • Customers are building an open source community to help author the abstractions customers need
Editor's Notes
- The global network of AWS Edge locations now consists of 216 Points of Presence (205 Edge Locations and 11 Regional Edge Caches) in 84 cities across 42 countries.
- The AWS Cloud spans 19 geographic regions and we have announced 5 additional regions in Italy, Sweden, Bahrain, Hong Kong, and South Africa. But when you see a map like this, it is easy to underestimate what a region is. Each of these locations is not simply a data center. Not even close. Each of these regions is made up of multiple datacenters that geographically separated into what we call Availability Zones. Each Availability Zone is a datacenter, or in most cases many datacenters, and is engineered to provide full independence from other Availability Zones in the region. We will look at that more deeply in a minute. All Regions have 2 or more Availability Zones. All new regions all have 3 Availability Zones And some Regions have as many as 6 Availability Zones. We have 57 Availability Zones in all. By having multiple fully independent Availability Zones in every Region, customers can easily write their applications using common replication techniques that would otherwise NOT work across greater distances. Each Availability Zone is a big partition of our Infrastructure. All Availability Zones start as a single datacenter, but most Availability Zones grow to multiple datacenters over time. Our largest Availability Zones is 14 datacenters. And some individual datacenters contain over 300,000 servers. Availability Zones are big. Availability Zones are separated from other Availability Zones by meaningful distance. Not across the street…but meaningfully separated. The exact distance depends on the specific geographic attributes of the region….but we mean at least a mile and in most cases many miles. This distance protects each Availability Zone from things like fires, floods, and other natural disasters that might impact other Availability Zones in the Region. Each Availability Zone has fully independent power infrastructure. Not just separate power line-ups and generators….but fully isolated power infrastructure. Each Availability Zone is also connected to other Availability Zones, to other AWS Regions, and to rest of the world through a highly scaled, highly redundant network. One of the important things we do to make the networking between Availability Zones highly available is deploy a lot of network capacity. Excess capacity is the network engineers best friend and our Regional model allows us to cost effectively connect our Availability Zones with a massive amount of connectivity. In one of our largest regions alone, we have 388 unique fiber paths connecting our Availability Zones to one another and to the multiple transit centers that connect these Availability Zones to the rest of the world. In aggregate, this fiber provides over 4,947 Terabits of capacity just within this one region.
- To add this much capacity, you need to be hyper focused on cost. One way to reduce costs is to get more fibers in the same conduit. You can always dig a new trench, but this is usually way more expensive than you would think. You can also use Dense Wavelength Division Multiplexing (or DWDM) to put more data on a single fiber. But this too is more expensive. Left: It packs 3,456 fibers into a cable which fits through a standard 2” conduit. Right: 6,912 fiber pairs into that same conduit. It’s Innovations like these, at every level of our infrastructure, that help us to continue to add more scale at even lower cost.
- With CFN you use parameters and macros to provide external values at deployment time and get specialized stacks we are working on CFN parameters to support customers that have tooling that relies on parameterized templates With CDK you use parameters, loops, conditions, and reference external values in your code to generate get concrete, specific templates
- For CDK GA we have to focus our high-level abstractions on a subset of AWS, and have aligned with the developer tools organization goal to promote serverless, containerized, and CI/CD
- The AWS Construct Library allows you to define AWS infrastructure resources in your CDK apps. The construct library is built in layers: CFN Resource Constructs – these are the lowest level constructs and map directly to CloudFormation resources. They are autogenerated from the CloudFormation resource specification. When a new resource or feature is added to the CFN spec, the CDK will pick it up in the next release which is generally weekly. AWS Constructs – these constructs are hand crafted, higher-level abstractions for each AWS service and take care of a lot of the boilerplate configuration for you. They generally contain sensible default values to get you started quickly. Not all AWS services have high-level abstractions yet, but the CDK team, AWS service teams, and the open source community are adding new ones all the time. Patterns Constructs – Patterns constructs represent opinionated reference architectures and design patterns that include multiple AWS services. This layer is the future of the CDK and the AWS ECS team has built one for their service as an example for others to follow.
- Key points: Encapsulate details and well-architected patterns A module for every AWS service Rich APIs that speak in a developer’s language and not limited to backend calls Constructs can infer a lot of details from intent such as permissions, hooking up events, alarms, etc --- In addition to this powerful programming model, the CDK is shipped with a rich library of higher-level constructs for working with AWS, we call that the AWS Construct Library. We’ll be talking about that AWS Construct Library a lot more later and how it encapsulates much of the detail and many of the AWS well-architected patterns that we’ve learned at AWS over the years. The APIs in the AWS Construct Library are designed to allow you to describe your intents, and automatically infer many of the details, such as IAM permissions, hooking up events, creating dashboards and so on.