How Distributed Application Runtime (Dapr) has grown since its announcement
Since the October 2019 announcement of the Distributed Application Runtime (Dapr), we have seen a tremendous response and the emergence of an engaged Dapr community.
Since the October 2019 announcement of the Distributed Application Runtime (Dapr), we have seen a tremendous response and the emergence of an engaged Dapr community.
Thinking about joining the Kubernetes Release Team? Curious what it even is? As someone who started as a shadow on the Communications team for the 1.16 and 1.17 Release Team and eventually became the Communications Lead for the 1.18 release, I want to share what I’ve learned from this journey and answer any questions you may have about the Release Team.
Linux container technology has changed the face of computing, but especially distributed computing in publicly rentable servers commonly said to be “the public cloud” (like Microsoft Azure). With containers came tooling – like Docker – and systems that orchestrate potentially millions of them – with Kubernetes becoming the most widely used.
Last year Microsoft and Red Hat announced Kubernetes Event-driven Autoscaling (KEDA) – a way to bring event scale for any container or workload deployed into any Kubernetes cluster. Since then, we have been blown away by the response from the community in helping to make KEDA even better.
As more users take advantage of Kubernetes for their Windows applications, the Windows community in Kubernetes has been working on improvements that enable even more use cases. With the release of Kubernetes v1.18, many of these changes are taking shape.
The questions started around KubeCon San Diego. Maybe because we had just released Helm 3. Or, maybe because a few operator tools had been put up for adoption by CNCF. Whatever the cause, I started receiving questions about Helm and operators.
Hello KubeCon and welcome to San Diego! It’s fantastic to have the chance to get some warm California sun, as well as the warmth of the broader Kubernetes community.
Event-driven applications are a key pattern for cloud-native applications. Event-driven is at the core of many growing trends, including serverless compute like Azure Functions. Event-driven means your application responds and reacts to different events – business or system events.
Next week is KubeCon North America 2019, but we wanted to give you an early preview of one of the things we’ll be showing. Over the last few years, we’ve been working on tools for the cloud native ecosystem. From Helm and Brigade to Porter and Rudr, each tool we have built is designed to stand on its own.
Ecosystem complexity increases every time we look around, our dizzying panoply of choices multiplies by the day, and (now, as always) we need a way to find, share, and operate applications reliably, in production, and at scale. What’s a busy Kubernetes user to do? Helm is the well-known and much-used package manager for Kubernetes.
In May 2019, Network Policies on Azure Kubernetes Service (AKS) became generally available through the Azure native policy plug-in or through the community project Calico. This user-defined network policy feature enables secure network segmentation within Kubernetes and allows cluster operators to control which pods can communicate with each other and resources outside the cluster.
Kubernetes has become the leading container orchestration environment. Its success has driven the remarkable growth of Kubernetes services on every public cloud. However, the core resources in Kubernetes like Services and Deployments represent disparate pieces of an overall application. They do not represent the application itself.
It is remarkable to see the transformation over the last few years as more and more developers build scalable, cloud native applications, taking advantage of managed services to deploy and run them.