Future Work Needed Kenneth Wade Najim Yaqubie

Outline 1.Model is simple 2.Too many assumptions 3.Conflicting internal architectures 4.Security Challenges & Risks 5.Reliability Concerns 6.Legal issues, regulatory issues 7.Tradeoff is insignificant

Model is Simple No tests under any significant load “the applications we consider are typically overprovisioned” in regards to lacking a queuing model. No failure scenarios discussed Uses a single cloud-based app on Azure test bed “We consider a simple model for measuring benefits” “We limit our discussion of variance to transactions that may be modeled as a path of components.” No discussion on parallel threads, atomicity of transactions Explicitly states that issues in regard to scaling optimization is not explored. Not really hybrid, assumes entire entities are fully cloud-based or locally maintained (databases)

Assumptions “All associated storage and servers are either maintained locally or entirely migrated” Assumption of full transaction information is available. A linear cost model for internet transfers Interdependent components will be affected, compounding costs The number of times each transaction is encountered “does not influence the delay experienced per encounter” Assume that components are EITHER computationally intensive or storage intensive, not both or neither. No account for heterogeneity in perceived benefits across servers in either classes.

Dissimilar Architectures Current enterprise apps can't be migrated conveniently Trying to migrate ACL policies using their migration model acknowledges a “slight growth in rules is due to an inconsistent policy in the original network” These inconsistencies are inherent in functioning networks Each of the major cloud providers (Amazon Web Services, Google App Engine, and Microsoft Azure) imposes an architecture dissimilar to the common architectures of enterprise apps Azure is a.NET-based architecture that offers services based on the existing Microsoft development framework, but does not offer regular SQL RDBMS storage... thereby requiring a different application architecture. The Case Against Cloud Computing. Bernard Golden.

Security Challenges & Risks According to the recent survey where more than 500 global C-level executives and IT managers in 17 countries were interviewed, and found that inspite of the benefits that cloud provides, "By a 5-to-1 ratio, executives report that they trust existing internal systems over cloud-based systems due to fear about security threats and loss of control of data and systems” Survey: Cloud Computing ’No Hype’, But Fear of Security and Control Slowing Adoption. Technical report. The major concern for most of them is violation of confidentiality and integrity of data. A company’s data present in cloud can be leaked or tampered, intentionally or accidentally. Such actions result in damage to reputation and finances of a company. Security Challenges in Hybrid Cloud Infrastructures. Koushik Annapureddy

Difficulty in management Determining which components of the system to migrate to the cloud is a nontrivial task The software and services needed to perform the migration from physical to cloud will require additional costs System management tools for managing cloud applications were developed at a time when hardware was very expensive and difficult to replace External cloud management tools do well at managing hardware in cloud environments… but the end user has no hardware to manage

Difficulty Cont’d Outsourcing IT staff to a cloud will reduce personnel overhead but the tradeoff is that core functions of an enterprise system is now dependent on a third-party Getting technical personnel up to speed on the requirements of cloud computing with respect to architecture, implementation, and operation is difficult.

Significance? Simply put, a tradeoff of price and response is intuitive Hybrid cloud-based deployments are cheaper due to economies of scale and the ability to dynamically allocate resources for a tradeoff in performance Same tradeoff could be made with purchasing cheaper and lower performing equipment If there were fewer assumptions, more robust testing and actual implementation (1.5 terabyte storage case is not a “large” system) that also acknowledges failure situations, it may actually be applicable.

Thank you!