Introduction to architecture diagramming. An architecture diagram is a map of a software system and the relationships between those components. For example, this is an architecture diagram. Architecture diagrams are important because they help us frame our conversations about the Cloud. If you work with the Cloud, you'll be constantly creating, reviewing, and interpreting these architecture diagrams. Let's create a simple hypothetical architecture diagram for Airbnb. Let's use this diagram to show the type of application that might power Airbnb. One that allows you to book an Airbnb in Denver from January 1st to January 7th for less than $40 a day. This diagram starts with two halves. The purple half in the left represents the client. The white half in the right represents the server. This is the client-server architecture, are the most commonly used computing architecture today. When you log into your email, your computer queries a mail server somewhere. The mail server responds with your new emails. When you logged into Coursera to watch these videos today, it queries Coursera's AWS servers. The AWS servers responded with the content you're watching right now. Clients can be from all over the world and represent users and their laptops, smartphones, tablets, and other devices, making requests to AWS servers running Airbnb's logic. In my diagram, the client contains the icon for many users, which includes you trying to book your Airbnb. The server contains a server icon inside the AWS Cloud because we know that Airbnb uses AWS servers. Finally, there's an arrow between the clients and the AWS Cloud showing the flow of data into and from AWS. What happens when you type Airbnb.com into your browser bar? Your web browser sends a request to a domain name system, abbreviated DNS, to translate Airbnb.com into the machine readable IP address 54.227.25.54. Amazon provides a DNS service called Route 53. Once Route 53 tells your laptop the correct IP address, it will connect your laptop to the Airbnb server, which happens to be in Ashburn, Virginia, and display the Airbnb website on your laptop. Assume that a few milliseconds have passed and the Airbnb website loaded onto your laptop, you start entering inputs such as the date range January 1 to January 7, geography, Denver, and your price range, less than $40 per night. Every time you make an input, your browser sends that request to Airbnb's application server, which is an Amazon Elastic Cloud Compute , abbreviated EC2 Instance. This EC2 Instance translates your request into a query for a database such as Amazon Aurora. Aurora performs the query and reports back to EC2, such as, "here's a list of all Airbnb's endeavor available during that period of time that charge less than $40 per night." The EC2 server then delivers that list of matching results to your web browser. Your laptop shows you the Airbnbs that fit your criteria. Airbnb also wants to show you pictures to inform your decision. It stores those pictures and other static files on Amazon Simple Storage Service, abbreviated S3, because this is more cost-effective than storing the pictures in a database like Aurora. Instead, in our example, Amazon Aurora contains a reference to where each image is on S3. EC2 gets that reference from Aurora, pulls the image from S3, and sends it to your laptop. Now let's assume that Airbnb is expanding into Brazil, China, India, and Russia. It probably doesn't want everyone connecting to Ashburn, Virginia because that would slow down search results and page loads for its global customers. Airbnb uses AWS CloudFront to cache its most popular content at edge locations around the world. In general, the more often a group of people at a particular location request a specific image or object or information, the more likely Amazon CloudFront will include it in its cache for future users to load quickly. Back when I looked through the Airbnb public data set, there was a California man who lived in a trailer with a bunch of goats, and he was the most popular Airbnb in the world. Why not? He let us guess pet his goats. Because his Airbnb was so popular, his Airbnb photos were probably cached in Amazon CloudFront. This practice of caching shows us that, for AWS, speed matters. AWS wants to minimize the latency and deliver content to customers without delay. Another location where we can place a cache is in front of the database using Amazon ElastiCache to further speed things up. When EC2 queries the database, if the information is already available in ElastiCache, the database does not need to run a search through the disk. Now, you might wonder, for the fastest experience, shouldn't we put everything in Aurora into ElastiCache? The answer is no, because caching has two drawbacks. The first drawback is that because caches are much faster, they're also much more expensive to store data on than a slower object store such as S3. The second drawback is that the data stored in ElastiCache is ephemeral, meaning that if your cached resource is interrupted for any reason, you lose all your cached data. Your cache has to re-learn what your users want to view. This is different from storage and databases services that write to a disk, making the written data permanent. It also means that if your storage or databases services suffer an interruption, that data you have written will still be there after the interruption passes. Now let's assume that Airbnb is a huge success. Users increased from thousands to millions and existing EC2 servers can't keep up with the demand. This is when EC2 and Aurora can start up more instances scaling to meet that increased demand. But if you have multiple EC2 Instances, how does Route 53 know which one to send your request? The answer is to let Elastic Load Balancing pick the best EC2 Instance for you. An Elastic Load Balancer assess how much traffic each EC2 Instance is handling and routes your request to the EC2 Instance that can respond to your request the fastest. Finally, let's assume there's a pandemic, most of the world is locked down, and no one is traveling or using Airbnb. What can Airbnb do to save costs given low usage? AWS allows Airbnb to scale down its fleet of EC2 Instances and databases and achieve cost savings. This means that Airbnb can always respond to demand and pay for only the services it needs. Let's reflect on what we just did. We created an architecture diagram of a full-stack application on AWS. A full-stack application is one that combines network, compute, database, and storage resources, and is the modern approach for building software systems. In our approach, Route 53 is a network service, EC2 is a compute service, Aurora is a database service, and S3 in a storage service. We also saw that every time we needed a part of our application stack, AWS provided a corresponding service. If this sork of work interests you, then please continue with our specialization as we dig into the roles of individual AWS services.
