Industry 4.0 Digital Readiness¶
App X-Readiness¶
The App E(x)ecution Readiness Checklist helps you create a ScaleIT App that is technically ready to be executed on any ScaleIT platform instance. It builds the basis for the other checklists.
DockerCompose is the chosen aggregation unit for an App. However, it can be replaced with Kubernetes Pods or Rancherfiles without changing the logical construction of an App.
Todo
Work in progress
App Containers (Docker Subsystem)¶
Git repository conforms to ScaleIT template (Domain Apps, Sidecars folders)
<app_name>
├── docker-compose.yml
├── dc.build.yml [optional]
├── .env.default
├── .env.test.default [optional]
├── .env.staging.default [optional]
├── .env.production.default [optional]
├── README
├── Resources/
| ├── Documentation/
| ├── Rancher/
| | ├── catalogIcon-<app1>.svg //jpg,png or other format ok
| | ├── appHubIcon-<app1>.svg //jpg,png or other format ok
| | ├── config.yml // meta-data about the app
| | └── Screenshots/ // App Screenshots
| | | └── 1.jpg
| | └── Versions/
| | . └── 0/
| | . . └── docker-compose.yml // compose version 2 due to compatibility reasons
| | . . └── rancher-compose.yml
| └── Documentation/
| └── README
├── Domain Software/
| ├── DomainContainer1/
| | ├── Dockerfile
| | └── <some other files>
| └── DomainContainer2/
| └── Dockerfile
└── Platform Sidecars/ [optional]
. ├── SidecarContainer1/
. | ├── Dockerfile
. | └── <some other files>
. └── SidecarContainer2/
. . └── Dockerfile
Dockerfile -> Docker Build -> Image: includes all needed Dependencies (Self Contained-ness/in sich geschlossen)
Docker Compose declares all needed Services (no other services will be started within the app)
The App can be started with a single “click” (docker-compose up)
Docker Compose declares all needed Volumes (Data Volume + Log Volume)
The App can be stopped and restarted without domain data loss or (docker-compose stop/restart)
The App containers can be deleted without domain data loss (docker-compose down)
The App containers can be replaced by new containers without domain data loss or corruption (docker-compose down + build + up)
The timezone set for the container is UTC. See Time Zone Details, Why UTC?
Data Migration check may be necessary
The created containers shut down properly (no PID 1 zombies)
Adhere to the Dockerfile best practices
App Interfaces¶
Sinn dieser Interfaces: “Eine Web-UI zu haben um Administration und Datensicht auf die App und das was sie macht zu erlauben”.
Administration Endpoint /admin
- admin/config
- admin/doc
- admin/log
- admin/status
User Endpoint /user
- user/doc
- user/status
Developer Endpoint /dev
- dev/doc
- dev/rest
- dev/swagger.yaml
Todo
Insert Link to Spec as Swagger file
App Catalog Entry¶
A separate git repository contains the meta-data from the Resources/Store directory in a Rancher-compatible directory structure
Auto-generated entries for this repository (e.g. git post commit hooks that push meta-data to this app-store repository)
-- templates
|-- <app1>
| |-- 0 // App1-Version 0
| | |-- docker-compose.yml
| | |-- rancher-compose.yml
| | |-- answers.txt //environment variables for rancher-compose
| | |-- README.md
| |-- 1 // App-Version 1
| | |-- docker-compose.yml
| | |-- rancher-compose.yml
| | |-- README.md
| |-- catalogIcon-<app1>.svg //jpg or other format ok
| |-- appHubIcon-<app1>.svg //jpg or other format ok
| |-- config.yml // meta-data about the app
| |-- README.md
|-- <app2>
| |-- 0 // App2-Version 0
...
Contents of the config.yml
name: # Name of the Catalog Entry
description: |
# Description of the Catalog Entry
version: # Version of the Catalog to be used
category: # Category to be used for searching catalog entries
maintainer: # The maintainer of the catalog entry
license: # The license
projectURL: # A URL related to the catalog entry
This information is strongly inspired by the Rancher Catalog system: [http://rancher.com/docs/rancher/v1.2/en/catalog/private-catalog/](http://rancher.com/docs/rancher/v1.2/en/catalog/private-catalog/)
A catalog entry generator can be found here: [https://github.com/slashgear/generator-rancher-catalog](https://github.com/slashgear/generator-rancher-catalog)
App Documentation¶
Readme states the purpose of the App
Readme lists the services and describes them shortly
Playbook includes App Lifecycle commands (pull, start, stop, upgrade)
Architecture Diagramm (eg. UML Deployment Diagramm)
Readme includes logo and screenshots
App Requirements (RAM, CPU, HDD)
### ScaleIT App Compliance Level
App has the networking information included (routing address)
Time Zone Details, Why UTC?¶
Why Not {PST, GMT, PDT, etc}? [2]
- UTC has no Daylight Savings
- Uniform time across all sites, factories and offices
- Decreases data corruption chances due to inconsistent time zones
- Standardized time across all our Apps will ensure logs, databases and all components relying on the time will function in a predictibale and interoperable way.
Note
- This will move the problem up into the UI layer. We recommend working with UTC inside the App logic and converting UTC to local time only on the user interface.
- Tech Tip: Using the angular DatePipe in the UI will help you achieve this easily [3]. Look in the programming language of your choice to find similar useful features.
[1] | UTC in a glance, https://www.timeanddate.com/worldclock/timezone/utc |
[2] | An argument for UTC, http://yellerapp.com/posts/2015-01-12-the-worst-server-setup-you-can-make.html |
[3] | Angular DatePipe, https://angular.io/api/common/DatePipe |
App Engineering Readiness¶
This Readiness list includes proper features of a well maintainable and extensible software application. While this is optional, it is highly recommended for ensuring a proper App Eco System as it includes Software Engineering best practices.
Software Engineering¶
Reactive Design (App Richtlinien)
[https://projects.teco.edu/projects/scaleit-ap2/wiki/Richtlinien_App-Entwicklung]( https://projects.teco.edu/projects/scaleit-ap2/wiki/Richtlinien_App-Entwicklung)
Development Process¶
Maintenance¶
- Verification scripts for data base format upgrades
Testing¶
- CI compatibility
- Container level test suite
- BDD Testing
Production Readiness Checklist¶
The Production Readiness Checklist and Microservice Evaluation is an advanced list for ensuring the microservices have a level of production readiness comparable to those of companies such as Uber, Netflix, Google etc [4].
A. Production-Readiness Checklist¶
Production-Ready Service is …
- Stable and Reliable
- Scalable and Performant
- Fault Tolerant and Prepared for Any Catastrophe
- Properly Monitored
- Documented and Understood
B. Evaluate Your Microservice¶
- Stability and Reliability
- The Development Cycle
- The Deployment Pipeline
- Dependencies
- Routing and Discovery
- Deprecation and Decommissioning
- Scalability and Performance
- Knowing the Growth Scale
- Efficient Use of Resources
- Resource Awareness
- Capacity Planning
- Dependency Scaling
- Traffic Management
- Task Handling and Processing
- Scalable Data Storage
- Fault Tolerance and Catastrophe-Preparedness
- Avoiding Single Points of Failure
- Catastrophes and Failure Scenarios
- Resiliency Testing
- Failure Detection and Remediation
- Monitoring
- Key Metrics
- Logging
- Dashboards
- Alerting
- On-Call Rotations
- Documentation and Understanding
- Microservice Documentation
- Microservice Understanding
[4] | Susan J. Fowler Production-Ready Microservices, https://www.safaribooksonline.com/library/view/production-ready-microservices/9781491965962/ |
App ECO-Readiness¶
The App ECO-Readiness is a list of capabilities that an App can use within the ScaleIT Eco System. Based on the capabilities fulfilled, the App receives a Compatiblity Readiness Level (0-4).
General Capabilities¶
Compliance Level 0¶
An app must …
- Meet the X-Readiness Checklist
- Be uniquely identifiable and by a URL or IP(v4/v6) Adress
- Have a human readable Web UI at its adress
- Support at least HTTP/1.1
- Works standalone with a minimal feature set.
- Communicates Errors to the user
Compliance Level Max¶
- Must follow the Engineering Readiness list
Networking¶
An app must …
Level 0¶
- Have an open TCP/IP network pathway to the Web-UI (IP+Port/URL).
Level 1¶
- Reverse Proxy Support with static (per deploy) qualified domain names
- Able to receive HTTPS requests
Level 2¶
- Able to send and receive MQTT messages
Level 3¶
Data Handling Capabilities¶
Level 0¶
- Supports JSON Syntax for data exchanges.
- Parse errors or data handling exception do not cause the app to crash
Level 1¶
- Supports JSON Syntax for data exchanges and returns parsing error information
Level 2¶
Level 3¶
Level 4 (Semantic Enabled)¶
- Expose RDF-structured data with semantic annotations.
- JSON-LD as recommended syntax format for data exchange
- Vanilla JSON for backwards compatibility
- Self-describing API (eg. using the Hydra vocabulary).
have a root resource accessible via an HTTP URL. * expose a REST API. * accord to the highest level of maturity in the RMM. * fulfill all four Linked Data principles. * implement passive communication. use JSON or
over a human-facing HTML representation or user-interface. be stateless. * explicitly declare its dependencies, instead of relying on system-wide packages
Future Readiness, ensure the app… * Has HTTP2 support and can be upgraded to HTTP2 * …
Eco System Readiness - Platform¶
The Eco System Readiness describes the capabilities the underlying App Execution Environent and Platform Essentials provided.
General Capabilities¶
Compliance Level 0¶
- TCP/IP Networking layer
- HTTP and HTTPS Communication layer (Open ports 80 and 443 in Firewall)
- Container (Docker) runtime
Compliance Level 1¶
- Additional Communication Buses (MQTT, Autobahn etc.)
- Container (Docker) Registry
- HTTP Routing Capabilities
Compliance Level 2¶
- HTTPS support in central Routing (enables secure privacy sensitive features for HTML5 such as cameras)
- Routing Side Car
- Single Sign On
Compliance Level 3¶
- App Store
- License Management
- Data Safety (eg. Automatic Backups)
- Data Security (eg. Encryption)
- Identity Manager
- Role Manager
- Corporate Design Manager
Compliance Level 4¶
Compliance level 4 may only be relevant to large (>50 Apps) deployments as well as for high resiliance and minimal downtime scenarios (<1s). May be attained with more complex runtimes such as Kubernetes (Vanilla K8s, Openshift etc.).
- Auto Scaling
- Cross Server Replication
- Distributed storage interface (eg. CEPH)
- Cluster Resource Monitoring
INSERT SCALEIT PLATFORM DESCRIPTION HERE
Also: https://projects.teco.edu/projects/scaleit-ap2/wiki/ScaleIT_App_Compliance_Level