Kategorie: Microsoft Azure

Bletchley – The Cryptlet Fabric & Evolution of blockchain Smart Contracts

Anatomy of a Smart Contract

The concept of a Smart Contract has been around for awhile and is largely attributed to Nick Szabo’s work in the late 1990s. However, it remained an abstract concept until the summer of 2015 with the Frontier release of Ethereum as its first implementation. The promise of Smart Contracts is sprawling and has gotten the attention of every industry as a revolutionary disrupter that can change the way business is done forever. That remains to be seen, but like most first implementations of significantly important technology, there are some early lessons learned and some introspection about how improvements can be made.

I have written a paper that describes at a high level how Smart Contracts are implemented today and how they can be refactored to significantly improve their performance, security, scalability, manageability, versioning, and reuse in the near future. This paper describes the thought process and historical context for a new architectural approach that focuses on separation of concerns and implementing a 3 Layered/Tiered Smart Contract architecture.

To understand the context and exactly what a “3-Layered & Tiered” Smart Contract architecture means please give this paper a read, Anatomy of a Smart Contract.

If you want the short and sweet answer it is this: Smart Contracts designed for semi-trusted enterprise consortium networks should be separated into 3 main layers:

Data Layer – The definition of data schema and only the data logic for validation of inserts (appends) and optimization of reads. In platforms like Ethereum or Chain, languages like Solidity and Ivy can be used at this layer. This is similar to how relational databases use the SQL language and stored procedures.
Business Layer – All business logic for Smart Contracts and surface level APIs for interacting with Smart Contracts from the Presentation layer (UI) or other external applications. Cryptlets written in any language targeting the runtimes supported by the Cryptlet Fabric. (.NET, .NET Core, JVM, native)
Presentation Layer – User Interface platforms and other applications built on using the exposed APIs by Cryptlets.

These Layers can then be deployed, optimized, and scaled in their respective tiers: Presentation, Middle (Business), and Data tiers.

*Note, this approach is not generally valid for trustless implementations of Smart Contracts, but targeted at enterprise consortium blockchains.

The Cryptlet Fabric – Update

As we get closer to the first public preview of the Cryptlet Fabric, I though it was a good time to quickly highlight what blockchain enthusiasts, professionals and developers should be looking forward to. The Cryptlet Fabric is designed to be the middle tier in the new proposed 3-Layered & Tiered Smart Contract architecture, so it will deliver things you would expect from such an implementation.  It manages scale, failover, caching, monitoring, management…a long list of features, but what is new:

Cryptographic primitives, secure execution enclaves and a runtime secure key (secrets) platform that allows for the creation, persistence and dynamic reanimation for performing cryptographically secure operations with these keys at scale.

This allows Cryptlets to create, store, and use key pairs in a secure execution environment to do all sorts of “blockchain-ey” things like digital signatures, zero knowledge proofs, ring signatures, threshold signatures, and even homomorphic encryption all within secure enclaves. Cryptlets will come in 2 basic types, which I went into some detail in the reading Cryptlets in Depth, utility and contract.

The Cryptlet Fabric provides a blockchain router layer, abstracting away different transaction messages and cryptographic signing from the code implemented in Cryptlets, as well as integration with existing systems. For example, a Cryptlet’s output only contains the information to be sent to the blockchain, like market data or business logic results, and is packaged into the actual blockchain specific transaction by the Cryptlet Fabric below it by the blockchain router and blockchain platform specific providers.  This encapsulation technique has been used for decades allowing technologies like TCP/IP to work on all sorts of networks (LAN, WAN, Internet and Mobile) and all kinds of applications. This is what allows for Cryptlets to be reused across different types of blockchains.

Utility Cryptlets (oracles)

Ok, I admit that being a Microsoft guy makes it hard for me to call anything an oracle without associating it with the company. The fact of the matter is that Utility Cryptlets can largely be thought of as a more scalable, standard, secure, and discoverable way to write blockchain oracles. The majority of requests that we get for Cryptlets are initially in this category, providing a secure attested data source for blockchain applications. You will able to write cryptlet oracles using the language of your choice targeting (initially) .NET, .NET Core, JVM and bare metal runtimes, so C#, Java, C++, F#, VB, etc… Your cryptlet oracle can publish any type of data you want, including:

Market prices
Package delivery notifications
Workflow next steps
Weather alerts
Wounterparty updates like credit downgrade

and define your subscription parameters like:

Time and date
Event driven triggers from the blockchain or listening to external sources
Conditional – if “this” and “that” are true, evaluation combinations if, else if, switches, etc.
Combination – if the time is 4PM EST & the NYSE was open today then send me the LIBOR and the price of x

As a developer or provider of cryptlet oracles you can publish them as libraries into the Azure Marketplace for discovery and acquiring customers. We expect to see a robust catalog of Cryptlet libraries from our partners big and small.

However, there is more to Utility Cryptlets than just providing data. You can use them to expose a secure channel into your blockchain based applications for other applications and user interfaces. An ERP or CRM system can read data from the blockchain without having to know any of the details, and they can also securely fire data and events into the blockchain to ease integration of blockchains into existing enterprise infrastructure. Cryptlets can also provide services to blockchain applications and analytics platforms by triggering events into existing systems by watching blockchain transactions and issuing an index request or data pull.

I’m sure that customers and partners will find many uses for Utility Cryptlets, but the first and most obvious is for blockchain oracles.

Contract Cryptlets

These Cryptlets are key to fully realizing the refactoring of Smart Contracts into a 3-Layered/Tiered architecture. These Cryptlets differ from Utility Cryptlets in many ways. Utility Cryptlets can have many instances at once, each handling many different subscriptions at the same time, whereas Contract Cryptlets are single, paired, or ring instanced and bound to a specific Smart Contract. Contract Cryptlets contain the business logic, rules, and external API for interaction for executing a Smart Contract between counterparties.  In a private, semi-trusted consortium blockchain network where there are strong identities or trust between counterparties, the Smart Contract logic does not need to exist “on-chain” or be executed by every node on the network. Separation of concerns between the data layer in the blockchain and the business and presentation above, isolates code between layers abstracting implementations for reuse and optimization.

Contract Cryptlets are themselves digitally signed and run within an enclave that attests that the code they contain ran unaltered without tampering in private.  This allows for the code in the Cryptlet to be private between counterparties and even be encrypted to protect intellectual property.  Counterparties can write and review their own Contract Cryptlets and all inspect and verify the code before compiling and packaging for implementation, or they can choose from certified Contract Cryptlets that a vendor or reputation stands behind. 

Contract Cryptlets can be instantiated for each counterparty participating in a specific Smart Contract instance.  These Cryptlet Pairs and Rings are optional, but allows for each Contract Cryptlet to hold secrets like private keys for signing or encryption belonging to that counterparty, avoiding co-mingling secrets of counterparties in the same address space.  This capability allows for more advanced transaction scenarios, like encrypting results, to be stored on the blockchain using threshold or ring encryption schemes.

Contract Cryptlets can use private keys and secrets it has permissions to that are fetched from the fabric’s “secret” services.  These secrets are controlled completely by the counterparty via Azure Key Vault, and remain inaccessible to other participants, including Microsoft.

This approach allows code defining a Smart Contract’s business and integration logic to be run on scaled up resources and collocated near data for maximum performance.  The data that they persist to the blockchain is still subject to the data logic “on-chain” and is reconciled on the network through its consensus process.  The digital signatures from the Cryptlet, enclave and blockchain provider are used for validation and attestation, and can be stored along with each transaction on the blockchain as proofs.

Contract Cryptlets also use Utility Cryptlet services, however they can interact directly within the fabric via a subscription or direct API access.

Using Cryptlets allows for a three layered architecture where:

The Smart Contract on the blockchain defines schema and data logic, which is deployed to the blockchain network representing the Data Tier.
Contract Cryptlets define business logic and a Surface Level API for User Interfaces and external applications deployed to the Cryptlet Fabric representing the Middle Tier.
Utility Cryptlets provide reusable data sources and events also in the Middle Tier.
Presentation tier communicates with the Surface Level API of the Cryptlet Fabric using standard UI technologies or integration platforms deployed to web servers, mobile devices, service bus, etc. for the Presentation Tier.

This architectural approach provides abstraction of the blockchain implementation from its clients, as well as tuning and scaling the blockchain and Cryptlet Fabric independently.

Cryptlet Fabric Diagram

Here is an updated diagram of the Cryptlet Fabric.  We will cover its parts in more detail in subsequent posts and white papers, which will also be included in its releases.

Quelle: Azure

Announcing general availability of Managed Disks and larger Scale Sets

I love it that so many of you enjoy both our Infrastructure-as-a-service (IaaS) and Platform-as-a-service (PaaS) services. In fact, over 55% of our IaaS customers also benefit from PaaS services. With this deep experience in both PaaS and IaaS, we can take insights from our PaaS services, like the agile benefit of automated management and scale, and apply it to improve our infrastructure services. Today, I am excited to announce one such insight with the general availability of Managed Disks. With this PaaS-like support, you no longer need to be concerned with the complexity of storage management nor worry about storage as you scale. Yet, you still have the full power and control you expect and love with Azure VMs – a "PaaS bridge" on our IaaS VMs.

This not only simplifies the management of every VM created, it is exponentially helpful when deploying at cloud-scale with VM Scale Sets. Azure VM scale sets (VMSS) are a powerful way to reliably deploy massive cloud infrastructure without the overhead of coordinating multiple resources. With Scale sets, you can simplify the management of your applications with automated application scale and load-balancer integration. Today’s announcement extends these platform features to include automated disk management, enabling simpler storage management and even larger scale. With Managed Disks, you can now attach data disks to every instance and create a VM scale set of up to 1,000 VMs, a 10X increase.

These capabilities are just the beginning to bring the agility of PaaS to the comfort of IaaS. I look forward to announcing additional capabilities coming later this year, including OS patching support, application lifecycle integration, application health monitoring, and load-balancer app health integration.

The sections below elaborate on the key benefits of Managed Disks and VM Scale Sets.

Management

Managed Disks free you from storage account scale management.  Managed Disks are Azure Resource Manager (ARM) resources, can be fully templatized, and support both Standard and Premium Disk types. You only need to specify the size and type of the disk you want. You can create thousands of Managed Disks without worrying about the storage account and without having to specify any disk details. You can create a blank disk, create one from a VHD in a storage account, or create one from an image as part of VM creation. You can even migrate an existing Azure Resource Manager VM to a VM with managed disks with just a single reboot. You don’t have to worry about reconfiguring your networking or your security rules to start using the powerful new capability.

In addition to the new Managed Disk resource, we also have added Snapshots and Images as Azure Resource Managed resources.

Snapshot and Backup

With today’s launch, you can also take a Disk Snapshot and maintain it as an Azure Resource Manager resource. With snapshots, you can back up your Managed Disks at any point-in-time. These Snapshots exist independent of the source disk and can be used to create new Managed Disks. You can also use the Azure Backup service with Managed Disks to create a backup job with time-based backups, easy VM restoration, and backup retention policies.

Image

Managed Disks also support creating a managed custom Image. You can create an Image from your custom VHD in a storage account or directly from a running VM. This captures in a single Image, all Managed Disks associated with a running Virtual Machine, including both the OS and Data Disks. This even enables deploying a large VM Scale Set with hundreds of VMs using your custom Image, without the need to copy to or manage any storage accounts.

“The new Managed Disks significantly reduces code complexity and simplifies the management of disks. Managed Disks will enable us to expand upon our current database-as-a-service offering on Azure with new MongoDB plan types to help meet the demanding workloads of our users.” – Sean Hyrich, mLab

Creating a VM

Using the Azure PowerShell or AZ CLI, you can easily create a VM with Managed Disks. Below is an example of a CLI command to create a VM with a managed OS disk and a 128 GB managed data disk. You no longer specify a Storage account for either the OS disk or data disk.

$ az vm create -g myResourceGroup -n myLinuxVM –image RHEL –size Standard_DS3_v2 –data-disk-sizes-gb 128

You can also easily create a VM with Managed Disks in the portal by selecting, “Use managed disks:”

Here is an example of creating a Windows VM with Managed OS disk using Azure PowerShell. You will notice that now you don’t specify a Storage account. You can also programmatically create a virtual machine with Managed Disks using Azure Management Libraries for Java and .NET.

Scale

Today, you can now deploy up to 1,000 VMs in a Scale Set based on platform images, a 10x scale improvement. This enables you to deploy and manage a single cluster, like a large-scale Hadoop, DataSynapse, Cassandra, or IIS deployment. Additionally, if you need load balancing at this scale, you can deploy with an Azure Application Gateway for layer-7 load-balancing.

“Elasticsearch, the leading open source data search solution, allows companies to explore anywhere from gigabytes to petabytes of data in real-time. Managed Disks and expanded VM Scale Sets will help Azure users deploy Elasticsearch clusters at very large scale” – Martijn Laarman, Elastic Software Developer

Here is how you can easily create a 1,000 VM scale set:

$ az vmss create -g myResourceGroup -n myVMSSName –image ubuntuLTS –instance-count 1000

Application support for scale sets

VM scale sets now support attached data disks. When you define a scale set you can create as many attached disks as the VM size supports. This allows more data-intensive analytics and search applications to take advantage of the management and scalability benefits of scale sets.

Security

Because Managed Disks, Snapshots, and Images are Azure Resource Manager resources, you can now apply granular access control using Azure RBAC on each. Managed Disks expose a variety of operations such as read, write (create/update), delete, and export. You can now grant access to only the operations that a person needs to perform his/her job. You can even create custom roles and only grant the permissions to best suit your requirements.

You can also encrypt Managed Disks using Azure Disk Encryption with Customer-managed or Microsoft-managed keys.

"Through providing disk as a managed logical resource, Managed Disk brings our customers an enhanced, easy to use and more secure experience. We can now define role-based access controls for the Disks." – Jesper Jensen, Solvo IT

Migration

Managed Disks comes with easy migration capability from existing unmanaged Azure Resource Manager VMs to Managed Disks VMs without the need to recreate the VM, preserving the configuration and security of that VM. After initiating migration, the VM become available immediately after rebooting. You have full control of the migration and can choose to migrate one VM at a time or plan the migration to be scripted on all of your VMs at once.

You can now also migrate your Managed Disks from Standard to Premium in an easy way. With Managed Disks, if you stop your VM, you can change the account type of your disks without deleting or reconfiguring the VM. The changed disks become available immediately to restart your VM. Here are more details on how to execute the above migration options.

“Performance limits and proper naming to distribute accounts in different stamps need to be considered for a proper design. With Managed Disks, we’ve seen the light, they put to rest all these concerns and let us and our customers concentrate on our business. That’s not all, Managed Disks come with the migration capability, where I can migrate my Virtual Machines to Managed Disks with a single reboot.” –Daniele Grandini, Progel

Pricing

You can visit the Azure Storage Pricing page for more details for Managed Disks. The pricing of Premium Managed Disks is the same as Premium Unmanaged Disks. Standard Managed Disks offer a slightly different pricing model as Standard Unmanaged Disks with pricing based upon the provisioned disk size. Given the change, we are offering a 50% promotional discount on Standard Managed Disks for the first six months.

Availability Regions

As of today, Managed Disks are available in all the global regions. Sovereign clouds will have this support in the coming weeks. Discover the Availability of Managed Disks by regions.

Getting Started

I hope you enjoyed this post and really enjoy this new service offering bringing the agility and ease of PaaS management and scale to your IaaS VMs. Give the service a try! We would love to hear your feedback and comments. Deploying infrastructure has never been so much fun.

See ya around,

Corey

Learn more about Managed Disks:

Getting started
Azure Management Libraries for Java
Azure Management Libraries for .NET
Azure CLI V2
Premium Managed Disks
Standard Managed Disks
Managed Disks FAQ
VM Scale Set overview
Migrate to Managed Disks
Azure VM scale sets and attached data disks

Quelle: Azure

.NET: Manage Azure Managed Disks

We are announcing beta 5 of the Azure Management Libraries for .NET. Beta 5 adds support for Azure Managed Disks.

Today, Microsoft announced the general availability of Azure Managed Disks – it simplifies the management and scaling of Virtual Machines. Specify the size and disk you want to use for Virtual Machines. You do not have to worry about creating and managing Storage Accounts.

You can use the Azure Management Libraries for .NET to manage Managed Disks.

https://github.com/Azure/azure-sdk-for-net/tree/Fluent

You can download beta 5 from:

Create a Virtual Machine with Managed Disks

You can create a Virtual Machine with an implicit Managed Disk for the operating system and explicit Managed Disks for data using a define() … create() method chain. Creation is simplified with implicit creation of managed disks without specifying all the disk details. You do not have to worry about creating and managing Storage Accounts.

var linuxVM1 = azure.VirtualMachines
.Define(linuxVM1Name)
.WithRegion(Region.USEast)
.WithNewResourceGroup(rgName)
.WithNewPrimaryNetwork("10.0.0.0/28")
.WithPrimaryPrivateIpAddressDynamic()
.WithNewPrimaryPublicIpAddress(linuxVM1Pip)
.WithPopularLinuxImage(KnownLinuxVirtualMachineImage.UbuntuServer16_04_Lts)
.WithRootUsername(“tirekicker”)
.WithSsh(sshkey)
.WithNewDataDisk(100)
.WithSize(VirtualMachineSizeTypes.StandardD3V2)
.Create();

You can download the full, ready-to-run sample code.

Create a Virtual Machine Scale Set with Managed Disks

You can create a Virtual Machine Scale Set with implicit Managed Disks for operating systems and explicit Managed Disks for data using a define() … create() method chain.

var vmScaleSet = azure.VirtualMachineScaleSets
.Define(vmScaleSetName)
.WithRegion(Region.USEast)
.WithExistingResourceGroup(rgName)
.WithSku(VirtualMachineScaleSetSkuTypes.StandardD5v2)
.WithExistingPrimaryNetworkSubnet(network, "subnet1")
.WithExistingPrimaryInternetFacingLoadBalancer(publicLoadBalancer)
.WithoutPrimaryInternalLoadBalancer()
.WithPopularLinuxImage(KnownLinuxVirtualMachineImage.UbuntuServer16_04_Lts)
.WithRootUsername("tirekicker")
.WithSsh(sshkey)
.WithNewDataDisk(100)
.WithNewDataDisk(100, 1, CachingTypes.ReadWrite)
.WithNewDataDisk(100, 2, CachingTypes.ReadOnly)
.WithCapacity(3)
.Create();

You can download the full, ready-to-run sample code.

Create an Empty Managed Disk and Attach It to a Virtual Machine

You can create an empty Managed Disk using a define() … create() method chain.

var dataDisk = azure.Disks.Define(diskName)
.WithRegion(Region.USEast)
.WithExistingResourceGroup(rgName)
.WithData()
.WithSizeInGB(50)
.Create();

You can attach the empty Managed Disk to a Virtual Machine using another define() … create() method chain.

var linuxVM2 = azure.VirtualMachines.Define(linuxVM2Name)
.WithRegion(Region.USEast)
.WithExistingResourceGroup(rgName)
.WithNewPrimaryNetwork("10.0.0.0/28")
.WithPrimaryPrivateIpAddressDynamic()
.WithNewPrimaryPublicIpAddress(linuxVM2Pip)
.WithPopularLinuxImage(KnownLinuxVirtualMachineImage.UbuntuServer16_04_Lts)
.WithRootUsername("tirekicker")
.WithSsh(sshkey)
.WithNewDataDisk(100)
.WithNewDataDisk(100, 1, CachingTypes.ReadWrite)
.WithExistingDataDisk(dataDisk)
.WithSize(VirtualMachineSizeTypes.StandardD3V2)
.Create();

You can download the full, ready-to-run sample code.

Update a Virtual Machine

You can detach Managed Disks and attach new Managed Disks using an update() … apply() method chain.

linuxVM2.Update()
.WithoutDataDisk(2)
.WithNewDataDisk(200)
.Apply();

You can download the full, ready-to-run sample code.

Create a Virtual Machine From a Specialized VHD

You can create a Virtual Machine from a Specialized VHD using a define() … create() method chain.

var linuxVM4 = azure.VirtualMachines.Define(linuxVmName3)
.WithRegion(Region.USEast)
.WithExistingResourceGroup(rgName)
.WithNewPrimaryNetwork("10.0.0.0/28")
.WithPrimaryPrivateIpAddressDynamic()
.WithoutPrimaryPublicIpAddress()
.WithSpecializedOsUnmanagedDisk(specializedVhd, OperatingSystemTypes.Linux)
.WithSize(VirtualMachineSizeTypes.StandardD3V2)
.Create();

You can download the full, ready-to-run sample code.

Create a Virtual Machine Using a Custom Image

You can create a custom image from a de-allocated and generalized Virtual Machine using a define() … create() method chain.

var virtualMachineCustomImage = azure.VirtualMachineCustomImages
.Define(customImageName)
.WithRegion(Region.USEast)
.WithExistingResourceGroup(rgName)
.FromVirtualMachine(linuxVM) // from a de-allocated and generalized Virtual Machine
.Create();

You can create a Virtual Machine from the custom image using another define() … create() method chain.

var linuxVM4 = azure.VirtualMachines.Define(linuxVM4Name)
.WithRegion(Region.USEast)
.WithExistingResourceGroup(rgName)
.WithNewPrimaryNetwork("10.0.0.0/28")
.WithPrimaryPrivateIpAddressDynamic()
.WithoutPrimaryPublicIpAddress()
.WithLinuxCustomImage(virtualMachineCustomImage.Id)
.WithRootUsername(userName)
.WithSsh(sshkey)
.WithSize(VirtualMachineSizeTypes.StandardD3V2)
.Create();

You can download the full, ready-to-run sample code.

Create a Virtual Machine Using Specialized Disks From Snapshots

You can create a Managed Disk Snapshot for an operating system disk.

// Create a Snapshot for an operating system disk
var osDisk = azure.Disks.GetById(linuxVM.OsDiskId);
var osSnapshot = azure.Snapshots.Define(managedOSSnapshotName)
.WithRegion(Region.USEast)
.WithExistingResourceGroup(rgName)
.WithLinuxFromDisk(osDisk)
.Create();

// Create a Managed Disk from the Snapshot for the operating system disk
var newOSDisk = azure.Disks.Define(managedNewOSDiskName)
.WithRegion(Region.USEast)
.WithExistingResourceGroup(rgName)
.WithLinuxFromSnapshot(osSnapshot)
.WithSizeInGB(100)
.Create();

You can create a Managed Disk Snapshot for a data disk.

// Create a Snapshot for a data disk
var dataSnapshot = azure.Snapshots.Define(managedDataDiskSnapshotName)
.WithRegion(Region.USEast)
.WithExistingResourceGroup(rgName)
.WithDataFromDisk(dataDisk)
.WithSku(DiskSkuTypes.StandardLRS)
.Create();

// Create a Managed Disk from the Snapshot for the data disk
var newDataDisk = azure.Disks.Define(managedNewDataDiskName)
.WithRegion(Region.USEast)
.WithExistingResourceGroup(rgName)
.WithData()
.FromSnapshot(dataSnapshot)
.Create();

You can create a Virtual Machine from these specialized disks using a define() … create() method chain.

var linuxVM5 = azure.VirtualMachines.Define(linuxVm5Name)
.WithRegion(Region.USEast)
.WithExistingResourceGroup(rgName)
.WithNewPrimaryNetwork("10.0.0.0/28")
.WithPrimaryPrivateIpAddressDynamic()
.WithoutPrimaryPublicIpAddress()
.WithSpecializedOsDisk(newOSDisk, OperatingSystemTypes.Linux)
.WithExistingDataDisk(newDataDisk)
.WithSize(VirtualMachineSizeTypes.StandardD3V2)
.Create();

You can download the full, ready-to-run sample code.

Convert a Virtual Machine to Use Managed Disks With a Single Reboot

You can convert a Virtual Machine with unmanaged disks (Storage Account based) to Managed Disks with a single reboot.

var linuxVM6 = azure.VirtualMachines.Define(linuxVM6Name)
.WithRegion(Region.USEast)
.WithNewResourceGroup(rgName)
.WithNewPrimaryNetwork("10.0.0.0/28")
.WithPrimaryPrivateIpAddressDynamic()
.WithNewPrimaryPublicIpAddress(linuxVM6Pip)
.WithPopularLinuxImage(KnownLinuxVirtualMachineImage.UbuntuServer16_04_Lts)
.WithRootUsername("tirekicker")
.WithSsh(sshkey)
.WithUnmanagedDisks() // uses Storage Account
.WithNewUnmanagedDataDisk(100) // uses Storage Account
.WithSize(VirtualMachineSizeTypes.StandardD3V2)
.Create();

linuxVM7.Deallocate();
linuxVM7.ConvertToManaged();

You can download the full, ready-to-run sample code.

Try It

You can run the samples above or go straight to our GitHub repo. Give it a try and let us know what do you think (via e-mail or comments below). Over the next few weeks, we will be adding support for more Azure services and applying finishing touches to the API.
Quelle: Azure