PREFACE
Another day, another Tech Essay posted. This marks the 9th Tech Essay that I have posted in the Chatting Area so far.
Now… For this installment in the Marvel-Of-Software-Engineering, I’ll be covering a very massive product that I wanted to cover since the very start of this series. Now, this product also involves a lot of dense abbreviations and acronyms (e.g., S3 = Simple Storage Service), so I tried to minimize the usage of such keywords as much as humanly possible for this essay. Without further ado, let’s begin the essay, and I’ll finish sorting out what my next “tech essay topic” is going to be about.
AN ESSAY ABOUT AMAZON WEB SERVICES (AWS)
FAANG, composed of the following tech companies: Facebook, Amazon, Apple, Netflix, and Google. Billions of people on the global scale use their products on a daily basis. Specifically for Amazon, we all often identify Amazon as an e-commerce website where we purchase items (e.g., books) online and wait for the shipping trucks to arrive. Granted, Amazon is considered the largest e-commerce application in the world, so this idea is warranted. But the product Amazon itself values most is not their e-commerce website, but their cloud provider: Amazon Web Services (AWS).
But, let’s first get down to the question in your minds, what is a cloud provider? They are companies who offer services like powerful virtual servers, virtual computers, virtual databases, and other powerful virtual tools. They primarily make money as a rental business, letting people rent out their services for a small fee. The size of the fee can depend on how much you’re using from the provider. As one might expect, AWS is a massive money printer for the entire corporation . With over 200 services offered, thousands of companies use AWS services in their web applications. For example, Netflix uses AWS in its backend as a database, storing important information like user data and video files while handling heavy user traffic.
Speaking of which, how does something like AWS handle scalability? One day your website with a backend of AWS has only 100 users, the next day it has 100,000 users. Would your website crash in this case? Well, it could, but it doesn’t have to be that way. For one, AWS allows you to scale the size and power of your server, more RAM and CPU power should handle more user traffic. The other method is for you to increase the quantity of the servers that AWS gives you, and AWS will automatically distribute all the thousands of incoming user requests between these servers (load balancing), ensuring that no individual server will be overwhelmed. Both options do increase your billing though.
Now, when Amazon was started, it was not intended to generate most of its income from a cloud provider, rather it was meant to be an online bookstore that former Wall Street Vice President Jeff Bezos pulled out of his mind in 1994. A relatively simple idea to implement if one would think about it, but it was a massive pain for the engineers. If they wanted to add in any new features, then they would have to constantly build their own servers and infrastructure to handle the updates, a lot of boilerplate setup taking up a mindnumbing amount of time. This issue was not limited to Amazon. Plenty of other tech companies (e.g., Yahoo) had to reinvent the wheel when developing updates.
(Yes, Amazon’s original idea was an online bookstore. The business was started in a garage by Jeff Bezos who left a lucrative career in Wall Street for this, now it’s worth over $2,000,000,000,000)
AWS essentially fixed all these infrastructure issues for Amazon, founded in 2002, engineers no longer had to manually set up their own databases and virtual servers when AWS already had it all prepared/standardized for them. AWS started as something private and only exclusive to Amazon. AWS would later be released to the public for all companies to utilize in 2006, with realizing the infrastructure issues across the entire tech industry and seeing AWS as a game changer that could generate a lot of money.
Technically, while one does rent virtual products from AWS, AWS still runs on hardware for the entire cloud. This is why data centers are vital to AWS ’ success. No data center, no AWS in the first place. When you rent AWS’s virtual services, you are renting a piece of an Amazon data center. Also AWS physical servers require a heavy amount of water and resources to cool them down and keep them running smoothly, resulting in a lot of criticism from climate change activists.
Based on some (unverified) data, Amazon appears to have over 900 data centers set up across the globe for AWS. Now, the reason why Amazon doesn’t just have 1 big data center only in Silicon Valley is because of, y’know, distances. If this was the case, then a software engineer in California using AWS will naturally have better/faster performance compared to someone using AWS in the middle of India. That type of stuff leads to critical issues, especially when other big tech companies have offices in India. Also, with hundreds of data centers, if one goes down, engineers can still use AWS with another available data center.
(The inside of an AWS data center)
Now Amazon doesn’t just brainlessly spam data centers across the world map. No sir, where each data center is built is somewhat nuanced. Multiple data centers are grouped into specific areas called Availability Zones (e.g., some specific spaces in the middle of Oregon). Many Availability Zones are then grouped into a large AWS Region. Regions typically take up a lot of land at once, like one of them is called “us-west-1.” Users can specify what AWS Region to access the data centers at, and it is recommended that they actually the region that is the closest to their location for that instance. If someone lives in Tokyo, then they should select the region called “ap-northeast-1” for smoothest performances.
Amazon also set up a bunch of fiber-optic cables across the world. So when you click on a hyperlink that leads you to a website powered by AWS, a HTTP request will be sent through the cables and signal to the nearest data center in your selected region. The servers in these data centers will then process that HTTP request you sent, and return the contents of the website back to your device.
Welp. This covers most of the physical infrastructure that powers AWS, but what about the software side of it? Every year, Amazon hires over 10,000 Software Engineers and interns into the AWS team. Granted, every other company in FAANG does hire thousands of Software Engineers each year. But for AWS, why do they need many Software Engineers if it was all just a bunch of data centers and nothing more than that? Well, simply put, without any software, any intricate hardware is pretty much useless, especially when dealing with virtual products.
In each AWS data center with all their servers, they undergo virtualization. In a nutshell, one large physical server will be sliced up into multiple virtual servers. Having one singular server to handle all the trillions of incoming HTTP requests at once is typically a recipe for burning, so distributing all the requests to multiple different servers simultaneously serves as an effective solution. It’s also worth noting that the act of virtualization is done by a software itself called a hypervisor, so that’s one of the things that Software Engineers do for AWS.
Amazon’s Software Engineers also split each and every one of their AWS services into 2 distinct systems called the Control Plane and the Data Plane. Let’s first discuss the Control Plane, it is the system that handles all the (administrative) CRUD functions. CRUD stands for “Create, Read, Update, Delete,” it’s used very often when handling and editing databases (e.g., adding entries). Developers using AWS typically access the Control Plane in ways, such as: setting up new AWS servers, expanding the size/power of your servers, and changing configuration. The Data Plane on the other hand deals with the functions of the AWS services themselves. For example, having the individual AWS virtual servers actually handle the many incoming requests at once.
The work that AWS Software Engineers can do isn’t just seen through codebases or databases, but in the field of embedded systems. Embedded systems means a computer program built into electronics to perform a specific task. As it turns out, using traditional Hypervisor software alone isn’t considered optimal, especially for networking and storage purposes. Hypervisors directly use the computers’ CPU and RAM, resulting in a copious amount of computing power being used up. If Amazon wanted to improve AWS performance, then naturally they would need to include some new software that isn’t as reliant on CPU and RAM.
(A bunch of AWS Nitro Cards on display)
This would lead to the creation of the Nitro System. Amazon would build special hardware “Nitro” cards that run the software that handles the AWS cloud’s networking and storage without burning through the CPU and RAM, much more efficient as compared to just using a Hypervisor for all of that. If you haven’t guessed already, it’s the AWS Software Engineers who are writing the code for the embedded Nitro Card software.
(…)
Amazon is not just holding the largest e-commerce application in the world, but it is also holding the largest cloud provider in the world. This might be a case of “Too Big to Fail” in the sense that the internet is extremely reliant on AWS. Let’s just say if AWS gets permanently shut down, then it takes down a good chunk of all software on the internet with it. It’s not just the software in tech companies that would be in bad shape: banks, hospitals, even the US Government utilizes AWS for their agencies (e.g., CIA). Until its competitors like Microsoft catch up with their dominance, we can only hope for no more outages on Amazon’s part.
