The transition of Microsoft Azure to a Kubernetes-based platform has given it an interesting capability that it’s slowly starting to turn into a competitive advantage: Azure is now portable.
We’re already seeing some aspects of that portability in Azure’s edge solutions, based on Azure Arc and Azure Stack, and in the abilities to push containerized Azure Cognitive Services to edge hardware and to run serverless functions outside the cloud. A portable cloud offers a great deal of flexibility, with cloud native development models scaling from single-board Raspberry Pi computers to global distributed systems running across multiple geographies.
At the same time, the scalable, portable cloud allows you the use the same APIs and SDKs everywhere you want them. It’s not entirely a “write once, run anywhere” solution, but you have a scalable, flexible, and composable environment that can be managed using familiar devops orchestration tools up and down the stack.
Now Microsoft is taking Azure into space. Azure Space is the wrapper for a range of different tools and technologies, from portable satellite ground stations to Azure Orbital Space, a development platform for space-based applications. For those of us who write code, it’s Azure Orbital Space that’s most interesting. Nearly a year after announcing it, Microsoft is keeping its Orbital Space SDK under close wraps; the SDK for building satellite-agnostic applications is available only through a private preview.
However, we can get a good idea of what it offers from the available public documentation and GitHub repositories. What’s clear is that, as expected, it builds on the same set of Azure technologies that Microsoft is using for its edge platform, treating satellites as simply another edge host. That means it should be very easy to take any existing Azure edge code and push it to space.
Computing at the edge of space
Applications run on a virtualized platform that provides common interfaces for communications, data, and sensors, with applications built in Visual Studio Code using familiar CI/CD pipelines and test frameworks. Once an application is built it can be uploaded to in-orbit hardware that supports containers and Dapr, the open-source distributed application runtime. This approach supports the development and sharing of templates for common space-borne applications, as well as the ability to do more data processing in a satellite.
For example, an earth-observing satellite could use container-hosted computer vision models to identify, say, wildfires in the images it captures. By identifying fire locations in orbit, the satellite could send only the relevant images and location data to the ground, instead of consuming limited bandwidth to send all of the imaging data to a ground station for processing. With Azure’s AI tools and edge capabilities at the heart of Microsoft’s AI for Earth program, existing earth resources applications and tools could be placed where they’re needed at minimal cost, giving developing countries access to valuable data.
Onboard intelligence based on these approaches is now powering a new generation of satellite hardware, somewhere between the low-cost cubesats with relatively simple sensors and a reliance on ground-based analytics, and the larger government operated earth resources imaging platforms. Here you’re working with hardware that’s designed for on-site compute, a mid-sized platform with higher resolution sensors. You can think of it as an edge data center in space.
Using Dapr for space applications
Another useful aspect of the Azure Orbital Space SDK is that it makes it simple to update space-borne software as required. Using Dapr as the deployment target ensures that code addresses a known set of APIs, and because Dapr runs as a container sidecar, your application container becomes your unit of deployment, consuming Dapr components as needed. Code can be built and tested on Earth, using a local set of virtualized satellite services, allowing code to be validated against the APIs before being uploaded to your satellite’s container host.
There’s one big advantage to running compute in space: reducing the cost of communications. Despite the ubiquity of space communications, it remains a significant part of your operational expenditure. Microsoft describes the Azure Orbital Space SDK as a “compute fabric” that lets applications run on the ground and in space, with the aim of providing a more resilient network. That’s one of the benefits of building on a cloud-native platform, as it’s designed to scale both up and out.
Working with satellite data
Naturally, for handling more complex processing tasks, you can bring your satellite data into the existing Azure data platform and work with geospatial and third-party GIS tools as well as Azure’s big data analytics tools in Microsoft Fabric. Azure Orbital Analytics provides a set of pre-defined data processing pipelines, as well as support for delivering data to common enterprise tooling, including the Power Platform.
The Azure Orbital tooling also includes ways to integrate downloaded data with GIS systems, using tools like Azure Maps to add the appropriate geographic layer to your data. By using Microsoft Fabric to transform data, you will be able to take imagery processed by in-satellite applications and export it to standard GIS formats for use in existing emergency service or aid applications, allowing you to deliver earth observation and resource data where it’s needed, when it’s needed.
Communicating with software-defined radio
Another interesting aspect of Microsoft’s Azure Space platform is its focus on communications. In addition to partnerships with various ground station and connectivity providers, with the aim of integrating satellite communications into Microsoft’s 5G private network offering, Azure Space offers tools for developing your own software-defined radio applications.
Building on well-known open source tools like Fosphor and GNU Radio, the Ubuntu-based Azure software radio developer VM gives you the tools necessary to build a software-defined radio that can integrate with Azure services as part of a radio flow, including support for delivering RF data to Azure Event Hubs. Using these tools, you can control radio hardware from the cloud and integrate Azure applications directly to downlink data from satellite applications.
The software radio developer VM takes the same approach as the rest of the Azure Space offering, which treats all aspects of satellite operations as a cloud-native programming service. As Microsoft continues to experiment with making Linux devices part of the Kubernetes environment, it’s possible to imagine future software-defined radio hardware being managed by containerized radio applications—both on the ground and in orbit.