Let me introduce you to Trust Architectures for applications that leverage connected devices. A reoccuring theme in my recent articles is that there is a lot to learn about the future of connected devices by looking back through the history of cloud-native development.
Why Service-Oriented Systems Rule Cloud Development
Over the past decade, cloud-native developers have embraced service-oriented design for their applications as “the rule.” Application Program Interfaces, APIs, and microservices are the most talked about implementations of these principles, and there are dozens of other developer tools and standards that we all use to build services.
As a quick review of service-oriented design, most narratives focus on highly flexible code functionality that is broken down into small components. These components make their functionalities discoverable and interoperable to other parts of the system. Such an architecture allows these microservices to be reused in the future via simple program interfaces (APIs).
Without such decomposition, scaling applications and adding new functionality to hard-coded applications with monolithic architectures becomes difficult, or even impossible. For example, an analytics microservice could be scaled-up with on-demand cloud hardware independently of the user sign-in service. Or, a new feature could access that analytics service without any changes to the existing service. This is how modern cloud-native apps are able to adapt so quickly.
Open source tools, cloud infrastructure, and a community of knowledge sharing have moved best practices forward for building modern and complex application systems with service architectures.
Applications Have Moved Into Hardware at the Edge, Creating New Challenges
Modern connected devices utilize standard APIs to communicate with supporting infrastructure, and the ones that don’t, should. However, the nature of connected devices at the edge leaves much to be desired in connected device architectures. Internet of Things (IoT) devices tend to be designed from the inside out, have a monolithic code base and are optimized for communicating with their manufacturer’s back-end web app (and not with others in highly proprietary ways).
Most connected devices are in physically insecure locations, scattered around the real world, outside of the cloud. As such, they’re susceptible to attacks by hostile actors. At the very least, it’s practically impossible for a system architect to understand the attack surface of devices with the same fidelity and trust that they do with applications built on infrastructure secured by cloud providers.
There is also an n-squared complexity with connected device integration as larger fleets of devices are installed in the field. For vast networks of interoperable systems to work together, they need more horsepower than service-oriented designs provide on their own.
Service-oriented systems are built for availability, interconnection
What Is a “Trust Architecture”? Why Do They Matter?
A “trust architecture” provides a framework that enables trusted data to flow through a service-oriented system. When a connected device is providing data to another system participant, it must go further than simply providing an endpoint to supply data, it must cryptographically prove its identity and cryptographically sign all data that it sends into the rest of the distributed system.
The only way for secure interoperability to exist among vast networks of connected devices is for devices to serve trusted data to their entire ecosystem as-a-service in a verifiable way. It’s the responsibility of devices to serve metadata that allows other services to reason about their trustworthiness ; that is a “trust architecture.”
Connecting Devices Requires a Trust Architecture
Just as application developers assume service-oriented design in their web apps, they now need to adopt trust architecture principles when building application stacks with connected devices. Only then can billions of connected devices safely scale to serve the applications that rely on their data. This is how autonomous systems in the future will be able to arrive at well-reasoned determinations of data trustworthiness in their ecosystems.