A brief history of the cloud

It's impossible to go anywhere these days without hearing about cloud computing. If you currently work in the technology world, I'm sure you've been at a gathering with family or friends when someone finally asks you, "so... what IS the cloud?" Even to the most technically savvy, it is a difficult question to answer. "Cloud" is often used as a buzzword, describing computing or storage infrastructure that can be accessed by many users from any location. To provide the right context, let's take a moment to dive into a brief history of the cloud. If you've heard this story before, feel free to skip ahead!

The plight of the software developer

The application. Whether we are swiping through colorful icons on our smartphone home screens or logging on to our laptop's operating system, the app is everywhere. In fact, the term is used so frequently that it's difficult to give app a proper definition.

So, rather than attempt to define what apps are, we can surely define what they do: solve problems. Apps can provide solutions to some of our most critical business headaches, saving and making money for organizations (and individuals). But more importantly, they often present users with unrealized needs. Think about how many people consider Twitter, Facebook, and LinkedIn on their smartphone to be a necessity to their daily lives.

We typically call the minds behind applications software developers. But life for the software developer wasn't so easy 20 years ago. A developer would hack away on their home or office desktop, perfecting and testing their code into the late hours of the night. When the time for them to share their work with the world, they would need a physical computing device with CPU, disk, and memory. The computer would likely require internet access so it could reach a greater population. And in order to make that happen, a software developer would typically rely on a group of system engineers to call up a hardware vendor and get this machine shipped to the office or data center.

After going through the grueling process of getting the machine unboxed, racked, stacked, and wired up, system engineers would then need to configure the operating system, install the necessary programs and frameworks, and ensure the software developer could connect to the machine from their desktop. Consider some of the technical practices at this time: high availability and fault tolerance, although widely discussed, were not commonly enforced.

Once the servers were ready to go, the software developer would share their masterpiece, placing it on the provided infrastructure. As users accessed the application, all would be great... until the app was no longer accessible. Suddenly, the software developer's phone would ring in the middle of the night. System engineers would struggle to fix hardware failures, thus bringing down the application and facing many angry end users. This required trips to the data center—which itself needed disaster recovery plans in case of a fire, flood, or storm. And how about if the application had a spike of major success? If tons of users rushed to type the URL into their browsers and navigate to the site, resources on existing hardware could be overloaded. The system engineers would need to purchase and install additional servers, firewalls, and load balancers to provide more resources for the additional traffic. All of these potential hazards could be a headache for everyone involved—especially a software developer whose focus should stay on the application itself.

The birth of enterprise virtualization

November 10, 2003: A group of IT executives in dresses, business suits, and blazers stood around a boardroom, watching a screen projecting a video clip of Terminator II: Judgement Day. "Are you ready?" said one of the men standing at a podium. On the bottom right of the screen, a small box of a few Microsoft Windows control panels displayed icons representing running servers.

These servers were virtual machines, and the video clip the room was watching was being played from a file server on one of these virtual machines. Suddenly, the host clicked on a few context menus on the virtual machine and a progress bar appeared. The video continued to play as the T-1000 Advanced Prototype morphed from liquid metal into human form, chasing John Connor in a burning police car. The room exploded with hoots, hollers, and cheers—and it wasn't because of the Terminator. This was a demo of a technology called VMotion, which would revolutionize the IT operations world for years to come.

Although virtualization had been around out since the 1960s, VMware can certainly be credited for bringing it to the masses in their official release of VMware VirtualCenter featuring VMotion. VMotion allowed system engineers to convert their existing physical machines to hypervisors, enabling the running of virtual machines. It also kept those virtual machines up by live-migrating them to another hypervisor in the event of an underlying hardware problem. This was done by transferring the virtual machine's active memory and execution state over the network.

Software developers and system engineers alike were overjoyed with the technology, knowing they would now sleep quite well while their application hummed along regardless of hardware headaches. The software developers continued to develop their incredible applications, but their development methodology remained the same. They were still developing their application as if they were on traditional physical machines!

Gartner, the information technology research and advisor company, has labeled this type of environment Mode 1, otherwise known as enterprise virtualization. In fact, enterprise virtualization still exists today and is the most adopted type of the cloud by enterprises around the world. See Figure 1.1.

Figure 1.1: Enterprise Virtualization (Mode 1) versus Elastic Cloud (Mode 2)

Here are some common characteristics of the enterprise virtualization cloud:

• GUI-emphasized: When one creates a new virtual machine in this model, they typically do so via a Graphical User Interface (GUI). This may be something like vSphere Web Client or Hyper-V Manager. Command-line tools may exist but are less popular with a majority of its operators.
• Expensive hardware: Enterprises that buy into enterprise cloud also buy into expensive blade servers, SANs, network/fabric switches, component redundancy, and high-cost, boutique super microcomputers—specialized hardware with a high price tag.
• Vertical scaling: If your application begins getting more traffic, the ability to scale will be necessary. In the enterprise virtualization world, this means assigning more resources to virtual machines powering the application. When one scales up or vertically, they go about this by adding more CPU, RAM, or disk space to the individual virtual machines. This is the opposite philosophy to scaling horizontally.
• Proprietary: The infrastructure code in this model is closed source. This includes software such as VMware VCenter powered by Microsoft Windows Server. If a bug is discovered while working with the software, it must be filed with the vendor. Because one monolithic organization controls access to the code, bug fixes can take weeks or months to be patched.
• Traditional software development: In an Enterprise Virtualization cloud, the software developer continues to develop the applications in the same manner they developed applications on physical machines. This is sometimes referred to as the monolithic approach. Although the web server or database may reside on different virtual machines, the application's functions are combined into a single program from a single platform. This differs drastically from the cloudy development approach explained in the next section.

Amazon - not just a place for books

In March of 2006, Michael Arrington—founder of Silicon Valley news blog TechCrunch—had an exciting announcement:

Amazon Web Service is launching a new web service tonight called S3 – which stands for “Simple Storage Service”. It is a storage service backend for developers that offers “a highly scalable, reliable, and low-latency data storage infrastructure at very low costs… This is game changing.”

Arrington was right. At this time, Amazon Web Services had yet to release the catalog of services we all know today. Simple Storage Service (S3) provided users with the ability to create an account, enter their credit card number, and have access to upload files to AWS's hosted infrastructure within seconds. One benefit stood out above all: unlimited storage space.

At the time, hosting companies offered virtual private servers (VPS), allowing one to rent a server and use it for backup or file storage. The problems with these solutions was the space limitation on a particular server, not to mention the responsibility of the customer to maintain the health and security of the operating system. While a VPS may have charged users with monthly or yearly flat rates, S3 billed the user for what they used, much like a household electricity bill. The software developer now had the power to avoid the purchase of additional physical servers and storage arrays.

In 2006, there was one surprise left from AWS. On August 25, 2006, Jeff Bar, Chief Evangelist at AWS, announced the launch of Elastic Compute Cloud (EC2):

"Amazon EC2 gives you access to a virtual computing environment. Your applications run on a "virtual CPU", the equivalent of a 1.7 GHz Xeon processor, 1.75 GB of RAM, 160 GB of local disk and 250 Mb/second of network bandwidth. You pay just 10 cents per clock hour (billed to your Amazon Web Services account), and you can get as many virtual CPUs as you need."

This post was the shot heard 'round the IT operations world. Not only could the software developer have access to unlimited storage space with S3, but create as many virtual machines as they wanted. A college student in their dorm now had access to the data centers, bandwidth, and computing power of large-scale enterprises. It was the competitive advantage they needed. This truly provided power to developers. They would quickly scale their application during times of success (with a few clicks of a button) and quickly handle failure elegantly if anything went wrong.

Gartner labeled this type of cloud Mode 2, otherwise known as elastic cloud. See Figure 1.1.

Here are some common characteristics of the elastic cloud:

• API emphasized: Both AWS S3 and EC2 offered Simple Object Access Protocol (SOAP) and Representational State Transfer (REST) APIs at the time of launch. The power of the API is the ability for a developer to easily incorporate these web services into their web application software logic. Visualize a website allowing users to upload and share photos. The developers creating the web application could make API calls to S3 whenever a user uploads or downloads a photo, thus ensuring all the users' uploaded photos were stored in AWS's S3 infrastructure. Although the SOAP API was deprecated by AWS in December 2015, the much more elegant REST API allows browsers to easily communicate with GET, PUT, POST, HEAD, and DELETE methods over the protocol that powers the web: HTTP.
• Standard hardware: Werner Vogels, Vice President and CTO of Amazon, once said everything fails all the time. The inevitability of hardware failures means that redundancy and high availability are going to be a fundamental part of the application running on top of the underlying hardware. If hardware fails, it shouldn't be a problem because the developer has ensured that their application follows the cloudy development style (see final bullet point).
• Horizontal scaling: When one needs more computing power, they rarely bother with resizing existing instances. They instead choose the unlimited nature of elastic cloud by creating more virtual machines and do work in parallel. This is also known as scaling horizontally.
• Open source: Although AWS's overall design and infrastructure are considered proprietary information, the release of its core services sparked a revolution in the tech startup world. Startups with a little cash and a few tech-savvy individuals could use and deploy open source tools, adopt a continuous deployment model, and focus on delivering minimum viable products to customers.
• Cloudy development: Perhaps the most important difference with elastic cloud is cloudy development. As AWS continued to release more services and features throughout the late 2000's, its users began to develop new methodologies for deployment and continuous integration. Many of the users embraced the "fail fast" motto by shipping application code into production as soon as possible to enhance the customer experience. These developers also began embracing a new cloudy methodology, moving from monolithic applications to microservices—utilizing message queues to avoid tightly coupled services, and embracing cloud automation and instance personalization via tools such as Puppet and Chef.

Amazon gripes

Although Amazon was beginning to gain traction as an incredible way to deploy applications, there were many concerns:

• Security: Amazon has significantly improved its security offerings over the years, but at the time of its release, Amazon only offered shared hosted infrastructure. The physical machine hosting your virtual machine most likely served other customers, including competitors! Companies with strict security compliance requirements found this unacceptable.
• Cost: There's no doubt that Amazon is much cheaper than choosing to purchase, deploy, manage, and support the infrastructure yourself. But what about all that AWS cloud spending over time? This is a subject of much debate. But in some scenarios, hiring a company to manage your cloud may be cheaper over time.
• Vendor lock-in: As companies began to place more and more of their production workloads on AWS, this required employees investing hours and days of their time learning the ins and outs of the unique AWS ecosystem. This included digging through official AWS documentation so that one could learn how to code to their APIs. As a single organization in charge of all aspects of the offering, AWS could easily choose to change their API syntax or even raise their resource usage prices. Imagine the hassle involved in attempting to migrate workloads on AWS to another cloud provider.

NASA and Rackspace open source the cloud!

In 2008, NASA was interested in utilizing AWS EC2 to perform scientific computation, but had some concerns about security. As a result, they decided to build their own open-source cloud platform called Nebula. Nebula was a scalable compute-provisioning engine that was loosely based on the EC2 offering.

Around the same time, Rackspace, a managed hosting company from San Antonio, Texas, was working on an open source project called Swift. Swift was (and still is) a distributed object storage system similar to AWS S3, which became a part of Rackspace's Cloud Files offering.

It wasn't until July of 2010 that NASA and Rackspace officially announced the plan to actively combine the Nebula and Swift projects, inviting the world to begin contributing code to a new open source cloud project known as OpenStack. Discussions about the direction of OpenStack began immediately, as more than 100 architects and developers from more than 25 companies traveled to Austin for the first OpenStack conference. Just as quickly, hundreds of developers, hardware manufacturers, and IT software companies began contributing code, inspired by the OpenStack mission:

"To produce the ubiquitous Open Source Cloud Computing platform that will meet the needs of public and private clouds regardless of size, by being simple to implement and massively scalable."

This mission statement appeared on the wiki on May 24th, 2010 and still captures the long-term goal of the OpenStack community today.

OpenStack wasn't the only open source cloud in town—it was in an open source cloud war with Eucalyptus, OpenNebula, and Apache CloudStack. Although these clouds were quite popular between 2008 and 2010, they could not compete with the number of large IT vendors (such as IBM, Ubuntu, and Red Hat) officially announcing their support for OpenStack. Suddenly, more and more people dedicated their precious coding time to OpenStack, and the other cloud projects fell by the wayside.