Azure IoT vs AWS IoT – Read Before Building your Industrial IoT Platform
We have been building industrial IoT systems since 2009. Back then, we worked with our customers to build almost every component needed at the edge and in the cloud. Microsoft Azure and Amazon Web Services (AWS) weren’t yet offering much more than compute, storage, and networking services – not that it mattered much as most customers were restricting deployments to on-premises (and weren’t even calling it IoT). Fast forward now almost a decade, and so much has happened since then. Both Microsoft and AWS are churning out service after service for enabling enterprises to embrace digital transformation through connected product systems at a pace bordering on the unbelievable. If you’re an industrial equipment manufacturer preparing to begin your journey from hardware vendor to a software-enabled, information driven enterprise, you have several critical choices to make.
Industrial IoT Platform Choices
Whichever cloud platform you choose, you’ll still need to build infrastructure for taking advantage of their respective services. And you’ll have to maintain and update that infrastructure on a regular basis as you add new asset and data types, and as various cloud services are upgraded, deprecated, and released. Alternately you can sign up for a SaaS platform that handles the cloud service orchestration and administration for you, at the expense of giving up control over your data and feature roadmap. To help you determine which approach makes sense for your particular goals, constraints, requirements, and business model, we’ve published a field guide to IoT platform development approaches. Whichever option you choose, we recommend selecting an approach aligned with the capabilities of your team, and providing the right level of control you’ll need to deliver value to your customers from the very beginning.
For industrial equipment manufacturers intent on transforming their machines into connected product systems, a SaaS offering clearly won’t do. You can’t move from selling pumps, chillers, and filters to providing gallons of fluid pumped or cleaned and hours or cycles of operation if you have to send your data to someone else’s system or wait for them to implement features in their platform that your customers need today. So what components will you need to build for yourself?
Secure and Scalable Infrastructure
Both Microsoft Azure and AWS provide secure data ingestion (Azure IoT Hub and AWS IoT Core, respectively) as well as storage and compute capabilities. Support for encryption, authentication, monitoring, and other platform services form a secure and scalable cloud infrastructure for enterprise applications. Newer services for device management and provisioning are also a big win. In many cases you can connect one of your things to the cloud and see some data on a dashboard without writing a lot of code. To move from a prototype to a customer pilot, and then to a production enterprise solution however requires additional components and capabilities that cloud vendors don’t provide ‘out of the box’. Most critically, you’ll need a flexible data management infrastructure for enabling higher level functionality in the application layer. These services include data normalization, policy enforcement, asset modeling, user roles, audit trails, and multi-tenancy. We’ve seen enterprises with large engineering teams spend 12-24 months on such architecture and development of their own IoT infrastructure on Azure and AWS, only to find themselves in a constant cycle of restructuring and rewriting large areas whenever new products are introduced or new features are required. There’s no value to your customers in your infrastructure, and the more resources you dedicate to building and maintaining it the less you’ll have for building differentiated products and services that your customers will want to buy over what your competitors are offering.
This is why we recommend buying your infrastructure. All of it. You’re already buying your ingest, storage, compute, encryption, monitoring, and other components. Data management, flexible user roles, asset modeling, and granular access control are in that same category. They’re all incredibly hard to get right at an enterprise level, require constant maintenance as technology advances and business models evolve, and are simply the scaffolding upon which you will create your unique business value.
Once you have your infrastructure in place and outside of your responsibility (though still under your control), you’ll need to write a lot of code for handling the 80% of complexity common to all IoT projects. User management, UI services and reporting engines, asset lifecycle, and alert management are examples of functionality that should exist your application layer. While the majority of features here may be used in most connected product systems, there is indeed customization required for enabling your specific customer scenarios. Our recommendation for the application layer is to start with pre-built functional code blocks developed and tested using best practices and real world experience, and modify them for your particular business context.
One big mistake we’ve seen teams make when assembling their own IoT application (or when they’ve hired a mobile app shop to build one for them from scratch) is not cleanly separating the application core and business logic from the user interface layer, creating a rigid monolith requiring changes to everything whenever you need to change anything. To avoid this headache, and for creating flexible systems and maintaining engineering agility, we recommend a purpose-built enterprise API for separating the core “digital product” from your user applications and enterprise IoT integrations. This API represents the digital boundary of your connected product, providing a consistent interface for customer-facing applications and integrations with your analytics, machine learning, AI, and enterprise CRM, ERP, and other systems. For many organizations, the layers below this API are owned by a central enterprise platform team, enabling each business unit to innovate independently above this stable boundary at their own pace. This architecture also creates an “open” system, enabling rapid integration with your choices of business applications and tools, including those running inside your customers’ operations without requiring changes to the core connected product.
If you come away from this article with just one lesson, it’s this: All of the value to be derived from your connected product systems, for both your organization and to your customers’ operations, comes from the applications and integrations that you build above this enterprise API boundary. Everything below this level is either foundational infrastructure required for any enterprise data solution, or functional blocks for enabling value to be extracted from data higher up the stack. No differentiation or competitive advantage occurs below the API beyond the fact that it needs to be reliable and secure. If you choose to have your own team build these lower layers for your production system, you can expect at least 12-24 months for delivery and a continuous maintenance responsibility. At that point, and with your remaining resources, you can then build applications and services to make use of the data collected for your customers.
That’s like a chef building their own restaurant from beams of wood and nails, fashioning their own appliances and utensils, and raising their own animals and vegetables so they can develop their recipes and cook the meals their customers have come to them for. True, this “invent it all here” approach may attract a few niche foodies looking for an “artisanal” dining experience. But what are the odds your industrial manufacturing customers will choose your welding machine over a competitor’s because you built your own Attribute-Based Access Control (ABAC) module? Or will it be because you guarantee uptime, provide real-time monitoring and visualizations, and integrate seamlessly with their existing enterprise workflows for optimizing yields?
Whether you choose Microsoft Azure IoT or AWS IoT for your connected product solution, your most important decision is the approach you take for developing your solution above the clouds.
Originally the article was published here.
This article was written by Marc Phillips, the Director of Marketing at Bright Wolf, a leading IoT technology provider and system integrator helping Fortune 1000 companies design, develop, and deploy Enterprise IoT systems and connected product solutions.