DEV Community: Adeje Oluwatobiloba

Deployed a Production-Ready Three-Tier Node.js Application on AWS

Adeje Oluwatobiloba — Wed, 19 Aug 2026 20:32:21 +0000

Introduction

Deploying an application to AWS is more than launching a few EC2 instances and making the application accessible over the internet. A production-oriented deployment must consider network isolation, security, availability, scalability, load balancing, database resilience, and operational troubleshooting.

In this project, I deployed a full-stack Book Review Application using a three-tier architecture on AWS. The architecture separates the application into Presentation, Business, and Data tiers, with controlled communication between each layer.

The final traffic flow is:

Internet --> Public ALB --> Web Tier --> Internal ALB --> Application Tier --> Database Tier

The objective was to build an architecture where each tier has a clearly defined responsibility and can be secured, scaled, and maintained independently.

Architecture Overview

The deployment consists of three primary layers:

🌐 Web Tier

The Web Tier hosts the Next.js frontend on Ubuntu EC2 instances, with Nginx configured as a reverse proxy. The public ALB distributes incoming HTTP traffic across healthy Web Tier instances deployed across multiple Availability Zones.

Nginx serves the frontend and can route backend/API requests through the internal ALB, which then forwards traffic to the private Node.js/Express instances.

The request flow is:

Client → Public ALB → Nginx → Internal ALB → Node.js App Tier → RDS

This design keeps the Application Tier private while allowing the frontend to communicate with backend services through a controlled internal path, providing security, load balancing, scalability, and fault isolation.

⚙️ Application Tier

The Application Tier hosts the Node.js/Express backend on port 3001, deployed across EC2 instances in private subnets.

An internal Application Load Balancer distributes API traffic from the Web Tier across healthy application instances.

Because the Application Tier is private, the backend is not directly exposed to the internet. This provides a controlled communication path between the frontend and backend while allowing the application layer to scale independently.

🗄️ Data Tier

The Data Tier uses Amazon RDS for MySQL deployed in private subnets with restricted access from the Application Tier.

A Read Replica was used to offload read-heavy workloads from the primary RDS instance and provide additional read scalability, while Multi-AZ was used to improve high availability and failover.

This design protects the database from direct public access while providing availability, resilience, and controlled database connectivity.

VPC and Network Architecture

The foundation of the deployment is a custom Amazon VPC using:

VPC CIDR: 10.0.0.0/16

The VPC was divided into six subnets across two Availability Zones:

Tier	Availability Zone A & CIDR Block	Availability Zone_B & CIDR Block
Web	Web_Public_SubnetA (10.o.1.0/24)	Web_Public_SubnetB (10.0.2.0/24)
Application	App_Private_SubnetA (10.0.10.0/24)	App_Private_SubnetB (10.0.12.0/24)
Database	DB_Private_SubnetB (10.0.20.0/28)	DB_Private_SubnetB (10.0.22.0/28)

This subnet segmentation creates clear network boundaries between the three application layers.

The Web Tier requires public connectivity because it receives traffic from the internet through the public ALB.

The Application Tier remains private because it should only receive traffic from the Web Tier through the internal ALB.

The Database Tier is also private and should only accept database connections from the Application Tier.

Security Group Design

Security Groups were configured using a least-privilege approach.

The major security rules are:

Component	Port	Source
Web-EC2-SG	80	Internet
App-EC2-SG	80, 3001	Web-EC2-SG, App-EC2-SG
RDS-DB-SG	3306	App-EC2-SGSG

This avoids unnecessary CIDR-based access between tiers and ensures that each component only accepts the traffic required for its role.

Most importantly, the Application and Database tiers are not directly accessible from the public internet.

Web Tier Deployment

The Web Tier was deployed on Ubuntu EC2 instances running the Next.js frontend, with Nginx configured as a reverse proxy. Nginx receives HTTP requests on port 80 and routes them to the appropriate frontend or backend service.

The public ALB performs health checks against the Web Tier and distributes requests only to healthy instances.

Running multiple instances across Availability Zones reduces dependence on a single EC2 instance and provides a foundation for horizontal scaling.

Application Tier Deployment

The backend was deployed using Node.js and Express.

The application listens on:

Port: 3001

The backend instances are located in private subnets and are registered with the internal ALB.

The internal ALB provides load distribution between backend instances while keeping the API servers inaccessible from the public internet.

This separation also allows the Application Tier to scale independently of the Web Tier.

Database Deployment with Amazon RDS

The database layer uses Amazon RDS for MySQL.

The RDS instances are deployed using a DB subnets configuration spanning the private database subnets.

The database is not publicly accessible.

The RDS Security Group permits MySQL traffic only from the Application Tier.

This provides an additional security boundary between application logic and persistent data.

Multi-AZ and Read Replica

Two database concepts are particularly important in this architecture: Multi-AZ and Read Replicas.

They solve different problems.

Multi-AZ: Multi-AZ is primarily used for high availability and failover.

If the primary database instance becomes unavailable, AWS can fail over to the standby instance.

The goal is therefore resilience rather than increasing read capacity.

Read Replica: A Read Replica is primarily used for read scalability.

For workloads with a large number of read operations, suitable read traffic can be directed to the replica rather than sending every query to the primary database.

This can reduce read pressure on the primary database and provide additional capacity for read-heavy workloads.

A key distinction is:

Multi-AZ = high availability

Read Replica = read scalability

The Read Replica should therefore not be presented as the primary failover mechanism for the database.

Why This Architecture?

The primary reason for using a three-tier architecture is separation of concerns.

Each tier has a specific responsibility:

Web Tier: presentation and user interaction
Application Tier: business logic and API processing
Data Tier: persistent data storage

This separation provides several operational advantages.

Security: Private application and database tiers reduce the attack surface.
Scalability: Each tier can be scaled independently according to its workload.
Availability: Multiple Availability Zones, load balancing, and database redundancy reduce single points of failure.
Maintainability: Changes to one layer can be managed without unnecessarily affecting the others.
Fault Isolation: A failure in one component does not automatically require the entire application to be unavailable.

Key Takeaways

This deployment reinforced several core cloud and DevOps principles:

Security: Don't expose components unnecessarily. Control communication using least-privilege access.

Scalability: Design components so they can scale independently.

Availability: Eliminate unnecessary single points of failure through redundancy and Multi-AZ architecture.

Automation and repeatability: Infrastructure and application deployment should eventually become reproducible rather than dependent on manual configuration.

Observability and troubleshooting: Understanding how traffic moves through the system makes failures easier to isolate and resolve.

Most importantly, I learned that cloud engineering is not simply about deploying AWS services.

It is about understanding how those services work together to create a secure, reliable, scalable, and maintainable system.

Conclusion

The completed architecture provides a production-style foundation for the Book Review Application:

The project provided hands-on experience across AWS networking, EC2, Application Load Balancers, Nginx, Node.js, Next.js, RDS, security groups, private networking, high availability, scalability, and troubleshooting.

More importantly, it shifted my thinking from simply deploying an application to engineering the platform that the application runs on.

P.S. This post is part of the DevOps Micro Internship (DMI) with Agentic AI — Cohort 3 — by Pravin Mishra. My graded progress is public: https://dmi.pravinmishra.com/s/Tobilee10.html · Start your DevOps journey: https://dmi.pravinmishra.com/?utm_source=student&utm_medium=ps-linkedin&utm_campaign=cohort3

Building a Read-Only Jira Intelligence Layer for Claude Code with MCP

Adeje Oluwatobiloba — Tue, 18 Aug 2026 09:26:20 +0000

AI-assisted engineering is moving beyond code generation.

A more interesting use case is giving an AI assistant controlled access to the systems engineers already use for planning and delivery.

I recently built a small integration that connects Claude Code to Jira through Atlassian MCP (mcp-atlassian), allowing Claude Code to retrieve live sprint data and analyze delivery health directly from the terminal.

The goal was not to let AI modify Jira.

It was to give AI enough context to observe, analyze, and surface useful insights while keeping humans responsible for operational decisions.

The core workflow is:

Gather → Analyze → Human Act → Verify

Connecting Jira to Claude Code

I registered the Jira MCP server in the project's .mcp.json configuration using uvx:

{
  "mcpServers": {
    "jira": {
      "command": "uvx",
      "args": ["mcp-atlassian"]
    }
  }
}

This configuration defines how Claude Code discovers and communicates with the MCP server.

The important concept here is the Model Context Protocol (MCP) abstraction.

Instead of building a custom integration directly into the AI client, MCP provides a standardized interface through which the client can discover and invoke the tools exposed by the server.

That separation makes the integration easier to reason about and extend.

Keeping Credentials Out of the Repository

Authentication details were kept outside the committed MCP configuration.

The Jira URL, username, and API token were provided through local environment configuration:

{
  "env": {
    "JIRA_URL": "https://your-site.atlassian.net",
    "JIRA_USERNAME": "your_email@example.com",
    "JIRA_API_TOKEN": "your_token_here"
  }
}

The integration uses a dedicated Jira API token rather than embedding credentials directly into the project configuration.

The important principle is:

Architecture belongs in Git. Secrets don't.

The configuration required to understand and reproduce the integration can be version controlled, while credentials remain local and are excluded from source control.

For a production implementation, I would take this further with a managed secrets solution and appropriate credential rotation policies.

Pulling Live Jira Sprint Data

After establishing the MCP connection and verifying it through Claude Code, I could query Jira for current sprint information.

The available data included:

Issue status Assignees Story points Priorities Sprint information Missing estimates Potentially stagnant or at-risk work

This changed the role of the AI assistant.

Instead of asking Claude to reason about manually copied Jira information, I could give it access to current delivery data and let it perform the analysis from the live source.

That distinction matters.

AI analysis is only as useful as the context available to the model.

Building a Read-Only /sprint-health Skill

I then wrapped the analysis into a custom Claude Code /sprint-health skill.

The skill was intentionally designed around read-only Jira operations, including:

jira_search jira_get_issue jira_get_sprint jira_get_board

It does not create issues.

It does not update tickets.

It does not add comments.

It does not transition issues.

The skill's responsibility is analysis.

It evaluates information such as:

Sprint progress Remaining work Story-point distribution Stagnant work Missing estimates Potential delivery risks Areas that may require attention during standup

The output can then be used to prepare more focused standup discussions.

Why Read-Only Access Matters

The most interesting part of this project was not connecting Jira to Claude Code.

It was defining the permission boundary.

There is a tendency with AI agents to focus on what they can do.

I was more interested in defining what the agent cannot do.

The Jira board remains the operational source of truth.

Claude Code can observe that state and provide analysis, but the human lead remains responsible for deciding what action should be taken.

That produces a controlled workflow:

Gather
AI retrieves current Jira data.

Analyze
AI identifies trends, gaps, and potential risks.

Human Act
The responsible person reviews the analysis and decides what action to take.

Verify
AI retrieves the updated Jira state and evaluates the sprint again.

This creates a practical human-in-the-loop model rather than giving the AI unrestricted authority over the project-management system.

Least Privilege for AI Agents

This project also reinforced a principle that is well established in security engineering:

Give a system only the permissions it needs to perform its intended function.

If the purpose of /sprint-health is to analyze sprint health, it does not need permission to create or modify Jira issues.

Restricting the available operations reduces the potential impact of an incorrect AI decision or unexpected tool invocation.

This is especially important as AI agents become increasingly capable of interacting with external systems.

The question should not only be:

“What can the agent automate?”

It should also be:

“What is the minimum authority the agent actually needs?”

The DevOps Perspective

From a DevOps perspective, I found this project interesting because it connects delivery data with engineering intelligence.

Traditional workflows often require engineers or delivery leads to manually inspect dashboards, identify trends, and prepare updates.

With controlled AI access to live project data, some of that analysis can become conversational and repeatable.

For example, instead of manually checking multiple Jira views, a developer or delivery lead could ask for a sprint-health analysis and receive a structured summary based on the current state of the board.

The important distinction is that the AI becomes an analysis layer, not the system of record.

Jira remains Jira.

The AI simply provides another interface for understanding the information.

What I Learned

This project taught me several lessons beyond simply configuring an MCP server.

Integration design matters

Connecting tools to an AI assistant is relatively straightforward. Designing the correct boundaries around that connection is more important.

Context matters

An AI assistant becomes significantly more useful when it can work with current, relevant operational data rather than static information supplied manually.

Least privilege applies to AI

The principle of least privilege should apply to AI agents just as it does to traditional applications and services.

Human oversight remains valuable

Automation does not mean removing humans from every decision.

For operational workflows, a better model can be:

AI observes → AI analyzes → Human decides → System changes → AI verifies

Source-of-truth boundaries matter

Jira remains the authoritative system for sprint state.

The AI should not create a competing source of truth.

Conclusion

This project started as an experiment with Claude Code, Jira, and Model Context Protocol, but it became a practical exercise in designing controlled AI-assisted engineering workflows.

The architecture can be summarized simply:

Jira → MCP → Claude Code → Analysis → Human Decision → Jira

The interesting part isn't that an AI can read Jira.

The interesting part is deciding how much access it should have, what responsibility it should carry, and where human authority should remain.

As AI agents become more integrated into engineering workflows, I believe these boundaries will become increasingly important.

AI doesn't need permission to change everything to be useful.

Sometimes the most valuable engineering agent is the one that can observe deeply, analyze intelligently, and act only when explicitly authorized.

Building a Layered Code Review Workflow with Git Hooks and AI

Adeje Oluwatobiloba — Thu, 23 Jul 2026 19:06:28 +0000

As I progressed through my DevOps internship, I explored a workflow that combines Git pre-commit hooks with AI-assisted code review. While learning how these tools work together, I realized the entire process can be explained using a football analogy.

Think of a football match.

Git is VAR

Just as the Video Assistant Referee (VAR) records every play and allows referees to review important moments, Git records every change made to a project. Every commit becomes part of the project's history, making it possible to compare versions, inspect changes, or roll back to a previous state whenever necessary.

Without Git, recovering from mistakes would be much more difficult. In fact, during this assignment I accidentally performed a git reset --hard HEAD~1. Thanks to Git's history and the reflog, I was able to recover my work, this is a reminder of how valuable version control really is.

GitHub is the Referee

If Git records the match, GitHub acts as the referee.

GitHub manages pull requests, code reviews, approvals, and ultimately determines what gets merged into the main branch. It provides a structured collaboration process where developers can discuss changes, request improvements, and verify code before it becomes part of the production codebase.

Git Hooks are the Assistant Referee

An Assistant Referee watches for clear rule violations and immediately raises the flag.

Git pre-commit hooks serve exactly the same purpose.

Before every commit, the hook automatically inspects the staged changes and enforces predefined rules. During this assignment, the hook scanned my staged diff for issues such as:

Potential leaked secrets
API key patterns
Repository policy violations

These checks are deterministic. They don't understand the meaning of the code, they simply verify whether the staged changes violate known rules.

This makes Git hooks extremely fast and reliable for catching common mistakes before they ever enter the repository.

AI-Assisted Code Review is the VAR Review Team

While Git hooks look for predefined violations, AI-assisted code review analyzes the same code from a broader perspective.

Instead of asking:

"Does this code match a forbidden pattern?"

AI asks questions like:

Is this implementation maintainable?
Does it follow best practices?
Could this introduce security risks?
Is the pull request ready for review?

Unlike rule-based automation, AI evaluates context, allowing it to identify improvements that cannot easily be expressed as regular expressions or fixed validation rules.

This showed me that AI is not replacing automation, rather it is extending it.

Security Through Least Privilege

Another important concept I learned was the principle of least privilege.

The AI review workflow was intentionally granted only the permissions it required:

Read repository contents
Execute validation commands

It could not modify code, commit changes, or push to the repository.

Actions such as:

git commit
git push
Opening a pull request

remain the responsibility of the developer.

This design ensures that AI can provide recommendations without making irreversible changes to the codebase.

Key Takeaways

This week's assignment reinforced several important DevOps practices:

Create feature branches to protect the main branch and support collaborative development.
Use Git pre-commit hooks to catch predictable issues before code is committed.
Combine fixed-rule automation with AI-assisted review for more comprehensive code validation.
Follow the principle of least privilege by granting tools only the permissions they require.
Keep developers responsible for repository-changing actions while using automation and AI as decision-support tools.

Final Thoughts

The football analogy helped me understand the relationship between these tools:

Git records every play like VAR.
GitHub acts as the Referee, managing reviews and merges.
Git Hooks function as the Assistant Referee, enforcing predefined rules before play continues.
AI-assisted code review acts as the VAR Review Team, providing context-aware analysis that goes beyond simple rule checking.

Modern DevOps isn't about replacing one tool with another. It's about combining deterministic automation, intelligent analysis, and human decision-making into a layered workflow that delivers secure, reliable, and maintainable software.

Automating Linux Tasks with Bash

Adeje Oluwatobiloba — Wed, 22 Jul 2026 13:15:39 +0000

"Every repetitive task is an opportunity waiting to be automated."

One of the biggest lessons I've learned this weeek in the DevOps Micro Internship (DMI) is that automation begins with understanding the manual process.

Working in production support exposed me to many routine operational tasks. Whether it was gathering system information, validating files and directories, or running the same Linux commands repeatedly, I realized that many of these activities followed a predictable workflow. Although these tasks are essential for maintaining production environments, performing them manually can be time-consuming, inconsistent, and prone to human error.

This realization made learning Bash scripting more than just another technical exercise, it became an introduction to how automation solves real operational challenges.

Understanding Bash

Before writing scripts, I first learned the difference between a shell and Bash.

A shell is a command-line interpreter that allows users to interact with the operating system. Bash (Bourne Again Shell) is one of the most widely used Unix/Linux shells, offering features that make scripting powerful and flexible.

One important lesson was verifying the Bash version before writing scripts. Different Bash versions support different features, and writing scripts for the correct version helps avoid compatibility issues across Linux environments.

Importance of the shebang:

#!/bin/bash

This tells the operating system to execute the script using the Bash interpreter.

Before running a script directly, execute permissions must also be granted using:

chmod +x script.sh

This allows the operating system to execute the file as a program.

Building Scripts with Variables

Variables are one of the simplest but most important concepts in Bash scripting.

Instead of hardcoding values throughout a script, variables allow information to be stored once and reused multiple times.

For example, storing usernames, directories, or file paths inside variables makes scripts easier to maintain because updates only need to be made in one location.

Accessing variable values using the $ symbol also makes scripts dynamic and reusable.

Managing Multiple Values with Arrays

As scripts become larger, managing multiple values individually becomes inefficient.

Arrays solve this problem by storing multiple related items under a single variable.

Instead of creating several variables, I learned how arrays simplify data management while making loops much easier to implement.

This is particularly useful when working with multiple servers, directories, or applications that require the same operation.

Eliminating Repetition with Loops

One of the concepts that immediately demonstrated the value of automation was the for loop.

Rather than executing the same command repeatedly, a loop performs an action for every item in a list.

For example, instead of checking multiple directories manually, a loop can iterate through each directory automatically.

This simple concept significantly reduces repetitive work while making scripts shorter, cleaner, and easier to maintain.

Making Intelligent Decisions with Conditionals

Automation isn't only about repeating commands—it also requires making decisions.

Using if-else statements, scripts can respond differently depending on specific conditions.

During my exercises, I learned to:

Check whether files exist using -f
Verify directories using -d
Compare numbers using operators such as -ge
Execute different commands based on the results

These conditionals make scripts more reliable because they validate conditions before executing operations.

Organizing Code with Functions

As scripts become more complex, writing everything in a single block quickly becomes difficult to manage.

Functions solve this by grouping related commands into reusable blocks.

Instead of duplicating code throughout a script, a function can be written once and called whenever needed.

This improves readability, reduces maintenance effort, and makes debugging much easier.

Bringing Everything Together

The final assignment combined every concept into a single Bash automation script.

The script was designed to:

Display user and system information
Store values using variables
Manage collections with arrays
Repeat tasks using loops
Verify files and directories
Make decisions with conditionals
Organize reusable logic using functions

Although these are foundational Bash concepts, together they represent the building blocks of automation used across Linux administration, DevOps workflows, cloud infrastructure, and production support.

Key Takeaways

One thing this assignment reinforced is that automation is not simply about writing scripts.

Automation starts with understanding the manual process. Once the workflow is fully understood, repetitive tasks can be transformed into reusable, reliable, and consistent scripts.

As someone beginning a career in DevOps, this has changed the way I think about operational work. Instead of asking, "How do I perform this task?", I now find myself asking, "How can I automate this task safely and efficiently?"

Bash scripting is only one piece of the DevOps ecosystem, but it provides a strong foundation for future topics such as Infrastructure as Code, CI/CD pipelines, configuration management, cloud automation, and production engineering.

This is just the beginning of my automation journey, and I'm excited to continue building tools that simplify operations, improve reliability, and reduce manual effort.

How the Internet Works: A Beginner's Guide to Networking from Browser to Server

Adeje Oluwatobiloba — Wed, 22 Jul 2026 12:39:35 +0000

Learn how DNS, IP addresses, TCP/IP, packet switching, and HTTPS work together when you visit a website.

"You can't troubleshoot what you don't understand. For a DevOps Engineer, networking isn't optional, it's the foundation behind every deployment, API call, and cloud service."

When I first started learning DevOps, networking felt overwhelming. I could memorize terms like DNS, IP Address, TCP/IP, and HTTP/HTTPS, but I struggled to understand how they worked together. I knew the definitions, but I couldn't visualize what actually happens when someone types a website address into a browser.

To make learning easier, let's use an imaginary online bookstore called EpicReads.

The Journey Begins

Imagine you open your browser and type:

https://epicreads.com

From your perspective, it's just a website address.

Behind the scenes, however, several networking technologies work together in just a few milliseconds to deliver the webpage to your screen.

Let's walk through that journey step by step.

Step 1: DNS Finds the Server

The first question your browser asks is:

"Where is epicreads.com?"

Browsers cannot communicate using names like epicreads.com.

They communicate using IP addresses.

This is where DNS (Domain Name System) comes in.

Think of DNS as the internet's phonebook.

It translates:

epicreads.com

into something computers understand:

52.172.142.222

This translation happens because of a DNS A Record, which maps a domain name directly to an IPv4 address.

Without DNS, we'd have to memorize long strings of numbers every time we wanted to visit a website.

Step 2: Connecting to the Server

Now the browser knows where the server lives.

It begins communicating using the TCP/IP protocol suite.

This consists of two major protocols:

IP (Internet Protocol)

IP is responsible for routing data to the correct destination.

Think of it as the address written on a package.

TCP (Transmission Control Protocol)

TCP ensures that every piece of data arrives safely, completely, and in the correct order.

Think of TCP as the delivery company making sure every package reaches the customer without anything missing.

Together, TCP/IP forms the foundation of internet communication.

Step 3: Packet Switching

The browser doesn't send one huge request.

Instead, it breaks the request into many smaller pieces called packets.

This process is known as Packet Switching.

Each packet can travel through different routers and network paths.

Some packets may even arrive before others.

TCP keeps track of every packet and puts them back together once they reach the destination.

This makes the internet faster, more efficient, and more resilient.

Step 4: HTTP and HTTPS

After reaching the server, the browser sends an HTTP or HTTPS request.

These protocols define how browsers and web servers communicate.

Today, almost every website uses HTTPS because it encrypts communication between the browser and the server.

That encryption protects information such as:

Passwords
Credit card details
Personal information
Login sessions

Without HTTPS, anyone intercepting the traffic could potentially read the transmitted data.

Step 5: The Server Processes the Request

The request finally reaches the EpicReads web server.

The server may:

Retrieve available books
Check user accounts
Read shopping cart information
Process orders
Query the database

Once everything is ready, the server creates a response and sends it back to your browser.

Step 6: The Browser Displays the Website

The response also travels across the internet using Packet Switching.

TCP checks that every packet arrives successfully.

The browser reassembles the packets, interprets the HTML, CSS, and JavaScript, and finally displays the EpicReads homepage.

All of this typically happens in less than a second.

Putting It All Together

When you understand this flow, networking becomes much less intimidating.

Conclusion

Networking is one of the most important skills for anyone pursuing a career in DevOps, Cloud Engineering, or Site Reliability Engineering.

At first, it can feel like a collection of disconnected terms and protocols. But once you understand how DNS, IP addresses, TCP/IP, Packet Switching, and HTTPS work together, the internet starts to make much more sense.

If you're just beginning your DevOps journey, don't focus solely on memorizing definitions. Focus on understanding the complete flow of a request—from your browser to the server and back again.

That's when networking truly starts to click.

# Reflection – Week 2

Adeje Oluwatobiloba — Fri, 10 Jul 2026 09:23:11 +0000

"Shifting from Prompt Engineering to Infrastructure Orchestration"

Week 2 was a mix of excitement, curiosity, and a little bit of frustration. I learned a lot of new concepts, but I also realized that the best way to understand them is by actually trying them out. Reading or watching tutorials helps, but experimenting with the tools made everything click for me.

One of the topics I enjoyed learning about was Claude Code. Before this week, I mainly thought of AI as something that answers questions or helps write content. Seeing how Claude can assist with coding, debugging, and understanding projects made me see it differently. It feels less like a search engine and more like someone you can work with while building something. That really changed how I think about using AI in development.

Another interesting topic was Skills. I liked the idea that you can give an LLM specific skills so it behaves more like a specialist instead of a general assistant. It made me realize that the quality of the output doesn't only depend on the model itself, but also on how you guide it and what tools or skills you give it. That was something I hadn't really thought about before, and I can already see how useful it could be for different types of projects.

I also learned about Subagents, which was a new concept for me. At first, I didn't really understand why you would need multiple agents instead of just asking one AI to do everything. But after learning more about it, I started to see the benefit. Having different agents focus on different tasks seems like a much cleaner and more organized way to work, especially for bigger projects.

The biggest challenge I faced this week was running out of tokens while practicing. It happened a few times, and honestly, it was a little annoying because I would be in the middle of exploring an idea and suddenly had to stop. Even though it was frustrating, it also made me think more carefully about how I write prompts and how I use my conversations. I learned that being clear and intentional can make a big difference.

Despite the challenges, there was one moment this week that I’m really proud of. I was working on setting up infrastructure, and seeing my Terraform files get generated automatically by the AI felt incredible. However, it didn't work perfectly right away and threw an error. Instead of panicking or blindly asking the AI to fix it, I took a step back, read the error output carefully, and figured out how to fix it myself. Actually understanding what went wrong and resolving it was a huge confidence booster.

This week also changed my mindset a bit. I realized that it's okay not to understand everything immediately. Some of the concepts felt overwhelming at first, but after trying them myself, they became much easier to understand. I'm starting to feel more comfortable experimenting instead of worrying about getting everything right the first time.

Going forward, one habit I want to build is working on more hands-on projects with Claude instead of only learning the theory. I think building small projects and experimenting with different features will help me remember what I've learned much better than just reading about them. I also want to keep challenging myself by trying new ideas, even if they don't work perfectly on the first attempt.

Overall, Week 2 helped me see AI as more than just a tool for answering questions. I'm beginning to understand how it can become a real partner in learning and building projects. There were definitely some challenges along the way, but they were part of the learning experience, and I'm looking forward to seeing what I'll be able to build as I keep practicing.

This post is part of the DevOps Micro Internship (DMI) with Agentic AI — Cohort 3 — by Pravin Mishra. My graded progress is public: https://dmi.pravinmishra.com/s/Tobilee10.html · Start your DevOps journey: https://dmi.pravinmishra.com/?utm_source=student&utm_medium=ps-linkedin&utm_campaign=cohort3

DevOps Success Mindset

Adeje Oluwatobiloba — Thu, 02 Jul 2026 21:37:08 +0000

The DevOps Mindset: Build Yourself Before You Build Systems

We often measure growth in DevOps by the tools we know namely Docker, Kubernetes, Terraform, GitHub Actions, Ansible, cloud platforms, and everything in between. While mastering these technologies is important, they're only part of the equation.

The most valuable system you'll ever build isn't running in the cloud. It's the one that shapes how you think, learn, solve problems, and grow as an engineer.

Tools will change. Principles won't.

Here's the mindset that has become increasingly important to me as I continue my journey in DevOps.

Long-Term Thinking
There are no overnight experts in DevOps.
Every deployment, failed pipeline, production issue, and late-night debugging session teaches something valuable. These experiences compound over time, shaping both your technical skills and your confidence.
Instead of chasing rapid progress, focus on becoming slightly better every day. Consistency will always outperform short bursts of motivation.
Remember: careers are built one commit, one project, and one lesson at a time.
Think Like an Engineer, Not Just a Tool User
Knowing commands is useful. Understanding systems is invaluable.
Great engineers don't jump straight to solutions—they investigate first. They rely on logs, metrics, monitoring data, and evidence instead of assumptions. They ask why before asking how.
When something breaks:
a. Stay calm.
b. Gather information.
c. Identify the root cause.
d. Improve the system so the same problem is less likely to happen again.
DevOps isn't about fixing the same issue repeatedly; it's about building systems that prevent it from happening in the first place.
Build More Than You Consume
Tutorials are a great starting point, but they shouldn't be your destination.
The fastest way to grow is to build.
Create projects that challenge you. Experiment with new technologies. Break things in your lab environment. Document your discoveries, even when they don't go as planned.
Every GitHub repository, technical article, and project becomes evidence of your progress.
Your portfolio should speak before your résumé does.
Protect Time for Deep Work
Modern engineering comes with endless distractions—notifications, meetings, social media, and constant context switching.
Real progress happens when you dedicate uninterrupted time to meaningful work.
Whether you're debugging Kubernetes, writing Terraform modules, or designing a CI/CD pipeline, focus on one important objective at a time.
Quality engineering requires attention, not multitasking.
Stay Curious and Adaptable
Technology evolves faster than job titles.
The tools you rely on today may be replaced tomorrow, but the ability to learn will always remain valuable.
Be willing to question old habits, embrace better practices, and remain teachable regardless of your experience.
The best engineers don't know everything.
They simply never stop learning.
Collaboration Is a DevOps Superpower
DevOps isn't just about automation.
It's about people.
The best solutions emerge from clear communication, thoughtful documentation, constructive feedback, and shared ownership.
Write documentation that helps the next engineer.

Review code with respect.
Share knowledge freely.
Celebrate team success, not just individual achievement.
Strong systems are built by strong teams.
Measure Progress, Not Perfection

At the end of each week, ask yourself:

Did I build something meaningful?
Did I learn something new?
Did I improve an existing process?
Did I document or share what I learned?
Did I help someone else grow?
Did I take care of my health and maintain a sustainable pace?

You don't need a perfect week.
You just need more good weeks than bad ones.

Final Thoughts
DevOps is often associated with automation, cloud infrastructure, containers, and deployment pipelines.
But beneath every reliable system is an engineer who has developed discipline, curiosity, resilience, and a commitment to continuous improvement.

Invest in your technical skills.
Invest even more in your mindset.
Because tools will evolve, platforms will change, and frameworks will come and go.
A growth mindset, strong engineering principles, and consistent execution will remain your greatest competitive advantage.
Build systems that scale.
Build habits that last.
And never stop building yourself.

What mindset has had the biggest impact on your growth as an engineer? I'd love to hear your thoughts in the comments.