Ocopea's key feature is the ability to create and restore full application copies of cloud native apps. Ocopea is able to do this thanks to two key ingredients:

• Understanding the cloud native app topology
• Abstraction of the service consumption API (Ocopea Brokers)

In order for Ocopea to take application copies, it first needs to understand the application topology: what components it is built of and what is the interaction between them. Ocopea differentiates between two types of components: stateless components (app service) and stateful components (infrastructure services). Mostly thanks to the ability to easily scale stateless microservices this has become a common distinction for cloud native apps. In addition, while it is popular to run the stateless microservices using container orchestrators/PaaS - many organizations prefer delegating the standard infrastructure services to either SaaS (e.g. AWS RDS) or DevOps (e.g. Oracle database on premises).

Lets walk through an example:

The application topology diagram above describes our basic sample hackathon application. The application is built of one app service: The "hackathon service", written in java delivered as a docker container, and has two infrastructure service dependencies: an S3 service for storing documents and a Postgres database for storing hackathon ideas metadata. The hackathon service is the application entry point - meaning application users can interact with it via the web.

In order to make a copy of the entire hackathon application state and later restore it on a different environment, Ocopea needs the ability to make copies of each individual component configuration and data:

• The hackathon docker image version that is used including the configuration (port bindings, environment variables etc.)
• The postgres database - hackathon schemas, users and the configuration allowing the hackathon service to access it (bindings)
• The S3 service - hackathon buckets data, and the configuration allowing the hackathon service to access it (bindings)

The ability to both create copies and later restore individual components falls under the responsibility of the "Ocopea Brokers".

Ocopea brokers are the components that allow Ocopea to interact with the world. Deployment of containers, provisioning and creation of infrastructure services copies is all delegated to brokers.
Brokers are managed by the ocopea component called the Site. Every Ocopea site is responsible for a local geographical location - either a public cloud availability zone or an on premises datacenter. Sites can be aggregated by a central component called the Ocopea Hub.
There are three types of brokers:

• PSB - PaaS/Container Orchestrator brokers
• DSB - Data service brokers
• CRB - Copy repository brokers

The PSB is responsible for communicating with the PaaS or the container orchestrator. It is used by the Ocopea site to deploy the stateless containers and bind them to infrastructure services (Data Services)
Ocopea has built in PSBs for both Kubernetes and Cloud Foundry

The DSB is responsible for communicating with stateful services. Stateful services can run within the boundaries of the platform the app is running, or externally.
The two main tasks of a DSB are:

• Provision a new stateful service instance
• Create a copy of the service to a copy repository

Every service that implement the DSB API can be used by Ocopea. The API and samples can be found here

Examples of services that require DSBs:

• AWS S3 DSB
• Oracle DSB
• Docker volume mount DSB

As you can see in our standardization page, we keep our eye open for in the field of service consumption.

The CRB is responsible for listing and providing connectivity with copy repositories. Copy repositories are where Ocopea stateful services store copies. Ocopea has out-of-the box a postgres and a filesystem implementation of CRB.
Examples of services that require CRBs:

• AWS Glacier/S3 CRB
• VTL DSB

For more information regarding data path protocols and API see the CRB project.