Provocative … ;-)

If you were to deal with complexity by systematically implementing infrastructure as code and API Gateway-styled registry, would you change your view?

The process of evolving monoliths to separate the UX/UI-specific services that address limits or strengths of the UI from the business services that should be used by any UI, and to scale them independently, is a formidable task. An iterative approach to architecture factoring is avoidable if what has come to be called microservices are used. When microservices first became a thing, there was (my view) a (very) impractical point of view that microservices could be implemented in distinct stacks, etc. Polyglot taken to an extreme makes no sense, but it does make sense because there are right tools for right jobs… I think the microservice thinking has evolved to be sensible, and serverless functions in public clouds also make such cost effective if granularity of the service is effective (fine-grained services shouldn’t be public, again my view). Perhaps I am a bit old-school here, but I think “services” are “microservices done right” because services represent right granularity. But I stray into religion here, perhaps…

I’ve come to believe that complexity is quite deceptive… we seem to form a view that evolving toward a microservice platform from a monolith (or whatever) is a problem that can be solved. BUT I think there are plenty of counter examples… all seem to distill to the task becoming a multi-year and costly effort. Of course, you’re right … if something built is small, maybe microservices aren’t needed for scale (maybe cost, though, given the quota freebies given in Amazon et al). But there are problems that start out big if you invest appropriate amounts of planning in them. I’d venture to say this is more with a focus on systematic agility than agile… (more religion… with half hearted apologies… ;-)).

Thanks for your article… one can see from the responses that you struck a (good) nerve. Best to you…