Gopalakrishnan M
07. April 2024 Categories: Technology,

In the last blog, we explored the monolithic and microservice architectures, the primary differences, and reasons for adapting microservice architecture in embedded domain. While there are numerous benefits such as ease of rolling out new features and less cross-functional impact due to fault isolation etc., there are some challenges associated with the Microservices at the Edge architecture. In this blog, we will touch upon a few challenges in this architecture and mitigation plans that could be adopted to overcome them. While this article covers the general aspects, the same can be applied to any specific embedded system irrespective of the domain/technology.

Scope of microservices in IoT Platform

In a typical IoT based computing architecture, there are 3 layers

  1. Edge device
  2. Edge Gateway
  3. Cloud
Microservices at the Edge

Microservices at the Edge


Cloud

This is the central system, where the data collection from various IoT devices, data enrichment, historical data management, data analytics are done. In many cases it provides data visualization to end users via mobile phone or social media etc. Since Cloud based IT systems are the pioneers in adopting microservices and our scope is more on embedded systems, we will not delve deeper here.

Edge Gateway

Mostly present to accumulate data from non-connected and legacy devices, the gateways are the cloud facing system. Typically, these are powerful processor-based systems directly interacting with the edge devices. In many cases, they have the capability for running complex algorithms and storing huge data etc. Another vital role that the gateways play is processing the data and running real-time analytics locally on the edge. By completing a part of the cloud application functionality, this saves time and data usage by not sending unwanted data to the cloud.

The Edge Gateway will be communicating to Edge devices via multiple interfaces such as GPIO, RS232, RS485, BLE, ZigBee etc. There is a possibility every interface can be a specific device meant for specific features such as Fire sensor, Water level, Wind power etc. So, in the monolith design, usually all these features are managed via threads and data sent to cloud for further processing. For even one single bug fix or new feature release, complete features in a system need to be reverified and that increases the testing iteration count and delays in rolling out the upgrades to the system in the field.

Edge Devices

Edge devices have a well-defined single job application like monitoring speed, temperature etc., and communicating the result to edge gateway via CAN, RS232, RS485, Automotive ethernet etc. While most of them run on a microcontroller-based resource constrained environment, there are powerful devices as well, those are based on micro-processor environment running complex data processing algorithms. In such designs, it is possible to migrate to a micro-services architecture.

One of main advantages in going for microservice architecture for edge devices and gateways is that each service can be made independently and it can be replaced or upgraded without impacting other features. This makes it easier for OEM and product owner to roll out new feature or bug fixes easily in short duration.

Challenges with embedded Microservices

With the basic premises about the potential places to deploy microservices at the edge, let us see a few challenges with embedded microservices.

Initial Design Complexity

When designing microservices, developers face a higher degree of complexity than when developing monolithic applications. This architecture poses a variety of challenges, some of which include deciding the functionality and size of each individual microservice, identifying the optimum boundaries between microservices, and integrating microservices with one another.

Failure Detection

Failure detection could be challenging, as the services are isolated, and a typical debugging approach is not possible. And new sources of faults could be introduced due to various factors such as microservice application, container, communication between container etc.

Communication complexities

Since all the services are standalone, communication among themselves gets complicated such as one to one, one to many, request response etc. Communication must be well designed to not fail and prevent disruption.

Testing

This can be more challenging, because after testing all individual services in a developer perspective, the complete system should be tested.

Resource constraints

As the services could be deployed easily, fine control needs to be done to the number of features getting added to the system in run time.

Processing Power

One of the major challenges with embedded microservices is that limited CPU and GPU resources can hinder the performance of new or upgraded microservices.

Memory

As each microservice is itself a standalone component, it has all its supporting elements such as executable environment etc. within its package. This increases the memory usage of flash and in turn limits the number of services that can be loaded into the system.

Mitigation Strategies for challenges with microservices

Resilience

Identifying the root cause of faults in embedded microservices can be challenging due to the distributed nature of microservices and the constraints of embedded systems. However, with a systematic approach, as given below, we can identify the root cause

  1. Logging – Having a dedicated logging service backed up by files.
  2. Monitoring & Metrics – Container CPU/RAM metrics and application VM/run time metrics can be monitored and recorded.
  3. Tracing - Tracing a request and response from all service in the log
  4. Version control - Service or feature dependency on versions of other dependent microservice can be documented clearly.

Communication protocols

The entire application use case should be identified in the beginning of project itself and a right protocol -that is simple and proven - must be adapted for inter services communication. Over-engineering will complicate the system for scalability and maintainability.

As edge devices typically have limited CPU, memory, and storage resources, it can restrict the ability to run multiple microservices and handle complex communication protocols. Lightweight communication protocols such as MQTT, CoAP, or gRPC can be adopted.

Managing communication among many edge devices can be complex, especially as the number of devices scales up. This can be addressed by following a hierarchical communication architecture, distributed communication framework and service discovery mechanism to dynamically identify/learn device feature and communicate.

Memory

To avoid running out of resources while adding features to a product in runtime. OEM must keep an eye on inactive services, and it has to be removed from the cloud or central system.

Testing

Versions and features mapping need to be documented clearly and updated for every release. Testers need to make sure that all microservices are running with the expected version before starting the versions. Additionally, testers need to have a list like the given below to make sure all field scenarios are addressed.

  • Possible combination of service list in a device
  • Possible combination of service versions in the field

While this increases the combinations of testing a microservices product, it ensures no unexpected scenario occurs in the field. For this, automation-based testing is recommended.

Conclusion

Rise of Edge computing brings both opportunities and challenges for microservice architectures. While offering scalability and flexibility, having microservices at the edge presents complexities like network variability, resource constraints, data consistency, and security vulnerabilities. Addressing these requires strategic testing, lightweight protocols, efficient resource management, and strong security practices. Utilizing tools for service discovery, dynamic routing, and edge orchestration can enhance reliability and streamline operations.

To fully leverage the potential of edge deployments, OEM must navigate these challenges effectively. By adopting the solutions outlined, organizations can achieve resilient, scalable, and secure microservice architectures. This paves the way for innovative applications and improved user experiences in the edge computing landscape, ensuring robust and efficient performance even in resource-constrained and distributed environments.

Subscribe to our Blog