TechOps Examples
Hey — It's Govardhana MK 👋
Welcome to another technical edition.
Every Tuesday – You’ll receive a free edition with a byte-size use case, remote job opportunities, top news, tools, and articles.
Every Thursday and Saturday – You’ll receive a special edition with a deep dive use case, remote job opportunities, and articles.
You're spending 40 hours a week writing code that AI could do in 10.
While you're grinding through pull requests, 200k+ engineers at OpenAI, Google & Meta are using AI to ship faster. How?
The Code newsletter teaches them exactly which AI tools to use and how to use them. Here's what you get:
AI coding techniques used by top engineers at top companies in just 5 mins a day
Tools and workflows that cut your coding time in half
Tech insights that keep you 6 months ahead
👀 Remote Jobs
Canonical is hiring a Site Reliability Engineer
Remote Location: Worldwide
Particle41 is hiring a DevOps Engineer (AWS)
Remote Location: India
Powered by: Jobsurface.com
📚 Resources
Looking to promote your company, product, service, or event to 55,000+ Cloud Native Professionals? Let's work together. Advertise With Us
🧠 DEEP DIVE USE CASE
How to Design 3 Tier Architecture in AWS
Before talking about scalability, more often than not, I see too many cloud engineers, especially beginners, get confused between fault tolerance and high availability. Once for all…
Fault tolerance means the system continues to operate even when a part of it dies. For example, if one Availability Zone in AWS goes completely dark, a fault tolerant design will have another zone already running the same workload without any disruption.
High availability means the system remains accessible most of the time with very little downtime. For example, if an EC2 instance in a zone crashes, Auto Scaling launches a new one and the service is restored within minutes.
Load balancing ties both together by continuously distributing traffic across multiple servers and rerouting users away from unhealthy ones, keeping the service both available and fault resilient.
How Availability gets calculated in real ?
Total availability is calculated by multiplying the uptime of each tier in the system. This is where design choices directly change the final percentage, eventually hits your target SLA.
When a single tier is in use like one web server, one app server, and one database, the overall uptime quickly drops. Each server may run 99% on its own, but once you stack them together the effective uptime is much lower than expected.
When you add redundancy in the web tier with two servers behind a load balancer, that tier’s uptime improves dramatically. This raises the overall system uptime as well.
When you extend the same design to every tier with multiple web servers, multiple app servers, and a master–replica database, the compounded uptime gets close to the high availability targets most businesses set in their SLAs.
It is no wonder in all the three examples though the individual tier element availability numbers are the same, the total availability dramatically improves from 96.04% to 99.4%.
Take away:
Redundancy in a single tier lifts the entire system.
Overall uptime depends on how tiers are combined.
End-to-end redundancy across all tiers delivers near SLA grade uptime.
With this foundation knowledge, let us deep dive into practical AWS architecture and the nuances that make it work in the real world.
🔴 Get my DevOps & Kubernetes ebooks! (free for Premium Club and Personal Tier newsletter subscribers)
Upgrade to Paid to read the rest.
Become a paying subscriber to get access to this post and other subscriber-only content.
UpgradePaid subscriptions get you:
- Access to archive of 250+ use cases
- Deep Dive use case editions (Thursdays and Saturdays)
- Access to Private Discord Community
- Invitations to monthly Zoom calls for use case discussions and industry leaders meetups
- Quarterly 1:1 'Ask Me Anything' power session
