Tag Archives: primary

Microsoft seeks broader developer appeal with Azure DevOps

Microsoft has rebranded its primary DevOps platform as Azure DevOps to reach beyond Windows developers or Visual Studio developers and appeal to those who just want a solid DevOps platform.

Azure DevOps encompasses five services that span the breadth of the development lifecycle. The services aim to help developers plan, build, test, deploy and collaborate to ship software faster and with higher quality. These services include the following:

  • Azure Pipelines is a CI/CD service.
  • Azure Repos offers source code hosting with version control.
  • Azure Boards provides project management with support for Agile development using Kanban boards and bug tracking.
  • Azure Artifacts is a package management system to store artifacts.
  • Azure Test Plans lets developers define, organize, and run test cases and report any issues through Azure Boards.

Microsoft customers wanted the company to break up the Visual Studio Team Services (VSTS) platform so they could choose individual services, said Jamie Cool, Microsoft’s program manager for Azure DevOps. By doing so, the company also hopes to attract a wider audience that includes Mac and Linux developers, as well as open source developers in general, who avoid Visual Studio, Microsoft’s flagship development tool set.

Open source software continues to achieve broad acceptance within the software industry. However, many developers don’t want to switch to Git source control and stay with VSTS for everything else. Over the past few years, Microsoft has technically separated some of its developer tool functions.

But the company has struggled to convince developers about Microsoft’s cross-platform capabilities and that they can pick and choose areas from Microsoft versus elsewhere, said Rockford Lhotka, CTO of Magenic, an IT services company in St. Louis Park, Minn.

Rockford Lhotka, CTO, MagenicRockford Lhotka

“The idea of a single vendor or single platform developer is probably gone at this point,” he said. “A Microsoft developer may use ASP.NET, but must also use JavaScript, Angular and a host of non-Microsoft tools, as well. Similarly, a Java developer may well be building the back-end services to support a Xamarin mobile app.”

Most developers build for a lot of different platforms and use a lot of different development languages and tools. However, the features of Azure DevOps will work for everyone, Lhotka said.

Azure DevOps is Microsoft’s latest embrace of open source development, from participation in open source development to integrating tools and languages outside its own ecosystem, said Mike Saccotelli, director of modern apps at SPR, a digital technology consulting firm in Chicago.

In addition to the rebranded Azure DevOps platform, Microsoft also plans to provide free CI/CD technology for any open source project, including unlimited compute on Azure, with the ability to run up to 10 jobs concurrently, Cool said. Microsoft has also made Azure Pipelines the first of the Azure DevOps services to be available on the GitHub Marketplace.

Bringing Device Support to Windows Server Containers

When we introduced containers to Windows with the release of Windows Server 2016, our primary goal was to support traditional server-oriented applications and workloads. As time has gone on, we’ve heard feedback from our users about how certain workloads need access to peripheral devices—a problem when you try to wrap those workloads in a container. We’re introducing support for select host device access from Windows Server containers, beginning in Insider Build 17735 (see table below).

We’ve contributed these changes back to the Open Containers Initiative (OCI) specification for Windows. We will be submitting changes to Docker to enable this functionality soon. Watch the video below for a simple example of this work in action (hint: maximize the video).

What’s Happening

To provide a simple demonstration of the workflow, we have a simple client application that listens on a COM port and reports incoming integer values (powershell console on the right). We did not have any devices on hand to speak over physical COM, so we ran the application inside of a VM and assigned the VM’s virtual COM port to the container. To mimic a COM device, an application was created to generate random integer values and send it over a named pipe to the VM’s virtual COM port (this is the powershell console on the left).

As we see in the video at the beginning, if we do not assign COM ports to our container, when the application runs in the container and tries to open a handle to the COM port, it fails with an IOException (because as far as the container knew, the COM port didn’t exist!). On our second run of the container, we assign the COM port to the container and the application successfully gets and prints out the incoming random ints generated by our app running on the host.

How It Works

Let’s look at how it will work in Docker. From a shell, a user will type:

docker run --device="/"

For example, if you wanted to pass a COM port to your container:

docker run --device="class/86E0D1E0-8089-11D0-9CE4-08003E301F73" mcr.microsoft.com/windowsservercore-insider:latest

The value we’re passing to the device argument is simple: it looks for an IdType and an Id. For this coming release of Windows , we only support an IdType of “class”. For Id, this is  a device interface class GUID. The values are delimited by a slash, “/”.  Whereas  in Linux a user assigns individual devices by specifying a file path in the “/dev/” namespace, in Windows we’re adding support for a user to specify an interface class, and all devices which identify as implementing this class   will be plumbed into the container.

If a user wants to specify multiple classes to assign to a container:

docker run --device="class/86E0D1E0-8089-11D0-9CE4-08003E301F73" --device="class/DCDE6AF9-6610-4285-828F-CAAF78C424CC" --device="…" mcr.microsoft.com/windowsservercore-insider:latest

What are the Limitations?

Process isolation only: We only support passing devices to containers running in process isolation; Hyper-V isolation is not supported, nor do we support host device access for Linux Containers on Windows (LCOW).

We support a distinct list of devices: In this release, we targeted enabling a specific set of features and a specific set of host device classes. We’re starting with simple buses. The complete list that we currently support  is  below.

Device Type Interface Class  GUID
GPIO 916EF1CB-8426-468D-A6F7-9AE8076881B3
I2C Bus A11EE3C6-8421-4202-A3E7-B91FF90188E4
COM Port 86E0D1E0-8089-11D0-9CE4-08003E301F73
SPI Bus DCDE6AF9-6610-4285-828F-CAAF78C424CC

Stay tuned for a Part 2 of this blog that explores the architectural decisions we chose to make in Windows to add this support.

What’s Next?

We’re eager to get your feedback. What specific devices are most interesting for you and what workload would you hope to accomplish with them? Are there other ways you’d like to be able to access devices in containers? Leave a comment below or feel free to tweet at me.

Cheers,

Craig Wilhite (@CraigWilhite)