I had the chance to interview Cox Automotives’ Udaya Veeramreddygari . Udaya is an experienced software engineering leader with over two decades of proven expertise in architecting, developing, and managing enterprise-scale applications across automotive, retail, finance, and telecommunications domains. He pecializes in implementing scalable, cloud-native systems using modern frameworks and architectural patterns, AWS, and GenAI technologies, leading global cross-functional teams to deliver high-performance, secure, cloud-native solutions aligned with business strategy. In his current role as Lead Software Engineer at Cox Automotive, he drives legacy system modernization, ML/AI integration, and generative AI enablement—boosting productivity, fostering automation, and orchestrating agent-driven workflows across the SDLC. He is a certified professional in AWS, Anthropic, Scrum, ITIL, and architecture
Beyond engineering, Veeramreddygari is actively engaged with the technology community through global conference speaking, technical program committee memberships (ICoSEIT, BDAA), and peer reviews of conference papers, and serving as a judge for Globee Awards and Business Intelligence Group. An active Senior IEEE member, Fellow SCRS, Senior ISAC, SEFM, and Fellow IETE in producing research papers, he also contributes scholarly articles on Data, Microservices, Event Driven architecture, LLMs, GenAI, AI productivity, and sustainability across platforms like DZone, Dev.to, Medium, RTInsights, IoTEolutionWorld and Dataversity. Veeramreddygari brings a rare combination of deep technical expertise, leadership acumen, and thought leadership, enabling teams and organizations to navigate modern engineering challenges with clarity and innovation.
I asked him about AIoT and where it is impacting business overall and, more specifically, how it’s changing work for him. Below are his answers
Carl Ford: You have a history of software development, starting with Cobol. I have two questions for you on this front. The first is that Cobol is still essential in financial systems and other systems, yet, industry is all about coding in more modern languages. What do you foresee as the future of Cobol?
Udaya Veeramreddygari: Honestly, Cobol isn't going anywhere anytime soon. It's too deeply embedded in critical financial and government systems. However, I see the future being more about modernization through microservices and APIs that wrap around these legacy systems, rather than complete rewrites. We're moving toward a hybrid world where Cobol continues running core business logic, while modern interfaces and cloud-native services handle everything else. The real challenge is finding talent who understands both worlds.
CF: Will Cobol be coded by AI?
UV : AI will definitely play a role in maintaining and even generating Cobol code, especially for routine tasks and bug fixes. I've already seen generative AI tools help developers understand legacy Cobol logic and translate business rules into more modern languages. But, here's the thing – AI still needs human oversight, particularly for complex business logic that's been refined over decades. I think we'll see AI becoming more of a copilot for Cobol maintenance rather than completely replacing the need for human expertise.
CF: In your transition to AI, you are going into a blended world of AI writing code. How does that change your development style? To me, it feels like it’s like running a team of coders, making sure they understand the instructions, and then taking over when the skill set is beyond the coder’s ability. Am I close to what’s its like?
Udaya Veeramreddygari
UV: Your analogy about running a team of coders is spot on! Working with AI tools, like GitHub Copilot and Claude Code, has fundamentally changed how I approach development. I spend more time being an architect and reviewer, clearly articulating requirements, validating AI-generated code, and stepping in when the logic gets too complex or requires deep domain expertise. It's less about typing every line of code and more about orchestrating the development process, ensuring quality, and making strategic technical decisions that AI can't make on its own.
CF: You are an advocate of microservices. Are microservices the same as Functions-as-a-Service (FaaS) from the cloud? If yes, does this mean microservices will come from the cloud? Does the cloud offer any advantages?
UV: They're related, but not the same. Microservices are independently deployable services that own specific business capabilities, while FaaS, like AWS Lambda, are stateless, event-driven functions that execute specific tasks. At my workplace, we use both – microservices for complex business logic that needs state management and FaaS for event-driven workflows. The cloud definitely offers advantages, like automatic scaling, reduced operational overhead, and pay-per-use pricing. We've leveraged AWS extensively to deploy our microservices architecture, which gives us the flexibility to scale individual services based on demand.
CF: How do microservices help comply with privacy concerns? Are we talking about regulation, corporate policies, or both?
UV: Microservices align beautifully with both regulatory requirements, like GDPR, and corporate privacy policies. By decomposing applications into smaller services, we can isolate sensitive data and apply specific security controls to just those services that handle personal information. For example, in our document management system application, we created separate microservices for document storage and metadata handling, which allowed us to implement encryption, access controls, and audit logging precisely where needed. This granular approach makes compliance easier to prove and maintain compared to monolithic architectures.
CF: You’ve mentioned scalability in the past. Can you explain the advantages of microservices in terms of scalability?
UV: The biggest advantage is independent scaling; you can scale just the services that need it, rather than the entire application. In one of our applications, we handle millions of records monthly, and microservices let us scale our processing services during peak auction times without over-provisioning everything else. We also get faster deployment cycles, since teams can update individual services without coordinating massive releases. Plus, if one service fails, it doesn't bring down the whole system, which is crucial for maintaining uptime in mission-critical environments.
CF: As the modules in IoT solutions become capable of AI at the device, does that imply that microservices themselves will become embedded in device solutions? Or will they always be at some aggregation point, like the edge or the cloud?
UV: I think we'll see both approaches, depending on the use case. For resource-constrained IoT devices, you'll have lightweight processing at the edge, but true microservices architecture will likely remain at aggregation points, like edge gateways or the cloud. As devices become more capable with AI chips, we might see containerized services running locally, but the full microservices ecosystem – with service discovery, load balancing, and orchestration – makes more sense at the edge or cloud layer. In retail and automotive IoT, which I've worked with extensively, we process device data through edge services before routing to cloud-based microservices for complex business logic.
CF: How have you applied microservices to your job?
UV: Throughout the past 10 years, microservices have been central to our modernization efforts. I've led the design of multiple systems using Spring Boot microservices – from our Document Management System to our Data Transmissions platform, which handles around 100 distinct data transmissions for major OEMs like Ford, Toyota, and Mercedes. We've built event-driven architectures using Active MQ and implemented REST APIs that allow different services to communicate independently. This approach has dramatically improved our deployment velocity and system reliability, while reducing the complexity of coordinating changes across large codebases.
CF: What was the hardest part of bringing microservices to your job? Convincing management, training personnel, upgrading / retrofitting equipment, or something entirely different?
UV: Honestly, the cultural shift was the biggest challenge, more than any technical hurdle. Convincing teams to move from a monolithic mindset to thinking in terms of bounded contexts and service ownership took time. We had to train developers on new patterns, like circuit breakers, service mesh, and distributed tracing. The organizational structure also had to evolve to align teams with services rather than technical layers. Management buy-in was critical, and I spent considerable time demonstrating business value through proofs of concept that showed faster deployment cycles and better fault isolation before we got full support for the transformation.
CF: Through the years, we have seen career recommendations to younger generations from older generation become outdated – often before the younger generation gets out of school. Given what you see on the horizon and the way AI is impacting different industries, what recommendations would you give to the next generation?
UV: My advice is to become deeply proficient in fundamentals – algorithms, data structures, system design – because those never go out of style, but stay agile with learning new tools and frameworks. Don't just learn to use AI tools; understand how they work and when to trust them, versus when to question their output. Focus on problem-solving and communication skills, because as AI handles more coding, your ability to understand business needs and architect solutions becomes even more valuable. Finally, build systems thinking – understand how your code fits into larger distributed systems, how data flows, and how to design for resilience and scale. The industry is moving so fast that adaptability and continuous learning are your greatest assets.
Edited by
Erik Linask
