Mohan Reddy Atalu

In the world of AI-driven automation, LangChain is redefining how we build intelligent applications. Whether you're working on cloud infra, DevOps, or data engineering, understanding LangChain's core components can give you a serious edge. 🔧 Functions Reusable logic blocks that allow LLMs to interact with external systems. Think of them as smart APIs that can fetch data, trigger workflows, or perform calculations — all orchestrated by language models. 🛠️ Tools Encapsulated capabilities like web search, code execution, or database queries. Tools extend the LLM’s reach beyond text generation, enabling real-world actions and integrations. 🤖 Agents The brain behind LangChain! Agents decide which tools to use and when — based on user intent. They enable dynamic decision-making, chaining multiple steps to solve complex tasks. 💡 Use Case Example: Imagine an agent that reads JIRA tickets, analyzes sprint velocity, and generates a Confluence report — all triggered by a simple prompt. That’s LangChain in action! 🔍 Whether you're building automation scripts, intelligent dashboards, or AI copilots — LangChain’s modular architecture makes it scalable, flexible, and incredibly powerful. Let’s connect if you're exploring LangChain for enterprise automation, cloud workflows, or AI integrations. Happy to share insights and collaborate! #LangChain #AI #Automation #CloudEngineering #InfraManagement #Python #LLM #DevOps #JIRA #Confluence #Tempo #EazyBI #GenerativeAI #LinkedInTech

2

AWS Hadoop Data Engineer (HDFS to AWS Migration) – Hybrid, New Jersey Lead migration of on‑prem HDFS/Hadoop workloads to AWS cloud. Build and optimize ETL/ELT pipelines using Glue, EMR, Lambda, and S3. Convert legacy Spark/Hive jobs into AWS‑native PySpark workflows. Develop scalable data processing solutions using Python, PySpark, and Spark SQL. Implement data quality, validation, and governance best practices. Work with structured and unstructured data across hybrid environments. Troubleshoot issues across Hadoop clusters, AWS services, and ETL pipelines. Collaborate with architects and cross‑functional teams during cloud modernization.

13

14 Comments

𝗔𝘂𝘁𝗼𝗺𝗮𝘁𝗶𝗼𝗻 𝗶𝘀 𝗱𝗼𝗶𝗻𝗴 𝘁𝗵𝗶𝗻𝗴𝘀 𝗿𝗶𝗴𝗵𝘁. 𝗢𝗿𝗰𝗵𝗲𝘀𝘁𝗿𝗮𝘁𝗶𝗼𝗻 𝗶𝘀 𝗱𝗼𝗶𝗻𝗴 𝘁𝗵𝗲 𝗿𝗶𝗴𝗵𝘁 𝘁𝗵𝗶𝗻𝗴𝘀.  One of the major bottlenecks in scaling a true 𝗔𝗜 𝗔𝘂𝗴𝗺𝗲𝗻𝘁𝗲𝗱 𝗦𝗗𝗟𝗖 isn't model capability; it is the friction of context switching. Visual Studio Code 1.107 released on Dec 10 shifts the paradigm from 𝗮𝘂𝘁𝗼𝗺𝗮𝘁𝗶𝗼𝗻 𝘁𝗼 𝗠𝘂𝗹𝘁𝗶-𝗔𝗴𝗲𝗻𝘁 𝗢𝗿𝗰𝗵𝗲𝘀𝘁𝗿𝗮𝘁𝗶𝗼𝗻.  With the new 𝗔𝗴𝗲𝗻𝘁 𝗛𝗤, we can move from "Pair Programming" to "Fleet Management," delegating work across a proper architectural hierarchy. 🤖 𝗧𝗵𝗲 𝗠𝗮𝗻𝗮𝗴𝗲𝗿 (𝗟𝗼𝗰𝗮𝗹 𝗔𝗴𝗲𝗻𝘁): Your standard Copilot Chat. You use this for strategy, clarification, and quick answers. 🛠️ 𝗧𝗵𝗲 𝗪𝗼𝗿𝗸𝗲𝗿 (𝗟𝗼𝗰𝗮𝗹 𝗕𝗮𝗰𝗸𝗴𝗿𝗼𝘂𝗻𝗱 𝗔𝗴𝗲𝗻𝘁): Deep work tasks delegated to run locally in isolated Git worktrees. They fix bugs and write tests in the background without blocking your editor or corrupting your current state.  ☁️ 𝗧𝗵𝗲 𝗦𝗰𝗮𝗹𝗲𝗿 (𝗖𝗹𝗼𝘂𝗱 𝗔𝗴𝗲𝗻𝘁): Heavy lifting (like documentation generation or security scanning) offloaded entirely to GitHub’s servers. This is grounded by the 𝗚𝗶𝘁𝗛𝘂𝗯 𝗠𝗖𝗣 𝗦𝗲𝗿𝘃𝗲𝗿, ensuring these agents share a unified context without hallucinating your project structure. For leaders, the value is clear: 𝗔𝘀𝘆𝗻𝗰𝗵𝗿𝗼𝗻𝗼𝘂𝘀 𝗘𝘅𝗲𝗰𝘂𝘁𝗶𝗼𝗻. We are no longer limited by the speed of a single chat interaction. This framework is extensible: you can engineer custom agents to handle your unique tech stack or deploy organization-wide agents to enforce architectural standards at scale. 𝗪𝗲 𝗮𝗿𝗲 𝗮𝗿𝗰𝗵𝗶𝘁𝗲𝗰𝘁𝗶𝗻𝗴 𝗼𝘂𝘁𝗰𝗼𝗺𝗲𝘀, 𝗻𝗼𝘁 𝗷𝘂𝘀𝘁 𝘄𝗿𝗶𝘁𝗶𝗻𝗴 𝗰𝗼𝗱𝗲.   🚀 𝘚𝘵𝘰𝘱 𝘸𝘢𝘪𝘵𝘪𝘯𝘨. 𝘚𝘵𝘢𝘳𝘵 𝘥𝘦𝘭𝘦𝘨𝘢𝘵𝘪𝘯𝘨.  🏗️ 𝘉𝘶𝘪𝘭𝘥 𝘵𝘩𝘦 𝘧𝘢𝘤𝘵𝘰𝘳𝘺, 𝘯𝘰𝘵 𝘫𝘶𝘴𝘵 𝘵𝘩𝘦 𝘸𝘪𝘥𝘨𝘦𝘵.  ⚙️ 𝘐𝘯𝘯𝘰𝘷𝘢𝘵𝘪𝘰𝘯 𝘪𝘴 𝘢𝘯 𝘦𝘹𝘦𝘤𝘶𝘵𝘪𝘰𝘯 𝘱𝘳𝘰𝘣𝘭𝘦𝘮. 𝘛𝘩𝘪𝘴 𝘵𝘰𝘰𝘭𝘴𝘦𝘵 𝘨𝘪𝘷𝘦𝘴 𝘶𝘴 𝘵𝘩𝘦 𝘥𝘪𝘴𝘤𝘪𝘱𝘭𝘪𝘯𝘦 𝘵𝘰 𝘦𝘹𝘦𝘤𝘶𝘵𝘦 𝘪𝘯 𝘱𝘢𝘳𝘢𝘭𝘭𝘦𝘭. https://lnkd.in/gGYcRjD4

28

1 Comment

🌿 When Spring Blossomed Again: My Journey of 33 components migration to Spring Boot 3 and Java 17 “Upgrading code is easy. Upgrading mindset is the real migration.” Here’s a story from our team’s recent migration to Spring Boot 3 and Java 17 — a journey that began with optimism, hit turbulence with Jakarta EE, and eventually taught us more about architecture and patience than any documentation could. --- 🌪️ The Calm Before the Jakarta Storm Our system isn’t a monolith. It’s a distributed mesh of microservices, each communicating through RPC and REST APIs. They’d been quietly running on Spring Boot 2.7 and Java 11, reliable as ever. Then came Spring Boot 3 — with a seemingly harmless change: javax.* → jakarta.* It sounded trivial. In reality, it was like changing the alphabet halfway through a novel. --- 🔍 The First Sign of Trouble Our first migrated service deployed smoothly. Unit tests passed. Logs looked good. Until RPC calls started failing. “Cannot deserialize ConstraintViolationException.” After hours of debugging, we discovered the issue: One service was using jakarta.validation.ConstraintViolationException, while its peer — still on Spring Boot 2 — expected javax.validation.ConstraintViolationException. Two identical words. Two worlds apart. Both correct, yet unable to talk. --- ⚔️ The Battle of Two Worlds For weeks, our services lived in two realities. Jakarta-based services were incompatible with javax-based ones. RPC payloads broke silently. Validation failed across network calls. We tried patching. Each fix solved one issue, created another. And that’s when the truth hit us: Migration isn’t just technical — it’s architectural empathy. --- 🧭 Finding the Bridge The breakthrough came when we built an adapter bridge: 1. Neutral Contract Layer: We extracted shared DTOs into a module without any javax/jakarta imports. Pure POJOs. 2. Jackson Mixins for Validation: Created mapping rules to ensure both worlds serialized exceptions in a compatible format. 3. Interceptors for RPC Calls: Added Feign/gRPC interceptors that caught old exception types and translated them to the new namespace --- 🌞 The Reward: Java 17’s Simplicity Beyond interoperability, Java 17 brought real joy: Records replaced verbose DTOs. Sealed classes made inheritance intent crystal clear. Memory usage dropped by ~12%. --- 🌱 What I Learned Backward compatibility is culture, not configuration. Jakarta’s shift was more philosophical than syntactical. Every migration teaches patience — in people, process, and design. Looking back, the migration wasn’t about frameworks. It was about trust — between components, teams, and the systems we build to last. ✨ Conclusion If your team is planning a Spring Boot 3 + Java 17 migration, embrace it as a learning journey, not a checklist. You’ll come out with cleaner code — and a wiser engineering culture. --- #SpringBoot3 #Java17 #JakartaEE #MigrationJourney #EngineeringLeadership #Microservices

8

Most skilling nonprofits, focusing on mainstream careers such as software engineering, digital marketing, finance, etc., haven't been able to crack this problem. They ask for preliminary data and take BPL/income certificates, etc., as evidence for underprivilege. Unfortunately, such evidence can be easily manipulated. On top of that, nonprofits don't get much funding or aren't even extensively audited for due diligence related to underprivilege verification. Hence, a lot of the funding for skilling for mainstream careers goes to beneficiaries who aren't necessarily underprivileged. This is why Xcelevate Skills Foundation decided to solve this problem even before starting the first cohort. There was no holistic underprivilege assessment framework that Xcelevate could adopt. No, underprivilege isn't just about economic factors. Holistic assessment needs to consider social, gender, health, and other factors as well. Thanks to Nivedha Ramadoss for researching extensively and innovating the framework from the ground up. Assessment by this framework is a critical part of the admission process, as Xcelevate is fully focused on skilling the underprivileged. Stay tuned for the next post in this series to know more about this innovative and holistic underprivilege assessment framework... Joy Doctor Talha Yunus Ritesh Mathur Milan Dang Vikram Singh Shweta Dhillon Dinesh Sundaravaradan Supreeya Swaroop Bhandari Kanwal Kaul - KK Vandana Chotrani Deepti Kalia Arti Gangaiya Krishnam Raju Akula Sameer D'MELLO Shyamanta (Sam) Baruah

22

4 Comments

What is common between Mahabharat, Microsoft Azure and Data? The launch of the 100-episode AI-powered series Mahabharat: Ek Dharmayudh (JioHotstar /Star Plus) is a monumental achievement, positioning it as India’s first AI-powered premium series. While the exact technical blueprint is not public, I am inferring this architecture based on partnership information available (JioStar, Collective Artists Network/Galleri5 AI, Microsoft Azure) and the current state of enterprise-grade Generative AI: 1. Platform: Microsoft Azure AI Foundry, providing scalable compute (likely NVIDIA H100/A100 GPUs) for high-volume video synthesis. 2. Visuals: Custom-finetuned Latent Diffusion Models (LDMs). Their key to success is using proprietary "mythology and culture-based AI datasets" to ensure cultural fidelity and character consistency. 3. Coherence: Specialized LLMs (for script consistency) and Neural TTS models (for multilingual localization in seven Indian languages) complete the sophisticated pipeline. First Impressions & Quality: Technologically, the series is impressive. Characters maintain remarkable visual likelihood between frames, and critical AI anomalies (like characters having extra fingers) appear to have been successfully filtered out, showcasing the robustness of their finetuning. My own cynical eye found the visual flow slightly surreal, perhaps perceiving it as connected video segments (my bias!). Yet, the true test was showing it to my in-laws—they were completely immersed and couldn't tell it was AI-generated. I applaud JioStar/CAN/Galleri5 (now, part of Collective Artists Network) AI for this pioneering effort. I strongly urge them to release a detailed technological case study. This blueprint for the world's first AI epic deserves to be shared! #AI #GenerativeAI #Mahabharat #JioStar #MicrosoftAzure #TechCaseStudy #IndianM&E #FutureOfFilmmaking CFBR: divya kodukula Ravi Ramchandran Abhishek Sagar Jitendra Agrawal Venu A.

35

12 Comments

The U.S. remains the largest source of contributions (~12.8M, 31.8%). India ranks second (~5M, 12.5%) and leads by distinct repositories (405k vs. 342k).

17

Thrilled to see the Build with AI – Pune | GenAI Workshop from GDG Cloud Pune come alive at Data Axle India Workshops like these, exploring ADK, MCP, multi-agent systems, and real-world GenAI, show the true power of community-driven learning. And this is only the beginning. At Data Axle, we aim to build a vibrant, open tech-learning ecosystem with monthly community meetups focused on Python / Django, React, MS .net, C++, Amazon Web Services (AWS), Google Cloud, Databricks, AI, and its use cases, as well as in-depth architecture discussions and hands-on engineering sessions. If you are excited about sharing knowledge, hosting a meetup, or collaborating on tech events, please don't hesitate to reach out to me. Let’s grow this community together, make Pune a hub of continuous learning and innovation, and build a movement where learning never stops and everyone grows together.

23

Argo CD + App of Apps = Apply Once. Manage Everything. I cleaned up my GitOps workflow by introducing a dedicated bootstrap repo for Argo CD. Instead of running multiple "kubectl apply -f root-app.yml" commands across repos, I now: Apply one root app once Let Argo CD sync all child apps automatically Keep everything fully GitOps-driven Architecture (App of Apps Pattern) Bootstrap Repo └── Root Application  ├── Child App → Web App Repo  ├── Child App → Payment App Repo  ├── Child App → Token App Repo  └── Child App → Monitoring Repo Each Application: Points to one repo + one path Is auto-synced by Argo CD Uses prune: true + selfHeal: true for full automation After the first apply, Argo CD takes over. No manual syncing. No repeated kubectl applies. Also learned: Avoid multiple apps managing the same resource (Ingress, ConfigMap, Secret) — or you’ll hit SharedResourceWarning. This setup made my multi-repo Kubernetes environment cleaner, scalable, and production-ready. Bootstrap repo - https://lnkd.in/eNxb83KF Child Apps 1 - https://lnkd.in/eJB6MXgw Child Apps 2 - https://lnkd.in/eBmufNmC #Kubernetes #GitOps #ArgoCD #DevOps #CloudNative

15

Real-Time Spark Streaming Issue – A Lesson in State Management & Scalability Recently, I have come across a critical challenge in a production grade Spark Structured Streaming pipeline that processes real-time events from Kafka on AWS EMR. Issue: During high throughput periods, the application began failing intermittently with GC Overhead Limit Exceeded errors, despite stable message volumes (~5K records/sec). The failures were impacting downstream SLAs and raised concerns around stability and scale. Root Cause Analysis: The job was using stateful operations (mapGroupsWithState) to maintain user-level session windows. However, no state timeout was configured, causing unbounded state growth in memory. Additionally, the checkpoint directory was shared across job retries, leading to inconsistent state recovery and increased memory pressure. Resolution Steps: Introduced a state timeout policy to efficiently manage and evict old session data. Isolated and versioned the checkpoint directory to ensure clean recovery on retries. Tuned executor memory (spark.executor.memory, spark.memory.fraction) based on observed GC metrics. Implemented structured logging and metrics publishing to monitor JVM memory trends proactively. Enabled dynamic scaling to adjust to burst loads. Impact: Post optimization, the pipeline became significantly more stable, and we improved throughput handling by ~30% while maintaining consistent latency and SLA adherence. Key Takeaway: Spark Structured Streaming is powerful, but improper state management can introduce subtle yet critical performance issues. Investing time in observability and resilience design pays off at scale. Would love to hear how others approach memory tuning and state management in real-time Spark environments. #DataEngineering #ApacheSpark #Kafka #StreamingAnalytics #AWS #EMR #BigData #RealTimeData #Scalability #Observability #StreamingAtScale

2

Talk is cheap. Show me the experiment. Here's Idea Factory running live -- two ways to get AI-generated equity insight: Scenario 1: Chat Ask the AI assistant anything about an NSE/BSE stock. "Summarize latest earnings for HDFCBANK" -- and you get Q3 FY2025 financials in seconds. No analyst call. No waiting. Scenario 2: AI Brief Open any stock. Hit the AI Brief tab. Four sections generate in parallel: Business Model, Moat Analysis, Key Metrics, Key Risks. Every response is logged with a full audit trail -- model version, timestamp, data sources. Two interfaces. One compliance guardrail. Zero budget approval forms. This is what a governed AI prototype looks like in practice. #Demo #Innovation #EnterpriseArchitecture #IndianEquities #IdeaFactory #DeveloperExperience #AIatScale #Blueprint #ContextEngineering #DotNetAspire #GitHubCopilotSDK #CTO

28

2 Comments

🚀 Excited to announce the launch of Utsav Synapse – now LIVE! 🚀 After long ideation, learning, and building, I’m proud to share that Utsav Synapse, an AI-powered SAP Intelligence Platform, is officially live 🎉 🔹 What is Utsav Synapse? Utsav Synapse is designed to simplify and accelerate SAP Security, Authorization, and SOD analysis by providing instant intelligence on SAP T-codes and Fiori applications. It empowers SAP Security Administrators, Consultants, and Auditors to make faster, better-informed decisions. 🔹 Key capabilities include: ✅ AI-powered instant analysis of SAP T-codes & Fiori Apps ✅ Comprehensive Segregation of Duties (SoD) risk identification ✅ Preventive & detective control insights ✅ Organization-level and non-organization-level field mapping ✅ Role recommendations aligned with SAP best practices ✅ Authorization Matrix analysis & conflict detection ✅ BPH & PDD document generation ✅ Export-ready outputs in PDF and Excel 🎯 Why this matters: SAP Security analysis is often time-consuming and complex. Utsav Synapse aims to reduce manual effort, improve accuracy, and bring clarity to authorization design and risk assessment—especially in S/4HANA environments. 🔗 Try it out here: 👉 https://lnkd.in/gceSBZan I’d love feedback from the SAP community—your insights will help shape the next phase of this platform. If you’re passionate about SAP Security, GRC, IAM, or S/4HANA, this one’s for you! #SAP #SAPS4HANA #SAPSecurity #GRC #SoD #Fiori #Authorization #AI #ProductLaunch #Innovation #UtsavSynapse

16

6 Comments