https://unsplash.com/photos/BJHN6Do8kjQ

As you know, I’ve been working more with IoT edge use cases around my career. It was going fine with Azure to date, but when we were re-analyzing the architecture, we found a need for cloud-agnostic microservices instead of cloud-native microservices (more precisely with Azure). So I just wanted to share some thoughts around the same.

💡 In case you’re unfamiliar with the concept of microservices, you can read more about it here, and here.

Cloud-Native Microservices

Let's start with a basic ingestion microservice which we built for an IoT platform using azure as our cloud provider and .net C# as our primary programming platform.

Here in this example, we are having a limited capability edge device that receives sensor readings from multiple sensors. Then the same will be up-streamed to the cloud. IoT Hub will act as the ingestion entry point and then it will be routed to event hubs based on the routing. Further Azure functions will process the same and persist in the database or pass on to other event hubs for further chained process.

Pain points

Now let's consider the pain points, when we plan to move the same to any other cloud provider, we have to change all the ingestion and components to match with the provider. In this case, if we are moving to AWS, we need to change the services like IoT Hub, Event Hub Azure function to AWS-specific services and the same will need time and effort again to move the same.

I agree that this will not happen very frequently and we need to spend time and effort if there is any strategic initiative to move from one to other. But let’s consider another scenario.

Now in this case, if we receive a new Edge Device, which is more capable compared to the older one, and we want to move some of the cloud services to edge to reduce latency and improve the Time-To-Respond time, let’s look at how we can do the same.

When using the Azure IoT Edge components, still we will face some challenges as, the services like IoT Hub, Event Hub and Azure Function is only available in the cloud (there are some initiatives from Microsoft to enable an Azure function in Edge, but let’s consider this as a constraint for the time being). Now we see that the services will become a constraint for us, this will also become applicable if we are also planning to move the same to a Kubernetes environment.

your cloud processing

your cloud processing becomes a lock for you

In that case, we need to move our components with additional changes to make them run on edge. So it’s time to think if any alternatives are available to achieve the same.

Cloud-Agnostic Microservice

In this approach, we will be using only services from the “Cloud Native Cloud Foundation” which will be available across the cloud services and we will not going to use cloud vender specific services. Let’s see how the previous image can be re-drawn to accommodate it as a cloud-agnostic one.

Here in this architecture, we will be using only cloud-agnostic platforms or services to design the process.

Now it may look very simple to move to another queue but what will happen to other services, or what if we don't have MQTT available at the edge?

Yes, so we should design our application with more capabilities and the ability to switch between the connectors so that it can switch on an ad-hoc basis or environment basis with the same processing service.

Here we will be using “Distributed Application Runtime (DAPR)” This will help us in enabling the processing application to connect to multiple services based on the configurations. am not covering the implementation steps of the DAPR, you can find the same on their website.

Here in this example, we are writing our application using DAPR and thus it gives us more flexibility to switch between the services without affecting the processing logic.

In this example, we are mentioning only the queuing mechanism in the spotlight, we will be using the pub/sub provider of the DAPR, thus we will be creating our implementation or service as per DAPR, then we can switch the pub/sub provider with any supported provider of DAPR, as provided in this image. It ranges from services like Mosquito, Azure Service Bus, GCP Pub/Sub and many more. You also have the flexibility to create your own if needed.

Similarly, we can also switch between other services for the secret store, and observability. As an extended version, we can implement the Entity framework which will give a similar capability for the database. Thus, we will remain isolated from cloud-specific services.

Now we have changed our processing with more features, and now we can easily switch between edge/cloud or environments with very minimal effort.

Conclusion

Now you may get some more light shed onto your cloud-agnostic microservice journey. Let’s explore more on the same and choose the same based on the analysis and available services. We can also look at this approach and develop the services in this fashion also without using DAPR.

Keep coding, and share your views on the same! :)

From monolithic to composable software with Bit

Bit’s open-source tool help 250,000+ devs to build apps with components.

Turn any UI, feature, or page into a reusable component — and share it across your applications. It’s easier to collaborate and build faster.

→ Learn more

Split apps into components to make app development easier, and enjoy the best experience for the workflows you want:

→ Micro-Frontends

→ Design System

→ Code-Sharing and reuse

→ Monorepo