The evolution of networking technology to support large-scale data centers is most evident at the access layer due to rapid increase of number of servers in a data center. Some research work (Greenberg, Hamilton, Maltz, & Patel, 2009; Kim, Caesar, & Rexford, 2008) calls for a large Layer-2 domain with a ﬂatter data center network architecture (2 layers vs. 3 layers). While this approach may ﬁt a homoge- nous, single purpose data center environment, a more prevalent approach is based on the concept of switch virtualization which allows the function of the logical Layer-2 access layer to span across multiple physical devices. There are several architectural variations in implementing switch virtualization at the access layer. They include Virtual Blade Switch (VBS), Fabric Extender, and Virtual Ethernet Switch technologies. The VBS approach allows multiple physical blade switches to share a common management and control plane by appearing as a single switching node (Cisco Systems, 2009d). The Fabric Extender approach allows a high-density, high-throughput, multi-interface access switch to work in conjunction with a set of fabric extenders serving as “remote I/O modules” extending the internal fabric of the access switches to a larger number of low-throughput server access ports (Cisco Systems, 2008). The Virtual Ethernet Switch is typically software based access switch integrated inside a hypervisor at the server side. These switch vir- tualization technologies allow the data center to support multi-tenant cloud services and provide ﬂexible conﬁgurations to scale up and down the deployment capacities according to the level of workloads (Cisco Systems, 2009a, 2009c).
Using an IaaS cloud you can create the virtual machine without owning any of the virtual- ization software yourself. Instead, you can access the tools for creating and managing the virtual machine via a web portal. You do not even need the install image of the operating system; you can use a virtual machine image that someone else created previously. (Of course, that someone else probably has a lot of experience in creating virtual machine images, and the image most likely went through a quality process before it was added to the image catalog.) You might not even have to install any software on the virtual machine or make customizations yourself; some- one else might have already created something you can leverage. You also do not need to own any of the compute resources to run the virtual machine yourself: Everything is inside a cloud data center. You can access the virtual machine using secure shell or a remote graphical user interface tool, such as Virtual Network Computing (VNC) or Windows ® Remote Desktop. When you are
Commonly, agility, delivery speed, and cost savings entice companies to public clouds. Public cloud, for example, can free a company from having to invest in consolidating, expanding, or building a new data center when it outgrows a current facility, Kavis says. IT really doesn’t “want to go back to the well and ask management for another several mil- lion dollars,” thus it dives into the public cloud, he says. Stadtmueller says the public cloud is the least ex- pensive way to access compute and storage capacity. Plus, it’s budget- friendly because up-front infra- structure capital investments aren’t required. Businesses can instead align expenses with their revenue and grow capacity as needed. This is one reason why numerous startups choose all- public-cloud approaches.
A common option for reducing the operating costs of only sporadically used IT infra- structure, such as in the case of the “warm standby” , is CloudComputing. As defined by NIST , CloudComputing provides the user with a simple, direct access to a pool of configurable, elastic computing resources (e.g. networks, servers, storage, applications, and other services, with a pay-per-use pricing model). More specifically, this means that resources can be quickly (de-)provisioned by the user with minimal provider interaction and are also billed on the basis of actual consumption. This pric- ing model makes CloudComputing a well-suited platform for hosting a replication site offering high availability at a reasonable price. Such a warm standby system with infrastructure resources (virtual machines, images, etc.) being located and updated in the Cloud is herein referred to as a “Cloud-Standby-System”. The relevance and po- tential of this cloud-based option for hosting replication systems gets even more ob- vious in the light of the current situation in the market. Only fifty percent of small and medium enterprises currently practice BCM with regard to their IT-services while downtime costs sum up to $12,500-23,000 per day for them .
The Heartbeat Service periodically collects the dynamic performance information about the node and publishes this information to the membership service in the Aneka Cloud. These data are collected by the index node of the Cloud, which makes them available for services such as reserva- tions and scheduling in order to optimize the use of a heterogeneous infrastructure. As already dis- cussed, basic information about memory, disk space, CPU, and operating system is collected. Moreover, additional data are pulled into the “alive” message, such as information about the installed software in the system and any other useful information. More precisely, the infrastructure has been designed to carry over any type of data that can be expressed by means of text-valued properties. As previously noted, the information published by the Heartbeat Service is mostly con- cerned with the properties of the node. A specific component, called Node Resolver, is in charge of collecting these data and making them available to the Heartbeat Service. Aneka provides different implementations for such component in order to cover a wide variety of hosting environments. A variety of operating systems are supported with different implementations of the PAL, and differ- ent node resolvers allow Aneka to capture other types of data that do not strictly depend on the hosting operating system. For example, the retrieval of the public IP of the node is different in the case of physical machines or virtual instances hosted in the infrastructure of an IaaS provider such as EC2 or GoGrid. In virtual deployment, a different node resolver is used so that all other compo- nents of the system can work transparently.
Case in point? Six in 10 channel firms say that cloud has generally strengthened their customer relationships, with just 15% claiming it has weakened them and roughly a quarter that said that their client bonds have remained the same. This is encouraging news given the fact that many in the channel have feared publicly that cloud would drive a wedge between them and their customers. There’s been rampant apprehension about such ill effects as a resurgence in vendor direct sales and end user customers choosing a self-‐service model for their IT solutions, i.e. procuring SaaS applications over the Internet. And while both of these trends are happening to a certain extent, CompTIA data suggest not at such dire expense to most of the channel, especially those that have reached a high level of cloud maturity today and intend to remain committed. That said, not all channel firms that adopt cloud will engender more good will with customers; some may simply have a customer set that is not cloud-‐ friendly, others may not gain sufficient expertise to provide value, etc.
A cloud OS should provide the APIs that enable data and services interoper- ability across distributed cloud environments. Mature OSs provide a rich set of services to the applications so that each application does not have to invent important functions such as VM monitoring, scheduling, security, power management, and memory management. In addition, if APIs are built on open standards, it will help organizations avoid vendor lock-in and thereby creating a more flexible environment. For example, linkages will be required to bridge traditional DCs and public or private cloud environments. The flex- ibility of movement of data or information across these systems demands the OS to provide a secure and consistent foundation to reap the real advan- tages offered by the cloudcomputing environments. Also, the OS needs to make sure the right resources are allocated to the requesting applications. This requirement is even more important in hybrid cloud environments. Therefore, any well-designed cloud environment must have well-defined APIs that allow an application or a service to be plugged into the cloud eas- ily. These interfaces need to be based on open standards to protect customers from being locked into one vendor’s cloud environment.
Bob Evans, senior vice president at Oracle, further wrote some revealing facts in his blog post at Forbes, clearing away all doubts people may have had in their minds. You may like to consider some interesting facts in this regard. Almost eight years ago, when cloud terms were not yet established, Oracle started developing a new generation of application suites (called Fusion Applications) designed for all modes of cloud deployment. Oracle Database 12c, which was released just recently, supports the cloud deployment framework of major data centers today and is the outcome of development efforts of the past few years. Oracle’s software as a service (SaaS) revenue has already exceeded the $1 billion mark, and it is the only company today to offer all levels of cloud services, such as SaaS, platform as a service (PaaS), and infrastructure as a service (IaaS). Oracle has helped over 10,000 customers to reap the beneﬁts of the cloud infrastructure and now supports over 25,000 users globally. One may argue that this could not have been possible if Larry Ellison hadn’t appreciated cloudcomputing. Sure, we may understand the dilemma he must have faced as an innovator when these emerging technologies were creating disruption in the business (www.forbes.com/sites/oracle/2013/01/18/oracle-cloud-10000- customers-and-25-million-users/).
Apart from the vendor-specific migration methodologies and guidelines, there are also proposals independent from a specific cloud provider. Reddy and Kumar proposed a methodology for data migration that consists of the following phases: design, extraction, cleansing, import, and verification. Moreover, they categorized data migration into storage migration, database migration, application migration, business process migration, and digital data retention (Reddy and Kumar, 2011). In our proposal, we focus on the storage and database migration as we address the database layer. Morris specifies four golden rules of data migration with the conclusion that the IT staff does not often know about the semantics of the data to be migrated, which causes a lot of overhead effort (Morris, 2012). With our proposal of a step-by-step methodology, we provide detailed guidance and recom- mendations on both data migration and required application refactoring to minimize this overhead. Tran et al. adapted the function point method to estimate the costs of cloud migration projects and classified the applications potentially migrated to the cloud (Tran et al., 2011). As our assumption is that the decision to migrate to the cloud has already been taken, we do not con- sider aspects such as costs. We abstract from the classification of applications to define the cloud data migration scenarios and reuse distinctions, such as complete or partial migration to refine a chosen migration scenario.
Cloudcomputing evolved out of grid computing , which is a collection of dis- tributed computers intended to provide computing power and storage on demand [ 1 ]. Grid computing clubbed with virtualisation techniques help to achieve dynam- ically scalable computing power, storage, platforms and services. In such an envi- ronment, a distributed operating system that produces a single system appearance for resources that exist and is available is solicited most [ 2 ]. In other words, one can say that cloudcomputing is a specialised distributed computing paradigm. Cloud differs with its on-demand abilities like scalable computing power – up or down, service levels and dynamic confi guration of services (via approaches like virtualisation ). It offers resources and services in an abstract fashion that are charged like any other utility, thus bringing in a utility business model for comput- ing. Though virtualisation is not mandatory for cloud, its features like partitioning, isolation and encapsulation [ 3 ] and benefi ts like reduced cost, relatively easy administration, manageability and faster development [ 4 ] have made it an essential technique for resource sharing. Virtualisation helps to abstract underlying raw resources like computation, storage and network as one, or encapsulating multiple application environments on one single set or multiple sets of raw resources. Resources being both physical and virtual, distributed computing calls for dynamic load balancing of resources for better utilisation and optimisation [ 5 ]. Like any other traditional computing environment, a virtualised environment must be secure and backed up for it to be a cost saving technique [ 3 ]. Cloudcomputing is a trans- formation of computing by way of service orientation, distributed manageability and economies of scale from virtualisation [ 3 ].
“Clouds are about ecosystems, about large collections of interacting services including partners and third parties, about inter-cloud communication and sharing of information through such semantic frameworks as social graphs.” Transformationvsutility This, he adds, is clearly business transformational, whereas “computing services that are delivered as a utility from a remote data centre” are not. The pioneers in VANS/EDI methods – which are now migrating into modern cloud systems in offerings from software ﬁrm SAP and its partners, for example – were able to set up basic trading data exchange networks, but the cloud transformation now is integrating, in real-time, the procurement, catalogue, invoicing and other systems across possibly overlapping and much wider business communities.
Starting in 1958 the agency, then known as ARPA, was responsible for carrying out research and development on projects at the cutting edge of science and technology. While these typically dealt with national security–related matters, the agency never felt bound by military projects alone. One outcome of this view was significant work on general information technology and computer systems, starting with pioneering research on what was called time-sharing. The first computers worked on a one user–one system principle, but because individuals use computers intermittently, this wasted resources. Research on batch processing helped to make computers more efficient because it permitted jobs to queue up over time and thereby shrunk nonusage time. Time-sharing expanded this by enabling multiple users to work on the same system at the same time. DARPA kick-started time-sharing with a grant to fund an MIT-based project that, under the leadership of J. C. R. Licklider, brought together people from Bell Labs, General Electric, and MIT (Waldrop 2002). With time-sharing was born the principle of one system serving multiple users, one of the foundations of cloudcomputing. The thirty or so companies that sold access to time-sharing computers, including such big names as IBM and General Electric, thrived in the 1960s and 1970s. The primary operating system for time-sharing was Multics (for Multiplexed Information and Computing Service), which was designed to operate as a computer utility modeled after telephone and electrical utilities. Specifically, hardware and software were organized in modules so that the system could grow by adding more of each required resource, such as core memory and disk storage. This model for what we now call scalability would return in a far more sophisticated form with the birth of the cloud- computing concept in the 1990s, and then with the arrival of cloud systems in the next decade. One of the key similarities, albeit at a more primitive level, between time-sharing systems and cloudcomputing is that they both offer complete operating environments to users. Time-sharing systems typically included several programming-language processors, software packages, bulk printing, and storage for files on- and offline. Users typically rented terminals and paid fees for connect time, for CPU (central processing unit) time, and for disk storage. The growth of the microprocessor and then the personal computer led to the end of time-sharing as a profitable business because these devices increasingly substituted, far more conveniently, for the work performed by companies that sold access to mainframe computers.
When working at scale, as you are likely to do with a private cloud implementation, strongly consider standardization of your server hardware models and purchasing groups of serv- ers together. Not only does this approach guarantee you’ll have compatible CPU generations and identical hardware, it makes your deployment process simpler. You can use tools like Autodeploy and host profi les to deploy and redeploy your servers. Likewise, using DHCP rather than static IP addressing schemes for vSphere servers becomes more appealing. vSphere 5.1 with Autodeploy also allows you to deploy stateless vSphere hosts, where each node is booted from the network using a Trivial File Transfer Protocol (TFTP) server. The host downloads the vSphere hypervisor at boot-time and runs it in RAM; then it downloads its confi guration from the Autodeploy server.
In 1997, Professor Ramnath Chellappa of Emory University, defined cloudcomputing for the first time while a faculty member at the University of South California, as an important new “computing paradigm where the boundaries of computing will be determined by economic rationale rather than technical limits alone.” Even though the international IT literature and media have come forward since then with a large number of definitions, models and architectures for cloudcomputing, autonomic and utility computing were the foundations of what the community commonly referred to as “cloudcomputing”. In the early 2000s, companies started rapidly adopting this concept upon the realization that cloudcomputing could benefit both the Providers as well as the Consumers of services. Businesses started delivering computing functionality via the Internet, enterprise- level applications, web-based retail services, document-sharing capabilities and fully-hosted IT platforms, to mention only a few cloudcomputing use cases of the 2000s. The latest widespread adoption of virtualization and of service- oriented architecture (SOA) promulgated cloudcomputing as a fundamental and increasingly important part of any delivery and critical-mission strategy, enabling existing and new products and services to be offered and consumed more efficiently, conveniently and securely. Not surprisingly, cloudcomputing became one of the hottest trends in the IT armory, with a unique and complementary set of properties, such as elasticity, resiliency, rapid provisioning, and multi-tenancy.
OAGIS (Open Applications Group Integration Speci ﬁ cation)  from the OAGi is an international cross-domain transaction standard for B2B and A2A and exists since 1996 (only its ﬁ rst versions were not XML-based), it is used by over 38 industries in 89 states (05/2011); main stakeholders are IBM, Oracle, DHL, SAP, Microsoft. OAGIS 9.5.1 consists of 84 BOs, used in over 530 BODs (including master data exchange), the BODs are used in 64 sample scenarios, and OAGi provides Web service de ﬁ nitions. One of its explicit objectives is to provide a canonical business object model . It integrates many other standards: UN/ CEFACT, ISO, OASIS, CCTS/CCL and many more and can be used together with ebXML and is EDIFACT-compatible. The OAGi quickly adopts modern trends, e.g. soon the JSON exchange format will be supported additionally to XML to better support mobile devices, and there are cloud and BPMN initiatives. Most important for us is its openness and schema extensibility by XSD overlays, in addition to instance extensions by freely usable so-called user areas.
components. Network isolation in the cloud can be done using various techniques of network isolation such as VLAN, VXLAN, VCDNI, STT, or other such techniques. Applications are deployed in a multi-tenant environment and consist of components that are to be kept private, such as a database server which is to be accessed only from selected web servers and any other traffic from any other source is not permitted to access it. This is enabled using network isolation, port filtering, and security groups. These services help with segmenting and protecting various layers of application deployment architecture and also allow isolation of tenants from each other. The provider can use security domains, layer 3 isolation techniques to group various virtual machines. The access to these domains can be controlled using providers' port filtering capabilities or by the usage of more stateful packet filtering by implementing context switches or firewall appliances. Using network isolation techniques such as VLAN tagging and security groups allows such configuration. Various levels of virtual switches can be configured in the cloud for providing isolation to the different networks in the cloud environment.
Internet services are the most popular applications with lots of users. Websites such as Facebook, Yahoo, and Google are accessed by millions every day, as a result of which a huge volume of valuable data (in terabytes) is generated, which can be used to improve online strategies of advertising and user fulfillment. Storage, real-time capture, and analy- sis of that data are general needs of all applications. To trace these problems, some cloudcomputing strategies have recently been implemented. Cloudcomputing is a style of com- puting where virtualized resources are provided to the customers as a service, which is dynamically scalable, over the Internet. The cloud refers to the data center hardware and software that a client requests from remotely hosted applications, often in the form of data stores. Those companies are using these infrastructures to cut costs by eliminating the call for physical hardware, which allows them to outsource data and on-demand com- putations. The function of large-scale computer data centers is the main focus of cloudcomputing. These data centers benefit from the economies of scale, allowing for decrease in the cost of bandwidth, operations, electricity, and hardware .
as its stack, it might not have been able to achieve the scalability that it achieved on AWS. This by no means is a knock on Google or a declaration that AWS is any better than Google. Simply put, for scaling requirements like Instagram’s, an IaaS provider is a better choice than a PaaS. PaaS providers have thresholds that they enforce within the layers of their architecture to ensure that one customer does not consume so many resources that it impacts the overall platform, resulting in performance degradation for other customers. With IaaS, there are fewer limitations, and much higher levels of scalability can be achieved with the proper architecture. We will revisit this use case in Chapter 5. Architects must not let their loyalty to their favorite vendor get in the way of making the best possible business decision. A hammer may be the favorite tool of a home builder, but when he needs to turn screws he should use a screwdriver. Recommendation: Understand the differences between the three cloud service models: SaaS, PaaS, and IaaS. Know what business cases are best suited for each service model. Don’t choose cloud vendors based solely on the software stack that the developers use or based on the vendor that the company has been buying hardware from for years.
Data transfer performance is a critical factor when considering the deployment of a data-intensive processing pipeline on a distributed topology. In fact, an important part of the DESDynI pre-mission studies consisted in using the deployed array of cloud servers to evaluate available data transfer technologies, both in terms of speed and easiness of installation and confi guration options. Several data transfer toolkits were compared: FTP (most popular, used as performance baseline), SCP (ubiquitous, built- in SSH security, potential encryption overhead), GridFTP (parallelized TCP/IP, strong security, but complex installation and confi guration), bbFTP (parallelized TCP/IP, easy installation, standalone client/server), and UDT (reliable UDP-based bursting technology). Benchmarking was accomplished by transferring NetCDF fi les (a highly compressed format commonly used in Earth sciences) of two representative sizes (1 and 10 GB) between JPL, two cloud servers in the AWS-West region, and one cloud server in the AWS-East region. The result was that UDT and GridFTP offered the overall best performance across transfer routes and fi le sizes: UDT was slightly faster and easier to confi gure than GridFTP, but it lacked the security features (authen- tication, encryption, confi dentiality, and data integrity) offered by GridFTP. It was also noticed that the measured transferred times varied considerably when repeated for the same fi le size and transfer end points, most likely because of concurrent use of network and hardware resources by other projects hosted on the same cloud. Additionally, using the Amazon internal network, when transferring data between servers on the same AWS-West region consistently, yielded much better performance than when using the publicly available network between the same servers.