No, Agile does not 'equal' DevOps: Examining complexity and the long haul

Microservices, the new DCOM/CORBA/JavaBeans components...

Microservices are just another name for software components, especially distributed ones. (D)COM, CORBA, JavaBeans were all the same kind of solution which got a lot of hype in the 1990s.

Those as well should have been separate components with well defined interfaces, language agnostic (but Java ones), well tested, so you could build your application joining together separate components written by different teams and orchestrated by some framework. And they even did a great effort to let you call define and call interfaces as if they were "local" calls, with parameter marshalling, data conversions, ACLs, and more, not the ugly, primitive RESTful calls over HTTP of today.

It didn't work out quite as envisioned.

Especially because I know companies who thought that could have been a way to hire cheaper (and less skilled) developers hoping they could just "assemble" like in a factory pre-made components developed by a smaller group of better (and more expensive) developers, or bought outside.

I really wonder if this stuff will work better...

There have always been the unexpected consequences in a system interaction. That's when the developers all say "my bit is working ok". Unfortunately the people who can sort out system problems need an aptitude - and to have learned their trade in many different situations. Careers these days are focussed on "industrialisation" - where you are paid for a specialisation in one narrow level of one component.

A generalist who can show various groups why their components fail to mesh under certain unexpected conditions may be lauded during a crisis - but no one would allow them the time and experience needed to grow those wide skills in the first place.

Micro services do not break up a monolith - they just move the sh*t to another place and spread the sh*t out. Making finding problems harder - not because technology, but because where with the monolith you may have had 1 to 3 teams, each micro service has a team. Each team probably has their own release pipeline hobbled by corporate governance and change control.

Monolith domain knowledge dilutes, contractors eagerly rub hands together, nightmare ensues, stock exchange crashes, economy collapses, flu shot evolves into the T-virus.

What if the interface actually needs to change?

Wholesale change in interfaces does happen in the real world. Eventually old versions of interfaces need to evolve so extensively that the old interfaces need to be demised. Perhaps there are new technologies or standards to leverage. SOAP being replaced with REST, say. Or perhaps there's just been a broad design shift in what your service needs to do, affecting all its interfaces. I've seen both happen in environments I support, though the services weren't "micro" in the DevOps sense. Surely similar considerations still apply, though.

I guess in cases like this you can transitionally support both interfaces from your (micro)service (or add the new interface as a new service) and demise the old interface later.

That's still something you can't *just* cover with testing in a sufficiently complex (i.e. enterprise) environment, since you have to make very sure you know who all your consumers are before you demise older interfaces they might be using. Appropriate logging in your production instance can be invaluable here, so you can see who is actually making requests, to reach out to them to make sure they're ready (and have tested) for their applications to consume your new interface.

This doesn't mean the whole DevOps approach doesn't have merits, but at least as I see it discussed in brief in articles like this, the shiny, happy world they describe seems like would only really manifest in environments where its easy to manage all the service dependencies.

I won't mind being corrected if I'm just missing something.

Wow!!!

"Enter microservices that are designed to replace large monolithic systems with much smaller systems that are very fine-grained (sometimes so small they do one job and one job really well)."

This is ground breaking stuff!

A grab bag of individual utilities that do one thing and do it well, working together to achieve a larger task? You could even design an operating system using this ethos. Why didn't anyone think of this before!?

It is such a pleasure to be in this industry at a time when thinkers like these are innovating so dramatically. Such a change from those crusty old farts in the '70s. They could never imagine such a sublime vision. Not their fault I suppose. They didn't even have JavaScript!

The problem with this will be...

... that people have been trained to make highly complex interfaces like SOAP or whatever.

This concept only was able to be so successful on Unix because the interfaces were dead simple yet incredibly efficient. Take a look at sort, it can sort any kind of dataset. It doesn't need to be adapted when you change your dataset as long as it's tabular data with one line per dataset.

It's little use splitting your task into several if most of the complexity will lie in the interface between them.