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)

checkbox 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

checkbox Dockerfile -> Docker Build -> Image: includes all needed Dependencies (Self Contained-ness/in sich geschlossen)

checkbox Docker Compose declares all needed Services (no other services will be started within the app)

checkbox The App can be started with a single “click” (docker-compose up)

checkbox Docker Compose declares all needed Volumes (Data Volume + Log Volume)

checkbox The App can be stopped and restarted without domain data loss or (docker-compose stop/restart)

checkbox The App containers can be deleted without domain data loss (docker-compose down)

checkbox The App containers can be replaced by new containers without domain data loss or corruption (docker-compose down + build + up)

checkbox The timezone set for the container is UTC. See Time Zone Details, Why UTC?

checkbox Data Migration check may be necessary

checkbox The created containers shut down properly (no PID 1 zombies)

checkbox 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

checkbox A separate git repository contains the meta-data from the Resources/Store directory in a Rancher-compatible directory structure

checkbox 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

checkbox Readme states the purpose of the App

checkbox Readme lists the services and describes them shortly

checkbox Playbook includes App Lifecycle commands (pull, start, stop, upgrade)

checkbox FAQ

checkbox Known common Errors

checkbox Architecture Diagramm (eg. UML Deployment Diagramm)

checkbox Readme includes logo and screenshots

checkbox App Requirements (RAM, CPU, HDD)

checkbox Examples:

### ScaleIT App Compliance Level

checkbox App has a User UI

checkbox App has an Administration UI

checkbox 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.
UTC in a glance: No DST, No GMT/UTC offset, 2 hours behind Baden-Württemberg

UTC in a glance [1]

[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.

App Behaviour

checkbox Logging

checkbox Graceful degradation

Development Process

checkbox Automated build pipeline

checkbox Continuous Integration

checkbox Use Dynamic Port ranges 49,152 through 65,535.

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 * …

App Compliance Level

App Compliance Level structure

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