Cloud Integration: On-Premise vs. Public Cloud
A detailed comparison of deployment options for IoT systems, including cost analysis, security considerations, and decision frameworks.
Introduction
The choice between public cloud and on-premise deployment is one of the most consequential decisions in IoT system design. It affects not only your technical architecture but also your business model, operational costs, security posture, and ability to scale. There is no universal “right” answer—the optimal choice depends on your specific requirements for data sensitivity, budget, technical expertise, regulatory compliance, and connectivity.
This article provides a comprehensive comparison of public cloud and on-premise deployment for IoT systems, covering advantages, disadvantages, cost structures, security considerations, and decision frameworks. We’ll also explore hybrid approaches and examine how the N3xar platform supports all deployment models.
1. Overview: The Decision Landscape
1.1 The Core Question
At its heart, the cloud vs. on-premise decision comes down to trade-offs:
┌─────────────────────────────────────────────────────────────────┐ │ The Deployment Decision │ ├─────────────────────────────────────────────────────────────────┤ │ │ │ Public Cloud On-Premise (Self-Hosted) │ │ ──────────── ──────────────────────── │ │ ✓ No infrastructure management ✓ Full data control │ │ ✓ Scalability on demand ✓ No recurring fees │ │ ✓ Global availability ✓ Complete security control │ │ ✓ Pay-as-you-grow ✓ Offline operation │ │ ✓ Managed services ✓ Full customisation │ │ │ │ ✗ Recurring costs ✗ High initial cost │ │ ✗ Vendor lock-in ✗ Technical expertise needed │ │ ✗ Limited data control ✗ Maintenance burden │ │ ✗ Internet dependency ✗ Scaling complexity │ │ │ └─────────────────────────────────────────────────────────────────┘
1.2 Why This Decision Matters
The deployment model you choose affects:
| Aspect | Impact |
|---|---|
| Capital expenditure | Cloud is OPEX; on-premise is CAPEX |
| Operational costs | Cloud has ongoing per-device fees; on-premise has fixed costs |
| Data sovereignty | Cloud data may cross borders; on-premise data stays local |
| Security | Cloud security is provider-managed; on-premise is self-managed |
| Scalability | Cloud scales automatically; on-premise requires planning |
| Maintenance | Cloud is provider-managed; on-premise is self-managed |
| Integration | Cloud integrates with other services; on-premise integrates with legacy systems |
| Compliance | Cloud depends on provider certifications; on-premise gives full control |
2. Public Cloud Deployment
2.1 What Is Public Cloud IoT?
Public cloud deployment means running your IoT backend on infrastructure provided by a third-party cloud provider such as:
| Provider | Key IoT Services |
|---|---|
| Amazon Web Services (AWS) | AWS IoT Core, Greengrass, Timestream, SageMaker |
| Microsoft Azure | Azure IoT Hub, IoT Edge, Time Series Insights, ML |
| Google Cloud Platform (GCP) | Cloud IoT Core, Edge TPU, BigQuery, AI Platform |
| IBM Cloud | Watson IoT Platform, Analytics, Blockchain |
| Oracle Cloud | IoT Cloud, Integration, Analytics |
2.2 Advantages
1. No Infrastructure Management
Description: You don’t need to procure, configure, or maintain any hardware or infrastructure software.
Benefits:
- Focus on application logic – development teams focus on features
- No hardware procurement – no capital expenditure for servers
- No maintenance windows – provider handles updates and patches
- No facility costs – no data centre space, power, cooling
Example: A startup with 50 sensors can deploy on AWS IoT Core without buying any hardware—they simply configure services and start ingesting data.
2. Scalability on Demand
Description: Infrastructure scales automatically (or with minimal configuration) as your device count grows.
Benefits:
- Elastic capacity – resources grow with demand
- No capacity planning – don’t need to predict growth years in advance
- Auto-scaling – services scale up and down automatically
- Global scale – deploy in multiple regions for low-latency access
Example: A smart city project grows from 1,000 to 10,000 sensors over two years. The cloud platform scales without any manual intervention.
3. Global Availability
Description: Cloud providers have data centres worldwide, enabling global deployments.
Benefits:
- Multi-region deployment – choose regions closest to devices
- High availability – built-in redundancy and failover
- Content Delivery Networks (CDN) – fast global asset delivery
- Disaster recovery – automated backup and geographic redundancy
Example: A multinational corporation deploys its IoT platform in AWS regions in North America, Europe, and Asia-Pacific, ensuring low latency for all devices.
4. Managed Services
Description: Cloud providers offer fully managed services that eliminate operational burden.
Benefits:
- Managed databases – automated backup, replication, patching
- Managed messaging – MQTT brokers, Kafka, message queues
- Managed analytics – stream processing, data warehousing, ML
- Managed security – DDoS protection, identity management, encryption
Example: Using AWS IoT Core provides a managed MQTT broker, device registry, and rules engine—no need to install or maintain Mosquitto.
5. Pay-as-You-Grow
Description: Costs scale with usage, avoiding large upfront investments.
Benefits:
- Low initial cost – no minimum spend, free tiers available
- Variable costs – pay only for what you use
- Predictable OPEX – monthly billing with usage reports
- No waste – don’t pay for unused capacity
Example: A startup pays $0.10 per million messages in the early stage, scaling to $100/month as they grow.
6. Integration with Cloud Services
Description: Seamless integration with a vast ecosystem of cloud services.
Benefits:
- AI/ML services – SageMaker, Azure ML, Vertex AI
- Analytics – BigQuery, Athena, Redshift, Power BI
- Serverless – Lambda, Functions, Cloud Run
- CI/CD – CodePipeline, DevOps, Cloud Build
Example: A predictive maintenance system uses AWS IoT Core for ingestion, SageMaker for model training, and QuickSight for dashboards.
2.3 Disadvantages
1. Recurring Costs
Description: Costs are ongoing and can become significant at scale.
| Cost Component | Description |
|---|---|
| Device connection | Per-device monthly fees |
| Message ingestion | Per-message fees (typically $0.10-$1.00 per million messages) |
| Data storage | Per-GB storage fees (time-series data can grow quickly) |
| Data transfer | Egress fees (sending data out of the cloud) |
| Compute | Per-hour fees for processing |
| API calls | Per-request fees |
Example: A deployment with 10,000 devices sending 100 messages per day could cost $100-$500/month just for message ingestion, plus storage and compute.
2. Vendor Lock-in
Description: Once you’re deeply integrated with a cloud provider, migrating is difficult and costly.
| Lock-in Type | Description |
|---|---|
| API lock-in | Proprietary APIs that don’t translate to other providers |
| Data lock-in | Data stored in proprietary formats |
| Service lock-in | Using managed services with no equivalent elsewhere |
| Cultural lock-in | Team expertise becomes provider-specific |
Example: A company using AWS IoT Core’s rules engine, Greengrass, and DynamoDB would need significant rework to migrate to Azure.
3. Limited Data Control
Description: Data resides on third-party infrastructure with limited control over its location and processing.
Concerns:
- Data residency – may not know exactly where data is stored
- Data sovereignty – may not comply with local data laws
- Data access – limited visibility into who can access data
- Data lifecycle – limited control over data retention and deletion
Example: A European company with GDPR requirements must ensure data stays within the EU—which is possible but requires careful configuration.
4. Internet Dependency
Description: All data must flow through the cloud provider’s infrastructure.
Concerns:
- No offline operation – devices can’t function if connectivity is lost
- Latency – dependent on network conditions
- Outages – provider outages affect all connected devices
- Bandwidth costs – transferring large amounts of data costs money
Example: A remote mining site with intermittent satellite connectivity may struggle with cloud-only architecture.
5. Security Dependence
Description: Security relies on the cloud provider’s practices and configurations.
Concerns:
- Shared infrastructure – theoretical risk from other tenants
- Limited visibility – can’t audit all security practices
- Incident response – depends on provider’s response times
- Regulatory compliance – depends on provider’s certifications
Example: A healthcare company must ensure its cloud provider has HIPAA-compliant configurations and agreements.
3. On-Premise (Self-Hosted) Deployment
3.1 What Is On-Premise IoT?
On-premise deployment means running your IoT backend on infrastructure you own and manage—physical servers, private cloud, VPS instances, or on-premise data centres that you control completely.
3.2 Advantages
1. Data Sovereignty
Description: Full control over where data is stored and how it is processed.
Benefits:
- Data residency – keep data within specific geographic boundaries
- Legal compliance – meet local data protection laws (GDPR, CCPA, etc.)
- No third-party access – data never leaves your infrastructure
- Full auditability – complete control over data access logs
Example: A government agency deploying IoT sensors in a secure facility can keep all data within the facility’s network.
2. No Ongoing Costs
Description: No per-device or data transfer fees; costs are fixed.
Benefits:
- Fixed costs – once infrastructure is purchased, costs are predictable
- No per-device fees – scaling doesn’t increase fees
- Cost control – no surprise charges for data usage
- Economies of scale – cost per device decreases as fleet grows
Example: A company with 10,000 sensors pays the same infrastructure cost regardless of data volume, unlike cloud where each message incurs a fee.
3. Complete Security Control
Description: You control security measures end-to-end.
Benefits:
- Physical security – control access to servers
- Network security – firewall rules, VPNs, air-gapping
- Security policies – implement your own standards
- Incident response – full control over investigation and remediation
Example: A defence contractor with classified data implements multiple layers of physical and network security.
4. Offline Operation
Description: System functions without internet connectivity.
Benefits:
- Local processing – data stays within the local network
- No internet dependency – continues operating during outages
- Reduced latency – faster response times locally
- Store-and-forward – cache data when connectivity is lost
Example: A remote mining operation with unreliable internet maintains monitoring and control even when satellite connection is lost.
5. Customisation
Description: Full flexibility for specific requirements.
Benefits:
- Custom integrations – connect to legacy systems
- Modified features – adapt platform to specific needs
- UI branding – full control over look and feel
- Custom security – implement specific authentication and authorisation
Example: A hospital integrates its IoT platform with an existing electronic health record system.
6. Predictable Performance
Description: Resources are dedicated, ensuring consistent performance.
Benefits:
- No noisy neighbours – no sharing with other tenants
- Predictable latency – dedicated network paths
- Consistent throughput – no surprises from other workloads
Example: A factory control system requires deterministic response times—on-premise ensures no variability from shared infrastructure.
3.3 Disadvantages
1. High Initial Cost
Description: Significant capital expenditure for hardware and setup.
| Cost Component | Description |
|---|---|
| Hardware | Servers, storage, networking equipment |
| Licensing | Software licenses for operating systems, databases, etc. |
| Setup | Installation, configuration, and testing |
| Facilities | Data centre space, power, cooling, security |
Example: A modest deployment of 5 servers, 50TB storage, and networking could cost $50,000-$100,000 upfront.
2. Technical Expertise Required
Description: In-house skills needed for all aspects of infrastructure.
| Skill Area | Description |
|---|---|
| Hardware | Server procurement, assembly, racking |
| Networking | Routing, switching, firewalls, VPNs |
| Operating Systems | Installation, configuration, patching |
| Database Administration | Installation, configuration, backup, replication |
| Security | Firewalls, IDS/IPS, access control, compliance |
Example: A company must hire or contract DevOps, database administrators, and network engineers.
3. Maintenance Burden
Description: All updates, patches, and maintenance are your responsibility.
| Task | Description |
|---|---|
| OS updates | Security patches, version upgrades |
| Database maintenance | Indexing, backup, replication management |
| Hardware replacement | Failed components, upgrades |
| Security monitoring | Intrusion detection, log analysis |
| Compliance | Regular audits, documentation |
Example: A company must schedule maintenance windows for security patches, which may cause downtime.
4. Scaling Complexity
Description: Scaling requires planning, procurement, and implementation.
Challenges:
- Hardware procurement – lead time for servers and storage
- Capacity planning – must predict growth accurately
- Vertical scaling – upgrading existing hardware (replacement cycle)
- Horizontal scaling – adding more servers (load balancing, clustering)
Example: A company growing from 500 to 5,000 sensors must plan hardware upgrades months in advance.
5. Limited Disaster Recovery
Description: Disaster recovery requires duplicate infrastructure and manual failover.
Challenges:
- Secondary site – need a second location for recovery
- Data replication – copy data to secondary site
- Manual failover – complex procedures for switching
- Testing – regular recovery testing is expensive
Example: A company must maintain a duplicate data centre for disaster recovery, doubling costs.
4. Hybrid Approach
4.1 What Is Hybrid IoT?
Hybrid deployment combines cloud and on-premise, keeping sensitive data and critical operations on-premise while leveraging cloud for scalability, analytics, and global access.
4.2 Common Hybrid Patterns
Pattern 1: Edge + Cloud
┌─────────────────┐ ┌─────────────────┐ ┌─────────────────┐ │ │ │ │ │ │ │ On-Premise │────│ Edge Gateway │────│ Cloud │ │ (Data Source) │ │ (Processing) │ │ (Analytics) │ │ │ │ │ │ │ └─────────────────┘ └─────────────────┘ └─────────────────┘
Description: Edge gateways process data locally and send only aggregated/anonymized data to the cloud.
Example: A retail chain processes customer data at each store (on-premise) and sends aggregated sales and occupancy data to cloud for chain-wide analytics.
Pattern 2: Core + Analytics
┌─────────────────────────────────┐ ┌─────────────────────────────────┐ │ │ │ │ │ On-Premise │ │ Cloud │ │ (Core IoT Platform) │ │ (Analytics & AI) │ │ │ │ │ └─────────────────────────────────┘ └─────────────────────────────────┘
Description: Core IoT platform (device management, control, data storage) stays on-premise, while analytics and AI are in the cloud.
Example: A manufacturing plant runs its control system on-premise for low-latency response, while using cloud for predictive maintenance models.
Pattern 3: Development + Production
┌─────────────────┐ ┌─────────────────────────────────┐ │ │ │ │ │ Cloud │ │ On-Premise │ │ (Development) │ │ (Production) │ │ │ │ │ └─────────────────┘ └─────────────────────────────────┘
Description: Development and testing in the cloud, production on-premise.
Example: A company develops and tests its IoT platform on AWS, then deploys the production version on-premise for the client.
4.3 Advantages
| Advantage | Description |
|---|---|
| Best of both worlds | Control of on-premise with scalability of cloud |
| Risk management | Critical systems remain under your control |
| Cost optimization | Pay for cloud only when it adds value |
| Compliance | Meet regulatory requirements for sensitive data |
| Flexibility | Adapt to changing needs over time |
| Resilience | Edge continues when cloud is unavailable |
4.4 Disadvantages
| Disadvantage | Description |
|---|---|
| Complexity | More systems to manage and integrate |
| Integration overhead | Need to keep cloud and on-premise in sync |
| Cost | Both infrastructure and cloud costs |
| Skills | Need expertise in both cloud and on-premise |
| Consistency | Ensuring consistent configuration across environments |
4.5 N3xar’s Hybrid Implementation
The N3xar platform supports hybrid deployment with:
- Self-hosted Docker deployment – run the complete platform on-premise
- Cloud-based data storage and visualization – optional cloud services for analytics and dashboards
- Secure API – integration between on-premise and cloud components
- Flexible configuration – choose which components run where
“The platform supports both Docker/cloud deployment anywhere and offers custom development for enterprise clients, including branded user interfaces and business rules.”
5. Decision Framework
5.1 Key Decision Factors
| Factor | Questions to Ask |
|---|---|
| Data Sensitivity | Is the data confidential? Does it fall under regulations? |
| Budget | Do you prefer CAPEX or OPEX? What is your total budget? |
| Technical Expertise | Do you have in-house DevOps skills? |
| Internet Reliability | Is your internet connection stable and fast? |
| Scale | How many devices now? In 3 years? 5 years? |
| Compliance | What regulations apply to your data? |
| Latency | How fast must you respond to events? |
| Disaster Recovery | What is your RTO/RPO requirement? |
| Customisation | Do you need custom integrations or features? |
| Integration | Does the system need to connect to existing on-premise systems? |
5.2 Decision Matrix
| Factor | Choose Cloud | Choose On-Premise | Choose Hybrid |
|---|---|---|---|
| Data Sensitivity | Low to medium | High | High for sensitive data, low for others |
| Budget | OPEX preferred | CAPEX preferred | Flexible |
| Technical Expertise | Limited | Available | Available |
| Internet Reliability | Good | Poor | Variable |
| Scale | Growing rapidly | Stable | Growing |
| Compliance | Standard | Strict | Mix |
| Latency Requirements | Moderate | Critical | Critical for local operations |
| Disaster Recovery | Provider-managed | Self-managed | Mix |
5.3 Weighted Scoring Model
Use this scoring model to evaluate your options:
Step 1: Assign weights (1-5) to each factor based on importance Step 2: Score each deployment option (1-5) for each factor Step 3: Calculate weighted score = weight × score Step 4: Sum scores for each option
Example:
| Factor | Weight | Cloud Score | On-Prem Score | Hybrid Score |
|---|---|---|---|---|
| Data Sensitivity | 5 | 2 | 5 | 5 |
| Budget | 4 | 5 | 3 | 4 |
| Technical Expertise | 4 | 5 | 2 | 3 |
| Internet Reliability | 3 | 5 | 4 | 5 |
| Scale | 3 | 5 | 3 | 4 |
| Compliance | 5 | 3 | 5 | 5 |
| Latency | 3 | 3 | 5 | 5 |
| Total | 78 | 86 | 94 |
5.4 Decision Flowchart
Start → Is your data highly sensitive or regulated?
├── Yes → Can you trust the cloud provider's security?
│ ├── Yes → Hybrid (cloud for non-sensitive)
│ └── No → On-Premise
└── No → Is your internet connection reliable?
├── Yes → Do you have technical expertise?
│ ├── Yes → Cloud or Hybrid
│ └── No → Cloud
└── No → Is offline operation critical?
├── Yes → On-Premise
└── No → Hybrid
6. Cost Comparison
6.1 Cloud Cost Model
Cost components:
Monthly Cloud Cost = (Device Connection × Count)
+ (Message Ingest × Volume)
+ (Data Storage × GB)
+ (Data Transfer × GB)
+ (Compute × Hours)
+ (API Calls × Count)
Example (10,000 devices, 100 messages/day, 1GB storage/month):
- Device connection: $0.10/month × 10,000 = $1,000
- Message ingest: $0.50/million × 30 million = $15
- Storage: $0.25/GB × 1,000GB = $250
- Data transfer: $0.09/GB × 100GB = $9
- Compute: $0.10/hour × 720 hours = $72
- Total: ~$1,350/month = ~$16,200/year
6.2 On-Premise Cost Model
Cost components:
Initial Capital = Hardware + Licensing + Setup + Facilities Ongoing Costs = Maintenance + Staff + Power + Cooling + Support
Example (5 servers, 50TB storage, 3-year lifecycle):
- Initial: Servers ($30,000) + Storage ($10,000) + Networking ($5,000) + Setup ($10,000) = $55,000
- Annual: Maintenance ($5,000) + Staff ($60,000) + Power/Cooling ($3,000) = $68,000/year
- 3-Year Total: $55,000 + $204,000 = $259,000
6.3 Hybrid Cost Model
Cost components:
Hybrid Cost = On-Premise Base + Cloud Variable
Example (on-premise for control, cloud for analytics):
- On-premise base: $20,000 initial + $40,000/year
- Cloud analytics: $200/month = $2,400/year
- 3-Year Total: $20,000 + $120,000 + $7,200 = $147,200
6.4 Break-Even Analysis
Formula:
Break-Even Point (months) = (On-Premise CAPEX - Cloud Setup) / (Cloud Monthly Cost - On-Premise Monthly OPEX)
Example:
- Cloud setup: $0
- Cloud monthly: $1,350
- On-premise setup: $55,000
- On-premise monthly: $5,667 (staff + maintenance)
- Break-even = ($55,000 - $0) / ($1,350 - $5,667) = Negative (on-premise is never cheaper if staff costs are considered)
Note: Break-even depends heavily on staff costs. With no additional staff (self-managed by existing team), on-premise can break even in 10-20 months.
7. Security Considerations
7.1 Cloud Security
| Aspect | Cloud Provider’s Role | Your Role |
|---|---|---|
| Physical security | Provider managed | None |
| Network security | Provider managed | Configure VPC, firewalls |
| Data encryption (in transit) | Provider managed | Enable TLS/SSL |
| Data encryption (at rest) | Provider managed | Configure encryption settings |
| Identity and access | Provider managed | Configure IAM, roles |
| Compliance certifications | Provider managed | Choose compliant regions/services |
| Security monitoring | Provider managed | Configure logging, alerts |
| Incident response | Provider managed | Coordinate with provider |
Example: AWS IoT Core provides encryption at rest, TLS in transit, IAM for access control, and SOC2 compliance.
7.2 On-Premise Security
| Aspect | Your Responsibility |
|---|---|
| Physical security | Full—access control, cameras, secure facility |
| Network security | Full—firewalls, switches, VPNs, segmentation |
| Data encryption | Full—implement and manage |
| Identity and access | Full—AD/LDAP, access control, MFA |
| Compliance | Full—audit, documentation, controls |
| Security monitoring | Full—SIEM, intrusion detection, log analysis |
| Incident response | Full—team, procedures, drills |
Example: A government agency implements multiple layers of physical and network security with no third-party access.
7.3 Hybrid Security
| Layer | Security Approach |
|---|---|
| Edge | Local encryption, authentication, access control |
| On-premise core | Complete security control |
| Cloud analytics | Data anonymization, encrypted transfer |
| Integration | Secure API with mTLS, VPN |
8. Compliance and Regulations
8.1 Common Regulations
| Regulation | Description | Cloud Impact |
|---|---|---|
| GDPR | EU data protection | Data residency, data subject rights |
| CCPA | California consumer privacy | Data access, deletion rights |
| HIPAA | US healthcare data | Business Associate Agreements required |
| PCI-DSS | Payment card data | Special cloud configurations |
| SOX | Financial reporting | Access controls, audit logging |
| NIST | US government standards | Specific security controls |
8.2 Cloud Compliance Considerations
| Consideration | Impact |
|---|---|
| Data residency | Must know where data is stored |
| Data transfer | Cross-border transfer may be restricted |
| Provider certifications | Must match regulatory requirements |
| Shared responsibility | You still have compliance obligations |
| Audit support | Must be able to provide logs, evidence |
8.3 On-Premise Compliance Considerations
| Consideration | Impact |
|---|---|
| Full control | Complete control over compliance |
| Audit burden | Must manage all audit requirements |
| Documentation | Must maintain complete records |
| Certification | Must obtain and maintain certifications |
| Staff training | Must train staff on compliance requirements |
9. N3xar’s Deployment Options
9.1 Cloud Option (SaaS)
| Aspect | Description |
|---|---|
| Deployment | Fully managed N3xar platform |
| Best for | Rapid deployment, small to medium deployments |
| Pricing | Per-device subscription |
| Scaling | Automatic with demand |
| Security | Managed by N3xar |
| Updates | Managed by N3xar |
9.2 On-Premise Option (Self-Hosted)
| Aspect | Description |
|---|---|
| Deployment | Docker-based on client infrastructure |
| Best for | Data-sensitive clients, service providers |
| Pricing | One-time license + infrastructure costs |
| Scaling | Client-defined |
| Security | Client-managed |
| Updates | Client-managed |
9.3 Dedicated Option (High Security)
| Aspect | Description |
|---|---|
| Deployment | Custom deployment for single client |
| Best for | Enterprise, government, high-security |
| Pricing | Custom quoted |
| Customisation | Full—branded UI, custom business rules, integrations |
“The platform supports both Docker/cloud deployment anywhere and offers custom development for enterprise clients, including branded user interfaces and business rules.”
10. Conclusion
The choice between public cloud and on-premise deployment for IoT systems is a strategic decision with far-reaching implications. There is no universal “right” answer—the optimal choice depends on your specific requirements.
Key Takeaways
Choose Cloud When:
- You need rapid deployment and scalability
- You have limited in-house infrastructure expertise
- Data sensitivity is low to moderate
- You prefer OPEX over CAPEX
- You want to leverage cloud-native services (AI, analytics)
Choose On-Premise When:
- Data sovereignty is critical
- You have in-house expertise and staff
- You need offline operation
- You prefer CAPEX over OPEX (long-term)
- You need complete security control
Choose Hybrid When:
- You need both control and scalability
- Some data is sensitive, some is not
- You need local processing for real-time response
- You want the best of both worlds
Recommendations
| Scenario | Recommended Approach |
|---|---|
| Startup, rapid prototyping | Cloud (SaaS) |
| Enterprise, data-sensitive | Self-hosted (on-premise) |
| Government, high-security | Dedicated (on-premise) |
| Multinational, global deployment | Hybrid (regional cloud + central management) |
| Remote, unreliable internet | Hybrid (edge + occasional cloud sync) |
“The best deployment model is not the one with the highest specifications, but the one that most effectively and efficiently supports your business goals.”
Further Reading
- Dockerizing Your IoT Stack – step-by-step guide to containerising your backend.
- Designing Scalable IoT Systems: A Practical Guide for Integrators – the main article providing a broad overview of IoT architecture.
This article is based on practical experience building the N3xar platform, which supports cloud, self-hosted, and dedicated deployment models to meet diverse client needs.