Showing posts with label Software Architecture. Show all posts
Showing posts with label Software Architecture. Show all posts

Wednesday, July 22, 2026

Agents Are the New Microservices

 


A team I talked to recently took their working AI feature (one model, one prompt, one call) and split it into twelve cooperating agents. A planner, a researcher, a critic, a writer, a few tool-callers. The demo was beautiful.

Then they tried to run it in production and discovered they no longer had an AI problem. They had a distributed systems problem. The exact one the rest of us solved, painfully, a decade ago, and called microservices.

If you sat through the microservices years, the agent conversation in 2026 should feel like déjà vu. Same pitch, same gleam in everyone's eye, and, I'd bet, the same bill coming due.

The industry decomposes on a cycle

Step back and software architecture is a pendulum. Monoliths to SOA to microservices to serverless. Every wave breaks the system into smaller, more independent pieces, sells the same benefits (independent deployment, team autonomy, scale the hot parts) and quietly ships the same costs. Agents are the next swing.

But there's a real insight underneath the hype, and it's worth saying clearly. Microservices decomposed your code. Agents decompose your work. A microservice is a slice of functionality waiting to be called. An agent is a slice of a decision, pursuing a goal. That's a genuinely bigger idea, and it's why the pitch is seductive: you stop wiring logic for every edge case and instead hand a goal, some tools, and constraints to something that figures out the path. When it works, it's remarkable.

The tax comes back, with interest

What the slide never mentions, then or now: the moment you split one process into many that talk to each other, you inherit every problem of distributed systems whether you wanted them or not. Unreliable calls, timeouts and retries, debugging across boundaries, tracing, state that used to be a variable and is now a message someone might not receive. Conway's law shows up on schedule: your twelve agents start mirroring your org chart instead of your problem.

We paid for those lessons in outages. Agents inherit the whole invoice. But they also change the shape of failure, and this is the part that should keep an architect up at night.

A microservice fails loud. HTTP 500, a timeout, an alert. You know. An agent fails quiet. It returns something fluent, confident, and wrong. There's no error code for "plausible but false." One agent hallucinates, the next treats it as fact, and the mistake compounds down the chain like a game of telephone with no exception thrown. You don't get a red dashboard; you get a subtly bad outcome three steps later.

That's because the "contract" between two agents is natural language. No schema, no types, no compiler to catch a mismatch. The thing distributed systems spent twenty years learning to depend on, gone. And the work isn't deterministic, so the same input can take three different paths, which means you can't unit-test your way to confidence. Add that each hop is a model call, so latency and cost stack, and your elegant twelve-agent design can burn fifty inference calls to answer one question.

Honest version: agents can be microservices with brains, or microservices with worse tooling. Which one you get depends entirely on the discipline you bring.

What's genuinely better (To tax, you need income)

It would be lazy to only sound the alarm. Some of the upside is real and new.

Agents adapt without a redeploy: change a goal or a prompt, not a CI/CD pipeline. They can wrap a legacy monolith that has no API, driving it as a tool, which resurrects systems you'd otherwise pay millions to rewrite. They can self-heal and triage, routing around failures instead of just reporting them. And service discovery gets smarter: instead of looking up payment-service-v2 by exact name, an orchestrator can ask for "something that can process a payment" and match on capability. These aren't small.

So agents won't replace microservices

The headline is provocative, but the literal version is wrong, and the options that claim agents simply replace microservices are selling the same over-decomposition that gave us the distributed monolith. The accurate version: agents won't replace microservices. They'll sit on top and consume them. The deterministic, transactional, regulated heavy lifting stays in boring, reliable services. The cognitive, orchestrating, user-facing layer becomes agents. The future is a hybrid, and the architect's job is drawing that line well.

The lessons we already bought

We're not starting from zero. We paid for this education once. The trick is using it.

Start with the monolith. The hardest microservices lesson was "don't decompose first." One well-built agent beats twelve that need a committee meeting to answer a question. Split only when a real seam forces it.

Schema the handoffs. If agents must pass work, pin the boundary to typed, validated structure, not free prose. Give the natural-language soup a contract where it crosses a line.

Buy observability before you scale, not after. With agents you need more than logs and traces; you need the reasoning and inputs at each hop, or you'll never reconstruct why the system did what it did. Tracing a request becomes tracing a thought.

Don't decompose by hype. We split into microservices because it was fashionable, then spent years merging them back. Don't earn that scar twice. Decompose by genuine boundaries (different scaling, ownership, rate of change), not because "multi-agent" sounds advanced on a slide.

The actual point

The architects who came out of the microservices era well treated it as a tool, not a dogma. They knew "distributed" is a cost you pay for a benefit, and they paid it only when the benefit was real. The ones who suffered adopted the pattern because the conference talks were exciting.

Agents are at exactly that fork. The capability is real, the architecture is familiar, and the failure mode is predictable, because most of us have lived it once already.

So before you split your working system into a swarm of clever agents, ask the same question that should have been asked in 2015: do you have a problem that actually needs distributing, or do you just like the diagram?

Friday, January 21, 2011

Book Review: Beautiful Architecture Leading Thinkers Reveal the Hidden Beauty in Software Design

Book Review: Beautiful Architecture Leading Thinkers Reveal the Hidden Beauty in Software Design by Diomidis Spinellis , and Georgios Gousios: Publisher- O'Reilly: ISBN- 13: 978-0-596-51798-4
Beautiful Architecture book is loosely coupled collection of articles from industry veterans. Book starts with very basics like what is architecture but then deep dive into more complex and intricacies of software architecture. This book is certainly not for green horns.

The book is to be read in non linear fashion. Read first chapter and then on the need and requirement basis, read the respective chapters. I am not going to that what each chapter does which you can get from Amazon or O’Reilly or other reviewers.

As one of the reviewer at Amazon said “too many cooks” and “half backed”.

Disclaimer: I did not get paid to review this book, and I do not stand to gain anything if you buy the book. I have no relationship with the publisher or the author.


One can get more information about book and related topics from:

1. Amazon: http://www.amazon.com/Beautiful-Architecture-Leading-Thinkers-Software/dp/059651798X
2. BookMooch: http://bookmooch.com/detail/059651798X
3. Publisher – O’Reilly http://oreilly.com/catalog/9780596517984/
4. Book Review: http://www.spinellis.gr/blog/20090204
5. One more review: http://millionchimpanzees.blogspot.com/2009/03/beautiful-architecture-leading-thinkers.html
6. Last one: http://www.i-programmer.info/bookreviews/10-software-architecture/155-beautiful-architecture-leading-thinkers-reveal-the-hidden-beauty-in-software-design-.html

Thursday, July 16, 2009

Software Architecture

Software architecture is formulation of optimum interaction among components keeping current and foreseeable future requirements (functional and non functional) in view while ensuring that required compliance and required industry standards are followed.

Lucky 13

While doing my job as software architecture I follow certain rules. I call them as Lucky 13. I have borrowed these principles from different streams of knowledge. Few of them are just picks and few are modified to fit software architect’s job description.

1.Be Lazy: Do not reinvent wheel, also what ever I create, it should be reusable within time and resource constraints -- From Object Oriented Principles
2.6 Wives and 2 Husbands Principle: 6 Wives – What, When, Why, Who, Where and To Whom. 2 Husbands – How and How many/much -- From 6 Sigma and Lean
3.One plus One is Eleven: When two heads work together their synergetic output is more than arithmetic summation -- Extreme Programming
4.Democracy is good but Veto system is required: In case of dispute there must be a authority to take decision à Political Science
5.One is not enough: If there is only one way of achieving goal/target, more grey matter is required -- War Theory
6.Nothing is future proof: No one can predict future only guess. Today’s systems is tomorrow’s legacy -- Experience
7.Organization hierarchy governs visibility: As persons move in Organization/Project hierarchy has more visibility of overall picture -- Organizational Theory
8.Learn Daily: The day you do not learn some thing, deduct that that day from your experience in resume -- Experience
9.Business has Money and veto power: Architecture might be superb but if there is no money and business requirement then it is not a workable solution -- Experience
10.Process’ absence as well as presence has its own burden: No or little process invites chaos while excessive processes brings red tape -- Process and Control Theory
11.Time and will are pre-requisites: To active a target with given constrains Time and will power are pre-requisites apart from resources -- Time Management and Psychology
12.Perfection is an illusion: For worldly challenges good enough solutions are sufficient -- Philosophy
13.Be an architect not consultant: Consultant is like Seagull. He flies high, zero on some thing good, take that good thing, create some disturbance, leave shit behind and fly way -- Experience

Thursday, July 9, 2009

Book Review: 97 Things Every Software Architect Should Know Edited by Richard Monson-Haefel: Publisher- O'Reilly Media, Inc.: ISBN- 10: 059652269X

This book introduces new concept of book writing – Community Book. And to pleasure of Open Source supporters, book is available under Common Creative License.

Book consists of 97 aptly written essays about Software Architecture barring technical details but focused on Business and human behavior. Book does not mention any vendor and technology specific details which makes universally applicable. Unlike other Software Architecture books which are highly loaded with UML, patterns and other technical details this book covers practical day to day practices for software architecture.

97 Things Every Software Architect Should Know is crisp 200 pages long. Few of the participating authors are well known authority in software while some are hidden gems who yet to be discovered. Few of the authors have their own site and blog which will give insight into their work.

1 Allison Randal (The lead developer for Parrot)
2 Barry Hawkins
3 Bill de hÓra (Co-editor of Atom publishing protocol)
4 Brian Hart
5 Burk Hufnagel
6 Chad LaVigne
7 Clint Shank
8 Craig L Russell
9 Dan Chak
10 Dave Anderson
11 Dave Bartlett
12 Dave Muirhead
13 Dave Quick
14 David Ing
15 Doug Crawford
16 Eben Hewitt (Author of SOA Cookbook)
17 Edward Garson
18 Einar Landre
19 Eric Hawthorne
20 Erik Doernenburg
21 Evan Cofsky
22 George Malamidis
23 Greg Nyberg (author of the WebLogic companion workbook for Enterprise JavaBeans 3rd Edition and is the lead author of the book Mastering WebLogic Server )
24 Gregor Hope (Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions (Addison-Wesley Signature Series)
25 Jeremy Meyer
26 John Davies
27 Kamal Wickramanayake
28 Keith Braithwaite
29 Kevlin Henney (coauthor of two volumes in the Pattern-Oriented Software Architecture series: A Pattern Language for Distributed Computing and On Patterns and Pattern Languages)
30 Mark Ramm
31 Mark Richards
32 Michael Harmer
33 Michael Nygard (Release It!: Design and Deploy Production-Ready Software (Pragmatic Programmers))
34 Michael Nygard ( “Release It! Design and Deploy Production-Ready Software” - a 2008 Jolt Productivity Award Winner)
35 Mike Brown
36 Mncedisi Kasper
37 Neal Ford (Author of “The Productive Programmer”)
38 Niclas Nilsson
39 Nitin Borwankar
40 Norman Carnovale
41 Paul W. Homer
42 Peter Gillard-Moss
43 Philip Nelson
44 Randy Stafford
45 Rebecca Parsons (CTO of ThoughtWorks)
46 Richard Monson-Haefel
47 Sam Gardiner
48 Scot Mcphee
49 Stephen Jones
50 Timothy High
51 Udi Dahan
52 Vinayak Hegde
53 Yi Zhou
54 Zubin Wadia (Author of: "The Definitive Guide to Apache MyFaces & Facelets" and "Facelets Essentials: Guide to JavaServer Faces View Definition Framework")

In nutshell book spells out two vital things:

1. Role of a Software Architect
2. What should a Software Architect know apart from technical details?

In starting of book natural question come into mind that why 97, why not 96 or 98 but as you go along with book you do not care about its count. You can get details of why 97 at its site

97 Things Every Software Architect Should Know is already in bookshelf.

Disclaimer: I did not get paid to review this book, and I do not stand to gain anything if you buy the book. I have no relationship with the publisher or the author.

Further reading:
1. The Architectural Journal (Microsoft) 15
2. www.bredemeyer.com/pdf_files/role.pdf
3. http://en.wikipedia.org/wiki/Software_architect

One can get more information about book and related topics from:

1. Book’s web presence
2. Amazon
3. Publisher – Oreilly
4. flipkart
5. Barnes & Noble
6. For Indian Customers
7. One More place for Indian Customers
8. Discussion at The Server Side
9. Review by Mark Needham
10. Review by Brian
11. Book Review at Dzone
12. Review at Meme Agora
13. One More Review
14. Another Review
15. The last one