Effective use of application copies can boost the development process agility and product quality. With a microservices architecture this becomes even more critical as applications tend to have many small databases. Ocopea comes to the rescue and makes the developer's life simpler by enabling application copy re-purposing into developer workflows and tools.

Let's walk through some of the scenarios using the Ocopea UI.

I am testing the latest version of my organization's app named Lets-chat. Lets-chat is a chat app that uses MongoDB to store all of its data. Today I managed to reproduce a sneaky rare bug that is very annoying to customers. Excited with my success, I plan on sending the mail to the entire organization saying: Don't touch this cluster until a developer reviews the bug and fixes it! Then I plan to leave the app running, and go have a snack as my environment is pending.

Oh.. Copy.. but I have Ocopea!

With Ocopea it is simpler than ever to freeze application state and transfer it between engineers. All we have to do is simply create a "saved application image" and share it.

When creating the image, users name it, label it, and add comments so that it will be easy to locate in the future.

In the background, Ocopea orchestration kicks in and creates a copy of all the components involved in running the app: Container versions, Kubernetes deployment configuration and a physical copy of all data services involved - in our case one instance of MongoDB. Copies are stored on a copy repository configured by the user.

Once the image is persisted it is stored in the Ocopea image catalog and can be shared with other team members.

Restoring the Ocopea image is as easy as creating it and can be done with a click. Developers can restore the images to their own environment for debugging purpose.

Ocopea supports several bug tracking tools, but it can be extended to integrate with anything.

Modern engineering groups are using some sort of process to manage the deployments of cloud native apps. With short iterations, and frequent deployments - the ability to have a rolling application instance with fresh and relevant data can improve the process and boost quality and productivity.

Ocopea's saved images fits perfectly into this process by allowing developers and other stake holders to store and share application in specific states. Product owners for example, can use a customer database and manipulate it with data so that developers at the end of the sprint could demo the features using a pre-defined application instance with enough data to cover the use case. Developers can always pick an image pre-loaded with large quantities of data in order to demonstrate how new features do not degrade the app performance. App images can be used by everyone in the org to demo the latest state of the app - all with relevant data populated and up-to-date.

When a developer uses the Ocopea UI in order to run a new copy of the app he can choose to populate the application instance with data using one of these options:

• Blank - run the app with empty initialized schemas
• Saved Image - populate data using one of the images from the Ocopea saved images catalog

Once an image is created, developers can choose target cluster/site to be used. Ocopea will present only sites that can support the deployment. for example - if the application has an S3 dependency, only sites that support that can be used (AWS S3, minio on premises etc.). In addition, Ocopea will let you select the service plan to be used. This is useful since for most cases - test and dev can use service plans with reduced SLA.

By default Ocopea will configure the application exactly the same as it was when the copy was made. Users can, however, make changes to the configuration, for example, by changing some of the component versions or even creating partial deployments - all according to what is needed. Ocopea integrates with public and private docker registries and maven repositories allowing the user to pick from the latest images available.

Having the ability to provision a full running app including its data with a single click is huge deal for developers. This replaces the process of going though ops to provision the instances, asking the backup admin to restore the data, coordinating with DBAs to install the database binaries and finally deploying the application and configuring it to use the restored services. If developers used to think twice before validating their fixes with various sets of data from production systems - with Ocopea - there is no hesitation!

When deploying to production frequently, automated tests are critical. A big weak point of automated tests has always been the way it generates application data. When trying to run a system level test that involves more than one service there are several ways to generate data for the tests. To name a few:

• Starting from scratch and generating data through the application API
• Each service runs database scripts to load data
• Using a dedicated production copy environment cluster and cleaning up afterward

All methods have caveats and usually result in insufficient test quality, testing against schemas that are not up-to-date and/or having a messy process of maintaining historical upgraded instances.

Ocopea offers a different path. Using the Ocopea API, developers can insert Ocopea into the CI/CD pipeline and use it to orchestrate up-to-date application copies with various sets of pre-defined data sets. Not only will test quality improve, it will also allow developers to debug failing tests on their own environment with identical data. Developers can now easily add new test use cases based on production data that can be re-executed on every build. Instead of maintaining upgradable test instances, there is only one schema upgrade process - the one used in production is also used in tests.

Cloud native platforms simplify deployments by using shared infrastructure among developers. If in the past developers used their own VMs to do development and debugging, with cloud native they simply deployed their instances into a shared cluster. While this simplifies the lives of developers, it can also easily lead to resource over-utilization and lack of visibility into what the resources are being used for. Without visibility into the entire application deployment and its usage - it is difficult to make sense of what is going on out there in the services zoo. Allowing drill-down into which services are being used by developers can lead to significant cost reduction.

In our vision we see application-centric quota management. Implementing this requires standardization of the service consumption API so we can calculate usage of an application consisting of stateless services side by side managed SaaS services. Please join us in our call for action for standardization.

In the mean time Ocopea can still display application centric usage metrics and can be used to get better visibility into the application clusters.

With modern software, the more one can automate - the better. That said, at least for now - our business application code is still being typed by human developers. With frequent deployments to production, errors in production is only a matter of time. Ocopea allows developers to hook into the application copy orchestrator via API and make application copy before each upgrade and perform tests with latest code on fresh production data.