In the beginning, Jeff Bezos created Amazon.com and took the company to a successful Initial Public Offering (IPO) by 1997. Everyone knows Amazon.com, of course, and it has become a force of nature, dominating the online retail and diversifying into several other fields. However, in the early 2000s, after the Dotcom bubble burst, the company's future was not quite as certain as now. Even so, one of the many things that Amazon was doing right even then was architecting its internal computer systems in a truly robust and scalable way.

Amazon had a lot of users and a lot of traffic, and in order to service that traffic, the company really had to think deeply about how to build scalable, cost-effective compute capacity. Now you could argue rightly that other companies had to think about the same issues too. Google also had a lot of users and a lot of traffic, and it had to think really carefully about how to handle it. Even so, most observers agree that a couple of important differences existed between the two giants. For one, Google's business was (and is) fundamentally a far more profitable one, which means that Google could always afford to overinvest in compute, secure in the knowledge that its money printing press in the ad business would cover the costs. For another, Google's primary technical challenges came in processing and making sense of vast quantities of data (it was basically indexing the entire internet for Google Search). Amazon's primary technical challenges lay around making sure that the inherently spiky traffic of their hundreds of millions of users was serviced just right. The spiky nature of consumer traffic remains a huge consideration for any online retail firm. Just consider Alibaba, which did $25 billion in sales on Singles Day (11/11) in 2017.

Somewhere along the line, Amazon realized that it had created something really cool: a set of APIs and services, a platform in fact that external customers would be willing to pay for, and that would help Amazon monetize excess server capacity it had lying about. Let's not underestimate the magnitude of that achievement; plenty of companies have overinvested in servers and have extra capacity lying around, but virtually none of them have built a platform that other external customers are willing and able to use and to pay top dollar for.

So, in 2006, Amazon launched Elastic Compute Cloud (EC2), basically, cloud Virtual Machine (VM) instances, and Simple Storage Service (S3), basically, elastic object storage, which to this day are the bedrock of the AWS cloud offerings. Along the way, the other big firms with the money and technical know how to offer such services jumped in as well. Microsoft launched Azure in 2010, and Google had actually gotten into the act even earlier, in 2008, with the launch of App Engine.

Notice how Amazon's first product offerings were basically Infrastructure as a service (IaaS), whereas Google's initial offering was a Platform as a service (PaaS). That is a significant fact and with the benefit of hindsight, a significant mistake on Google's part. If you are a large organization, circa 2010, and contemplating moving to the cloud, you are unlikely to bet the house on moving to an untested cloud-specific platform such as App Engine. The path of least resistance for big early adopters is definitely the IaaS route. The first-mover advantage and the smart early focus on IaaS helped Amazon open up a huge lead in the cloud market, one which they still hold on to.

In recent years, however, a host of other cloud providers have crowded into the cloud space, notably Microsoft and, to a lesser extent, Google. That partially has to do with the economics of the cloud business; Amazon first broke out the financials of AWS separately in April 2015 and stunned the world with its size and profitability. Microsoft missed a few important big trends in computing, but after Satya Nadella replaced Steve Ballmer at the helm, he really made the cloud a company-wide priority in a way that mobile, search, and hardware never were. The results are obvious, and if you are a Microsoft shareholder, very gratifying. Microsoft is probably the momentum player in the cloud market right now; many smart observers have realized that Azure is challenging AWS despite the still-significant differences between their market shares.

Okay, you say, all fine and good: if AWS is the market leader, and Azure is the momentum player, then why exactly are we reading and writing a book about the Google Cloud Platform? That's an excellent question; in a nutshell, our considered view is that the GCP is a great technology to jump into right now for a few, very rational reasons, as follows:

• Demand-supply: There is a ton of demand for AWS and Azure professionals, but there is also a ton of supply. In contrast, there is growing demand for the GCP, but not yet all that much supply of highly skilled GCP professionals. Careers are made by smart bets on technologies like this one.
• PaaS versus IaaS: Notice how we called out Amazon for being smart in focusing on IaaS early on. That made a lot of sense when cloud computing was new and untested. Now, however, everyone trusts the cloud; that model works, and people know it. This means that folks are now ready to give up control in return for great features. PaaS is attractive now, and GCP's PaaS offerings are very competitive relative to its competitors.
• Kubernetes for hybrid, multi-cloud architectures: You may or may not have heard about this, but Amazon acquired a US-based grocery chain, Whole Foods, some time ago. It gave many current and potential AWS consumers pause for thought, what if Amazon buys up a company in my sector and starts competing with me? As a result, more organizations are likely to want a hybrid, multi-cloud architecture rather than to tie themselves to any one cloud provider. The term hybrid implies that both on-premise data centers and public cloud resources are used, and multi-cloud refers to the fact that more than one cloud provider is in the game. Now, if the world does go the hybrid, multi-cloud way, one clear winner is likely to be a container orchestration technology named Kubernetes. If that does happen, GCP is likely to be a big beneficiary. Kubernetes was developed at Google before being open-sourced, and the GCP offers great support for Kubernetes.

The technical rationale for moving to the cloud can often be summed up in two words—autoscaling and autohealing.

• Autoscaling: The idea of autoscaling is simple enough although the implementations can get quite involved—apps are deployed on compute, the amount of compute capacity increases or decreases depending on the level of incoming client requests. In a nutshell, all the public cloud providers have services that make autoscaling and autohealing easily available. Autoscaling, in particular, is a huge deal. Imagine a large Hadoop cluster, with say 1,000 nodes. Try scaling that; it probably is a matter of weeks or even months. You'd need to get and configure the machines, reshard the data and jump through a trillion hoops. With a cloud provider, you'd simply use an elastic version of Hadoop such as Dataproc on the GCP or Elastic MapReduce (EMR) on AWS and you'd be in business in minutes. This is not some marketing or sales spiel; the speed of scaling up and down on the cloud is just insane.

Here’s a little rhyme to help you remember the main point of our conversation here—we’ll keep using them throughout the remainder of the book just to mix things up a bit. Oh, and they might sometimes introduce a few new terms or ideas that will be covered at length in the following sections, so don’t let any forward references bother you just yet!

• Autohealing: The idea of autohealing is just as important as that of autoscaling, but it is less explicitly understood. Let's say that we deploy an app that could be a Java JAR, Python package, or Docker container to a set of compute resources, which again could be cloud VMs, App Engine backends, or pods in a Kubernetes cluster. Those compute resources will have problems from time to time; they will crash, hang, run out of memory, throw exceptions, and misbehave in all kinds of unpredictable ways. If we did nothing about these problems, those compute resources would effectively be out of action, and our total compute capacity would fall and, sooner or later, become insufficient to meet client requests. So, clearly, we need to somehow detect whether our compute resources got sick, and then heal them. In the pre-cloud days, this would have been pretty manual, some poor sap of an engineer would have to nurse a bare metal or VM back to health. Now, with cloud-based abstractions, individual compute units are much more expendable. We can just take them down and replace them with new ones. Because these units of compute capacity are interchangeable (or fungible—a fancier word that means the same thing), autohealing is now possible:

The financial considerations for moving to the cloud are as important as the technical ones, and it is important for architects and technical cloud folks to understand these so that we don't sound dumb while discussing these at cocktail party conversations with the business guys.

• CAPEX refers to a large upfront spend of money used to get an asset (an asset is a resource that will yield benefits over time, not just in the current period)
• OPEX refers to smaller, recurring spends of money for current period benefit

Now, that the last line in the previous image makes clear the big difference between using the cloud versus going on-premise. If you use the cloud, you don't need to make the big upfront payment. That in turn has several associated advantages:

• No depreciation: When you buy a house, hopefully, it appreciates, but when you buy a car, it loses a fourth of its value as soon as you drive it out of the dealer's parking lot. Depreciation is called an intangible expense, but try selling a barely used car, and you will find it tangible enough. With the cloud, you don't worry about depreciation, but the cloud provider does.
• Transparency: Let's face it folks—big contracts are complicated and have been known to have big payoffs for people concerned. This is a reality of doing business: procurement and sourcing are messy businesses for a reason. Using the cloud is far more transparent and simpler for internal processes and audit
• Flexibility in capacity planning: The worlds of business and history are littered with unfulfilled ambitions and unrealistic plans and targets that went nowhere. Your firm might have a target to triple revenues in 3 years: such ambitious plans are common enough. If you, as an architect, sign off on a commensurate tripling in your server capacity and that business growth does not happen, the finance guys will come asking you why overspent if you are still in this firm 3 years down the line. At that point, you will likely not have the luxury of pointing a finger at the CEO who launched the 3X plan. He likely will have moved on adroitly to another shiny plan.

Note, incidentally, that we did not include straight cost as a reason to move to the cloud. The big cloud providers are all rolling in the money, their stock prices are surging on the heady cocktail of high revenue growth and high profitability. The cloud business is a great business to be in if you can get in. It stands to reason that if the suppliers of cloud services are doing so well financially, the consumers of cloud services are paying for it. So, cloud services are not necessarily cheap, they do, however, offer all of these other attractions that make it a real win-win for both sides in the bargain.

Our considered opinion is that the move to the cloud is going to affect a lot of folks more than they expect. In particular, employees at a host of IT services companies and system integrators will need to retool fast. Now that's not to say that these companies are clear losers, because the cloud services are pretty complex too and will provide lots of room for several different ecosystems. Some things that used to be hard will now be easy, and some things that used to be easy will now be hard. Workforces will need to be retrained, and the expectations of career trajectories will need to be changed. So, if you are new to the cloud world, here are three topics you might want to spend time really understanding—these are now a lot more important than they used to be:

• Containers, Docker, and Kubernetes
• Load balancers
• IaaS technologies such as Terraform or Google Cloud Deployment Manager

On the other hand, folks who are in the following teams probably need to think long and hard about how to get with today's (and tomorrow's) hot technologies because the cloud is radically simplifying what they currently work on:

• Virtual Machines and IaaS sysadmins
• Physical networking, router, and VPN engineers
• Hadoop administrators

You learned about the rise of public cloud computing and how GCP, AWS, and Azure came to where they currently are in the market. We also examined some important technical reasons for switching to the cloud. We looked at some good and bad financial implications of moving to the cloud. Finally, we pointed out some technologies that stand to gain from the rise of the cloud and some others that stand to recede in relevance.