Here's a dirty little secret that the cloud providers may not want you to know. Cloud providers use cryptic acronyms and fancy terms such as Elastic Compute Cloud (EC2) instances and S3 services (in the case of AWS), or Azure Virtual Machines (VMs) and blobs (in the case of Azure), but at its most basic level, the cloud is just a bunch of servers and other computing resources managed by a third-party provider in a data center somewhere.

But we had data centers and third-party-managed servers long before the term cloud became popular. So, what makes the cloud different from your run-of-the-mill data center?

Before we try to define cloud computing, let's analyze some of the characteristics that are common to many of the leading cloud providers.

Cloud elasticity

One important characteristic of the leading cloud providers is the ability to quickly and frictionlessly provision resources. These resources could be a single instance of a database or a thousand copies of the same server, used to handle your web traffic. These servers can be provisioned within minutes.

Contrast that with how performing the same operation may play out in a traditional on-premises environment. Let's use an example. Your boss comes to you and asks you to set up a cluster of computers to host your latest service. Your next actions probably look something like this:

1. You visit the data center and realize that the current capacity is not enough to host this new service.
2. You map out a new infrastructure architecture.
3. You size the machines based on the expected load, adding a few more terabytes here and a few gigabytes there to make sure that you don't overwhelm the service.
4. You submit the architecture for approval to the appropriate parties.
5. You wait. Most likely for months.

It may not be uncommon once you get the approvals to realize that the market opportunity for this service is now gone, or that it has grown more and the capacity you initially planned will not suffice.

It is difficult to overemphasize how important the ability to deliver a solution quickly is when you use cloud technologies to enable these solutions.

What do you think your boss would say if after getting everything set up in the data center and after months of approvals, you told them you made a mistake and you ordered an X213 server instead of an X312, which means you won't have enough capacity to handle the expected load and getting the right server will take a few more months? What do you think their mood would be like?

In a cloud environment, this is not necessarily a problem, because instead of needing potentially months to provision your servers, they can be provisioned in minutes.

Correcting the size of the server may be as simple as shutting down the server for a few minutes, changing a drop-down box value, and restarting the server again.

Hopefully, the unhappy boss example here drives our point home about the power of the cloud and the pattern that is emerging. The cloud exponentially improves time to market. And being able to deliver quickly may not just mean getting there first. It may be the difference between getting there first and not getting there at all.

Another powerful characteristic of a cloud computing environment is the ability to quickly shut down resources and, importantly, not be charged for that resource while it is down. Being able to shut down resources and not paying for them while they are down is not exclusive to AWS. Many of the most popular cloud providers offer this billing option.

In our continuing on-premises example, if we shut down one of our servers, do you think we can call the company that sold us the server and politely ask them to stop charging us because we shut the server down? That would be a very quick conversation and depending on how persistent we were, it would probably not be a very pleasant one. They are probably going to say, "You bought the server; you can do whatever you want to do with it, including using it as a paperweight." Once the server is purchased, it is a sunk cost for the duration of the useful life of the server.

In contrast, whenever we shut down a server in a cloud environment, the cloud provider can quickly detect that and put that server back into the pool of available servers for other cloud customers to use that newly unused capacity.

Cloud virtualization

Virtualization is the process of running multiple virtual instances on top of a physical computer system using an abstract layer sitting on top of actual hardware.

More commonly, virtualization refers to the practice of running multiple operating systems on a single computer at the same time. Applications that are running on VMs are oblivious to the fact that they are not running on a dedicated machine.

These applications are not aware that they are sharing resources with other applications on the same physical machine.

A hypervisor is a computing layer that enables multiple operating systems to execute in the same physical compute resource. These operating systems running on top of these hypervisors are VMs – a component that can emulate a complete computing environment using only software but as if it was running on bare metal.

Hypervisors, also known as Virtual Machine Monitors (VMMs), manage these VMs while running side by side. A hypervisor creates a logical separation between VMs, and it provides each of them with a slice of the available compute, memory, and storage resources.

This allows VMs to not clash and interfere with each other. If one VM crashes and goes down, it will not make other VMs go down with it. Also, if there is an intrusion in one VM, it is fully isolated from the rest.

Definition of the cloud

Let's now attempt to define cloud computing.

The cloud computing model is one that offers computing services such as compute, storage, databases, networking, software, machine learning, and analytics over the internet and on demand. You generally only pay for the time and services you use. The majority of cloud providers can provide massive scalability for many of their services and make it easy to scale services up and down.

Now, as much as we tried to nail it down, this is still a pretty broad definition. For example, in our definition, we specify that the cloud can offer software. That's a pretty broad term. Does the term software in our definition include the following?

• Code management
• Virtual desktops
• Email services
• Video conferencing

These are just a few examples of what may or may not be included as available services in a cloud environment. When it comes to AWS and other major cloud providers, the answer is yes. When AWS started, it only offered a few core services, such as compute (Amazon EC2) and basic storage (Amazon S3). As of 2020, AWS offers 212 services, including compute, storage, networking, databases, analytics, developer and deployment tools, and mobile apps, among others. For the individual examples given here, AWS offers the following:

• Code management: AWS CodeCommit, AWS CodePipeline, and AWS CodeDeploy
• Virtual desktops: AWS WorkSpaces
• Email services: Amazon SES and Amazon WorkMail
• Video conferencing: Amazon Chime

As we will see throughout the book, this is a tiny sample of the many services that AWS offers. Additionally, since it was launched, AWS services and features have grown exponentially every year, as shown in the following figure:

Figure 1.1 – AWS – number of services

There is no doubt that the number of offerings will continue to grow at a similar rate for the foreseeable future. Having had the opportunity to work in the AWS offices in Seattle, I can report that AWS is hard at work creating these new services and eating their own dog food by using their existing services to create these new services.

Up until a few years ago, one of the biggest and most common objections to hamper cloud adoption on a massive scale was the refrain that the cloud is not secure. To address this objection, cloud providers started offering private clouds: a whole infrastructure setup that only one company can access and is completely private to them. However, this privacy and security come at a price. One of the reasons why the cloud is so popular and affordable is that any resources that you are currently not using can be used by other customers that do need the capacity at that time, meaning they share the cost with you. Whoever uses the resources the most, pays the most. This cost-sharing disappears with private clouds.

Let's use an analogy to gain further understanding. The gig economy has great momentum. Everywhere you look, people are finding employment as contract workers. There are Uber drivers, people setting up Airbnbs, people doing contract work for Upwork. One of the reasons contract work is getting more popular is that it enables consumers to contract services that they may otherwise not be able to afford. Could you imagine how expensive it would be to have a private chauffeur? But with Uber or Lyft, you almost have a private chauffeur who can be at your beck and call within a few minutes of you summoning them.

A similar economy of scale happens with a public cloud. You can have access to infrastructure and services that would cost millions of dollars if you bought them on your own. Instead, you can have access to the same resources for a small fraction of the cost.

A private cloud just becomes a fancy name for a data center managed by a trusted third party, and all the elasticity benefits wither away.

Even though AWS, Azure, Google Cloud Platform (GCP), and the other popular cloud providers are considered mostly public clouds, there are some actions you can take to make them more private. As an example, AWS offers Amazon EC2 dedicated instances, which are EC2 instances that ensure that you will be the only user for a given physical server. Again, this comes at a cost.

Dedicated instance costs are significantly higher than on-demand EC2 instances. On-demand instances may be shared with other AWS users. As mentioned earlier in the chapter, you will never know the difference because of virtualization and hypervisor technology. One common use case for choosing dedicated instances is government regulations and compliance policies that require certain sensitive data to not be in the same physical server with other cloud users.

Truly private clouds are expensive to run and maintain, and for that reason, many of the resources and services offered by the major cloud providers reside in public clouds. But just because you are using a private cloud does not mean that it cannot be set up insecurely, and conversely, if you are running your workloads and applications on a public cloud, you can use security best practices and sleep well at night knowing that you are using state-of-the-art technologies to secure your sensitive data.

Additionally, most of the major cloud providers' clients use public cloud configurations, but there are a few exceptions even in this case. For example, the United States government intelligence agencies are a big AWS customer. As you can imagine, they have deep pockets and are not afraid to spend. In many cases with these government agencies, AWS will set up the AWS infrastructure and services on the premises of the agency itself. You can find out more about this here:

https://aws.amazon.com/federal/us-intelligence-community/

Now that we have gained a better understanding of cloud computing in general, let's get more granular and learn about how AWS does cloud computing.

Put simply, AWS is the undisputed market leader in cloud computing today, and even though there are a few worthy competitors, it doesn't seem like anyone will push them off the podium for a while. Why is this, and how can we be sure that they will remain a top player for years to come? Because this pattern has occurred in the history of the technology industry repeatedly. Geoffrey A. Moore, Paul Thompson, and Tom Kippola explained this pattern best a long time ago in their book The Gorilla Game: Picking Winners in High Technology.

Some important concepts covered in their book are listed here:

• There are two kinds of technology markets: Gorilla Games and Royalty Markets. In a Gorilla Game, the players are dubbed gorillas and chimps. In a Royalty Market, the participants are kings, princes, and serfs.
• Gorilla Games exist because the market leaders possess proprietary technology that makes it difficult for competitors to compete. This proprietary technology creates a moat that can be difficult to overcome.
• In Royalty Markets, the technology has been commoditized and standardized. In a Royalty Market, it's difficult to become a leader and it's easy to fall off the number one position.
• The more proprietary features a gorilla creates in their product and the bigger the moat they establish, the more difficult and expensive it becomes to switch to a competitor and the stronger the gorilla becomes.
• This creates a virtuous cycle for the market leader or gorilla. The market leader's product or service becomes highly desirable, which means that they can charge more for it and sell more of it. They can then reinvest that profit to make the product or service even better.
• Conversely, a vicious cycle is created for second-tier competitors or chimps. Their product or service is not as desirable, so even if they charge as much money as the market leader, because they don't have as many sales, their research and development budget will not be as large as the market leader.
• The focus of this book is on technology, but if you are interested in investing in technology companies, the best time to invest in a gorilla is when the market is about to enter a period of hypergrowth. At this point, the gorilla might not be fully determined and it's best to invest in gorilla candidates and sell stock as it becomes obvious that they won't be a gorilla and reinvest the proceeds of that sale into the emerging gorilla.
• Once a gorilla is established, most often, the way that a gorilla is vanquished is by a complete change in the game, where a new disruptive technology creates a brand new game.

To get a better understanding, let look at an example of a Royalty Market and an example of a Gorilla Game.

Personal computers and laptops – Back in the early 1980s when PCs burst onto the scene, many players emerged that sold personal computers, such as these:

• Dell
• Gateway
• IBM
• Hewlett Packard

I don't know about you, but whenever I buy a computer, I go to the store, see which computer is the cheapest and has the features I want, and pull the trigger regardless of the brand. This is the perfect example of a Royalty Market. It is difficult to differentiate yourself and stand out and there is little to no brand loyalty among consumers.

Personal computer operating systems – Whenever I buy a new computer, I make sure of one thing: that the computer comes with Microsoft Windows, the undisputed market leader in the space. Yes, the Macintosh operating system has been around for a long time, Linux has been around for a while making some noise, and the Google Chrome operating system is making some inroads, especially in the educational market. But ever since it was launched in November 1985, Microsoft Windows has kept the lion's share of the market (or should we say the gorilla's share?).

Of course, this is a subjective opinion, but I believe we are witnessing the biggest Gorilla Game in the history of computing with the advent of cloud computing. This is the mother of all competitive wars. Cloud vendors are not only competing to provide basic services, such as compute and storage, but are continuing to build more services on top of these core services to lock in their customers further and further. Vendor lock-in is not necessarily a bad thing. Lock-in, after all, is a type of golden handcuffs. Customers stay because they like the services they are being offered. But customers also realize that as they use more and more services, it becomes more and more expensive to transfer their applications and workloads to an alternate cloud provider.

Not all cloud services are highly intertwined with their cloud ecosystems. Take these scenarios, for example:

• Your firm may be using AWS services for many purposes, but it may be using WebEx, Microsoft Teams, Zoom, or Slack for its video conference needs instead of Amazon Chime. These services have little dependency on other underlying core infrastructure cloud services.
• You may be using Amazon SageMaker for artificial intelligence and machine learning projects, but you may be using the TensorFlow package in SageMaker as your development kernel, even though TensorFlow is maintained by Google.
• If you are using Amazon RDS and you choose MySQL as your database engine, you should not have too much trouble porting your data and schemas over to another cloud provider that also supports MySQL, if you decide to switch over.

With some other services, it will be a lot more difficult to switch. Here are some examples:

• Amazon DynamoDB is a NoSQL proprietary database only offered by AWS. If you want to switch over to another NoSQL database, porting it may not be a simple exercise.
• If you are using CloudFormation to define and create your infrastructure, it will be difficult, if not impossible, to use your CloudFormation templates to create infrastructure in other cloud provider environments. If the portability of your infrastructure scripts is important to you and you are planning on switching cloud providers, Terraform by HashiCorp may be a better alternative since Terraform is cloud-agnostic.
• If you have a graph database requirement and you decide to use Amazon Neptune (which is the native Amazon graph database offering), you may have a difficult time porting out of Amazon Neptune, since the development language and format can be quite dissimilar if you decide to use another graph database solution such as Neo4j or TigerGraph.

As far as we have come in the last 15 years with cloud technologies, I believe, and I think vendors realize, that these are the beginning innings, and locking customers in right now while they are still deciding who their vendor is going to be will be a lot easier than trying to do so after they pick a competitor.

A good example of one of those make-or-break decisions is the awarding of the Joint Enterprise Defense Infrastructure (JEDI) cloud computing contract by the Pentagon. JEDI is a $10 billion 10-year contract. As big as that dollar figure is, even more important is the fact that it would be nearly impossible for the Pentagon to switch to another vendor once the 10-year contract is up.

For that reason, even though Microsoft was initially awarded the contract, Amazon has sued the US government to potentially get them to change their mind and use AWS instead.

Let's delve a little deeper into how influential AWS currently is and how influential it has the potential to become.

It is hard to argue that AWS is not the gorilla in the cloud market. For the first 9 years of AWS's existence, Amazon did not break down their AWS sales and their profits. As of January 2020, Microsoft does not fully break down its Azure revenue and profit. As of 2019, in its quarterly reports, they were disclosing their Azure revenue growth rate without reporting the actual revenue number and instead burying Azure revenues in a bucket called Commercial Cloud, which also includes items such as Office 365 revenue. Google, for a long time, has been cagey about breaking down its GCP revenue. Google finally broke down its GCP revenue in February 2019.

The reason cloud providers are careful about reporting these raw numbers is precisely because of the Gorilla Game. Initially, AWS did not want to disclose numbers because they wanted to become the gorilla in the cloud market without other competitors catching wind of it. And if Microsoft and Google disclosed their numbers, it would reveal the exact size of the chasm that exists between them and AWS.

Even though AWS is the gorilla now, and it's quite difficult to dethrone the gorilla, it appears the growth rates for GCP and Azure are substantially higher than AWS's current growth rate. Analysts have pegged the growth rate for GCP and Azure at about 60% year on year, whereas AWS's recent year-on-year revenue growth is closer to 30% to 40%. But the revenue for Azure and GCP is from a much smaller base.

This practice of most cloud providers leaves the rest of us guessing as to what the exact market share and other numbers really are. But, analysts being analysts, they still try to make an educated guess.

For example, one recent analysis from Canalys Cloud Channels in 2019 puts AWS's share of the market at around 33% and the market share for its closest competitor, Azure, at around 17%.

Up until this point, AWS has done a phenomenal job of protecting their market share by adding more and more services, adding features to existing services, building higher-level functionality on top of the core services they already offer, and educating the masses on how to best use these services. It is hard to see how they could lose the pole position. Of course, anything is possible, including the possibility of government intervention and regulation, as occurred in the personal computer chip market and in the attempt the government made to break up Microsoft and their near monopoly on the personal operating system market.

We are in an exciting period when it comes to cloud adoption. Up until just a few years ago, many C-suite executives were leery of adopting cloud technologies to run their mission-critical and core services. A common concern was that they felt having on-premises implementations was more secure than running their workloads on the cloud.

It has become clear to most of them that running workloads on the cloud can be just as secure, if not more secure, than running them on-premises. There is no perfectly secure environment, and it seems that almost every other day we hear about sensitive information being left exposed on the internet by yet another company. But having an army of security experts on your side, as is the case with the major cloud providers, will often beat any security team that most companies can procure on their own.

The current state of the cloud market for most enterprises is a state of Fear Of Missing Out (FOMO). Chief executives are watching their competitors jumping on the cloud and they are concerned that they will be left behind if they don't take the leap as well.

Additionally, we are seeing an unprecedented level of disruption in many industries propelled by the power of the cloud. Let's take the example of Lyft and Uber. Both companies rely heavily on cloud services to power their infrastructure and old-guard companies in the space, such as Hertz and Avis, that rely on older on-premises technology are getting left behind. In fact, on May 22, 2020, Hertz filed for bankruptcy protection. Part of the problem is the convenience that Uber and Lyft offer by being able to summon a car on demand. Also, the pandemic that swept the world in 2020 did not help. But the inability to upgrade their systems to leverage cloud technologies no doubt played a role in their diminishing share of the car rental market.

Let's continue and learn some of the basic cloud terminology in general and AWS terminology in particular.

There is a constant effort by technology companies to offer common standards for certain technologies while providing exclusive and proprietary technology that no one else offers.

An example of this can be seen in the database market. The Standard Query Language (SQL) and the ANSI-SQL standard have been around for a long time. In fact, the American National Standards Institute (ANSI) adopted SQL as the SQL-86 standard in 1986.

Since then, database vendors have continuously been supporting this standard while offering a wide variety of extensions to this standard in order to make their products stand out and to lock in customers to their technology.

The cloud is no different. Cloud providers provide the same core functionality for a wide variety of customer needs, but they all feel compelled to name these services differently, no doubt in part to try to separate themselves from the rest of the pack and make it more difficult to switch out of their environments once companies commit to using them.

As an example, every major cloud provider offers compute services. In other words, it is simple to spin up a server with any provider, but they all refer to this compute service differently:

• AWS uses EC2 instances.
• Azure uses Azure VM.
• GCP uses Google Compute Engine.

The following tables give a non-comprehensive list of the different core services offered by AWS, Azure, and GCP and the names used by each of them:

Table 1.1 – Cloud provider terminology and comparison (part 1)

These are some of the other services, including serverless technology services and database services:

Table 1.2 – Cloud provider terminology and comparison (part 2)

These are additional services:

Table 1.3 – Cloud provider terminology and comparison (part 3)

If you are confused by all the terms in the preceding tables, don't fret. We will learn about many of these services throughout the book and when to use each of them.

In the next section, we are going to learn why cloud services are becoming so popular and in particular why AWS adoption is so prevalent.

Depending on who you ask, some estimates peg the global cloud computing market at around USD 370 billion in 2020, growing to about USD 830 billion by 2025. This implies a Compound Annual Growth Rate (CAGR) of around 18% for the period.

There are multiple reasons why the cloud market is growing so fast. Some of them are listed here:

• Elasticity
• Security
• Availability
• Faster hardware cycles
• System administration staff
• Faster time to market

Let's look at the most important one first.

Elasticity

Elasticity may be one of the most important reasons for the cloud's popularity. Let's first understand what it is.

Do you remember the feeling of going to a toy store as a kid? There is no feeling like it in the world. Puzzles, action figures, games, and toy cars are all at your fingertips, ready for you to play with them. There was only one problem: you could not take the toys out of the store. Your mom or dad always told you that you could only buy one toy. You always had to decide which one you wanted and invariably, after one or two weeks of playing with that toy, you got bored with it and the toy ended up in a corner collecting dust, and you were left longing for the toy you didn't choose.

What if I told you about a special, almost magical, toy store where you could rent toys for as long or as little as you wanted, and the second you got tired with the toy you could return it, change it for another toy, and stop any rental charges for the first toy? Would you be interested?

The difference between the first traditional store and the second magical store is what differentiates on-premises environments and cloud environments.

The first toy store is like having to set up infrastructure on your own premises. Once you purchase a piece of hardware, you are committed to it and will have to use it until you decommission it or sell it at a fraction of what you paid for it.

The second toy store is analogous to a cloud environment. If you make a mistake and provision a resource that's too small or too big for your needs, you can transfer your data to a new instance, shut down the old instance, and importantly, stop paying for that instance.

More formally defined, elasticity is the ability of a computing environment to adapt to changes in workload by automatically provisioning or shutting down computing resources to match the capacity needed by the current workload.

In AWS as well as with the main cloud providers, resources can be shut down without having to completely terminate them, and the billing for resources will stop if the resources are shut down.

This distinction cannot be emphasized enough. Computing costs in a cloud environment on a per-unit basis may even be higher when comparing them with on-premises prices, but the ability to shut resources down and stop getting charged for them makes cloud architectures cheaper in the long run, often in a quite significant way. The only time when absolute on-premises costs may be lower than cloud costs is if workloads are extremely predictable and consistent. Let's look at exactly what this means by reviewing a few examples.

Web storefront

A popular use case for cloud services is to use it to run an online storefront. Website traffic in this scenario will be highly variable depending on the day of the week, whether it's a holiday, the time of day, and other factors.

This kind of scenario is ideally suited for a cloud deployment. In this case, we can set up resource load balancers that automatically start and shut down compute resources as needed. Additionally, we can set up policies that allow database storage to grow as needed.

Apache Spark and Hadoop workloads

The popularity of Apache Spark and Hadoop continues to increase. Many Spark clusters don't necessarily need to run consistently. They perform heavy batch computing for a period and then can be idle until the next batch of input data comes in. A specific example would be a cluster that runs every night for 3 or 4 hours and only during the working week.

In this instance, the shutdown of resources may be best managed on a schedule rather than by using demand thresholds. Or, we could set up triggers that automatically shut down resources once the batch jobs are completed.

Online storage

Another common use case in technology is file and object storage. Some storage services may grow organically and consistently. The traffic patterns can also be consistent.

This may be one example where using an on-premises architecture may make sense economically. In this case, the usage pattern is consistent and predictable.

Elasticity is by no means the only reason that the cloud is growing in leaps and bounds. Having the ability to easily enable world-class security for even the simplest applications is another reason why the cloud is becoming pervasive. Let's understand this at a deeper level.

Security

The perception of on-premises environments being more secure than cloud environments was a common reason that companies big and small would not migrate to the cloud. More and more enterprises are now realizing that it is extremely hard and expensive to replicate the security features that are provided by cloud providers such as AWS. Let's look at a few of the measures that AWS takes to ensure the security of its systems.

Physical security

You probably have a better chance of getting into the Pentagon without a badge than getting into an Amazon data center.

AWS data centers are continuously upgraded with the latest surveillance technology. Amazon has had decades to perfect the design, construction, and operation of its data centers.

AWS has been providing cloud services for over 15 years and it literally has an army of technologists, solution architects, and some of the brightest minds in the business. It leverages this experience and expertise to create state-of-the-art data centers. These centers are in nondescript facilities. You could drive by one and never know what it is. If you do find out where one is, it will be extremely difficult to get in. Perimeter access is heavily guarded. Visitor access is strictly limited, and they always must be accompanied by an Amazon employee.

Every corner of the facility is monitored by video surveillance, motion detectors, intrusion detection systems, and other electronic equipment.

Amazon employees with access to the building must authenticate themselves four times to step on the data center floor.

Only Amazon employees and contractors that have a legitimate right to be in a data center can enter. Any other employee is restricted. Whenever an employee does not have a business need to enter a data center, their access is immediately revoked, even if they are only moved to another Amazon department and stay with the company.

Lastly, audits are routinely performed and part of the normal business process.

Encryption

AWS makes it extremely simple to encrypt data at rest and data in transit. It also offers a variety of options for encryption. For example, for encryption at rest, data can be encrypted on the server side, or it can be encrypted on the client side. Additionally, the encryption keys can be managed by AWS, or you can use keys that are managed by you.

Compliance standards supported by AWS

AWS has robust controls in place to allow users to maintain security and data protection. We'll be talking more about how AWS shares security responsibilities with its customers, but the same is true with how AWS supports compliance. AWS provides many attributes and features that enable compliance with many standards established by different countries and standards organizations. By providing these features, AWS simplifies compliance audits. AWS enables the implementation of security best practices and many security standards, such as these:

• ITAR
• SOC 1/SSAE 16/ISAE 3402 (formerly SAS 70)
• SOC 2
• SOC 3
• FISMA, DIACAP, and FedRAMP
• PCI DSS Level 1
• DOD CSM Levels 1-5
• ISO 9001/ISO 27001/ISO 27017/ISO 27018
• MTCS Level 3
• FIPS 140-2
• HITRUST

In addition, AWS enables the implementation of solutions that can meet many industry-specific standards, such as these:

• Criminal Justice Information Services (CJIS)
• Family Educational Rights and Privacy Act (FERPA)
• Cloud Security Alliance (CSA)
• Motion Picture Association of America (MPAA)
• Health Insurance Portability and Accountability Act (HIPAA)

Another important thing that can explain the meteoric rise of the cloud is how you can stand up high-availability applications without having to pay for the additional infrastructure needed to provide these applications. Architectures can be crafted in such a way that additional resources are started when other resources fail. This ensures that we only bring additional resources when they are necessary, keeping costs down. Let's analyze this important property of the cloud in a deeper fashion.

Availability

When we deploy infrastructure in an on-premises environment, we have two choices. We can purchase just enough hardware to service the current workload, or we can make sure that there is enough excess capacity to account for any failures that may occur. This extra capacity and the elimination of single points of failure is not as simple as it may first seem. There are many places where single points of failure may exist and need to be eliminated:

• Compute instances can go down, so we need to have a few on standby.
• Databases can get corrupted.
• Network connections can be broken.
• Data centers can flood or burn down.

This last one may seem like a hypothetical example but there was a fire reported in the suburb of Tama in Tokyo, Japan, that apparently was at an AWS data center under construction. Here is a clip of the incident:

https://www.datacenterdynamics.com/en/news/aws-building-site-burns-in-fatal-tokyo-fire-reports-say/

Using the cloud simplifies the "single point of failure" problem. We already determined that provisioning software in an on-premises data center can be a long and arduous process. In a cloud environment, spinning up new resources can take just a few minutes. So, we can configure minimal environments knowing that additional resources are a click away.

AWS data centers are built in different regions across the world. All data centers are "always on" and delivering services to customers. AWS does not have "cold" data centers. Their systems are extremely sophisticated and automatically route traffic to other resources if a failure occurs. Core services are always installed in an N+1 configuration. In the case of a complete data center failure, there should be the capacity to handle traffic using the remaining available data centers without disruption.

AWS enables customers to deploy instances and persist data in more than one geographic region and across various data centers within a region.

Data centers are deployed in fully independent zones. Each data center is constructed with enough separation between them such that the likelihood of a natural disaster affecting two of them at the same time is very low. Additionally, data centers are not built in flood zones.

To increase resilience, data centers have discrete Uninterruptable Power Supplies (UPSes) and onsite backup generators. They are also connected to multiple electric grids from multiple independent utility providers. Data centers are connected redundantly to multiple tier-1 transit providers. Doing all this minimizes single points of failure.

Faster hardware cycles

When hardware is provisioned on-premises, from the instant that it is purchased it starts becoming obsolete. Hardware prices have been on an exponential downtrend since the first computer was invented, so the server you bought a few months ago may now be cheaper, or a new version of the server may be out that's faster and still costs the same. However, waiting until hardware improves or becomes cheaper is not an option. At some point, a decision needs to be made and a purchase needs to be made.

Using a cloud provider instead eliminates all these problems. For example, whenever AWS offers new and more powerful processor types, using them is as simple as stopping an instance, changing the processor type, and starting the instance again. In many cases, AWS may keep the price the same even when better and faster processors and technology become available.

System administration staff

An on-premises implementation may require full-time system administration staff and a process to ensure that the team remains fully staffed. By using cloud services, many of these tasks can be handled by the cloud providers, allowing you to focus on core application maintenance and functionality and not have to worry about infrastructure upgrades, patches, and maintenance.

By offloading this task to the cloud provider, costs can come down because instead of having a dedicated staff, the administrative duties can be shared with other cloud customers.