DZone Spotlight

Wednesday, July 9 View All Articles »

Stop Prompt Hacking: How I Connected My AI Agent to Any API With MCP

By Christina Lin

CORE

In Part 1 of this series, I laid out the high-level architecture for my "InstaVibe Ally" and made the case for building a team of specialist AI agents instead of a single, monolithic brain. I sketched out a system where an Orchestrator delegates tasks to a Social Profiler, a Planner, and a Platform Interaction Agent. Now, I'm going to zoom in on one of the most critical, practical challenges you’ll face: How do you actually let your agent use your application's APIs? An AI agent, powered by a Large Language Model (LLM) like Gemini, is a master of language and reason. But by default, it's a brain in a jar—isolated from the real world of your applications. It can't update a Salesforce record, book a flight, or, in my case, post an event to the InstaVibe platform. To do useful work, it needs to connect with the code I've already built. The first instinct for many developers is to start prompt-hacking. You try stuffing API documentation, cURL commands, and examples directly into the agent's prompt. Let’s be honest, this feels clever for about five minutes, and then it becomes a maintenance nightmare and a pile of technical debt. Every time your API changes, you have to hunt down and update every single prompt that uses it. You’re tightly coupling your agent's logic to your API's implementation details, and it will come back to bite you. This is not the way. The solution for me was the Model Context Protocol (MCP). MCP is an open standard that acts as a structured, standardized bridge between an AI agent and any external tool. It's the universal adapter that lets you plug your application's existing capabilities directly into your agent's brain, without creating a messy, unmaintainable prompt. Let's dive into exactly how I used MCP to transform my own internal REST APIs into a set of clean, discoverable tools for my Platform Interaction Agent. The Problem: My Agent on the Outside, My API on the Inside My InstaVibe application, like most modern web apps, has a standard set of internal REST endpoints. For this feature, I cared about two in particular: POST /api/posts for creating a new social post.POST /api/events for creating a new event. My goal was to allow my agent to call these endpoints intelligently. It needed to be a first-class citizen of my application ecosystem, not a guest who has to be told how to do everything. I wanted the agent to take a user's request like, "Post a positive message from Julia about her new cat!", and have it translate that into a well-formed, secure API call to my existing service. To do this cleanly, I introduced the MCP Tool Server. You can think of it as a dedicated microservice that acts as an API proxy specifically for my agents. It's an integration hub, a translation layer, and a security gateway all in one. The architecture is simple but powerful, and I love it for a few key reasons: Separation of concerns. It only communicates with my MCP Tool Server. It has no idea the InstaVibe API even exists.Easy to introduce security. My MCP Tool Server is the only component that communicates directly with the internal InstaVibe API and acts as a centralized security control point. This completely decouples the agent from the application. The agent's world is simple: it just knows about tools. The application's world is unchanged: it just serves its API. The MCP server is the bridge that connects them, and that separation makes your life a whole lot easier down the road. Step 1: Write a Function, Not a Prompt The first thing I did was create a clean separation of concerns. My agent shouldn't have to think about HTTP methods, headers, or authentication. That's application logic. So, on my MCP server, I wrote simple Python functions that represent each tool I wanted to expose. These wrappers handle all the ugly details. For example, here’s the wrapper for my create_post API. It's the only place where the requests library and the API's URL are mentioned. Python def create_post(author_name: str, text: str, sentiment: str): """ Sends a POST request to the /posts endpoint to create a new post. This function encapsulates the API call logic. """ url = f"{BASE_URL}/posts" headers = {"Content-Type": "application/json"} payload = { "author_name": author_name, "text": text, "sentiment": sentiment } try: response = requests.post(url, headers=headers, json=payload) response.raise_for_status() # Raise an exception for bad status codes print(f"Successfully created post.") return response.json() except requests.exceptions.RequestException as e: print(f"Error creating post: {e}") return None Look how clean that is! My agent will never see a URL or an HTTP header. It will only know about a tool called create_post, along with the arguments they need. Step 2: Build the MCP Server—The Agent's New Best Friend With the wrapper functions ready, the next step was to build the MCP Server itself. It’s a lightweight web application (I used FastAPI, which is great for this) that implements two fundamental endpoints defined by the MCP standard: list_tools(): This is the discovery mechanism. You can think of it as the "handshake." When an agent first connects, it calls this endpoint to ask, "Hey, what can you do?" The server responds with a machine-readable list of all available tools (create_post, create_event), their descriptions, and, most importantly, a JSON Schema for their arguments. This schema is critical—it tells the LLM exactly what parameters are needed and what their data types are, which drastically reduces errors and hallucinations.call_tool(name, arguments): This is the execution endpoint. After the agent has decided which tool to use (based on the user's request and the info from list_tools), it calls this endpoint and says, "Okay, do this." It sends the tool's name and a dictionary of arguments. The server then acts as a router, finds the matching Python function I wrote in Step 1, and executes it. I packaged this MCP server into a Docker container and deployed it to Cloud Run. Now it has its own unique, publicly accessible URL and runs as an independent microservice. Step 3: Plug It In—The Easy Part This is where I LOVED using Google's Agent Development Kit (ADK). After all the careful setup of the server, telling the agent to use it was incredibly simple. I didn't need to write a custom client, parse JSON, or deal with any networking logic myself. I just had to point the ADK at my deployed MCP server. Python from google.adk.agents import Agent from google.adk.mcp import MCPToolset, SseServerParams .... async def build_agent_with_mcp_tools(): """Connects to the MCP server and initializes an agent with the discovered tools.""" print(f"Connecting to MCP server at {MCP_SERVER_URL} to fetch tools...") # This single line handles the entire MCP handshake. It connects to the server, # calls list_tools(), gets the definitions, and creates ADK-compatible tool objects. # It's beautiful. tools = MCPToolset( connection_params=SseServerParams(url=MCP_SERVER_URL) ) print(f"Successfully loaded tools: {[tool.name async for tool in tools.tools()]}") # Now I create my agent and pass in the dynamically loaded tools. # The agent's toolset is now whatever the MCP server provides. platform_agent = Agent( model="gemini-2.5-flash", instruction="You are an expert at interacting with the InstaVibe platform using the provided tools.", tools=[tools] ) return platform_agent And just like that—boom! The process is automated and flexible. My agent's toolset is no longer hardcoded. The tool logic is centralized on the MCP server, making it a breeze to update. I've successfully unlocked my existing API for my AI agent without getting tangled in a mess of prompts. What's Next? From Theory to Your Terminal By embracing the Model Context Protocol, I've built a robust and maintainable bridge between my agent's reasoning capabilities and my application's existing API. I've treated AI integration like proper software engineering, and the result is a clean, scalable system. But this is only one piece of the puzzle. My Platform Agent can now talk to my application, but how does the Orchestrator talk to the Platform Agent? What happens when agents need to talk to each other? That’s a job for the Agent-to-Agent (A2A) protocol, and it’s exactly what I’ll cover in Part 3, the final post of this series. In the meantime, reading is great, but building is better. I turned this entire project—from the multi-agent design in Part 1 to the MCP integration I just covered, and even the A2A orchestration I'll discuss next—into a hands-on InstaVibe Multi-Agent Google Codelab. You can build this exact system yourself, step-by-step, and get the gift of simplicity so you can spend less time scrolling and more time coding. You'll get to: Build your first agent with the Agent Development Kit (ADK).Expose your application’s APIs as tools using MCP.Connect your agents with the A2A protocol.Orchestrate the whole team and deploy it to Cloud Run and Vertex AI Agent Engine. It's the perfect way to skip the steep learning curves and see how these powerful concepts work in practice. Give the Codelab a try and drop a comment below with any questions. I'll see you in Part 3. More

12 Principles for Better Software Engineering

By Manas Dash

CORE

These are not just technical tips, but principles that shaped how I learned and think about engineering. Take what’s useful, ignore what isn’t. But remember, being a great developer isn’t only about code. 1. “The Most Elegant Solution Is the One You Never Have to Maintain.” The most effective code is often the code you never have to write. This might sound counter-intuitive, but one of the most profound lessons I've learned is that sometimes, the most effective solution is to avoid writing new code altogether. Example: Before you embark on building a complex feature or system, pause and ask: Does a library, service, or existing component already do this?Can we simplify the problem so much that this feature isn't even necessary?Is there a manual process, or a simpler, non-technical solution, that would suffice for now? Often, the cost of maintaining, debugging, and evolving new code far outweighs the perceived benefit of building it from scratch. PRO-Tip: Prioritize simplicity and reusability. Always look for opportunities to leverage existing solutions, whether internal or external. Question the necessity of every line you write. The less code you have, the less there is to break, and the easier it is to maintain and evolve. 2. “Tools Are Servants of Your Ideas, Not Their Masters.” Master Your Tools, But Don't Worship Them. Just as a master does, great software engineers understand their tools—languages, frameworks, IDEs, and deployment pipelines. However, the tools are a means to an end, not the end itself. Example: Python is a powerful language, Django a robust framework. But relying solely on them without understanding the underlying principles of web development, databases, or algorithms can lead to chaos and inefficient systems. The true master can pick up a new language or framework with relative ease because they grasp the fundamental concepts that transcend specific technologies.PRO-Tip: Dive deep into how your tools work. Understand their strengths and weaknesses. But also, regularly explore new tools and paradigms. This prevents dogma and keeps your mind agile. Don't be afraid to leave a comfortable tool behind if a newer, better one emerges, but only after careful consideration and understanding. 3. "Perfect Is a Moving Target; Value Is When You Release." Know When to Ship, and When to Refine. Perfection can stop you from doing good work, But careless work will ruin long-term success. A true expert knows how to strike the right balance. Example: Google's "launch early and iterate" philosophy is a testament to this. They release products when they are "good enough" and then refine them based on real-world user feedback. On the other hand, critical infrastructure like medical software or aerospace systems demands an extremely high level of initial polish and rigorous testing before deployment.PRO-Tip: Understand the context of your project. For a new feature, aim for a Minimum Viable Product (MVP) to get feedback quickly. For core, critical systems, invest more upfront in design, testing, and robustness. Always strive for quality, but be pragmatic about where to apply your greatest efforts. Sometimes, a quick-and-dirty solution today allows you to deliver value and learn, which informs the truly elegant solution tomorrow. 4. “Programs Must Be Written for People to Read, and Only Incidentally for Machines to Execute.” — Harold Abelson Understand the Business, or the Code Won’t Matter: You must understand the business first. If you don’t know what problem you’re solving or who your work is for, your code won’t matter, no matter how perfect it is. Knowing the business gives purpose to your code and makes it truly valuable. Example: Google PageRank Algorithm Solved a business-critical problem: surfacing the most relevant content.Original paper:The Anatomy of a Large-Scale Hypertextual Web Search EnginePRO-Tip: Always ask: What real-world outcome will this produce? 5. “Any Fool Can Write Code That a Computer Can Understand. Good Programmers Write Code That Humans Can Understand.” — Martin Fowler Write your code as a gift to the next engineer who reads it. Your future teammates will thank you for clear, thoughtful code that’s easy to read and maintain. Example: Django Codebase Famous for clarity and explicitness.Example urls.py:Django URLconf ExamplePRO-Tip: Leave docstrings: Python def get_user_profile(user_id): """ Retrieve the user profile based on the given user ID. Returns None if the profile does not exist. """ 6. “The Most Dangerous Phrase in the Language Is: ‘We’ve Always Done It This Way.’” — Grace Hopper Every line of code has a story behind it—why it was written, what problem it solves, and how it fits into the bigger picture. Respect that history before you change or remove anything as understanding the story helps you make better decisions. Example: Linux Kernel Git History Rich commit logs spanning decades.Browse online:Linux Kernel Git RepositoryPRO-Tip: Use git blame: GitHub Flavored Markdown git blame -L 50,70 -- path/to/file.c …and see who changed those lines and why. 7. “Premature Optimisation Is the Root of All Evil.” — Donald Knuth Choose the Right Abstraction—Not the Most Abstract One. Pick the right level of abstraction for your code, not the fanciest or most complicated one. The goal is to make your design clear and practical, not to impress people. Good abstractions solve real problems without adding confusion. Example: Python collections module Simple, practical structures instead of overengineering.Docs:collections — Container DatatypesPRO-Tip: Sometimes a list is better: Python words = ["apple", "banana", "cherry"] 8. “The Biggest Problem in Communication Is the Illusion That It Has Taken Place.” — George Bernard Shaw Communication is the most underrated skill in engineering. You can write great code, but if you can’t clearly explain your ideas, share your decisions, or ask for help, your work will suffer. Good communication makes teams stronger and projects more successful. Example:Stripe API Documentation Clear and approachable examples.See it live:Stripe API ReferencePRO-Tip: Write a README.md: Markdown # Payment Processor This module validates and charges credit cards via the Acme API. ## How to Use 1. Configure credentials. 2. Call `charge()`. 3. Handle exceptions. 9. “Debugging Is Twice as Hard as Writing the Code in the First Place.” — Brian Kernighan Good logs are like time machines. They let you travel back and see exactly what happened in your system when things go wrong. Clear, detailed logs save you hours of guessing and help you fix problems faster. Example: Airbnb Postmortem Culture They publish internal retrospectives to learn from incidents.Example (summary): Airbnb’s engineering team practices blameless, detailed postmortems using a custom incident-tracking tool to document both failures and successes, fostering a culture of continuous learning and improvement.This video, 12 essential logging best practices, explains how to make your logs more useful, structured, secure, and scalable for easier debugging and monitoring. PRO-Tip: Use structured logging: Python import logging logger = logging.getLogger(__name__) logger.info("Processing order", extra={"order_id": order.id, "user_id": user.id}) 10. “If You Want to Go Fast, Go Alone. If You Want to Go Far, Go Together.” — African Proverb You Grow When Your Team Grows. The real measure of your skill is how much stronger everyone becomes because you were here.” Example: Apache Software Foundation Thousands of contributors mentored into maintainers.See their project governance:Apache Project Maturity ModelPRO-Tip: Pair-program, document decisions, encourage questions. 11. “Code With Purpose, Design With Clarity, Build With Care—This Is How Good Engineers Create Lasting Impact.” Engineering isn’t just solving problems — it’s solving the right problems, in the right way, for the right reasons.” Example: Git’s Design A sophisticated internal model but simple commands.Linus’s original design notes:Git Design Notes PRO-Tip: Keep interfaces small and focused. 12. “Yesterday’s Expertise Is Today’s Starting Line.” Cultivate a Growth Mindset; The Learning Never Stops Technology is a relentless tide, constantly bringing new waves of innovation. The moment you believe you've learned it all is the moment you start falling behind. Example: The transition from monolithic architectures to microservices, from relational databases to NoSQL, from manual deployments to CI/CD pipelines—these shifts demand continuous learning. The engineers who thrived through these changes were those who embraced new ideas, experimented, and were willing to unlearn old habits.PRO-Tip:Dedicate time, even if it's just a few hours a week, to continuous learning. Read technical books, follow industry leaders, experiment with new technologies, contribute to open source, or even teach others. The act of teaching is one of the most powerful ways to solidify your own understanding. Keep learning. Keep teaching. Keep building. More

Trend Report

Software Supply Chain Security

Gone are the days of fragmented security checkpoints and analyzing small pieces of the larger software security puzzle. Today, we are managing our systems for security end to end. Thanks to this shift, software teams have access to a more holistic view — a "full-picture moment" — of our entire software security environment. In the house that DevSecOps built, software supply chains are on the rise as security continues to flourish and evolve across modern software systems. Through the increase of zero-trust architecture and AI-driven threat protection strategies, our security systems are more intelligent and resilient than ever before. DZone's Software Supply Chain Security Trend Report unpacks everything within the software supply chain, every touchpoint and security decision, via its most critical parts. Topics covered include AI-powered security, maximizing ROI when it comes to securing supply chains, regulations from a DevSecOps perspective, a dive into SBOMs, and more.Now, more than ever, is the time to strengthen resilience and enhance your organization's software supply chains.

Refcard #267

Getting Started With DevSecOps

By Akanksha Pathak

CORE

Refcard #394

AI Automation Essentials

By Tuhin Chattopadhyay

CORE

*You* Can Shape Trend Reports: Join DZone's Data Engineering Research

Hey, DZone Community! We have an exciting year of research ahead for our beloved Trend Reports. And once again, we are asking for your insights and expertise (anonymously if you choose) — readers just like you drive the content we cover in our Trend Reports. Check out the details for our research survey below. Data Engineering Research Across the globe, companies are leveling up their data capabilities and analytics maturity. While organizations have become increasingly aware of the copious new technologies at our disposal, it's now about how we can use them in a thoughtful, efficient, and strategic way. Take our short research survey (~10 minutes) to contribute to our upcoming Trend Report. Did we mention that anyone who takes the survey will be eligible for a chance to enter a raffle to win an e-gift card of their choosing? We're exploring key topics such as: Driving a data-centric cultureData storage and architectureBuilding a robust AI strategyStreaming and real-time dataDataOps trends and takeawaysThe future of data pipelines Join the Data Engineering Research Over the coming month, we will compile and analyze data from hundreds of respondents; results and observations will be featured in the "Key Research Findings" of our upcoming Trend Report. Your responses help inform the narrative of our Trend Reports, so we truly cannot do this without you. Stay tuned for each report's launch and see how your insights align with the larger DZone Community. We thank you in advance for your help! —The DZone Content and Community team

By DZone Editorial

How to Build Your First Generative AI App With Langflow: A Step-by-Step Guide

As you all know, Generative AI is reshaping how we build certain applications — but diving into LangChain code or orchestrating complex pipelines can be intimidating for newcomers. That’s where I feel Langflow comes in very handy for first-timers trying to explore and build such applications. Langflow is a low-code, visual interface that lets you prototype and deploy LLM-powered applications without writing a single line of backend code. Whether you're building a chatbot, a document summarizer, or a custom retrieval-augmented generation (RAG) app — Langflow lets you do it visually and quickly. In this tutorial, I will walk you through building your first GenAI app using Langflow, step-by-step — no prior LangChain experience needed. Why Langflow? Before we dive in, let’s briefly understand what makes Langflow appealing: No Backend Coding Required: Build apps without diving deep into Python or LangChain syntax.Rapid Prototyping: Drag, drop, and connect blocks to test ideas instantly.Modular and Extensible: Mix and match components like embeddings, loaders, memory, and LLMs.Visual Debugging: Inspect node-level inputs and outputs at any stage of your flow.Multi-model Support: Integrate OpenAI, Cohere, HuggingFace, PaLM, and more.Built for Collaboration: Share flows or export them for integration with teams. Langflow is especially valuable for: Data scientists prototyping quicklyDevelopers avoiding boilerplateProduct teams doing proof-of-conceptsEducators and researchers demoing concepts Prerequisites Before we begin, make sure you have: Basic understanding of LLMs (like GPT)A working Python environment (Python 3.8+)OpenAI API key (or any supported LLM provider)Node.js and npm installed (optional for advanced deployment or front-end integration) Step 1: Install Langflow (You Can Either Use Python or Datastax) You can install Langflow using pip. It’s as easy as: Python pip install langflow #Once installed, run the app: langflow run It will start a local server on http://localhost:7860, where you can start building your app visually. This web interface is where you’ll design, test, and deploy your GenAI workflows. Pro Tip: Create a virtual environment (venv) before installing Langflow to avoid dependency conflicts with other Python projects. Step 2: Design Your App Flow Visually Langflow gives you a drag-and-drop canvas to build your app. Let’s say you want to build a PDF summarizer: Drag in a FileLoader node (like PyPDFLoader)Connect it to a Text SplitterFeed that into an Embedding GeneratorStore embeddings in a Vector Store (like FAISS)Link the store to a RetrievalQA ChainAdd an LLM block (e.g., OpenAI or HuggingFace)Connect to an Input/Output Interface for users The UI makes it super intuitive — no manual coding required. Step 3: Add Your LLM Credentials Click on the LLM node in your flow, and paste your OpenAI API key or use another supported provider. Langflow supports the following (I used OpenAI GPT 3.5 for my app): OpenAI (GPT-3.5 / GPT-4)HuggingFaceCohereGoogle PaLMAzure OpenAIAnthropic Claude (via API endpoints) Step 4: Test Your Flow Hit “Run” or test specific nodes in isolation. You’ll instantly see how the data flows through your pipeline. You can debug each block and inspect outputs — perfect for understanding how your app works. Step 5: Deploy or Export Your Flow There are different ways. Langflow supports: Exporting to JSON or Python codeRunning locally as a Python scriptDeploying as a FastAPI appOr, integrating with a front-end using APIs To export your project: Python langflow export my_app.json langflow convert my_app.json --to=python Build a Chatbot UI (Optional) Langflow can integrate with: StreamlitReact.jsGradio Want to build a chatbot interface? Just connect your app’s backend with a frontend using Streamlit: Python import streamlit as st user_input = st.text_input("Ask your PDF:") if user_input: response = call_langflow_pipeline(user_input) st.write(response) And that’s it! You now have a working GenAI app that you can tweak, enhance, or scale. Troubleshooting Tips Issue Solution "Cannot find module" Reinstall dependencies or check Python path Slow execution Reduce chunk size or limit input tokens API errors Verify keys, rate limits, and model availability UI not loading Restart server or clear browser cache Real-World Use Cases Legal Document Analyzer – Summarize clauses, search precedents, answer queries.Internal Knowledge Base – Load company docs and chat with them securely.Sales Enablement Tool – Summarize competitor reports, generate scripts.Academic Research Assistant – Digest papers and generate citations.Customer Support Assistant – Pull from FAQs, manuals, tickets for real-time resolution. Enterprises are using Langflow to rapidly prototype internal tools, MVPs, and AI assistants — cutting down dev cycles by weeks. Wrapping Up Langflow lets you go from idea → prototype → deployment in minutes. For developers and teams trying to bring AI to their apps quickly, it’s a game-changer. With its visual flow editor, LLM integration, and plug-and-play tooling, it abstracts away much of the boilerplate that typically slows down GenAI development. TL;DR Step 1: Install Langflow via pip - Langflow is available on PyPI and can be installed with a single command.Step 2 : Design your app visually - Langflow lets you build GenAI apps by connecting modular components together on a canvas — similar to how you'd wire up nodes in a no-code workflow tool.Step 3 : Plug in your LLM API key - Langflow supports a range of providers out of the box. You can also switch models or test multiple providers to compare performance.Step 4 : Test each Component - This granular level of testing helps debug complex pipelines before they go live. It’s especially useful when chaining multiple tools like document loaders, retrievers, and memory modules. Step 5 : Export or deploy your app -Once your app is working as expected, you have several deployment options.Step 6 : Add a Front-End UI - To make your GenAI app more user-friendly and interactive, you can easily integrate Langflow with popular front-end frameworks. Langflow supports seamless integration with Streamlit, React.js, and Gradio, allowing you to build intuitive interfaces for end users. Learn More Langflow GitHubLangChain DocumentationStreamlitDZone AI Zone

By Diganta Sen Gupta

Stop Building Monolithic AI Brains, Build a Specialist Team Instead

You’ve been there. You’ve got a killer app idea, and you want to sprinkle in some AI magic. The first instinct? Build a single, massive AI model—a "genius brain" that can handle anything a user throws at it. But let's be real, as soon as things get even a little complex, that approach starts to fall apart. Your "genius" model becomes a jack-of-all-trades and a master of none. It gets confused, it becomes a massive bottleneck when traffic spikes, and trying to update one part of its knowledge is a complete nightmare. Sound familiar? That’s the exact wall I hit. Let me explain. The Problem: Turning 'Likes' into Actual Plans So, let me set the scene. "InstaVibe" is my fictional social events platform. Think of it as a place where you discover cool things happening in your city—concerts, pop-up markets, sports games—and see which of your friends are interested. It's great for discovery. But here's the catch I kept seeing in our user data: discovery wasn't translating into action. A user and their friends would all "like" an event, but the conversation to actually plan on going would move to a messy group chat on another app. The coordination—picking a time, getting RSVPs, making a decision—was a huge point of friction. I knew I could solve this with AI. But I didn't want to just bolt on a generic chatbot that could answer basic questions. I wanted to build a true digital assistant, something I call the "InstaVibe Ally." It needed to be smart enough to understand the user's friend group, do the tedious research for them, and handle the logistics of creating the event right on our platform. And that's a job too big for any single AI. The Case for a Team: Why Specialists Beat a Generalist Think about building a new software feature. You wouldn't hire one person and expect them to be the DBA, backend dev, frontend dev, and UI/UX designer, right? You’d build a team. So why are we trying to make our AIs do everything at once? It’s time to apply the same logic to our intelligent systems. For my "InstaVibe Ally" feature, I needed to understand social graphs, research real-world events, and call our platform's APIs. A single AI trying to do all that would be a mess of constant context-switching. A multi-agent system, however, offered clear advantages: Specialization Saves Your Sanity: Identified the core jobs-to-be-done and built a specific agent for each one. This modularity makes everything cleaner and easier to manage.The Orchestrator (The Project Manager): This agent’s only job is to understand the user's high-level goal (e.g., "plan a fun weekend for my friends and me") and delegate the work. It coordinates, it doesn't execute.The Social Profiling Agent (The Data Nerd): This agent is an expert in our Spanner Graph Database. It’s a beast at running complex queries to figure out social connections and shared interests. It knows nothing about Google Search or our platform APIs, and that’s the point.The Event Planning Agent (The Creative Researcher): This one is the "boots on the ground." It’s an expert at using external tools like Google Search to find cool venues, check opening times, and find fun activities in real-time.The Platform Interaction Agent (The API Guru): Its entire world is the InstaVibe platform API. It's a master of creating posts, sending invites, and updating events. It’s the hands of the operation. Scalability and Resilience(The Microservices Advantage): Because each agent is its own service, they can scale independently. If we get a flood of users planning trips, the Event Planning Agent can scale up to handle the load without affecting the other agents. If the Social Profiler hits a bug, it doesn’t take the whole system down with it. This makes your life so much easier during production incidents. Evolve, Don't Rebuild: This architecture is built for the future. Want to swap out Google Search for a new, specialized API on the Planning Agent? No problem. Just deploy the new agent. As long as it speaks the same "language" as the Orchestrator, the rest of the system doesn't even need to know. Good luck doing that with a monolithic AI. Bringing the AI Team to Life on Google Cloud An architecture diagram is nice, but making it real is what matters. Google Cloud provides the perfect toolkit to host, connect, and manage this AI team without the usual infrastructure headaches. Here’s a look at the stack and how I put it together. Cloud Run: The Home for Each Specialist Agent To make our agents truly independent, I packaged each one—the Planner, Social Profiler, and Platform Interactor—into its own Docker container and deployed it as a separate service on Cloud Run. I love Cloud Run for this because it’s serverless, which means less work for us. I get: Unique HTTPS endpoints for each agent out of the box.Automatic scaling from zero to… well, a lot. This saves a ton of money because I only pay when an agent is actually working.A fully managed environment. No patching servers, no configuring VMs. More time coding, less time managing infra. This isn't just a logical separation; it's a physical one. Our architecture diagram is now a reality of distinct, scalable microservices. Spanner as a Graph Database: The Shared Knowledge Base Our Social Profiling Agent needs to be brilliant at understanding relationships. For this, I used Spanner. I leveraged its graph capabilities. Instead of flat, boring tables, I modeled our data as a rich graph of Users, Events, and Friendships. This lets our agent ask incredibly powerful questions like, "Find common interests for all friends of User X who also went to Event Y." This is the kind of intelligence that makes the recommendations feel magical, and it’s all built on a globally-distributed, strongly consistent foundation. Vertex AI: The Command Center Vertex AI serves as the hub for our AI operations, providing two critical components: Gemini Models: The cognitive engine—the actual "smarts"—inside every single agent is a Gemini model. I chose it specifically for its incredible reasoning skills and, most importantly, its native support for tool use (also known as function calling). This is the magic that allows the model to intelligently decide, "Okay, now I need to call the find_events tool" and pass the right arguments. It’s what turns a language model into a true agent.Agent Engine: While the specialists live on Cloud Run, I deployed the Orchestrator to Vertex AI Agent Engine. This is a fully managed, purpose-built environment for hosting production agents. It handles the immense complexity of scaling, securing, and managing the state of conversational AI. By deploying our Orchestrator here, I get enterprise-grade reliability that abstract away the infrastructure so I can focus on the agent's logic. I’ve designed our team of AI specialists and given them a home on Google Cloud. But how do they talk to each other and to the outside world? This is where a set of standardized protocols comes into play, forming the nervous system of our architecture. The Nervous System: How They All Talk I’ve designed our team of AI specialists and given them a home on Google Cloud. But how do they talk to each other and to the outside world? This is where a set of frameworks and standardized protocols comes into play. In the workshop that this post is based on, we used: Google's Agent Development Kit (ADK) to build the core logic of each agent.The Model Context Protocol (MCP) to allow agents to use external tools, like our own InstaVibe APIs.The Agent-to-Agent (A2A) protocol to let the agents discover and delegate tasks to each other. So, What's Next? Now, this isn't just a theoretical design I dreamed up. It's the exact architecture we built, step-by-step, in a comprehensive Google Codelab. This blog post is the story behind that workshop, explaining the 'why' behind our technical choices. But there's so much more to unpack. The real magic is in the details of the communication protocols, so I'm planning two more deep-dive posts to follow this one: The API-to-Tool Pipeline (MCP Deep Dive): How do you securely let an agent use your own internal APIs? In my next post, I’m going to focus on the Model Context Protocol (MCP). I'll show you exactly how we built a custom MCP server to wrap our existing InstaVibe REST endpoints, effectively turning our platform's functions into tools any agent can use.The Agent Intercom (A2A Deep Dive): After that, we'll tackle the Agent-to-Agent (A2A) protocol. We’ll explore how our Orchestrator uses "Agent Cards" to discover its teammates, understand their skills, and delegate complex tasks across a distributed system. But you don't have to wait to get your hands dirty. If you're itching to see how this all fits together, you can build the entire system right now. The Codelab takes you through everything: Building your first agent with the Agent Development Kit (ADK).Exposing your application’s APIs as tools using MCP.Connecting your agents with the A2A protocol.Orchestrating the whole team and deploying it to Cloud Run and Vertex AI Agent Engine. It's the perfect way to skip the steep learning curves and see these powerful concepts in practice. Stop scrolling and start coding!

By Christina Lin

CORE

Are Traditional Data Warehouses Being Devoured by Agentic AI?

From a technical architecture perspective, I believe this wave of AI will profoundly reshape the entire software ecosystem. DSS systems are designed around the logic of human decision-making as the ultimate consumer. However, with the advent of the Agentic AI era, the final "consumer" is more likely to be an agent. This will lead to a complete redesign—or even elimination—of traditional data warehouses and complex ETL pipelines. Conventional data warehouses emphasize structure and query patterns, but they will be replaced by Agentic Data Stack architectures that focus on semantics and response patterns. Introduction: The Signal Behind Snowflake’s CEO Change In the spring of 2024, Snowflake, a star in the cloud data warehouse space, announced a change in leadership: Sridhar Ramaswamy, former head of Google’s advertising business, succeeded the legendary CEO Frank Slootman, who had helped Snowflake reach a $60 billion valuation. If you think this is just a routine executive shuffle, you're not seeing the full picture. The real implication is that the paradigm of the data warehouse world is undergoing a quiet yet profound transformation. Technological evolution is never linear—it's about leaps. From OLTP databases to MPP data warehouses, from localized MPP computing to vectorized cloud data engines, each stage represents a leap to the next generation of technology—and from one dominant product to the next. Slootman represented the "golden age of data warehousing." He bet on cloud-native, multi-tenant architectures and positioned Snowflake as the central hub of the next-generation data platform. Under his leadership, Snowflake directly disrupted my first employer—Teradata, the former data warehouse giant—which saw its market value plummet from $ 10.2 billion to just $2 billion. As he stepped down, the keywords on Snowflake’s official blog shifted to: AI-first, agent-driven, and semantically-oriented data architecture. This is no coincidence—it’s a sign of the times. At the same time, the most forward-thinking VCs in Silicon Valley are betting on a new concept: “Agentic AI.” In this new paradigm, AI is no longer just a model—it’s an agent that can perceive, act, set goals, and collaborate. So here’s the question: When AI is no longer just a “chat tool” but a smart agent capable of sensing business changes, understanding intentions, and executing actions—can traditional data warehouses, designed for humans, still meet the needs of agents? Data warehouses, once considered vital enterprise “data assets,” are now at risk of becoming mere “data material libraries” for agents. Even the term “material” is losing value, because an Agentic Data Stack can directly access raw data and feed it to upper-layer Sales Agents, Risk Agents, and others in a semantic + data format. Meanwhile, the redundant, non-semantic data in traditional warehouses is left for BI tools and data engineers to consume. The real danger isn't just being eliminated—it's that you're still operating by the old rules while the world has already flipped the script. This isn’t about disparaging data warehouses—it's about the recurring cycles of tech history. Just as Hadoop and Iceberg once reshaped the data lake landscape, Agentic AI is now rewriting the enterprise big data architecture. 1970–2024: The Evolution of Data Warehouse Architectures 1970: The Father of Data Warehousing, Bill Inmon Bill Inmon, the “Father of Data Warehousing,” was the first to propose the concept of an EDW (Enterprise Data Warehouse) as a “subject-oriented, integrated, time-variant, and non-volatile collection of data,” laying the foundation for enterprise data architecture over the next half-century. I was fortunate to study and participate in the translation of the first edition of Building the Data Warehouse more than 20 years ago during my time at Peking University under the guidance of Professor Tang Shiwei. This book's descriptions of subject areas, data layering architecture, and slowly changing dimensions (historical tables) have endured from the last century to today, becoming foundational concepts for data warehousing. 1983: Teradata Is Born: MPP Architecture Takes the Stage In 1983, Teradata Corp. was founded—the company that dominated enterprise data warehouse infrastructure for the next 30 years. This was also my first job after graduation. Teradata was the first to introduce the MPP (Massively Parallel Processing) architecture into data systems. With its tightly integrated software and hardware and Bynet-based MPP design, Teradata significantly outperformed Oracle and DB2 in massive data processing and complex SQL queries. When I joined Teradata, it was still a department under NCR, and my business card looked like this. 1996: Kimball Proposes the “Snowflake Schema”; OLAP Engines Emerge Following Bill Inmon, Ralph Kimball introduced the concept of the “data mart” and redefined data modeling with the star schema and snowflake schema. For the next several decades, data architects continuously debated whether to build a centralized data warehouse or separate data marts first. “Dimensional modeling” and the “snowflake schema” became calling cards for data engineers. At the BI layer, MOLAP engines like Hyperion Essbase and Cognos began to emerge. OLAP technology finally had a systematic methodology to follow. Decades later, a new generation of data warehouse companies even adopted “Snowflake” as their brand name, inspired by the snowflake schema. 2013: The Big Data Boom – Hadoop Takes the World by Storm With the release of Apache Hadoop in 2006, enterprises began widely adopting big data systems with low storage costs. In Big Data: A Revolution That Will Transform How We Live, Work, and Think, Viktor Mayer-Schönberger defined big data with the “4Vs”: Volume, Velocity, Variety, and Value. Photo from 2015: The author William Guo with Viktor Mayer-Schönberger This marked the beginning of a massive wave of big data platform construction. Over the next 10 years, a new generation of big data technologies emerged—Apache Hadoop, Hive, Spark, Kafka, DolphinScheduler, SeaTunnel, Iceberg, and more. Big data platforms began to shake the dominance of traditional data warehouses. In fact, after 2015, most Chinese enterprises dealing with petabyte-scale data storage no longer used traditional MPP data warehouse architectures. Instead, they built their platforms using Hadoop or Iceberg-based big data/data lake architectures. 2015: Snowflake Bursts Onto the Scene, the Modern Data Stack Rises With the rise of the cloud and the release of Marcin Zukowski's paper on “vectorized” engines, Snowflake emerged with a cloud-native architecture that separated compute and storage, completely disrupting traditional data warehouse thinking. For the first time, BI engineers could enjoy elastic scaling “on demand” without worrying about cluster scheduling or resource allocation. Snowflake turned the “data warehouse” into the “data cloud.” It led to the rise of an entirely new generation of data warehouse technology stacks. Tools like Fivetran, Dagster, Airbyte, DBT, and WhaleStudio followed, giving rise to the Modern Data Stack trend in Silicon Valley. Indeed, the previous generation of ETL and data engineering tools—Informatica, Talend, DataStage—originated in the 1980s. The rise of new technologies required a completely new ecosystem. Overall, throughout the past decades, whether it was traditional data warehouses, big data platforms, cloud data warehouses, or data lakes, their architectures all essentially followed the structure shown in the diagram below: In the Inmon era, this architecture was called a DSS system (Decision Support System). As the name suggests, the “support” was always intended for humans. The entire data warehouse tech stack was designed for human users. The architecture of the data warehouse was also designed for data engineers. That’s why we had multiple subject areas, atomic layers, aggregation layers, and metrics layers—to assist ETL engineers in development. BI tools also needed to define star and snowflake schemas, with drag-and-drop interfaces for reports and dashboards. All the consumers were human. But in the era of large-model agents, all of this is about to change dramatically. Are Agents Devouring Traditional Data Warehouses?! At the end of 2022, OpenAI released ChatGPT, kicking off the era of large language models. Since 2023, Llama, Claude, Gemini, GPT-4o, DeepSeek… many LLMs have rapidly evolved. AI is no longer just a language model, but a “general intelligence engine” capable of understanding and making decisions for complex tasks. In 2024, RAG (Retrieval-Augmented Generation) technology went mainstream. Tools like LlamaIndex, LangChain, and Dify gained widespread adoption. AI began integrating enterprise domain knowledge, becoming a truly “knowledgeable assistant.” By 2025, the Agent architecture will have fully risen. Technologies and protocols like AutoGPT, Function Calling, and the MCP protocol have emerged. AI is no longer just a chat tool—it now has perception, planning, and execution capabilities, becoming a “digital employee.” In the data domain, the arrival of large models has also brought major disruption. Have you used ChatGPT’s Data Analyst? If so, you were likely amazed by its performance. It can help a business user generate a detailed analytical report from a dataset from multiple perspectives. It can practically replace a junior data analyst. At various layers, many "automation" tools have also emerged, such as ChatBI and TXT2SQL, each leveraging large models and agents to automate or semi-automate data warehouse development processes. In the future, more and more agents will emerge—not just in data analysis, but also in ad campaign optimization, customer service, and risk management. These agents will gradually liberate business personnel by replacing their interactions with systems. Ultimately, AI will no longer be a “passive answering tool,” but an “intelligent agent proactively achieving goals.” For the past 20+ years, the “users” of data platforms have typically been data engineers, analysts, and BI professionals. In the next 20 years, every role—from analyst to supply chain operator—may be redefined by Agents: Marketers will have a Campaign Agent that automatically integrates multi-channel data, optimizes placements, and generates copy;Customer service reps will have a Support Agent that’s more than a chatbot—it will be a context-aware assistant with knowledge graphs and memory;The supply chain team will have a Procurement Agent that parses orders, tracks delivery timelines, fetches ERP data, and auto-replenishes inventory;Legal teams will have a Compliance Agent, HR will have a Hiring Agent, and even the board of directors could have a Board Agent… The SQL you used to write every day, the reports you compiled, and the ops meetings you attended are all becoming Agent-triggered actions, semantic commands, and automated responses. But a pressing reality follows: If the end users of data are Agents, and even data warehouse development is done by Agents—and the ultimate decision-makers using data are Agents rather than “humans”—does the original DSS (Decision Support System) data warehouse architecture still make sense? Anyone who’s studied software engineering knows the first diagram you draw when designing a system is the “Use Case” diagram—it defines the system’s users, boundaries, and behavior scenarios. When the user of a data warehouse shifts from human to Agent, the DSS architecture envisioned by Bill Inmon no longer holds water. At least in my view, it doesn’t. When the user changes, the software must change, too. The rise of Agents isn’t just a win for large models—it’s a complete disruption of how we perceive the user experience: Traditional data systems operated in a “pull model”: the user knew the problem, queried the data, and extracted conclusions.Future Agents operate in a “push model”: the system proactively senses changes, understands intent, and generates decision suggestions. It’s like moving from traditional maps to GPS navigation: You no longer need to know “where the road is”—you simply tell the system where you want to go, and it takes you there. Traditional data warehouses focus on structure and querying, whereas Agentic architectures prioritize semantics and responsiveness. Put simply: whoever understands business language will rule the data world. Agentic Data Stack and Contextual Data Unit (CDU): Data With Built-In Semantics For Agents to develop and use data automatically, today’s data warehouse design is not suitable—it was never meant for large models or Agents. What’s stored inside are “raw” data—just numerical values and column names. What these values or fields mean is stored in a separate “data asset” management system. Understanding each value or field requires a full-fledged “data governance” project. This design is unfriendly to large models and Agents, which rely on semantic reasoning. So, if we were to redesign a data storage system for Agents and large models, we’d have to store data and semantics together. I call this: Contextual Data Unit (CDU): a dual-element unit combining data + semantic explanation—every data entry carries its meaning with it. It fuses the information traditionally stored in data catalogs directly into each data entry, reducing lookup time and error rate when Agents or large models access it. Meanwhile, the semantics in CDU are derived from business systems—they’re distilled and abstracted by Data Flow Agents at the source. The CDU is formed during ingestion, flowing into an Agentic Data Lake—not generated afterward. In other words, data governance and lineage are embedded in the agent-driven development process itself, not retroactively applied after data has entered the warehouse, avoiding conflict and ambiguity. At this point, you should understand my thinking: in the era of Agentic AI, everything from ETL to storage to data application will be reshaped because the consumers are now Agents and models. To serve these intelligent agents, traditional data platforms must evolve into an Agent-callable, semantically-aware, event-driven architecture—what we call the Agentic Data Stack. Agentic Data Stack: in the Agent era, a new data tech stack that spans from tools to obtain “data + semantics,” to platforms that compute and store CDU-format data, and finally to the interaction layer that delivers this data to Agents. Here’s my bold prediction of what the Agentic Data Stack might include: Semantic Orchestrator (Interaction Layer): This is no longer a BI/dashboard interface, but the “brain” and “command center” of the Agentic architecture. With natural language understanding and semantic reasoning capabilities, it bridges other agents with underlying data assets, enabling intelligent, multi-round interactions and service generation.Data Mesh (Storage Layer): No longer a traditional Data Warehouse or Data Lake—it’s a service-oriented, computation-friendly fusion layer that stores data with semantics. It can supply data for complex computations by LLMs while also supporting real-time processing.Data Flow Agent (Processing Layer): Not just “moving data,” but understanding and orchestrating data. Not scheduled periodically, but event-driven and intent-driven. Capable of detecting data changes, analyzing schemas, understanding business logic, and responding accordingly. In the Agentic AI era, the cycle of building data platforms will drastically shrink. New data is discovered by Data Flow Agents, pre-stored in the Data Mesh, and interpreted by the Semantic Orchestrator with business-aligned definitions—ultimately enabling “instant computation” from business demand to data output. LLMs provide the brainpower. Agents are the hands and feet. Agentic Data Stack gives them the data accessibility needed in the era of large models. With the rise of the Agentic Data Stack, the cost of building next-gen “data warehouses” drops dramatically. Having natural-language query capabilities and access to relevant data won’t just be the privilege of big enterprises—it will become accessible to small businesses and even individuals. You can capture your Google Drive files, home NAS, PDFs on your laptop, and app orders from your phone into your personal data store via a Data Flow Agent. Then ask a question like “How much did I spend visiting Disney last month?”—something that previously required exporting from multiple platforms and manually building Excel sheets. Even more complex queries like “Find my insurance contract from 5 years ago” become doable. And this isn’t fantasy. Recently, under the leadership of WhaleOps, the Apache SeaTunnel community released Apache SeaTunnel MCP Server—already moving toward becoming a Data Flow Agent. Of course, there are still technical hurdles to overcome—like the immature A2A protocols, unproven semantic+data storage models in the Data Mesh layer, and the transformation of legacy governance outputs into inputs for the Semantic Orchestrator. But the arrival of the LLM and Agent era will reshape the data analytics industry just as the invention of SQL once did. It’s never your “visible” competitor who beats you. A story: When I was a kid, two popular bike brands were Forever and Phoenix. They competed over speed via “accelerated axles.” But what disrupted the bike market wasn’t a better bike—it was a food delivery company launching shared bikes, flipping the entire industry. As Agents rise, some core product paths we once believed in may lose meaning. While keeping your head down on execution, remember to look up at the sky. Conclusion: Live in the Present, See the Future When I shared this vision at AICon, AWS Community Day, and other tech summits, the audience always split into two camps. The “Believers” think I’m too conservative in saying Agentic Data Stack is 5–10 years away—they believe AI is evolving so fast that we’ll see it fully formed within 5 years. The “Skeptics” think the impact of AI Agents on data warehouse architecture is wildly exaggerated. They argue that today’s data warehouse designs are the highest-ROI format, and anything less efficient won’t scale commercially—it’s just a pie in the sky. Personally, I’m a “centrist”: I believe the emergence of the Agentic Data Stack is inevitable. This wave of AI will impact software architecture in a way that’s fundamentally different from previous waves. We must look at the total cost and outcome of enterprise data warehouse construction and operations, not just storage or compute ROI alone. Currently, we see trends: the rise of real-time data warehouses, the expansion of data lakes, and the reduction of layers in modern warehouse design. (I’d even argue that now that our generation of Teradata-trained data modeling architects is retiring, the market lacks professionals who can keep up with fast-evolving business logic). So traditional modeling itself is iterating—real-time warehouses now often use 2 layers instead of 3–4. I’m simply pointing out a bigger leap ahead in the Agentic AI era. On balance, the ROI of Agentic Data Stack will likely surpass that of the current Modern Data Stack. It’s not AI that replaces you—it’s the person who knows how to use AI. It’s not that data warehouses are being devoured, but rather their structure-and-query-centric model is being replaced by a semantics-and-response-centric architecture. Just like how once you’ve used GPS, you won’t go back to a paper map. The gates to the Agentic Data Stack are opening. Are you ready?

By William Guo

Leveraging AI: A Path to Senior Engineering Positions

As I sit here, reflecting on my past experiences as a software engineer, I am reminded of the countless hours spent trying to streamline the development processes and improve productivity for the team. It's an issue that plagues many of us, but one that I believe can be addressed with the help of AI agents. I clearly remember when I first encountered AI agents - I was skeptical, to say the least. But as I delved into the world of machine learning and automation together, I began to see the possibilities for these tools to transform the business. After months of experimenting with a variety of AI-powered tools, I am excited to share my findings with the community. At first, I was hesitant to adopt AI agents into the development workflow. I had concerns about accuracy, and the potential for AI to make errors. However, as I began to explore the capabilities of AI agents, I realized that they could augment our work, freeing us up to focus on more complex and creative tasks. I experimented with various AI-powered tools, from chatbots to code generators. I was impressed by their ability to automate repetitive tasks, provide insights, and even assist with debugging. As I worked with these tools, we began to see the potential for AI to revolutionize our industry. Survey Results and Learnings I polled 300+ software development engineers (SDEs) from various companies at our weekly meetups to understand their experience using AI tools in 2025. The distribution of their responses is as follows: 18% shared that they have tried using Code Generation previously but haven't used it again and 35% of the engineers shared they don't use any AI tool other than writing.23% of software Engineers shared that they use AI agents (like Chat GPT or Co-pilot) to write or refactor code. 15% mentioned it's a hassle to integrate end to end. 15% found AI tools a game changer for enhancing productivity and efficiency. 20% have not used AI agents due knowledge gaps or restrictions - "Didn't Realize It Could Do That for Us" or "No Access in Our Workplace Environment". 10% mentioned "Seems Like More Trouble Than It's Worth to Integrate" Hands-On Tinkering With AI Assistants My exploration kicked off with GitHub Copilot. Think of it as that super-helpful pair programmer who anticipates your next line of code, flags potential errors in real-time, and even nudges you with relevant documentation. I was genuinely impressed by its accuracy and speed – it quickly became another tool in our daily arsenal. But the rabbit hole went deeper. I started playing with other AI tools like Kite and DeepCode, and they've not only sped up my workflow but also helped me write cleaner, more maintainable code. It's like having a silent, experienced reviewer constantly looking over your shoulder, offering subtle but valuable suggestions. How to Leverage Approved AI I was looking for ways to optimize our workflows and deliver higher quality with less friction. That's where the approved AI agents come into play – they're practical tools designed to augment our abilities. Take Large Language Models (LLMs), for instance. Here's how they have been used to tangibly improve the code quality and reduce review cycles: Generating Solid Code Blocks: LLMs or GitHub Copilot can help generate high-quality code snippets that actually meet the specified requirements. This allows engineers to focus on the higher-level design and logic, knowing the generated code is likely sound and efficient.Getting an AI Sanity Check on Code: Using GPT 4.0 or Kite offers intelligent code completions, debugging assistance, and project-wide insights. They also perform initial code reviews and provide feedback. It's surprisingly good at catching potential edge cases and suggesting improvements before it even hits a human reviewer's queue. DeepCode on the other hand identifies potential security flaws, performance bottlenecks, and deviations from coding standards.Making Documentation Less of a Pain Point: Tools like Claudia help generate accurate, up-to-date, and easily understandable technical documentation. This makes it much easier to communicate complex technical concepts to both technical and non-technical stakeholders. The real value of AI agents for us engineers boil down to a few key areas: Cutting Down on Repetitive Grind: AI can automate those tedious, repetitive tasks like initial code reviews, basic testing, and even some debugging, freeing us up to focus on the more intellectually stimulating and complex aspects of our work.Building More Robust Systems: AI-powered code analysis tools can help us identify potential errors and security vulnerabilities earlier in the development lifecycle, leading to more stable and secure software.Making Collaboration More Seamless: AI agents can facilitate clearer communication and better collaboration within teams by providing context-aware information and summarizing key discussions.Boosting Our Output: By automating mundane tasks and providing intelligent assistance, AI agents can help us deliver more value in less time. A Path to Senior Engineering Positions More Time for Strategy Building - As Engineers grow in their levels, they shift their focus from short-term deliverables to long-term strategy and goals. There is an 80-20 rule in which Engineers should focus 80% of their time on their current priorities and 20% on future initiatives. AI agents free up the bandwidth from day-to-day tasks, it can help Engineers focus more on long term initiatives which will keep the team on the path of ruthless prioritization and delivering the most impactful work items first. Product Growth - AI agents (company approved agents only) are solid in building contextual understanding and relationship among various workstreams which initially appear disjoint but have commonalities among them. It helps us get more strategic ideas and capitalize on them. For me, I shared several long documents of various workstreams to the company approved AI agent and then asked questions that helped strengthen clarity and gave ideas for road mapping and product expansion.Improved Communication with Leadership and Stakeholders- AI agents can help us with better messaging with leadership interactions. I have gotten several ideas when it comes to phrasing my thought process during 1:1 or leadership strategy review meetings. For instance, I have taken several data driven decisions in projecting the value proposition and growth trajectory of my complex ideas in a simplified and succinct manner. Engineers (eg: from India/China) for whom English is not the first language, AI agents help in writing a more professional project communication. Getting Your Feet Wet With AI When Your Company Isn't Onboard Yet If your current workplace hasn't embraced AI tools, you can still start exploring and building your own understanding: Dive into Online Learning: Platforms like Coursera, Udacity, and edX have fantastic courses on AI and its applications in software development. Invest some time in building a foundational understanding.Experiment with Personal Projects: Use your side projects as a sandbox to try out different AI tools and see how they can streamline your own development process.Connect with the Community: Engage in online forums eg: ChatGPT forum and communities to connect with other engineers who are exploring AI and learn from their practical experiences.Build a Case for Adoption: Demonstrate the benefits of AI tools through small-scale projects to encourage organizational support. Be Mindful of Company Policies - If you consider using external AI tools, especially cloud-based ones, be sure to understand and adhere to your company's policies on data security and the use of external services. Conclusion Artificial intelligence is moving beyond theoretical ideas and is now offering tangible support for engineers. By handling routine tasks, offering smart suggestions, and improving teamwork, AI agents can really boost how efficiently we work and the quality of our software. As technology keeps advancing quickly, it's up to us engineers to be inquisitive, try things out carefully, and see how these AI tools can help us become even better at what we do.

By Rohit Garg

The Evolution of Software Integration: How MCP Is Reshaping AI Development Beyond Traditional APIs

As software engineers, we've spent years mastering the art of API integration. We've wrestled with REST endpoints, debugged authentication flows, and built countless adapters to make disparate systems talk to each other. But as artificial intelligence transforms from experimental technology to production necessity, we're witnessing a fundamental shift in how software systems need to communicate. The API Foundation: A Double-Edged Success Story We need to acknowledge what APIs have helped us accomplish; they helped revolutionize software development by providing standardized ways for systems to interact. For example, the Stripe payment API enabled developers across the world to add complex financial transactions through simple HTTP calls, and GitHub's REST API enabled an entire ecosystem of development tools. These successes shaped how we think about system integration. However, APIs come with inherent limitations that become apparent when building intelligent systems. Traditional APIs are: Stateless by design: Each request exists in isolationFixed in scope: Endpoints are predefined and staticManually integrated: Developers must write custom code for each serviceFragmented in implementation: Different authentication schemes, response formats, and error handling patterns These characteristics work perfectly for traditional web applications where developers control both the integration logic and user experience. However, these traits create obstacles for intelligent systems like AI agents because they need to automatically find and interact with multiple services and tools that match their workflow requirements without human assistance. Enter the Age of Intelligent Agents The rise of large language models like GPT-4 and Claude has unlocked something unprecedented: software that can reason, plan, and act autonomously. These AI agents can understand natural language instructions, break down complex tasks, and coordinate multiple operations to achieve goals. Imagine telling your AI assistant: "Analyze my team's productivity last month, schedule a review meeting with stakeholders, and prepare a summary report." This simple request requires: Accessing project management dataQuerying calendar systemsRetrieving team metricsGenerating documentsSending notifications With traditional APIs, you'd need to pre-build integrations for each service, handle authentication for multiple systems, and write custom logic to coordinate these operations. The agent would be limited to only the integrations you've specifically coded. Model Context Protocol: The Missing Link This is where Anthropic's Model Context Protocol (MCP) enters the picture. Introduced in November 2024, MCP isn't trying to replace APIs—it's creating a standardization layer specifically designed for AI agents. The Three Pillars of MCP MCP introduces three fundamental primitives that make AI integration more powerful: 1. Tools: These are discrete functions that agents can invoke dynamically. MCP tools differ from API endpoints because they provide self-describing functionality that agents can discover during runtime. 2. Resources: Read-only data sources that agents can query for context. Agents can access documentation, configuration files, and real-time data feeds through this resource. 3. Prompt Templates: Pre-defined templates that help how the AI model should interact with users to perform specific tasks. They offer pre-defined instructions to guide AI's behavior in different scenarios. Dynamic Discovery in Action Here's where MCP truly shines. When an AI agent starts up, it can query available MCP servers and discover their capabilities: JSON { "jsonrpc": "2.0", "method": "tools/list", "id": 1 } The response might reveal dozens of available tools: JSON { "jsonrpc": "2.0", "id": 1, "result": [ { "name": "createJiraTicket", "description": "Create a new JIRA issue with specified details", "input_schema": { "type": "object", "properties": { "title": {"type": "string"}, "description": {"type": "string"}, "priority": {"type": "string", "enum": ["low", "medium", "high"]} } } }, { "name": "analyzeCodeQuality", "description": "Run static analysis on a code repository" } ] } The agent can then invoke these tools through a standardized protocol without needing pre-configured integrations. Real-World Implementation: Building a DevOps Assistant Let me illustrate this with a practical example. Suppose you're building an AI assistant for DevOps teams that can: Monitor application healthCreate incident ticketsDeploy hot-fixesUpdate team communications The Traditional API Approach Using conventional APIs, you'd need to: Study documentation for Datadog, PagerDuty, GitHub, and Slack APIsImplement authentication for each serviceHandle different rate-limiting schemesWrite custom error handling for each integrationManually coordinate workflows between servicesUpdate code whenever APIs change This approach works, but it's brittle and requires constant maintenance. The MCP Approach With MCP, your DevOps assistant could: Discover available monitoring, ticketing, and deployment tools at startupDynamically adapt to new tools as they're added to the environmentUse a consistent protocol for all interactionsLeverage built-in error handling and retry logicAutomatically coordinate complex workflows The underlying services still use their native APIs (REST, GraphQL, etc.), but MCP servers act as intelligent translators that expose functionality through a unified interface. Technical Architecture MCP operates on a client-server model using JSON-RPC 2.0 over various transport layers (stdio, HTTP, WebSocket). This design choice provides several advantages: Language agnostic: Any language that can handle JSON-RPC can implement MCPTransport flexible: Works over multiple communication channelsBidirectional: Supports both request-response and streaming patternsExtensible: New capabilities can be added without breaking existing implementations When to Choose MCP vs Traditional APIs Understanding when to use each approach is crucial: Use Traditional APIs when: Building conventional web applicationsIntegrating a small number of well-known servicesYou need fine-grained control over every integration detail Use MCP when: Building AI-powered applicationsNeed dynamic service discoveryWant to minimize integration maintenance overheadPlanning for autonomous agent capabilitiesWorking with frequently changing service landscapes The Future of Intelligent Integration The integration landscape shows rapid development as we approach 2025 and future years. AI agents continue to advance in complexity so they can execute advanced operations autonomously. The changing environment requires organizations to develop fresh methods for system communication and collaboration. MCP functions as more than a new protocol because it represents a complete transformation of how intelligent systems should interact with the digital world. By providing dynamic discovery, standardized communication, and built-in adaptability, MCP enables AI agents to become truly autonomous problem-solvers. Getting Started with MCP If you're ready to explore MCP in your own projects, here are some practical next steps: Experiment with existing MCP servers: The official MCP repository includes servers for popular services like GitHub, Google Drive, and PostgreSQLBuild a simple MCP server: Start by wrapping one of your existing APIs in an MCP interfaceIntegrate MCP into your AI applications: Try using MCP-compatible tools in your current agent implementations Conclusion: Evolution, Not Revolution MCP is to AI agents what APIs were to web applications, a foundational enabler. But where APIs expose functionality statically, MCP brings discovery, abstraction, and adaptability to the table. MCP isn't here to destroy the API ecosystem that we've spent years building. Instead, it's the next evolutionary step to bridge the gap between the static, deterministic world of traditional APIs and the dynamic, intelligent future of AI-driven applications. As developers, our job is to recognize these shifts and adapt our architectures accordingly. The companies and teams that master this transition early will have a significant advantage as AI continues to evolve and reshape how software is built and deployed. The question isn't whether MCP will replace APIs but rather how quickly we can leverage both technologies to build the intelligent systems our users increasingly expect. The future of software integration is dynamic, discoverable, and AI-native. Are you ready to build it?

By Chetan Yeddula

Modernizing Apache Spark Applications With GenAI: Migrating From Java to Scala

If you're working on big data projects using Spark, you've likely come across discussions within your team about Java vs. Scala vs. Python, along with comparisons in terms of implementation, API support, and feasibility. These technologies are typically chosen on a case-by-case basis depending on the specific use case. For example, data engineering teams often prefer to use Scala over Java because of: Native language advantage (Spark itself is written in Scala)Better compatibility with Spark's core APIsEarly access to the latest Spark featuresMore idiomatic patternsFunctional programming featuresLess boilerplate code—typically 20–30% less compared to Java—which boosts productivity and speeds up development cyclesStronger type safety and compile-time checksPerformance benefits On the other hand, data science teams tend to lean toward Python because of its extensive support for machine learning libraries. However, PySpark (Python for Spark) comes with some translation overhead. That is, when you write Spark code in Scala or Java, it executes natively within the Spark engine. In contrast, PySpark runs Python code that must communicate with the JVM through a process called Py4J, introducing serialization and inter-process communication delays. This can raise performance concerns in PySpark. The goal of this post is to provide a well-rounded comparison between Java and Scala from a data engineering perspective, and to show how generative AI code assistants can help modernize Java codebases to Scala, without discounting the strengths of either language. In a Nutshell, What to Choose? Both Java and Scala will do the job for you. Java is object-oriented programming language, whereas Scala is a functional language with object-oriented concepts. With the new Generative AI services/tools such as Amazon Q Developer, ChatGPT, GitHub Copilot, and Google's Gemini code assist etc., developers/software engineers can save a significant amount of coding time (more than 50%) and boost productivity. These GenAI tools are integrated with popular IDEs (Integrated Development Environments) and will be handy to the developers with natural language capabilities. So, considering these GenAI tools makes the job easy. Keep an eye on API support in terms of understanding the limitations and seamless implementation. For instance, Enterprise applications were mainly developed on Java and have vast API availability, whereas Scala is often used for more distributed high-compute applications like Apache Spark. Migration from Java to Scala, or vice versa, is generally unnecessary unless faced with specific challenges such as a talent scarcity or corporate-wide technology alignment initiatives Microservice architecture, which has become a de facto standard nowadays, can be implemented in both Java and Scala. Also, other languages like GO etc. Perspective Decision Developer perspective The decision will be guided by programming expertise, comfort level, and years of experience. Project Management perspective: From the project management perspective, you don’t want to go with all the technical jargon. Instead, you want to quickly absorb the comprehensive comparison. below is a quick comparison in a nutshell. Learning curve: Learning Scala isn’t easy, especially for developers new to the language — but as the saying goes, "Once a programmer, always a programmer." There may be a steep learning curve, but it's definitely manageable with persistence.Project timelines: Java is more verbose in terms of lines of code, while Scala leverages type inference and functional constructs. As a result, code implementation may progress faster in Java, especially for teams already familiar with its syntax.Business Continuity Plan (BCP) and resource availability in market: Java’s been around since 1996, while Scala came along later in 2004. That means it’s usually easier to find experienced Java developers, especially when you need to plan for things like business continuity, than it is to find people with strong Scala skills. Development team: Traditionally, development teams would stick to a single programming language for a given project. But with modern development trends, it’s becoming more common for developers to be familiar with, and even use, multiple languages during implementation. The great thing is, Java and Scala can interoperate seamlessly, allowing teams to combine the strengths of both in a single project. Java and Scala Comparison Feature Java Scala Programming Primarily, object-oriented programming (OOPS) language. From Java 8 version, functional language features are supported Primarily, Functional language and object-oriented concepts are supported Lazy Evaluation (Key differentiator) Does not support lazy evaluation Scala's key feature is lazy evaluation, which allows differing time-consuming computation until absolutely needed by using the keyword “lazy”. Supports Lazy evaluation For example, in the following Scala code, loading images is a slow process; it shall be done only if needed to show images. This can be done using Lazy evaluation Scala lazy val images = getImages() // 'lazy' ensures images are loaded only when accessed. if (viewProfile) { showImages(images) } else if (editProfile) { showImages(images) showEditor() } else { // Do something without loading images } Implementation pace Code is more verbose. So, implementation pace can be high compared to Scala Less verbose thus reducing the no. of lines of code and improved code pace compared to Java Code Compilation ‘javac’ compiler which compiles the java code into byte code. ‘scalac’ compiler which compiles the scala code into byte code Compile Time Faster. Java also has Just-in-compiler which converts frequently executed code to machine native instruction to speed up the execution Slower due to type inference and functional features but use of SBT (Scala Build Tool) could fast up the compilation time. Runtime environment JVM (Java Virtual Machine) based. The byte code generated by javac compiler runs on java virtual machine (JVM) JVM (Java Virtual Machine) based. The byte code generated by the ‘scalac’ compiler runs on a Java virtual machine (JVM). Scala also takes advantage of ubiquity, administrative tools, profiling, garbage collection etc. REPL (Read-Eval-Print Loop) Support Supported through JShell which was introduced in Java 9 version Built-in and natively supported. Scala supports REPL, allowing developers to explore datasets and prototype applications easily without going through a full-blown development cycle. Succinct and Concise code Java is always on the firing line for being too verbose. Any code written in java in 5 to 6 lines can be written in Scala in 2 to 3 lines. e.g.: A Java Hello World program: Java public class HelloJava { public static void main(String[] args) { System.out.println(“Hello World !!!”) } } Java 8 introduced functional interfaces and streaming, which considerably reduces the number of lines of code in certain scenarios. Scala reduces the number of lines of code by clever use of type inference, treating everything as an object. Scala is designed to express common programming patterns in an elegant, concise, immutable and type safe way. Scala compiler avoids the developer to write those things explicitly that the compiler can infer. e.g.: A Scala Hello World program: Scala Object HelloScala { def main(args : Array[String]):Unit { println(“HelloWorld!!!”) } } OperatorOverloading Java does not support Operator overloading except of strings ‘+’ Scala supports Operator Overloading. We can overload any operator here and can create new operators of any type. E.g. Scala class Complex(val real: Int, val image: Int) { def +(that: Complex): Complex = new Complex(this.real + that.real, this.image + that.image) override def toString: String = s"$real + ${image}i" } val c1 = new Complex(2, 3) val c2 = new Complex(1, 4) println(c1 + c2) // Output: 3 + 7i Backward Compatibility (Key differentiator) Java provides backward compatibility that means ,later versions of Java can run code written in older versions and can execute it. Scala has all advantages of java except backward compatibility that is a key difference between java and Scala Concurrency Threads Actors (lightweight threads) Thread Safety Need to handle thread safety programmatically. So little extra effort compared to Scala Inherently immutable objects. Learning Curve Steeper learning curve due to functional programming concepts and advanced type system Gentler learning curve IDE ( Integrated Development Environment) support Good IDE support (IntelliJ IDEA, Eclipse), build tools (sbt, Maven, Gradle) Excellent IDE support (IntelliJ IDEA, Eclipse, NetBeans), mature build tools (Maven, Gradle) How GenAI Code Assistants Help Modernize Spark Application From Java to Scala Generative AI services/tools helps to boost productivity: Adopting and using new GenAI tools such as Amazon Q Developer, ChatGPT, GitHub Copilot, and Google's Gemini code assist, etc. Use Natural Language (aka NLP features) Learning curve or transition phase can be minimized and improve the coding standards.These tools also help to do the coding documentation, code reviews and unit test cases. Saving coding time and boost productivityMulti language support. like Java, Scala, SQL etc. More information can be found here. Modernizing Spark and Java Applications In this section, we'll explore how Amazon Q (Generative AI Code Assistant) can support the modernization of Java to Scala, as well as the upgrade of Spark versions. 1. Install Amazon Q in your IDE. Please refer these installation instructions. The following shows the Amazon Q plugin enabled Visual Studio IDE Visual Studio Code IDE with Amazon Q Plugin 2. Code Generation: In the following screenshot, i am showing that a sample Java Apache Spark code is generated using a prompt, "show apache spark code to read a dataset from s3 file names sales_dataset.csv and marketing_compaign_dataset.csv and perform join operation in java" you can create file in your repo instead of showing or pick your own spark code. Spark Code conversion from Java to Scala with a prompt Prompt: "Convert this java code to Scala" Code Conversion from Java to Scala 3. Now that we've seen the high-level code conversion, let's take a closer look at the file level. For this example, I'll be using a Spark Example repo featuring the classic WordCount program written in Java. Spark Java Example 4. Let’s convert the Java code to Scala. In the example below, the red boxes highlight the prompt I used: “Convert JavaWordCount.java program to Scala”, along with Amazon Q’s response. Amazon Q not only converted the Java code to Scala but also created a new Scala file named WordCount.scala in the same repository directory. Amazon Q - Code Conversion from Java to Scala 5. Next, let’s click on the WordCount.scala file to view the code generated by Amazon Q. As shown in the image below (highlighted in green), a new window opens displaying the WordCount.scala file, along with a tag indicating it was “Generated by Amazon Q.” Amazon Q - Converted/Generated Scala Code File When upgrading from an older version of Spark to a newer one, it’s important to be aware of potential breaking changes that could affect your existing code. For example, in Spark 2.4, the DATE_ADD(a, b) function allowed the second argument b to be a decimal. But starting with Spark 3.5, this argument must be an integer — decimal values are no longer supported. In the next section, we’ll walk through how to migrate a Spark 2.4 project to Spark 3.5. Prompt: "Create a spark 2.4 version code with DATE_ADD(a,b) function previously allowed b to be decimal" Amazon Q - Spark 2.4 Code Generation Prompt: "now modernize this code to spark 3.4" Amazon Q - Spark 3.5 Code Generation Note: Although edge cases will invariably require manual attention, a GenAI assistant offers a powerful advantage by tackling the bulk of the Spark code conversion, potentially transforming a traditionally challenging migration into a far more efficient undertaking. Conclusion Using a generative AI assistant like Amazon Q can make code modernization tasks faster and more manageable. It helps not just with converting code, but also: Upgrading to newer library or framework versionsGenerating code based on simple promptsReviewing and debugging existing codeWriting basic unit testsProducing lightweight documentation by analyzing the code structure It’s especially useful when dealing with large legacy projects or unfamiliar codebases. Disclaimer The views and opinions expressed here are strictly personal and do not constitute an official statement from our employer.

By Srikanth Daggumalli

One Checkbox to Cloud: Migrating from Tosca DEX Agents to E2G

If you read my recent article on the Elastic Execution Grid (E2G), you’ll know I’ve been exploring some of the newer additions to the Tosca ecosystem. It’s been an interesting learning curve and raised a few thoughts about how we approach execution infrastructure. That said, I realize many teams are still working smoothly with their existing DEX testing setups, and for good reason. If your workflows are stable and reliable, it can be hard to justify changing what already works. The effort to switch can feel like more hassle than it’s worth. Still, I’ve found that transitioning to E2G is surprisingly straightforward. And depending on your setup, the potential benefits, like improved scalability and simpler maintenance, might make it a worthwhile shift to consider. In this article, I’ll revisit Elastic Execution Grid, this time focusing on what the migration from DEX to E2G actually looks like in practice, and some of the reasons teams are choosing to make the move. Should I Switch to E2G? One of the main reasons I explored the switch to E2G was flexibility. Managing your own testing infrastructure, whether it’s a local setup or cloud VMs, can be time-consuming and rigid. E2G introduces more options when it comes to how and where your tests run. It supports three agent types: Personal Agents: Local agents ideal for quick, ad hoc runs.Team Agents: Self-managed VMs, either on-prem or in the cloud.Cloud Agents: Fully managed, ephemeral instances with no long-term footprint. You can choose the most appropriate agent for each test run, which offers a level of adaptability not always possible with DEX. Another factor is simplicity. In many workflows, E2G removes the need for scripting, custom XML, or manual network configurations. You just select the agent type, configure parallel or sequential execution, and add test characteristics. And for use cases that still require specific hardware or middleware, the option to use team agents remains. Cost efficiency is also worth noting. If you shift to cloud-based agents, there’s potential to cut down on infrastructure overhead, retiring underutilized machines, scaling back reserved VMs, or minimizing the maintenance burden of test-dedicated hardware. Scalability rounds out the list. With cloud agents, E2G handles auto-scaling on demand, adding capacity as needed and tearing it down when idle. When Staying on DEX Might Make Sense Now let’s look at the other side. Here are some reasons you may not want to switch. You have strict requirements for on-prem or air-gapped environments. You can’t run on the cloud if you can’t get to the internet!You have highly predictable, always-on workloads. In some of these cases, a dedicated DEX VM might be more cost-effective and convenient. It’s worth evaluating to see.As I’ll mention later, there is a cold-start latency with the first run on E2G. If you have ultra-low-latency needs, you may not be able to handle the start time (~60s or less). If every second truly counts and there’s no workaround, a DEX solution is probably better. How Can I Move from DEX to E2G? Now that you know why (or why not) you should make the move, let’s get into how to move from DEX to E2G. First, we all know that infrastructure changes can present risks. It takes many hours—and headaches—to make major changes. But in most cases, it actually takes minimal effort to change from DEX to E2G. Your core tests don’t need to change. While there will be some effort configuring agents (especially if you have a large number), the actual switching is easy. Team Agents Your first option is to start with E2G Team Agents. Maybe your organization (or you) just isn’t comfortable with cloud yet. Maybe you have lingering requirements to continue using your boxes. With Team Agents, you still manage your own infrastructure, but E2G manages the Team Agents. So you can retire your old distribution server, but still keep the infrastructure. It’s a baby step to Cloud Agents. This move is straightforward. 1. Spin down the DEX server. It’s probably safest to keep the machine provisioned, though, until you’re comfortable with the switch. 2. Create your E2G Team Agents. Download and install the Tosca Cloud launcher Follow the three-step wizard to name the agents, assign them to pool, and define their characteristics. 3. Execute your playlist! E2G will distribute the tests to available agents and report back with the results. Cloud Agents You can also jump straight into Cloud Agents and run your tests on the cloud. No more managing and configuring local hardware. It’s still simple to get started—basically the difference is just a checkbox and some options. 1. Open the Playlist Details, find the Agent Characteristics tab, and check the “Cloud-agent” box. 2. Choose your options for run order and recording. If your tests can run in parallel, you could see significant time savings by choosing that option. 3. That’s it! Now execute your tests. Regardless of whether you choose Cloud, Person, or Team Agents, the results and logs are shown in the E2G dashboard. Again, keep in mind that even if you’re using Team Agents, if you ever need specific hardware or configurations, you can always drop back to Team Agents. Edge Cases The above clear path is pretty easy. But let’s look at some potential problems I’ve run across that you should watch out for: Mismatched characteristics — Tag mismatches can cause problems. If you mistype or forget to update a tag, E2G won’t find a matching agent, and your runs might get stuck on “Pending.” Network/data access — Since Cloud Agents live on Tricentis-managed resources, if your app sits behind a VPN, you’ll need to configure appropriately for access.Cold starts — The first run of a fresh flow can take a bit of time (~60s or less) while the cloud VM spins up. Custom plugins — If you use custom plugins, you may need extra packaging or installation scripts. Once you’ve accounted for these edge cases, you should be good to go. Conclusion Overall, migrating to the Elastic Execution Grid is a relatively straightforward process. Compared to DEX Agents, E2G offers a simpler and more flexible approach to managing test execution. For teams looking to reduce overhead and increase scalability, it’s a model worth considering. With E2G, much of the manual infrastructure setup is abstracted away, often, running a test is as simple as selecting a checkbox. For more info, check out this detailed getting started guide. Have a really great day!

By John Vester

CORE

How to Troubleshoot Common Linux VPS Issues: CPU, Memory, Disk Usage

Linux, for its reputation of stability, security, and efficiency, several of the internet is hosted on Linux-based cloud servers, web hosts, and enterprise applications. This reliability positions it ideal for Virtual Private Servers (VPS), where even during high-demand workloads, it remains operational. Linux has native tools that are very powerful for diagnosing and solving your issues in no time. The commands such as top, htop, vmstat, and sar are used to monitor the system resources in real-time so that the performance bottleneck can be identified and corrective action can be taken before your VPS starts to freeze. Read below to understand the most common Linux VPS performance problems to troubleshoot and show how to keep your server running at full throttle. Basic Commands To Troubleshoot Common Linux Issues Before we get into the deep of the “Big 3”, let’s highlight a few basic Linux commands to check the performance issues: top – Shows current statistics on your CPU and memory and the processes utilizing themfree -m –Displays memory allocated and consumed in MBdf -h –Reports disk space usage in human-readable formatdu -sh /path/to/directory –Provides a relative path to disk use for a given directorysar – Gathering and reporting activity within the system to give historical performance. Familiarity with these commands will spare you hours of fruitless effort. Now here are the three big performance killers and ways to troubleshoot them. The "Big 3" (CPU, RAM, and Disk I/O) Three factors affect your VPS performance. CPU usage – Shows availability of processing powerMemory (RAM) usage - The more RAM your VPS utilizes, the fewer processes it can cope with.Disk I/O (Input/Output) - Affects the reading / writing speed. All of these lead to performance degradation when not monitored and tuned well, you can use monitoring tools to optimize your performance. Let’s analyze each in detail. Checking CPU Usage With Top The number of processes that can run simultaneously on your VPS is determined by the number of CPU (Central Processing Unit). Your server works extra hard when there is a high CPU load, which results in longer response times and may even cause your applications to stop responding. Indicators of High CPU Usage Pages load slow or (often) timeout.SSH connections are slow after a certain amount of time or don’t respond at all.Processes get queued, and it leads to some delays in executionEven for basic commands, the system feels terribly slow. How to Check CPU Usage? You can see live CPU usage with the top command. Here’s what to focus on: CPU: CPU Percentage utilized by each processLoad Average: The three numbers on the upper right corner displays the system load average for the past 1, 5 and 15 minutes. This generally indicates a load average higher than the CPU, i.e., the system has a heavier load than is placed on the system. Identifying Problematic Processes You will find out if one process is hogging the CPU in the %CPU column. To find out more details: ps -eo pid,ppid,cmd,%cpu --sort=-%cpu | head How to Fix High CPU Usage? a.) Identify and Kill Problematic Processes Stop a process that's overusing CPU resources: kill -9 <PID> Or restart the service: systemctl restart <service> b.) Limit CPU Usage for Processes For processes that you know will use a lot of CPU (like MySQL, or Apache), try limiting how much of your resources they burn with: cpulimit -P /usr/bin/apache2 -l 50 c.) Optimize Your Applications Caching: Helps here to avoid unnecessary processing (such as Redis to cache database queries)Change scripts to be less CPU intensive.Limit the background processes that use CPU unnecessarily. d.) Upgrade CPU Resources In this case, opt for more CPU cores if your VPS constantly struggles with CPU-heavy workloads. RAM Usage: Your Server’s Short-Term Memory The RAM (random access memory) is what enables your VPS to run several processes at the same time. Your system begins to use swap space, which is considerably slower than RAM, when you run out of RAM. Indicators of High RAM Usage High swap usage (free -m shows little or no available RAM).Out of memory (OOM) errors crash processes.Apps needing more data, like MySQL or those using PHP, become pretty slow. More disk I/O because of too much swapping How to Check Memory Usage? Use the free command to view the memory status: free -m Example output: total used free shared buff/cache available Mem: 4096 3800 296 100 512 500 Swap: 2048 1980 68 If this says that your "available" memory is too small (<500MB), your VPS is running out of RAM.If you are getting a lot of use out of swap, your system is using slow disk-based memory. For a real-time view, use: top or htop The processes using the most memory are listed at the top of the list. How to Fix High RAM Usage? a.) Find and Kill RAM-Hogging Processes Identify Processes That Are Overusing Memory: ps aux --sort=-%mem | head -10 Kill unnecessary ones: kill -9 <PID> b.) Clear Cached Memory Clears cache memory safely (without affecting any running application). sync; echo 3 > /proc/sys/vm/drop_caches c.) Increase Swap Space Extend swap if your server exchanges memory a bit often. dd if=/dev/zero of=/swapfile bs=1M count=2048 mkswap /swapfile swapon /swapfile d.) Optimize Applications Combine PHP and MySQL memory usage (my.cnf) SettingsRegenerate periodically to fix memory leaks systemctl restart apache2 e.) Upgrade RAM If you spend your day constantly over the available RAM, upgrade your VPS to a higher memory plan. 3. Disk Space Problems The Disk I/O (Input/Output) determines the speed of reading and writing data to storage on your VPS. Slow databases, file transfers, and how quickly an application loads usually come down to poor disk performance. Symptoms of High Disk I/O Usage File read/write operation becomes too slow.Database request response times incrases than normal.In top or vmstat, high wa (I/O wait time) can be noticed.Often "disk full" errors appear. How to Check Disk I/O Usage? a.) Monitor Disk Usage df -h If usage is more than 90%, release space.Identify which files or directories are using the most disk space with this command: du -sh /* b.) Check Disk I/O Performance To monitor disk I/O performance, use the following command: iostat -x 5 10 Have a look at the await and %util columns. If the %util is above 80%, the disk is likely struggling to handle the workload. How to Fix High Disk Usage? 1. Delete Unnecessary Files Find and remove large files: find / -type f -size +500M 2. Clear log files rm -rf /var/log/* 3. Optimize Disk I/O Usage Reduce the read/write operations by enabling MySQL query cache.Temporary Files → use tmpfs to lessen the disk writesServe static files through a Content Delivery Network (CDN) to minimize disk reads. 4. Upgrade to SSD Storage Switching from HDD to SSD can drastically make a difference to your VPS speed if your VPS is using traditional HDD storage. Step-by-step Troubleshooting Guide You should troubleshoot your Linux VPS when it displays errors. A proper troubleshooting process will help you determine the cause of the issue so you can give the right fix instead of simply rebooting your server or upgrading your resources. Here’s a step-by-step guide to troubleshoot problems commonly seen with VPSs. Step 1: Verifying Resources Checking the usage of system resources is the first step you should take if you are facing performance issues. Most of the time, server slowdown happens because the overloaded CPU, memory gets exhausted, or the disk I/O turns high. Check these metrics regularly and know what is exactly causing the server to slow down. How to Check Resource Usage? Connect to your VPS via SSH ssh user@your-server-ip Run Top to See How Much Memory and CPU Are Being Consumed Focus on the two columns %CPU and %MEM which represent processes with the highest resource usage.Restart or optimize a process if it is using too much CPU or RAM Use vmstat For An Overview of theWhole System It shows CPU, memory, and disk I/O usage every 5 seconds on 10 iterations.If you notice a higher wa (I/O wait time), it means you are going to have disk bottlenecks. Scan For Large Files Taking Up Disk Space du -sh /* If your disk is almost full, delete old logs and remove any files that you no longer need. Think For Resource Optimization or an Upgrade If your VPS regularly pushes the limits of CPU, RAM, or disk space, tweak applications to consume fewer resources.Upgrading to a higher tier VPS plan with increased resources is another option if optimizations have failed to alleviate the issue. Step 2: Fixing Network Problems If your VPS is unreachable, then there may be an issue with network configurations or firewall rules. Downtime, slow responses, or failed connections to external services result from network issues. How To Troubleshoot Network Problems? Verify Network Interface Configurations ip addr show Ensure your network adapter is active and has the correct IP address assigned. Check the firewall and port configurationCheck active firewall rules sudo ufw status If you are blocking any real service, then you can allow it by using: sudo ufw allow <port_number> For deeper technical investigation, you can use: sudo iptables -L -n -v Perform a Ping Test for Connectivity ping -c 5 google.com Your server might have connectivity or DNS related issues if you lose packets.Restart the network service: sudo systemctl restart networking Verify Port Accessibility with nmap nmap -p <port_number> your-server-ip If the port needed is the other way around, make sure the service is run ( Apache, MySQL… ) sudo systemctl status apache2 Most connectivity issues can be fixed on your Linux VPS by systematically going through network settings and firewall rules and checking if the port is bound by xprocess. Step 3: Secure Your VPS To Ensure Stability For The Long Term Security is an essential aspect of managing a VPS. Compromised / Misconfigured Server may run out of speed and stability, or it may be hacked/penetrated. By taking steps to secure your server, you are ensuring that it will not only remain secure, but perform well. How to Secure Your Linux VPS? System and Software Update Buggy, old software can be a security risk through exploits, and slowdownsRegularly update your packages sudo apt update && sudo apt upgrade -y Authentication Based On SSH Key Instead Of Password Brute-force attacks can easily crack password-based authenticationUse key authentication to secure your SSH access ssh-keygen -t rsa Copy the key to your VPS ssh-copy-id user@your-server-ip Configure a firewall to disallow external attempts to access it Configure UFW (Uncomplicated Firewall) to limit any unnecessary incoming connections sudo ufw allow ssh sudo ufw allow http sudo ufw enable Monitor and Disable Bad Login Attempts Fail2Ban, an intruder defense system that short-circuits invadersby blocking repeated failed logins. sudo apt install fail2ban -y Enable protection for SSH sudo systemctl start fail2ban Make A Habit Of Backing Up Your VPS Data At any point, if you mess up (your server crashes, gets a malware, or is deleted by accident), your backups bring things back to normal.Copy data over rsync, create a backup to the other server rsync -avz /your/data/path user@backup-server:/backup/location Implementing these security best practices can help to mitigate the potential for cyber threats while promoting seamless operation of your VPS, free from unforeseen interruptions. How Can Troubleshooting Techniques Solve the Above Problems? By following these steps, you can significantly enhance the performance of your VPS. Here's how those troubleshooting techniques help you: Reduced CPU usage protects you from slow response times.By freeing up the RAM, the applications can run smoothly.Disk management is essential for maintaining stability in the system.In-depth monitoring enables you to detect problems before they become an issue. Thus, regular maintenance and troubleshooting are the key elements to keep your Linux VPS running smartly. Conclusion Since nothing is perfect, you will face problems with your VPS, which is part of server management. However, you can solve many issues quickly and efficiently if you know what to do. But when you follow the troubleshooting steps in this guide, you will be prepared to troubleshoot CPU overload, memory exhaustion, disk space problems, and network connectivity problems to make your VPS stable and responsive.

By Ankit Mathur

Designing Microservices Architecture With a Custom Spring Boot Starter and Auto-Configuration Framework

Spring Boot has Java development with its embedded servers, auto-configuration, and convention-over-configuration philosophy. Among its many features, one of the most powerful — but often underused — is the ability to create custom Spring Boot starters. These components enable development teams to package and reuse common configuration and boilerplate logic, making microservices more modular, maintainable, and consistent across a large-scale enterprise platform. This article explores how to build and use custom Spring Boot starters with auto-configuration to centralize concerns such as database access, authentication, and WebSocket communication, especially valuable in environments like loan servicing and trading platforms that operate with numerous microservices. Why Use a Custom Starter? In any microservices-based system, many functional concerns repeat across services: Database connectivitySecurity configurations (e.g., JWT, OAuth2)Exception handlingWebSocket communicationHealth checks and monitoring Traditionally, developers either duplicate configuration files or share utility libraries to handle these recurring needs. However, this approach leads to fragmented configurations and tightly coupled services. Custom Spring Boot starters allow you to extract and modularize this functionality. Instead of duplicating setup logic, you can include a starter dependency and configure only what’s unique to the microservice. The benefits include: Cleaner codebase: Each microservice focuses purely on business logic.Faster onboarding: New services go live with minimal setup.Consistency: Uniform application of security, logging, and monitoring policies.Centralized maintenance: Updates to shared logic are propagated via version bumps. Project Structure To illustrate, let’s assume you’re designing a loan servicing and trading platform. Here's how you might structure your Spring Boot-based framework: Java loans-framework/ │ ├── loans-starter-db/ # Custom DB configuration starter ├── loans-starter-security/ # JWT and OAuth2 setup ├── loans-starter-websocket/ # WebSocket endpoints and config ├── loans-core-service/ # Sample microservice using above starters Each module serves a clear purpose: loans-starter-db handles JPA configuration, datasource bean creation, and repository setup.loans-starter-security provides authentication filters, JWT decoding logic, and security context management.loans-starter-websocket manages message brokers, STOMP endpoints, and topic subscriptions.loans-core-service is a business-specific microservice that leverages the above starters for its infrastructure. This separation enforces modular design and supports easy scaling as new services are added. Creating a Custom Starter Let’s walk through building loans-starter-db, a custom Spring Boot starter for JPA database access. Step 1: Create the Starter Module Define the Maven artifact: XML <artifactId>loans-starter-db</artifactId> <packaging>jar</packaging> Include relevant Spring dependencies: XML <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-data-jpa</artifactId> </dependency> Do not hardcode versions — inherit from a parent POM to maintain alignment. Step 2: Add Auto-Configuration Create an auto-configuration class using Spring annotations: Java @Configuration @ConditionalOnClass(DataSource.class) @EnableJpaRepositories(basePackages = "com.loans.common.repository") public class DatabaseAutoConfiguration { @Bean @ConditionalOnMissingBean public DataSource dataSource(DataSourceProperties properties) { return DataSourceBuilder.create() .url(properties.getUrl()) .username(properties.getUsername()) .password(properties.getPassword()) .build(); } } @ConditionalOnClass ensures the configuration is only applied if DataSource is available.@ConditionalOnMissingBean allows services to override this bean if needed.@EnableJpaRepositories automatically scans for JPA repositories in the specified package. Step 3: Register the Configuration In src/main/resources/META-INF/spring.factories, declare your config: Java org.springframework.boot.autoconfigure.EnableAutoConfiguration=\ com.loans.dbstarter.DatabaseAutoConfiguration This file tells Spring Boot to pick up your auto-configuration during the application startup phase. Using the Starter in a Microservice In loans-core-service, include the dependency: XML <dependency> <groupId>com.loans</groupId> <artifactId>loans-starter-db</artifactId> </dependency> Then, configure only the database credentials in application.yml: YAML spring: datasource: url: jdbc:postgresql://localhost:5432/loans username: user password: secret You no longer need to configure JPA manually — the starter handles everything. Extending to Other Concerns Following the same approach, you can build additional starters: Security Starter (loans-starter-security) Configures a JWT filter chain.Loads public key for token validation.Provides global exception handling for security failures. WebSocket Starter (loans-starter-websocket) Defines STOMP endpoints.Configures message brokers (e.g., RabbitMQ).Sets up channel interceptors and listeners. These components keep your services clean and focused on business capabilities while offloading platform concerns to reusable, tested modules. Platform-Wide Benefits Feature Impact Decoupled config Services remain lean and business-focused Standardization Consistent security, DB access, and communication layers Faster dev cycles Starters eliminate boilerplate and promote reuse Easier maintenance Version-controlled updates to shared logic Best Practices One responsibility per starter: Don’t combine DB, security, and WebSocket logic into one.Use a parent POM: Align versions across all modules to avoid conflicts.Publish to a private repository: GitHub Packages or Nexus works well.Add logging in auto-config classes: This aids debugging when beans aren’t loading as expected.Document everything: Provide sample usage, config options, and default behaviors. Testing Before Production Before releasing a starter, create integration test services that: Verify that all beans load correctly.Confirm that service-level overrides still work.Ensure that properties are bindable and follow expected naming conventions. Include documentation or onboarding guides so that internal teams can adopt starters with minimal friction. Conclusion Custom Spring Boot starters are essential for teams managing distributed microservices at scale. They encapsulate shared logic, enforce consistent practices, and enable rapid, reliable service creation. By investing in a modular, auto-configurable architecture, engineering teams can unlock both speed and quality in their software delivery process. GitHub example: https://github.com/ggajwani9/loans-framework.

By Girish Gajwani