Kategorie: Microsoft Azure

Better together, synergistic results from digital transformation

Intelligent manufacturing transformation can bring great changes, such as connecting the sales organization with field services. Moving to the cloud also provides benefits such as an intelligent supply chain and innovations enabled by connected products. As such, digital transformation is the goal of many, as it can mean finding a competitive advantage.

The Azure platform offers a wealth of services for partners to enhance, extend, and build industry solutions. Here we describe how one Microsoft partner uses Azure to solve a unique problem.

Leverage through Azure services

One company, PTC, is well-known for ThingWorx, a market-leading, end-to-end Industrial Internet of Things (IIoT) solution platform, built for industrial environments. PTC has moved its platform to Azure, and in doing so, leverages the resources and technical advantages of Microsoft. Together, the two create a synergy that can help any manufacturer make a successful move to the digital world.

Why things matter

The ThingWorx by PTC platform includes a number of components that can kickstart any effort to digitally transform a manufacturing floor. The platform consists of two notable components:

ThingWorx analytics
ThingWorx industrial connectivity

By implementing the platform, developers can create comprehensive, feature-rich IoT solutions and deliver faster time-to-insights, critical to the success of industrial implementations. Because the platform is customized for industrial environments and all aspects of manufacturing, as outlined below, it streamlines the digital transformation with capabilities unique to manufacturing. Add to that, PTC’s partnership with Microsoft and you get capabilities such as integrating HoloLens devices into mixed reality experiences.

Azure IoT Hub integration

Azure IoT Hub has a central role on the platform. The service is accessed through the ThingWorx Azure IoT Connector. Features include:

Ingress processing: Devices that are running Azure IoT Hub SDK applications send messages to the Azure IoT Hub. These messages arrive through an Azure Event Hub endpoint that is provided by the IoT Hub. Communication with the ThingWorx platform is asynchronous to allow for optimal message throughput.
Egress processing: Egress messages arrive from the ThingWorx platform and are pushed to the Azure IoT Hub through its service client.
Device methods as remote services: The Azure IoT Hub enables you to invoke device (direct) methods on edge devices from the cloud.
Azure IoT Blob Storage: allows integration with Azure Blob Storage accounts.
File transfers: The Azure IoT Hub Connector supports transferring files between edge devices and an Azure Storage container.

Next steps

To learn more, go to the Azure marketplace for ThingWorx for Azure and click Contact me.
To see more about Azure in manufacturing, go to Azure for Manufacturing.

Quelle: Azure

Improving Azure Virtual Machines resiliency with Project Tardigrade

"Our goal is to empower organizations to run their workloads reliably on Azure. With this as our guiding principle, we are continuously investing in evolving the Azure platform to become fault resilient, not only to boost business productivity but also to provide a seamless customer experience. Last month I published a blog post highlighting several initiatives underway to keep improving in this space, as part of our commitment to provide a trusted set of cloud services. Today I wanted to expand on the mention of Project Tardigrade – a platform resiliency initiative that improves high availability of our services even during the rare cases of spontaneous platform failures. The post that follows was written by Pujitha Desiraju and Anupama Vedapuri from our compute platform fundamentals team, who are leading these efforts.” Mark Russinovich, CTO, Azure

This post was co-authored by Jim Cavalaris, Principal Software Engineer, Azure Compute. 

Codenamed Project Tardigrade, this effort draws its inspiration from the eight-legged microscopic creature, the tardigrade also known as the water bear. Virtually impossible to kill, tardigrades can be exposed to extreme conditions, but somehow still manage to wiggle their way to survival. This is exactly what we envision our servers to emulate when we consider resiliency, hence the name Project Tardigrade. Similar to a tardigrade’s survival across a wide range of extreme conditions, this project involves building resiliency and self-healing mechanisms across multiple layers of the platform ranging from hardware to software, all with a view towards safeguarding your virtual machines (VMs) as much as possible.

How does it work?

Project Tardigrade is a broad platform resiliency initiative which employs numerous mitigation strategies with the purpose of ensuring your VMs are not impacted due to any unanticipated host behavior. This includes enabling components to self-heal and quickly recover from potential failures to prevent impact to your workloads. Even in the rare cases of critical host faults, our priority is to preserve and protect your VMs from these spontaneous events to allow your workloads to run seamlessly.

One example recovery workflow is highlighted below, for the uncommon event in which a customer initiated VM operation fails due to an underlying fault on the host server. To carry out the failed VM operation successfully, as well proactively prevent the issue from potentially affecting other VMs on the server, the Tardigrade recovery service will be notified and will begin executing failover operations.

The following phases briefly describe the Tardigrade recovery workflow:

Phase 1:

This step has no impact to running customer VMs. It simply recycles all services running on the host. In the rare case that the faulted service does not successfully restart, we proceed to Phase 2.

Phase 2:

Our diagnostics service runs on the host to collect all relevant logs/dumps systematically, to ensure that we can thoroughly diagnose the reason for failure in Phase 1. This comprehensive analysis allows us to ‘root cause’ the issue and thereby prevent reoccurrences in the future.

Phase 3:

At a high level, we reset the OS into a healthy state with minimal customer impact to mitigate the host issue. During this phase we preserve the states of each VM to RAM, after which we begin to reset the OS into a healthy state. While the OS swiftly resets underneath, running applications on all VMs hosted on the server briefly ‘freeze’ as the CPU is temporarily suspended. This experience is similar to a network connection temporarily lost but quickly resumed due to retry logic. After the OS is successfully reset, VMs consume their stored state and resume normal activity, thereby circumventing any potential VM reboots.

With the above principles we ensure that the failure of any single component in the host does not impact the entire system, making customer VMs more immune to unanticipated host faults. This also allows us to recover quickly from some of the most extreme forms of critical failures (like kernel level failures and firmware issues) while still retaining the virtual machine state that you care about.

Going forward

Currently we use the aforementioned Tardigrade recovery workflow to catch and quickly recover from potential software host failures in the Azure fleet. In parallel we are continuously innovating our technical capabilities and expanding to different host failure scenarios we can combat with this resiliency initiative.

We are also looking to explore the latest innovations in machine learning to harness the proactive capabilities of Project Tardigrade. For example, we plan to leverage machine learning to predict more types of host failures as early as possible. For example, to detect abnormal resource utilization patterns of the host that may potentially impact its workloads. We will also leverage machine learning to help recommend appropriate repair actions (like Tardigrade recovery steps, potentially live migration, etc.) thereby optimizing our fleetwide recovery options.

As customers continue to shift business-critical workloads onto the Microsoft Azure cloud platform, we are constantly learning and improving so that we can continue to meet customer expectations around interruptions from unplanned failures. Reliability is and continues to be a core tenet of our trusted cloud commitments, alongside compliance, security, privacy, and transparency. Across all of these areas, we know that customer trust is earned and must be maintained, not just by saying the right thing but by doing the right thing. Platform resiliency as practiced by Project Tardigrade is already strengthening VM availability by ensuring that underlying host issues do not affect your VMs.

We will continue to share further improvements on this project and others like it, to be as transparent as possible about how we’re constantly improving platform reliability to empower your organization.
Quelle: Azure

Your single source for Azure best practices

Optimizing your Azure workloads can feel like a time-consuming task. With so many services that are constantly evolving it’s challenging to stay on top of, let alone implement, the latest best practices and ensure you’re operating in a cost-efficient manner that delivers security, performance, and reliability.

Many Azure services offer best practices and advice. Examples include Azure Security Center, Azure Cost Management, and Azure SQL Database. But what if you want a single source for Azure best practices, a central location where you can see and act on every optimization recommendation available to you? That’s why we created Microsoft Azure Advisor, a service that helps you optimize your resources for high availability, security, performance, and cost, pulling in recommendations from across Azure and supplementing them with best practices of its own.

In this blog, we’ll explore how you can use Advisor as your single destination for resource optimization and start getting more out of Azure.

What is Azure Advisor and how does it work?

Advisor is your personalized guide to Azure best practices. It analyzes your usage and configurations and offers recommendations to help you optimize your Azure resources for high availability, security, performance, and cost. Each of Advisor’s recommendations includes suggested actions and sharing features to help you quickly and easily remediate your recommendations and optimize your deployments. You can also configure Advisor to only show recommendations for the subscriptions and resource groups that mean the most to you, so you can focus on critical fixes. Advisor is available from the Azure portal, command line, and via REST API, depending on your needs and preferences.

Ultimately, Advisor’s goal is to save you time while helping you get the most out of Azure. That’s why we’re making Advisor a single, central location for optimization that pulls in best practices from companion services like Azure Security Center.

How Azure Security Center integrates with Advisor

Our most recent integration with Advisor is Azure Security Center. Security Center helps you gain unmatched hybrid security management and threat protection. Microsoft uses a wide variety of physical, infrastructure, and operational controls to help secure Azure—but there are additional actions you need to take to help safeguard your workloads. Security Center can help you quickly strengthen your security posture and protect against threats.

Advisor has a new, streamlined experience for reviewing and remediating your security recommendations thanks to a tighter integration with Azure Security Center. As part of the enhanced integration, you’ll be able to:

See a detailed view of your security recommendations from Security Center directly in Advisor.
Get your security recommendations programmatically through the Advisor REST API, CLI, or PowerShell.
Review a summary of your security alerts from Security Center in Advisor.

The new Security Center experience in Advisor will help you more quickly and easily remediate security recommendations.

How Azure Cost Management integrates with Advisor

Another Azure service that provides best practice recommendations is Azure Cost Management, which helps you optimize cloud costs while maximizing your cloud potential. With Cost Management, you can monitor your spending, increase your organizational accountability, and boost your cloud efficiency.

Advisor and Cost Management are also tightly integrated. Cost Management’s integration with Advisor means that you can see any cost recommendation in either service and act to optimize your cloud costs by taking advantage of reservations, rightsizing, or removing idle resources.

Again, this will help you streamline your optimizations.

Azure SQL DB Advisor, Azure App Service Advisor, and more

There’s no shortage of advice in Azure. Many other services including Azure SQL Database and Azure App Service include Advisor-like tools designed to help you follow best practices for those services and succeed in the cloud.

Advisor pulls in and displays recommendations from these services, so the choice is yours. You can review the optimizations in context—in a given instance of an Azure SQL database, for example—or in a single, centralized location in Advisor.

We often recommend the Advisor approach. This way, you can see all your optimizations in a broader, more holistic context and remediate with the big picture in mind, without worrying that you’re missing anything. Plus, it’ll save you time switching between different resources.

Review your recommendations in one place with Advisor

Our recommendation? Use Advisor as your core resource optimization tool. You’ll find everything in a single location rather than having to visit different, more specialized locations. With the Advisor API, you can even integrate with your organization’s internal systems—like a ticketing application or dashboard—to get everything in one place on your end and plug into your own optimization workflows.

Visit Advisor in the Azure portal to get started reviewing, sharing, and remediating your recommendations. For more in-depth guidance, visit the Azure Advisor documentation. Let us know if you have a suggestion for Advisor by submitting an idea here in the Advisor forums.
Quelle: Azure

Announcing the preview of Azure Actions for GitHub

On Thursday, August 8, 2019, GitHub announced the preview of GitHub Actions with support for Continuous Integration and Continuous Delivery (CI/CD). Actions makes it possible to create simple, yet powerful pipelines and automate software compilation and delivery. Today, we are announcing the preview of Azure Actions for GitHub.

With these new Actions, developers can quickly build, test, and deploy code from GitHub repositories to the cloud with Azure.

You can find our first set of Actions grouped into four repositories on GitHub, each one containing documentation and examples to help you use GitHub for CI/CD and deploy your apps to Azure.

azure/actions (login): Authenticate with an Azure subscription.
azure/appservice-actions: Deploy apps to Azure App Services using the features Web Apps and Web Apps for Containers.
azure/container-actions: Connect to container registries, including Docker Hub and Azure Container Registry, as well as build and push container images.
azure/k8s-actions: Connect and deploy to a Kubernetes cluster, including Azure Kubernetes Service (AKS).

Connect to Azure

The login action (azure/actions) allows you to securely connect to an Azure subscription.

The process requires using a service principal, which can be generated using the Azure CLI, as per instructions. Use the GitHub Actions’ built-in secret store for safely storing the output of this command.

If your workflow involves containers, you can also use the azure/k8s-actions/docker-login and azure/container-actions/aks-set-context Actions for connecting to Azure services like Container Registry and AKS respectively.

These Actions help setting the context for the rest of the workflow. For example, once you have used azure/container-actions/docker-login, the next set of Actions in the workflow can perform tasks such as building, tagging, and pushing container images to Container Registry.

Deploy a web app

Azure App Service is a managed platform for deploying and scaling web applications. You can easily deploy your web app to Azure App Service with the azure/appservice-actions/webapp and azure/appservice-actions/webapp-container Actions.

The azure/appservice-actions/webapp action takes the app name and the path to an archive (*.zip, *.war, *.jar) or folder to deploy.

The azure/appservice-actions/webapp-container supports deploying containerized apps, including multi-container ones. When combined with azure/container-actions/docker-login, you can create a complete workflow which builds a container image, pushes it to Container Registry and then deploys it to Web Apps for Containers.

Deploy to Kubernetes

azure/k8s-actions/k8s-deploy helps you connect to a Kubernetes cluster, bake and deploy manifests, substitute artifacts, check rollout status, and handle secrets within AKS.

The azure/k8s-actions/k8s-create-secret action takes care of creating Kubernetes secret objects, which help you manage sensitive information such as passwords and API tokens. These notably include the Docker-registry secret, which is used by AKS itself to pull a private image from a registry. This action makes it possible to populate the Kubernetes cluster with values from the GitHub Actions’ built-in secret store.

Our container-centric Actions, including those for Kubernetes and for interacting with a Docker registry, aren’t specific to Azure, and can be used with any Kubernetes cluster, including self-hosted ones, running on-premises or on other clouds, as well as any Docker registry.

Full example

Here is an example of an end-to-end workflow which builds a container image, pushes it to Container Registry and then deploys to an AKS cluster by using manifest files.

on: [push]

jobs:
build:
runs-on: ubuntu-latest
steps:
– uses: actions/checkout@master

– uses: azure/container-actions/docker-login@master
with:
login-server: contoso.azurecr.io
username: ${{ secrets.REGISTRY_USERNAME }}
password: ${{ secrets.REGISTRY_PASSWORD }}

– run: |
docker build . -t contoso.azurecr.io/k8sdemo:${{ github.sha }}
docker push contoso.azurecr.io/k8sdemo:${{ github.sha }}

# Set the target AKS cluster.
– uses: azure/k8s-actions/aks-set-context@master
with:
creds: '${{ secrets.AZURE_CREDENTIALS }}'
cluster-name: contoso
resource-group: contoso-rg

– uses: azure/k8s-actions/k8s-create-secret@master
with:
container-registry-url: contoso.azurecr.io
container-registry-username: ${{ secrets.REGISTRY_USERNAME }}
container-registry-password: ${{ secrets.REGISTRY_PASSWORD }}
secret-name: demo-k8s-secret

– uses: azure/k8s-actions/k8s-deploy@master
with:
manifests: |
manifests/deployment.yml
manifests/service.yml
images: |
demo.azurecr.io/k8sdemo:${{ github.sha }}
imagepullsecrets: |
demo-k8s-secret

More Azure Actions

Building on the momentum of GitHub Actions, today we are releasing this first Azure Actions in preview. In the next few months we will continue improving upon our available Actions, and we will release new ones to cover more Azure services.

Please try out the GitHub Actions for Azure and share your feedback via Twitter on @AzureDevOps, or using Developer Community. If you encounter a problem during the preview, please open an issue on the GitHub repository for the specific action.
Quelle: Azure

6 ways we’re making Azure reservations even more powerful

Our newest Azure reservations features can help you save more on your Azure costs, easily manage reservations, and create internal reports. Based on your feedback, we’ve added the following features to Azure reservations:

Azure Databricks pre-purchase plan
AppService Isolated Stamp Fee reservations
Ability to automatically renew reservations
Ability to scope reservations to resource group
Enhanced usage data to help with charge back, savings, and utilization
API to get prices and purchase reservations

Azure Databricks pre-purchase plans

You can now save up to 37 percent on your Azure Databricks costs when you pre-purchase Azure Databricks commit units (DBCU) for one or three years. Any Azure Databricks use deducts from the pre-purchased DBUCs automatically. You can use the pre-purchased DBCUs at any time during the purchase term.

See our documentation "Optimize Azure Databricks costs with a pre-purchase" to learn more, or purchase an Azure Databricks plan in the Azure portal.

AppService Isolated stamp fee reservations

Save up to 40 percent on your AppService Isolated stamp fee costs with AppService reserved capacity. After you purchase a reservation, the isolated stamp fee usage that matches the reservation is no longer charged at the on-demand rates. AppService workers are charged separately and don’t get reservation discount.

Visit our documentation "Prepay for Azure App Service Isolated Stamp Fee with reserved capacity" to learn more or purchase a reservation in the Azure portal.

Automatically renew your reservations

Now you can setup your reservations to renew automatically. This ensures that you keep getting the reservation discounts without any gaps. You can opt-in to automatically renew your reservations anytime during the term of the reservation and opt-out anytime. You can also update the renewal quantity to better align with any changes in your usage pattern. To setup automatic renewal, just go to any reservation that you’ve already purchased and click on the Renewal tab.

Scope reservation to resource group

You can now scope reservations to a resource group. This feature is helpful in scenarios where same subscription has deployments from multiple cost centers, represented by their respective resource groups, and the reservation is purchased for a particular cost center. This feature helps you narrow down the reservation application to a resource group making internal charge-back easier. You can scope a reservation to a resource group at the time of purchase or update the scope after purchase. If you delete or migrate a resource group then the reservation will have to be rescoped manually.

Learn more in our documentation "Scope reservations."

Enhanced usage data to help with charge back, savings, and utilization

Organizations rely on their enterprise agreement (EA) usage data to reconcile invoices, track usage, and charge back internally. We recently added more details to the EA usage data to make your reservation reporting easier. With these changes you can easily perform following tasks:

Get reservation purchase and refund charges
Know which resource consumed how many hours of a reservation and charge back data for the usage
Know how many hours of a reservation was not used
Amortize reservation costs
Calculate reservation savings

The new data files are available only through Azure portal and not through the EA portal. Besides the raw data, now you can also see reservations in Cost Analysis.

You can visit our documentation "Get Enterprise Agreement reservation costs and usage" to learn more.

Purchase using API

You can now purchase azure reservation using REST APIs. The APIs below will help you get the SKUs, calculate the cost, and then make the purchase:

Get SKUs
Calculate cost
Purchase

Quelle: Azure

Rapidly develop blockchain solutions, but avoid the complexities

After first emerging as the basis for the Bitcoin protocol, blockchain has since gained momentum as a way to digitize business processes that extend beyond the boundaries of a single organization. While digital currencies use the shared ledger to track transactions and balances, enterprises are coming together to use the ledger in a different way. Smart contracts—codified versions of paper based agreements—enable multiple organizations to agree on terms that must be met for a transaction to be considered valid, empowering automated verification and workflows on the blockchain.

These digitized business processes, governed by smart contracts and powered by the immutability of blockchain, are poised to deliver the scalable trust today’s enterprises need. One Microsoft partner, SIMBA Chain, has created an offering that reduces the effort and time to start creating solutions using blockchain technology.

The Azure platform offers a wealth of services for partners to enhance, extend, and build industry solutions. Here we describe how one Microsoft partner uses Azure to solve a unique problem.

Simplifying blockchain app development

SIMBA stands for SIMpler Blockchain Applications. SIMBA Chain is a cloud based, Smart Contract as a Service (SCaaS) platform, enabling users with a variety of skill sets to build decentralized applications (dApps) and deploy to either iOS or Android.

The figure below shows the platform and the components (such as the Django web framework) used to communicate to a dApp using a pub/sub model. SIMBA Chain auto-generates the smart contract and API keys for deployment, and the app can be deployed to a number of backends for mobile apps (such as Android and iOS.) Communication to participate in the blockchain occurs through an API generated from a smart contract.

With this platform, anyone with a powerful idea can build a decentralized application. SIMBA Chain supports Ethereum and will add more blockchain protocols to their platform.

A time-saving technology

SIMBA Chain’s user-friendly interface greatly reduces the time and custom code generation required to build and deploy a blockchain-based application. Users can create and model a business application, define the assets along with the smart contracts parameters, and in a few simple clicks the SIMBA platform generates an API which interfaces with the ledger. By reducing application development time, SIMBA enables faster prototyping, refinement, and deployment.

Recommended next steps

Go to the Azure Marketplace listing for SIMBA Chain and click Get It Now.

Learn more about Azure Blockchain Service.
Quelle: Azure

Building Resilient ExpressRoute Connectivity for Business Continuity and Disaster Recovery

As more and more organizations adopt Azure for their business-critical workloads, the connectivity between organizations’ on-premises networks and Microsoft becomes crucial. ExpressRoute provides the private connectivity between on-premises networks and Microsoft. By default, an ExpressRoute circuit provides redundant network connections to Microsoft backbone network and is designed for carrier grade high availability. However, the high availability of a network connectivity is as good as the robustness of the weakest link in its end-to-end path. Therefore, it is imperative that the customer and the service provider segments of ExpressRoute connectivity are also architected for high availability.

Designing for high availability with ExpressRoute addresses these design considerations and talks about how to architect a robust end-to-end ExpressRoute connectivity between a customer on-premises network and Microsoft network core. The document addresses how to maximize high availability of an ExpressRoute in general, as well as components specific to Private peering and to Microsoft peering.

Private Peering High Availability

Each component of the ExpressRoute connectivity is key to build for high availability, including the first mile from on-premises to peering location, from multiple circuits to the same virtual network (VNet), and the virtual network gateway within the VNet.

To improve the availability of ExpressRoute virtual network gateway, Azure offers Zone-redundant virtual network gateways utilizing Availability Zones. ExpressRoute also supports Bidirectional Forwarding Detection (BFD) to expedite link failure detection and thereby significantly improving Mean Time To Recover (MTTR) following a link failure.

Microsoft Peering High Availability

Further, where and how you implement Network Address Translation (NAT) impacts MTTR of Microsoft PaaS services (including O365) consumed over Microsoft Peering following a connection failure. Path selection between the Internet and ExpressRoute on Microsoft Peering is also imperative to ensure a highly reliable and scalable architecture.

ExpressRoute Disaster Recovery Strategy

How about architecting ExpressRoute connectivity for disaster recovery and business continuity? Would it be possible to optimize ExpressRoute circuits in different regions both for local connectivity and to act as a backup for another regional ExpressRoute failure?  In the following architecture, how do you ensure symmetrical cross-regional traffic flow either via Microsoft backbone or via the organization’s global connectivity (outside Microsoft)? Designing for disaster recovery with ExpressRoute private peering addresses these concerns and talks about how to architect for disaster recovery using ExpressRoute private peering.

Summary

To build a robust ExpressRoute circuit, end-to-end ExpressRoute connectivity should be architected for high availability that maximizes redundancy and minimizes MTTR following a failure. A robust ExpressRoute circuit can withstand many single-point failures. However, to safeguard against disasters that impact an entire peering location, your disaster recovery plans should include geo-redundant ExpressRoute circuits. Failing over to geo-redundant ExpressRoute circuits face challenges including asymmetrical routing. The following documents help you architect highly available ExpressRoute circuit and design for disaster recovery using geo-redundant ExpressRoute circuits.

Designing for high availability with ExpressRoute
Designing for disaster recovery with ExpressRoute private peering
What are Availability Zones in Azure?
About zone-redundant virtual network gateways in Azure Availability Zones
Path selection between the Internet and ExpressRoute
Configure BFD over ExpressRoute

Quelle: Azure