When Cursor and Copilot started showing up everywhere, I rolled my eyes hard. "Great, another tool that's going to write buggy code and make me clean up its mess," I thought.

I'd tried the early versions. They were... fine? They could write a basic function. But they also hallucinated APIs, suggested deprecated patterns, and generally made me spend more time debugging than if I'd just written the code myself.

But then something changed. And I don't just mean the models got better (though they definitely did). I mean I figured out how to actually use these tools in a way that didn't make me want to throw my laptop out the window.

Fast forward six months, and I've tracked my time religiously. The result? I'm saving 10+ hours every single week. Not by letting AI write all my code — that's a recipe for disaster — but by using it strategically for the right tasks at the right time.

Here's how.

The Breaking Point

It was a Tuesday at 11 PM. I was still debugging a Kubernetes deployment issue that should have taken 30 minutes. I'd been at it for 4 hours. My eyes were burning. And I had a sinking feeling I was going to dream about YAML indentation.

The problem? I knew what I needed to do — configure a network policy, set up resource limits, and debug a failing health check. But I was stuck in documentation hell, jumping between 12 different tabs, trying to remember the exact syntax for a specific kubectl command.

That's when I had my moment of weakness. I opened Cursor, pasted my deployment config, and asked: "Why is this pod stuck in Pending?"

30 seconds later, I had my answer. The resource requests were too high for my node pool. I had a working fix. I went to bed before midnight.

The lesson? AI isn't replacing developers — it's replacing Stack Overflow at 2 AM when your brain has stopped working.

What Actually Changed

Here's the thing nobody tells you about AI coding assistants: they're not magic. They won't architect your system for you. They won't understand your business logic. They won't know why you made that weird technical decision three years ago that now haunts your codebase.

But what they can do is accelerate the boring, repetitive, time-consuming parts of development that eat up your day. Here's exactly where I'm saving those 10 hours.

1. Boilerplate Elimination (2-3 hours saved)

You know that feeling when you need to create a new API endpoint and you sigh because you know you're about to write the same CRUD code you've written 50 times before?

Yeah, I don't do that anymore.

Before:

• Create controller file

• Write route handlers

• Add validation logic

• Set up error handling

• Write tests

• 45 minutes gone

Now:

• Describe what I need: "Create a REST endpoint for user preferences with validation."

• Review and customize the generated code

• 10 minutes done

The AI doesn't get it perfect. I still need to review, adjust, and sometimes rewrite. But starting from 80% complete instead of 0%? That's the difference between getting it done and putting it off.

2. Context Switching Reduction (2-3 hours saved)

Here's something that doesn't get talked about enough: the cognitive cost of context switching.

You're deep in implementing a feature. You need to look up how to do something specific. You open a browser. You search. You find a Stack Overflow answer. You get distracted by a notification. You check your email. You fall into a Reddit hole. 30 minutes later, you forgot what you were originally doing.

My new workflow:

• Ask the AI directly in my editor

• Get an answer immediately

• Never leave my coding flow

• Stay focused on the actual problem

The time savings here aren't just the search — it's preserving my mental state. I stay in the zone. I ship faster. I'm less exhausted at the end of the day.

3. Debugging Acceleration (2-3 hours saved)

I'm going to say something controversial: I'm a good debugger. I've been doing this for years. I know how to read stack traces, analyze logs, and trace through code.

But I'm also human. I miss things. I make assumptions. I get stuck in rabbit holes.

AI assistants are like having a second pair of eyes that never gets tired. They spot patterns I miss. They suggest causes I hadn't considered. They help me question my own biases.

Example from last week:

I had a race condition that was driving me insane. I'd been debugging for an hour. I was convinced it was a database locking issue.

I pasted the code into Claude and asked: "What could cause intermittent failures in this concurrent operation?"

It suggested three possibilities. The third one was right — a subtle closure variable capture issue I never would have caught. 5 minutes to fix. An hour I would have spent going down the wrong path.

4. Documentation & Testing (2-3 hours saved)

Raise your hand if you love writing documentation.

Yeah, that's what I thought.

I don't love writing docs. But I love having good docs. And I've learned that AI assistants are surprisingly good at generating documentation that doesn't suck.

My workflow now:

• Write the code

• Ask AI to generate docstrings

• Review and refine

• Ask AI to generate test cases

• Review and refine

The keyword here is review. I'm not blindly accepting AI output. But starting from a solid draft instead of a blank page? That's the difference between having documentation and... not having it.

5. Learning New APIs & Patterns (1-2 hours saved)

I work across a lot of different technologies. One day it's Kubernetes, the next it's a new JavaScript framework, then it's some cloud service I haven't used before.

Traditionally, learning a new API meant reading documentation, finding tutorials, trial and error, Stack Overflow deep dives, and hours of frustration.

Now?

• "Show me how to implement authentication with NextAuth.js"

• Get working code examples

• Learn by doing, not by reading

• Ask follow-up questions when stuck

It's like pair programming with someone who's read all the docs and remembers everything.

The Tools I Actually Use

Let me be specific about what I'm using, because not all AI assistants are created equal.

For Daily Coding: Cursor

Cursor has become my primary editor. The inline completions are good, but the real magic is the chat interface. I can ask questions about my entire codebase, get explanations of complex functions, and have it help me refactor.

Best for:

• Understanding legacy code

• Refactoring large files

• Generating boilerplate

• Debugging tricky issues

For Architecture & Complex Tasks: Claude

When I need to think through a system design or solve a complex problem, Claude is my go-to. It's better at reasoning, follows instructions more carefully, and produces higher-quality output for complex tasks.

Best for:

• System design discussions

• Writing comprehensive tests

• Documentation generation

• Complex debugging scenarios

For Quick Lookups: GitHub Copilot

Copilot is great for those "I know what I want to write but can't remember the exact syntax" moments. It's fast, it's in my IDE, and it's surprisingly good at completing my thoughts.

Best for:

• Auto-completing repetitive code

• Remembering syntax

• Quick function generation

• Boilerplate reduction

What I Don't Use AI For

Here's the part that matters: I'm not letting AI write my critical business logic. I'm not accepting suggestions blindly. I'm not outsourcing my thinking.

Things I still do myself:

• Architecture decisions — AI doesn't understand my constraints, trade-offs, or business context

• Security-sensitive code — I'm not trusting AI with auth, encryption, or anything that could be exploited

• Complex algorithm design — AI is good at implementation, not innovation

• Code review — I still review every line, even AI-generated code

• Understanding the "why" — AI can tell me how to do something, but I need to understand why

The rule I live by: AI accelerates my work, but I'm still the developer. I'm responsible for the code that ships.

The Real ROI: Beyond Hours Saved

Tracking hours is useful, but it doesn't capture the full picture. Here are the benefits I didn't expect:

Less mental fatigue. I'm not exhausted at the end of the day anymore. I'm not making as many silly mistakes. I'm not burning out as quickly.

More time for deep work. Because I'm spending less time on boilerplate and debugging, I have more time for the interesting stuff: architecture, optimization, building features that actually matter.

Faster learning. I'm learning new technologies faster because I have an AI tutor available 24/7. I'm more willing to try new things because the barrier to entry is lower.

Better code quality. Counterintuitive, right? But having AI suggest test cases and catch edge cases I would have missed has actually improved my code quality.

Your Action Plan

If you're convinced (or at least curious), here's how to get started without drowning in tool overload:

Week 1: Pick One Tool

Don't try to learn everything at once. Pick one AI assistant:

• Cursor if you want an all-in-one editor experience

• GitHub Copilot if you want minimal disruption

• Claude if you prefer a chat interface for complex tasks

Week 2: Identify Your Pain Points

Track your time for a week. Notice where you're getting stuck:

• Writing boilerplate?

• Debugging?

• Learning new APIs?

• Writing tests?

These are your opportunities.

Week 3: Build New Habits

Start integrating AI into your workflow:

• Ask for help when you're stuck for more than 10 minutes

• Use AI to generate tests for new functions

• Let AI write your first draft of documentation

Week 4: Review and Refine

Look back at the AI-generated code. What worked? What didn't? Adjust your approach. Learn the patterns where AI helps and where it hinders.

Common Pitfalls

I've made all these mistakes, so you don't have to:

Blind trust. Don't accept AI suggestions without understanding them. If you can't explain what the code does, don't ship it.

Fix: Always review AI-generated code. Treat it like code from a junior developer — helpful, but needs supervision.

Over-reliance. Don't let your skills atrophy. AI is a tool, not a replacement for your knowledge.

Fix: Periodically write code without AI assistance. Stay sharp on fundamentals.

Security blind spots. AI can generate insecure code. It doesn't know your security requirements.

Fix: Never let AI handle authentication, authorization, or encryption without thorough review.

Hallucination trust. AI makes things up. It invents APIs that don't exist. It suggests deprecated patterns.

Fix: Always verify API documentation. Don't assume AI knows the latest best practices.

The Bottom Line

AI coding assistants aren't magic. They're not going to make you a 10x developer overnight. They're not replacing the need to understand your craft.

But used correctly? They're the most significant productivity boost I've experienced in my career.

Those 10 hours I save each week? I'm spending them on building better features, learning new technologies, and actually having a life outside of work.

And honestly? That's worth more than any tool.

I'm curious: What's your experience with AI coding assistants? Are you using them? Skeptical? Tried and gave up?

Drop a comment — I read every single one, and I love hearing about other developers' real-world experiences.

Ready to try AI-assisted coding? Start small. Pick one task. See how it feels. You might be surprised.

What's the most time-consuming part of your development workflow? Let me know in the comments — I might have a solution for you.

I needed to pick up some furniture from a friend across town, then drop it off at my place. The metro? Sure, but good luck hauling a chair through the station. An Uber? $25 each way, so $50 total. But if I could just grab a Flex vehicle – any Flex vehicle – I could do the whole trip for under $15.

The app showed a Toyota Corolla two blocks away. Perfect. I tapped on it. Loading... Loading... And then:

"Sorry, this vehicle is no longer available."

Frustrated? Yeah, you could say that. 😤

The Refresh Game Nobody Asked For

Here's the thing about using car-sharing services like Communauto Flex in a busy city: finding an available vehicle isn't just about luck – it's about speed. And not the speed of getting to the car, but the speed of your thumbs on the screen.

I'd see a vehicle pop up on the map, tap it as fast as I could, wait for the details to load, and by the time the booking button appeared, someone else had already grabbed it. Every. Single. Time.

It felt like playing a video game where the difficulty was permanently set to "impossible." 🎮

So what did I do? Like any reasonable person who just needed to get somewhere, I started developing a strategy:

1. Open the app

2. Refresh

3. See a car

4. Tap it instantly

5. Lose it to someone faster

6. Repeat steps 2-5 until either:

   • I miraculously won the refresh lottery

   • I gave up and took the metro

   • I was late to where I needed to be

I'm not exaggerating when I say I spent 15 minutes one morning just standing on the street, refreshing the app, watching cars appear and disappear like some kind of vehicular whack-a-mole game. 🚗💨

Real talk: I calculated once that I was probably refreshing the app 3-4 times per minute. That's over 45 refreshes in 15 minutes. And I still didn't get a car.

The Moment Everything Changed 💡

One particularly frustrating morning, after losing yet another vehicle to a faster refresher, I had a thought that changed everything:

"I'm a software engineer. What if I could automate this?"

What if, instead of me sitting there refreshing the app like a maniac, there was a system that could watch for available vehicles on my behalf? What if it could instantly block a car the second it became available, before anyone else even saw it?

What if I could just set my location, tell it "find me a Flex vehicle within 500 meters," and then go about my morning while the system did the hunting for me?

That's when CommunoPlus was born. Not because I had some grand plan, but because I was genuinely tired of losing the car-sharing game to people with faster fingers. I just wanted to solve my own problem.

But Wait, Isn't That... Cheating? 🤔

I know what you're thinking. "Dude, you're basically cutting in line."

And yeah, I get why it might feel that way. But here's how I saw it:

The official Communauto app makes you manually refresh and manually search. That's just... how it works. There's no notification system. There's no "alert me when a car becomes available near me" feature. You're expected to just know when cars become available and be faster than everyone else.

That's not user experience. That's a competition.

And like any competition, the person with the better tools wins. Some people had faster phones. Some had better internet connections. Some were just naturally faster at tapping through screens.

I just happened to have the ability to write code that could do it for me. 🤷‍♂️

The Real Problem I Discovered

As I started building what would eventually become CommunoPlus, I realized something: I wasn't alone in this frustration.

I started talking to other Communauto users – friends, coworkers, people on Reddit – and the stories were all the same:

• Weekend planners who needed a car for errands or day trips but couldn't find one in time

• Parents trying to get their kids to activities across town

• Students missing classes because they spent 20 minutes trying to book a vehicle

• Remote workers who gave up on Flex entirely because it was "too unreliable"

The common thread? Everyone was playing the same refresh game. Everyone was frustrated. And everyone just accepted it as "how car-sharing works."

But it didn't have to be that way.

The Other Problems I Noticed 📝

Once I started really paying attention to my Communauto usage, I noticed other problems too:

The 31-Day Booking Window Problem

I wanted to book a car for a trip I was planning two months out. Can't do it. Communauto only lets you book 31 days in advance.

So I had to set a reminder for exactly 31 days before my trip, hope I remembered to check at that exact time, and hope a vehicle was available. And if I forgot? Well, I might be taking the bus on my vacation. 🙈

The Lost & Found Black Hole

Left my AirPods in a Flex vehicle once. The official lost and found process involved calling customer service, filing a report, and... waiting. And hoping. And usually never hearing back.

There was no way to connect with the next person who used that car. No systematic way to match "I lost something" with "I found something." Just a void where your belongings disappeared forever.

The Mystery Vehicle Experience

Ever book a car and have no idea what you're getting until you show up? No photo, no ratings, no reviews. You just see "Toyota Prius C" and hope for the best.

Sometimes you'd get lucky – a decent vehicle. Other times? Not so much. The AC doesn't work (those old Prius Cs...). There's a weird smell. The previous user left trash everywhere. Or worse – dog hair. Everywhere. On the seats, in the air vents, coating your jacket the moment you sit down.

There was no way to know if the vehicle you're about to book is pristine or... problematic. You just had to roll the dice. 🎲

Why I Decided to Build Something

So there I was, a software engineer in Montreal, actively using Communauto multiple times a week, running into all these frustrations, and thinking:

"Someone should fix this."

And then the classic developer realization:

"Wait... I'm someone. I can fix this." 💪

I wasn't planning to build a competitor to Communauto. I loved the service! I just wanted to solve the user experience problems that were making my life harder.

I wanted:

• Automation for finding and blocking vehicles (solve the refresh game)

• Smart scheduling for long-term planning (solve the 31-day window)

• Community features for lost and found (solve the black hole)

• Transparency through vehicle ratings (solve the mystery vehicle)

The Journey Begins 🚀

That Saturday morning frustration led to 18 months of development. Late nights after work. Weekends jumping from mobile development to backend architecture to cloud infrastructure. Learning about API integration, background job processing, and how to build a system that actually works reliably.

I was building CommunoPlus as a solution to my problem. The fact that other Communauto users found it helpful too – that hundreds of people now use it to enhance their car-sharing experience – that was the surprise.

And you know what? There was a better way. 🎯

What Happened Next

Over the next 18 months, I built CommunoPlus from scratch. I launched it on the App Store and Google Play. I watched as real users started solving the same problems I had. I saw the Reddit posts from people sharing their success stories.

And you know what the coolest part was?

I stopped losing the refresh game. Because I wasn't playing it anymore. 🎯

In the coming posts, I'll walk you through how I built each feature – the technical challenges, the architecture decisions, the mistakes I made, and the lessons I learned. From Flex Radar's automated hunting system to the AI-powered Lost & Found, I'll share the entire journey.

But for now, I want to know:

Have you ever experienced this frustration? Are you tired of playing the refresh game? Have you missed opportunities because you couldn't find a Flex vehicle in time?

If so, I built CommunoPlus for you. And I'd love to hear your story.

Ready to stop playing the refresh game?

📱 Download CommunoPlus:

• iOS: App Store Link

• Android: Google Play Link

• Website: communoplus.com

Coming up next: "Building Flex Radar - When Automation Meets Real Problems" – The technical deep dive into how I automated vehicle hunting and what I learned about building reliable background systems.

Have a car-sharing frustration story? Drop a comment or reach out at support@communoplus.com – I love hearing from fellow Communauto users!

It got me thinking. I've been doing this for over a decade now, and honestly? The landscape feels both familiar and alien at the same time.

If you've been in this space for a while, you probably remember when "DevOps" was this revolutionary idea that half the industry was skeptical about. Now my nephew's coding bootcamp has a whole module on it. Wild, right? 😅

So let me share what I've been seeing out there in 2025 — the good, the weird, and the "wait, we're still dealing with this?" parts of modern DevOps. 🚀

The Stuff That's Actually Different Now

AI Is Everywhere (And I Mean Everywhere) 🤖

Remember spending entire afternoons debugging YAML files? Yeah, those days are mostly behind us. I watched a junior dev on my team fix a broken pipeline last month by literally asking an AI: "Why is my deployment failing?"

The AI didn't just give her an answer — it suggested three different fixes and explained the trade-offs of each. I'm not gonna lie, I was a little jealous. 😂

What we're seeing:

• AI that actually writes decent infrastructure code (not just boilerplate)

• Monitoring that tells you about problems before your users start complaining

• Incident response that feels less like chaos and more like having a really smart friend walking you through it

Platform Engineering Has Saved My Sanity 🙏

I used to spend half my time helping developers figure out how to deploy their apps. Now? We built them a platform that just... works. They push code, it goes live, everyone's happy.

It's like we finally figured out that not every developer needs to be a Kubernetes expert. Revolutionary concept, I know. 💡

Security Isn't the "Fun Police" Anymore 🔒

This might be the biggest change I've seen. Security used to be this thing that happened at the end, usually involving tense meetings and delayed releases. Now it's just... part of the process.

My team runs security scans on every commit, and honestly, most of the time we don't even think about it. It's like wearing a seatbelt — just something you do. ✅

Observability Actually Makes Sense Now

I used to have seventeen different dashboards, and somehow still couldn't figure out why the app was slow. Now everything talks to everything else, and when something breaks, I usually know what and why before I've finished my first cup of coffee.

The Cloud Bill Is... Yikes 💸

Multi-cloud isn't a strategy anymore — it's just what happens when you've been around long enough. One acquisition here, one cost optimization there, and suddenly you're running workloads on three different cloud providers.

Pro tip: Get really good at FinOps, or your CFO will not be happy with you. 📊

The Stuff That Hasn't Changed (Thank God) 🙌

It's Still About People, Not Tools 👥

I've seen teams with the fanciest AI-powered everything fall apart because they couldn't talk to each other. I've also seen teams with basic tools ship incredible products because they actually worked together.

The technology is just the easy part. Getting humans to collaborate well? That's still the real challenge.

CI/CD Is Still the Foundation

Yeah, the pipelines are smarter now. Yeah, they can fix themselves sometimes. But the core idea — deploy small changes frequently, test everything, don't break production — that's exactly the same as it was five years ago.

Kubernetes Still Rules (Whether We Like It or Not) ⚓

I have mixed feelings about this one. Kubernetes solved a lot of problems, but it also created new ones. The good news is that platform engineering has made it so most developers don't have to care about it anymore.

It's like electricity in your house — super important, but you don't think about the power grid every time you flip a light switch. 💡

Finding Good People Is Still Hard 🔍

The tools change every six months, but finding someone who really gets infrastructure, automation, and how to work with people? That's still the holy grail. 🏆

What I Think Comes Next 🔮

Honestly? I think we're heading toward a world where the technical stuff becomes increasingly invisible. More AI, better platforms, fewer 2 AM phone calls about prod being down. 📞

But the human stuff — the collaboration, the problem-solving, the "let's figure this out together" mentality — that's going to matter more than ever. 🤝

My Take

DevOps in 2025 feels like we've finally grown up. We have better tools, smarter processes, and (mostly) learned from our mistakes. But at its core, it's still about building great software with great people.

If you're just getting started in this field, here's my advice: learn the fundamentals, stay curious, and remember that every expert was once a beginner who couldn't figure out why their Docker container wouldn't start. 🐳

And if you're a veteran like me? Embrace the changes, but don't forget why we started doing this in the first place — to make building and shipping software better for everyone.

What's your experience been like? Has AI actually made your life easier, or are you still fighting with YAML files like the rest of us? I'd love to hear your stories — the real ones, not the LinkedIn success posts. 😉

Yeah, that actually happened to a founder I know. Turns out, someone found their misconfigured S3 bucket and used it to mine cryptocurrency. Ouch.

Look, I get it. When you're in startup mode, security feels like something you'll "figure out later." You're moving fast, breaking things, and honestly? The cloud makes everything feel so easy that it's tempting to think it's handling the security stuff for you too.

Spoiler alert 🚨: It's not.

But before you panic, here's the thing – most cloud security disasters aren't caused by some hoodie-wearing hacker with a Matrix-style setup. They're usually just... mistakes. Really preventable mistakes that happen when smart people are moving too fast.

So let's talk about the ones I see over and over again, and how to fix them without slowing down your momentum.

"We'll Just Make Everything Public for Now"

I can't tell you how many times I've heard this. Someone creates an S3 bucket, makes it public so the whole team can access it quickly, and then... forgets about it. Forever.

Here's what actually happens: Your bucket becomes Google-able. Yes, people literally search for exposed buckets. It's like leaving your front door open with a sign that says "free stuff inside."

What you should do instead:

• Default to private. Always. No exceptions.

• Create proper IAM users for your team (I know, it takes 5 extra minutes, but trust me)

• Use AWS's "Block Public Access" feature – it's literally a checkbox that prevents these disasters

• Set calendar reminders to audit permissions quarterly

Real talk: I once helped a company that had accidentally exposed their entire customer database this way. The founder told me he aged 10 years in 10 minutes when he realized what happened.

The "We All Share the God Account" Problem

This one makes me want to pull my hair out. Using the root account (or one shared admin account) because "it's just easier right now" is like giving everyone in your office a master key to the building, your house, and your car.

When (not if) someone leaves your company, do you really want to change every single password and regenerate every API key?

Here's the grown-up approach:

• Create individual accounts for everyone. Yes, even your co-founder who's sitting right next to you.

• Use the principle of least privilege – if someone only needs to read logs, don't give them permission to spin up new servers

• Turn on MFA everywhere. Everywhere. Your future self will thank you.

Pro tip from someone who learned the hard way: When you inevitably forget to revoke access for that intern who left six months ago, you'll be really glad they didn't have admin privileges.

Secrets in Your Code (AKA "Please Hack Me")

I've seen API keys in GitHub repos more times than I can count. Sometimes in the commit message. Sometimes in a file literally called passwords.txt. I wish I was making this up.

If your repo ever becomes public, or if someone gets access to it, you've basically handed them the keys to your entire infrastructure.

Do this instead:

• Use a proper secrets manager. AWS Secrets Manager, HashiCorp Vault, whatever – just not your source code.

• Create a .env.example file with dummy values so your team knows what variables they need

• Set up pre-commit hooks that scan for accidentally committed secrets

• Rotate your keys regularly (and yes, that includes the ones you think nobody knows about)

The $50,000 Surprise (Monitoring Your Wallet)

Remember that founder I mentioned earlier? His story isn't unique. Attackers love finding misconfigured cloud resources because they can use them for free crypto mining, sending spam, or worse.

But here's what really gets me: this is totally preventable.

Set up alerts for everything:

• Spending alerts (seriously, set these up before you deploy anything)

• Usage spikes that don't match your actual traffic

• New resources being created outside business hours

• Failed login attempts

Personal anecdote: I once got a text at 3 AM because someone was trying to brute-force one of our servers. It was annoying at the time, but that alert probably saved us thousands in compute costs and a potential data breach.

"We'll Add Logging Later" (Famous Last Words)

You know what's worse than having a security incident? Having a security incident and having no idea what happened, when it happened, or how bad it is.

I get it – logging feels like overhead when you're trying to ship features. But it's like having security cameras in your store. You hope you'll never need them, but when something goes wrong, you'll be desperate for that footage.

Start simple:

• Turn on CloudTrail, Azure Activity Logs, or GCP Audit Logs (it's literally a toggle switch)

• Forward everything to a central place where you can actually search it

• Set up alerts for the obvious bad stuff: failed logins, resources being created outside business hours, API calls from weird locations

Compliance Isn't Just for "Big Companies"

I used to think compliance was something you dealt with after you had "real customers." Then I watched a promising startup spend six months retrofitting their entire infrastructure because they needed SOC 2 to close a big deal.

Here's the reality check: If you're collecting any user data (and you probably are), you're going to need to think about compliance eventually. Starting early is way easier than trying to bolt it on later.

Baby steps that make a big difference:

• Know what type of data you're storing (personal info, payment data, health records)

• Encrypt everything (in transit and at rest)

• Document your security practices as you go

• Consider compliance requirements for your target market

Backups Are Like Insurance (You Need Them Before You Need Them)

"We'll set up backups next sprint" is probably the most expensive technical debt you can accumulate. I've seen too many companies learn this lesson the hard way.

Make it automatic:

• Set up automated daily backups

• Store them in a different region (or better yet, a different account)

• Actually test your recovery process – don't just assume it works

• Have a plan for different scenarios (accidental deletion vs. ransomware vs. natural disaster)

The Real Talk Section

Look, security isn't sexy. It doesn't directly add features your users will notice. It's easy to deprioritize when you're trying to find product-market fit or close your next funding round.

But here's what I've learned after years in this space: the companies that treat security as a feature of their product – not an afterthought – are the ones that scale successfully. They're the ones that don't have to pause everything to deal with a breach. They're the ones that can confidently tell enterprise customers "yes, we take security seriously."

Your Startup Security Checklist

Here's what you can knock out this week (seriously, most of this takes less than a day):

Week 1 priorities:

• ✅ Lock down all storage buckets (default to private)

• ✅ Create individual IAM accounts for everyone

• ✅ Enable MFA everywhere

• ✅ Set up basic spending alerts

Month 1 priorities:

• ✅ Move all secrets to a proper secrets manager

• ✅ Enable basic logging and monitoring

• ✅ Set up automated backups

• ✅ Document your current security practices

Quarter 1 priorities:

• ✅ Regular access audits

• ✅ Test your backup recovery

• ✅ Evaluate compliance requirements

• ✅ Security training for the team

Bottom Line

Every successful startup I know has had at least one "oh shit" moment with security. The difference between the ones that survive and thrive versus the ones that don't is usually just timing – did they get serious about security before or after something went wrong?

The cloud gives you superpowers, but like any superpower, it comes with responsibility. The good news? Most of this stuff is way easier to implement than you think, and future you will be incredibly grateful that present you took the time to do it right.

Your users are trusting you with their data. Your investors are trusting you with their money. And honestly, you're probably trusting your entire company's future to your cloud infrastructure.

That trust is worth protecting.

What's your startup's biggest cloud security concern? Drop me a line – I love helping founders navigate this stuff, and I promise not to judge you for any shortcuts you might have taken. We've all been there.

Blog post Objectives

Upon completion of this tutorial, you will be able to:

• Install kubeadm and its dependencies

• Initialize a control-plane node

• Join a node to a cluster

• Configure a network plugin

Prerequisites

You should be familiar with:

• Working with Kubernetes to deploy applications

• Working at the command line in Linux

At the end of this blog post, you will be able to create a K8S Cluster with a Master Node and two Worker Nodes

This tutorial experience involves Amazon Web Services (AWS), and we'll use the AWS Management Console.

Creating 3 AWS EC2 Instances

Start by creating 3 Ubuntu instances with the following names:

1. instance-a

2. instance-b

3. instance-c

Connecting to an EC2 Instance

We will connect to the three Amazon EC2 instances and configure them to be a Kubernetes cluster. In later steps, we'll connect to instances named instance-b and instance-c.

Now we have our 3 EC2 instances UP and running, let's connect to the instance named instance-a using the Amazon EC2 Instance Connect:

Right-click the instance named instance-a, and click Connect:

A browser-based shell will open in a new window and you will see a shell similar to:

Now that we are connected to our instance-a let's see what kubeadm is:

kubeadm is a tool that allows you to easily create Kubernetes clusters. It can also perform a variety of cluster lifecycle functions, such as upgrading and downgrading the version of Kubernetes on nodes in the cluster. We will use kubeadm to create a Kubernetes cluster from scratch. Creating clusters with kubeadm is the recommended way for learning Kubernetes, creating small clusters, and as a piece of more complex systems for more enterprise-ready clusters.

Installing Kubeadm and its Dependencies

Our three EC2 instances running the Ubuntu distribution of Linux. we will configure the instance "instance-a" as a Kubernetes control-plane and the other instances as worker nodes in the cluster. In this step, we will install kubeadm and its dependencies, including containerd.

1. Enter the following command to update the system's apt package manager index and update packages required to install containerd:

# Update the package index
sudo apt-get update
# Update packages required for HTTPS package repository access
sudo apt-get install -y apt-transport-https ca-certificates curl software-properties-common gnupg lsb-release

1. Allow forwarding IPv4 by loading the br_netfilter module with the following commands:

# Load br_netfilter module
sudo modprobe overlay
sudo modprobe br_netfilter
cat <<EOF | sudo tee /etc/modules-load.d/k8s.conf
overlay
br_netfilter
EOF

1. Allow the Linux node's iptables to correctly view bridged traffic with the following commands:

# sysctl params required by setup, params persist across reboots
cat <<EOF | sudo tee /etc/sysctl.d/99-kubernetes-cri.conf
net.bridge.bridge-nf-call-iptables  = 1
net.ipv4.ip_forward                 = 1
net.bridge.bridge-nf-call-ip6tables = 1
EOF
# Apply sysctl params without reboot
sudo sysctl --system

1. Install containerd using the DEB package distributed by Docker with the following commands:

# Add Docker’s official GPG key
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /usr/share/keyrings/docker-archive-keyring.gpg
# Set up the repository
echo \
  "deb [arch=amd64 signed-by=/usr/share/keyrings/docker-archive-keyring.gpg] https://download.docker.com/linux/ubuntu \
  $(lsb_release -cs) stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null
# Install containerd
sudo apt-get update
sudo apt-get install -y containerd.io=1.6.18-1

Note: This is only one way of installing containerd. Please refer here for the other options.

1. Configure the systemd cgroup driver with the following commands:

# Configure the systemd cgroup driver
sudo mkdir -p /etc/containerd
containerd config default | sudo tee /etc/containerd/config.toml
sudo sed -i 's/SystemdCgroup = false/SystemdCgroup = true/' /etc/containerd/config.toml
sudo systemctl restart containerd

This is required to mitigate the instability of having two cgroup managers. Please refer here for further explanation.

1. Install kubeadm, kubectl, and kubelet from the official Kubernetes package repository:

# Add the Google Cloud packages GPG key
curl -s https://packages.cloud.google.com/apt/doc/apt-key.gpg | sudo apt-key add -
# Add the Kubernetes release repository
sudo add-apt-repository "deb http://apt.kubernetes.io/ kubernetes-xenial main"
# Update the package index to include the Kubernetes repository
sudo apt-get update
# Install the packages
sudo apt-get install -y kubeadm=1.28.1-00 kubelet=1.28.1-00 kubectl=1.28.1-00

1. Prevent automatic updates to the installed packages with the following command:

sudo apt-mark hold kubelet kubeadm kubectl

The version of all the packages is set to 1.28.1 for consistency in this tutorial experience, and so that we can perform a cluster upgrade in a later blog post.

1. Display the help page for kubeadm:

kubeadm

Read through the output to get a high-level overview of how a cluster is created and the commands that are available in kubeadm.

After setting the first instance-a up we must do the same thing for instance-b and instance-c: Right-click the instance named instance-b, and click Connect:

After connecting the instance-b, enter the same commands we have executed before for the instance-b, The same steps should be done for instance-c

Now that kubeadm is configured on the 3 EC2 instances, connect back the instance-a to configure it as the master node for our k8s cluster.

Initializing the Kubernetes Master Node

We will use kubeadm to initialize the control-plane node. The initialization process will create a certificate authority for secure cluster communication and authentication, and start all the node components (kubelet), control-plane components (API server, controller manager, scheduler, etcd), and common add-ons (kube-proxy, DNS). You will see how easy the initialization process is with kubeadm.

The initialization uses sensible default values that adhere to best practices. However, many command options are available to configure the process, including if you want to provide your own certificate authority or if you want to use an external etcd key-value store. One option that you will use is required by the pod network plugin that you will install after the control-plane is initialized. kubeadm does not install a default network plugin for you. You will use Calico as the pod network plugin. Calico supports Kubernetes network policies. For network policies to function properly, you must use the --pod-network-cidr option to specify a range of IP addresses for the pod network when initializing the control-plane node with kubeadm.

There are many network plugins besides Calico. Calico is used primarily because it is used in clusters in Kubernetes certification exams and it supports network policies. Calico is used internally by AWS, Azure, and GCP for their managed Kubernetes offerings, so you can be certain it is production-ready. However, if all of your environments live in AWS, you may consider the Amazon VPC network plugin.

1. Initialize the control-plane node using the init command:

sudo kubeadm init --pod-network-cidr=192.168.0.0/16 --kubernetes-version=stable-1.28

The pod network CIDR block (192.168.0.0/16) is the default used by Calico. The CIDR does not overlap with the Amazon VPC network CIDR used in this tutorial. If it did, you would need to perform additional configuration of Calico later on to avoid the overlap. The output reports the steps that kubeadm takes to initialize the control-plane:

Read through the output to understand what is happening. At the end of the output, useful commands for configuring kubectl and joining worker nodes to the cluster are given:

1. Copy the kubeadm join command at the end of the output and store it somewhere you can access later.

It is simply convenient to reuse the given command, although you can regenerate it and create new tokens using the kubeadm token command. The join tokens expire after 24 hours by default.

1. Initialize your user's default kubectl configuration using the admin kubeconfig file generated by kubeadm:

mkdir -p $HOME/.kube
sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
sudo chown $(id -u):$(id -g) $HOME/.kube/config

1. Confirm you can use kubectl to get the cluster component statuses:

kubectl get componentstatuses

The output confirms that the scheduler, controller-manager, and etcd are all Healthy. The Kubernetes API server is also operational, or kubectl would have returned an error attempting to connect to the API server. Enter kubeadm token --help if you would like to know more about kubeadm tokens.

1. Get the nodes in the cluster:

   
    kubectl get nodes
   

   

   The control-plane node is reporting a STATUS of NotReady. Notice kubeadm gives the node a NAME based on its IP address. The --node-name option can be used to override the default behavior.

2. Describe the node to probe deeper into its NotReady status:

kubectl describe nodes

In the Conditions section of the output, observe the Ready condition is False, and read the Message:

The kubelet is not ready because the network plugin is not ready. The cni config uninitialized refers to the container network interface (CNI) and is a related problem. Network plugins implement the CNI interface. You will resolve the issue by initializing the Calico network plugin.

1. Enter the following commands to create the Calico network plugin for pod networking:

kubectl apply -f https://clouda-labs-assets.s3.us-west-2.amazonaws.com/k8s-common/1.28/scripts/calico.yaml

A variety of resources are created to support pod networking. A daemonset is used to run a Calico-node pod on each node in the cluster. The resources include several custom resources (customresourcedefinition) that extend the Kubernetes API, for example, to support network policies (networkpolicies.crd.projectcalico.org). Many network plugins have a similar installation procedure.

1. Watch the status of the nodes in the cluster:

watch kubectl get nodes

With the network plugin initialized, the control-plane node is now Ready. Note: It may take a minute to reach the Ready state.

Press ctrl+c to stop watching the nodes.

Joining a Worker Node to the Kubernetes Cluster

The process of adding a worker node with kubeadm is even simpler than initializing a control-plane node. You will join a worker node to the cluster using the command that kubeadm init

1. Open a second terminal connected to instance-b that is listed in the EC2 Console.

Refer back to the earlier steps on connecting to instance-a using EC2 Instance Connect, if required.

1. Enter sudo followed by the kubeadm join command that you stored from the output of kubeadm init. It resembles:

sudo kubeadm join 10.0.0.100:6443 --token ... --discovery-token-ca-cert-hash sha256:...

Read through the output to understand the operations kubeadm performed.

1. In the control-plane node's SSH shell, confirm the worker node is part of the cluster:

kubectl get nodes

The worker node appears with a role of <none>.

Note: It may take a minute for the worker node to become Ready.

Confirm that all the pods in the cluster are running:

kubectl get pods --all-namespaces

All of the pods are Running, and the two-node cluster is operational. Notice that there are two Calico pods that support pod networking on each node.

Summary

In this blog post, we have transformed 3 EC2 simple instances into a Kubernetes Cluster having one Master Node and 2 Worker Nodes, we have also configured Calico as a pod network plugin.