For a long time, I was doing everything manually.

Logging into one device… then the next… then the next.
Running the same commands. Fixing the same issues.
And every time, I thought — *this is just part of the job.*

But it started getting frustrating.

Not because the work was hard…
but because it was repetitive.

And deep down, I knew something wasn’t right.


One day, after spending hours doing something that felt like it should take minutes, I paused and asked myself:

*“Is this really the best way to do this?”*

That question stayed with me.

I didn’t suddenly become an automation expert overnight.

I started small.

One simple script.
Then another.
Then slowly… things began to change.

Tasks that used to take hours started taking minutes.
And more importantly — I started thinking differently.

Not like someone who executes tasks…
but like someone who builds systems.


This series is just me sharing that journey.

No big claims.
No “become expert in 24 hours” promises.

Just one small step every day.

## What you’ll find here

Every day, I’ll pick one real problem.

Something I’ve faced.
Something you’ve probably faced too.

And I’ll show how I approached it using automation.

Sometimes it’ll be simple.
Sometimes I’ll mess up and learn along the way.

But it’ll always be real.

## Who this is for

If you’re someone who:

* Feels stuck doing repetitive network tasks
* Knows automation is important but hasn’t started yet
* Wants to move beyond just running commands

Then you’ll feel at home here.

## How to follow this

Don’t overthink it.

Start from Day 1.
Spend a little time with each post.
Even if you don’t understand everything — that’s okay.

Just stay with it.

## The plan

30 days.
30 small steps.
That’s it.

No pressure to be perfect.

## Start here

👉 Day 1: Coming Soon !!
👉 Day 2:

(I’ll keep updating this as we go)


If you decide to follow along…

just know this:

You don’t need to have everything figured out.You just need to start.---

See you in Day 1.

LLMs for Engineers — Part 5

So far in this series, we’ve broken things down step by step. We started with where the data comes from, then saw how text becomes tokens, and then understood how the model predicts the next token again and again.

At this point, you already know how the system behaves from the outside. But there is still one big missing piece .What is actually inside the model that makes all of this possible?

If we simplify everything, we can think of the model as a function. You give it a sequence of tokens, and it gives you probabilities for the next token. That’s the behavior we discussed earlier. But that function is not magic. It has a structure, and that structure is what we call a transformer.

Before transformers came into the picture, models used to process text step by step. They would read one word, then the next, and then the next. This worked, but it had clear limitations. It was slow, and more importantly, it struggled to handle long sequences. If something important appeared earlier in a sentence, the model would often lose track of it by the time it reached the end.

Transformers changed this completely by introducing a different way of looking at text. Instead of processing words one by one, they look at the entire sequence at the same time. This might sound simple, but it is a big shift. It means the model doesn’t have to “remember” things in the same way. It can directly look at any part of the input whenever it needs to.

To make this more concrete, think about a sentence like “the router that connects to the core switch is down”. When you read this, you naturally understand that “is down” refers to the router, not the switch. You connect different parts of the sentence without even thinking about it. The transformer is designed to do something similar, but using numbers.

This is where the idea of attention comes in. Attention is the core mechanism inside a transformer. In simple terms, it means that for every token in the sequence, the model looks at all the other tokens and decides which ones are important. Not all tokens contribute equally. Some carry more useful information for the current prediction, and the model learns to focus on those.

You can think of it like this. Each token is asking a question: “which other tokens should I pay attention to right now?” The model then assigns weights to all the tokens based on their importance. Tokens that matter more get higher weights, and those that matter less get lower weights. This creates a web of relationships across the entire sequence.

Once these relationships are established, the information flows through multiple layers inside the transformer. Each layer refines the representation a little more. At the beginning, the model might only capture very basic patterns. As we go deeper into the layers, it starts capturing more complex relationships and context. By the time we reach the final layers, the model has built a rich internal representation of the input sequence.

From there, the process is similar to what we discussed in the previous post. The model takes this refined representation and produces probabilities for the next token. So even though the core task is still next-token prediction, the transformer makes that prediction much more informed by understanding how tokens relate to each other.

One way to think about the transformer is that it allows every token to interact with every other token. Instead of a straight line where information flows from left to right, it creates a fully connected view of the sequence. This is why it works so well for language, where meaning often depends on relationships between words that may be far apart.

At this point, it’s important to remember something we’ve said before. Even with all this complexity, the model is not actually “understanding” language the way humans do. It is still working with numbers and patterns. What the transformer gives us is a much better way to capture those patterns, especially when context matters.

If you connect this back to the earlier posts, the full picture becomes clearer. We start with tokens, feed them into the transformer, use attention and layers to build relationships, and finally produce probabilities for the next token. That output is then sampled and added back into the sequence, and the process repeats.

So while the behavior of ChatGPT might feel complex from the outside, the core idea remains consistent. It is still predicting the next token, one step at a time. The transformer is simply the reason those predictions are so good.

Simple network architecture, the Transformer Link for reference

https://arxiv.org/abs/1706.03762

This week I spent some time going through network automation basics. Not deeply, just trying to understand what problem we are actually solving. I was not focusing on tools yet. More on the “why” behind all of this.

I would like to start with one of the scenerio where a retail network with around 500 stores had a full outage during what was supposed to be a routine change.

Everything was managed through CLI. During a security update, an ACL was pushed manually across devices. The configuration itself was not complex, but the order was wrong. A deny all rule was placed before the permit rules.

That was enough to stop traffic everywhere.

At first, it looks like a simple mistake. Someone configured it wrong. But after thinking about it for a while, it did not feel like just a human error. It felt more like a system problem.

Because one small mistake should not be able to take down an entire network like that.

That only happens when the same action is repeated manually across a large number of devices without any real validation in between. The mistake itself was small, but the way it was applied made it big

Where CLI Starts Feeling Uncomfortable

Most networks still run on CLI. Login via SSH , run commands, check output , move to enxt devcie .That is how things are done

But when the number of devices increases, something starts to feel off. Not immediately, but gradually. You spend more time repeating steps than actually thinking about what you are doing. It becomes mechanical.

And the more repetitive it gets, the more it depends on you not making a mistake.

That is the part that does not scale.

It is not about effort. It is about consistency. Doing the same thing correctly, every single time, across hundreds of devices. That is harder than it sounds.

First Thought Was, Just Automate It with Python

Naturally, the next thought was scripting.

Connect to devices, send commands, capture output. It feels like a direct upgrade from CLI. Same workflow, just automated.

This is probably why most people start here. It feels familiar and you can get something working quickly.

But after looking into it a bit more, there is something slightly uncomfortable about it.

You are still dealing with text.

The commands are text. The output is text. Everything depends on how that text looks.

And that is not stable.

A small change in output format can break everything. The information is still there, just displayed differently. That is enough for parsing logic to fail.

I had not really thought about this before. From a human perspective, the output still makes sense. From a script’s perspective, it can completely break.

So now instead of manually checking output, you are writing logic to interpret it. Which adds another layer that can go wrong.

It works, but it does not feel reliable when you think about scaling it.

APIs Felt Cleaner, But Took Time to Click

Then I looked at NETCONF and RESTCONF.

At first, it was not immediately clear why this was better. It just looked like another way of doing the same thing.

But after spending some time with it, the difference started to make sense.

Instead of sending commands, you are sending structured data. Instead of parsing output, you are receiving structured responses.

JSON or XML.

This changes things in a better way.

You are no longer guessing where the data is. You are accessing it directly.

Error handling also becomes clearer. You are not searching for keywords in output, you are reading defined responses.

It feels more predictable.

Still, not everything is available via API. So CLI does not disappear. It just becomes one option among others.

Ansible and Terraform Were Not Obvious at First

This part honestly took me some time. Because it is not just a tool difference. It is a thinking difference.

Earlier the approach was always step by step. Run this command. Then this. Then check. Now it becomes something else. You define what should exist.

For example, instead of writing steps to create a VLAN, you just say VLAN 10 should be there.

The system figures out whether it needs to create it or not.

This felt strange initially. I kept thinking in steps, so this did not click immediately.

But after a while, it started to make sense.

You are not managing execution anymore. You are defining intent.

There is also this concept of idempotency, which sounds complex but is actually simple.

Running the same thing again should not change anything unnecessarily.

That turns out to be very important when you are dealing with repeated operations.

Terraform goes a bit further.

It keeps track of what already exists and compares it with what you want. Then it calculates what needs to change.

That makes things more predictable. You can see changes before applying them.

It feels closer to managing a system rather than running commands on devices.

Controllers Felt Powerful, But Also Slightly Distant

Then I looked at controller-based platforms.This is where you stop thinking about devices directly.

You define something like creating a network across multiple locations, and the system handles the rest.

This looks powerful, especially at scale.But it also feels a bit distant from what is actually happening underneath.

You are relying on the platform to do the right thing.

And while that works for standard use cases, I am not sure how it behaves in edge scenarios.

There is also dependency on the vendor, which changes how flexible your setup is.

So it feels useful, but not something that replaces everything else.

What I Thought Initially vs What I Think Now

Initially, I was trying to figure out which tool is best. That question does not really make sense anymore.

Each approach solves a different part of the problem.

→ CLI is simple but fragile at scale
→ Python scripting gives control but depends on parsing
→ APIs make things structured
→ Ansible and Terraform improve consistency
→ Controllers simplify large environments

It is not about picking one.

It is about understanding where each one fits.

What Actually Stayed With Me

Automation, at least from what I understand now, is not about doing things faster.

It is about making sure the same thing happens correctly every time.

Especially when the system grows.

What I Am Doing Next

Right now I am not jumping into complex automation setups.

Still trying to get basics right. Python network fundamentals
simple scripts

Trying to understand things properly before layering more complexity.

Closing Thought

I am still figuring things out. But one thing feels clear.

Manual processes do not fail immediately. They fail when they scale.

LLMs for Engineers — Part 4

So far in this series, we’ve talked about where the data comes from and how text gets converted into tokens.

That gives us the raw ingredients, but it still doesn’t explain the most important part how the model actually learns from all of this and how it ends up generating responses that feel surprisingly intelligent. If you strip everything away, what remains is a very simple objective, but one that becomes incredibly powerful at scale . The model is trained to predict what comes next.

To understand this properly, it helps to change how you think about the data. Instead of imagining documents, web pages, or structured knowledge, it’s better to think of the entire training dataset as one long continuous stream of tokens. There are no real boundaries in the way the model sees it is just sequences of numbers flowing endlessly.

In large systems, this stream can be on the order of trillions of tokens, but conceptually, it’s just a sequence where each token follows another. The model’s job is to observe this stream and learn the patterns that govern how tokens tend to follow each other.

Now imagine we take a small slice of this stream. For example, something like “router sends data packet”.

[router, sends, data, packet]

This slice is what we call the context. The training task is surprisingly straightforward: given this context, predict the next token. In this case, a reasonable continuation might be “forward”.

But instead of directly outputting the word “forward”, the model produces a probability distribution over all possible tokens in its vocabulary. So it might assign a higher probability to “forward”, a slightly lower probability to “drop”, and smaller probabilities to many other tokens. At the beginning of training, these probabilities are essentially random because the model hasn’t learned anything yet.

At this point, it helps to pause and visualize what is actually happening. The entire learning process can be reduced to a simple flow a sequence goes in, probabilities come out, and the model moves toward the correct answer.

If you look at the diagram, you can see exactly what we just described. A sequence of tokens such as “router sends data packet” is fed into the neural network, which then produces probabilities for the next token. The correct answer in this case “forward” is already known from the dataset, and the model is adjusted so that its probability increases. This process is repeated over and over again, across massive amounts of data, gradually shaping the model’s internal parameters.

This is where the learning actually happens. Since we already know the correct next token from the dataset, we can compare the model’s prediction with the actual answer. If the model assigned a low probability to the correct token, we adjust its internal parameters slightly to increase that probability and decrease the probabilities of incorrect tokens. The adjustment itself is very small, almost negligible in isolation, but when you repeat this process across millions of sequences and eventually trillions of tokens, the model begins to capture meaningful structure in the data.

What’s important here is that the model is not learning rules in the traditional sense. It is not explicitly told that routers forward packets or that certain facts must always hold true. Instead, it is learning statistical relationships between tokens based on how frequently they appear together. If a particular sequence shows up often enough, the model encodes that relationship into its parameters. Over time, these relationships become strong enough that the model’s predictions start to look intelligent, even though they are fundamentally based on probabilities.

If we look inside the model, things become more mathematical but not necessarily more mysterious. At its core, the model is simply a function that maps input tokens to output probabilities. Internally, this involves a series of matrix multiplications, additions, and nonlinear transformations applied across many layers. The behavior of this function is controlled by its parameters often billions of them which are adjusted during training. You can think of these parameters as knobs that are gradually tuned so that the model produces better predictions over time.

Once training is complete, the model stops learning and switches to what we call inference, which is what happens when you interact with it. Suppose you type “router sends data”. The model processes this input and predicts a probability distribution for the next token. It might assign high probability to “packet”, but instead of always choosing the highest probability token, the model samples from this distribution. This introduces a controlled amount of randomness, allowing the model to produce more varied and natural responses.

Again, it helps to visualize what is happening during generation. The diagram shows this process clearly. Instead of updating the model, we now repeatedly feed the growing sequence back into the network and sample one token at a time.

Each step looks simple in isolation, but together they form a loop. The model takes the current sequence, predicts the next token, appends it, and then repeats the process. So “router sends data” becomes “router sends data packet”, then “router sends data packet forward”, and so on. What looks like a complete sentence to us is actually built one token at a time through this iterative process.

This also explains many of the behaviors people observe when using models like ChatGPT. Because the model is generating text based on probabilities rather than verifying facts, it can sometimes produce outputs that sound confident but are incorrect. Similarly, because sampling introduces randomness, the same input can lead to slightly different outputs on different runs. These are natural consequences of how the system works, not anomalies.

One useful way to think about the model is as a compressed representation of the data it was trained on. It doesn’t store exact copies of the internet, but it captures patterns in a highly condensed form within its parameters. When generating text, it reconstructs these patterns in new combinations, which is why it can produce both familiar and novel outputs.

If there’s one idea to take away from all of this, it’s that ChatGPT is fundamentally a next-token prediction system operating over sequences of tokens. Everything else the fluency, the apparent reasoning, and the usefulness emerges from this simple mechanism applied at massive scale. Once you internalize this, many of the behaviors of large language models start to make much more sense.

In the next post, we’ll build on this foundation and explore how a base model, which is essentially just a next-token predictor, gets transformed into something that behaves like an assistant — following instructions, answering questions, and interacting in a helpful way. That’s where alignment and post-training come into the picture, and it’s what turns a raw model into something like ChatGPT.

Smiles :)

Anurudh

LLMs for Engineers — Part 3

Welcome back to our LLM Journey. If you are new to here , don’t miss to check previous posts before diving into this post.

So far, we’ve seen:

• ChatGPT predicts the next word

• It learns from internet-scale data

Most of us assume that AI reads text the same way we do. We see words, sentences, and meaning. So it’s natural to think that models like ChatGPT also process language in a similar way.

But that’s not what’s happening at all.

In fact, the model doesn’t see words. It doesn’t see sentences either. What it actually sees is something much more basic numbers.

To understand this properly, it helps to zoom in a bit.

Take a simple sentence like “router sends data”. When you read it, you instantly understand what it means. But a computer can’t work with text directly. The first thing it does is convert everything into a numerical form. At the lowest level, this means turning characters into bytes, and bytes into numbers. So even before we talk about AI, the sentence is already transformed into a long sequence of numbers.

Now here’s the problem. If we keep everything at the character or byte level, the sequence becomes very long and inefficient. And in models like these, sequence length matters a lot. Longer sequences mean more computation, more cost, and slower processing. So we need a better way to represent text.

This is where tokenization comes in.

Instead of working with individual characters, the model groups pieces of text into units called tokens. You can think of tokens as chunks of text that are more efficient to work with. Sometimes a token is a full word, sometimes it’s part of a word, and sometimes it even includes spaces or punctuation.

For example, the sentence “router sends data” might be broken into tokens like:

[router, sends, data]

Each of these tokens is then mapped to a unique number. So what the model actually sees is not the words themselves, but something like:

[1532, 8471, 2983]

These numbers are just IDs. They don’t carry meaning by themselves. They are simply a way to represent text in a format the model can process.

At this point, it might feel like we’re losing information, but we’re actually making things more efficient. By using tokens, we reduce the length of the sequence while still keeping important patterns intact. Common patterns like “data”, “packet”, or “forward” can become single tokens, while rare or complex words can be broken into smaller pieces. This balance is what makes tokenization powerful.

A natural question here is: how does the model decide what becomes a token?

The idea is surprisingly simple. We look at large amounts of text and find patterns that appear frequently. If certain combinations of characters show up again and again, we merge them into a single token. Over time, this builds a vocabulary of tokens that covers common patterns in language. This process is often done using methods like Byte Pair Encoding, but you don’t need to worry about the details. The key idea is that tokens are designed to make text both compact and flexible.

If you want to really understand this, it helps to try it yourself once.

Go to:

👉

https://tiktokenizer.vercel.app/?model=cl100k_base

Type something simple like “router sends data”.

Now try small changes. Add an extra space. Change the case. Add punctuation. You’ll notice that the tokens change. Sometimes even a tiny change in text leads to a completely different token sequence.

This is an important moment.

Because what you type is not what the model sees.

The model only sees tokens.

That means when you change your prompt even slightly ,you are actually changing the sequence of tokens going into the model. And that can change the output.

This explains a lot of things people notice when using AI. Why small wording changes affect responses. Why formatting matters. Why sometimes adding or removing a word changes everything. It’s all happening at the token level.

If you like networking analogies, you can think of this like packetization. Before sending data over a network, we break it into packets. Here, before feeding text into a model, we break it into tokens. The model doesn’t see the original message it sees the encoded form.

So when you write a prompt, you’re not really writing for a human. You’re designing a sequence of tokens for a machine.

And that sequence is what drives everything that comes next.

In the next post, we’ll build on this idea and see what the model actually does with these tokens. Because once text becomes tokens, the next step is where the real magic — or more accurately, the math — begins.

LLMs for Engineers — Part 2

In the last post, we uncovered something surprising:

ChatGPT is just predicting the next word.

When people first hear about ChatGPT, one of the most common questions is this: where does it actually learn all of this from? It can answer questions, explain concepts, write code, and even sound conversational. So it’s natural to assume there must be some kind of structured knowledge base behind it.

But that’s not really how it works.

At its core, the model learns from a massive amount of text data. Not neatly organized knowledge, not curated lessons, but raw text collected from across the internet. This includes things like articles, blogs, forums, documentation, and code. The idea is simple — if you expose a model to enough examples of how language is used, it can start picking up patterns. And once it learns those patterns, it can generate similar text on its own.

But this doesn’t mean the model is just blindly copying the internet. The process is more structured than that.

A large part of this data comes from datasets like Common Crawl, which has been collecting web data for years. You can think of it like a system that starts from a set of websites, follows links, and keeps collecting content along the way. Over time, it builds a huge snapshot of the web. But this raw data is messy. It contains everything —useful content, ads, broken pages, scripts, and a lot of noise.

So before any training happens, this data goes through heavy cleaning.

At this point, it helps to think about what we actually want the model to learn from. If we feed it entire web pages as they are, it will learn patterns from things we don’t care about navigation menus, pop-ups, or random scripts. That’s not useful. So the first step is filtering out bad or irrelevant sources. Websites that are spammy, unsafe, or low quality are removed early on.

Once that is done, the next step is extracting the main content. This means stripping away all the extra parts of a webpage and keeping only the meaningful text. If you’ve ever used a “reader mode” in your browser, it’s a similar idea. We only want the actual content, not the surrounding clutter.

After that comes language filtering. Since most large models are trained primarily on English, the system checks whether the text is mostly in English. If a page doesn’t meet a certain threshold, it might be excluded. This step directly affects what languages the model becomes good at.

Then comes deduplication, which is more important than it sounds. The internet has a lot of repeated content copied articles, mirrored pages, or slight variations of the same text. If the model sees the same thing again and again, it doesn’t learn anything new. So duplicates are removed to make the dataset more useful.

Finally, there is filtering for sensitive information. Things like personal data, phone numbers, or credit card details are removed. This step is important for safety and privacy.

If you step back and look at all this, the process is actually quite logical. We start with a huge amount of raw data, then clean it step by step until we are left with mostly useful text. What remains is not perfect, but it’s good enough for the model to learn patterns from.

Even after all this filtering, the dataset is still enormous. We are talking about tens of terabytes of text. That’s far beyond what any human could read in a lifetime. And that scale is what makes these models powerful. The more data they see, the better they get at capturing how language works.

But here’s an important point that is easy to miss.

The model is not learning facts in the way we think. It is not storing information like a database. Instead, it is learning patterns in how words and sentences are used. If something appears frequently in the data, the model becomes more likely to generate it. If something is rare or inconsistent, the model is less confident about it.

So when you ask a question, the model is not retrieving an answer from memory. It is generating a response based on patterns it has learned from all this data.

That’s a subtle but very important difference.

You can think of this entire process as building the “experience” of the model. Just like humans learn language by reading and listening over time, the model learns by seeing massive amounts of text. The difference is scale ,the model sees far more data than any human ever could.

And this is just the first stage.

Because even after learning from all this data, the model is still not ChatGPT yet. It has learned patterns, but it doesn’t know how to behave like an assistant. That part comes later.

In the next post, we’ll zoom in further and understand how this text is actually represented inside the model. Because before the model can learn patterns, it needs to convert everything into a form it can work with.

And that’s where tokens come in.

Smiles :)

Anurudh

Subscribe now

LLMs for Engineers — Part 1

When you first use ChatGPT, it feels a bit strange.

You ask a question, and it replies almost instantly. Not just with random text, but with something that feels structured, confident, and often surprisingly accurate. It explains things clearly, writes code, fixes errors, and even sounds conversational.

At some point, a natural question comes up.

👉 What is actually going on behind this?

Is it thinking?
Does it understand what I’m saying?
Is there some kind of intelligence inside?

The surprising answer is… not really.

Or at least, not in the way we usually think about intelligence.

What ChatGPT is doing at its core is much simpler than it appears. It is not searching the internet in real time. It is not looking up answers in a database. And it is not reasoning like a human sitting across from you.

Instead, it has learned patterns from a massive amount of text and uses those patterns to generate responses. In fact, one of the simplest ways to describe what it does is this:

👉 It tries to predict what should come next in a piece of text.

That’s it.

Now this might sound almost too simple.

How can something that just “predicts the next word” write essays, explain concepts, or answer questions?

The answer lies in scale.

The model has seen an enormous amount of text articles, documentation, conversations, code, and more. Over time, it has learned how language usually flows. So when you give it a prompt, it doesn’t “think” about the answer. It continues the pattern in a way that looks correct.

You can imagine it like this.

If you had read millions of examples of how people explain something, you would also get very good at continuing those explanations. You might not know the exact source of every fact, but you would still be able to produce something that sounds right.

That’s roughly what’s happening here.

This also explains something important.

Sometimes ChatGPT gives answers that sound very confident… but are not fully correct. That’s because it is not verifying facts. It is generating what is most likely to come next based on patterns it has learned.

So in a way, you are not talking to a system that “knows” things.

You are interacting with a system that is very good at producing language that looks like knowledge.

At this point, things start to look different.

It stops feeling like magic and starts feeling like a system with a very specific behavior.

And once you see it this way, a lot of things begin to make sense:

• why small changes in prompts change the output

• why it sometimes makes mistakes

• why it can sound intelligent without actually understanding

But this is just the surface.

Because now the real questions begin:

👉 Where did it learn these patterns from?
👉 How does it even read text?
👉 What is happening inside when it generates a response?

That’s exactly what we’ll explore in this series.

We’ll break this down step by step, starting from the data, then tokens, then prediction, and finally what’s inside the model itself.

By the end, you won’t just use ChatGPT.

👉 You’ll understand how it works.

Next in this series

👉 Where ChatGPT actually learns from

Smiles :)

Anurudh

But i am more interested to know the behind the scenes , actually how the overall system is working.How they actually helps us to think grow and learn !!

That is what i generally put in GrowAIth.

The noise problem

Right now, AI content is everywhere.

There is so muss fuss about AI everywhere.

new Models , new Prompts ,New 10X claims !!!

But very little of it explains

• What problem is actually being solved

• Why a technique works

• Where AI fits in real work

The result is noise.

You can consume a lot and still feel unsure about what you really understand.

The approach I want to take

GrowAith is my attempt to slow things down.

Instead of chasing updates, I want to focus on:

• Understanding core ideasbehind AI and systems

• Breaking concepts into clear mental models

• Writing what I’m learning, as I’m learning it

Think less “AI hacks” and more:

How does this actually work, and why does it matter?

What I’ll be writing about

Here’s the rough direction:

AI fundamentals

Not tutorials first but concepts that make tools easier to understand.

Systems thinking

Learning from networks, automation, and engineering .

Learning in public

My Notes, explanations, and mistakes.

Practical takeaway

Each post should leave you with at least one clear insight.

This won’t be perfectly structured from day one and that’s okay.

Who this is for

GrowAith is for:

• Engineers and builders

• Curious learners

• Anyone tired of shallow explanations

If you enjoy thinking slowly and clearly, you’ll probably enjoy what I write here.

A simple promise

I won’t write to impress.

I’ll write to understand

And if something helps me think better, I’ll share it here.

That’s the idea behind GrowAith.

Key takeaway

This publication is about clarity over speed and understanding over hype.

If that resonates, welcome aboard.

Anurudh

Let’s unpack this in plain language.

Not Understanding — Predicting

When most people talk about AI — especially generative models — they assume the system understands like a human does. That’s not true.

Generative AI is trained on huge amounts of data and then uses statistical patterns to generate new content. It’s not thinking. It’s not reasoning. It is incredibly good at predicting what comes next based on patterns it has seen before.

If you ask it to write an essay, it doesn’t sit down and think about ideas — it predicts word patterns that make sense based on training data. If you ask it to generate an image, it doesn’t imagine like a person — it stitches together elements that look right together in the data it saw during training.

Generative AI in Practice: A Different Kind of Collaboration
So what is it really good at?

It can produce new artifacts — text, music, images — that look original.But this “originality” is really a recombination of patterns it has already seen. It’s creativity without consciousness, intuition, or intent.

So Why All the Hype?

Because humans are pattern-seekers too. We look at outputs that seem cohesive and pretend the machine has internal understanding. That’s not just inaccurate — it’s dangerous.

Hype focuses on what AI looks like it can do, not what it actually can do.

This leads us to two common pitfalls:

❌ Believing AI is a thinking partner

AI doesn’t think, it predicts.

❌ Assuming it’s always correct

Pattern prediction can still be flawed , biased or incorrect ,especially if the training data is poor or incomplete.

What Really Matters

Here’s the insight most people miss:

Generative AI is a mirror — not a mind.
It reflects patterns from provided data ,not understanding from experiance.

This distinction matters because it defines how we should use it:

It’s great for augmentation -summarizing, drafting, pattern spotting.

It’s not a substitute for expert judgment or contextual reasoning.

As professionals - whether in tech, products, analysis, or decision-making — this should be our lens:
We don’t ask what AI can generate.
We ask what patterns we should trust, and why.

Final Thought

The beauty and the risk of generative AI aren’t in what it outputs.
They’re in how people interpret those outputs.

If you chase the pattern - the shiny result-you’ll be distracted by noise.
If you chase the meaning beneath the pattern - that’s signal.

Subscribe now

Let’s Bring It Into Networking

This is where it gets interesting for us.

Say you’re managing a large network — multiple sites, lots of routers, switches, logs , lot of support tickets.

Now imagine Gen AI trained on your own environment — logs, past tickets, config files, SNMP data, etc.

Here’s what it can do.

Example: Automatic RCA Report with Gen AI

Problem: You see packet loss in Region X. Alerts come in.
Old Way: You log in, check logs, dig through past incidents, prepare RCA. Hours gone.

With Gen AI:
You just type below prompt:

"Generate RCA for packet loss on Router R2 at 4PM in Region X"

And it replies:

"Packet loss caused due to MTU mismatch post-software upgrade on R2. Similar problem on 14 Mar & 3 June. Recommend audit + MTU compliance check."

Straight to the point.

⏱️ Time saved: Big
📄 Consistency: High
📚 Backed by actual data: Yes

There are so many other case too , like config generator ,capacity manangment ,audit repot etc.

Why It Works for Us

• It handles logs, tickets, config — all the messy stuff

• It finds patterns we may miss

• It can explain things, not just detect

• It keeps getting better with feedback

Final Words

Generative AI is like a team member that doesn’t sleep. You give it data, it gives you solutions.
You ask for help, it explains. It’s not perfect — but it’s fast, useful, and always learning.So don’t think of it as a threat.
Use it as a tool — to save time, reduce noise, and work smarter.

Multicloud is now new normal for Network engineer.

When it comes of AI workload , Companies are no way interested to bet on single cloud provider ,they prefer multi cloud option and for good reason .Reason is simple no one cloud is best on everything

💡 Why Go Multi-Cloud for AI?

Each cloud provider has its own strength

• One might be excellent in providing top tier AI/ML service

• Another might be good in serverless compute

• Third may be providing good pricing as compared to others

So its now the cloud architect task to pick the best provider considering all below points.

• Better uptime and distory recovery

• Dependability on one vendor

• Flexibility and more power while renewing the contract

• Most importantly meeting data residency & sovereignty laws

❓ Is It Common for AI Workloads?

While multicloud is now standard in many IT companies but still less common for AI training Why ?

• Training models is very resource-intensive

• Highly Optimized on a single cloud or even on premises

• Often involves massive datasets which is more expensive to move across clouds.

But once the model is trained...

• Inference (making predication) is less resource intensive

• Can be deployed closer to user

• Reducing latency and providing better user experience.

That’s why inference workloads (predications) are more likely to be spread across clouds.

💾 Managing Data in a Multi-Cloud World

AI workloads run on data—and lots of it.

Managing that across clouds? Needs solid strategy. Here’s a breakdown:

• Portability & Interoperability

  Keep data in sync across clouds using available tools like AWS DataSync.

• Smart Storage Strategies

  Localize storage near compute to reduce data transfer latency

  Hybrid storage(on prem+cloud) offers flexibility and compliance benefits

• Data Consistency

  Use distributed database and leverage available synchronization tools to keep data up to date and accurate across cloud

• Security & Compliance

  Encrypt data in transit and at rest.

  Use governance tools for compliance and auditing

• Cost Optimization

  Use compression

  Avoid unnecessary cross-cloud movement

  Use fast storage for active data wheras cheap storage for archived data.

🔍 Final Thought

Multi-cloud AI isn’t just a trend—it’s a smart, strategic move if done right. But it requires planning, the right tools, and a mindset focused on portability, security, and efficiency.

Container - It’s word that pops up everywhere right ? May be you have gone through few youtube videos .Many of them decent and good jobs explaining concept but here, I want to explain containers in a way that’s super simple, natural, and easy to relate and most importantly, these are my own notes as I’m learning this myself, and as I do, I want to make sure I learn and share along the way.

🚦 The Real-World Problem

Why we even need to know or care about container ?

If you have worked in deveolpment or IT operations, you might be aware of struggle

• The code works perfectly in ppe enviornemnt or on deveoplers own machine

• As soon as code is pushed on production ? Error , crash , mismatch some or other issue

  This disconnet between Dev and Ops is frustrating — it’s sometime costly for companies .And even it today’s exponentially growing tech , its not expected move slow or break things in production. . So what’s the fix ?

  📦 Enter Container-Based Architectures

  We can say Container is solution of the problem . It packages everything application needed - the code , the runtime, libaries and dependencies —- into a single unit .Thus making apps:

• Easily to deploy

• Easier to Update

• Easier to run on any machine

🧱 From Monolith to Microservices

Let’s look at architecure now →

• On the left, you have a traditional way (Monolithic) — all parts of the application bundled together (…all one big block).

• On the right, you split that into smaller services ( Microservcies )— each one running independently in its own container .

Why this is awesome:

• You can scale each part separately.

• You can update one service without touching the others.

• You can deploy services faster and with fewer errors.

Deployment Models: Bare Metal → VMs → Containers

We had bare Metal , VMs then whey there was need of Container .Lets see difference of all three in simplastic way :

Bare Metal

Apps runs directly on the OS . One change or update has potentail to break everything .Its headache for Dev /OPS to troubleshoot or update

Subscribe now

Virtual Machines

Apps now run inside a full virtaul OS .Its more stable but use lot of resourse and is bit slow to start .Each VM can be servaral GBs in size .

Containers

APps shre the Host OS but are completed isolated to each other .Container starts in second and use less resourse .Its portable ,easy to move scale and replicate.

USP — > One container = One service = Super clean and efficient

🧠 How Containers Work

Imagine a container like a lightweight box that holds your application code , all dependencies it need to run and contains seetinga nd config file.

Now, imagine these containers running on your system, isolated but lightweight — just like you ahve multiple apps installed on your phone.

Technically speaking:

• Containers run in a namespace — a sandboxed space on the host OS.

• They behave like mini virtual machines, but they’re just regular processes.

• They share the host’s kernel but are managed separately.

⚙️ Why Developers and Engineers Love Containers

• Fast to Start: Seconds, not minutes

• Clean Deployments: No leftover or conflicts

• Repeatable: “It works on my machine” becomes “It works everywhere”

• Composable: Build systems from plug-and-play components

• Scalable: Quickly spin up more containers during high demand

🧰 Example Tools and Features in the Container Ecosystem

• Docker – The most popular tool to create and manage containers

• Docker Compose – To define multi-container setups

• Kubernetes – For large-scale orchestration

• Monitoring & Telemetry – Containers can be monitored app-wise, not just machine-wise

🧪 For Network Engineers: Why It Matters

Containers aren’t just for app developers — they’re changing network automation too:

• Run various tools like NetBox, or custom scripts in containers

• No OS dependency: works on Linux, Mac, or Windows

• Spin up test labs, tools, or dashboards in seconds

• Extend network devices with containerized apps — safely and easily

🔚 Wrapping It Up

Containers are transforming how we build, deploy, and scale applications. They’re:

• Lightweight

• Fast

• Isolated

• Portable

Whether you're a developer, a DevOps engineer, or even a network engineer, learning Docker and containers will level up your game.

Last week, I was watching a random AI video on YouTube when a thought struck me:

What if AI actually had a important role in networking industry?

This post is the outcome of that thought and bit reserach .

I’ve written a lot of Ansible playbooks recently.

Honestly, it felt magical at first. Push changes across routers with a single play — amazing.
But over time, something about it didn’t sit right.

I kept asking myself: Is this really automation? Or just scripted execution?

The Realization

The more I automated — using Ansible, Python, and even some in-house tools — the more I saw the issue.

Yes, configs got pushed faster. But if something went wrong ?
Manual digging. Logs. Debugs.
No real “Brain” in the system.

It was like teaching a robot to follow steps, but not think.

And then AI started buzzing everywhere. ChatGPT, co-pilots, LLMs...

And the question hit me hard:

What if the system could understand what I want — not just what I tell it?

Subscribe now

What If I Could Say…

“Add a static route for 10.1.1.0/24 via 192.168.1.1 on router R1.”

That’s it.

No YAML. No template variables. Just the intent.

And the system should know:

• Which router R1 is

• What the current config looks like

• Whether that next hop is reachable

• And apply the change safely

Right now, its not a dream. But AI is making it possible.

Where Automation Falls Short

Let’s be honest.

Automation is great. But it:

• Doesn’t understand intent

• Can’t read the network’s topology or policy dependencies

• Doesn’t explain logs

• Doesn’t help you write documentation (which we all love to skip)

• And grows harder to maintain the more scripts you have

We’re building bigger toolboxes — but not necessarily smarter ones.

How AI Can Help

I don’t think AI will replace us. But it’s already helping.

Tools like GPT can:

• Turn natural language into starting configs

• Draft validation logic for pre/post checks

• Generate parts of LLDs

• Parse log outputs and summarize them

And yes — even generate diagrams or mind maps based on device configs.

The One Thing We Always Skip

Documentation.

We all hate it. Most of us leave it to the last minute (or never).
But when something breaks — it’s the first thing we wish we had.

AI can:

• Summarize LLDs

• Highlight change impacts

• Auto-generate diagrams

• Keep things up to date when the network changes

It saves hours of writing and backtracking.

So What’s the Future Look Like?

A hybrid world.

• CLI + YAML + Prompts + AI + Human judgment.

• Systems that suggest. Engineers that decide.

• AI that writes the first draft, and we finalize it.

The goal isn’t to remove engineers.
It’s to remove the repetition — and free us to focus on what matters.

I believe the best network engineers of the in future won’t just configure routers — they’ll Join Hands with AI to design, test, and troubleshoot smarter than ever before.

Smiles :)

Anurudh

You have got big warehouse, drivers and a road connecting to all destinations.

🧠 Compute: The Brains — or the Drivers on the Road

Compute layer is like team of drivers ground around, moving packages (data) from Point A to Point Z.

CPU are all purpose vans -- they can handle anything but aren't used for speed delivery.

GPU are the specialized trucks that carry huge volume fast -- Built for heavy duty tasks lets say like training neural network

RAM That is essential part that every driver need like dashbaoard in front of hime

NICs Think of its like high-speed lanes of tunnels that helps you bypass traffic and get to destination faster

Why the love with GPUs lately? Because AI training isn’t normal — it’s like moving large chunk of data around.

GPUs are wired to handle that kind of workload efficiently, with thousands of cores working in parallel.

Some systems stack up 8, 16, even more GPUs in a single server — all linked with ultra-fast NICs pushing speeds up to 800 Gbps.

That’s not a typo. We're talking about transferring entire libraries worth of data in the blink of an eye.

📦 Storage: Your Warehouse System

Now, where do all those packages come from? Right — the warehouse.

In AI, storage plays that role. But it’s not just about capacity. It’s about speed. If your drivers are sitting around waiting for boxes to load, your whole system slows down.

SSDs are the fast-loading bays — perfect for handling large datasets quickly.

InfiniBand with RDMA? It’s like teleporting data straight to the truck, skipping the harder task. (in our case the CPU). Again this itself is very big topic and will love to come with post specfically to InfiniBand with RDMA.

IP-based storage is more plug-and-play. Maybe not the fastest, but it works well with what most systems already have.

And distributed storage spreads data out, so there's no single point of failure. It's like having multiple warehouses stocked with the same inventory — so if one goes down, another picks it up.

Subscribe now

🌐 Networking: The Road System That Connects It All

Networking is the glue. Or, sticking everything together, it's the actual road system your fleet depends on.

Most AI data centers use something called spine-leaf architecture:

Leaf switches connect directly to compute nodes — the endpoints.

Spine switches tie everything together, making sure data can flow across the entire network without bottlenecks.

If that sounds technical, think of it like this: it's a carefully designed freeway system with enough lanes to handle rush hour — or in this case, petabytes of data moving in real time.

And to keep things moving? Engineers tweak the subscription ratio — the balance between how many compute nodes share bandwidth and how much is actually available. Get it wrong, and things slow down. Get it right, and data moves so efficiently it barely feels like it’s traveling at all.

🔧 When Everything Clicks

Put all of this together — compute that’s optimized, storage that’s fast and accessible, and networking that keeps things flowing — and you’ve got an AI infrastructure that can scale to almost anything.

That’s what powers:

It’s not about any one component. It’s how they all work together.

Smiles :)

Anurudh

Welcome back to our Ansible Mastery Journey. If you are new to here , don’t miss to check previous posts before diving into this post.

We have already discussed how ansible is used to automate infrastructre .right ?

We right playbooks to handle config and much more .But sometimes these playbooks need senstive information —password API tokens, Licence key ,SSH Keys —Stuff that you dont want to be in plain text.

Now imagine pushing those playbook to Github or Gitlab , may be due to need of collabaration with others. If you just drop your secrets into the YAML as plain text , bascially you are taking risk and sharing your secrets with the world.

🔒 What is Ansible Vault?

Think of Ansible Vault as a password protected envelope for your YAML content . You can encrypyt either:

• Entire files

• Or just individual variables.

This way we can safely version control playbooks with senstive data in locked condition.

🧪 Step-by-Step: Encrypting a File

Let’s say we have critical_data.yml file which has api and licence key

((venv) ) anurudh@localhost:~/Ansible_Network_Engineer$ cat inventory/critical_data.yml 
---
 api_key: Cisco@123
 licence_key: abcdef
((venv) ) anurudh@localhost:~/Ansible_Network_Engineer$ 

Let’s Encrypt it :

ansible-vault encrypt ./inventory/critical_data.yml 

It will ask for vault password- choose one and remember. You will need it to decrypt file later

((venv) ) anurudh@localhost:~/Ansible_Network_Engineer$ ansible-vault encrypt ./inventory/critical_data.yml 
New Vault password: 
Confirm New Vault password: 
Encryption successful
((venv) ) anurudh@localhost:~/Ansible_Network_Engineer$ 

The contents are now encrypted. ✅

((venv) ) anurudh@localhost:~/Ansible_Network_Engineer$ cat inventory/critical_data.yml 
$ANSIBLE_VAULT;1.1;AES256
3764346265303562323837363163663030636231373665343763366339343064346331323066638
3035336434306331366230306361396465333635363739300a33373533313238633666666330611
3735616534633434373262343930336136303938303332303136373030313833383739643133361
3032613261666333330a33393431633662623436656538306537336662393838613433383661363
3937653837316337313532353734343432393762346333333636373036353637363032353236306
6438323364373136316432616163396164383564616366653439
((venv) ) anurudh@localhost:~/Ansible_Network_Engineer$ 

Share

🔓 Decrypting the File

To decrypt it when needed:

ansible-vault decrypt ./inventory/critical_data.yml 

📦 Using Encrypted Files in Playbooks

Lets look back at our playbook

((venv) ) anurudh@localhost:~/Ansible_Network_Engineer$ cat ansible_playbook/03_ssh_key.yml 
---
 - hosts: routers
   #gather_facts: false
   vars_files:    
           /home/anurudh/Ansible_Network_Engineer/inventory/critical_data.yml
   tasks:
     - name: Print Ansible Config location 
       ansible.builtin.debug:
        msg: 
        - "{{ ansible_config_file }}"
        - "{{ ansible_user }}"
        - "{{ api_key }}"
        - "{{ license_key }}"((venv) ) anurudh@localhost:~/Ansible_Network_Engineer$  

Let’s run the playbook:

((venv) ) anurudh@localhost:~/Ansible_Network_Engineer$ ansible-playbook ansible_playbook/03_ssh_key.yml 
ERROR! Attempting to decrypt but no vault secrets found
((venv) ) anurudh@localhost:~/Ansible_Network_Engineer$ 

Expected. We will get ERROR! Attempting to decrypt but no vault secrets found

we need to tell Ansible to ask for the vault password:

ansible-playbook ansible_playbook/03_ssh_key.yml --ask-vault-pas

Then provide the vault password, and boom — it works:

((venv) ) anurudh@localhost:~/Ansible_Network_Engineer$ ansible-playbook ansible_playbook/03_ssh_key.yml --ask-vault-pass
Vault password: 

PLAY [routers] ******************************************************************************************************************

TASK [Gathering Facts] **********************************************************************************************************
ok: [r2]
ok: [r1]

TASK [Print Ansible Config location] ********************************************************************************************
ok: [r1] => {
    "msg": [
        "/home/anurudh/Ansible_Network_Engineer/ansible.cfg",
        "ansible_admin",
        "Cisco@123",
        "abcdef"
    ]
}
ok: [r2] => {
    "msg": [
        "/home/anurudh/Ansible_Network_Engineer/ansible.cfg",
        "cisco",
        "Cisco@123",
        "abcdef"
    ]
}

PLAY RECAP **********************************************************************************************************************
r1                         : ok=2    changed=0    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0   
r2                         : ok=2    changed=0    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0   

((venv) ) anurudh@localhost:~/Ansible_Network_Engineer$ 

🤔 Tired of Typing the Password Every Time?

You might have noticed that we have to provide Vault password everytime while running playbook

((venv) ) anurudh@localhost:~/Ansible_Network_Engineer$ ansible-playbook ansible_playbook/03_ssh_key.yml --ask-vault-pass
Vault password: 

Shouldn’t be great if we dont have to provide Vault password everytime?

Lets see how it can be done.

Lets create a vault password file to store the vault password .

In my case i have take vault password as 1234

((venv) ) anurudh@localhost:~/Ansible_Network_Engineer$ cat inventory/vid_pass 
1234
((venv) ) anurudh@localhost:~/Ansible_Network_Engineer$ 
((venv) ) anurudh@localhost:~/Ansible_Network_Engineer$ 

Then update your ansible.cfg:

vault_password_file=/home/anurudh/Ansible_Network_Engineer/inventory/vid_pass

ansible.cfg file for reference

((venv) ) anurudh@localhost:~/Ansible_Network_Engineer$ cat ansible.cfg 

[defaults]
inventory = /home/anurudh/ansible/inventory/cisco_devices
transport = network_cli
#host_key_checking =False  # Disables SSH host key checking
vault_password_file=/home/anurudh/Ansible_Network_Engineer/inventory/vid_pass
 

Now you can run your playbook without --ask-vault-pass:

ansible-playbook ansible_playbook/03_ssh_key.yml 

It picks up the password automatically. Nice.

((venv) ) anurudh@localhost:~/Ansible_Network_Engineer$ ansible-playbook ansible_playbook/03_ssh_key.yml 

PLAY [routers] ******************************************************************************************************************

TASK [Gathering Facts] **********************************************************************************************************
ok: [r2]
ok: [r1]

TASK [Print Ansible Config location] ********************************************************************************************
ok: [r1] => {
    "msg": [
        "/home/anurudh/Ansible_Network_Engineer/ansible.cfg",
        "ansible_admin",
        "Cisco@123",
        "abcdef"
    ]
}
ok: [r2] => {
    "msg": [
        "/home/anurudh/Ansible_Network_Engineer/ansible.cfg",
        "cisco",
        "Cisco@123",
        "abcdef"
    ]
}

PLAY RECAP **********************************************************************************************************************
r1                         : ok=2    changed=0    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0   
r2                         : ok=2    changed=0    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0   

((venv) ) anurudh@localhost:~/Ansible_Network_Engineer$ 

Yes, you have got it !!! We have used now Ansible-Vault feature to encrypt our critcial data. You know, we can go ahead and encrypt even out vault password file ?

I hope you can try even to encrypt vault password file .Its all same as above.

Share Automation

✅ Recap

• Ansible Vault is your built-in secret protector.

• It plays nice with Git and automation pipelines.

• Use it to keep your playbooks clean and your credentials safe.

✅ Action Step for You Today

Try it, break it, automate it.
If you’re doing infra-as-code, this is a must-have tool in your Ansible workflow.

I’ll guide you, one simple post at a time.

We will deep dive more into Ansible in upcoming posts. Don’t miss to DM or ping me with your queries and comments.

Smiles :)

Anurudh

Welcome back to our Ansible Mastery Journey. If you are new to here , don’t miss to check previous posts before diving into this post.

Ever stare at a bunch of IPs and think, "This would be so much easier if these routers had names?" Same. Instead of setting hostnames manually on each Cisco box, here’s a simple way to get Ansible to do it for you. No copy-pasting the same command again and again. Just clean automation.

Let’s get straight into it.

Start With Your Inventory

Open up your hosts.ini file. Here's how I set mine up:

[anurudh@localhost ansible_start]$ cat hosts.ini 

[routers]
1.1.1.1
2.2.2.2

[ios_devices:children]
routers

[ios_devices:vars]
ansible_user=cisco
ansible_password=cisco
ansible_connection=network_cli
ansible_network_os=ios[anurudh@localhost ansible_start]$ 

This tells Ansible: “Hey, we’re working with Cisco IOS gear, here are the devices, and here’s how to log in.”

Make Sure Ansible Knows What’s Up

Next, check your ansible.cfg. You don’t need anything fancy — just make sure it points to your inventory file and uses the right connection method:

Subscribe now

[anurudh@localhost ansible_start]$ cat ansible.cfg 

[defaults]
gathering = explicit
inventory = hosts.ini
transport = network_cli
#host_key_checking = False  # Disables SSH host key checking
[anurudh@localhost ansible_start]$ 

That commented-out line disables SSH key checking — helpful during testing, but use it wisely.

Now the Fun Part: Auto-Generate Hostnames

You don’t want to manually set hostnames like R1111 and R2222, right? Let Ansible do that. Here's a tiny playbook that makes it happen:

[anurudh@localhost ansible_start]$ cat 04_config_hostname.yml 

---
 - name: Configure Hostane on Cisco routers
   hosts: ios_devices
   gather_facts: no 
   
   tasks:
    - name: set hostname based on IP
      cisco.ios.ios_config :
         lines:
            - hostname R{{ inventory_hostname | regex_replace('\\.', '') }}
            
[anurudh@localhost ansible_start]$ 

What’s happening here?

• inventory_hostname is the IP of each device.

• The regex_replace('\\.', '') bit strips out the dots.

• So 1.1.1.1 becomes R1111. Neat, right?

Let’s See It in Action

Run the playbook like this:

[anurudh@localhost ansible_start]$ ansible-playbook  03_ping_router 

PLAY [check connectivity to cisco routers] *************************************************

TASK [ping the router] *********************************************************************
ok: [1.1.1.1]
ok: [2.2.2.2]

PLAY RECAP *********************************************************************************
1.1.1.1                    : ok=1    changed=0    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0   
2.2.2.2                    : ok=1    changed=0    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0   

[anurudh@localhost ansible_start]$ 

Once it runs, SSH into your devices to confirm the hostname stuck:

[anurudh@localhost ansible_start]$ ssh cisco@1.1.1.1
(cisco@1.1.1.1) Password: 

R1.1.1.1#exit
Connection to 1.1.1.1 closed.
[anurudh@localhost ansible_start]$ ssh cisco@2.2.2.2
(cisco@2.2.2.2) Password: 

R2.2.2.2#

If you see that hostanme R111 for router 1 and R2222 for router 2, congrats — it worked.

Recap

• You learned how to build hostnames from router IPs

• You used Jinja2 to clean them up

• You pushed config with Ansible

• You did it without repeating yourself 50 times

If you’ve got more routers to name, this setup will save you hours. Add this to your playbook toolbox — you’ll use it again.

Action Step for You Today

Just one thing: make sure to go through the concepts and follow along with the tasks.

I’ll guide you, one simple post at a time.

Buy Me A Coffee

We will deep dive more into Ansible in upcoming posts. Don’t miss to DM or ping me with your queries and comments.

Smiles :)

Anurudh

In this post , we will talk about “How AI Learns”

• Supervised Learning :How we train machine with example with correct answer

• Un Supervised Learning: How Machine finds hidden pattern when provided with unlabeled data

• Reinforcement Learning :How machine leans by trying things out using feedback

🔍 Supervised Learning :Teaching Machine With Example

Its basically to teach a machine using examples that already have a answers. So we teach model with real example with both input and the correct answers. Over the time ,it starts to get in.

Supervised learning is like teaching someone with flashcard.

Imagine this:

You are sitting with kid showing him flash card of shapes. Each flashcard has a label:

“Square” “Triangle” ” Circle”

Keep showing him flash card over and over.

After sometime , show him flash card having new shape without any label and ask:

“What is this ?

Kid will reply with correct answer may be “Triangle”

That’s supervised learning—you learn from examples that already have answers (labels), and then you try to guess the answer for new stuff.

🎯 Real-Life Example – Predicting House Prices

Okay, Let’s say we are building a model to guess house prices. we provide relevant input to it:

• How big the house is

• Where it’s located

• Number of rooms

...plus what it actually sold for. We keep giving it example after example, and slowly it starts to notice, “Hmm, houses in Mumbai facing Sea go for more. “

Now, if you hand it data for a brand-new house, it can take a decent guess at the price—even if it’s never seen that specific one before.

Subscribe now

🌐 How This Works in Networking

Lets consider —network data—we might use this to catch bad traffic.

we train the model on labeled flow data. Stuff like:

• IP addresses

• Ports

• Traffic volume

• Protocol used

• Packet size

• Time of day

• Duration

And for each one, mark it “Safe” or “Malicious.”

We do that long enough, and the model starts spotting patterns. “Ah, this combination of port + packet timing? Seen that before. Pretty sure it’s a X”

This is where it starts getting useful—real-time detection, with way less manual effort.

So Why’s It Called “Supervised”?

Simple: because We are literally supervising the learning process. Like showing kid how to ride a bike. We are e right there holding the seat, giving feedback as they go.

It’s not figuring stuff out on its own yet—We are guiding it.

🔍 Unsupervised Learning: When There Are No Answers

So, this one’s bit different. There’s no training, no right answers, nothing. basically give the model a bunch of raw data and say, “Here. Figure it out.”

It’s like landing in a city you’ve never been to—with no map—and just walking around. Over time, you notice stuff: “Okay, everyone gathers near that bus stop,” or “This street’s always jammed during peek hours at 6 PM.” That’s what unsupervised learning does. Finds patterns. Groups.

🎯 Real-life Example – Retirement Savings

Take this—say you’ve got a dataset of people’s ages and their savings. That’s it. No idea who’s doing well, who’s behind. Just raw numbers.

Now, the model might look at it and say, “Hmm, looks like these over-50 folks with low savings—yeah, one group. Then these younger ones saving aggressively? Another group.”

No labels. No judgment. Just clusters. Then a human (like a financial advisor) can come in, look at those clusters, and go, “Yeah, that first group’s in trouble. These others? They’re good.”

Share Automation

🌐 Network Example – Spotting Behavior

Okay, now let’s bring it to networking.

Say you’ve got logs—tons of unlabeled flow data. You dump it into a model. It’s got no clue what “normal” even means, but still starts spotting patterns.

Maybe it figures out that from 9 to 5, traffic looks pretty normal. But then at 2 AM, suddenly some host is pushing massive files to some unknown IP. The model’s like, “That’s not the usual routine.”

Boom. Anomaly detection.

That’s the magic. No one tells it what’s bad—it just sees something off.

🎮 Reinforcement Learning: Learning by Doing

This one’s honestly a gaming. Feels like how we all actually learn.

Reinforcement learning is trial and error, plain and simple. The model does something, sees what happens, and adjusts.

Do something good? Get a reward.
Mess up or wrongly executed ? Penalty.

🎯 Example – Teaching a Game Bot

You’ve got a bot learning to play a game. You don’t tell it the rules. You just give it a little reward when it scores.

You just say,
🟢 “Score point? +1 reward”
🔴 “Lose a life? -1 penalty”

First few rounds? It’s clueless. But it keeps trying. Gets a little better. Tries different moves. Slowly starts winning more.

Eventually it discovers the strategy to win.

Same as how a kid learns. Fall off the cycle? Stay upright?

🌐 Network Example – Auto-Tuning Without the Manual Work

Now, think networking.

Imagine a system that’s allowed to adjust routing paths, bandwidth, QoS settings—whatever.

It tries something new. If latency improves, or throughput increases—reward.
If things get worse—penalty.

And over time? It learns the best combo. Without a human manually tweaking BGP attribute or adjusting buffer size

It’s literally self-tuning. Just like we all do after messing up a few times and figuring things out.

We will talk more about AI in coming posts.

Till time , keep learning !!!!

Smiles :)

Anurudh

Welcome back to our Ansible Mastery Journey. If you are new to here , don’t miss to check previous posts before diving into this post.

In this post, we will have a deep dive into:

• Why SSH matters for Ansible

• How to set up key-based ssh access(no password required)

• Real setup providing steps to push your public key to Cisco routers

• Testing your setup and tshoot with playbooks.

🚀 Why SSH Matters for Ansible

Lets talk about SSH , honestly its one thing which we expect to work while working with ansible.

At its core ,SSH is basically secure tunnel into remote machines. Its how we get in device without physically being there. It used port 22 by default but you can t change it without any issue.

Ansible is agentless, which means it doesn’t need to install anything on the remote machine to work its magic. It just depend upon on SSH to get in, do its job.

So if your SSH setup is broken or misconfigured? Good luck running playbooks. That’s why getting SSH right is half the battle when setting up Ansible.

⚙️ Setting Up SSH for Ansible

Here’s how I usually go about it:

1. Install OpenSSH

Make sure OpenSSH is installed—both on your control machine (where you run Ansible) and the target machines (the ones you want to manage).

To check if it's installed:

[anurudh@localhost ~]$ ssh -V
OpenSSH_8.7p1, OpenSSL 3.2.2 4 Jun 2024
[anurudh@localhost ~]$ 
[anurudh@localhost ~]$ 
[anurudh@localhost ~]$ 

if not , it can be installed like this:

[anurudh@localhost ~]$ sudo yum install openssh-server
Last metadata expiration check: 1:02:08 ago on Sat 03 May 2025 12:33:40 PM IST.
Package openssh-server-8.7p1-45.el9.x86_64 is already installed.
Dependencies resolved.
Nothing to do.
Complete!
[anurudh@localhost ~]$ 

2. Set Up Key-Based Auth

This is important. You don’t want to be typing passwords every time Ansible connects, right?
So generate a key pair on your control node:

[anurudh@localhost ~]$ ssh-keygen

Now if you check your .ssh directory:

anurudh@localhost ~]$ ls ~/.ssh/
id_rsa  id_rsa.pub  known_hosts
[anurudh@localhost ~]$ 

That id_rsa is your private key. Keep it safe. Never share it.

And id_rsa.pub? That’s the one you give to devices so they let you in.

This way, Ansible can log in without needing a password every time.

Subscribe now

3. Test the Connection

Before going all-in with Ansible, test the SSH connection manually:

[anurudh@localhost ~]$ ssh ansible_admin@1.1.1.1

If it logs in without asking for a password—you’re done

Lets walk through each step discussed above with real example

🔧 Real-World Example: Pushing Public Key to a Cisco Device

Let’s go step-by-step on setting up key-based SSH access with a Cisco router.

Lets first check ssh directory in master node

[anurudh@localhost ~]$ ls ~/.ssh/
known_hosts
[anurudh@localhost ~]$ 

Okay, no key yet—let’s generate one:

[anurudh@localhost ~]$ ssh-keygen

After that directory should look like this

[anurudh@localhost ~]$ ls ~/.ssh/ 
id_rsa  id_rsa.pub  known_hosts

Here we have got bot private ( id_rsa ) and public key (id_rsa.pub ) generated. Private key should not leave this machine . We will copy public key to network devices to enable SSH key based authentication.

and now we'll take a look into the public key.

[anurudh@localhost ~]$ cat ~/.ssh/id_rsa.pub 

ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABgQDiHucZaT0Q6dYc5LD5tYZBfiioPY6WrsryPLV4K7ypw+bS92fWnPorNi5EUvJY4xJ46uCFvIj14JNGBHiUfDDbmX2ZHqsIGe536fh1V7TmkQl/5n1Aq6tikzjui3tBgh5r7O5A3EF6HoU/FsFPGEWPDMLJP0uv2KIVcD5VJDr9SdR62x2b/+6ZhKV6R6v8seEk31El4oFyGIRh8G9e21avqhl9ikoXor9SEaQx5WEVvO3vjHH+JWgyq2QfR3bqC4tXM+BRgpHiJ9PirL/unneZMAQD/+relOVWymY2uMrtSZFvSoWWxE10CabAn2Lc2Fs7MQM6gRFWo4BaPJCCUMwvcv3g7nmIAVY86BDYnzcSCCkR6xzrY4WB1OPfY9bDunDC3ZUWwMHzl/yB8pagl84g83/r/FfGxABntnM7UMBC2rNHUYJYGSOp0GDTO5iJ2YabBoIy99tFEqzoXrqwHsuFxS/oLtNC26eFFuEZ9eAYX1WbV2x9xWipnz6khJo6hw8= anurudh@localhost.localdomain
[anurudh@localhost ~]$ 

So we need to copy and paste this content into Cisco device.

But hold up—Cisco CLI only accepts 256 characters per line. So we need to fold that key before pasting:

[anurudh@localhost ~]$ fold -b -w 64 ~/.ssh/id_rsa.pub

Share

Now let’s jump into the Cisco device:

[anurudh@localhost network_automation_ansible]$ ssh cisco@1.1.1.1(cisco@1.1.1.1) Password: 
R1#

Inside the router

anurudh@localhost network_automation_ansible]$ ssh cisco@1.1.1.1 (cisco@1.1.1.1) 
Password:  
R1#config t Enter configuration commands, one per line.  End with CNTL/Z. R1(config)#username ansible_admin
R1(config)#ip ssh pu 
R1(config)#ip ssh pubkey-chain  
R1(conf-ssh-pubkey)#username ansible_admin 
R1(conf-ssh-pubkey-user)#key-? key-hash  key-string   
R1(conf-ssh-pubkey-user)#key-str 
R1(conf-ssh-pubkey-user)#key-string  
R1(conf-ssh-pubkey-data)#

we will paste public key copied into cisco terminal

R1(conf-ssh-pubkey-user)#key-string
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABgQDiHucZaT0Q6dYc5LD5tYZBfiio
PY6WrsryPLV4K7ypw+bS92fWnPorNi5EUvJY4xJ46uCFvIj14JNGBHiUfDDbmX2Z
HqsIGe536fh1V7TmkQl/5n1Aq6tikzjui3tBgh5r7O5A3EF6HoU/FsFPGEWPDMLJ
P0uv2KIVcD5VJDr9SdR62x2b/+6ZhKV6R6v8seEk31El4oFyGIRh8G9e21avqhl9
ikoXor9SEaQx5WEVvO3vjHH+JWgyq2QfR3bqC4tXM+BRgpHiJ9PirL/unneZMAQD
/+relOVWymY2uMrtSZFvSoWWxE10CabAn2Lc2Fs7MQM6gRFWo4BaPJCCUMwvcv3g
7nmIAVY86BDYnzcSCCkR6xzrY4WB1OPfY9bDunDC3ZUWwMHzl/yB8pagl84g83/r
/FfGxABntnM7UMBC2rNHUYJYGSOp0GDTO5iJ2YabBoIy99tFEqzoXrqwHsuFxS/o
LtNC26eFFuEZ9eAYX1WbV2x9xWipnz6khJo6hw8= anurudh@localhost.local
domain                                                                                          

Press enter and exit

R1(conf-ssh-pubkey-data)#exit
R1(conf-ssh-pubkey-user)#
R1(conf-ssh-pubkey-user)#exit
R1(conf-ssh-pubkey)#

Now test it again from your control node:

[anurudh@localhost ~]$ ssh ansible_admin@1.1.1.1
R1#

if you’re in without a password prompt—Great we have done it .

If not, and you're being asked for a password, try updating your SSH config:

[anurudh@localhost ~]$ sudo vi /etc/ssh/ssh_config

add:

PubkeyacceptedKeyTypes +ssh-rsa

Lets run below playbook now

Here’s a simple Ansible playbook to check inventory details:

[anurudh@localhost network_automation_ansible]$ cat 03_cisco_inventory_check 
---
 - name: Cisco inventory check
   hosts: ios_devices
   #
   gather_facts: false

   tasks: 
    - name: print Ansible config location
      ansible.builtin.debug:
        msg:
         - "{{ ansible_config_file }}"
         - "{{ inventory_file }}"
         - "{{ ansible_facts }}"
         - "{{ ansible_user }}"

[anurudh@localhost network_automation_ansible]$ 

run it

[anurudh@localhost network_automation_ansible]$ ansible-playbook 03_cisco_inventory_check 

You should see output like:

[anurudh@localhost network_automation_ansible]$ ansible-playbook 03_cisco_inventory_check 

PLAY [Cisco inventory check] *************************************************************************************************************************************************************

TASK [Gathering Facts] *******************************************************************************************************************************************************************
ok: [R2]
ok: [R1]

TASK [print Ansible config location] *****************************************************************************************************************************************************
ok: [R1] => {
    "msg": [
        "/home/anurudh/network_automation_ansible/ansible.cfg",
        "/home/anurudh/network_automation_ansible/hosts.ini",
        {
            "net_api": "cliconf",
            "net_gather_network_resources": [],
            "net_gather_subset": [
                "default"
            ],
            "net_hostname": "R1", .....},
        "ansible_admin"
    ]
}
ok: [R2] => {
    "msg": [
        "/home/anurudh/network_automation_ansible/ansible.cfg",
        "/home/anurudh/network_automation_ansible/hosts.ini",
        {
            "net_api": "cliconf",
            "net_gather_network_resources": [],
            "net_gather_subset": [
                "default"
            ],
            "net_hostname": "R2", ....},            
        "cisco"
    ]
}

PLAY RECAP *******************************************************************************************************************************************************************************
R1                         : ok=2    changed=0    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0   
R2                         : ok=2    changed=0    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0   

[anurudh@localhost network_automation_ansible]$ 

So R1 is using the ansible_admin user we set up for key-based access. R2 is still using the default cisco user from the group vars.

Lets check our inventory file

[anurudh@localhost network_automation_ansible]$ cat hosts.ini 

[routers]
R1 ansible_host=1.1.1.1 ansible_user=ansible_admin
R2 ansible_host=2.2.2.2

[ios_devices:children]
routers

[ios_devices:vars]
ansible_user=cisco
ansible_password=cisco
ansible_connection=network_cli
ansible_network_os=ios
[anurudh@localhost network_automation_ansible]$ 

R1 has its own user and SSH key setup. R2 falls back to the default group settings. Simple, flexible, and super clean.

let change private key file location to something different , if we get error after playbook , it means that ssh key is working perfectecly

[anurudh@localhost network_automation_ansible]$ cat hosts.ini 

[routers]
R1 ansible_host=1.1.1.1 ansible_user=ansible_admin ansible_ssh_private_key_file=/home/anurudh/.ssh/id_rsa_2
R2 ansible_host=2.2.2.2

[ios_devices:children]
routers

[ios_devices:vars]
ansible_user=cisco
ansible_password=cisco
ansible_connection=network_cli
ansible_network_os=ios
[anurudh@localhost network_automation_ansible]$ 

configured wrong file name —> /home/anurudh/.ssh/id_rsa_2

lets run same playbook again

[anurudh@localhost network_automation_ansible]$ ansible-playbook 03_cisco_inventory_check 

You should see output like:

[anurudh@localhost network_automation_ansible]$ ansible-playbook 03_cisco_inventory_check 

PLAY [Cisco inventory check] *************************************************************************************************************************************************************

TASK [Gathering Facts] *******************************************************************************************************************************************************************
fatal: [R1]: FAILED! => {"ansible_facts": {}, "changed": false, "failed_modules": {"ansible.legacy.ios_facts": {"failed": true, "invocation": {"module_args": {"available_network_resources": false, "gather_network_resources": null, "gather_subset": ["min"]}}, "msg": "[Errno 2] No such file or directory: '/home/anurudh/.ssh/id_rsa_2'"}}, "msg": "The following modules failed to execute: ansible.legacy.ios_facts\n"}
ok: [R2]

TASK [print Ansible config location] *****************************************************************************************************************************************************
ok: [R2] => {
    "msg": [
        "/home/anurudh/network_automation_ansible/ansible.cfg",
        "/home/anurudh/network_automation_ansible/hosts.ini",
        {
            "net_api": "cliconf",
            "net_gather_network_resources": [],
            "net_gather_subset": [
                "default"
            ],
            "net_hostname": "R2" ....},
        "cisco"
    ]
}

PLAY RECAP *******************************************************************************************************************************************************************************
R1                         : ok=0    changed=0    unreachable=0    failed=1    skipped=0    rescued=0    ignored=0   
R2                         : ok=2    changed=0    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0   

[anurudh@localhost network_automation_ansible]$ 

R1 is failing as it not having correct ssh key path. so we are good and It means R1 is taking SSH authentication .

Lets modify inventory file and correct it

[anurudh@localhost network_automation_ansible]$ cat hosts.ini 

[routers]
R1 ansible_host=1.1.1.1 ansible_user=ansible_admin ansible_ssh_private_key_file=/home/anurudh/.ssh/id_rsa
R2 ansible_host=2.2.2.2

[ios_devices:children]
routers

[ios_devices:vars]
ansible_user=cisco
ansible_password=cisco
ansible_connection=network_cli
ansible_network_os=ios
[anurudh@localhost network_automation_ansible]$ 

lets run same playbook again

[anurudh@localhost network_automation_ansible]$ ansible-playbook 03_cisco_inventory_check 

You should see output like:

[anurudh@localhost network_automation_ansible]$ ansible-playbook 03_cisco_inventory_check 

PLAY [Cisco inventory check] *************************************************************************************************************************************************************

TASK [Gathering Facts] *******************************************************************************************************************************************************************
ok: [R1]
ok: [R2]

TASK [print Ansible config location] *****************************************************************************************************************************************************
ok: [R2] => {
    "msg": [
        "/home/anurudh/network_automation_ansible/ansible.cfg",
        "/home/anurudh/network_automation_ansible/hosts.ini",
        {
            "net_api": "cliconf",
            "net_gather_network_resources": [],
            "net_gather_subset": [
                "default"
            ],
            "net_hostname": "R2".....},
        },
        "cisco"
    ]
}
ok: [R1] => {
    "msg": [
        "/home/anurudh/network_automation_ansible/ansible.cfg",
        "/home/anurudh/network_automation_ansible/hosts.ini",
        {
            "net_api": "cliconf",
            "net_gather_network_resources": [],
            "net_gather_subset": [
                "default"
            ],
            "net_hostname": "R1"......},
        "ansible_admin"
    ]
}

PLAY RECAP *******************************************************************************************************************************************************************************
R1                         : ok=2    changed=0    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0   
R2                         : ok=2    changed=0    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0   

We have done it !!!!

Action Step for You Today

Just one thing: make sure to go through the concepts and follow along with the tasks. Try to complete them within two days after the post is published.

I’ll guide you, one simple post at a time.

Buy Me A Coffee

We will deep dive more into Ansible in upcoming posts. Don’t miss to DM or ping me with your queries and comments.

Smiles :)

Anurudh

When it comes to automation tools for networks and infrastructure, they aren't all built the same way.
Here are some important differences you should know — explained in a way that’s easy to understand:

1. Building vs. Setting Up Infrastructure

• Infrastructure provisioning is like building the house — setting up walls, roofs, windows, and doors (things like servers, network connections, and databases).

• Configuration management is like setting up the inside of the house — adding beds, lights, and furniture (installing and configuring the right software).

Provisioning happens on Day 0 (building), and configuration happens on Day 1 (setting things up properly).

2. Agent-Based vs. Agentless Tools

• Agent-based tools need a little helper (software) installed on each device to manage it.

• Agentless tools don’t need any helper installed; they connect directly.

In networking, agentless tools are often better because many devices don’t allow installing extra software.

3. Centralized vs. Decentralized Control

• Centralized = one big "boss" server tells all devices what to do.

• Decentralized = devices manage themselves or work with each other without a central boss.

4. Special Language vs. Common Language

• Some tools use their own special language (DSL), and you have to learn it to use the tool.

• Other tools use common formats like YAML, making it easier because many people already know it.

5. Declarative vs. Imperative Approaches

• Declarative = you say what you want ("I want a red living room") and the system figures out how to do it.

• Imperative = you tell it step-by-step ("First paint the wall red, then bring in a big sofa").

  Subscribe now

6. Extending Tools with Programming

• Many tools let you add extra features using common languages like Python or Go — kind of like upgrading your house with smart gadgets.

7. Push, Pull, and Event-Driven Actions

• Push model = you send instructions to the devices.

• Pull model = devices ask for new instructions themselves.

• Event-driven = devices act when something specific happens (like turning on lights when someone rings the doorbell).

8. Mutable vs. Immutable Infrastructure

• Mutable = you change things in the house while living in it (like repainting while living there).

• Immutable = if you want changes, you build a brand-new house and move in.

Share Automation

9. Managing the "State" of Infrastructure

• Some tools don’t remember what was changed — you have to check manually.

• Other tools keep track of everything they built and know when something needs to be rebuilt or fixed.

Smiles:)

Anurudh

Buy Me A Coffee

Have you wondered how computer can recognize face , talk like human , suggest for next movie or even suggest what you need to buy . Let's explore this transformation together.

The Early Days: Traditional AI

A long time ago , Scientist wanted computer to think like people. This idea was called Traditional AI. Because of their work, computers got better at solving problems and understanding information.

One smart person, John McCarthy, made a special computer language called Lisp to help with AI. Lisp is really good at working with symbols, like letters and numbers. Even today, some scientists still use it when working on AI.

Thanks to Traditional AI, we also learned more about how the human brain works and how computers can copy some of that thinking.

Subscribe now

But Traditional AI had some trouble. It followed very strict rules and didn’t do well with messy or confusing problems. So, people came up with better ways to make AI smarter — like machine learning and deep learning. These new methods help computers learn from a lot of data instead of just following rules.

That’s how AI keeps getting better and better over time!

The Shift: Embracing ML and DL

Today, there are two main types of smart computer programs: Machine Learning (ML) and Deep Learning (DL). They both learn from data, but they do it in different ways.

It's important for people who build and use these programs to know the difference between ML and DL. This helps them pick the best one for what they need.

Share

Knowing about both also helps people come up with new and better ideas. Sometimes, they even mix ML and DL together to get the best of both! For example, they might use ML first to clean up and organize the data, and then use DL to find really tricky patterns and make smart guesses.

Machine Learning (ML)

Machine Learning (ML) is when computers use different algo to get better at tasks the more they practice.

In simple words, ML is like teaching a computer by giving it lots of examples. After learning from these examples, the computer can guess or figure out things it has never seen before!

A good example is how email spam filters work:

The computer looks at tons of old emails that were marked as "spam" and "not spam," learns the difference, and then tries to catch new spam emails all by itself.

Deep Learning (DL)

Deep Learning (DL) is a special kind of Machine Learning.

It uses something called artificial neural networks, which are a lot like the way our brains work. These networks have many layers that help computers learn from huge amounts of information.

Deep Learning can look at things like pictures, words, or sounds and figure out patterns.

For example, it can help a computer look at a photo and say what’s in it!

Because DL uses so much data and many smart layers, it can be very, very good at things like recognizing faces in pictures or understanding what someone says in a recording.

Data Needs for ML and DL

Machine Learning (ML) doesn’t need a lot of data to work well.

Imagine you want to teach a computer to guess house prices — you only need a small list with basic information like house size and number of rooms.

Since it doesn’t need tons of examples, it’s faster to teach and doesn’t need super powerful computers.

ML is also easier to understand — you can usually figure out why it made a certain choice.

That’s why ML is great when you don’t have much information or when the information is nice and neat (like tables).

But ML struggles with messy stuff like pictures or sounds.

Deep Learning (DL) is different — it needs way more data, especially messy things like photos, music, or books.

Even if the information looks small (like a short story), DL still takes a lot of time because it has to work really hard to understand it.

Teaching a DL computer to recognize voices, for example, could take days or even weeks!

It also needs big, powerful computers to do all that work.

And, it's much harder to understand how DL makes decisions because it’s like a giant maze inside the computer.

We will talk more about AI in coming posts.

Smiles :)

Anurudh

Buy Me a Coffee

☕️ Buy Me a Coffee

☕️ Buy Me a Coffee