Hybrid Cloud SLAs for Industry 4.0: Bridging the Gap

Received: 6th November 2020; Accepted: 11th December 2020; Published: 20th December 2020 Abstract: Hybrid Cloud Service Level Agreements (SLA) comprises of the legal terms and conditions for the cloud contract. Even though all the service level objectives, metrics and service descriptions are clearly outlined in the cloud SLA contract, sometimes vendors fail to meet the promised services and confusing terms lead to tenant-vendor cloud legal battles. Hybrid Cloud involves two different cloud models (public and private) working together, applications running under the hybrid cloud are subject to different availability sets, functionality and parameters developing SLA complexity and ambiguity. The new manufacturing environment (Industry 4.0 concept) is based on a fully connected, intelligent and automated factory, which will highly be dependent on cloud computing and IoT-based solutions for data analytics, storage and computational needs. In situations where Hybrid cloud services are not defined and managed properly may result in Industrial-IoT data security issues leading to financial and data losses. This paper discusses various aspects of the cloud service level agreement in Industry 4.0 for better understanding and implementation and puts a light on the issues that arise out of imprecise statements.


Introduction
Cloud Computing is well-known for efficiently providing computational, storage and resource provision services in a multi-tenant environment, saving process and people cost [1]. Cloud Computing offers different models and services to different tenants based on their compute requirements. Industry 4.0 (I4.0) which is based on the new technologies and communication models (i.e. Advanced robotics, Artificial Intelligent, Big data, Industrial-IoT, 5G, etc.) highly relies on cloud computing for its data processing requirements. Data security is the key factor driving the I4.0 environment, data analysis helps in making efficient decisions related to the production, transparency, product work flow and flexibility. Since 2007, the Industrial Control Systems have suffered cybersecurity breaches (Malware, Keyloggers, Denial of Service, Tampering, etc), Stuxnet, German Steel Mill, Ukraine Power Grid 1 , are just a name to few. Cloud computing offers different applications and services, many of which are provided by third-party subcontractors. Based on ENISA's report, a wide range of vulnerabilities arise when services are provided by subcontractors 2 . Cloud vendors state that these issues can be controlled through a Service Level Agreement but majority of the SLA contracts are improperly defined, ambiguous and end-in vendor lock-in situation, which are discussed in this paper in detail.
Cloud Service Level Agreement (CSLA) measures and monitors the performance and Quality of Service (QoS) promised by the vendor [2]. A CSLA is based on several parameters such as: response times, identity and access management, availability, versioning, etc. Each of these prime uptime or availability as parameters in the application code or database tier. However, this method is limited to static rules and insufficient set of parameters [4]. In [5] many text-only real world SLAs are analyzed and the authors found distinct types of policies which need to be imposed by IT service providers.

SLA Attributes
SLA attributes may vary from vendor to vendor or may use different names. SLA attributes may possess discrete characteristics and features broadening the scope for cloud ecosystem. Cloud models SLA QoS parameters may also vary for different cloud models (i.e. IaaS, PaaS and SaaS) as they differ in terms of applications and service which is discussed in detail comprehensively in this paper. Table 1 depicts a list of generalized SLA parameters. Each parameter may comprise SLA details such as: SLA description, measurement, method and frequency of collection, threshold levels, cloud delivery model and availability for evaluating the SLA QoS.

SLA functionality and dependencies
SLA metrics often share functionality and performance dependencies. Figure. 1 shows the authors designed illustration for service quality metrics called Instance Starting Time Metric (ISTM). The role of this instance is to measure the instance performance based on the frequency, pre-defined vendor threshold, date and time details for instance requested and the duration it took to respond to the tenant requests [6]. Each SLA metric triggers other metrics and sub-metrics such as: average response time, throughput, billing cycles, service credits, etc. These metrics have a predefined threshold, response time and measurement as well. As per [7] cloud risks can be mitigated for vulnerability with SLA guarantees with webservices providing the following attributes, such as: Statefulness, Access, Response-time, Time-out and Versioning. Though, it may exempt potential threats from the SLA such as: hardware, software performance monitors and network failures, Denial of Service, acts of God, scheduled upgrades and backups, etc. Vendors may differentiate with naming the SLA attributes, for example: Elasticity (cloud metrics) may be used by vendors instead of resource provisioning, scalability and agility metrics. For Example: the cloud metrics (i.e. throughput, response time for initiating a new instance www.aetic.theiaer.org AETiC 2020, Vol. 4, No. 5 44 on the IaaS, user-threshold levels, data requests threshold level, resources threshold levels) have a significant impact on the tenant's hybrid cloud performance but majority of vendors do not provide reliable QoS metrics [6] creating confusion and service issues in the hybrid cloud environment.

SLA rules
Service Level Agreements (SLAs) have become highly substantial, as they define policies for the provisioning and implementation of cloud services including the security aspects. The essential Cloud SLAs security requirements, include asset sensitivity, legal, governing policies and cloud providers security competences. This includes the privacy rules and regulations based in different regions in which cloud vendors may store or process the tenant's data. The authors discussed the Data Governance Risk and Control (DGRC) issues in Section 4.3 in detail.
These SLA rules combine the technical, organizational and legal components together. For example, QoS parameter service availability (technical component) falling less than the promised threshold level may activate the SLA monitoring tool (organization component) to report this issue to the cloud vendor (legal component) for violating the promised services.
Like other basic utilities, cloud vendors may also differentiate charges based on prime, peak or standard timings for the resources granted [4]. However, just like terms and conditions associated with IT based services, in a cloud environment the attributes stated in exemptions are automatically voided from the SLA penalty. SLA rules depict the feasibility of the SLA attributes, since tenant requirements may change or vary weekly, monthly or yearly therefore it is compulsory for SLAs to update automatically and be of a dynamic nature in assuring the SLA QoS.
As discussed in Table 1, each SLA may be linked with another set of attributes and needs to follow a relational formalization to calculate the parameter thresholds correctly. The complexity of an SLA increases in hybrid and multi-cloud environments which is discussed in section 4.

SLA categorization
In [4], the authors categorize SLAs as follows: (i) Basic agreement (ii) SLA (i.e. Promised QoS guaranteed 99.5%, 99.95%, 99.99%) (iii) Group SLA as shown in author's illustration (see Figure 1) and Table 1 (a single parameter invoking another set of QoS attributes which must be capable of functioning together) (iv) Operation Level Agreement (Service Agreement with internal partners for operational level guarantees such as network or software providers) (v) Underpinning Contract (i.e. Shareholders).
The nature of SLAs dynamically changes based on tenants demands for computation and resources. Each SLA may be linked with another group of SLAs which need to be met to fulfil the QoS parameter. The basic agreement conceals the overall outline and framework for the cloud services whereas the Operational Level Agreement focuses on the contractual SLA requirements to be met by the internal operational partners. The underpinning contract is based on contracts with external operational partners, if the I4.0 tenant has any this may apply.

SLA pricing policy
The SLA pricing policy [9] is the most critical and confusing characteristic for new cloud tenants. As mentioned before pricing may vary as per peak, prime or standards timings. Another categorization for pricing is: fine-grained or coarse-grained [9].
• Fine-grained pricing may be based on per minute or per second charges [10].
• Coarse-grained pricing is based on hourly basis, whether the resources are fully utilized or not the tenant is liable to pay for the full hour. Previously, well-known vendors offered only coarse-grained pricing offers but with recent competition vendors such as: AWS and Google Cloud Platform have initiated the fine-grained per minute pricing to maintain their monopoly in the cloud environment.
AWS offers per second billing for AWS Elastic Cloud Compute Engine (EC2) and Elastic Block Storage (EBS). Google follows the same trend for its cloud offerings. Fine-grained billing may only be feasible for tenants with less computational needs or tenants running short-run batch jobs at offwww.aetic.theiaer.org peak hours. Tenants who have already bought their computational needs in advance (3-5 years) may not find the fine-grained pricing attractive as they generally need computational resources round the clock 3 .
Based on tenant's contracts, services are provisioned. For example, a flexible tenant contract may grant a leverage for requesting more resources as the computational demand increases, unlike fixed contracts where additional resources may not be granted or may be subject to availability. Cloud Instances offered by cloud vendors comprise of the following features: operating system, computation, memory, instance, storage type, storage region and category of the contract 3 as shown in Table. 2. AWS 4 further categorizes its instance types as following: • On-demand instances follow the pay-as-you go strategy without any prerequisite condition. • Reserved instances are only granted when a prerequisite for a long-term con-tract and upfront consumption costs is approved. • Spot instance function based on bids and on-spot prices which varies based on available instances. Spot bidding provides cost benefits since workloads can be ended anytime whereas spot-blocks are subject to fixed interval, it does not intervene in terminating the instance midway, but the processing may finish when the allotted time-period is over. Cloud computing deployment costs add up with the following services: Premium CPU Platforms, Red Hat Enterprise Edition Images, SQL Server Images, network pricing (i.e. ingress, egress), load balancing (i.e. ingress and egress charges) and protocol forwarding, traffic through external IP address, Virtual Private Network (VPN), disk pricing, unused IP address pricing, etc.
Cloud vendors exempt the pricing offers for small instances and length of contract. Therefore, it is necessary for I4.0 tenants to evaluate the costs from all aspects before adopting the cloud platform. Pricing schemes, Virtual Machines (VMs) and instance types have been discussed in detail in [9]. Cloud vendors may change the cloud pricing schemes as any time giving a short notice period to the I4.0 cloud tenants to make a decision, leaving them in a vendor lock-in type situation.

SLA management for Public, private and Hybrid Cloud
Public cloud SLAs depicted on cloud vendors website are generic and may not show the technical aspects of the cloud and SLA management. For example: AWS SLA which was last updated on February 12, 2018 [13] states "Service commitment definitions associated to availability zone, monthly uptime per-centage, region unavailability, service credits and commitments, payment methods and SLA exclusions only". There is absolutely no detail provided of how the SLA will be managed when services are subcontracted to third-party subcontractors. Public SLAs may only be monitored by the provided vendor's graphical user interface cloud portfolio. If tenants require additional security they may have to purchase additional packages in AWS (i.e. AWS Inspector, AWS CloudWatch AWS CloudTrail) 8 , Microsoft Azure (Cloudyn and Azure Monitor) and Google (Google SlackDriver) 9 . These additional services assist in services managing and monitoring, but they do increase cloud management costs too. For example: The AWS Inspector 5 pricing is based on agent-assessment and is calculated as following: No. of assessment runs x No. of agents or systems assessed during those runs = agent assessment.
Where α represents the no. of assessments runs, β represents the no. of agents or systems assessed during those runs and γ represents the agent assessments. α x β = γ (1) An on-demand billing period is one calendar month like all AWS services. The pricing of each individual agent-assessment is based on a tiered pricing model. The more volume of agentassessments in each billing period the lower a tenant may pay, but it is still an additional cost.
Private clouds are based on-premises and may not be subject to unavailability, as there are alternative storage and network paths defined to keep the IT operations running in IT failover situations. Private clouds may only monitor SLA for applications (i.e. ERP, DSS, etc.) bought by software houses for supporting their core business performance.
The hybrid cloud is a fusion of private and public cloud services with communications between the platforms for IT operation management. This model provides a business flexibility to focus on their core business and different deployment models. Aside from the benefits, hybrid cloud model may present technical, business and cloud management challenges. Hybrid cloud SLAs need to be managed effectively. Previously I4.0 tenants were only running their non-critical business processes on the public cloud and keeping their critical data and applications on the private cloud but currently tenants prefer running applications on the hybrid environment due to latest IoT based services provided on the public cloud. Industrial applications running on the hybrid cloud must be designed to function in sync, be compatible and fully integrated, to avoid complexity.

Vendor Service Level Comparison
This section differentiates and highlights shortcomings in different vendor SLAs.

Vendor Service Level Agreement
SLA Metrics are parameters for assessing the SLAs performance levels based on a variety of parameters, such as: computing, storage, scalability, availability, etc. Table 3 highlights the types of service offered by well-known cloud vendors, Amazon Web Service (AWS) and Google Cloud Platform (GCP) aggressively and do have options for I4.0 tenants who wish to switch from AWS to GCP or GCP to AWS 10 . The vendor services for each architecture (IaaS, PaaS and SaaS) also vary based on their expertise and global reach to third-party subcontractors. AWS is more IaaS focused where as Microsoft Azure concentrates on the PaaS and SaaS architecture. Google Compute Platform (GCP) inclines to support start-ups and focuses on SaaS and lastly IBM build its own services and has contributes 50-75% in SaaS, PaaS and IaaS architectures. Amazon Web Services (AWS). AWS's generic SLA has already been discussed in Section 2.6, however each product or service AWS offers is subject to a separate set of SLAs in terms of performance, availability, exclusions and upgrades. AWS offers a wide variety of instances, applications, services and serverless computing and integrates seamlessly with other Amazon services. AWS being the pioneers in the cloud sector have been the longest in this industry compared to the others which means that a lot of sub-services and tools for cloud deployments all support AWS integrations 4 . Amazon EC2 service exclusions: "The Service Assurance does not apply to downtime, interruption or service closure of EC2/EBS performance issues in terms of force majeure, subcontractor service downtime, region inaccessibility, software or hardware failure, etc. If availability is clogged by issues different from the those listed in the monthly uptime percentage calculation, then AWS could grant a Service Credit considering such factors on the vendors choice" 5 . Majority of the service violations are simply exempted by AWS by placing them in the SLA exclusions, which means that I4.0 tenants may not be eligible for service credits despite of experiencing an outage. Data confidentiality, integrity and availability are essential for I4.0 at the IT/OT level. Failure to comply with these requirements may lead to complete system failure, loss of control, product defect, financial or human loss.
Microsoft Azure. "Microsoft Azure's SLA describes Microsoft's provides assurance for uptime and connectivity only" 6 . The SLA for individual Azure services are listed explicitly which means each service (i.e. compute, networking, storage, security, monitoring, etc.) has a different availability, upgrade, region and exclusions. Tenants moving their applications on to the vendors cloud may have to track multiple SLAs since each service may be subject to unavailability at a different time leading the tenant's IT operations to halt. Recently, a load-balancing fault lead Hotmail to 12 hours of downtime in the UK and European region, despite having fault and network management configurations, cloud vendors may suffer unplanned outages [12]. Microsoft Azure offers a singleinstance VM SLA of 99.9% on VMs backed by Azure Premium Storage and 99.95% SLA for availability sets 6 . An Availability Set denotes to multiple VMs installed across diverse Fault Domains avoiding lone failovers. Azure offers smaller and flexible server configurations. VMs perform better providing flexibility as compared to AWS but is limited in terms of VM Instance types. Alike AWS, Azure stores data in Blobs but is offered at different SLA levels such as 4 : Locally redundant storage (LRS), Zone redundant storage (ZRS), Geographically redundant storage (GRS) and Read-Access Geographically Redundant Storage (RA-GRS). Azure offers multiple availability zones, greater resilience and Databox which gives the tenants mail the flexibility of up to 100 TB of data from private datacentres to the cloud. Azure would be a smart choice for I4.0 tenants requiring workload with low latency, a range of datacentres, and comprehensive VM settings. The pricing structure 11 is based on either pay-as-you-go instances or advance payments for reserved instances which may offer discounts at times as well.
Google Cloud Platform (GCP). GCPs SLA describes different service levels for each of its application provided to the tenants. The GCP terms of service clause covers the GCP license agreement as follows 7 : provision of services, billing terms, Intellectual Property Rights, use of tenant data, termination clauses, assurances, exclusion, etc. Google supports customized and assorted instances and provides control over tenant-defined machine/instance settings, but complications may arise while running N-amounts of machine/instance types 4 . GCPs sustained-use pricing for compute services provides flexible approach to AWS's reserved instances 7 . Based on tenant's continuous consumption, the on-demand baseline hourly rate automatically implements the discount on the tenants' account which means that there are no upfront requirements for concessions. GCP overcomes the latency issues with its global network infrastructure that Google controls, but this may require the tenant's workload to be processed in region specific datacentre 7 . As per GCP Terms of Service clause 12, disclaimer states "Google and its sub contactors do not guarantee any sort of assurances of merchantability, capability for a precise use and non-infringement. GCP and its sub-contractors exempt responsibility for tenant's data processing, transfer and backup and do not authenticate that the software's/services operating on the cloud will be uninterrupted" [12]. Based on the above, GCP does not take responsibility in terms of service failures, force majeure, services which are out of their control or service denials that may take place due to a cloud broker or third-party sub-contractor leading the tenant vulnerable to security and DGRC, such requirements are essential for I4.0 tenants.
International Business Machines Clouds (IBM Cloud). "IBM 12 does not assure an error-free, continuous cloud service operations or avoid third-party disruptions or unauthorized third-party access. These guarantees fall under the exclusions such a misuse of services, damages, modification, noninfringement, etc.". Considering the above-mentioned SLAs, the I4.0 tenants would be susceptible to a number of security-based risks.
The cloud SLAs published by AWS, Azure, GCP and IBM, make it evident that none of these vendors guarantee the cloud QoS, processed on-premises or via a third-party subcontractor leading the tenant susceptible to operational and security-based risks. Table. 4 illustrates service comparisons between AWS, Azure, GCP excluding IBM, as IBM does not provide its service details publicly. Billing Dashboard: AWS shuffles around zones/account which makes tracking complex with respect to zone correspondence. The billing is stated by spot-pricing sometimes whereas invoicing documents fail to refer to specific zone alphabetical notation. The cloud expense is accumulated as line entry where dissimilar line items have rate pointers. These rates are multiplied by the consumed resource quantities following a predictable denormalized data scheme that is compatible with multiple analysis tools 13 . Cost Considered cost friendly and competitive, but the pricing and offering lead are quite confusing, on the other hand the bill lack clarity of how data is being processed in another region than defined and billed. Security Azure Disks support 99.999% uptime allowing I4.0 tenants to have multiple data replications enabling high tolerance against failures. This architecture provisions Azure to continuously deliver enterprise-grade robustness for IaaS disks. The tenant data is routinely encrypted at rest which might be of concern for the I4.0 tenants data security. Disk resources can only be accessed by other instances within the same zone. Disks attached in one zone as an instance cannot be attached to other zones. The Standard persistent disks, SSD persistent disks, Local SSDs, cloud storage buckets are supported by all machine types and available at regional zones but the availability % is not mentioned. GCE encrypts tenant's data before it moves to the persistent disk storage space and these disks stay encrypted with system-defined keys/tenant-supplied keys. Support 13 Good Database Cloud SQL Network Networking per VM is consistent and higher than AWS. The achievable network capacity is based on the number of CPUs tenant's virtual machines has. GCP provides the flexibility for defining specifications and delivering anticipated throughputs but does not provide fixed bandwidth for network attached storage but has higher network availability. Availability Zones (AZ) Persistent. Zone failures managed by load balancing and regional/zone diversity 13 regions globally 7 Billing Approximations are provided based on which the tenants can build Data Studio reports 12 . From a network logistics standpoint, GCP leads in zone labelling and provides same zone names for all tenants. The billing is exported into BigQuery, each line entry is a combined over a span of accrued usage and have subcomponents of credits. Their current billing has the following flaws (i) auditing is very hard, the tenant must take the numbers as presented, calculating the figures independently is hard. (ii) calculating estimated spend is complex, accumulating extra jobs for the financial teams 12 . Cost Cost effective cloud for certain applications and for new cloud (tenants), as billing is based on fine-grained criteria. Security GCP Cloud IAM, Cloud Platform Security Overview, GCP DoS Protection, GCP VPC, GCP Physical Infrastructure Security, etc.

Monitoring
Google StackDriver (monitoring, logging, and diagnostics for GCP and AWS apps).

Other Features
The GCP offering of custom machine types. AWS EC2 and GCP both supports networked and locally attached block storage. Commonality AWS, Azure and GCP support containers Cloud Failures: AWS, Azure and GCP have their own set of limitations and all have undergone outages and failures, and therefore there are so many exclusions mentioned in Vendor SLAs. Threats: Hardware failure, software failure, acts of God, network issues not in direct control on the vendor, scheduled upgrades, indemnification, force majeure, misconduct of service by a third-party or tenant, scheduled upgrades, etc. AWS target attacks are quoted to be in hundreds whereas GCP is subject to more than 100,000 attacks per day 13 . Cloud computing is a heterogenous environment forming new models and architectures, each diversifying in services, application and performance. The conventional cloud models are unfit in terms of the current computational demands and architectures because of: (i) Lack of standardization in the SLA specifications and parameters leads to confusion in a multi-cloud hybrid environment (ii) Customising issues. (iii) Cloud heterogenous models require visibility, insights, flexibility, reliability, compatibility and platform independence for monitoring and managing the hybrid, multi-cloud and federated cloud deployments. www.aetic.theiaer.org

SLA Variations for Cloud Architectures
This section discusses the SLA complexity with respect to different cloud architectures. Cloud computing offers three architectures: IaaS, PaaS and SaaS and each of these architectures are subject to different availability and QoS parameters. The authors focus on mainly the IaaS architecture through the rest of the sections as Industrial sectors mainly rent the computational and infrastructure-based (i.e. servers, storage, applications, etc.) services from cloud vendors. Although the tenant pays for all the resources used on the cloud vendor's infrastructure, the vendor only holds responsibility for the virtualization, servers, storage and networking layers which may also be subject to the SLA uptime and availability. PaaS is renting the cloud platform for building applications and is usually implemented by programmers who do not wish to invest in platforms as renting the resources has a cost benefit and ease of access to the services. The cloud vendors hold responsibility for all layers apart from the application and data management. SaaS is using Software as a Service. For example: Enterprise Resource Planning (ERP) Software, Microsoft 365 online, etc. Since it is a consumer application and provided by the vendor, therefore it holds responsibility for all layers. Any packaged or third-party software used by I4.0 cloud tenants which may run on the cloud vendor's infrastructure may solely be the tenant's responsibility. Table 5. summarizes the well-known cloud vendors architecture offerings 7,17 and liability 18

IaaS Issues
This section briefs the IaaS architecture, Hybrid multi-tenancy cloud challenges, database scalability, web services and legal issues associated to Service Level Agreements QoS.
Since AWS, Microsoft Azure and GCP do not publish their architecture blueprints the authors continue this section with IBM cloud providers SLA monitoring and management model (i.e. IBM multi-tenant cloud IaaS) as shown in Figure. 2. The authors believe that vendors AWS, Azure and GCP may implement a similar IaaS model like IBM. IBMs cloud infrastructure consists of cloud catalogue, virtualization, infrastructure, storage layers, etc. These layers need to be aligned with security and compliance measures.

Hybrid multi-tenant, multi-cloud IaaS model
A Hybrid Cloud is a fusion of a public and private cloud model. Cloud vendors encourage multi-tenancy to fully optimize their virtual resources and capacity. Since multiple tenants share the same virtual infrastructure it is susceptible to various risks such as: hacking, data theft, identity and access management (IAM) and Denial of Service (DoS), etc. which is a major security issue for I4.0 tenants.
Existing I4.0 tenants which run their applications on their existing private cloud, need to customise and integrate applications, considering the risks it may pose before migrating them on a hybrid cloud (multi-tenant environment). Migrating private clouds on a vendor's environment may require complying with the cloud standards and security measures (as shown in figure 2). The authors emphasize, that situations in which an Industrial tenant moves moves its multiple private clouds processing to the hybrid multi-tenant environment, security and compliance of the applications and services need to be orchestrated and automated across the IaaS model. The authors have designed a model of their recommendation as shown in figure 3.

Hybrid cloud multi-tenancy challenges for Industry 4.0 tenants
This sub-section highlights the challenges associated to a hybrid cloud multi-tenancy. Multitenancy requires I4.0 cloud tenant's integration at the following levels: (i) Data Centre (DC) layer (ii) Application (iii) Infrastructure layer [13].
(i) Data Centre (DC) services are provided by a cloud vendor or further processed with a sub-contractor hosting network, storage and computational resources within the same regional premises configuring security measures such as: firewalls and access controls to prevent tenant's applications and services from malicious attacks in the compute shared environment.
Multi-tenancy at application layer is challenging since tenant applications require modifications/redesigning of the existing software at the architecture level [13]. It also adds complexity while migrating/processing Industrial legacy applications on the hybrid cloud as the applications were not initially designed to function on a hybrid environment. Programming languages used for previous generation of software's had limitations in terms of scalability, reliability and were often hardware specific. Cloud vendors provide access to I4.0 tenants via web services or Hyper Text Transfer protocol (HTTP) interfaces which act as pointers to directly access the tenant's applications. Vendors differentiate the tenants by linking their account details in the HTTP Uniform Resource Locator (URL) making the process simpler for tenant requests [13]. Application servers have a significant impact on the application layer as it modifies the way applications are installed and configured [13]. Tenants anticipate the application servers to provide high performance and scalability during peak processing hours. The www.aetic.theiaer.org application code changes are required as multiple tenants are running their applications on the same server which may lead to lower or higher response times depending on the number of transactions being processed. As mentioned before, the I4.0 tenants application security is a matter of concern as it shares the same application server and logical system memory with the other cloud tenants on the VM [13].
Many cloud vendors pre-configure the Infrastructure layer making it easier for physical or virtual resource deployment, since it exempts the need for application code modifications until and unless the applications have specific requirements [13]. Insecure Application Programming Interfaces (APIs) [14] may lead the I4.0 cloud tenants susceptible to authentication, authorization, access control and monitoring of the application during runtime, leading to a high-level security breach.
Cloud servers capable of hosting multiple VMs allows multiple applications from multiple tenants running under the same VM making it vulnerable to malicious attacks. The complexity lies in tracing the security incident as information is traced out due to large volumes of write operations on the storage media [13]. Database scalability requires to be aligned with application and infrastructure layers. Multi-tenancy is implemented at the application-layer and may need to adhere the database schema patterns which apply to multi-tenant architectures. Multi-tenant databases issues can only be prevented if the tenant's applications are designed considering the database sizing and following the vendor's recommended database table spaces. Since database scalability is implemented on two different layers the SLA availability set may vary and the overall performance may from 99.95% to 99.5%, as the SLA is assessed cumulatively.
Resource management needs to be planned at the network level as well which is subject to a different SLA. Cloud Vendors may implement network and deployment topologies for distributing and replicating services in different clusters to overcome the availability and scalability limitations. The deployment topology assists in identifying the resource services mandatory for hardware and OS, since each service may require JDBC, reference libraries, etc. Multiple tenants retrieving the same hardware, application servers and databases may have different response and performance times leading to exhausted HTTP server, connectivity issues, dropped service requests, etc. To overcome this type of issue vendors, implement shared application servers based on tenant's transactions but this may increase the complexity with configuring, installing and automating the server deployments features. Each tenant applications and service are bound with an SLA, distributing a tenant's application on multiple clusters may increase the privacy, Identity and Access Management (IAM) and data breach-based risks as discussed above. As discussed in Section 2.2, 4.2 and 4.3 Multitenancy across different clusters is complicated, if the I4.0 tenant's services are processed at multiple regions, and services outsources to a third-party sub-contractor, this may only lead to monitoring, visibility, outages and control-based issues. Figure 4 is adapted from IBM (for illustration purpose only) to explain the mechanism of SLA parameter definitions based on Web Service Description Language (WSDL). Considering a heterogeneous computing environment, where a single metrics assessment depends on multiple sub-metrics functionalities. With so many dependencies and complexity, the I4.0 cloud tenants will definitely end in a vendor lock-in. The WSDL toolkit may overcome SLA monitoring and privacybased limitations in a tenant-vendor-subcontractor situation but will only be possible if three of them implement the same toolkit [25].
A cloud vendor may sub-contract tenant cloud processing to multiple third party subcontractors based on the conditions of installing services on the sub-contractor's domain itself and may only make I4.0 tenants SLA visible which are being processed on the sub-contractor's domain. This model may hold the following possibilities: (i) Tenant, vendor, sub-contractor (ii) Multiple tenants, one vendor, one sub-contractor (iii) Multiple tenants, one vendor, multiple sub-contractors. Multiple sub-contractors may be added for same or different tenant cloud services by the cloud vendor subject to using the same web-service toolkit which is again a vendor lock-in situation.

Web Services
Services using standard XML messaging system and independent of operating systems and programming languages available over the internet are called web-services [15]. "A web service is described as an application that accepts XML-formatted requests from other systems across the network" 20 . Web service technology [16] "depends upon specific XML standards such as: Simple Object Access Protocol (SOAP), XML-RPC (Request Procedure Call), or Representation State Transfer (REST) for messaging, Web Service Description Language (WSDL) for explaining the service interface, XML Schema for describing data types, and Universal Description Discovery and Integration (UDDI) for publishing and discovering service metadata". The two essential components for a web service are: selfdescribing/service publishing, self-discoverable/ser-vice identification and service execution [17]. Web Service Description Language: The WSDL follows syntax-based web-services, missing auto discovery and composition features [18]. Since services cannot be automatically discovered, they cannot be invoked, this is where the semantic web services such as: Web Ontology Language for Services (OWL-S) 21 and Web-Service Modelling Ontology (WSMO) [19] may benefit as semantic web services can analyse key-words of similar meanings and invoking services. Figure 5 illustrates the model for SLA monitoring based on the WSDL toolkit. This model measures, evaluates and responds based on service conditions and violations, this service may also be extended to thirdparty subcontractor's (based on different services providing an abstracted SLA for gaining vendor control). Many examples of third party sub-contracting have been presented by [20] leading to vendor negligence on sub-contractor assessments. The sub-contractors were essentially hardware suppliers with no proper backup setups, loss of data because of inadequate quality storage and lack of expertise. Such risks may lead I4.0 tenants to major data security issues.
SLA service levels [21] are defined to assess performance levels of the deployed web-service based on a list of performance metrics such as: availability, latency, response times, etc. at the hardware, network, storage levels, etc.

Set of SLA management mechanisms addressing the SLA life-cycle
SLAs between a cloud tenant and vendor may function in stages of a life-cycle as illustrated in figure 6. Different vendors may follow the SLA life-cycle differently. For example, vendors may implement multiple services such as: deploy, provision and enforcing SLAs in a single stage or may interpret them with different names. The Web Service Agreement (WS-Agreement) and WSLA Language and Framework standards are widely applied for stating Service Level Agreements in an Service Oriented Architecture (SOA) [11]. The WSLA framework consists of SLAs in an Extensible Markup Language (XML) [22] file which is exchanged back and forth during the SLA lifecycle [12]. Vendors implement their pre-defined architectures to assist in monitoring compliance, provisioning, classifying the services and providing near real-time logs for multiple tenants, differentiating them based on the type of web service opted for 5 . This model however does not work in the hybrid multi-cloud ecosystems and hybrid third-party subcontracting environments, since the tenants lack visibility and control.
Cloud vendors do not provide hybrid models therefore existing and possible issues related to SLA Orchestration and complexity have been discussed via author designed hybrid cloud models. The authors also felt that redesigning of application specific SLAs need to be addressed since every application is subject to different service levels, which ultimately affects the availability and other QoS parameters. The tenants deploying hybrid cloud realise the SLA QoS issues and limitations post-migration.

Cloud SLA Legal and Privacy aspect for Industry 4.0
The legal issues in the hybrid cloud environment are the most critical ones, few of which are as follows: (i) cloud vendors do not hold responsibility for any data loss, breach, malicious attack, unauthorized access, damage, etc. (ii) vendors processing tenant data in restricted geographical regions (iii) passing back and deleting the duplicated data after the vendor contract is over (iv) SLA exclusions (v) third-party sub-contracting liability (vi) credit terms, etc. Outsourcing data raises privacy concerns [23] due to lack of user control, visibility, transparency, multi-tenancy and VM based vulnerabilities, data governance risk and control, etc. Standards for Hybrid Clouds: Implementing cloud standards such as [12]: Open Cloud Computing Interface (OCCI), Open Grid Forum (OGF), Topology and Orchestration Standard for Cloud Applications (TOSCA), Cloud Data Management Interface (CDMI), etc. have become aggressive on tenant's demand and encouraging new tenants to adapt the cloud ecosystem.
Industry 4.0 is the next generation of smart factory involving new communication models and techniques. With thousands of IoT based devices transmitting data, insights, visibility, control and end-to-end security are a must requirement for SCADA (Industrial Control Systems). Industry 4.0 strictly adheres to the Industrial standards (i.e. IEC 62443 for cybersecurity, ISO 27001 for Information Security, etc.) but none of the cloud vendors follow a unified standardisation approach. Considering the above mentioned facts and SLA criteria, lack of knowledge/expertise in cloud SLAs may open up major security-based issues for Industry 4.0 tenants.

SLA Limitations in the Hybrid Cloud environment
Interoperable Service Level Agreements which may function independently with different cloud vendors and be understood irrespective of the platform limitations may be the only solution to overcome the existing issues highlighted in Section SLAs existing issues.
Currently, I4.0 cloud tenant migrations have only been possible at the application or database tier, since standardization and functionality has not been achieved at the web-service level yet. Cloud vendors individually deploying specific tools, implementation techniques and infrastructure governing software wish to maintain their monopoly and vendor lock-in situations, making the migrations for tenants from one platform to an-other difficult [24]. Some API designers intentionally build limitations to stop direct access to the internal features, limiting the scope of cloud vendors [25].
A wide number of projects [26] such as: Kubernetes, Docker, Mesos are working towards hybrid cloud standardization but this is yet formed in the container-oriented virtualization level. XML Schema (i.e. DProfSLA schema) for monitoring applications being under compliance with the promised SLA [27]. SLA Management mechanisms and architectures for hybrid cloud computing have been proposed by [28] [29] and [30] but these proposals have not been implemented by cloud vendors yet. Hybrid multi-clouds SLA complexity results in ambiguous operational management of the cloud, tenants find it hard to track and manage individual SLAs since the multiple applications running relate with each other. SLAs have multiple functionalities to provide: to adhere with tenant's application and data security, monitoring, visibility and control [22]. The core solution only lies in implementing a standard on the entire model, making it unified and easy to implement. As mentioned above, many vendors, projects and research has been proposed related to standardization but since it is an individual effort, the I4.0 tenants need to buy tools or implement frameworks or APIs to achieve the desired customization and flexibility in the hybrid cloud.
Extensible Stylesheet Language Transformations (XSLT) may be a possible solution for transforming different dialects of SLAs. XSLT 22 approach transforms XML data from one format to another, the result form is an XML file, but it can change XML data into other formats by producing a XSLT stylesheet and processing the data. Changes required at the output can be achieved by making variations to the stylesheet and pro-cess it again. This provides benefits to nonprogrammers, who can alter the stylesheet and change the outcomes. Figure 7 illustrates a I4.0 cloud tenant, vendor and sub-contractor SLAs, since all parties are using different dialect of an XML, the XSLT based framework translates the SLAs into a unified one to understand different attributes, functionalities and specifications to be delivered. This framework acts as a mediator which translates information requested and responds back in the cloud actors (i.e. tenant, vendor, broker, auditor, etc.) own dialect. Few researchers [2][11] [27] realized limitations associated to SLAs and designed frameworks for overcoming the existing issue. The frameworks were based on XML schemas have not been yet implemented due to vendor resistance and security-based issues. However, the WSLA framework is implemented by IBM WSDL Toolkit, since it provides interoperability only if the I4.0 tenant, cloud vendor and subcontractor use the same platform and not otherwise, thus leading to another vendor lock-in situation and leaving the issue unresolved.
This research was based on designing our own XML dialect, but was already done in past by some authors and has been limited to open source projects. The authors thus designed a Six Sigma Cloud Framework (SSCF) to overcome the cloud QoS issues. The Six Sigma Cloud Framework assists tenants/enterprises in being proactive, assessing the anticipated the Hybrid Cloud QoS before entering the cloud model. It also highlights the limitations, lock-ins and service breaches beforehand which helps the I4.0 tenants in negotiation and finding alternative solutions to overcome the hybrid cloud service breach. The fish bone cause-and-effect of the framework is presented by authors in [31]. Since this aspect of the project did not match with the dimension of this paper, the authors did not include this in the paper as it will form the basis of future publication.
Standardizing the Hybrid Cloud model would help in securing the system better. All vendors need to work towards a common goal to secure the Cloud IaaS making the deployment and I4.0 tenant adaption easier. Vendors resistance may only lead to alternate solutions of adapting and designing more cross-cloud platforms and applications, using transforming tools and frameworks.

Discussion
The study of uniform and standardised Service Level Agreements has been widely researched from different angles (i.e. toolkits, XML-based schemas, languages, standards, IT-operational management, etc.) since it can control and improve the cloud QoS. Cloud tenants have been actively looking for alternatives and solutions to mitigate vendor lock-ins, this is where the cross-cloud platforms tools, APIs and Frameworks assist, but cannot be considered as an ultimate solution since new cloud models are being commercialised without the underlying SLA being standardised. www.aetic.theiaer.org

Conclusion
Cloud Service Level Agreements play an vital role to manage and control the services leased by cloud vendors to the tenants. The Industry 4.0 environment depends on new communication technologies (IoT, Cloud Computing, AI, Robotics, etc). for automation, scalability, agility and process efficiency. In a self-driving, self-learning industrial environment, data security plays a vital role and needs to be secured by all ends (mediums over data is travelling and being processed). This is why it is important for cloud services to provide secure and standardised service. Cloud vendors conceal business and technical (underlying architectures, tools, management consoles, etc.) limitations, standards and QoS (availability, scalability, multi-tenancy and latency) issues smartly within the SLA and may go unnoticed by non-expert cloud tenants. Standardisation and transparency are compulsory for a successful cloud implementation. This paper acts as a catalyst bridging the SLA gaps between Industrial cloud tenants and vendors and developing insights on cloud QoS issues which otherwise stay disguised/unknown to the non-expert.