AWS User Group 5/12 meetup - ECS

Editor's Notes

• #2: And that’s what we built and customers seem to like it. They’re building all kinds of applications and services using ECS
• #3: Can this be a nice structured word cloud? Like this: https://cdn.cultofmac.com/wp-content/uploads/2017/06/wwdc-ios11.png
• #4: Today, startups to fortune 500 companies run tens of millions of applications worldwide on AWS using Amazon ECS. Amazon ECS has become so popular across a broad range of use cases because it allows you to easily run and manage Docker-enabled applications across a cluster of Amazon EC2 instances, without having to support your own cluster management infrastructure.
• #5: In the last couple of years we have seen great adoption of production use cases on Amazon ECS. Our active users are up by more than 450% since 2016 and we are managing containers across millions of instances each month. In fact, we are witnessing an incredible transition to containers and customers of ECS, whether its Expedia running its travel platform or Mapbox powering mapping data for some of the most popular websites, Amazon ECS enables these customers to be able to run containers at scale. And indeed, we see hundreds of millions of containers launched every week. ^^^Nate not sure about the title of this one, what do you think? Can you get me some more examples for my talk track. We said we were going to reference some examples from talks, right? (WeWork, Realtor)
• #6: For many of our customers they want to know whether they can run PCI, HIPAA, and other applications here. Today, you can build PCI compliant and HIPAA eligible applications using ECS SOC 1,2,3 PCI HIPAA Eligible ISO 9001, 27001, 27017, 27018 MTCS (https://aws.amazon.com/compliance/aws-multitiered-cloud-security-standard-certification/) Future: Fedramp
• #7: To date we haven’t given our customers an SLA that supports our confidence of operating this service for our customers. That’s no longer true. We now have a compute SLA which includes ECS and it’s 99.99%. https://www.istockphoto.com/photo/data-center-interior-gm622896088-109091143
• #8: There’s a T-shirt out there that says 9s don’t matter if your customers aren’t happy. For our customers to be happy availability is only the beginning. We want to make AWS the best place for our customers to run their applications. We want them to be happy. This means that as our customers run more production applications we have to continue to make it easier for them to do so
• #9: But the area we’ve spent a ton of time on based on what we’ve heard from our customers is to make containers a fundamental compute primitive.
• #10: For us it meant doing that for ECS Tasks » Scrolling animation of boxes being checked as we go to 68
• #15: rely on services as if they are functions look up by name in code and it auto-resolves Service Registry with latest state of dynamic infrastructure Scaling - Number of EC2 instances and containers change Scheduling / placement Dynamic ports dependent on placement Health Nothing to install or manage Easy to debug
• #16: Available next week, CodePipeline will support native deployments to ECS, making it easier than ever to build a continuous delivery pipeline for container-based applications on AWS. CodePipeline is a continuous integration and continuous delivery service that automates the build, test, and deployment of your code every time there is a code change. You can see here we’ve enabled it right in the deployment step for creating a pipeline; you can choose Amazon ECS as the deployment provider.
• #17: To help you get started building a CI/CD pipeline for running containers on ECS, several of my peers have built reference architectures that can be found on AWSLabs in Github. This reference architecture builds an automated pipeline using the Github, CodePipeline, CodeBuild, and ECR. When a change is pushed to Github, it triggers a pipeline that fetches the code from Github and passes it to CodeBuild. CodeBuild then builds the container from the instructions in the Dockerfile and and pushes the Docker image in an ECR registry. In the final step, CodePipeline updates the task and service definitions which triggers a deployment of a new task across the cluster.
• #18: Today’s container management systems spend too much time and emphasis on a cluster of machines. https://www.istockphoto.com/photo/data-processing-center-gm531044829-55048050
• #19: They don’t want to worry about the cluster the containers are running on. They don’t want to think about bin packing, which types of hardware apps should run on, and so on. Effectively our customers want an API for containers.
• #20: And that is AWS Fargate. https://www.istockphoto.com/photo/across-the-universe-traveling-in-space-time-travel-scene-of-overcoming-the-temporary-gm664390112-120918507
• #21: Fargate is a new container technology, essentially a data plane designed to do one thing. Run containers.
• #22: Till yesterday you ran tasks on a cluster of EC2 instances that you had to provision (or rely on a lot of automation to manage).
• #23: Well, no longer. When you choose launch type = Fargate in ECS, you get running Tasks. No instances to manage. All operations at the level of a Task. The best way to get a feel for Fargate is to see the technology in action. So let’s do that.
• #24: Our customers love ECS, but we’ve heard from some of our customers that they want other options to run their containers. 2 years ago it was very unclear what that option might be? Today, that’s unambiguous. Picture source: https://goo.gl/images/3Uge11 (Wikimedia Commons)
• #25: And that’s what we built and customers seem to like it. They’re building all kinds of applications and services using ECS
• #26: A number of our customers run Kubernetes, either because they love the community and tools around k8s, and it is a very rich community and a broad set of tools, or because they want a toolchain that is just as portable as the containers running underneath. Most the k8s in the world runs on AWS. We wanted to make sure they had a great experience.
• #27: (should have the CNCF logo here). Earlier this summer joined the CNCF to participate in the broader container ecosystem. We were also super interested in projects like containerd and CNI, but also wanted to get better aligned with the broader ecosystem on how to run k8s more reliably and give customers a better experience
• #28: Our customers told us, “Hey, running Kubernetes isn’t trivial work, and we think we can better spend our cycles focusing on our applications.” “if we had things our way, we wouldn’t have to think about the nuances of kubernetes deployments or configuration, we wouldn’t have to worry about managing etcd or the masters”
• #29: and we want the freedom to choose top notch aws integrations
• #30: But also to continue using the open source tooling we’re using today.
• #31: Announcing the preview for Amazon EKS
• #32: Now, with EKS, the complexity of standing up your own Kubernetes control plane is simplified. Instead of running the Kubernetes control plane in your account, you connect to a managed Kubernetes endpoint in the AWS cloud. This endpoint abstract the complexity of the Kubernetes control plane- your worker nodes can check into a cluster, and you can interact with your Kubernetes cluster through the tooling you already know and love.
• #33: Let’s talk about the tenants that anchor our design decisions for EKS. Tenant 1: EKS is a platform for enterprises to run production-grade workloads. EKS aims to provide features and management capabilities to allow enterprises to run real workloads at real scale. Reliability, visibility, scalability, and ease of management are our priorities. One of the areas where we are putting in a lot of effort is to availability. We don’t believe a single master is an acceptable approach to running production applications. EKS is multi-master by default. We manage your persistence layer
• #34: Tenant 2: EKS provides a native and upstream Kubernetes experience. Any modifications or improvements that we make in our service must be transparent to the  Kubernetes end user. This means that your existing Kubernetes experience and know how applies directly to EKS. Your existing applications and investments in Kubernetes work right out of the box with EKS.
• #35: Tenant 3: EKS customers are not forced to use additional AWS services, but if they want to, the integrations are seamless and eliminate undifferentiated heavy lifting. We are focused on making contributions to projects that allow customers to use the AWS components they currently know and love with their applications in Kubernetes. The other thing our customers care about is integration into the rest of AWS. This is another area where we plan to focus and contribute upstream.
• #36: (Changed slide background, because the figure was not pasting correctly and I didn’t want to recreate it) A great example is Networking. We are implementing a set of CNI plugins that bring native VPC networking to k8s. (NEED MORE DETAIL ON SECONDARY ENIs from Brandon) CNI Plugin networking Networking for Pods must support high throughput and availability, low latency and minimal jitter comparable to the characteristics a customer would get from EC2 networking. Network operation must be simple and secure. Customers must be able to apply exsiting AWS VPC networking and security best practices for building Kubernetes clusters over AWS VPC. For example, customers should be able to: use VPC flow logs for troubleshooting and compliance auditing, apply VPC routing polices for traffic engineering, apply security groups to enforce isolation and meet regulatory requirements. Pod networking should be setup in a matter of seconds. Customer should be able to scale clusters up to 2000 nodes.
• #37: A network policy is a specification of how groups of pods are allowed to communicate with each other and other network endpoints. NetworkPolicy resources use labels to select pods and define rules which specify what traffic is allowed to the selected pods. Optionally extends K8s API with more policy capabilities, and host protection (protecting the K8s infrastructure not just pods, and standalone instances not running K8s)
• #39: https://github.com/heptiolabs/kubernetes-aws-authenticator  The Heptio authenticatior helps us pass an IAM identity with Kubectl calls. We like this approach because it’s something anyone could use with Kubernetes. It’s an open source project and it helps us combine IAM for authn and built in Kubernetes RBAC for authz. Let’s look how.
• #40: Because we’re hosting Kubernetes as a service, we need to provide authentication on the API endpoint with IAM. IAM isn’t currently supported as a built-in authentication mechanism, so let’s dig into how this works. 1) The Authenticator assists here with step 1. When a Kubectl call is made- let’s say I’ve made a get pods call, my IAM identity is passed along with the kubernetes call. We can look in the default credential chain for my IAM ID- aws config file, IAM role, etc. 2) On the backend, Kubernetes verifies the IAM identity with AWS auth. This is purely authentication. 3) The auth response is sent back to Kubernetes, and K8s checks it’s internal RBAC mapping for authz. This determines if my original get pods call was allowed or denied. 4) The K8s API approves or denies the request.
• #41: EKS is available in preview. Go the aws.amazon.com/eks to sign up. We look forward to going GA in 2018
• #43: (Graphic showing EKS with Fargate)First things first. We want to bring the Fargate technology to EKS. Even there you shouldn’t have to worry about hosts. All you should care about is your containers, pods, and services, and build your applications
• #44: Today, we’ve talked about a grand journey. We have talked about lessons from the past. We’ve talked about some amazing ways our customers are using containers. Fargate changes how we think about containers. It simplifies the operational model, and completely changes the business model. You can use Fargate with two orchestration systems. Pick the one that meets your needs and requirements. I can’t wait to see what our customers do and where this journey ends and what new lessons we learn together as we build a new generation of apps. Can’t wait to talk about all of that this time next year.