The Service Store is a multi-cloud target environment which allows the launch and in-life management of applications. Customers can also be allowed to insert their own application into the service store. Application packaging allows customers to create a default configuration which is agnostic of which cloud target customers choose to deploy to. STRATEGIC as a multi-cloud broker and application marketplace, offers the following capabilities.
- Support for integration with private IaaS clouds
- Support for public IaaS clouds
- Support for shareable application templates
- Support for reselling of the applications
- Support for reporting on resource usage
- Matchmaking of resources based on EU location
- Matchmaking of resources based on EU legal system
- Federated authentication support
Pilots have been interested in migration projects. The process for a migration requires knowledge about the application installation. A step by step process needs to be established, and automated. There should not be any manual intervention required even when there are multiple scripts, and multiple servers involved.
Our approach consisted in reproducing the installation process manually in order to establish the sequence of events are installations steps required. This process reveals the following:
- Step by step installation commands
- Working Operating Systems
- Cross server configuration requirements
Once this is established the installation script can be written which will execute the following steps: load configuration, install all dependencies, install application. However, fully automated installation scripts also require debugging. This process is done mostly by log analysis. Unfortunately, during long installation processes logs took a long time to be available leading to slow and inefficient debugging sessions. Two main strategies are available to work around this problem. Primarily the breaking up of the installation script in smaller independent instructions. There might be no need for the full script to be run if a failure happens at the end. An entire deployment script can be cloned and renamed appropriately so as to run tests and fix installation issues. The other strategy consists of moving installation scripts in public repositories (e.g. AWS S3, or GitHub) and downloading those scripts on the fly. This has the benefit that errors can be corrected and application launch can be tested without having to access the Service Store package directly.
Some applications can be time consuming to migrate and the process may require expertise from different people in one organisation. Clear governance should be established at the start of the migration process. The migration process requires access to the virtualisation platform enough provisioning should be planned so that accounts being used have all the necessary access rights before working sessions so as to avoid un-necessary last minute cancellations of working sessions.
Applications that need multiple servers and heavy installation processes (e.g. interconnected web servers and large resilient database systems on Windows servers) demand a lot more time and resources. This should be taken into account when resourcing the migration process. As a rule of thumb, a migration process can take between two weeks and two months for bigger applications even if man-power has been resourced correctly.
Some considerations to be taken into account when resourcing include: what is the governance to access to existing application, who is knowledgeable about the software stack deployed, who owns security of the application, who is technically capable of migrating the application, and the security around it. It is also critical to involve the administrators of the virtualisation layer, i.e. who can provision virtual resources. STRATEGIC administrators may also be required if a new Operating System template is required, or for the connection of a private cloud (see next section).
The Service Store keeps a record of application deployment and usage. It is possible for an application owner to obtain reports to measure the success of their application. This includes usage data, and download frequency. There is no billing management associated with the Service Store therefore this functionality is subject to integration with new or legacy application.
Inevitably, changes in Cloud Service Providers APIs require software updates of the Service Store. This has occasionally disrupted deployment especially if the Cloud Service Provider has immature APIs. For instance AWS is extremely reliable and API changes are managed with sufficient warning to minimise disruption. On the other hand Microsoft Azure is more volatile in its functionality and less stable with their public APIs which can create launch issues. Equally, a private, or, virtual cloud update has to be validated by the STRATEGIC administrator ahead of its deployment to ensure compatibility (see next best practice).