AWS: Offered Services And Working In Nutshell

Welcome readers to our second session with AWS. I hope the first session "The Introduction" would have given us a brief idea about Amazon Web Services. In this session, we'll be moving ahead with the other problems AWS has simplified for us & its working.

Continuing with scaling as discussed in our previous session, AWS can easily be deployed in multiple global locations, just selecting a few different options while deploying your application, and AWS takes care of the rest.

But Why would you want to have your application deployed in different parts of the world?

Any web application being accessed from different parts of the world would always like to work on:

a) Reducing latency

b) Adding redundancy

Let me explain the above network terminologies in brief. Network Latency measures the time it takes for some data to get to its destination across the network. It is usually measured as a round trip delay - the time taken for information to get to its destination and back again. The round trip delay is an important measure because a computer that uses a TCP/IP network sends a limited amount of data to its destination and then waits for an acknowledgment to come back before sending any more.

Network redundancy is a process through which additional or alternate instances of network devices are installed within network infrastructure in order to ensure network availability in case of a network device or instance failure.

The round trip time it takes for requests to cover the geographic distance, is one of the hardest challenges to overcome, reducing the time it takes to fetch bits from servers and delivering it to the users' browser.

Basically the only way to reduce latency is to get your web application closer to that user. If you were self-hosting, you would have next to zero control over that because it is next to impossible traveling across the globe and manually installing servers.

The ability to have servers running in different parts of the world closer to your customers is a huge advantage in this industry. AWS has the most data servers in most geographical areas. That means the latency problem could be easily be solved with AWS.

AWS has many regions throughout the world. Usually having a server instance available in the same country or continent as the user is a sufficient reduction to latency.

Within each region, AWS also has availability zones. An availability zone is a collection of data centers that have completely separate power, networking, and connectivity but are connected via hyper-fast fiber optics. This allows an availability zone to be extremely fault-tolerant. So If any of the data centers fails, the others provide a redundant failover. By scaling your application across several availability zones and/or regions, you can achieve nearly unlimited uptime for your application.

Now as could achieve unlimited uptime for your application, imagine how much dependent your livelihood would be upon, it can be a little scary.

Not to worry friends as AWS hosts a page showing both current service statuses across regions, as well as status history at https://status.aws.amazon.com.

How does AWS works?

AWS offers a range of services and these services interact with each other in order to run an application.

Nearly all services interact with each other over typical TCP connections.

I'm listing a few of the top services offered by AWS. Out of the below-listed services, few of them I'll be discussing in brief in our upcoming sessions:

a) Amazon S3: Amazon Simple Storage Service allows us to store and retrieve data from the cloud. S3 allows the user to store, upload, retrieve large files up to 5 TB from the cloud.

b) Amazon EC2: Elastic Compute Cloud provides scalable computing capacity in the AWS cloud.

c) Lambda: allows the user to run code without any server.

d) Amazon Glacier: The Glacier is an online web storage service that provides you with low cost and effective storage with security features for archival and data backup.

I'm naming others Amazon ElastiCache, Amazon RDS, Amazon Elastic Beanstalk, DynamoDB, etc.

Each service can be configured in different ways as per the users' needs. for example, different types of databases running for different APIs would be configured on different ports and not a single protocol that all services use. Usually, you are initiating these connections in your application by making requests to the AWS services.

If you create all of your service instances in the same virtual private cloud, then they will have local IP addresses, and you can make super-fast connections to them.

So when you begin with the development of an application using AWS, all the services interact mostly the same on your local development machine as they do in the cloud, you can add and build on services as you like. For example, if you're developing a static website, the basic thing you would try to achieve would be to connect to a database service in AWS. You could begin using S3 (will be explained in brief in later sessions) for static file storage.

You can work with these services exactly the same on your development environment as you would in the cloud, making the development to deployment experience as painless as possible.

Once you're done with deployment of your application, what about its security. Your work is very well vulnerable to cyber attacks. And you can't do much until it is on your local machine while developing but amazon gives you plenty of options to secure it in the cloud.

Connections and permissions between each service are managed via security groups, which are essentially light firewalls around each service instance.

Controlling access and security is done with pure configuration completed with the web console, and is mostly straightforward. You even have a chance to misconfigure security groups making them buggy.

There's a lot more to discuss about the individual services and modules in our upcoming sessions, but this should serve as a basic explanation for how things are working in AWS.

Keep reading & stay tuned for more.