A brief introduction to Amazon Web Services
I have seen over the last couple of weeks that the interest to become an AWS practitioner or even expert has increased, or at least is in more demand.
And that makes sense, since it is still the most relevant player in the cloud industry right now.
And as a certified Solutions Architect in AWS, I would like to give you a brief introduction of what is it and what’s the problem is aiming to solve for its consumers.
What is the cloud?
Let’s start from the very beginning, what is exactly the cloud and what is its purpose in the computing industry?
We need to remember how deploying apps used to work back in the 2000's. Before the cloud, what companies used to do was to buy physical Servers connected to a energy supply and to the internet to deploy something to the internet. The so-called On-premises servers.
Basically a tiny data center in the company building or if you were a startup, probably in your parent’s garage.
That was really expensive and complex. The complexity comes from the technical expertise in system admin and the costly side comes from the upfront investment required to get up and running your server.
So if you were an entrepreneur back then, it would be very difficult for you to start and your probabilities to success would be drastically reduced due to the highly technical and financial support needed to scale your product.
More disadvantages of On-premises infrastructure
We already talked about the initial cost of the server and the complexity of setting everything up the server. However, there were many more issues related to physical servers. First of all: maintaining the servers.
One thing is to set everything up, but a very different one is to maintain it over time. Even that infrastructure expire after some years, depending on many factors but overall, how much the server has been used and how much has given maintenance.
But let’s imagine you already overcame those challenges. You are a seasoned systems admin and know exactly what to do to keep everything up and running. But now, what happens if you are expecting an increase in new customers for a given period of time. Let’s say Christmas season.
You digital product might be able to increase during last year season, but how much will it increase? We do not know for certain, but we know that the increase would be significant. How significant, 20, maybe 50%?
Here is where On-premises prove not to be scalable. Because we, as humans are more likely to overbuy servers and probably we end up expecting an increase of 50% in traffic but the reality was that our increase was around 25–30% just to say an example.
The takeaway here is:
Companies used to spent much more than what actually needed because On-premises infra was very difficult to scale.
Servers on-demand
Amazon was one of the few winners in the dotcom times back then and they too were victim of the disadvantages with On-premises infra. They developed a solution for internal use where they could run servers remotely on-demand mainly for testing and innovation purposes.
What they wanted was to validate some ideas very quickly, so they needed some server ready-to-use to deploy a possible product and validate with the customers. In case there was some traction in the product, iterating and scaling would be much easier.
However, they understood that this product could be helpful for many companies handling the same issue. So they launched their first platform to the public customers giving the option to get a server on-demand.
That very first product was the equivalent of today’s EC2 (Elastic Compute Cloud). EC2 gives you the possibility to “rent” a server, with the specifications that you want and do whatever you want there.
You can setup a database in that server, or use it as a backend server too. In any case, you have all the flexibility and responsibility to do whatever you want with the server. You have to maintain it, but remotely.
So, it is like having the physical server, but online. The main advantage is that you can turn it off if you do not need it anymore as well as paying for the server only after you used it.
Evolution of the cloud
That’s the way how AWS started out, giving the possibility to “rent” a server and start setting it up in minutes instead of buying a physical one, configure it, patching it with security software, buying a OS license and start using it, a process that could take at least 2 weeks and having a high upfront cost.
But AWS quickly realized it could offer easy-to-use products, such as a database as a service, along with some other products related to storage, computing and networking.
The idea of it was that you as a customer should not need to touch any physical networking device to deploy a digital product. So overtime it starts offering a set of products to host all your needs on the Cloud.
For example, databases as a service, where you only had to worry about entering your data, while AWS helps you to set it up in minutes and adding some caching, as well as read replicas and all in several data centers to ensure the security and consistency of your data.
And like that, the same was done for servers, storage, memory and networking. So, today you can build a professional infrastructure from scratch using AWS, with a relatively low cost and on-demand. Meaning you only pay for what you use.
How it works under the hood?
If you are like me, probably you wonder: Ok, I got that it is used for, but how it actually works, how can I start using it?
Well, Amazon only used technology that already existed, such as Virtualization and Hypervisor, where you can control someone’s else computer remotely. These are the fundamental technologies for AWS to work.
So, whenever you rent a server, in its most basic level, you are giving some credential so you can login to the remote instance of the server and then you got access to it from the terminal. So is like you using your own terminal on local, but with the difference that you are manipulating a remotely one in the data center of your choose.
As well you can login to the amazon console and start creating s3 buckets and many more stuff, but that’s not used too much in the professional area.
And finally, you can download a SDK for Nodejs, for example to connect to your AWS account and start modifying your cloud instances, buckets, etc programmatically.
At the end, you would end up having something like the following in your node app to start allocating, removing or updating resources from your app.
import { S3Client, ListBucketsCommand } from "@aws-sdk/client-s3";
const s3 = new S3Client({ region: "us-east-1" });
async function listBuckets() {
try {
const data = await s3.send(new ListBucketsCommand({}));
console.log("Buckets:", data.Buckets);
} catch (err) {
console.error("Error:", err);
}
}
listBuckets();
And that’s all I got for this post. I’m thinking about doing some other posts talking more on the technical level of how to use AWS and some recommendations to scale and secure your instances, as well as how to manage the roles and users to ensure safety in your resources. Let me know if you would be interested on those.