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

Two of the hottest buzzwords in the industry at the moment are DevOps and microservices – both are riding high on the hype cycle and we're starting to see gurus emerge telling us that they will save the IT industry (or at least save the industry a great deal of money). One of the ideas of DevOps is that software deployment …

  1. DwarfPants

    SEP implementation process

    Shock Horror - Complicated remains complicated even if you have moved complexity up stream.

    I suppose it depends where you sit, you could have successfully implemented a SEP (Somebody Else's Problem, thanks to Douglas Adams for inventing this)

    1. Doctor Syntax Silver badge

      Re: SEP implementation process

      "thanks to Douglas Adams for inventing this"

      He didn't really invent it, just communicated it to everyone who hadn't worked it out for themselves.

  2. LDS Silver badge

    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...

    1. Pascal Monett Silver badge

      Re: I really wonder if this stuff will work better

      It won't, but marketing teams will have a new playground to chase bonuses.

    2. Rosie Davies

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

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

      It will. At least it will initially. Then it'll start running into complex interactions between components some of which belong to a third party that is supporting 100 other consumers most of which are richer than you, others that are no longer being actively developed and some in a language so old that everyone's forgotten it's name and the last compiler update is 20 years ago and full of bugs^W known issues.

      Then there will be a lot of arguments, conferences will be held, books will be published. There will probably be religious wars, there usually are. Then best practice will emerge and it'll be possible to get useful work done in a reasonable time-frame with wanting to chew your own fingers off in frustration.

      Then someone will start complaining about how it isn't 'docile' enough and it'll all start up again...


  3. Anonymous Coward
    Anonymous Coward

    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.

  4. Spearchucker Jones

    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.

  5. zanshin

    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.

    1. pben

      Re: What if the interface actually needs to change?

      Turning this upside down, durable sustainable systems can be seen where the fundamental system design is the interface(ing). A good example is the piping mechanism in UNIX. The whole system approach of UNIX could be looked at as piping enabling microservices to interoperate in providing an operating system environment. -- The terms keep changing to support the industries of churn but so many of the fundamental are simply recycled. (old greybeard - with suspenders)

      1. Lysenko

        old greybeard - with suspenders

        Watch how you go there! Too many Brits on this board. What you are referring to (cis-normative microagression warning) are "braces". You use "suspenders" to stop your fishnet stockings flapping around your ankles ;)

  6. Lysenko


    "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!

    1. Quacky!

      Re: Wow!!!

      This discussion around microservices and devops just highlights the gulf between "dev" and "ops". Completely independent ecosystems, corporate players, methodologies, business goals and metrics, etc.

      Looks like an incredibly immature environment and marketplace, maybe 20 years from a genuinely integrated approach.

      @Lysenko - spot on, but it's not because one side is smarter than the other(*), it's just a fundamental difference in approach and incentive.

      (*) My experience and applying Occam's razor - your experience might suggest otherwise.

      1. Anonymous Coward
        Anonymous Coward

        Re: Wow!!!


  7. Christian Berger

    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.

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Biting the hand that feeds IT © 1998–2021