Open Source Bloghttps://cloudblogs.microsoft.com/opensource
Open dialogue about openness at Microsoft – open source, standards, interoperabilityWed, 27 May 2020 15:29:18 +0000en-US
hourly
1 The Open Application Model reaches a new milestone with v1Alpha2 and Crossplanehttps://cloudblogs.microsoft.com/opensource/2020/05/27/open-application-model-oam-v1alpha2-crossplane/
https://cloudblogs.microsoft.com/opensource/2020/05/27/open-application-model-oam-v1alpha2-crossplane/#respondWed, 27 May 2020 15:00:18 +0000https://cloudblogs.microsoft.com/opensource/2020/05/27/open-application-model-oam-v1alpha2-crossplane/In March of this year, the Open Application Model (OAM) specification reached the second draft milestone of the spec, dubbed v1Alpha2. This draft was a collaborative effort with the OAM community and the community behind Crossplanea forward-thinking open source project that enables you to use the Kubernetes API to provision and manage cloud infrastructure, services,Read more

]]>In March of this year, the Open Application Model (OAM) specification reached the second draft milestone of the spec, dubbed v1Alpha2. This draft was a collaborative effort with the OAM community and the community behind Crossplanea forward-thinking open source project that enables you to use the Kubernetes API to provision and manage cloud infrastructure, services, and applications. With last week's v0.11 release, Crossplane reached an exciting milestone, now implementing the OAM specification.

How we got here

The Open Application Model was designed from the beginning with the ambitious goal of providing a standard way to declaratively model applications agnostic of any specific platform, while still allowing each platform that implements the spec to surface its unique features and capabilities. OAM provides an extendable model at its core, so that applications can be modeled consistently anywhere without being reduced to lowest-common-denominator feature sets.

OAM applications are made of three basic elements:

Components: the workloads you want to run

Traits: operational behaviors for individual components

Scopes: a flexible way to group components around common operational behaviors and form applications of all shapes and sizes.

These elements come together in a simple configuration file that defines all or part of an application.

The key to OAM’s design is that every platform that implements the spec can choose which types of components, traits, and scopes to support, as long as the platform implements the overall model as described in the spec. This allows all platforms to surface their unique features and capabilities through a consistent application model. The v1Alpha2 draft of OAM introduces subtle changes with big impacts on how platforms can implement the specification.

In the first draft of the OAM spec, we mainly focused on containerized workloads. Rudr, the reference implementation of the initial draft of OAM for Kubernetes, included controllers that deployed OAM applications with containerized workloads to Kubernetes clusters. Soon after its initial release, we started thinking about how to extend the model in a few important ways: 1) modeling other types of workloads, like functions, queues, and databases as components; 2) allowing users to bring their existing custom workloads, such as CRDs in Kubernetes, into an OAM application without having to modify them; and 3) making the core extension model around components, traits, and scopes easier to use.

Enter Crossplane

Typically, before you can deploy an application, you first must figure out what infrastructure it will run on. Oftentimes, this ends up coupling the application to the chosen infrastructure. To help decouple the application from the infrastructure, OAM defines three distinct roles: application developer, application operator, and infrastructure operator. Being an application model, the OAM spec focuses mainly on the first two roles. Crossplane defines the same three roles, but mainly focuses on the infrastructure operator role. As it turns out, OAM and Crossplane naturally complement each other: OAM defines the application and Crossplane defines the infrastructure on which the application runs.

The combined result is a powerful, team-centric platform that enables infrastructure operators to define and compose vendor-neutral infrastructure for applications, as well as enables application developers and application operators to define, run, and manage portable applications without concern for the complexities of that infrastructure. We often hear from users about the importance of the separation of concerns, which we see as two sides of the same coin. On one side, application developers want to focus on application code without the complexities of cloud infrastructure. On the other side, infrastructure operators need a way to manage the infrastructure on which those applications run. OAM and Crossplane together provide an elegant solution to both application developers and infrastructure operators.

What’s next

We’re excited about the capabilities that Crossplane brings to operators that manage infrastructure for applications and the huge potential in combining that power with OAM's flexible and open standard for modeling applications. That's why we are excited to make Crossplane the best open source implementation of OAM for Kubernetes and continue our journey to bring an open and standard application model for cloud and edge scenarios.

]]>https://cloudblogs.microsoft.com/opensource/2020/05/27/open-application-model-oam-v1alpha2-crossplane/feed/0Announcing cloud-native workflows using Dapr and Logic Appshttps://cloudblogs.microsoft.com/opensource/2020/05/26/announcing-cloud-native-workflows-dapr-logic-apps/
https://cloudblogs.microsoft.com/opensource/2020/05/26/announcing-cloud-native-workflows-dapr-logic-apps/#respondTue, 26 May 2020 16:00:44 +0000https://cloudblogs.microsoft.com/opensource/2020/05/26/announcing-cloud-native-workflows-dapr-logic-apps/The Distributed Application Runtime (Dapr) project is growing rapidly are we're grateful for all the community support and customer feedback. While working with customers building business applications, we find that one of the most frequent needs is the ability to schedule, automate, and orchestrate business processes. This is often called a business workflow. Workflows alsoRead more

]]>The Distributed Application Runtime (Dapr) project is growing rapidly are we're grateful for all the community support and customer feedback. While working with customers building business applications, we find that one of the most frequent needs is the ability to schedule, automate, and orchestrate business processes. This is often called a business workflow. Workflows also frequently integrate with other apps, data, systems, and services across organizations. To enable developers to easily build workflow applications that use Dapr's capabilities, including diagnostics and multi-language support, we are excited to announce Dapr Workflows.

Dapr workflows using Azure Logic Apps

With Dapr, we have seen a growing list of customers using workflows in their applications. Some have used open source workflow engines, such as Workflow Core. Azure Logic Apps provides extensive workflow capabilities and recently the Logic Apps team decoupled their engine into a set of reusable libraries that can be hosted in many different environments. This provided the ideal opportunity to combine the capabilities of Dapr with Logic Apps to enable a whole new class of business processing applications that can now be built and run on any hosting platform, such as Kubernetes, IoT Edge, or VMs. Logic Apps has now become another application framework that is integrated with Dapr, taking advantage of Dapr's building blocks.

Invoking a Logic Apps workflow

Logic App workflows are extremely flexible enabling you to build a variety of different workload applications and at their core consist of triggers, actions, and connectors. Triggers fire when events or new data meet specified conditions. For example, an event might be getting an email, detecting changes in your Azure Storage account or an incoming HTTP request. Each time the trigger fires, the Logic Apps engine creates a new logic app instance that runs the workflow.

Actions are all the steps that happen after the trigger and enable you to compose data, set conditions, or send HTTP requests. Connectors are how your workflow can get access to data, services, and systems, where you can use pre-built connectors that take care of serializing/deserializing data correctly.

By integrating Logic Apps workflow with Dapr, you can now take advantage of the Dapr's service invocation and input bindings building blocks to trigger workflows. Let's look at an example of how this works.

Below is a simple workflow that is triggered by an incoming HTTP request and the workflow action composes a response message that contains the text message:

“Hello from Logic App workflow running with Dapr!”

You can run this workflow easily on your local machine by using the Dapr CLI, like this:

This command launches a workflow host called myWorkflow (accessed over port 50003), with a Dapr sidecar and the workflows-path flag is the path to the workflow file called workflow1.json that is loaded on startup. This workflow example is shown below or you can view it here. You can have as many workflow files in the workflows-path directory as you wish. You can now invoke a specific workflow file like this using the Dapr invoke method capability with curl:

This ability to easily invoke workflows from Dapr opens up a world of possibilities, including rapid no-code or low-code development, where the Logic Apps workflow, along with its connectors, does all the processes orchestration and integration to external systems and services for you. And, creating the workflows is as simple as opening up the workflow designer, either in the Azure portal or with the Visual Studio Code extension.

Workflow1.json created using the Azure portal Logic Apps designer

Triggering a workflow using Dapr input bindings

Workflows can also be triggered from Dapr input bindings and then within a workflow you can take advantage of the Dapr building blocks. To trigger a workflow from an input binding the name of the workflow must match the name of the input binding.

The workflowTopic.json file below shows how a message arriving on say, a Kafka queue as a Dapr input binding called workflowTopic, triggers this workflow to run. In this workflow, the action that runs takes the body of the input request and saves this to a Dapr state store called mystatestore, thereby showing how you can also call back out to Dapr from the workflow itself to take advantage of Dapr's state management building block.

WorkflowTopic.json shows how a workflow is triggered by an input binding and then calls Dapr state management

Putting this all together you can create some very powerful workflows. For example, workflow2.json below shows how a workflow can first invoke an Azure Function, save the result to a Redis store using Dapr's state management, and then send a request to both Azure Service Bus with the body from the Function call, as well as return the body value to the caller.

Workflow2.json combines multiple HTTP requests to external services

How does it work?

Let's take a deeper look at how this all works and at the same time check out the new repo in the Dapr org called Workflows with all the source code. In the repo there is a .NET Dapr-Logic App host, which loads the Logic Apps engine and runs a gRPC server hosting the Dapr client. When you launch this host process with Dapr as a sidecar, Logic Apps loads any workflow files it finds in the given directory (or via a volume mount if running in a container with Kubernetes) and then waits to receive an invocation or input binding call from Dapr to start any of the workflows. This is shown in the diagram below.

Dapr and application frameworks

As mentioned at the beginning of this post, Logic Apps is now another application framework integrated with Dapr. It is worth spending a moment to look at the developer layers that Dapr provides, as illustrated in the diagram below. At the lowest layer you can use any of the API building blocks over HTTP and gRPC, which means Dapr is accessible from virtually any language. On this is layered gRPC proto generated SDKs for several languages. On top of the gRPC proto layer are crafted SDKs for .NET, Java, and Python (as of today, with others coming), which provide an improved usability experience for developers. Finally, at the highest layer, Dapr integrates with specific application frameworks such as ASP.NET Core, Spring Boot, virtual actors, and now Logic Apps to provide workflows. As a developer you can choose to build against any of these layers, depending on your app requirements.

Future roadmap

This preview release enables the power of workflows with Dapr. On the roadmap is to enable the ability to use the Azure managed connectors (currently only the built-in connectors and actions are available). Managed connectors provide triggers and actions for accessing cloud services, on-premises systems, including Office 365, Azure Blob Storage, SQL Server, Dynamics 365, Salesforce, SharePoint, and more. Currently in this preview, the state of the workflow is saved to Azure Storage for failover recovery. We are exploring using Dapr's state management building block to save the state of the workflow, meaning that you can take advantage of any of the supported Dapr component state stores and make your code more portable.

Give it a try!

We'd love for you to try out Dapr workflows. You can go to the Getting Started overview in the repo, give feedback by raising issues, and become a member of the Dapr community on the Dapr community Gitter channel. You can also join the community calls held every two weeks. We would greatly enjoy hearing about the applications that you build and where you see Dapr workflows being useful.

Dapr continues to evolve rapidly, integrating with developer frameworks such as ASP.NET, Spring Boot, and now Logic Apps. You will see more of these framework integrations that open up new capabilities and scenarios using the power of Dapr's building blocks to enable you, the developer, to easily write apps that are portable, event-driven, and resilient.

]]>https://cloudblogs.microsoft.com/opensource/2020/05/26/announcing-cloud-native-workflows-dapr-logic-apps/feed/0Announcing accelerated training with ONNX Runtime—train models up to 45% fasterhttps://cloudblogs.microsoft.com/opensource/2020/05/19/announcing-support-for-accelerated-training-with-onnx-runtime/
https://cloudblogs.microsoft.com/opensource/2020/05/19/announcing-support-for-accelerated-training-with-onnx-runtime/#commentsTue, 19 May 2020 15:01:47 +0000https://cloudblogs.microsoft.com/opensource/2020/05/19/announcing-support-for-accelerated-training-with-onnx-runtime/ONNX Runtime is an open source project that is designed to accelerate machine learning across a wide range of frameworks, operating systems, and hardware platforms. It is used extensively in Microsoft products, like Office 365 and Bing, delivering over 20 billion inferences every day and up to 17 times faster inferencing. Today we are introducingRead more

]]>ONNX Runtime is an open source project that is designed to accelerate machine learning across a wide range of frameworks, operating systems, and hardware platforms. It is used extensively in Microsoft products, like Office 365 and Bing, delivering over 20 billion inferences every day and up to 17 times faster inferencing.

Today we are introducing significant updates to ONNX Runtime. In addition to improvements for model inferencing, we're announcing the preview of training acceleration.

ONNX Runtime for training

ONNX Runtime now supports accelerated training of transformer models. Transformer models have become the building blocks for advanced language processing and generation. These models contain hundreds of millions of parameters and training them can consume many clusters of GPUs over days. Reducing the total training time can help enable rapid improvements in, and thus faster deployment of, these models.

Today's preview release of training acceleration incorporates innovations from the AI at Scale initiative, such as ZeRO optimization and Project Parasail, that improve memory utilization and parallelism on GPUs. ONNX Runtime also features mixed precision implementation to fit more training data in a single NVIDIA GPU's available memory, helping training jobs converge faster, thereby saving time. It is integrated into the existing trainer code for PyTorch and TensorFlow.

ONNX Runtime is already being used for training models at Microsoft. For example:

Office 365 uses ONNX Runtime to accelerate pre-training of the Turing Natural Language Representation (T-NLR) model, a transformer model with more than 400 million parameters, powering rich end-user features like Suggested Replies, Smart Find, and Inside Look. Using ONNX Runtime has reduced training time by 45% on a cluster of 64 NVIDIA V100 Tensor Core GPUs in Azure Machine Learning.

Bing uses large transformer models with more than 500 million parameters to train and service task-specific models. These models use ONNX Runtime to accelerate pre-training and fine-tuning throughput, cutting training time by 44%.

Visual Studio uses ONNX Runtime to accelerate pre-training a model, similar to GPT-2 Medium, with more than 300 million parameters to power code autocompletion in the IntelliCode feature.

To further accelerate training, we built custom kernels and graph optimizations to eliminate redundant operations. Additionally, ONNX Runtime enables larger batch sizes on the same 32GB memory of NVIDIA V100 Tensor Core GPUs. We tested ONNX Runtime by pretraining BERT-Large, reusing the training scripts and datasets from benchmarking tests by NVIDIA.

In the table below, you'll see the relative training time improvements for pre-training the BERT-Large model on a 4 node NVIDIA DGX-2 cluster. The batch sizes reflect the Phase-1 and Phase-2 stages for the training experiment, using the datasets as detailed in NVIDIA repo. The detailed test report is here.

Developers can use the sample for pretraining BERT-Large with ONNX Runtime and fine-tune to their datasets as needed. We have also published a ready-to-use sample to start experiments in Azure Machine Learning. To use in custom environments, developers can build from the source code using the instructions published here.

ONNX Runtime for inferencing

We continue to improve inference acceleration with ONNX Runtime and are now partnering with Hugging Face to make it easy to accelerate popular transformer models.

We have seen gains from using ONNX Runtime with transformer models and are excited to release functionality that makes it easy to inference Hugging Face Transformer models with ONNX Runtime.

Clment Delangue, CEO of Hugging Face.

Today, we are also releasing multiple updates to ONNX Runtime for inferencing. The new ONNX Runtime inference version 1.3 includes:

]]>https://cloudblogs.microsoft.com/opensource/2020/05/19/announcing-support-for-accelerated-training-with-onnx-runtime/feed/1Introducing WhiteNoise: the new differential privacy platform from Microsoft and Harvard’s OpenDPhttps://cloudblogs.microsoft.com/opensource/2020/05/19/new-differential-privacy-platform-microsoft-harvard-opendp/
https://cloudblogs.microsoft.com/opensource/2020/05/19/new-differential-privacy-platform-microsoft-harvard-opendp/#respondTue, 19 May 2020 15:00:23 +0000https://cloudblogs.microsoft.com/opensource/2020/05/19/new-differential-privacy-platform-microsoft-harvard-opendp/The code for WhiteNoise, the first version of the open source differential privacy platform, is now live on GitHub. The project is jointly developed by Microsoft and Harvard's Institute for Quantitative Social Science (IQSS) and the School of Engineering and Applied Sciences (SEAS) as part of the OpenDP initiative. We've released the code for WhiteNoiseRead more

]]>The code for WhiteNoise, the first version of the open source differential privacy platform, is now live on GitHub. The project is jointly developed by Microsoft and Harvard's Institute for Quantitative Social Science (IQSS) and the School of Engineering and Applied Sciences (SEAS) as part of the OpenDP initiative. We've released the code for WhiteNoise to give developers around the world the opportunity to leverage expert differential privacy implementations, review and stress test them, and join the community and make contributions.

Insights from datasets have the potential to help solve the most difficult societal problems in health, the environment, economics, and other areas. Unfortunately, because many datasets contain sensitive information, legitimate concerns about compromising privacy currently prevent the use of potentially valuable stores of data. Differential privacy makes it possible to extract useful insights from datasets while safeguarding the privacy of individuals.

What is differential privacy?

Pioneered by Microsoft Research and their collaborators, differential privacy is the gold standard of privacy protection. Conceptually, differential privacy uses two steps to achieve privacy benefits.

First, a small amount of statistical noise is added to each result to mask the contribution of individual datapoints. The noise is significant enough to protect the privacy of an individual, but still small enough that it will not materially impact the accuracy of the answers extracted by analysts and researchers.

Then, the amount of information revealed from each query is calculated and deducted from an overall privacy-loss budget, which will stop additional queries when personal privacy may be compromised. This can be thought of as a built-in shutoff switch in place that prevents the system from showing data when it may begin compromising someone's privacy.

Deploying differential privacy

Differential privacy has been a vibrant area of innovation in the academic community since the original publication. However, it was notoriously difficult to apply successfully in real-world applications. In the past few years, the differential privacy community has been able to push that boundary and now there are many examples of differential privacy in production. At Microsoft, we are leveraging differential privacy to protect user privacy in several applications, including telemetry in Windows, advertiser queries in LinkedIn, suggested replies in Office, and manager dashboards in Workplace Analytics.

WhiteNoise platform

The WhiteNoise project aims to connect theoretical solutions from the research community with the practical lessons learned from real-world deployments, to make differential privacy broadly accessible. The name is inspired by the colloquial usage of the term white noise to refer to sound masking machines. Similarly, our system adds noise to mask the contribution of any individual data subject and thereby provide privacy.

WhiteNoise is designed as a collection of components that can be flexibly configured to enable developers to use the right combination for their environments.

In WhiteNoise Core, we provide a pluggable open source library of differentially private algorithms and mechanisms with implementations based on mature differential privacy research. The library provides a fast, memory-safe native runtime. In addition, we also provide the APIs for defining an analysis and a validator for evaluating these analyses and composing the total privacy loss on a dataset. The runtime and validator are built in Rust, while Python support is available and R support is forthcoming.

The analysis graph gives fine-grained control over the privacy-loss budget (epsilon). In this example, the analyst has chosen to distribute an epsilon of 1.0 unequally distributed across a mean and variance statistic.

WhiteNoise handles managing the budget for each query and adding the appropriate amount of noise based budget. Now the analysts has a differentially private mean and variance to use.In WhiteNoise System, we provide system components to make it easier to interface with your data systems, including a SQL query dialect and connections to many common data sources, such as PostgreSQL, SQL Server, Spark, Presto, Pandas, and CSV files. Conceptually, the SQL support permits composition of analysis graphs using a subset of SQL-92.

In WhiteNoise Samples, we provide example code and notebooks to demonstrate the use of the WhiteNoise platform, teach the properties of differential privacy, and highlight some of the nuances of the WhiteNoise implementation.

The WhiteNoise platform currently supports scenarios where the data user is trusted by the data owner and wants to ensure that their releases or publications do not compromise privacy. Future releases will focus on hardened scenarios where the researcher or analyst is untrusted and does not have access to the data directly.

Developing the future together

With the basic design and implementation for WhiteNoise in place, we welcome contributions from developers and others to help build and support the platform going forward. We believe an open approach will ensure trust in the platform and know that contributions from developers and researchers from organizations around the world will be essential in maturing the technology and enabling widespread use of differential privacy in the future.

]]>https://cloudblogs.microsoft.com/opensource/2020/05/19/new-differential-privacy-platform-microsoft-harvard-opendp/feed/0Scaling Kubernetes: Intro to Kubernetes-based event-driven autoscaling (KEDA)https://cloudblogs.microsoft.com/opensource/2020/05/12/scaling-kubernetes-keda-intro-kubernetes-based-event-driven-autoscaling/
https://cloudblogs.microsoft.com/opensource/2020/05/12/scaling-kubernetes-keda-intro-kubernetes-based-event-driven-autoscaling/#respondTue, 12 May 2020 16:00:37 +0000https://cloudblogs.microsoft.com/opensource/2020/05/12/scaling-kubernetes-keda-intro-kubernetes-based-event-driven-autoscaling/A Kubernetes cluster requires compute resources to run applications and these resources may need to increase or decrease depending on the application requirements. This typically falls under the category of "scaling" and can be broadly divided into cluster and application scaling. To deal with increasing requirements, such as high traffic, you can scale out yourRead more

]]>A Kubernetes cluster requires compute resources to run applications and these resources may need to increase or decrease depending on the application requirements. This typically falls under the category of "scaling" and can be broadly divided into cluster and application scaling.

To deal with increasing requirements, such as high traffic, you can scale out your application by running multiple instances. In Kubernetes, this is equivalent to scaling a deployment to add more pods.

You can do it manually, but the Horizontal Pod Autoscaler is a built-in component that can handle this automatically. You might also need to scale out the underlying Kubernetes nodes, such as virtual machines, bare metal instances, etc. This can also be done manually, but you can use a cluster autoscaler that will scale your cluster up and down in an automated fashion.

This blog series will cover open source components that can be used on top of existing Kubernetes primitives to help scale Kubernetes clusters, as well as applications. We will explore:

Virtual Kubelet, an open source Kubernetes kubelet implementation that allows Kubernetes nodes to be backed by providers, including serverless cloud container platforms.

Part 2 will showcase KEDA auto-scaling in action with a practical example

Part 3 will introduce Virtual Kubelet

Part 4 will conclude the series with another example to demonstrate how KEDA and Virtual Kubelet can be combined to deliver scalability

In this post, you will get an overview of KEDA, its architecture, and how it works behind the scenes. This will serve as a good foundation for you to dive into the next post, where you will explore KEDA hands-on with a practical example.

Overview

KEDA (Kubernetes-based Event-driven Autoscaling) is an open source component developed by Microsoft and Red Hat to allow any Kubernetes workload to benefit from the event-driven architecture model. It is an official CNCF project and currently a part of the CNCF Sandbox. KEDA works by horizontally scaling a Kubernetes Deployment or a Job. It is built on top of the Kubernetes Horizontal Pod Autoscaler and allows the user to leverage External Metrics in Kubernetes to define autoscaling criteria based on information from any event source, such as a Kafka topic lag, length of an Azure Queue, or metrics obtained from a Prometheus query.

You can choose from a list of pre-defined triggers (also known as Scalers), which act as a source of events and metrics for autoscaling a Deployment (or a Job). These can be thought of as adapters that contain the necessary logic to connect to the external source (e.g., Kafka, Redis, Azure Queue) and fetch the required metrics to drive autoscaling operations. KEDA uses the Kubernetes Operator model, which defines Custom Resource Definitions, such as ScaledObject, which you can use to configure autoscaling properties.

Pluggability is built into KEDA and it can be extended to support new triggers/scalers

High-level architecture

At a high level, KEDA does two things to drive the autoscaling process:

Provides a component to activate and deactivate a Deployment to scale to and from zero when there are no events

Scaler

As explained earlier, a Scaler is defined by a ScaledObject (Custom Resource) manifest. It integrates with an external source or triggers defined in the ScaledObject to fetch the required metrics and present them to the KEDA metrics server. KEDA integrates multiple sources and also makes it possible to add other scalers or external metric sources using a pluggable interface.

The KEDA Operator consists of a controller that implements a “reconciliation loop” and acts as an agent to activate and deactivate a deployment to scale to and from zero. This is driven by the KEDA-operator container that runs when you install KEDA.

It “reacts” to the creation of a ScaledObject resource by creating a Horizontal Pod Autoscaler (HPA). It's important to note that KEDA is responsible for scaling the deployment from zero to one instance and scaling it back to zero while the HPA takes care of auto-scaling the Deployment from there.

However, the Horizontal Pod Autoscaler also needs metrics to make the autoscaling work. Where does it get the metrics from? Enter the Metrics Adapter!

Metrics Adapter

In addition to defining a Custom Resource Definition and a controller/operator to act upon it, KEDA also implements and acts as a server for external metrics. To be precise, it implements the Kubernetes External Metrics API and acts as an “adapter” to translate metrics from external sources (mentioned above) to a form that the Horizontal Pod Autoscaler can understand and consume to drive the autoscaling process.

How can you use KEDA?

Although we will go through the details in the subsequent blog post, here is a quick peek at how one might use KEDA from a developer’s perspective. Once it is installed to your Kubernetes cluster, this is how you would typically use KEDA (for details, please refer to the examples available at https://github.com/kedacore/samples).

Create a Deployment (or a Job): This is simply the application you want KEDA to scale based on a scale trigger. Apart from that, it is completely independent.

Create a ScaledObject: This is the custom resource definition, with which you can define the source of metrics, as well as autoscaling criteria.

Once this is done, KEDA will start collecting information from the event source and drive the autoscaling accordingly. Here is an example of a ScaledObject, which defines how to autoscale a Redis list consumer called processor that is running in a cluster as a Kubernetes Deployment.

Notice that the ScaledObject definition is largely divided into two parts: one that is generic and the other one that is specific to the event source (Redis has been used as an example).

The generic parameters consist of:

scaleTargetRef.deploymentName: the name of the Deployment you want to autoscale

minReplicaCount: minimum number of replicas that KEDA will scale the deployment down to. You can scale down to zero, but it’s possible to use any other value

cooldownPeriod: the period to wait after the last trigger reported active before scaling the deployment back to minReplicaCount

pollingInterval: the interval to check each trigger on

maxReplicaCount: the maximum number of replicas that KEDA will scale the deployment out to

The event source or trigger specific parameters are:

triggers.type: the event source being used (e.g., redis)

triggers.metadata: attributes that differ from trigger to trigger (e.g., in case of redis, its address, listName, and listLength)

triggers.authenticationRef: allows you to refer to a TriggerAuthentication object, which is another KEDA-specific object to capture the authentication mechanism of an event source

Conclusion

KEDA is a lightweight component that can be added into any Kubernetes cluster to extend its functionality. It can be used to autoscale a variety of workloads ranging from traditional deployments to FaaS (serverless functions).

You can explicitly choose and configure specific applications (Deployment and Job) that you want KEDA to autoscale without impacting other components. KEDA will ensure that your application is scaled down to zero instances (configurable), unless there is work to do. And last but not the least, it is extensible. You can integrate custom event sources in the form of scalers to drive the autoscaling process.

Stay tuned for the next installment in this series, where we will dive deeper into KEDA with the help of a practical example. Other questions or comments? Please let me know in the comments below.

]]>https://cloudblogs.microsoft.com/opensource/2020/05/12/scaling-kubernetes-keda-intro-kubernetes-based-event-driven-autoscaling/feed/0Accelerating open source and hardware innovation to meet data and security demandshttps://cloudblogs.microsoft.com/opensource/2020/05/12/ocp-accelerating-open-source-hardware-innovation-data-growth-security/
https://cloudblogs.microsoft.com/opensource/2020/05/12/ocp-accelerating-open-source-hardware-innovation-data-growth-security/#respondTue, 12 May 2020 15:05:04 +0000https://cloudblogs.microsoft.com/opensource/2020/05/12/ocp-accelerating-open-source-hardware-innovation-data-growth-security/The Open Compute Project (OCP) Global Summit, kicking off virtually on May 12, is where a vibrant and growing community will come together to help grow, drive, and support the open hardware ecosystem. This year's theme for the OCP Global SummitOpen for allis a theme that certainly resonates for us as we continue our openRead more

]]>The Open Compute Project (OCP) Global Summit, kicking off virtually on May 12, is where a vibrant and growing community will come together to help grow, drive, and support the open hardware ecosystem.

This year's theme for the OCP Global SummitOpen for allis a theme that certainly resonates for us as we continue our open source journey alongside industry partners and the open source community. At Microsoft, we believe in and value a community approach to building better technology, because we truly believe that open source makes computing better for the world.

Each year at the OCP Summit, we contribute new innovations that address the most pressing challenges for demands on cloud infrastructure. This year is no different as we continue on our endeavor to accelerate open source innovation and partner with industry leaders and the community to ensure access to the latest hardware security technology.

Accelerating open source innovation

We believe data privacy and security are fundamental to building and maintaining trust in the cloud. By working alongside partners and the community, we can help provide access to the latest hardware security technology. We've been working closely with partners such as Intel, AMD, Broadcom, Nuvoton, Mellanox, and NXP to collaborate and contribute to Project Cerberus. Today, we're excited to announce that Project Cerberus source code and tools, including system processes, platform architecture, reference architecture, and firmware source are being open sourced to enable the broader community to collaborate and contribute to the architecture and technology. We're looking forward to Project Cerberus-enlightened products coming to the market in 2020.

New standards to drive interoperable modularity for AI capabilities and security

Open Accelerator Infrastructure (OAI)

After jointly contributing the OCP Accelerator Module (OAM) specification with Facebook and Baidu in March 2019, Microsoft collaborated with Facebook and Baidu and formed the Open Accelerator Infrastructure (OAI) subproject to jointly develop an open, interoperable, modular infrastructure for supporting emerging accelerators for artificial intelligence (AI) and high-performance computing (HPC). Since inception, OAI contributors have worked through an OCP joint development agreement (OAI-JDA) and have developed the specifications for various modules and three reference systems. Recognizing this interoperability opportunity, several accelerator companies such as Intel/Habana Labs, AMD, nVidia, and Xilinx have announced their plans for OAI-compatible OAMs.

Datacenter-ready Secure Control Module (DC-SCM)

Another example that follows Project Olympus' modular tenets includes DC-SCM and its interface, DC-SCI. As the "heart of the motherboard," DC-SCM includes all essential elements of a server motherboard excluding the CPU, Memory Slots, and IO Slots. It includes BMC, RoT, System, and BMC Flash, as well as other ancillary components required to deliver a datacenter-compatible, secure, control module. As a scheme for the division of roles and responsibilities, this approach allows a "win-win" opportunity for server suppliers, as well as for hyperscale datacenters.

The DC-SCI offers a standard demarcation point for DC-SCM to allow AMD-, Intel-, and ARM64-based servers to quickly and easily be built ready for OCP partner companies. While different OCP partners may utilize one server baseboard by installing their favorite flavor of DC-SCM (with potentially different BMC, RoT, etc.). As a collaborative example, Microsoft co-presented an earlier draft of the DC-SCM concept at the OCP Regional Summit in Amsterdam (September 2019) with Google.

We are looking forward to contributing DC-SCM/DC-SCI base specification to OCP and several ODMs are engaged to integrate DC-SCM into their server solutions over time. The value of DC-SCM and its standard interface has been recognized. The next effort will be its inclusion into the OAI specification as OAI-SCM.

Driving common media standards to improve serviceability

Following on our collaborative efforts to bring the M.2 and E1.L NVME drives into ODM systems, we are introducing the E.1S, a new contribution of a 1U and 2U chassis design optimized for Intel Cascade Lake-based & AMD Rome-based systems. We believe this new standard will help catalyze broader adoption across the enterprise by enabling smaller capacity increments and higher IOPS per GB, as well as easing cost constraints.

While many are arguing that we are reaching the limits of Moore's law, we believe that Moore's law can be applied to halving the cost every two years for the whole data center campusnot just the chip. This means that collectively the network, the hardware, and datacenter are optimized as a system to enable that goal. We see liquid cooling andin particular, immersion coolingare enabling some new architectures that we have not even begun to consider. We see OCP and its partners as a way to accelerate this development.

While liquid cooling is a technology that has been used in specific use cases, such as bitcoin mining, we are not only investing in the solutions and technologies that will power new architectures, but also focusing intensely on the challenges that will come into play as we look to extend the reach of these capabilities to a hyperscale cloud. Cold-Plate solutions have been used in supercomputers for years, but they're very customized and not designed for the serviceability and reliability required by the cloud. Microsoft is collaborating with the OCP ecosystem, particularly Facebook and CoolIT, to establish standards for developing blind-mate Cold-Plate solutions for both Project Olympus systems and Open Rack v3. Even though these racks are different, there are many common components:

Immersion cooling that enables significantly simpler systems and platform designs that are not possible with either air or cold-plate. The end-to-end solution results in the least energy consumed of all cooling methods. Many investigations and collaborations are running in the OCP Advanced Cooling Solutions subteam.

Industry, 3M in particular, on fluids.

Wiwynn as a strong partner bringing immersion systems to OCP.

Joint collaborations with OCP Rack and Power team, Facebook, and the broader ecosystem for Open Rack v3 (ORv3) standards.

Microsoft is working with ORv3 Power Shelf suppliers to deliver high-power racks and systems incorporating the learnings and experience of operating a global cloud. ORv3 holds promise for even deeper reuse of OCP gear.

We look forward to connecting virtually at the OCP Global Summit. We have several sessions throughout the summit, which you can find in the OCP Summit schedule.

]]>https://cloudblogs.microsoft.com/opensource/2020/05/12/ocp-accelerating-open-source-hardware-innovation-data-growth-security/feed/0More “Python for Beginners” videos…times two!https://cloudblogs.microsoft.com/opensource/2020/05/04/more-python-for-beginners-videos/
https://cloudblogs.microsoft.com/opensource/2020/05/04/more-python-for-beginners-videos/#respondMon, 04 May 2020 16:44:00 +0000https://cloudblogs.microsoft.com/opensource/2020/05/04/more-python-for-beginners-videos/When Susan and I created the Python for Beginners series last fall, we had the goal of trying to help new developers make the transition into one of the most popular and flexible programming languages available. We focused on some of the most common features and attempted to bring you to the point where youRead more

]]>When Susan and I created the Python for Beginners series last fall, we had the goal of trying to help new developers make the transition into one of the most popular and flexible programming languages available. We focused on some of the most common features and attempted to bring you to the point where you could complete a quickstart or other Python tutorials on your own.

We were both impressed by how well our audience (you!) liked the videos and we're really thankful for all the support you've shown. Seeing how we could make an impact on so many developers was a fulfilling experience for us too.

But…there’s always more to learn! We had a relatively short amount of time to cover a rather large topic. Cuts had to be made, and certain topics either didn’t get covered or introduced.

So, we’re back for more!

Even better news: we didn’t just create a new series, but two!

The first, cleverly titled “More Python for Beginners” is purely about Python. We'll examine some of the more intermediate features that didn’t quite fit in our first series. We'll explore lambdas (anonymous functions) and object-oriented programming. We'll also introduce some newer functionality to support asynchronous development through async/await.

Photo from February 2020, before social distancing guidelines were in place

While we’re not going to get into conversations about choosing algorithms or building models, we are going to introduce what you’ll use when you begin the journey. We’ll highlight notebooks, the favorite tool of data scientists. We’ll introduce a couple of common libraries: NumPy and pandas, which are used to help you manage data. You’ll see how to create tables in memory, and how to load, save, and manipulate data. We’ll finish by opening Scikit-learn to create a model and graph the results.

Photo from February 2020, before social distancing guidelines were in place

As with the first series, our goal is to help you reach a point where you could attend a course or follow a tutorial. If you’re looking for your next challenge after completing this course, you could predict flight delays, see how to setup classification in machine learning, and explore other free content on Microsoft Learn to continue your growth as a developer. Learning any new skill requires having a base set of knowledge on which to build: we’re here to help you build that base and support your learning journey!

]]>https://cloudblogs.microsoft.com/opensource/2020/05/04/more-python-for-beginners-videos/feed/0Helm, the package manager for Kubernetes, now a CNCF graduated projecthttps://cloudblogs.microsoft.com/opensource/2020/05/01/helm-package-manager-kubernetes-now-cncf-graduated-project/
https://cloudblogs.microsoft.com/opensource/2020/05/01/helm-package-manager-kubernetes-now-cncf-graduated-project/#respondFri, 01 May 2020 20:40:39 +0000https://cloudblogs.microsoft.com/opensource/2020/05/01/helm-package-manager-kubernetes-now-cncf-graduated-project/Yesterday, Helm became a graduated project in the Cloud Native Computing Foundation (CNCF), joining a select group of projects that the CNCF recognizes for achieving majority adoption by the cloud-native community. I want to extend congratulations and thanks both to the creators of Helm, as well as to the broader Helm community that has supported,Read more

]]>Yesterday, Helm became a graduated project in the Cloud Native Computing Foundation (CNCF), joining a select group of projects that the CNCF recognizes for achieving majority adoption by the cloud-native community.

I want to extend congratulations and thanks both to the creators of Helm, as well as to the broader Helm community that has supported, extended, and enabled Helm to reach this significant milestone. The wider Kubernetes community is better for the foresight of Helm's creators and the persistence of the community. Thank you!

Before the folks at Deis created Helm, there was no go-to solution in the Kubernetes landscape for packaging together and parameterizing a complete application running on Kubernetes. People who needed to collect and manage complete applications were forced to cobble together their own tools and approaches to packages. It was difficult to maintain applications that could address multiple environments and even harder to effectively collaborate on community-maintained packages for commonly deployed solutions.

Prior to the creation of the CNCF, Helm was a subproject of the Kubernetes project itself and the Helm 2 rewrite of the original Deis Helm project was a collaborative effort with the broader Kubernetes community. While I had some familiarity with the Helm project before the acquisition of Deis by Microsoft more than three years ago, getting to know the team, the project, and the community was one of the highlights of the acquisition for me.

Microsoft has played a key role in the support of the Helm project. Many of the core Helm developers are Microsoft employees who work full-time on Helm. Microsoft also supports much of the compute infrastructure necessary for developing, validating, and distributing Helm to the world. Microsoft is not alone in this support many important community contributions have come from various companies as Helm has evolved and improved. One of the amazing things about open source is that we can find ways to work very successfully together, even when coming from sometimes competing companies.

As both the Kubernetes and Helm communities grew, it made sense to separate the Helm project from Kubernetes itself. Configuration management is an opinionated space and having any sort of configuration management tightly integrated as a single solution within Kubernetes itself doesn't make sense. The CNCF was a natural home for Helm and Microsoft agreed, donating Helm to the CNCF as an incubating project.

Over the last few years, it has been awesome to see how the Helm project and community have flourished within the CNCF, from events like the Helm Summits to the recent milestone of becoming a graduated project. Helm is the de-facto packaging solution for cloud-native applications. More than 70% of Kubernetes users use Helm to deploy their applications. Helm itself has also evolved, with the recent Helm 3 release representing a nearly complete refactoring of the Helm codebase.

Configuration management and packaging is a tricky area of the cloud-native landscape. Designing a great solution is like designing a great programming language. It takes great insight, but also a great willingness to listen to your users and build tools that address the problems that they have today. I want to congratulate the Helm team on their journey so far. It is your talent and user obsession that has driven your success. I look forward to seeing what the Helm community accomplishes next.

]]>https://cloudblogs.microsoft.com/opensource/2020/05/01/helm-package-manager-kubernetes-now-cncf-graduated-project/feed/0How Distributed Application Runtime (Dapr) has grown since its announcementhttps://cloudblogs.microsoft.com/opensource/2020/04/29/distributed-application-runtime-dapr-growth-community-update/
https://cloudblogs.microsoft.com/opensource/2020/04/29/distributed-application-runtime-dapr-growth-community-update/#respondWed, 29 Apr 2020 16:00:35 +0000https://cloudblogs.microsoft.com/opensource/2020/04/29/distributed-application-runtime-dapr-growth-community-update/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. Over the past six months, more than 120 contributors have jumped on board and participated in the effort to build and extend Dapr through the GitHub repos opening issues,Read more

]]>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. Over the past six months, more than 120 contributors have jumped on board and participated in the effort to build and extend Dapr through the GitHub repos opening issues, offering feature proposals, taking part in discussions, and making more than 350 distinct code contributions. This community engagement has demonstrated that Dapr enables developers from all backgrounds to solve some of the toughest challenges when developing distributed applications. We are grateful for the engagement and participation from the community helping us make Dapr better.

On top of the community response, we have also been busy working with customers around the world and from different industries to use Dapr for developing business-critical workloads. These customer engagements have been a tremendous source of feedback and participation, helping shape the roadmap for Dapr and putting Dapr on a path towards a stable v1.0 release. In future blog posts, we'll share some of these real-world scenarios where Dapr is helping companies build their future applications.

What is Dapr?

Dapr is an event-driven, portable runtime for building microservices on cloud and edge and embraces the diversity of languages and developer frameworks. Dapr codifies best practices for building distributed applications and at its core are API abstractions that provide common capabilities needed to build microservices, including state management, service invocation, pub/sub messaging, secrets management, and others.

Each capability is abstracted through a "Building Block" that defines a simple and consistent API decoupled from the technology chosen to implement it through the use of pluggable components. This best practice of decoupling frees developers from the burden of integrating and having a deep understanding of the underlying technologies they use. The use of building blocks also allows swapping implementations when the application is deployed in different hosting environments or when needs change as the application evolves without affecting your code. Developers are free to use all, a few, or even just one building block as needed.

Since Dapr itself provides both HTTP REST or gRPC APIs, applications using Dapr are portable and can be written in any language. Furthermore, Dapr runs as a sidecar to the application so a developer using Dapr simply sends a call to the Dapr sidecar and Dapr takes care of the rest. Since Dapr is a process or container that runs alongside the application it can run in any environment including a local dev machine (running Linux, Mac, or Windows), a Kubernetes cluster, an ARM edge device, or any other compute infrastructure. Dapr is also not limited to either on-premises or cloud environments it can run alongside any application, written in any language, deployed to any environment.

Dapr evolution

Dapr has evolved considerably in the five versions released since October 2019. These are some of the highlights made in the past six months:

More building blocks, more components

Secrets building block – The first example of a community-driven addition to Dapr is the introduction of the Secrets building block which enables developers to retrieve secrets from secret stores that can then be used to authenticate to other resources, such as database access. The secrets building block takes away the complexity of authentication and secret retrieval with the store and turns this into a local API call. Currently supported secret stores include, HashiCorp Vault, Azure Key Vault, AWS Secret Manager, GCP Secret Manager, and Kubernetes.

More components – In addition, there have been many contributions of components, extending Dapr's support for commonly used technologies across all building blocks. For example, Dapr was launched with support for two state stores (Redis and Azure Cosmos DB) and since has added components for a total of 16 different state stores, including Memcached, MongoDB, AWS DynamoDB, among others. To explore more components, see the components contribution GitHub repo.

Dapr sidecars running for each service with pluggable components used by its API building blocks

Extended developer tools support

SDKs – While Dapr is independent of any programming language, it can be easily integrated into applications with language-specific SDKs. As we see more developers using Dapr, our investment in these SDKs to help streamline Dapr integration has increased. Dapr offers SDKs for JavaScript, Python, Java, .NET, Go, as well as recently added Rust and C++. In addition, based on community feedback many improvements have been added into the Java SDK, included virtual actors, typed classes, and integration with the Spring Boot web framework. For .NET there have also been improvements to the types classes and integration with ASP.NET Core web framework. Similar support is planned for the other SDKs as part of the future road map.

Visual Studio Code extension – Being able to develop applications on your local machine without any cloud dependency is important for productivity and cost and is a key goal of Dapr. The Dapr Visual Studio Code (VS Code) preview extension helps developers debug applications using Dapr, interact with the Dapr runtime, and combines with the Dapr CLI. You can find the extension in the Visual Studio Marketplace.

Dapr dashboard This Dapr dashboard is a web UI that helps you visualize information about Dapr instances running on your local machine or on Kubernetes.

Increased security

Making sure that messages cannot be sniffed or tampered with in a distributed application is vital to prevent any malicious behavior. Dapr provides end-to-end secure encryption via mutual TLS. This includes encryption of network traffic between the sidecars and from every sidecar to the Dapr control plane. Mutual TLS is turned on by default for any application using Dapr and is configurable to rollover certificates on a frequent basis, for example, every hour. Users can bring their own certificates or use the built-in certificate authority Dapr provides to ease certificate generation and management. Learn more about Dapr security features.

Observability

As the Dapr sidecars run alongside services, it offers advanced observability capabilities including tracing, logging, and metrics collection. Dapr currently uses the Open Census standard and is moving to the Open Telemetry standard as it moves to a stable version. The adoption of standards, where possible, is a key goal of Dapr. For example, all pub/sub events also conform to the v1.0 Cloud Events specification

Tracing Tracing provides visibility of the calls between your services to create an application map and help diagnose issues in production. Dapr uses middleware to intercept traffic and adds correlation-IDs to enable distributed tracing using W3C Trace Context. Since Dapr integrates at the application level it enables asynchronous tracing on top of synchronous tracing meaning, for example, intercommunication via pub/sub can be traced. Furthermore, tracing is handled by the Dapr sidecar, so no code changes are required to instrument an application. To try out tracing yourself see the observability sample which shows how to configure Dapr for distributed tracing integrated with Zipkin.

Metrics Metrics provide visibility into call latency times between services and resource usage. Dapr provides metric collection for both Dapr services (sidecar and the Dapr control plane system services), as well as the user application services. Metrics collected include CPU and memory usage, sidecar injection failures, request error rates, and many others. Dapr allows easy integrations with technologies such as Prometheus or Azure Application Insights so users can easily set up metric visualization. See how to setup Dapr with Prometheus and Grafana as an example.

What's next on the roadmap?

As Dapr matures, the focus of the upcoming work is towards the v1.0 release, getting Dapr out of preview and to production quality. This includes finalizing APIs, making stability improvements including long-running tests, extending end-to-end testing, performance testing infrastructure including releasing benchmark numbers, external security audits and threat model analysis, and taking contributions from the community.

To ensure that we are confident in getting to stable v1.0 release, we are working closely with several companies to take Dapr into production, deployed into a number of different environments, and with a diverse set of developer frameworks, including .NET, Go, Java, C++, Node.js, and others.

Join the Dapr community

We'd love for you to try out Dapr for yourself and become a member of the Dapr community. You can get involved in many ways, including:

Explore the GitHub repos. Read the docs, comment on issues or open new ones, and contribute through pull requests. Look for issues labeled as "good first issue" to start with, for example, in the dapr/dapr or the dapr/components-contrib.

]]>https://cloudblogs.microsoft.com/opensource/2020/04/29/distributed-application-runtime-dapr-growth-community-update/feed/0Announcing azcollection, the Ansible collection for Azurehttps://cloudblogs.microsoft.com/opensource/2020/04/28/announcing-azcollection-the-ansible-collection-for-azure/
https://cloudblogs.microsoft.com/opensource/2020/04/28/announcing-azcollection-the-ansible-collection-for-azure/#respondTue, 28 Apr 2020 16:49:08 +0000https://cloudblogs.microsoft.com/opensource/2020/04/28/announcing-azcollection-the-ansible-collection-for-azure/Back in November, we shared with the community that we had moved 18 certified Azure modules to azcollection. Today, we are happy to announce that we have completed the migration of more than 150 Ansible Azure modules to the Ansible Azure Collection: azcollection. Many of you are no stranger to Ansible's plan to move anythingRead more

]]>Back in November, we shared with the community that we had moved 18 certified Azure modules to azcollection. Today, we are happy to announce that we have completed the migration of more than 150 Ansible Azure modules to the Ansible Azure Collection: azcollection.

Many of you are no stranger to Ansible's plan to move anything not deemed ‘core’ into separate collection repositories in Ansible 2.10. Since the foundational Ansible components are separate from the content, from Ansible 2.10 onwards, you will need to perform a small additional step to install the latest release of azcollection.

To install azcollection, run the following command:

ansible-galaxy collection install azure.azcollection

Note: Ansible 2.9 (or later) is required for azcollection.

To make sure you have the most recent version, add the "–force” flag.

ansible-galaxy collection install azure.azcollection force

If you use Azure Cloud Shell, we are working on getting azcollection installed by default. In the meantime, you should run the same ansible-galaxy command in Cloud Shell.

Using azcollection

To reference the collection content, add these two lines (bolded) to your playbook:

- hosts: all collections: - azure.azcollection tasks: - ...

Contribute to azcollection

If you are interested in fixing issues and contributing to the code base, please refer to this README that details how to contribute directly to azcollection.

Bonus module: azure_rm_keyvaultsecret_info

We do have a small surprise for all of our users! We added the new module azure_rm_keyvaultsecret_info to azcollection. You can now retrieve the secret you store in the Azure Key Vault and use it in subsequent tasks. To learn more, check out this new end-to-end tutorial on how to use Azure Key Vault modules with a Linux virtual machine.

Migrating all of the Azure content was no small feat. To name just the basics, we needed to test all of the modules against ansible-base and set up a robust test infrastructure. While there are still minor kinks to iron, like working with our Red Hat counterparts on the documentation for new modules in our collection, we're incredibly proud of what we've achieved. Now that we've completed this major undertaking, we're hoping to switch our focus back to adding more coverage for Azure services. If you have any feedback, please let us know on GitHub.

Please be on the lookout for additional features and tutorials to be added.