Azure IoT vs AWS IoT

This is why we recommend buying your infrastructure. All of it. Youre 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. Theyre 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.

For industrial equipment manufacturers intent on transforming their machines into connected product systems, a SaaS offering clearly wont do. You cant 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 elses 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?

At Hannover Messe 2018 we released an Azure IoT reference architecture for industrial genset monitoring and control. This flexible solution…

The Industrial IoT Pyramid of Configurability

Bright Wolf has 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) werent 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 werent 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 youre 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.

Whichever cloud platform you choose, youll still need to build infrastructure for taking advantage of their respective services. And youll 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, weve published afield guideto 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 youll need to deliver value to your customers from the very beginning.

Both Microsoft Azure and AWS provide secure data ingestion (Azure IoT HubandAWS 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 dont provide out of the box. Most critically, youll 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. Weve 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. Theres no value to your customers in your infrastructure, and the more resources you dedicate to building and maintaining it the less youll have for building differentiated products and services that your customers will want to buy over what your competitors are offering.

Thats 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 competitors 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?

Azure IoT in the Industrial World: A Reference System for Genset Management

Azure IoT in the Industrial World: A Reference System for Genset Management

A field guide describing the 5 approaches to industrial IoT platform development and how to know which approach is the…

If you come away from this article with just one lesson, its 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.

Once you have your infrastructure in place and outside of your responsibility (though still under your control), youll 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 weve seen teams make when assembling their own IoT application (or when theyve 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 arigid monolithrequiring 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 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.

A critical aspect of industrial connected product commercialization often overlooked by product teams is how the system will be customized…

These are some of the key lessons weve learned from helping Fortune 1000 enterprises deliver long-lived connected product systems. If youre an industrial equipment provider getting started on your digital transformation journey, we can help you avoid the traps and pitfalls ahead of you and deliver an initial pilot release in 4-6 weeks with a solid foundation and clear path to production. For those enterprises further along their way with an existing system thats not keeping up with their changing needs and customer demands, we can work with you on a system migration and transition plan. If your team is currently trapped in a 12-18-24 month infrastructure building exercise,lets talkabout how to get on track and focused on creating customer value instead. 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 solutionabovethe clouds.

The Industrial IoT Pyramid of Configurability

The Missing Field Guide to Industrial IoT Platform Development Choices

Leave a Comment