DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Refcards Trend Reports
Events Video Library
Refcards
Trend Reports

Events

View Events Video Library

Zones

Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks

How does AI transform chaos engineering from an experiment into a critical capability? Learn how to effectively operationalize the chaos.

Data quality isn't just a technical issue: It impacts an organization's compliance, operational efficiency, and customer satisfaction.

Are you a front-end or full-stack developer frustrated by front-end distractions? Learn to move forward with tooling and clear boundaries.

Developer Experience: Demand to support engineering teams has risen, and there is a shift from traditional DevOps to workflow improvements.

Related

  • Mitigate the Security Challenges of Telecom 5G IoT Microservice Pods Architecture Using Istio
  • IoT Interoperability Solutions With Software-Based Architecture
  • PHP Development in the Era of the Internet of Things (IoT)
  • The Internet of Things Costs Too Much

Trending

  • Understanding the 5 Levels of LeetCode to Crack Coding Interview
  • Your Kubernetes Survival Kit: Master Observability, Security, and Automation
  • Debunking LLM Intelligence: What's Really Happening Under the Hood?
  • Scrum Smarter, Not Louder: AI Prompts Every Developer Should Steal
  1. DZone
  2. Data Engineering
  3. Data
  4. Microservices Granularity for the Internet of Things

Microservices Granularity for the Internet of Things

There are a lot of parallels between the Internet Of Things and Microservices. One of the big battles in the design is the granularity of each service and the impact that can have on interdependency and network costs.

By 
Scott Lewis user avatar
Scott Lewis
·
Jun. 02, 16 · Opinion
Likes (1)
Comment
Save
Tweet
Share
4.8K Views

Join the DZone community and get the full member experience.

Join For Free

In a 2014 blog posting, Martin Fowler discussed issues around creating networked services in Microservices and the First Law of Distributed Objects. One of his points is that networked services should generally be more coarse-grained than local (in-process) services. The reason for this is that distribution always has costs (bandwidth, performance), and these costs easily can become large with fine-grained remote calls. 


But as Fowler points out, there are good reasons (e.g. complexity) to make a networked API as fine-grained as possible. How granular/coarse should IoT microservices be? In his blog posting, Fowler suggested that granularity was an open question and that experience with different systems with different levels of microservices granularity would provide eventual insight. I agree with Fowler's view that experience is necessary to decide on 'appropriate' granularity.   I think it's particularly true for the Internet of Things, where multiple people and organizations are attempting attempting to create consistent abstractions for the relatively limited input and output capabilities exposed by newly networked devices...aka 'things'. 

But when actually defining remote services, often the first thing done is to bind the service to a particular transport+protocol+impl framework (e.g. https+json+jersey). Once bound to a transport, the service API may become very difficult to refactor and version. This is especially true once a service has been deployed, but frequently deployment is the only way to get enough real experience to be more (or less) granular!

One way to provide flexibility...and allow future change to the granularity of a service is to remain from the beginning as transport-independent as possible. As described by this article, new standards such as OSGi Remote Services/RSA and ECF's modular implementation of these specs makes transport independence much easier for the microservices designer and developer. One consequence of using such an approach is that once sufficient experience has been gained, it will be much easier to refactor a microservice to be more or less granular. It does not guarantee that all microservices granularity changes will remain possible, but it does make it easier.
microservice IoT Internet (web browser)

Published at DZone with permission of Scott Lewis, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

Related

  • Mitigate the Security Challenges of Telecom 5G IoT Microservice Pods Architecture Using Istio
  • IoT Interoperability Solutions With Software-Based Architecture
  • PHP Development in the Era of the Internet of Things (IoT)
  • The Internet of Things Costs Too Much

Partner Resources

×

Comments

The likes didn't load as expected. Please refresh the page and try again.

ABOUT US

  • About DZone
  • Support and feedback
  • Community research
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Core Program
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 3343 Perimeter Hill Drive
  • Suite 100
  • Nashville, TN 37211
  • [email protected]

Let's be friends: