Thinking in terms of cloud and not infrastructure
The day I discovered that noise can damage hard drives.
In December 2011, sometime between Christmas and new Year's Eve, I received dozens of alerts from OnLive's (my employer then) monitoring system. Apparently, we had just lost connectivity to our European data center in Luxembourg. I rushed to the network operations center (NOC) hoping that it's only a small glitch in our monitoring system, maybe just a joke after all; with so much redundancy, how can everything go offline? Unfortunately, when I got into the room, the big monitoring monitors were all red, not a good sign. This was just the beginning of a very long nightmare. An electrician working in our data center mistakenly triggered the fire alarm; within seconds, the fire suppression system set off and released its aragonite on top of our server racks. Unfortunately, this kind of fire suppression system made so much noise when it released its gas that sound waves instantly killed hundreds and hundreds of hard drives, effectively shutting down our only European facility. It took months for us to be back on our feet.
Where is the cloud when you need it!
Charles Philips said it best, "Friends don't let friends build a data center."
Deploying your own hardware versus in the cloud
It wasn't long ago that tech companies, small and large, had to have a proper technical operations organization able to build out infrastructures.
The process went a little bit like this:
- Fly to the location you want to set up your infrastructure in; take a tour of different data centers and their facilities. Look at the floor considerations, power considerations, HVAC (Heating, Ventilating, and Air Conditioning), fire prevention systems, physical security, and so on.
- Shop for an internet provider; ultimately, you are talking about servers and a lot more bandwidth but the process is the same: you want to get internet connectivity for your servers.
- Once this is done, it's time to buy your hardware. Make the right decisions because you will probably spend a big portion of your company's money on buying servers, switches, routers, firewalls, storage, UPS (for when you have a power outage), KVM, network cables, the dear to every system administrator's heart labeler and a bunch of spare parts, hard drives, raid controllers, memory, power cables, and much more.
- At this point, once the hardware is bought and shipped to the data center location, you can rack everything, wire all the servers, and power everything. Your network team can kick in and establish connectivity to the new data center using various links, configuring the edge routers, switches, top of the racks switches, KVM, and firewalls (sometimes). Your storage team is next and will provide the much needed Network Attached Storage (NAS) or Storage Area Network (SAN); next, comes your sysops team, who will image the servers, sometimes upgrade the BIOS, configure hardware raid, and finally put an OS on these servers.
Not only is this a full-time job for a big team, but it also takes a lot of time and money to even get there.
As you will see in this book, getting new servers up and running with AWS will take us minutes. In fact, more than just providing a server within minutes, you will soon see how to deploy and run a service in minutes and just when you need it.
Cost analysis
From a cost standpoint, deploying in a cloud infrastructure such as AWS usually ends up being a lot cheaper than buying your own hardware. If you want to deploy your own hardware, you have to pay upfront for all the hardware mentioned previously (servers, network equipment, and so on) and sometimes licensed software as well. In a cloud environment, you pay as you go. You can add or remove servers in no time and only be charged for the duration the servers were running for. Also, if you take advantage of PaaS and SaaS applications, you usually end up saving even more money by lowering your operating costs as you don't need as many staff to administrate your database, storage, and so on. Most cloud providers, AWS included, also offer tiered pricing and volume discount. As your service gets bigger and bigger, you end up paying less for each unit of storage, bandwidth, and so on.
Just-in-time infrastructure
As you just saw, when deploying in the cloud, you only pay for the resources you provision. Most cloud companies use this to their advantage to scale their infrastructure up or down as the traffic to their site changes.
This ability to add or remove new servers and services in no time and on demand is one of the main differentiators of an effective cloud infrastructure. In the example below, we can see the amount of traffic hitting Amazon.com during the month of November. Thanks to Black Friday and Cyber Monday, the traffic triples at the end of the month:
© 2017, Amazon Web Services, Inc. or its affiliates. All rights reserved.
If the company was hosting their service in an old-fashioned way, they would need to have enough servers provisioned to handle this traffic such that only 24% of their infrastructure used on an average during the month:
© 2017, Amazon Web Services, Inc. or its affiliates. All rights reserved.
however, thanks to being able to scale dynamically, they are able to provide only what they really need and dynamically absorb the spikes in traffic that Black Friday and Cyber Monday trigger:
© 2017, Amazon Web Services, Inc. or its affiliates. All rights reserved.
Here at Medium, you also see, on a very regular basis, the benefits of having fast auto-scaling capabilities. Very often, stories become viral and the amount of traffic going on Medium drastically changes. On January 21, 2015, to our surprise, the White House posted a transcript of the State of the Union minutes before President Obama started his speech:
As you can see in the following graph, thanks to being in the cloud and having auto-scaling capabilities, our platform was able to absorb five times the instant spike of traffic that the announcement made by doubling the number of servers our front service used. Later, as the traffic started to drain naturally, you automatically removed some hosts from our fleet:
The different layers of building a cloud
Cloud computing is often broken down into three different types of services, as follows:
- Infrastructure as a Service (IaaS): This is the fundamental block on top of which everything cloud is built upon. IaaS is usually a computing resource in a virtualized environment. It offers a combination of processing power, memory, storage, and network. The most common IaaS entities you will find are virtual machines (VM), network equipment, such as load balancers or virtual Ethernet interfaces, and storage such as block devices. This layer is very close to the hardware and gives you the full flexibility that you would get deploying your software outside of a cloud. If you have any physical knowledge about data centers, it will also mostly apply to this layer.
- Platform as a Service (PaaS): This layer is where things start to get really interesting with the cloud. When building an application, you will likely need a certain number of common components, such as a data store and a queue. The PaaS layer provides a number of ready-to-use applications to help you build your own services without worrying about administrating and operating those third-party services such as database servers.
- Software as a Service (SaaS): This layer is the icing on the cake. Similar to the PaaS layer, you get access to managed services, but this time these services are a complete solution dedicated to certain purposes, such as management or monitoring tools.
This book covers a fair amount of services of PaaS and SaaS types. When building an application, relying on these services make a big difference when compared to the more traditional environment outside of the cloud.
Another key element to success when deploying or migrating to a new infrastructure is to adopt a DevOps mindset.
