6 Cloud Platforms: Open-Source and Commercial
6.1 Start With Why This Chapter Names Products At All
Every chapter so far in this module has stayed at the level of a model or a taxonomy – NIST’s definition, the service-model responsibility bracket, the deployment-model taxonomy, the economics of scaling. This chapter is different: it surveys actual, named platforms – GreenCloud, OpenStack, Microsoft Azure, Amazon EC2, and CloudSim/CloudAnalyst – because “how do I evaluate a real platform?” is itself a skill the taxonomy chapters cannot teach on their own.
That makes this chapter the densest one in the module, and also the one most exposed to going stale. Every product name, version number, and instance-type list below comes from a specific lecture deck recorded in the mid-2010s. Cloud product catalogs change on a roughly annual cycle; a specific named list is a photograph, not a live feed. Read this chapter for the shape of each platform – what kind of thing it is, what problem category it solves, how to tell whether it is still current – not as a lookup table of today’s options.
How to read every named product, version, or instance type in this chapter. Treat each one as “as presented in the source material” rather than as a current fact, unless a passage explicitly says otherwise. Three habits carry over to any platform you evaluate later, cloud or otherwise: (1) check whether the provider’s own current documentation still lists the name; (2) check whether a newer, differently-numbered item has replaced it in the same category; (3) check what specific capability actually changed between the old and new version, rather than assuming “newer” only means “renamed.” This chapter teaches those three habits directly against real, sometimes-already-outdated examples – the outdated parts are not a flaw to route around, they are the worked example.
6.2 Open-Source and Commercial Clouds, and OpenStack’s Architecture
Before comparing named platforms, one more simulator belongs in the picture alongside the ones this chapter closes with: GreenCloud, an energy-aware cloud simulator built as an extension of the packet-level network simulator NS2 (D. Kliazovich, P. Bouvry, S. U. Khan, “GreenCloud: A packet-level simulator of energy-aware cloud computing data centers,” J. Supercomput., vol. 62, no. 3, pp. 1263-1283, Dec. 2012). Rising data-center energy consumption is GreenCloud’s own stated motivation for existing at all – it is not a general-purpose cloud platform, it is a tool built to answer one specific question: how much energy does a proposed cloud configuration actually burn? Its named features:
- User-friendly graphical interface
- Open source
- Facility for monitoring the energy consumption of network and devices
- Supports simulation of cloud network components
- Supports monitoring of energy consumption of individual components
- Enables improved power-management schemes
- Dynamic management and configuration of devices
With that energy-simulation angle in view, the first taxonomy this chapter needs is not a service model or a deployment model – it is ownership. A cloud platform is either open-source software you can run yourself, or a commercial service someone else runs for you, and the source material’s own comparison lays out what changes across that line:
One named example in that table is already gone. Eucalyptus, listed alongside OpenStack and CloudStack as an open-source example, was acquired by HP in 2014 and is no longer maintained as an independently developed open-source project the way OpenStack and CloudStack still are. This is the same lesson the module’s economics chapter drew from ClearDB’s discontinuation, applied to a platform instead of a database service: a named product in a comparison table is a snapshot of what existed when the table was built, not a guarantee the row is still accurate. “Google App Engine” as the sole named Google example is a similar snapshot – Google’s own cloud offering has grown far beyond App Engine since, into the broader Google Cloud Platform catalog.
Reading the table’s own logic rather than its specific names: open-source clouds hand you the software and, with it, the job of implementing security yourself; commercial clouds hand you a managed service, a wider span of service models (not just IaaS), and a provider who implements security on your behalf – the same “who manages what” trade this module’s second chapter built as the responsibility bracket, now applied to an entire platform choice rather than one layer of the stack.
OpenStack is this table’s own named example of an open-source cloud platform, and it is worth a closer look because of how it is built, not just what it is called. Per the OpenStack Foundation’s own description (openstack.org/software): it is a collection of open-source technologies, managed by the OpenStack Foundation, that supports a vastly scalable cloud system through a preconfigured software suite. Different services are available to users; it is generally considered Infrastructure-as-a-Service; new instances can be added quickly to run other cloud components; it provides a platform for creating software applications; and those applications, once developed, are usable by end users.
That one-paragraph description is the whole shape of an open-source IaaS platform in miniature: a common network layer hosting VM, storage, and container resources, monitored by a separate tool set, and exposed to users through a dashboard GUI on one side and their own applications on the other. Everything in the “under the hood” section below is that same shape broken into its nine named working parts.
6.3 Commercial Platforms: Reading Azure and EC2 as Examples, Not as a Catalog
Microsoft Azure – previously named Windows Azure – is this chapter’s named example of a commercial platform spanning both PaaS and IaaS. Per Microsoft’s own description (azure.microsoft.com), it supports an extensive set of services for quickly creating, deploying, and managing applications, across many programming languages and frameworks, available through a worldwide network of Microsoft-managed data centers. The source material’s own snapshot names ten service categories inside that offering: Compute, Mobile services, Storage services, Data management, Messaging, Media services, Content Delivery Network (CDN), Developer, Management, and Machine Learning.
Read the list above as a shape, not a catalog. A cloud provider organizing its offering into named service categories is the durable pattern; the specific ten category names and how they are grouped is not – Azure’s own service catalog has been reorganized and renamed multiple times since this material was recorded, and by the time you are reading this it almost certainly groups things differently and includes categories that did not exist in this snapshot. The transferable skill is recognizing the shape (“a provider groups dozens of individual services into a handful of named categories so a customer can navigate them”) rather than memorizing this particular ten-item list.
Azure’s own material frames the PaaS and IaaS sides of that catalog as two different value propositions for two different customers:
Azure as PaaS
A platform is provided to clients to develop and deploy software; clients focus on application development rather than hardware and infrastructure. Named advantages: low cost, less vulnerable to security attacks, easier to move on to new tools, and it resolves most operating-system, server, and networking concerns for the customer.
Azure as IaaS
Offers total control of the OS and application stack, with features to access, manage, and monitor the data centers directly. Named fit: applications where complete control is required, and workloads that need custom configurations loaded onto the infrastructure.
Amazon Elastic Compute Cloud (EC2) is the source material’s named IaaS commercial example on the compute side specifically: a web service for launching and managing server instances in Amazon’s data centers, with APIs, tools, and utilities that facilitate dynamic computation scaling within AWS, billed pay-per-use rather than requiring a large, expensive hardware purchase up front.
EC2 groups its virtual computing environments into named instance-type families – templates of a fixed CPU, memory, storage, and networking-capacity configuration, dynamically allocated by AWS according to user demand. The source material’s own snapshot of that grouping, by category:
General Purpose
T2, M4, M3 (as named in the source material)
Compute Optimized
C4, C3 (as named in the source material)
Memory Optimized
X1, R4, R3 (as named in the source material)
Accelerated Computing
P2, G2, F1 (as named in the source material)
This is the chapter’s sharpest currency-verification example. Every one of those eleven family names is a specific, dated snapshot – this list reflects roughly the mid-2010s generation of EC2 instance types. AWS iterates each of these four categories on a regular cycle: a general-purpose, compute-optimized, memory-optimized, or accelerated-computing family gets superseded by a new, differently-numbered family every one to three years, following AWS’s own letter-plus-generation-number naming convention (the letter names the category – “M” for general purpose, “C” for compute-optimized, “R” for memory-optimized, and so on – and the number increments with each new generation). Do not treat T2, M4, M3, C4, C3, X1, R4, R3, P2, G2, or F1 as AWS’s current lineup. Instead, before relying on any instance-family name in a real decision: open AWS’s own current EC2 instance-type page, find the category you need, and read off whichever generation is listed as current at that moment – not the generation shown in any lecture deck, tutorial, or course chapter, including this one.
Beyond instance families, EC2’s own named operational features round out what “Infrastructure-as-a-Service” concretely provides day to day:
Operating Systems and AMIs
Supports all major OS types, plus custom distributions via Amazon Machine Images (AMIs) such as the Amazon Linux AMI.
Persistent Storage Tiers
Temporary local “Instance Store,” Amazon Elastic Block Store (EBS) for persistent block storage, and Simple Storage Service (S3) for object storage.
Automated Scaling and Availability Zones
Rule-based or schedule-based automated scaling; separate availability zones within data centers increase fault tolerance.
Security Groups and Firewall Rules
Only predefined protocols, ports, and source IP ranges are allowed to reach an instance.
Elastic IP and Key-Pair Security
An Elastic IP maps a fixed address onto any of a user’s virtual machines; instances gain enhanced security through public-private key pairs.
CloudWatch and Virtual Private Clouds
Amazon CloudWatch monitors CPU, disk, and network resource utilization; Virtual Private Clouds (VPCs) are logically separated from the rest of the AWS cloud, with an optional connection back to a user’s own network.
Notice which of those two lists is more durable. The instance-family names in the box above are the part of EC2 most likely to have changed since this material was recorded. The six operational features here – OS flexibility, tiered storage, scaling, security groups, keyed access, monitoring, and network isolation – describe the kind of capabilities a serious IaaS platform provides, and that shape has stayed stable even as the specific product names implementing each feature evolve. When evaluating any IaaS platform, old or new, ask “does it have an answer for each of these six categories?” before asking “what is this specific service called this year?”
6.4 Under the Hood: OpenStack’s Components, Devstack (Conceptually), and Testing Placement Decisions in Simulation
OpenStack’s own history is a second, independent illustration of the same currency lesson this chapter keeps returning to. Per the source material: OpenStack launched as a joint project of Rackspace Hosting and NASA in 2010, is open-source, and is presently supported by a large contributor community including IBM, Cisco, HP, Dell, VMware, Red Hat, and SUSE alongside Rackspace itself. It can be used to build either a private or a public cloud. The source material’s own version list runs Austin, Bexar, Cactus, Diablo, Essex, Folsom, Grizzly, Havana, Icehouse, Juno, Kilo, Liberty, Mitaka, Newton, naming Ocata as “(Latest).”
“Latest” is the single most dated word in this chapter. OpenStack ships named releases on a regular, publicly documented cadence (see releases.openstack.org for the live list), and Ocata itself shipped in February 2017 – it has not been the latest release for years. Naming “the current OpenStack release” here would just replace one dated fact with another that goes stale on the same clock. The lesson this teaches directly: when a source names something as “latest,” “current,” or “newest,” read that claim as true only as of the source’s own recording date, and re-check it against the project’s own live release page before repeating it anywhere that needs to stay accurate.
OpenStack’s own component list is the part of this material that ages more slowly, because it describes an architecture rather than a version number. Nine named services fan out from a shared dashboard:
Keystone
Identity service. Provides authentication and authorization for the rest of OpenStack.
Horizon
Dashboard. The graphical user interface for the software, giving an overview of every other component.
Nova
Compute service. Where instances are actually launched and run.
Glance
Image service. Handles discovering, registering, and retrieving virtual-machine images and snapshots.
Swift
Object storage. Stores data safely, cheaply, and efficiently as objects rather than block devices.
Neutron
Networking service. Lets the other services communicate with each other and lets a user build their own network.
Cinder
Block storage. Virtualizes the management of block-level storage devices for instances.
Heat
Orchestration. Coordinates multiple resources together as one deployable template.
Ceilometer
Billing/metering. Tracks which service is being used, and for how long, to support usage-based billing.
Read that list against the deployment-and-virtualization chapter’s own container-vs-VM distinction and it maps directly onto the layered component stack from this module’s first chapter: Keystone and Horizon are access and control; Nova, Glance, and Cinder are compute and storage primitives; Swift is object storage; Neutron is the network layer; Heat and Ceilometer are the orchestration and accounting layers sitting on top. Nine names, one shape – and that shape is the part of OpenStack worth actually remembering.
This chapter stops at architecture, not installation. The source material also walks through installing a single-machine OpenStack environment using Devstack – a community-maintained scripted installer that automates the bootstrap of a reference OpenStack deployment for development and testing, driven by a local.conf configuration file (historically supplying values such as an admin password, database password, message-queue password, service password, and the host’s own IP address) and a stack.sh script that does the actual install. That walkthrough is lab-setup material, not systems-computing concepts, so it is deliberately out of scope here – this chapter’s job is knowing what each OpenStack component does, not standing up a live stack. If you do go looking for Devstack yourself, note that even OpenStack’s own code-hosting location has moved on since this material was recorded (the project’s infrastructure migrated off the old git.openstack.org domain to the OpenDev Collaboratory years ago) – one more small, concrete case of exactly the currency check this whole chapter has been asking you to run.
Once a platform choice and an architecture are on the table, the last question this chapter answers is: how do you test a placement or scaling decision before committing real money to it? That is exactly the gap CloudSim and CloudAnalyst fill – academic, open-source simulation toolkits built to answer “what would happen if…” questions about a cloud deployment without paying for one.
CloudSim is a simulation framework, written in Java and developed at the CLOUDS Lab of the University of Melbourne, that models cloud-computing environments – data centers, virtual machines, applications, users, and network topology – and lets a researcher examine the performance of application services under different resource-provisioning policies, with dynamic addition and removal of resources during a run (R. N. Calheiros, R. Ranjan, A. Beloglazov, C. A. F. De Rose, R. Buyya, “CloudSim: A toolkit for modeling and simulation of cloud computing environments and evaluation of resource provisioning algorithms,” Software: Practice and Experience, 41(1):23-50, 2011). Its own named advantages are time-effectiveness (minimum time and effort to model a cloud-based scenario) and flexibility (support for diverse cloud environments and any application-service model). CloudSim’s architecture is a three-layer stack:
User Code (Top Layer)
Presents machine and application specifications – the basic entities are users, physical machines, virtual machines, applications and services, and scheduling policies.
CloudSim (Middle Layer)
Provides the cloud environment itself: models host and VM provisioning, application-execution management, and dynamic system-state monitoring, and lets a simulated provider implement and evaluate custom policies.
Core Simulation Engine (Bottom Layer)
Handles event scheduling, entity creation, interaction between components, and clock management – the discrete-event engine everything above runs on.
CloudAnalyst is, in its own words, a simulation tool designed on top of CloudSim, adding a graphical user interface and support for modeling geographically distributed, large-scale cloud applications – the purpose is studying how such applications behave under different deployment configurations (B. Wickremasinghe, R. N. Calheiros, R. Buyya, “CloudAnalyst: A CloudSim-Based Visual Modeller for Analysing Cloud Computing Environments and Applications,” Proc. IEEE AINA, pp. 446-452, Perth, 2010). Its architecture wraps CloudSim in a triangle of components: a “CloudSim Extensions” layer and a “GUI” layer both sit on top of the underlying “CloudSim Toolkit,” each communicating with the other two. Eight named components do the actual modeling work: the GUI Package (front end), Simulation (create/execute/hold a run), UserBase (generates simulated user traffic), DataCenterController (handles data-center events), Internet (internetworking and routing), InternetCharacteristics (delay, bandwidth, throughput properties), VmLoadBalancer (load-balancing policies), and CloudAppServiceBroker (routes between a UserBase and a data center).
Honest scope: a simulation is a filter, not a verdict. CloudSim and CloudAnalyst let you test whether a proposed placement policy, scaling rule, or geographic distribution behaves sensibly against a modeled workload – catching an obviously bad policy cheaply, before it costs real infrastructure spend. That is genuinely useful, and it is exactly why this chapter closes the module’s platform survey on these two tools rather than on another named product. But a simulation result is not the same evidence as a production pilot: real networks have variability, real users are not the same as a generated UserBase, and the economics-of-scaling framework from the previous chapter still needs real usage data to confirm. Treat a favorable CloudSim or CloudAnalyst result as a reason to proceed to a real pilot, not as a substitute for one – the same “pilot-to-production gap” this module’s applied companion book treats as its own launch-gate topic.
6.5 Summary
This chapter surveyed five named platforms – GreenCloud, OpenStack, Microsoft Azure, Amazon EC2, and CloudSim/CloudAnalyst – while treating every specific product name, version, and instance-family list as a dated snapshot rather than a current catalog. Open-source clouds (OpenStack, CloudStack) trade a subscription for self-hosting and self-implemented security; commercial clouds (AWS, Azure, Google’s offering) trade cost and control for a managed, broader service span. OpenStack’s nine named components – Keystone, Horizon, Nova, Glance, Swift, Neutron, Cinder, Heat, Ceilometer – describe a durable architecture even as its release-version history (already several years past the source’s own “Ocata (Latest)” claim) does not. Azure’s PaaS/IaaS split and EC2’s instance-family taxonomy and operational features are best read the same way: the categories are the durable lesson, the specific names inside each category are not. CloudSim and CloudAnalyst close the chapter as an honest-scope answer to “test it before you pay for it” – a useful filter for a placement or scaling decision, not a replacement for a real production pilot.
6.6 Key Takeaway
Every named product, version, or instance type in this chapter is a photograph, not a live feed. Before repeating any specific name from here (or anywhere else) in a real decision, check the provider’s own current documentation – the categories in this chapter (open-source vs. commercial, OpenStack’s nine components, an IaaS platform’s operational-feature set, a simulator’s honest scope) are the part built to last; the product names filling in those categories are not.
6.7 See Also
Service Management, SLAs, and Economics
The previous chapter in this module: the economics-of-scaling framework this chapter’s CloudSim/CloudAnalyst section ties its “test before you pay” framing back to.
The next chapter in this module: who implements security under an open-source versus commercial platform, generalized into a full security taxonomy.
Cloud Platforms and Message Queues for IoT
The applied companion chapter: turns broker, queue, and managed-vs-self-managed platform choices into an IoT capacity and reliability decision.