Sitra rise of the pilots janne enberg
0 likes174 views
The document discusses the infrastructure and SaaS solutions provided by major cloud providers, emphasizing their focus on data standardization and deployment automation. It highlights the role of organizations like Gaia-X and IHAN in reducing dependency on large cloud providers and creating open standards for data interoperability. Additionally, it covers the architecture of data products using OpenAPI standards and the need for compliance in deploying applications across various infrastructures.
Sitra rise of the pilots janne enberg
- 1. Technology of IHAN Janne Enberg
- 2. Infrastructure and SaaS solutions Data standardization Infrastructure and deployment automation The big cloud providers tend to provide services in two main categories - infrastructure, and SaaS solutions. On the infrastructure side they provide the datacenter management and other capabilities so you can deploy your software on their managed servers, or use their managed storage services. For SaaS they build on those capabilities and provide ready-to-use services, such as logging, error reporting, databases, analytics, and so on. They also often have their own marketplace for ready "recipes" to deploy common Open Source Software on their infrastructure, and you can use existing OSS management tools such as Terraform to do that on any of the infrastructure providers also other providers than just Big Cloud. Gaia-X seems to have their main focus in reducing dependency on the infrastructure from the big cloud providers. They are building tools to standardize deployment to (primarily European) datacenters, so the infrastructure side is similarly handled by professionals on-site. Additionally they're building tooling to describe software deployments and their dependencies, so e.g. when you deploy common Open Source projects, the database they require is also deployed and configured at the same time. This is similar to many OSS Kubernetes management tools already out there, and they build heavily on Kubernetes and OpenStack. Unlike the other ones, IHAN does not have an opinion on where and how server infrastructure is managed. IHAN is focused on data standardization and building both fair markets for, and access to standardized data. IHAN is building open standards for this, and the implementations built for that can be hosted on any infrastructure, and deployed using any tools chosen for the task. IDSA is working on standardizing domain specific data vocabularies and is currently very closed. Big Cloud, Gaia-X, and any other infrastructure provider can run IHAN compliant systems, and the software can be deployed using Gaia-X's deployment tools, using e.g. Kubernetes Helm, or manually. Copyright © Digital Living International and Sitra IHAN | Enberg/Suomi/Frosti Big Cloud vs Gaia-X vs IHAN
- 3. Comparison of capabilities and focus areas Data Standardization Deployment tools SaaS & PaaS solutions Infrastructure services Provider + OSS projects = Focus area = Partial support / Some tooling or standards = No support / No opinion Infrastructure services is mostly about installing server software on servers that are physically managed by the datacenter. SaaS & PaaS are providing more comprehensive tools that require no manual maintenance by the users. Deployment tools are how you manage your software and install existing software, e.g. how to install a database on the infrastructure. Data Standardization for IHAN is about how services and software communicate between each other, e.g. how weather data is described and transferred from the data source to applications, to allow for applications to interoperate, and for various data sources to be compatible with each other, as well as to meet process needs for end users and businesses, and IDSA adds partial support specifically for data vocabularies. OSS tools with support for automating deployments to Big Cloud and other infrastructure: Terraform, Kubernetes Helm, Ansible, SaltStack, Vagrant, Chef, Puppet. Big Cloud vs Gaia-X vs IHAN - capabilities Copyright © Digital Living International and Sitra IHAN | Enberg/Suomi/Frosti
- 4. Subset of OpenAPI 3.0 Data Product standards Nexus Open Nexus standards Rulebook Certification Layering in the Nexus Layer 0: Everything is built on common standards such as OpenAPI, JSON, JWT, OpenID Connect, etc. and can be deployed and hosted on any infrastructure, depending on the requirements for the selected Nexus, Authorization, and Consenting providers. Such hosting infrastructure may be e.g. Gaia-X compatible hosting, any IaaS provider, or bare metal, and so on. These lay out the concrete foundation everything is built on. etc. Authentication Consent OpenID Connect JWT Layer 1: Data Product standards can be built by anyone for generic use or for their Nexus specifically, are publicly available and can be implemented by APIs directly without any Nexus, so when building a new system you don't always have to reinvent the wheel and come up with a unique new API design. Nexus standards are also openly available for anyone to implement a Nexus with, and we will happily work with open source projects on implementations. Layer 2: Nexus implementations can be written as SaaS, open source, or any other model based on the open nexus standards. Minimum feature set is limited, and e.g. consents and authentication are pluggable. Deployment requirements are implementation specific and can e.g. be compatible with Gaia-X. Layer 3: Each Nexus can set their own rules via a Rulebook that every member will have to agree to when they operate on the Nexus. These Rulebooks can vary differently depending on the specific organizations and use-cases, for example with health data they may be very strict, and with weather data they may be much more relaxed. Some small Nexuses might not need one at all. Layer 4: When a Nexus wants to be a reliable marketplace, they may require, or offer an optional Certification or Verification process for both the identity of the Data Vendor - ensuring you know who you are dealing with - and the quality and reliability of the Data Source - ensuring you can build serious business on it and trust that the data is good and available when you need it. Hosting, deployment tools Copyright © Digital Living International | Enberg/Suomi/Frosti
- 5. Nexus-as-a-Service JSON Custom Data Standards Packing list Invoice Shipping data Cargo receipt Insurance policy SAP Productizer Force Productizer Custom productizer Product Gateway Other data integrations Any protocol Applications follow strict Data Product standards when requesting data from the Nexus Data Productization layers receive standardized requests, communicate with backend systems, and return standardized responses back through the Nexus Nexus ensures all communication happens using the standards, and provides tools to manage and find Data Sources for developers on both sides Future protocols Pub/Sub Batch Streams "Opened" via PGW, then out-of-band SOAP + WSDL Example Data Standards https://github.com/digitalliving/standards/tree/master/draft/DataProducts Example Productizer https://github.com/digitalliving/ihan-productizer-example Auth & Consent The agreed OIDC and consent tokens are delivered from applications through the nexus to data sources where necessary for access control, logging, etc. Request Response Data Product requests define which Data Product they want, any parameters for it, and carry authentication, and consent tokens Data Product responses contain a standards- compliant Data Product response for the request, and digital signatures* to prove authenticity * Not yet New Data Sources may be built specifically with productization capabilities in mind, while existing systems do not need to be changed and a Productizer layer may be built separately for compatibility. 2. 3. 4. Data Standards define the exact protocol and payload of request and response for all Data Products using OpenAPI 3.0 specifications 1. Copyright © Digital Living International | Enberg/Suomi/Frosti IHAN Blueprint Nexuses are the first implementation of the IHAN Blueprint work
- 6. IHAN Testbed for March 2021 Closed alpha - management of connected data sources and applications is done manually for early pilot partners. Applications Data Sources Product Gateway Data Standards Mai ntai ns data sou rce Uses Standards B u ild s ap p lic at io n s Use applications Ask for data from selected provider Verify + fetch data from origin Testbed Uses Standards Next IHAN Testbed capabilities Additional capabilities we expect to have in the first public release are mostly around self-service tools to integrate your applications and data sources, marked with dashed lines. Additionally direct authentication integration will be replaced with a login portal. API Docs Developer Portal Register Data Source Explore options Login portal Find registered Data Sources End users Application developer Data source developer Authentication & Authorization + others Log in to application Authorize access to data Copyright © Digital Living International and Sitra IHAN | Enberg/Suomi/Frosti Authorize access to data (token) Log in to application
- 8. Thank you! Find out more: ihan.fi digitalliving.fi contact@digitalliving.fi If you want to get help setting up your own nexus project - don't hesitate to contact us!