Streamlined development experience with Azure Blockchain Workbench 1.6.0

We’re happy to announce the release of Azure Blockchain Workbench 1.6.0. It includes new features such as application versioning, updated messaging, and streamlined smart contract development. You can deploy a new instance of Workbench through the Azure portal or upgrade existing deployments to 1.6.0 using our upgrade script.

Please note the breaking changes section, as the removal of the WorkbenchBase base class and the changes to the outbound messaging format will require modifications to your existing applications.

This update includes the following improvements:

Application versioning

One of the most popular feature requests from you all has been that you would like to have an easy way to manage and version your Workbench applications instead of having to manually change and update your applications as you are in the development process.

We’ve continued to improve the Workbench development story with support for application versioning with 1.6.0 via the web app as well as the REST API. You can upload new versions directly from the web application by clicking “Add version.” Note that if you have any changes in the application role name, the role assignment will not be carried over to the new version.

You can also view the application version history. To view and access older versions, select the application and click “version history” in the command bar. Note, that as of now by default older versions are read only. If you would like to interact with older versions, you can explicitly enable the previous versions.

New egress messaging API

Workbench provides many integration and extension points, including via a REST API and a messaging API. The REST API provides developers a way to integrate to blockchain applications. The messaging API is designed for system to system integrations.

In our previous release, we enabled more scenarios with a new input messaging API. In 1.6.0, we have implemented an enhanced and updated output messaging API which publishes blockchain events via Azure Event Grid and Azure Service Bus. This enables downstream consumers to take actions based on these events and messages such as, sending email notifications when there are updates on relevant contracts on the blockchain, or triggering events in existing enterprise resource planning (ERP) systems.

Here is an example of a contract information message with the new output messaging API. You’ll get the information about the block, a list of modifying transactions for the contract, as well as information about the contract itself such as contract ID and contract properties. You also get information on whether or not the contract was newly created or if a contract update occurred.

{
“blockId”: 123,
“blockhash”: “0x03a39411e25e25b47d0ec6433b73b488554a4a5f6b1a253e0ac8a200d13f70e3″,
“modifyingTransactions”: [
{
“transactionId”: 234,
“transactionHash”: “0x5c1fddea83bf19d719e52a935ec8620437a0a6bdaa00ecb7c3d852cf92e18bdd”,
“from”: “0xd85e7262dd96f3b8a48a8aaf3dcdda90f60dadb1″,
“to”: “0xf8559473b3c7197d59212b401f5a9f07b4299e29″
},
{
“transactionId”: 235,
“transactionHash”: “0xa4d9c95b581f299e41b8cc193dd742ef5a1d3a4ddf97bd11b80d123fec27506e”,
“from”: “0xd85e7262dd96f3b8a48a8aaf3dcdda90f60dadb1″,
“to”: “0xf8559473b3c7197d59212b401f5a9f07b4299e29″
}
],
“contractId”: 111,
“contractLedgerIdentifier”: “0xf8559473b3c7197d59212b401f5a9f07b4299e29″,
“contractProperties”: [
{
“workflowPropertyId”: 1,
“name”: “State”,
“value”: “0”
},
{
“workflowPropertyId”: 2,
“name”: “Description”,
“value”: “1969 Dodge Charger”
},
{
“workflowPropertyId”: 3,
“name”: “AskingPrice”,
“value”: “30000”
},
{
“workflowPropertyId”: 4,
“name”: “OfferPrice”,
“value”: “0”
},
{
“workflowPropertyId”: 5,
“name”: “InstanceOwner”,
“value”: “0x9a8DDaCa9B7488683A4d62d0817E965E8f248398″
},
],
“isNewContract”: false,
“connectionId”: 1,
“messageSchemaVersion”: “1.0.0”,
“messageName”: “ContractMessage”,
“additionalInformation”: {}
}

Read more about the newly designed messaging API in our documentation “Azure Blockchain Workbench messaging integration.” Note that this redesign of the output messaging model will impact existing integrations you have done.

WorkbenchBase class is no longer needed in contract code

For customers who have been using Workbench, you will know that there is a specific class that you need to include in your contract code, called WorkbenchBase. This class enabled Workbench to create and update your specified contract. When developing custom Workbench applications, you would also have to call functions defined in the WorkbenchBase class to notify Workbench that a contract had been created or updated.

With 1.6.0, this code serving the same purpose as WorkbenchBase will now be autogenerated for you when you upload your contract code. You will now have a more simplified experience when developing custom Workbench applications and will no longer have bugs or validation errors related to using WorkbenchBase. See our updated samples, which have WorkbenchBase removed.

This means that you no longer need to include the WorkbenchBase class nor any of the contract update and contract created functions defined in the class. To update your older Workbench applications to support this new version, you will need to change a few items in your contract code files:

Remove the WorkbenchBase class.
Remove calls to functions defined in the WorkbenchBase class (ContractCreated and ContractUpdated).

If you upload an application with WorkbenchBase included, you will get a validation error and will not be able to successfully upload until it is removed. For customers upgrading to 1.6.0 from an earlier version, your existing Workbench applications will be upgraded automatically for you. Once you start uploading new versions, they will need to be in the 1.6.0 format.

Get available updates directly from within Workbench

Whenever a Workbench update is released, we announce the updates via the Azure blog and post release notes in our GitHub. If you’re not actively monitoring these announcements, it can be difficult to figure out whether or not you are on the latest version of Workbench. You might be running into issues while developing which have already been fixed by our team with the latest release.

We have now added the capability to view information for the latest updates directly within the Workbench UI. If there is an update available, you will be able to view the changes available in the newest release and update directly from the UI.

Breaking changes in 1.6.0

WorkbenchBase related code generation: Before 1.6.0, the WorkbenchBase class was needed because it defined events indicating creation and update of Blockchain Workbench contracts. With this change, you no longer need to include it in your contract code file, as Workbench will automatically generate the code for you. Note that contracts containing WorkbenchBase in the Solidity code will be rejected when uploaded.

Updated outbound messaging API: Workbench has a messaging API for system to system integrations. We have had an outbound messaging API which has been redesigned. The new schema will impact the existing integration work you have done with the current messaging API. If you want to use the new messaging API you will need to update your integration specific code.

The name of the service bus queues and topics has been changed in this release. Any code that points to the service bus will need to be updated to work with Workbench version 1.6.0.

ingressQueue – the input queue on which request messages arrive.
egressTopic – the output queue on which update and information messages are sent.
The messages delivered in version 1.6.0 are in a different format. Existing code that interrogates the messages from the messaging API and takes action based on its content will need to be updated. You can read more about the newly designed messaging API in our documentation “Azure Blockchain Workbench messaging integration.”

Workbench application sample updates: All Workbench applications sample code are updated since we no longer need the WorkbenchBase class in contract code. If you are on an older version of Workbench and use the samples on GitHub, or vice versa, you will see errors. Upgrade to the latest version of Workbench if you want to use samples.

You can stay up to date on Azure Blockchain by following us on Twitter @MSFTBlockchain. Please use our Blockchain User Voice to provide feedback and suggest features/ideas for Workbench. Your input is helping make this a great service. We look forward to hearing from you.
Quelle: Azure

New Azure Migrate and Azure Site Recovery enhancements for cloud migration

We are continuously enhancing our offerings to help you in your digital transformation journey to the cloud. You can read more about these offerings in the blog, “Three reasons why Windows Server and SQL Server customers continue to choose Azure.” In this blog, we will go over some of the new features added to Microsoft Azure Migrate and Azure Site Recovery that will help you in your lift and shift migration journey to Azure.

Azure Migrate

Azure Migrate allows you to discover your on-premises environment and plan your migration to Azure. Based on popular demand, we have now enabled Azure Migrate in two new geographies, Azure Government and Europe. Support for other Azure geographies will be enabled in future.

Below is the list of regions within the Azure geographies where the discovery and assessment metadata is stored.

Geography
Region for metadata storage

United States
West Central US, East US

Europe
North Europe, West Europe

Azure Government
U.S. Gov Virginia

When you create a migration project in the Azure portal, the region for metadata storage is randomly selected. For example, if you create a project in the United States, we will automatically select the region as West Central US or East US. If you are specific about storing the metadata in a certain region in the geography, you can use our REST APIs to create the migration project and can specify the region accordingly in the API request.

Note, the geography selection does not restrict you from planning your migration for other Azure target regions. Azure Migrate allows you to specify more than 30 Azure target regions for migration planning. You can learn more by visiting our documentation, “Customize an assessment.”

Azure Site Recovery

Azure Site Recovery (ASR) helps you migrate your on-premises virtual machines (VMs) to IaaS VMs in Azure, this is the lift and shift migration. We are listening to your feedback and have recently made enhancements in ASR to make your migration journey even more smooth. Below is the list of enhancements recently done in ASR:

Support for physical servers with UEFI boot type: VMs with UEFI boot type are not supported in Azure. However, ASR allows you to migrate such on-premises Windows servers to Azure by converting the boot type of the on-premises servers to BIOS while migrating them. Previously, ASR supported conversion of boot type for only virtual machines. With the latest update, ASR now also supports migration of physical servers with UEFI boot type. The support is restricted to Windows machines only (Windows Server 2012 R2 and above).
Linux disk support: Previously, ASR had certain restrictions regarding directories in Linux machines, it required the directories such as /(root), /boot, /usr, and more to be on the same OS disk of the VM in order to migrate it. Additionally, it did not support VMs that had /boot on an LVM volume and not on a disk partition. With the latest update, ASR now supports directories in different disks and also supports /boot on an LVM volume. This essentially means, ASR allows migration of Linux VMs with LVM managed OS and data disks, and directories on multiple disks. You can learn more by visiting our documentation, “Support matrix for disaster recovery of VMware VMs and physical servers to Azure.”
Migration from anywhere: ASR helps you migrate any kind of server to Azure no matter where it runs, private cloud or public cloud. We are happy to announce that the guest OS coverage for AWS has now expanded, and ASR now supports the following operating systems for migration of AWS VMs to Azure.

Source
OS versions

AWS

RHEL 6.5+ New
RHEL 7.0+ New
CentOS 6.5+ New
CentOS 7.0+ New
Windows Server 2016
Windows Server 2012 R2
Windows Server 2012
64-bit version of Windows Server 2008 R2 SP1 or later

Learn more about how you can migrate from AWS to Azure in our documentation, “Migrate Amazon Web Services (AWS) VMs to Azure.”

VMware and physical servers
Get more details on the supported OS versions by reading our documentation, “Support matrix for disaster recovery of VMware VMs and Physical servers to Azure.”

Hyper-V
Guest OS agnostic

We are listening and continuously enhancing these services. If you have any feedback or have any ideas, do use our UserVoice forums for Azure Migrate and ASR and let us know.

If you are new to these tools, get started at the Azure Migration Center. Make sure you also start your journey right by taking the free Assessing and Planning for Azure Migration course offered by Microsoft.
Quelle: Azure

Cloud computing patents a major part of another record-breaking year for IBM

For the 26th year in a row, IBM led US companies in patents in 2018, with engineers, researchers, scientists and designers racking up a record 9,100 patents.
Of those, more than 2,000 were related to cloud computing, “including a patent on a specialized monitor for unikernel-based virtual machines that takes a lightweight approach to improving isolation and security between a cloud application and its host”, an IBM press release states. This work is related to IBM container security research and could help organizations more easily and securely move applications and data across cloud and on-premises environments.
Another patent combined analytics, IBM Cloud and Internet of Things (IoT) technology to help engineer “the world’s smartest lake”, New York’s Lake George. An intelligent system helps identify and monitor vertical temperature profiles and gradients, which affect marine life.
Other areas that contributed greatly to the patent total included AI, blockchain, quantum computing and security.
Those 9,100 patents are the result of the work of more than 8,500 IBM inventors from 47 different US states and in 48 different countries.
Learn more about IBM patent leadership.
The post Cloud computing patents a major part of another record-breaking year for IBM appeared first on Cloud computing news.
Quelle: Thoughts on Cloud

Combining Federation V2 and Istio Multicluster

In a previous post, we saw how to leverage Istio Multicluster to deploy an application (bookinfo) on multiple Red Hat OpenShift clusters and apply mesh policies on all of the deployed services. We also saw that the deployment process was relatively complex. In this post we are going to see how Federation V2 can help […]
The post Combining Federation V2 and Istio Multicluster appeared first on Red Hat OpenShift Blog.
Quelle: OpenShift

Automatically Update Red Hat Container Images on OpenShift 3.11

Red Hat OpenShift manages container images using a registry. This is the place where it caches upstream container images and stores the images from your own builds as well. Each build or container image correlates to an ImageStream, which is an object that defines any number of related images by tags. For example, one specific […]
The post Automatically Update Red Hat Container Images on OpenShift 3.11 appeared first on Red Hat OpenShift Blog.
Quelle: OpenShift