The legal aspects of multi-cloud: DECIDEdly not unimportant! Part 1 - The Sock Shop

As the DECIDE project is quickly taking shape, the consortium leaves no stone unturned to ensure that the project’s results can be exploited in a fast-paced production environment. One of the aspects that are being duly considered is the legal side of things.

In a series of four blog posts, legal partner time.lex gives a high level overview of some of the main legal challenges surrounding the project. At this stage, several questions remain to be answered. The intent of this series of blog posts is to clarify which points are still to be addressed by the consortium. Future blog posts will provide answers and justification for the choices made.


Before diving in to the legal aspects, a basic understanding of the project and its aims are necessary.

As the reader might be aware of, DECIDE stands for “DevOps for trusted, portable and interoperable multi-Cloud applications towards the Digital single market”. Somewhat simplified this means that DECIDE aims to provide a framework of tools for continuous development of software applications that are made in such a way that they are suited for a multi-cloud scenario, while remaining safe and secure, portable, interoperable and overall smooth-functioning. The multi-cloud scenario refers to the use of different cloud resources, originating from multiple heterogeneous cloud service providers, to make up one single application.

The idea is that, if so designed through the DECIDE architecture and patterns, an application can be broken down into functional components, or micro-services, which can be deployed separately, thus allowing the whole of the application to be deployed in a distributed manner, across different cloud service providers in a composition that has, through another DECIDE tool, has been deemed optimal. Moreover, the DECIDE tools enable the application to seamlessly be re-deployed in another configuration should some micro-services be unavailable or under-perform, making the application as a whole portable across multiple heterogeneous cloud service providers. This multi-cloud approach reduces the reliance on a single cloud service provider while potentially reducing i.a. risk and cost, and enhancing i.a. scalability and availability, without touching upon the performance of the application.

The Sock Shop – A Practical example of DECIDE in action

The Sock Shop example application selected by DECIDE can illustrate this in more concrete terms. The Sock Shop application is a website meant for e-commerce, i.e. online sales, specifically for the sale of socks.

It can graphically be represented as follows:

Image source:

As one can see the shop consists of different micro-services: a front-end for the user to interact with and several underlying functionalities, enabling the user to register a profile, browse the catalogue, add things to the shopping cart and place an order, after which a shipping workflow is activated.

The application, which has been used to test the DECIDE tools, is broken down into as many microservices as possible and these micro-services are distributed over distributed cloud services providers. The specific configuration has been chosen by the application developer after having been recommended by the DECIDE OPTIMUS tool and take into account all the non-functional business requirements of the online web shop, which, hypothetically are:

  • Scalability: during morning hours and after 8 PM users are considerably more active. The application needs to be able to process many more queries in this timeframe
  • Performance: this essentially relates to the overall functioning of the application from the user’s side. Users expect both the rendering of the website to be extremely fast and the transaction speed to be high (e.g. less than 2 seconds), enabling a comfortable experience.
  • Availability: in order to not lose potential customers and maintain a strong reputation, the application should be available upwards of 99% of the time.
  • Cost: since the sock shop is a start-up, keeping costs to a minimum is of vital importance.

DECIDE allows for a clear overview of how important non-functional requirements are addressed in several proposed configurations, leaving the application developer (here the website developer) the choice to pick a deployment configuration. Once a deployment has been selected that satisfies the developer’s wishes, the corresponding cloud services are contracted through a DECIDE tool called ACSmI (Advanced Cloud Services meta-Intermediator).

In very simplified terms, ACSmI is a catalogue for cloud services that have been endorsed into the system, providing input on the specifications of those cloud services in terms of non-functional requirements to OPTIMUS. For example, if the non-functional requirement of availability is set at 99.5% for the application as a whole, a cloud service guaranteeing only 99% in its SLA will not be considered. This process is legally very relevant since it involves the extremely dynamic contracting of the cloud services, as will be elaborated upon below. Moreover, certain legal requirements or legally relevant requirements (e.g. location of the data) may come into play here, being non-functional requirements for the application as a whole themselves. Once the services have been contracted through ACSmI the application can be launched through ADAPT and is operational.

However, the DECIDE approach does not end when the application has been deployed. The DECIDE tools aims to provide a DevOps framework, where software development and software operation are unified. This means that the DECIDE tools provide for continuous monitoring of the application, so that adaptions might be made where necessary. An important DECIDE tool in this regard is ADAPT, which also monitors the functioning of the application. A key function of ADAPT is that it enables the re-deployment of an application when certain micro-services are underperforming or unavailable. Underperformance is measured by reference to certain threshold values of the non-functional requirements set for the application. Take availability as an example. If the minimum availability is set at 95% and the application dives below that, a new configuration might be needed. This means OPTIMUS again provides optimal configurations, which are then contracted through the use of ACSmI. Depending on how sensitive the application is, the re-deployment can be more or less automated. For a non-sensitive application, re-deployment might happen fully automated (i.e. without any intervention on the part of the application developer) and very frequently. Assuming the sock shop is not sensitive, in order to meet the non-functional requirement of keeping the cost at a minimum, re-deployment should happen several times every day in order to deal with varying demand during different times of the day, ensuring sufficient capacity at peak times while limiting excess resources at times of low activity.

Having discussed the main functionalities of DECIDE, it is time to look at the legal aspects surrounding the project.

Legal challenges

One of the main take-aways from the foregoing is that DECIDE’s multi-cloud approach provides for a very dynamic scenario. Only the application description and its non-functional requirements stay the same, whereas the cloud resources and the cloud service providers providing them can change rapidly and often. This presupposes a very lean and flexible contractual framework, which is worth looking at. Moreover, changing between cloud services and cloud service providers dynamically means that the data contained in the application will also will need to be shifted rapidly and potentially quite often, meaning that the data may change physical location and questions of control over the data may arise. Another thorny issue is the application of the General Data Protection Regulation (further: GDPR) to the data contained in the application and the impact of this finding. Moreover, even in the hypothesis of purely non-personal data, restrictions might apply, limiting the multi-cloud approach for applications containing non-personal data that is covered by one of the originally 45 detected data location restrictions within the EU in regards to non-personal data.

The most pertinent of these legal challenges are discussed in the next three posts, specifically in terms of how they affect the project. Each blog post tries to elaborate on how DECIDE should deal with this challenge, based on the information currently available at this stage of the project.