ETSI TR 103 528 V1.1.1 (2018-08)

SmartM2M; Landscape for open source and standards for cloud native software applicable for a Virtualized IoT service layer

DTR/SmartM2M-103528

General Information

• Status: Published
• Publication Date: 01-Aug-2018
• Technical Committee: SmartM2M - Smart M2M
• Current Stage: 12 - Completion
• Due Date: 22-Aug-2018
• Completion Date: 02-Aug-2018

Standards Content (Sample)

TECHNICAL REPORT
SmartM2M;
Landscape for open source and standards for cloud native
software applicable for a Virtualized IoT service layer

2 ETSI TR 103 528 V1.1.1 (2018-08)

Reference
DTR/SmartM2M-103528
Keywords
cloud, IoT, open source, virtualisation

ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex - FRANCE

Tel.: [phone]  Fax: [phone]

Siret N° 348 623 562 00017 - NAF 742 C
Association à but non lucratif enregistrée à la
Sous-Préfecture de Grasse (06) N° 7803/88

Important notice
The present document can be downloaded from:
http://www.etsi.org/standards-search
The present document may be made available in electronic versions and/or in print. The content of any electronic and/or
print versions of the present document shall not be modified without the prior written authorization of ETSI. In case of any
existing or perceived difference in contents between such versions and/or in print, the only prevailing document is the
print of the Portable Document Format (PDF) version kept on a specific network drive within ETSI Secretariat.
Users of the present document should be aware that the document may be subject to revision or change of status.
Information on the current status of this and other ETSI documents is available at
https://portal.etsi.org/TB/ETSIDeliverableStatus.aspx
If you find errors in the present document, please send your comment to one of the following services:
https://portal.etsi.org/People/CommiteeSupportStaff.aspx
Copyright Notification
No part may be reproduced or utilized in any form or by any means, electronic or mechanical, including photocopying
and microfilm except as authorized by written permission of ETSI.
The content of the PDF version shall not be modified without the written authorization of ETSI.
The copyright and the foregoing restriction extend to reproduction in all media.

© ETSI 2018.
All rights reserved.
TM TM TM
DECT , PLUGTESTS , UMTS and the ETSI logo are trademarks of ETSI registered for the benefit of its Members.
TM TM
3GPP and LTE are trademarks of ETSI registered for the benefit of its Members and
of the 3GPP Organizational Partners.
oneM2M logo is protected for the benefit of its Members. ®
GSM and the GSM logo are trademarks registered and owned by the GSM Association.
ETSI
3 ETSI TR 103 528 V1.1.1 (2018-08)
Contents
Intellectual Property Rights . 8
Foreword. 8
Modal verbs terminology . 8
Introduction . 8
1 Scope . 10
2 References . 10
2.1 Normative references . 10
2.2 Informative references . 10
3 Definitions and abbreviations . 11
3.1 Definitions . 11
3.2 Abbreviations . 11
4 A Landscape for Open Source and Standards . 13
4.1 Introduction. 13
4.2 Open Source Software, Cloud-Native Computing, IoT . 14
4.3 Content of the present document . 14
5 Open Source support to IoT Virtualization . 15
5.1 An Architecture for OSS component classification . 15
5.2 A map of Cloud-Native Software . 15
5.3 Open Source Software in support of IoT Virtualization . 16
5.3.1 The approach taken . 16
5.3.2 The role of Open Source Software eco-systems . 17
5.3.3 How to read the map . 18
6 Open Source Components for IoT Virtualization . 18
6.1 Cloud Infrastructure . 18
6.1.1 OpenStack . 18
TM
6.1.2 Amazon Web Services (AWS) . 20
TM
6.1.3 Microsoft Azure . 23
TM
6.1.4 IBM BlueMix . 25
6.2 Container . 26
6.2.1 Docker . 26
6.2.2 Rocket . 28
6.2.3 Comparison of Container Software . 29
6.3 Orchestration. 29
6.3.1 Kubernetes . 29
6.3.2 Mesos . 31
6.3.3 Zookeeper . 32
6.3.4 Docker Swarm . 33
6.3.5 Yarn . 35
6.3.6 Comparison of Orchestration Software . 37
6.4 Common Services . 37
6.4.1 Data Collection . 37
6.4.1.1 Fluentd . 37
6.4.1.2 Logstash . 39
6.4.1.3 Beats . 40
6.4.1.4 Comparison of Data Collection Software . 42
6.4.2 Communication . 42
6.4.2.1 Kafka . 42
TM
6.4.2.2 Amazon Kinesis . 43
6.4.2.3 Flume . 45
6.4.2.4 Redis . 46
6.4.2.5 Comparison of Communication Software . 47
6.4.3 Computation . 47
ETSI
4 ETSI TR 103 528 V1.1.1 (2018-08)
6.4.3.1 Apache Flink . 47
6.4.3.2 Apache Spark. 49
6.4.3.3 Apache Storm . 50
6.4.3.4 Apache Hadoop . 51
6.4.4 Storage . 52
6.4.4.1 Apache Cassandra . 52
6.4.4.2 Apache Hive . 53
6.4.4.3 Couchbase . 55
6.4.4.4 Apache HBase . 56
6.4.4.5 Vitess . 58
6.4.5 Search Engine. 60
6.4.5.1 Elasticsearch . 60
6.4.5.2 Solr . 61
6.4.5.3 Lucene . 62
6.4.5.4 Comparison of Search Engine Software . 63
6.4.6 Data Usage . 63
6.4.6.1 Kibana . 63
6.4.6.2 Grafana . 64
6.4.6.3 Comparison of Visualization Software . 66
6.5 Monitoring . 66
6.5.1 Prometheus . 66
6.5.2 Netdata . 67
6.5.3 Comparison of Monitoring Software . 69
7 Standards support to IoT Virtualization . 69
7.1 Introduction. 69
7.2 Standards Landscapes for IoT Virtualization . 70
7.2.1 An initial list of IoT Standards from AIOTI . 70
7.2.2 A landscape of Cloud Computing Standards . 70
7.3 Recent advances in IoT Standardization . 71
7.3.1 Introduction . 71
7.3.2 Big Data . 71
7.3.3 Semantic Interoperability . 72
7.4 Advances from IoT Research. 73
8 Conclusions . 74
8.1 Assessment and Lessons Learned . 74
8.2 Guidelines and Recommendations . 75
8.2.1 Guidelines to designers and developers . 75
8.2.2 Recommendation to oneM2M . 75
8.2.3 Recommendation to AIOTI and the IoT community . 75
Annex A: Change History . 76
History . 77

ETSI
5 ETSI TR 103 528 V1.1.1 (2018-08)
List of figures
Figure 1: The potential of Cloud-Native Infrastructures . 14
Figure 2: An HLA for IoT Virtualization . 15
Figure 3: The CNCF landscape of Cloud-Native Software Components . 16
Figure 4: A global map of OSS Components for IoT Virtualization . 17
Figure 5: The example of the Apache Hadoop ecosystem . 17
Figure 6: OpenStack architecture . 19
Figure 7: Amazon Web Services Architecture . 20
Figure 8: Microsoft Azure Architecture . 24
Figure 9: IBM Bluemix Architecture . 26
Figure 10: Docker Architecture . 27
Figure 11: Rocket Architecture . 28
Figure 12: Kubernetes architecture . 30
Figure 13: Mesos Architecture . 32
Figure 14: Zookeeper Architecture . 33
Figure 15: Docker Swarm Architecture . 34
Figure 16: Yarn Architecture . 36
Figure 17: Fluentd Architecture . 38
Figure 18: Logstash Architecture . 40
Figure 19: Beats Architecture . 41
Figure 20: Kafka Architecture . 43
Figure 21: Amazon Kinesis High-Level Architecture . 44
Figure 22: Flume Architecture . 45
Figure 23: Redis Architecture. 47
Figure 24: Flink Architecture . 48
Figure 25: Spark Architecture . 49
Figure 26: Storm Architecture . 50
Figure 27: Hadoop Architecture . 51
Figure 28: Cassandra Architecture . 52
Figure 29: Apache Hive Architecture . 53
Figure 30: Couchebase Architecture . 55
Figure 31: Apache HBase Architecture . 57
Figure 32: Vitess Architecture . 58
Figure 33: Elastic Search cluster . 60
Figure 34: Kibana interface . 64
Figure 35: Grafana dashboard . 65
Figure 36: Prometheus Architecture . 66
ETSI
6 ETSI TR 103 528 V1.1.1 (2018-08)
Figure 37: Netdata High-level features and Architecture . 68
Figure 38: Five patterns of interoperability . 73

ETSI
7 ETSI TR 103 528 V1.1.1 (2018-08)
List of tables
Table 1: Comparison of Container Software . 29
Table 2: Comparison of Orchestration Software . 37
Table 3: Comparison of Data Collection Software . 42
Table 4: Comparison of search Engine Software . 63
Table 5: Comparison of Data Usage Software. 66
Table 6: Comparison of Monitoring software. 69

ETSI
8 ETSI TR 103 528 V1.1.1 (2018-08)
Intellectual Property Rights
Essential patents
IPRs essential or potentially essential to normative deliverables may have been declared to ETSI. The information
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web
server (https://ipr.etsi.org/).
Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web
server) which are, or may be, or may become, essential to the present document.
Trademarks
The present document may include trademarks and/or tradenames which are asserted and/or registered by their owners.
ETSI claims no ownership of these except for any which are indicated as being the property of ETSI, and conveys no
right to use or reproduce any trademark and/or tradename. Mention of those trademarks in the present document does
not constitute an endorsement by ETSI of products, services or organizations associated with those trademarks.
Foreword
This Technical Report (TR) has been produced by ETSI Technical Committee Smart Machine-to-Machine
communications (SmartM2M).
Modal verbs terminology
In the present document "should", "should not", "may", "need not", "will", "will not", "can" and "cannot" are to be
interpreted as described in clause 3.2 of the ETSI Drafting Rules (Verbal forms for the expression of provisions).
"must" and "must not" are NOT allowed in ETSI deliverables except when used in direct citation.
Introduction
In addition to interoperability and security that are two recognized key enablers to the development of large IoT
systems, a new one is emerging as another key condition of success: virtualization. The deployment of IoT systems will
occur not just within closed and secure administrative domains but also over architectures that support the dynamic
usage of resources that are provided by virtualization techniques over cloud back-ends.
This new challenge for IoT requires that the elements of an IoT system can work in a fully interoperable, secure and
dynamically configurable manner with other elements (devices, gateways, storage, etc.) that are deployed in different
operational and contractual conditions. To this extent, the current architectures of IoT will have to be aligned with those
that support the deployment of cloud-based systems (private, public, etc.).
Moreover, these architectures will have to support very diverse and often stringent non-functional requirements such as
scalability, reliability, fault tolerance, massive data, security. This will require very flexible architectures for the
elements (e.g. the application servers) that will support the virtualized IoT services, as well as very efficient and highly
modular implementations that will make a massive usage of Open Source components.
These architectures and these implementations form a new approach to IoT systems and the solutions that this STF will
investigate will also have to be validated: to this extent, a Proof-of-Concept implementation involving a massive
number of virtualized elements will be made.
ETSI
9 ETSI TR 103 528 V1.1.1 (2018-08)
The present document is one of three Technical Reports addressing this issue:
• ETSI TR 103 527 [i.1]: "Virtualized IoT Architectures with Cloud Back-ends".
• ETSI TR 103 528 (the present document): "Landscape for open source and standards for cloud native software
for a Virtualized IoT service layer".
• ETSI TR 103 529 [i.2]: "Virtualized IoT over Cloud back-ends: A Proof of Concept".

ETSI
10 ETSI TR 103 528 V1.1.1 (2018-08)
1 Scope
The present document:
• Recalls the main elements of the High-Level Architecture (HLA) in support of IoT Virtualization as it is
described in ETSI TR 103 527 [i.1] and how Open Source Software (OSS) and Standards can be used in the
implementation of virtualized IoT systems.
• Presents, for each of the layers (and sub-layers) of the HLA, several of the OSS components that have been
developed by the open source communities.
• Presents on-going developments in standardization that can be used in support of such implementations.
2 References
2.1 Normative references
Normative references are not applicable in the present document.
2.2 Informative references
References are either specific (identified by date of publication and/or edition number or version number) or
non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the
referenced document (including any amendments) applies.
NOTE: While any hyperlinks included in this clause were valid at the time of publication ETSI cannot guarantee
their long-term validity.
The following referenced documents are not necessary for the application of the present document but they assist the
user with regard to a particular subject area.
[i.1] ETSI TR 103 527: "SmartM2M; Virtualized IoT Architectures with Cloud Back-ends".
[i.2] ETSI TR 103 529: "SmartM2M; IoT over Cloud back-ends: a Proof of Concept".
[i.3] ITU-T News, October 2017: "What is 'cloud-native IoT' and why does it matter?".
NOTE: Available at http://news.itu.int/what-is-cloud-native-iot-why-does-it-matter/.
[i.4] "Cloud Native Infrastructure", Justin Garrison, Kris Nova, O'Reilly Media, 2018.
[i.5] ETSI TR 103 375: "SmartM2M; IoT Standards landscape and future evolutions".
[i.6] ETSI TR 103 376: "SmartM2M IoT LSP use cases and standards gaps".
[i.7] ETSI SR 003 392: "Cloud Standards Coordination Phase 2; Cloud Computing Standards Maturity
Assessment; A new snapshot of Cloud Computing Standards".
[i.8] ETSI TS 103 264 (V2.1.1) (03-2017): "SmartM2M; Smart Appliances; Reference Ontology and
oneM2M Mapping".
[i.9] White Paper: "IoT Platforms Interoperability Approaches", IoT-EPI Platforms Interoperability
Task Force, 2017.
[i.10] NIST SP 1500-1: "NIST Big Data Interoperability Framework: Volume 1, Definitions".
[i.11] NIST SP 1500-2: "NIST Big Data Interoperability Framework: Volume 2, Big Data Taxonomies".
[i.12] NIST SP 1500-3: "NIST Big Data Interoperability Framework: Volume 3, Use Cases and General
Requirements".
ETSI
11 ETSI TR 103 528 V1.1.1 (2018-08)
[i.13] NIST SP 1500-4: "NIST Big Data Interoperability Framework: Volume 4, Security and Privacy".
[i.14] NIST SP 1500-5: "NIST Big Data Interoperability Framework: Volume 5, Architectures White
Paper Survey".
[i.15] NIST SP 1500-6: "NIST Big Data Interoperability Framework: Volume 6, Reference
Architecture".
[i.16] NIST SP 1500-7: "NIST Big Data Interoperability Framework: Volume 7, Standards Roadmap".
[i.17] Recommendation ITU-T Y.4100 (former Y.2066): "Common requirements of the Internet of
things".
[i.18] ISO/IEC DIS 20546: "Information technology -- Big data -- Overview and vocabulary".
[i.19] Recommendation ITU-T Y.4114: "Specific requirements and capabilities of the Internet of things
for big data".
[i.20] Recommendation ITU-T Y.2068: "Functional framework and capabilities of the Internet of
things".
[i.21] ISO/IEC 20547: "Information technology -- Big data reference architecture -- Part 4: Security and
privacy".
3 Definitions and abbreviations
3.1 Definitions
For the purposes of the present document, the following terms and definitions apply:
Open Source Software (OSS): computer software that is available in source code form
NOTE: The source code and certain other rights normally reserved for copyright holders are provided under an
open-source license that permits users to study, change, improve and at times also to distribute the
software.
source code: any collection of computer instructions written using some human-readable computer language, usually as
text
standard: output from an SSO
Standards Setting Organization (SSO): any entity whose primary activities are developing, coordinating,
promulgating, revising, amending, reissuing, interpreting or otherwise maintaining standards that address the interests
of a wide base of users outside the standards development organization
NOTE: In the present document, SSO is used equally for both Standards Setting Organization or Standards
Developing Organizations (SDO).
3.2 Abbreviations
For the purposes of the present document, the following abbreviations apply:
AIOTI Alliance for IoT Innovation
AM Application Master
API Application Programming Interface
AWS Amazon Web Services
BASH Bourne-again shell (a Unix Shell)
CA Certificate Authority
CDN Content Delivery Network
CLI Command Line Interface
CNCF Cloud Native Computing Foundation
ETSI
12 ETSI TR 103 528 V1.1.1 (2018-08)
CPU Central Processing Unit
CRUD create, read, update, delete
CSC Cloud Standards Coordination
CSP Cloud Service Provider
CSV Comma-Separated Values
DAG Directed Acyclic Graph
DC/OS Datacenter Operating System
DDL Data Definition Language
DIS Draft International Standard (in ISO)
DNS Domain Name Service
DVC Desktop Cloud Visualization
EBS Elastic Block Store
EC2 Elastic Compute Cloud
ECR EC2 Container Registry
ECS EC2 Container Service
EFS Elastic File System
ELB Elastic load Balancing
EMR Elastic MapReduce
ENA Elastic Network Adapter
ES ElasticSearch Service
ETS Elastic Transcoder Service
EU European Union
FTP File Transfer Protocol
GPL GNU General Public License
GSI Global Secondary Index
GUI Graphical User Interface
HDFS Hadoop Distributed File System
HLA High-Level Architecture
HPE Hewlett Packard Enterprise
HSM Hardware Security Module
HTML HyperText Markup Language
HTTP HyperText Transfer Protocol
HTTPD HTTP Daemon
HTTPS HyperText Transfer Protocol Secure
IaaS Infrastructure as a Service
IAM Identity and Access Management
ICMP Internet Control Message Protocol
IEC International Electrotechnical Commission
IO Input/Output
IP Internet Protocol
ISO International Organization for Standardization
IT Information Technology
ITU-T ITU Telecommunication Standardisation Sector
JAR Java Archive
JDBC Java Database Connectivity
JMX Java Management Extensions
JSON JavaScript Object Notation
JTC Joint Technical Committee
JVM Java Virtual Machine
KMS Key Management Service
LDAP Lightweight Directory Access Protocol
LRU Least Recently Used
MB Megabyte
NBDIF NIST Big Data Interoperability Framework
NIST National Institute of Standards and Technology
OCI Open Container Image
OLAP Online Analytical Processing
OSS Open Source Software
PaaS Platform as a Service
PHP Hypertext Preprocessor
RAM Random Access Memory
RDF Resource Description Framework
ETSI
13 ETSI TR 103 528 V1.1.1 (2018-08)
RDS Relational Database Service
REST Representational State Transfer
RM Resource Manager
RPC Remote Procedure Call
RTT Round-Trip Time
SaaS Software as a Service
SAREF Smart Appliance Reference Ontology
SDO Standards Development Organization
SES Simple Email Service
SLA Service-Level Agreement
SMS Short Message Service
SNS Simple Notification Service
SP Special Publication (of NIST)
SQL Structured Query Language
SQS Simple Queue Service
SR Special Report
SSH Secure Shell
SSO Standards Setting Organization
STF Specialist Task Force
SWF Simple Workflow
TCP Transmission Control Protocol
TFS Team Foundation Server
TLS Transport Layer Security
TPM Trusted Platform Module
TRL Technology Readiness Level
TSV Tab Separated Values
UDP User Datagram Protocol
UI User Interface
URL Uniform Resource Locator
VM Virtual Machine
VPC Virtual Private Cloud
VPN Virtual Private Network
W3C World-Wide Web Consortium
WG Work Group
XML Extensible Markup Language
4 A Landscape for Open Source and Standards
4.1 Introduction
The IoT industry starts to understand the potential benefits of Cloud-Native Computing for the fast, effective and
future-safe development of IoT systems combining the strengths of both IoT and Cloud industries in a new value
proposition (see [i.3] for example).
The notion of Cloud-Native Computing is now widely supported by a large set of technologies embedded in Cloud-
Native Infrastructures in support of Cloud-Native Applications. A possible definition is: "Cloud native infrastructure is
infrastructure that is hidden behind useful abstractions, controlled by APIs, managed by software, and has the purpose
of running applications. Running infrastructure with these traits gives rise to a new pattern for managing that
infrastructure in a scalable, efficient way" (see [i.4]).
The expectation of Cloud-Native applications is to benefit from offerings from Cloud Service Providers (CSP) that may
cover parts or all of the layers of Virtualized application, via Infrastructure as a Service (IaaS), Platform as a Service
(PaaS) or Software as a Service (SaaS). Figure 1 presents the possible usages of such offerings in delegating more and
more important parts of the underlying layers to a third-party in charge of hiding complexity, resource usage, etc.
ETSI
14 ETSI TR 103 528 V1.1.1 (2018-08)

Figure 1: The potential of Cloud-Native Infrastructures
4.2 Open Source Software, Cloud-Native Computing, IoT
In the case of IoT applications, the trade-off between what is delegated to the Cloud Service Provider and what is kept
in the hands of the application developers may vary depending a large number of potential factors. It is, for example,
not always clear which support of various IoT devices is available in a IaaS offer or how data at the edge can be
efficiently handled in a PaaS offer. This is why it is important to investigate the degree of flexibility that is offered to
the application developer by complementary solutions such as those provided by the Open Source Software.
The technologies assembled by the Open Source communities around Cloud-Native Computing are now more and more
diverse (involving all layers of a Micro-Service Architecture such as the one described in ETSI TR 103 527 [i.1]). In the
same time, these technologies have been made much easier to apprehend, to master and to package into more and more
complex systems.
It is important, in the context of IoT, where a number of systems are being developed with an important part of
"greenfield" development with new features and new devices deployed, to assess how these technologies are available
to the application developers. An inventory of major available OSS components is an essential first step.
4.3 Content of the present document
Clause 5 recalls the main architectural elements developed in ETSI TR 103 527 [i.1] and serves as a structured basis for
an introduction of OSS components which is done in subsequent Clause 6. Is also presents how these OSS components
are supported by OSS communities and eco-systems in order to ensure their perennial use by virtualized IoT systems
developers.
Clause 6 presents a detailed description of a number of selected OSS components that are currently used for Cloud-
Native implementations and that can be used in IoT Virtualization implementation projects. Many of these OSS
components are used in the proof-of-concept implementation developed in ETSI TR 103 529 [i.2].
Clause 7 addresses the support that standardization can bring, in addition to the OSS components, in support of IoT
Virtualization implementations. It assesses the current status of standardization in Cloud Computing and IoT and
presents potentially useful on-going developments in standardization or pre-standardization.
Clause 8 summarizes the main findings of the present document and provides a set of recommendations for architects
and developers in charge of potential IoT virtualization projects.
ETSI
15 ETSI TR 103 528 V1.1.1 (2018-08)
5 Open Source support to IoT Virtualization
5.1 An Architecture for OSS component classification
A Micro-Service Architecture is presented in ETSI TR 103 527 [i.1] with the purpose of identifying layers in the
development of IoT systems that can be mapped with on-going developments in the OSS communities. This Micro-
Service Architecture is recalled in Figure 2.

Figure 2: An HLA for IoT Virtualization
An important layer is the one of "Common Services" (i.e. Data Collection, Communication, etc.) where a very large
number of (sometimes competing) initiatives are taking place and a wealth of solutions are provided to the applications
developers. It is also one of those which will benefit from a detailed and precise map of existing solutions.
5.2 A map of Cloud-Native Software
The OSS communities are well aware of the very large number of initiatives related to Virtualization and the need to
provide some form of guidance to those who want to get involved.
An initiative like the Cloud Native Computing Foundation (CNCF, https://www.cncf.io) "builds sustainable ecosystems
and fosters a community around a constellation of high-quality projects that orchestrate containers as part of a
microservices architecture". More importantly, the CNCF is supporting a Landscape project intended as "a map through
the previously uncharted terrain of cloud native technologies". The current landscape of CNCF is shown in Figure 3.
This landscape displays only a few components for each of the software component category presented and is obviously
showing a very complex map.
ETSI
16 ETSI TR 103 528 V1.1.1 (2018-08)

Figure 3: The CNCF landscape of Cloud-Native Software Components
5.3 Open Source Software in support of IoT Virtualization
5.3.1 The approach taken
The present document is offering a more focused approach to the identification of OSS Components in support of IoT
Virtualization, essentially for the following reasons:
• The components analysed are not covering the whole of Cloud-Native components and, in particular, are more
focused on the "general purpose" cross-domain components, rather than on application-specific ones.
• The selection takes into account a form of "recognition" or of "notoriety" of the selected components and
limits the number of choices for each class of component.
ETSI
17 ETSI TR 103 528 V1.1.1 (2018-08)

Figure 4: A global map of OSS Components for IoT Virtualization
Altogether, the resulting global map of components in Figure 4 is simpler than the one of Figure 3.
It should be noted that some of the Components presented in the present document are actually used in the
implementation of the Proof-of-Concept described in ETSI TR 103 529 [i.2].
5.3.2 The role of Open Source Software eco-systems
In a large number of cases, the OSS components are not developed in isolation of the rest of what the OSS communities
are developing. Even if there are thousands of on-going OSS developments concurrently, some become more successful
because they are done within the context of large OSS communities supporting the coordinated development of related
components. Such "ecosystems" are providing a proper ground to the maturation of components that benefit from the
(technical) proximity with a (potentially large) number of other components.
The example of the maturation over time of the "Apache Hadoop" ecosystem in Figure 5 is typical.

Figure 5: The example of the Apache Hadoop ecosystem
In principle, components belonging to established and recognized eco-systems are more likely to evolve "properly",
with more transparent and controlled evolution of features, large support of skilled developers, etc. The potential
drawback may be the lack of adaptability of a compone
...