AWS Open Source Blog

Cloud Native Computing

本地云计算

Last August, Amazon Web Services joined the Cloud Native Computing Foundation, where I am representing AWS as the CNCF board member, with Arun Gupta coordinating technical engagement with projects and working groups. We have since made several contributions to CNCF projects: at re:Invent, Andy Jassy announced Amazon EKS, which makes running Kubernetes as a service on top of AWS much, much easier. And I recently presented a keynote at Cloud Native Con/KubeCon in Austin:

Our initial announcement about joining CNCF was made via my personal blog. Now that we have a dedicated AWS Open Source blog, it’s time for an updated summary of where we are with CNCF, and our plans going forward.

Cloud native architectures take full advantage of on-demand delivery, global deployment, elasticity, and higher-level services. They enable huge improvements in developer productivity, business agility, scalability, availability, utilization, and cost savings.

On-demand delivery, taking minutes instead of weeks, is often the first reason that people move to cloud, but it doesn’t just reduce the deployment time for a traditional application: it also enables a new cloud native pattern of ephemeral and immutable deployments. In the old deployment model, where it takes weeks to get a resource, you’re going to hang on to it, order extra capacity in advance, and be reluctant to give it back, so you’ll figure out how to update it in place. The cloud native pattern, instead, is to bake instances or build containers, deploy many identical copies just as long as they are needed, shut them down when you are done, and create new images each time the code changes. NetflixOSS pioneered these concepts by baking Amazon Machine Images (AMIs). Docker subsequently used it as a core element of the container deployment model adopted by CNCF.

Cloud native architectures are scalable. When I first presented about Netflix’s use of AWS in 2010, we were running front end applications on a few thousand AWS instances, supporting about 16 million customers in the USA. Nowadays, Netflix is fully migrated to AWS, has well over 100 million global customers, and is running on over 100,000 instances. The implementation details have changed over the years, but the architectural patterns are the same.

Over time, components of cloud native architectures move from being experimental, through competing implementations, to being well-defined external services. We’ve seen this evolution with databases, data science pipelines, container schedulers, and monitoring tools. This is one place where the Cloud Native Compute Foundation (CNCF) acts as a filter and aggregator. The Technical Oversight Committee (TOC) of the CNCF reviews projects, incubates them, and adopts projects as they move from the experimental phase to the competing implementation phase. For customers who are trying to track a fast-moving and confusing world, it’s helpful to regard CNCF as a brand endorsement for a loose collection of interesting, sometimes competing projects, rather than a single, integrated cloud native architecture. There’s no particular endorsement of any one project over another for members of CNCF, or for users of projects.

The CNCF currently hosts fourteen projects, and is incubating several more: Kubernetes for container orchestration, Prometheus for monitoring, Open Tracing for application flow monitoring, Fluentd for logging, Linkerd and Envoy for service meshes, gRPC for remote procedure calls, CoreDNS for service discovery, Containerd and rkt for container runtimes, CNI for container native networking, Jaeger for distributed tracing, Notary for secure delivery and TUF for software updates.

From the AWS perspective, we are interested in several CNCF projects and working groups. AWS were founding members of the Containerd project; we are excited about participating in the Containerd community, and have lots of ideas around how we can help our customers have a better experience. The recent release of Containerd 1.0 sets it up for us to (eventually) provide an optimized containerd-based runtime for Amazon EKS and Amazon ECS. Our ECS Task Networking capabilities were written as a CNI plugin, and CNI has become the basis for all container-based networking on AWS.

The most recent CNCF survey reports that 57 percent of respondents host Kubernetes on Amazon EC2, and customers were asking us to provide a managed Kubernetes service to make their lives easier. We announced EKS to meet this need, with a commitment to maintaining a fully upstreamed open source implementation.

In the meantime, Arun blogged about his experiences with several Kubernetes on AWS installers, starting with Kops, and has helped produce a Kubernetes on AWS workshop that was run three times at AWS re:Invent and again at Kubecon the following week. The focus of EKS is production workloads at scale, with a highly available control plane, and each cluster’s master/control plane can be spread over three availability zones.

AWS has contributed plug-ins for CNI that give full access to AWS network functionality and optimize performance for both ECS and Kubernetes.

EKS was announced as limited preview at re:Invent, and we are working on the contributions needed to get the first release out as soon as possible. In 2018, Amazon EKS will also be supported by AWS Fargate, which lets customers run containers directly, avoiding the need to maintain a fleet of underlying instances.

We have plans for many more Kubernetes blog posts and code contributions, and we believe that there are opportunities to propose existing and future AWS open source projects to be incubated by CNCF.

The charter of the open source team we are continuing to build at AWS is to engage with open source projects, communities, and foundations, as well as to help guide and encourage more contributions from AWS engineering. AWS is a member of the Linux Foundation, which hosts CNCF, and we look forward to working with old and new friends on the shared goal to create and drive the adoption of a new computing paradigm optimized for modern distributed systems. Our engineers are working on contributions to several CNCF projects, and all our changes are being discussed with the community and upstreamed. If you’re interested in joining us, please take a look at our job openings.


Please follow @AWSOpen or visit our web site at opensource.amazon.com to keep up to date on open source at AWS.

 

TAGS:
Adrian Cockcroft

Adrian Cockcroft

Vice President Cloud Architecture Strategy, Amazon Web Services Adrian Cockcroft has had a long career working at the leading edge of technology, and is fascinated by what happens next. In his role at AWS, Cockcroft is focused on the needs of cloud native and “all-in” customers, and leads the AWS open source community development team. Prior to AWS, Cockcroft started out as a developer in the UK, joined Sun Microsystems and then moved to the United States in 1993, ending up as a Distinguished Engineer. Cockcroft left Sun in 2004, was a founding member of eBay research labs, and started at Netflix in 2007. He initially directed a team working on personalization algorithms and then became cloud architect, helping teams scale and migrate to AWS. As Netflix shared its architecture publicly, Cockcroft became a regular speaker at conferences and executive summits, and he created and led the Netflix open source program. In 2014, he joined VC firm Battery Ventures, promoting new ideas around DevOps, microservices, cloud and containers, and moved into his current role at AWS in October 2016. During 2017 he recruited a team of experienced open source technologists and gave keynote presentations at AWS Summits and many other events around the world. Cockcroft holds a degree in Applied Physics from The City University, London and is a published author of four books, notably Sun Performance and Tuning (Prentice Hall, 1998).