DEV Community: Saloni Singh

Docker — Advanced Interview Questions

Saloni Singh — Sun, 17 Nov 2024 15:25:43 +0000

In today’s time, to get into DevOps roles is a bit challenging, and Docker plays an important role here. So, today I have brought up some interesting advanced interview questions that you might encounter in future related to Docker.

1. How does Docker ensure images are immutable?
Docker images are layer composites; each layer is read-only and immutable, while all modifications within a container end up in a new, writeable layer, without changing the image.

2. What is the difference between Docker’s bridge network and host network?
Bridge Networking Containers all communicate over private network bridges. Use: For those containers that have different networking needs. Host Networking Containers share a host’s network stack.
Use: Low-latency networking (e.g., in high-performance apps).

3. What happens to the data in a container when the container is deleted?
Unless a volume or bind mount is used, container data are stored in a writable layer, which is deleted when the container is removed.

4. What are Docker namespaces, and how do they work?
Namespaces provide isolation in Docker by separating resources for each container:
PID namespace: Process isolation.
NET namespace: Network isolation.
MNT namespace: Filesystem isolation.
UTS namespace: Hostname isolation.

5. How do you debug a Docker container which is hogging too much CPU or Memory?
Use docker stats to monitor resource usage.
Limit resources:

docker run - memory="500m" - cpus="1.5" <image>
Check the app inside the container using tools like top or htop.

6. What are ways to shrink Docker images?
Use smaller base images (e.g., Alpine).
Avoid installing unnecessary packages.
Use multi-stage builds to exclude build dependencies.
Cleanup temporary files in Dockerfile.
Dockerfile:

RUN apt-get update && apt-get install -y package && rm -rf /var/lib/apt/lists/*

How to automatically make Docker containers restart? Use the — restart flag during container creation no : Off, won’t restart. always : Docker will restart the container, unless manually stopped. on-failure : Docker will restart the container only if the exit code is not zero.

docker run - restart=always <image>

8. What is a dangling image? and how to remove it?
An dangling image is an image that does not have any tag.
Clean up using

docker image prune

9. What are Docker tags and when are they useful?
Tags refer to versions of an image.

For example python:3.9 vs python:latest
They offer versioning and ensures the same thing runs every time.

10. What is Docker Content Trust (DCT), and how does it secure images?
DCT ensures that only signed images are pulled or run.

Enable with

export DOCKER_CONTENT_TRUST=1
This verifies the integrity and publisher of images.

These questions range from a series of practical and theoretical Docker concepts in order to assess their depth of understanding and problem-solving capacities of the candidate.

Transitioning your Career to AWS and DevOps

Saloni Singh — Mon, 11 Nov 2024 03:39:43 +0000

Nowadays, all of us are looking to transition our career in a more better way, probably Cloud or DevOps, as the demand is increasing in the market for these roles.

So, this post is all about some steps that I would recommend you to follow, I’m sharing my personal experience and the steps I followed, it may differ from person to person, so please do the same according to your pace and interest.

Try to focus step by step on the services, don’t try to rush
First, if possible, cover AWS (or any other cloud of your choice) completely, only then move to DevOps
If you choose to go for AWS Developer roles, make sure you are really good with programming, and if you are going for Devops role, minimal programming is desired, but it is necessity, as there are many organisations, that expect you to code in interviews.
Programming language can be any of your choice, preferably Python or Golang if you think of moving towards DevOps.
Make sure, the services that you mention before the interviewer, you are really really good at them, please avoid bluffing about the services that you have very basic knowledge on, and if asked then you would be blank, as that creates an impression of not having enough knowledge.
Try connecting with DevOps people and asked about their real projects, how they work and what all they cover.
Avoid mentioning some common projects, like I have noticed in the interviews that I take, the candidate says, I have worked on an e-commerce website, or a retailing platform which is three tier application, I have created VPC, I created EC2, please note that real world projects aren’t this way. Try to state that we have managed the infra using IaC.
Focus on IaC tools, preferably Terraform would be great.
Be well prepared for the project you will be explaining, as that will be the one which interviewers would focus more on, so in and out you need to know everything about your project.
Mention working on tools like JIRA, ServiceNow, or any ticketing tools, preferably JIRA would be good one, and tell that you have also worked on stories and epics, this frames an impression of real hands-on.
Be consistent regarding your hands-on practice, avoid mugging up internet questions and answers, as nowadays the interviewer asks questions related to your project and some scenario based ones, so your practice is the key to your success.
Regarding DevOps, try to avoid covering each and every tool, if you just focus on Git, Docker and Kubernetes it’s more than enough.
At least one monitoring tool should be known, Datadog, Prometheus, Grafana or ELK, select any of your choice.
Watch Udemy lectures if possible, for AWS watch Stephane Maarek’s course on Solutions Architect Associate.
Regarding certifications, having one is good, but not necessary, at the end all that matters is your knowledge.
For better insights on AWS and Kubernetes, I would recommend watching Cloud With Raj on Youtube, Raj is a Principle Solution Architect at AWS, the way he presents the things before you are good, also watch some of the system design cases as they are also the one’s that need focus.

For more help connect with me on LinkedIn: https://www.linkedin.com/in/saloni-singh-aws/

AWS Valkey: Now available on Amazon ElastiCache and MemoryDB!

Saloni Singh — Mon, 04 Nov 2024 07:00:41 +0000

Introduction:
AWS has just added a new, high-power tool to the cloud for architects and developers who strive to make the most out of their performance and save costs: Valkey. This is an open-source, high-performance key-value store available on Amazon ElastiCache and MemoryDB, promising reliable and low-cost data management for ultra-fast data access by demanding applications. In this article, we will break down what are the key benefits from Valkey, give practical examples, and go further into why this new alternative is best suited for a lot of use cases.

Why Valkey?
Administered by the Linux Foundation, Valkey reaps all the benefits offered by Redis OSS with utmost concern for cost efficiency as well as performance. Key datastore built as vendor neutral, Valkey is coming in as a game-changer in applications that require application speed and low latency at any affordable price point.

KEY HIGHLIGHTS:
Cost-Effectiveness: Amazon ElastiCache with Valkey gives 33% lower serverless options and 20% in node-based pricing compared with Redis OSS.
High-Performance: The design at Valkey will allow speedy access to data, offering millisecond latency. Valkey is thus the ultimate solution for real-time apps.
Flexibility: Simple migration from Redis OSS using minimal code changes; then you can benefit from Amazon’s strong, managed platform.

Where Valkey Surpasses: Real-World Use Cases
For displaying Valkey’s strengths, let’s talk about a few typical use cases:

1. Web application caching
An e-commerce site with tens of thousands of concurrent users is easy to imagine. Caching here is key for allowing smooth, high-speed usage, especially in the load spikes. The ElastiCache for Valkey should dramatically reduce database load since you can store session user data and high-access products which would allow them to surf seamlessly and faster check-out.

2. Gaming leaderboard
Real-time, in-game leaderboards? Ideal. Sub-millisecond reads and consistent write performance make sure that players see up-to-the-minute rankings without delay — even in high-traffic scenarios. And at 30% cheaper than MemoryDB for Redis OSS, you can have the performance with control of the budget.

3. Analytics for Real-Time Data
Valkey is a good fit for applications that process large volumes of real-time data such as monitoring and analytics applications. For instance, an analytics dashboard in a logistics application can use Valkey to manage and serve near real-time data on each vehicle’s location and status for immediate insights from clients.

Getting Started with Valkey on AWS
AWS easily transitions to Valkey fully managed. One may deploy Valkey now to the ElastiCache or MemoryDB by entering either into the AWS Console. On either, clicking will locate Valkey among its offered data stores and present for selection.
With No Downtime: the preceding configurations and all previously learned access patterns continue with zero loss. That’s through AWS’s making possible of easy switching into Valkey without any losing any preceding configurations or already developed patterns of access established in those preceding configurations.
Cost Management: Since Valkey is discounted versus Redis OSS, keep track of the cost savings with AWS Cost Explorer so you see the cost cuts.

Redis OSS vs. Valkey
For those who already work with Redis OSS, a low-cost, equal-performing alternative now comes up through Valkey:

Lower Entry Price: **The pricing for ElastiCache for Valkey begins at $6 a month. There are also additional supported discounts for reserved nodes, for existing nodes.
**High Availability: Users can enjoy 99.99% availability and data replication and backup automatically by using AWS-managed reliability.

Conclusion
Start Leveraging Valkey Today
The release of Valkey on ElastiCache and MemoryDB has given the developers access to a high-performance, cost-effective key-value store backed by AWS’s reliability. It can either optimize for cost, performance, or be used for applications with demanding real-time requirements.

Start discovering Valkey on ElastiCache and MemoryDB today to realize the potential of the power of a cost-effective, high-performance key-value store that scales with you.

Latest Interview QnA faced recently as a DevOps Engineer

Saloni Singh — Thu, 31 Oct 2024 18:29:55 +0000

Hello Connections,

I usually try attending interviews to bring latest questions for you, I recently attended an interview and here are some questions which I encountered:

𝗕𝗿𝗮𝗻𝗰𝗵𝗶𝗻𝗴 𝗦𝘁𝗿𝗮𝘁𝗲𝗴𝘆:
Ques.: If we have some application being developed from scratch, what branching strategies would you suggest? What will be the questions you would ask?
Ans: For a greenfield application, it is generally recommended to use a trunk-based branching strategy where there is one central branch that contains the production-ready code. Developers are creating short-lived feature branches for new features or bug fixes and then merge these back into the main branch when completed. As the project grows, a GitFlow or GitHub Flow might be useful for managing features, releases, and hotfixes.

Questions to Ask:
Deployment Frequency: How often will the application be deployed?
Team Size and Coordination: How many developers are working on the application? What communication style does people use?
Release Management: Are there specific release cycles or timelines to be considered?
CI/CD Pipeline: Will you do automated testing with CI/CD pipelines for merging and deployment of code?

𝗧𝗲𝗿𝗿𝗮𝗳𝗼𝗿𝗺:

Ques: Let’s say I have two resource blocks, and each has a Bool value, one of it has True and another has False, I want to execute every block according to the value set, like if True, then first block, if False then second, how would that be possible?
Ans: Conditional Execution of Resource Blocks Based on Bool Values: To conditionally execute a block based upon a boolean you can use count with conditions:

resource "aws_resource" "example" { count = var.bool_value ? 1 : 0 # Resource configuration here }
Only the resource with count = 1 will be executed based on the value of the condition.

2. Difference between for_each and count?

Ans: Below are the differences:
count: Multi-instance of a resource, based on an integer. Simple replication-friendly.
for_each: Iterate over a set like a map or list, creating unique resources per item. The for_each variable determines that the Resource has an unique identifier which is different for every item in it.

3. If I have two resource blocks, first block has 2 load balancers and second has 2 target groups, I wish to have my first load balancer get attached to first target group, and second load balancer with second target group, how would I do that dynamically, without hard coding anything?

Ans: This will be achieved by using for_each to iterate over each load balancer and mapping them to target groups, for example:

`variable "load_balancers" {
type = list(string)
default = ["lb1", "lb2"]
}

resource "aws_lb" "lb" {
for_each = toset(var.load_balancers)
# Load balancer configuration
}

resource "aws_lb_target_group" "tg" {
for_each = toset(var.load_balancers)
# Target group configuration
}

resource "aws_lb_target_group_attachment" "attachment" {
for_each = aws_lb.lb
target_group_arn = aws_lb_target_group.tg[each.key].arn
# Attach load balancer to target group
}`
All load balancers will dynamically attach to a specific target group without being hardcoded.

𝗗𝗼𝗰𝗸𝗲𝗿:

Have you ever worked with multiple images in file? If yes, tell me why do we use multiple images?
Ans: Multiple images or Multi stage builds, let you have different images for different stages of the process, just by copying only the necessary components into the final image, you can optimize its size. A common use case is to separate the build and the runtime environments. You might want a Go build stage and copy only the executable into a really small runtime image.

2. If we use command docker build -t . for building our Docker file, which has a default name of Dockerfile, what will be the command used to build a file with some other name, what will be the flag that will be used?

Ans: To create a Docker file with a custom name, you can use the -f flag:

docker build -f CustomDockerfile -t myimage .
This tells Docker to use CustomDockerfile instead of the default Dockerfile.

𝗞𝘂𝗯𝗲𝗿𝗻𝗲𝘁𝗲𝘀:

If I have multiple worker nodes, and a master node, and I need to create a pod in every node for collecting logs, as I need logs of all these nodes, how will you make sure that the pods even if they go down or crash, they would quickly up and running, but make sure within the same node?
Ans: High Availability: Ensure Pods Run on Every Node A DaemonSet is used to ensure a copy of the pod runs on each node in the cluster and, if the pod crashes or a new node is brought up, Kubernetes can automatically recreate the pod on that node.

apiVersion: apps/v1 kind: DaemonSet metadata: name: log-collector spec: selector: matchLabels: app: log-collector template: metadata: labels: app: log-collector spec: containers: - name: log-collector image: your-log-collector-image # Container configuration
Your logging pods will run on every node even if they fail or are newly added with DaemonSet.

You can follow me over LinkedIn: https://www.linkedin.com/in/saloni-singh-aws/

Transit Gateway v/s Direct Connect v/s Site-to-Site VPN

Saloni Singh — Sun, 27 Oct 2024 16:17:01 +0000

Let’s discuss about VPC today, we all must have heard of Transit gateway, Direct Connect and Site-to-Site VPN, all of these seem to sound similar, but what’s the difference between them?

A 𝗧𝗿𝗮𝗻𝘀𝗶𝘁 𝗚𝗮𝘁𝗲𝘄𝗮𝘆 is a central hub by which you can connect VPCs and on-premises networks within the AWS environment.
𝗗𝗶𝗿𝗲𝗰𝘁 𝗖𝗼𝗻𝗻𝗲𝗰𝘁 does this by creating a direct, dedicated private connection with your on-premises network and AWS.
Creating a 𝗦𝗶𝘁𝗲-𝘁𝗼-𝗦𝗶𝘁𝗲 𝗩𝗣𝗡 creates an encrypted over-the-public-internet “tunnel” to associate your on-premises network with a single AWS VPC.
So, in fact, a Transit Gateway provides for managing multiple VPCs and on-premises networks connections, with Direct Connect offering a direct, high-bandwidth connection, and a Site-to-Site VPN is a fundamental connection using the public Internet for a single VPC link.

𝗞𝗲𝘆 𝗱𝗶𝗳𝗳𝗲𝗿𝗲𝗻𝗰𝗲𝘀:

𝗙𝘂𝗻𝗰𝘁𝗶𝗼𝗻𝗮𝗹𝗶𝘁𝘆:
𝗧𝗿𝗮𝗻𝘀𝗶𝘁 𝗚𝗮𝘁𝗲𝘄𝗮𝘆 : It is central to make the different VPCs and on-premises network connect to each other; it simplifies network management.
𝗗𝗶𝗿𝗲𝗰𝘁 𝗖𝗼𝗻𝗻𝗲𝗰𝘁 : Dedicated and private connection that connects your on-premises network to AWS with high bandwidth with minimal latency.
𝗦𝗶𝘁𝗲-𝘁𝗼-𝗦𝗶𝘁𝗲 𝗩𝗣𝗡 : An encrypted tunnel across the public internet which interconnects your on-premises network to an AWS VPC.

𝗦𝗰𝗮𝗹𝗮𝗯𝗶𝗹𝗶𝘁𝘆
𝗧𝗿𝗮𝗻𝘀𝗶𝘁 𝗚𝗮𝘁𝗲𝘄𝗮𝘆: It is highly scalable, thus allowing easy addition of new VPCs or on-premises network connections.
𝗗𝗶𝗿𝗲𝗰𝘁 𝗖𝗼𝗻𝗻𝗲𝗰𝘁: Highly scalable depending on the chosen bandwidth tier.
𝗦𝗶𝘁𝗲-𝘁𝗼-𝗦𝗶𝘁𝗲 𝗩𝗣𝗡: Not as scalable as Direct Connect because it is restrained by public internet bandwidth.

𝗦𝗲𝗰𝘂𝗿𝗶𝘁𝘆:
𝗧𝗿𝗮𝗻𝘀𝗶𝘁 𝗚𝗮𝘁𝗲𝘄𝗮𝘆: It is secure in the AWS infrastructure, but on the on-premises connection, there would rely on extra security measures.
𝗗𝗶𝗿𝗲𝗰𝘁 𝗖𝗼𝗻𝗻𝗲𝗰𝘁: Very secure since it is based on a dedicated private connection.
𝗦𝗶𝘁𝗲-𝘁𝗼-𝗦𝗶𝘁𝗲 𝗩𝗣𝗡: Relies on encryption to protect traffic across the internet.

𝗪𝗵𝗲𝗻 𝘁𝗼 𝘂𝘀𝗲 𝗲𝗮𝗰𝗵:
𝗧𝗿𝗮𝗻𝘀𝗶𝘁 𝗚𝗮𝘁𝗲𝘄𝗮𝘆:
You want to connect multiple VPCs and on-premises networks with complex routing requirements.
𝗗𝗶𝗿𝗲𝗰𝘁 𝗖𝗼𝗻𝗻𝗲𝗰𝘁:
You want a high-bandwidth, dedicated private connection to AWS for large data transfers.
𝗦𝗶𝘁𝗲-𝘁𝗼-𝗦𝗶𝘁𝗲 𝗩𝗣𝗡:
You want a simple way to connect a single on-premises network to an AWS VPC with smaller data volumes.

Real World Scenario Based Interview Q/A on AWS Availability Zones and Regions

Saloni Singh — Sat, 26 Oct 2024 17:22:15 +0000

We are all well-aware fo 𝗔𝗪𝗦 𝗔𝘃𝗮𝗶𝗹𝗮𝗯𝗶𝗹𝗶𝘁𝘆 𝘇𝗼𝗻𝗲𝘀 𝗮𝗻𝗱 𝗥𝗲𝗴𝗶𝗼𝗻𝘀, here are a few 𝘀𝗰𝗲𝗻𝗮𝗿𝗶𝗼 𝗯𝗮𝘀𝗲𝗱 𝗶𝗻𝘁𝗲𝗿𝘃𝗶𝗲𝘄 𝗾𝘂𝗲𝘀𝘁𝗶𝗼𝗻𝘀 for you. You will get tons of posts stating real-world interview questions, but most of them I found are very basic, here I will present some interesting questions, which help you cover the topics well.

Q: You have deployed your application within a single Availability Zone, and you now want to make the same highly available. What would you do?
A. I would increase the availability of the applications by at least another availability zone, with at least another instance of the same application in the same region. Subsequently, I would configure an Elastic Load Balancer that will distribute incoming traffic across these instances across the AZs. Finally, Auto Scaling should be configured to further enhance the increase in availability under increased loads or instance failure.

Q: One of the services in one Availability Zone has failed. How do you ensure that your application hasn't stopped working and no manual intervention is required?
A: I'll ensure that my application is spread across various AZs and ELB would redirect traffic to the healthy instances. In addition to that, I will have Auto Scaling configured so that new instances would be automatically launched in another AZ in case one zone fails.

Q: You have an RDS instance running in one AZ. How do you make it highly available and minimize downtime?
A: To make the RDS instance highly available and minimizing downtime, I'd make changes to the RDS instance to enable Multi-AZ deployment. This will create a standby replica of the instance in another AZ. In case the primary instance fails, RDS will failover automatically on the standby instance, hence preventing downtime.

Q: Ensure that your data is always accessible, even if a complete AWS region is unavailable. How do you approach this solution?
A: For multi-region architecture, I would always replicate data and applications across multiple regions. For S3, I can enable cross region replication. For databases, I can use either Amazon Aurora Global Databases or cross region replication in RDS. Aside from that, I would use Route 53 for DNS failover to redirect traffic to a healthy region in case of an outage in one region.

Q: You have an application with very high read traffic. How can you take advantage of Availability Zones to improve performance?
A: I would deploy the read replicas in different AZs to distribute the read traffic. This approach would improve latency and performance because read traffic could now be load-balanced across multiple AZs. As for databases like RDS, I can have the read replicas in multiple AZs and configure my application for forwarding the read requests to those replicas.

Q: Your web application needs to provide low latency to users in different geographies. How would you address this?
A: I would distribute the application across multiple regions on AWS, along with using Amazon Route 53-enabled Latency-based routing capabilities. Route 53 would then route end users to the nearest region offering low latency to them, thus minimizing the response time. Finally, I would cache the content close to the users through globally using CloudFront.

Q: A natural disaster affects the data center that hosts your primary AZ. Which AWS service would ensure your EC2 instances were still reachable?
A: If using more than one AZ in EC2 instance launch, with an ELB, the ELB will automatically route traffic to instances in good AZs and the application will be kept alive. Auto Scaling can automatically launch new instances of an AS group where at least one has failed, in healthy AZs.

Q: You notice that more geographically dispersed users hitting your application provide higher latency levels. What changes would you implement to minimize latency levels?
A: I would use Amazon CloudFront to distribute content at edge locations around the globe. I would be caching static and dynamic content for the reason that it would take less latency to the distinct geographically-dispersed locations now, therefore improving response times.

Q: You want to protect your S3 data in case there is a failure of an Availability Zone. What can you do?
A: In general, S3 stores data redundantly across multiple AZs within a region. If I wanted that extra layer of protection I could enable cross-region replication, by replicating that data into a different region if ever there was a full failure at the regional level.

Q: Your company wants to move to a new AWS region in order to serve a different market. How would you do it with little downtime?
A: First, I will replicate the application in the new region, deploying resources needed there (EC2, RDS, etc.). Then I would make use of data replication services like DMS (Database Migration Service) or cross-region S3 replication. Finally, I will update Route 53 to route traffic to the new region to do a failover swap-over with no downtime.

For more such stuffs, follow my page.

Learning AWS Day by Day — Day 83 — Disaster Recovery — Part 3

Saloni Singh — Thu, 24 Oct 2024 13:27:58 +0000

Exploring AWS !!

Day 83:

Disaster Recovery — Part 3

If a particular region goes down, we have active/passive strategies in AWS implemented using Multi-region Disaster Recovery, where active is the actual active region which is up and running, and passive is the standby.
We also have active-active, where both regions are up and running, in case of failure the

Business Continuity plan:
Before going for any Disaster Recovery plans, you need to perform a Business Impact Analysis (BIA), what are the consequences for your organisation if this workload fails, you ned to identify how quickly you need to recover the data, how much data loss in time (not in GB or TB), how much data loss can be tolerated. You also need to do risk assessment, like what is the risk of a natural disaster and also geographical impact of these disasters. So, we need tot hink about this before planning the DR strategy and even before planning to build application.

Recovery Objectives:
How much data can you afford to recreate or lose? — Recovery Point Objective (RPO)
How quickly must you recover, and what is the cost of downtime ? — Recovery Time Objective (RTO)

RTO is maximum amount of acceptable delay between the interruption of service and restoration of service.
RPO is maximum amount of data that can be afforded to be lost or recreated.

Disaster Recovery is different in cloud:
DR strategies evolve with technology
— Single AWS Region
Risk of disruption or loss of one data centre
Implement High Availability workload
Do not forget backups
— Multiple AWS Regions
Risk of disruption or loss of multiple data centres
Implement cross region availability
Do not forget backups

Strategies for Disaster Recovery:
Backup & Restore
Pilot Light
Warm Standby
Multi-Site active/active

Learning AWS Day by Day — Day 82 — Disaster Recovery (DR) — Part 2

Saloni Singh — Tue, 22 Oct 2024 06:22:00 +0000

Exploring AWS!

Day 82

Disaster Recovery (DR) — Part 2

How to implement High Availability Vs How to implement Disaster Recovery:

The diagram shown (above) gives you very resilient High Availability architecture. S3 and Dynamodb or NoSQL database are not in AZ as these are designed in a way by AWS that they are automatically replicated across AZ. The data they store is replicated across multiple AZ, that gives you High Availability and high durability of that data already built in for you.

So, if there’s a flood one AZ goes down, still another AZ is up and running. These AZs are designed specifically so that they dont share fate, and other 2 AZs are fine. Other than this, what else can be done is use Backups.

If you have EBS attached and they are in zones, you should keep backups which give you disaster resiliency which is a disaster recovery strategy.
EBS -> Volumes -> Snapshots

Another example is human actions, like let’s say accidental deletion or data corruption or bad actor, in that case replication is not good, you will replicate corrupted data, so here we need point in time backups. You can see Dynamodb, so we can go back to last good state and restore the data. Similarly, S3 has it’s versioning concept.

DynamoDB -> Point in time deploy
S3 -> Versioning

Learning AWS Day by Day — Day 81 — Disaster Recovery — Part 1

Saloni Singh — Mon, 21 Oct 2024 11:00:11 +0000

Exploring AWS!

Day 81:

Disaster Recovery (DR) — Part 1

For any tools or services you use, we prefer having some backup always, or atleast something that can support you in the times when you really need something and the main primary part has failed. Lets say, your battery just drains out and there is no power, your power bank always saves you there, but imagined what if there was no power bank as well? And you had some important call to attend?
Do you remember the Flight 777, it gives us an idea why resiliency is important, that was the plane which caught fire and somehow managed to land with only one engine working, so they had to keep the high availability and proper maintenance for these jet engines which are a business contiguity.
Now you see, its important to have a disaster recovery, even if you have a backup

About Business Contiguity:
There are various types of disasters, some larger scaled, less frequent events like Natural disasters including floods or fire or tsunamis or might be earthquakes. Then we have technical disasters like human actions, maybe hacking or intentional deletions.
This contiguity term measures a one time event: Recovery Time, Recovery Point.
High Availability: About application availability, smaller scaled which have to face more frequent events like component failures, network issues, load spikes, etc.
The measures mean over time which are ‘The 9s’ (99.99% availability).
So, Disaster Recovery is recovering from a loss of service due to some event or disaster, whereas High Availability is all about preventing these.

What is a disaster?
We all know about AWS Regions and AZs, these regions are the physical locations around the world where we cluster data centres. 33 geographic regions around the world, with announced plans for 12 more AZs and 4 more regions in Germany, Malaysia, New Zealand and Thailand.
These AZs, they are placed at proper distance for better operation to avoid disasters, but close enough to allow synchronous replications. So you can say, maximum distance of 60 miles or 100 kms.
We need to think of types of disasters when planning these DR strategies and what can be the outcome and effect of such a disaster on your data.
Shared Responsibility model for Resiliency: AWS & Customer responsible.

Customer Responsibility for resiliency ‘IN’ the cloud:
Server data backup
Workload architecture
Change management
Failure management
Networking, Quotas and Constraints

**AWS Responsibilty for resiliency ‘OF’ the cloud:
**Hardware and services
Compute, Storage Database, Networking
AWS Global Infrastructure
Regions, AZs, Edge locations

Note: High Availability is not a DR.

Learning AWS Day by Day — Day 80 — Amazon Cloud Directory

Saloni Singh — Tue, 04 Jun 2024 17:11:44 +0000

Exploring AWS !!

Day 80

AWS Cloud Directory

A directory-based store in AWS, where directories can scale to millions of objects. No need of managing the directory infrastructure, just focus on your development and deployment of the application. There is no limit to organize the directory objects in fixed hierarchy.
We can use Cloud Directory to organize directory objects in multiple hierarchies supporting many organizational pivots and relationships across directory information. For example, a directory of users may provide a hierarchical view based on reporting structure, location, and project affiliation. Similarly, a directory of devices may have multiple hierarchical views based on its manufacturer, current owner, and physical location.

We can do following with Cloud Directory:
Create directory-based applications easily and without having to worry about deployment, global scale, availability, and performance
Build applications that provide user and group management, permissions or policy management, device registry, customer management, address books, and application or product catalogs
Define new directory objects or extend existing types to meet their application needs, reducing the code they need to write
Reduce the complexity of layering applications on top of Cloud Directory
Manage the evolution of schema information over time, ensuring future compatibility for consumers

Cloud Directory is not a directory service for IT Administrators who want to manage or migrate their directory infrastructure.

Learning AWS Day by Day — Day 79 — Amazon MQ

Saloni Singh — Thu, 30 May 2024 17:03:26 +0000

Exploring AWS !!

Day 79

Amazon MQ

Message broker service that makes it easier to migrate to a message broker. A message broker allows software applications and components to communicate using various programming languages, OS, and formal messaging protocols.
Amazon MQ supports Apache ActiveMQ Classic and RabbitMQ engine types.
Amazon MQ works with your applications and services without the need to manage, operate, or maintain your own messaging system.

Difference between Amazon MQ and SQS or SNS
MQ is a message broker service providing compatibility with many popular message brokers. Amazon MQ is recommended for migrating applications from message brokers relying on compatibility with APIs like JMS or protocols such as AMQP 0–9–1, AMQP 1.0, MQTT, OpenWire, and STOMP.
Amazon SQS and Amazon SNS are queue and topic services — highly scalable, simple to use, and message brokers set up is not required. These services are better option for new applications that can benefit from nearly unlimited scalability and simple APIs.

Learning AWS Day by Day — Day 78 — Amazon DocumentDB

Saloni Singh — Wed, 29 May 2024 17:12:19 +0000

Exploring AWS !!

Day 78

Amazon DocumentDB

Amazon DocumentDB (with MongoDB Capability) is fast, scalable, highly available database service supporting MongoDB workloads. It makes easy for us to store and index JSON data.
This is a non-relational database service designed from basic to give you better performance and scalability when operating critical MongoDB workloads at scale. In DocumentDB, storage and compute are decoupled, allowing to scale independently. The read capacity to millions of request per second can be increased by adding upto 15 low latency read replicas.
We can use same drivers, same code and same tool those you use with MongoDB.

When using DocumentDB, we start by creating clusters. A cluster contains instances and volumes to manage the storage for that instance.
The cluster consists of 2 components:
Cluster volumes: DocumentDB has one cluster storage volume, storing 128 TB of data.
Instances: It can contains 0–16 instances.

DocumentDB provides multiple connection options, and to connect with the instance we specify the instance’s endpoint. An endpoint is a host address and a port number, separated by a colon.