DEV Community: Maajidh Sabeel A

Kubernetes 1.35 “Timbernetes” — What’s New & Why It Matters (December 2025)

Maajidh Sabeel A — Sun, 28 Dec 2025 07:04:12 +0000

💡 Introduction
The Kubernetes project, stewarded by the Cloud Native Computing Foundation (CNCF), has just released Kubernetes 1.35, codenamed “Timbernetes: The World Tree Release.” This is one of the most exciting releases of the year with 60 enhancements spanning Stable (production-ready), Beta, and Alpha features. Kubernetes

In this post, we’ll break down the most important, real-world features in a way that both beginners and experienced practitioners can understand.

🌟 What Kubernetes 1.35 Brings
This release includes several innovations that improve productivity, performance, and developer experience in Kubernetes clusters.

✅ 1. In-Place Pod Resource Updates (Stable)
Previously, if you wanted to change the CPU or memory of a running Pod, you had to delete it and recreate it — often causing downtime.

In Kubernetes 1.35, you can now resize Pod resources without restarting them.

This is a big deal because:

✔ Workloads (e.g., stateful apps, databases, batch jobs) can scale vertically without restarts.
✔ No more manual re-creations or temporary outages during updates.
✔ This reduces maintenance windows and improves reliability.

This change graduated to General Availability (GA) in this release — meaning it’s ready for production use.

🔐 2. Native Pod Certificates (Beta)
Managing certificates for workload identity — especially for secure mTLS communication — used to require external tools like cert-manager. Kubernetes 1.35 introduces native Pod certificates support:

✔ Certificates are automatically generated and rotated.
✔ Works without sidecars or manual secret creation.
✔ Simplifies zero-trust security and service mesh integrations.

This enhancement reduces operational overhead and strengthens security by default.

🧠 3. Smarter Scheduling with Node Declared Features (Alpha)
When you upgrade your Kubernetes cluster, sometimes the control plane gets new features before the worker nodes do.
This can cause a Pod to be scheduled on a node that doesn’t actually support what it needs.

In v1.35, nodes can announce what features they support using a new status field — and the scheduler uses that information to make better decisions.

This is currently in Alpha, meaning it’s experimental but hints at a more reliable scheduling future.

📍 4. Improved Traffic Routing (Stable)
Kubernetes has improved how Service traffic can be routed:

✔ A new option, PreferSameNode, prioritizes routing traffic to Pods on the same node (low latency).
✔ The previous PreferClose option is now renamed PreferSameZone for clarity.

🔄 5. New Beta & Alpha Features Worth Knowing
Beta Features (ready for testing):
Expose node topology via Downward API — Pods can see zone/region info without extra permissions.
Native storage version migration — simplifies CRD evolution.
Support for user namespaces in Pods — stronger isolation and security.
Configurable credential plugin settings in kubectl.
Alpha Features (future innovations):
Gang scheduling — schedule related Pods together for batch/AI workloads.
Watch-based route reconciliation — event-driven updates to cloud provider routes.
Extended toleration operators — smarter node matching based on policies.
These features show Kubernetes is expanding beyond simple orchestration into advanced use cases.

⚠️ Deprecations & Removals
Some legacy features are being phased out to make the platform cleaner and more secure. Always check the official release notes before upgrading your cluster.

🧠 Why This Matters in Real Life

Here’s how these changes help:
✨ Developers & DevOps:
Fewer pod restarts = less downtime
Better scaling workflows
Stronger workload security with less manual management
📊 Platform Teams:
More observability into cluster scheduling
Easier upgrade paths
Cleaner, future-proof API usage
🚀 Cloud Native Projects:
Easier adoption of service meshes and zero-trust
Better performance and latency control

📌 Conclusion
Kubernetes 1.35 “Timbernetes” is one of the most impactful releases in 2025 — combining stability, usability, and forward-looking features.

Whether you’re running production clusters or learning Kubernetes fundamentals, this release brings tangible improvements you can use today.

👉 Start testing these features in your staging clusters and explore their impact on your applications!

💸 AWS Bill Shock: Why It Happens and How to Prevent It

Maajidh Sabeel A — Tue, 19 Aug 2025 15:39:24 +0000

If you’ve ever opened your AWS bill and felt your heart skip a beat, you’re not alone.
“Bill Shock” is one of the most common surprises in cloud computing — and it’s not because AWS is trying to trick you. It usually happens because of how on-demand resources, scaling, and misconfigurations work in the cloud.

In this post, let’s break down:

Why AWS bill shock happens
Real-world scenarios where costs explode
AWS-native tools to prevent it
Practical tips I’ve learned as a Cloud/DevOps engineer

⚠️ Why AWS Bill Shock Happens

Unlike traditional data centers, AWS runs on pay-as-you-go pricing. That’s amazing for flexibility, but it also means:

Forgetting to stop resources

A test EC2 instance running 24/7
A GPU instance (like p3.2xlarge) left idle
RDS databases not stopped after testing

Data transfer costs

Free inbound, but outbound traffic costs money.
Example: Moving TBs of data out of AWS or across regions.

Auto-scaling surprises

Auto Scaling Groups or Kubernetes clusters that spin up more nodes than expected.

*Third-party services
*

Marketplace AMIs or services that look free but actually have hourly charges.

Storage creep

Old EBS volumes, snapshots, or S3 buckets you forgot about.

📖 Real-World Scenarios

Here are real situations I’ve seen in AWS projects:

Idle Development Cluster: A team spun up an EKS cluster for testing and forgot to shut it down. Two weeks later, the bill crossed $3,000.
Data Transfer Surprise: A company migrated logs to S3 but also pulled them daily into another region. The cross-region data transfer bill was higher than the EC2 costs.
Unused Snapshots: Multiple EBS snapshots were left running for years, quietly adding hundreds of dollars to the monthly bill.

🛠️ AWS Tools to Prevent Bill Shock

Thankfully, AWS gives us several tools to keep costs under control:

*AWS Cost Explorer
*

Visualize spending trends.
Identify which service or region is driving costs.

AWS Budgets

Set custom cost thresholds.
Get email/SNS alerts when you cross them.

AWS Cost Anomaly Detection

Uses ML to spot unusual spending patterns.
Example: If Lambda costs suddenly spike, you’ll get notified.

*Trusted Advisor
*

Gives cost optimization recommendations.
Flags underutilized resources like idle EC2 instances.

AWS Free Tier Alerts

Helps beginners avoid accidentally going over the free tier limits.

✅ My Practical Tips (From Experience)

Always tag resources (Environment=Dev/Test/Prod).
→ Makes it easy to track and clean up unused resources.
Use termination protection for important instances, but also set auto-stop schedules for dev/test EC2s.
Enable Budgets + Anomaly Detection on Day 1 — don’t wait for the first big bill.
Regular cleanup days: Once a month, review old S3 buckets, EBS volumes, and snapshots.
Monitor data transfer — it’s the silent cost killer in many architectures.

🚀 Closing Thoughts

AWS gives us amazing flexibility, but that flexibility comes with responsibility.
Bill shock isn’t an AWS problem — it’s a cloud operations challenge. By using the right mix of AWS tools and good practices, you can prevent nasty surprises and build cloud architectures that are both scalable and cost-efficient.

👉 Next time you launch a resource in AWS, remember: “It’s easy to spin up, but costs spin up even faster if you’re not careful.”

📌Originally published on Medium.

Why AWS AI Services Matter to Cloud Engineers Today

Maajidh Sabeel A — Sun, 27 Jul 2025 16:20:20 +0000

Not too long ago, my daily focus as a Cloud Engineer was all about provisioning infrastructure, optimizing deployments, setting up monitoring, and ensuring everything ran like clockwork.

But something has shifted.

The conversations around me—at work, online, and in the cloud community—started revolving around something bigger: AI.

Everyone’s talking about it.
Companies are asking, “How do we make our systems smarter?”
Engineers are wondering, “Where do I even start?”

And that got me thinking.

☁️ From Infrastructure to Intelligence
We’re already comfortable with building and scaling infrastructure. But what if we could also give it the ability to see, hear, understand, and even predict?

That’s exactly what AWS AI services are making possible—without needing a PhD in machine learning.

Here are a few that caught my attention:

🔍 Amazon Rekognition – Analyze images and videos to detect faces, objects, unsafe content, and more.

🧠 Amazon Comprehend – Understand natural language, extract key phrases, and even detect sentiment.

🗣️ Amazon Polly – Turn text into lifelike speech (yes, you can give your app a voice).

📜 Amazon Transcribe – Convert speech into accurate, readable text (useful for transcripts, call analytics, and more).

🚀 Amazon SageMaker – For when you're ready to build, train, and deploy your own machine learning models at scale.

These aren’t just “cool demos”—they're production-ready, fully managed services that cloud engineers like us can plug directly into our existing workflows.

🔧 Why Should a Cloud Engineer Care?

Here’s what I’ve realized:

Smart automation is becoming just as important as scalable architecture

Monitoring, alerts, chatbots, ticket routing—all have room for intelligent workflows

Many companies now expect infrastructure to be AI-ready by design

Whether you're deploying web apps or managing enterprise workloads, being AI-aware gives us an edge.

We’re already good at solving problems with code. Now we can solve bigger problems with smarter tools.

🛠️ How I’m Getting Started

My goal isn’t to become a data scientist overnight.

Instead, I’m learning by doing:

🧪 Running small experiments with Amazon Comprehend to analyze text logs

🎞️ Trying out Rekognition to auto-label images stored in S3

🎤 Using Polly to give voice to a web app I deployed

🧱 Looking into how SageMaker can fit into my DevOps CI/CD pipelines

I’m keeping it lightweight, practical, and fun. No deep math—just curiosity, use cases, and cloud tools.

And as I learn, I’ll share.

💬 Final Thoughts

AI isn’t coming—it’s already here. And the best part? AWS has made it approachable for cloud engineers like us.

You don’t have to be a machine learning expert. You just need a builder’s mindset—and you already have that.

So here’s to the next step in our cloud journey: building smarter, not just faster.

Let’s explore it together.

🤝 Let’s Connect

If you’re also exploring AWS AI or have ideas on how to apply it in real-world projects, I’d love to hear from you.

📩 Drop your thoughts in the comments
🔗 Connect with me on LinkedIn
✍️ Follow me on Medium for more real-world AWS + DevOps stories

Originally published on Medium: Why AWS AI Services Matter to Cloud Engineers Today

🧠 What I Wish I Knew Before Working with AWS From a Cloud Engineer's Desk

Maajidh Sabeel A — Sat, 26 Jul 2025 15:51:40 +0000

When I started working with AWS, I thought I just needed to learn EC2, S3, and maybe Lambda. But here's the truth: AWS is not just a cloud platform - it's a mindset shift.

Looking back, there are things I really wish I had known earlier - not just technical concepts, but how to approach AWS smartly, avoid burnout, and think like an engineer.

Here are the top things I learned the hard way - so you don't have to.

☁️ 1. AWS Isn't Hard - It's Huge
AWS has 200+ services. You're not supposed to master all of them.

🔍 What I do now:
I focus on the core services that matter for my projects. For me, that includes EC2, IAM, VPC, S3, Lambda, CloudWatch, and Terraform. Everything else is optional until needed.

👉 Tip: Start with projects, not certifications. Real-world scenarios teach better than multiple-choice questions.

🔒 2. IAM is the Heart of Everything
You can't do anything in AWS without Identity and Access Management (IAM). I ignored it at first - then spent hours debugging permissions and policy issues.

🔍 What I do now:
I treat IAM as part of security and DevOps, not just configuration. I version control IAM policies and follow the principle of least privilege.

👉 Tip: Learn how IAM roles, policies, and trust relationships work. This knowledge will save you countless hours.

🔁 3. Repetition Builds Intuition

You don't become good at AWS by watching tutorials - you get there by:

Launching EC2s (and breaking them)
Writing broken CloudFormation or Terraform scripts
Debugging VPC misconfigurations

🔍 What I do now:

I build labs, write Infrastructure as Code, and break things intentionally - because fixing them is where the learning happens.

👉 Tip: Deploy a static website using S3 + CloudFront + Route 53 + ACM. It's a great exercise to understand how AWS services work together.

⚙️ 4. DevOps and AWS Go Hand in Hand

You don't "do DevOps" after AWS - you do DevOps with AWS.
Whether it's CI/CD, monitoring, auto-healing infrastructure, or IaC - AWS offers services designed for a DevOps mindset.

🔍 What I do now:
I use Terraform, CodePipeline, CloudWatch, and Lambda to automate and optimize cloud operations. DevOps isn't just tools - it's how you think and build.

👉 Tip: Think in pipelines and systems, not manual steps.

🌍 5. Multi-Cloud is Real - But AWS is Still King

Yes, I explore Azure and GCP. But for now, AWS still leads, especially in infrastructure flexibility, community support, and breadth of services.

🔍 What I do now:
I stay strong in AWS, but experiment across other clouds to keep my perspective sharp.

👉 Tip: Be cloud-agnostic in design - but deep in one provider.

🎯 Final Thoughts: Cloud is a Career, Not a Checklist

AWS has taught me more than just tech - it's taught me how to learn better, build smarter, and think long-term.

If you're just starting out, don't be overwhelmed. Pick one project, go deep, and share what you learn.

That's why I'm writing this - and why I'll continue sharing my journey.

📌 Originally published on Medium: From a Cloud Engineer’s Desk

***👋 Let's Stay Connected
*💬 Curious about AWS, DevOps, or cloud careers?
📬 Reach out - I'm always open to connect!
🔗 Follow me on Medium | Connect on LinkedIn
Let's build, learn, and grow together - one cloud story at a time. �
**