6 Cloud Platforms: Open-Source and Commercial

6.1 Choosing a Cloud Platform

A cloud platform turns pools of compute, storage, and network capacity into services. To choose one, first ask what you need to run, who will operate it, and what control you need. A team that runs its own cloud has more control, but must also maintain the servers and the cloud software. A managed service shifts some of that work to a provider.

Open source describes a software licence; commercial describes a business arrangement. They are not opposites: a firm can sell a managed service built on open-source software. OpenStack and CloudStack are examples of open-source cloud software. AWS and Azure offer commercial services, including infrastructure and managed platforms. Either kind of software can be used in different deployment settings.

Security remains a shared duty. The operator secures the physical systems and the services it runs. A tenant must still manage access, settings, workloads, and data. The exact split depends on the service: with infrastructure as a service (IaaS), the tenant normally manages the guest operating system; with platform as a service (PaaS), the provider manages more of that stack. Read the service terms to find the boundary.

Product names and releases in the source lectures are a snapshot, not a live catalog. For example, the lectures call OpenStack Ocata the latest release; it dates from 2017. Before a real choice, check the provider’s or project’s own release page, then compare the features, support dates, and costs that matter to your workload.

6.2 Azure and EC2: Control and Service Choice

Azure offers both IaaS and PaaS. Suppose a team needs a custom operating system and its own server tools. A virtual machine gives the team that control, along with the duty to patch and secure the guest system. If the team instead uses a managed app platform, the provider handles more of the runtime and server setup. The team still owns its code, access rules, and data. Compare the actual service terms before assuming either option is safer or cheaper.

Amazon EC2 provides virtual server instances. An instance type sets a mix of CPU, memory, network, and other resources. A compute-heavy task may need more CPU, while a large in-memory cache needs more RAM. The old lecture lists families such as M4, C4, and R4; those are examples from its era. Use the current EC2 documentation to compare available types, region, price, and support for the workload. A newer type is not automatically the best fit.

A server choice is only one part of a deployment. Choose a machine image, a prepared copy of an operating system and its starting files, to boot the server. Decide what data must survive an instance stop or loss. EC2 instance store is temporary. EBS provides block storage: a volume acts like a disk attached to a server, which can read and write parts of it. S3 stores objects: each item contains data and details about it, such as its type; those details are called metadata. An object is retrieved by a key. Plan network access with a virtual private cloud, an isolated network for your resources. Security groups are rules that allow selected traffic to and from instances. Use monitoring to watch load and failures. Scaling rules can add or remove capacity, but test their limits and cost. Availability zones are separate locations within a region. Using more than one can reduce a single-site failure risk when the app is designed for it.

6.3 OpenStack: Follow an Instance Request

OpenStack is a set of open-source services used to build a cloud. It can serve a private or public cloud. Each service has a job, so a request crosses several boundaries. The project began with Rackspace and NASA in 2010; its release names change, so check the project’s release page before choosing a version.

A user can request a virtual machine through Horizon, the web dashboard. A program that sends requests to cloud services, called an API client, can also make the request. Keystone checks identity and provides service endpoints: the addresses clients use to contact cloud services. Nova handles the compute request; Glance supplies the selected machine image. Placement tracks the available capacity of hosts, such as CPU and memory. It returns possible resource assignments that can meet the request; these are called allocation candidates. Nova’s scheduler considers those candidates and picks a host. Neutron supplies network ports. Nova then creates the instance, and Cinder can provide a block volume when the request calls for one. The user should check the instance state, network reachability, volume, and app health.

This path helps locate a fault. If the user cannot sign in, start with identity and access. If the instance starts but cannot be reached, inspect the network and its rules. A successful boot alone does not prove the app is healthy. Swift stores objects, Heat coordinates resources from templates, and Ceilometer collects usage data; they need not take part in every boot. DevStack can set up a test environment, but this chapter does not ask you to install it.

6.4 Test a Placement Before a Pilot

A simulation lets a team compare plans before paying for a full deployment. CloudSim models hosts, virtual machines, workloads, and policies with events over simulated time. User code sets up the scenario, CloudSim models the cloud, and the event engine advances the clock. CloudAnalyst builds on CloudSim with a visual interface for testing apps whose users and data centres are spread across locations. GreenCloud models the individual packets that travel across a network. This packet-level approach helps it study data-centre energy use, including network and device energy under different policies.

For example, compare placing user requests at one data centre with spreading them across two. Set the same demand for both runs, record the network delays and capacity, and compare response time and cost. Then vary the demand and delay: a result that changes sharply with one input needs closer study. The result describes the model, not a guarantee about a real cloud. Real traffic, failures, network delays, and billing can differ from the assumptions. Use a small pilot to measure latency, errors, load, and actual cost before scaling up.

6.5 Cloud Placement Simulation Lab

Use this small browser model to explore the placement trade-off. Change the number of data centres, virtual machines, load, latency, and allocation policy. Compare the estimated response and cost, then test the same idea in a discrete-event simulator and a real pilot. This model uses fixed assumptions and is not CloudSim itself.

6.6 Summary

Choose a platform by the work it must do and by who will run and secure each layer. OpenStack shows how cloud services share the work of a virtual machine request. Azure and EC2 show managed platform and virtual server choices. A simulator can help compare plans, but a pilot must test those plans against real traffic and costs. Check current product and release details before making a decision.

6.7 Key Takeaway

Check the workload and responsibility boundary before choosing a platform.

6.8 See Also

Continue with service management and economics, cloud security fundamentals, or the applied chapter on cloud platforms and message queues for IoT.