Blueprint Overview/Introduction
Designing and building edge services is made more difficult by the need to combine many different devices, infrastructure resources, infrastructure services and applications, often with their own complex dependencies and interrelationships. It is not easy for players in a particular technology or service area to acquire and maintain the necessary expertise to design and build edge services, especially as the landscape rapidly changes around them. Even so, many companies want to expand and develop their businesses by providing edge services based on their strengths in specific product and service fields.
The objective of the Edge Service Enabling Platform Blueprint is to make it possible for a community of device and resource providers and edge service designers and maintainers to cooperate to make the design and implementation of edge services easier, without requiring deeply specialized knowledge of every component that goes into the services. The intent is to provide a framework for the creation of libraries which encapsulate the knowledge required to deploy specific devices and resources, and catalogs which capture the design of edge services by combining these libraries. The intent is to make it possible for an edge service provider to select an appropriate catalog and, with a minimum of configuration, deploy it directly into their target environment.
The diagram below shows how edge service catalogs encapsulate the specialized knowledge of various device, application, and service providers into a package which can be deployed in the field with minimal configuration. This benefits both the person deploying the service, by reducing the cost and effort required to design and deploy the service, and the device and infrastructure suppliers, who will see greater use of their devices and infrastructure because of the reduced friction in using them.
Use Cases
Below are some sample use cases which could benefit from the approaches implemented in this blueprint.
Where on the Edge
XXX
Business Drivers
XXX
Overall Architecture
The diagram below shows the overall architecture of this blueprint.
The three main types of actor are the device/infra provider, the edge service designer, and the edge service manager. The system manager is a fourth type of actor representing the manager of the Edge Service Enabling Platform itself.
Each actor engages in the following activities using the Edge Service Enabling Platform:
- Device/Infra Providers create and register libraries, which are stored in the registry component's library database and library file repository. A library contains the files necessary to deploy support for a device (e.g. a temperature sensor or a camera) or piece of infrastructure (e.g. a distributed storage system, messaging system, backend database, or computing platform) in an edge service, along with the data needed to connect the library with other libraries in a complete edge service design to form an edge service catalog. Aside from creating and registering libraries, device and infra providers will also use test environments and the platform's test tools to verify their libraries.
- Edge Service Designers create and register edge service catalogs. These are stored in the registry component's catalog database and refer to libraries in the library database. A catalog defines a configuration of nodes and libraries deployed on those nodes, connected to each other via various styles of API (e.g. REST messaging over IP networks, Unix file sockets, device driver ioctl, or direct calls, among many other possibilities), in order to provide a service. Edge service designers will also use test environments and the platform's test tools to verify their catalogs.
- Edge Service Managers use catalogs they choose from the platform and the platform's deployment tools to define and deploy instances of an edge service in their target environments. They choose a catalog for the service they wish to implement, and provide the target environment for deployment. They configure the specifics of their environment (network addresses, specific hardware configuration, security keys and so on) and use the platform's deployment tools, especially the deployment runtime components, to roll out the service.
- The System Manager maintains the platform itself, configuring the underlying system, installing and updating software, making backups, and maintaining the user database.
It is possible for one organization or even one individual to perform any number of these roles, or even all of them.
Platform Architecture
The table below summarizes the platform for each node in the blueprint.
Hardware Platform | |
---|---|
CPU | |
OS | |
Memory | |
Storage | |
Network | |
Other |
Software Platform Architecture
The software components used by the blueprint are listed below.
APIs
No additional APIs are defined by this blueprint.
Hardware and Software Management
Hardware provisioning and software management is described in the installation guide.
Licensing
Scripts and source code are licensed under the Apache 2.0 license.