BPM - Getting it off my Chest: Microservices and APIs 

I mentioned in post 17, that I had come back from a conference on Application Architecture.  Hosted by a national vendor with a good reputation for quality.  I'm expecting a call from the account rep asking me how I enjoyed the conference.  I think what I'm simply going to say is that "the coffee was good."

And leave it at that.


My first criticism was simply that the conference was more "bread than meat" -- the topics were only covered in the most cursory manner.  They were all the proverbial 50,000' fly-by.


I get it - the sessions are 45 minutes; you cannot get into too much detail in 45 minutes.  But still, that wasn't long enough for me.  I don't think I'll go back to this conference because of this alone.

But there was something else at this conference. What's a polite synonym for pandering? By the way, BPM, for this post, does not stand for Business Process Management.

Buzzwords de' decade.

Microservices and APIs.  Ugh. Every damned slide, poster, badge, ornament and coffee cup holder was emblazoned with Microservices and APIs.

Really? Really?  Really?  Give me a break.

So just what is an API anyway?

This one was puzzling.  We've been defining, designing, implementing and using APIs for over 40 years.  What was so different about the 2014 definition to warrant all this hype?

What's in shared library or DLL?  An API.  How did the client / server applications we created in the 80s interact? Through APIs.  Apollo Network Computing, OSF DCE, CORBA, SOA -- all laden with APIs.

So what's the difference between a service and an API anyway?  Only one analyst tackled this one head on and answered "Nothing." Thank you!

I'd venture a guess that that vast majority of attendees didn't know or didn't care about this.  I did.  Is it just the malcontent of an old curmudgeon?  I don't think so. I walked out feeling like I was being hyped.

I expect this kind of hype from a vendor.  But I thought it quite beneath the analysts at this conference. 

I found it distasteful.

Microservices

Goodness I don't know where to start.  Maybe I'll start off with a couple of opinions.

Opinion Number 1 - There's nothing new here

Service based design and programming is as old as dirt.  

Ok - as old as computer dirt.  I stumbled across the early trails, then called Network Computing, in the mid 80's with such offerings as Sun's RPC/XDR, and NFS products.  

A few years later and the design approach had gathered enough of a following to warrant OSF's DCE offering.  So it's at least 35 years old, and probably older.


Again - this isn't a rant about the old farts not getting credit for something.  This is a warning. Services, micro or macro, are not new. 

The service-based shoals of application development are littered with the bodies of those who've tried and failed to make these things work.  Which leads to Opinion Number 2.


Opinion Number 2 - There were 54 problems we ran into when designing applications using services.  Microservices takes that number down to 53.

When creating non-trivial applications using services we ran into:

• language independent service discovery
• transaction management
• auditing / logging
• orchestration / choreography
• common context (enterprise object models)
• contractual obligations / promises
• testing
• granularity
• security
• error handling

And 43 others.  Just Google "SOA implementation problems" for a taste of what we ran into.
With microservices there's a half-hearted attempt to tackle one: granularity.  Make 'em small.  How small?  Can't tell you exactly.  Make 'em small enough but not too small. Make 'em just the right size.

Sweet.  Thanks for the help.
You want to make a real impact - tackle error handling. That should be simple enough.

Bull Hockey

One analyst tossed up a slide showing that "applications of the future will be an assembly of microservices."  It was difficult to remain seated.  I've seen that slide, in one form or another, for 20+ years.

Ok - show me.
Show me one non-trivial application constructed from an assembly of microservices.
Show me one, non-trivial, business relevant, customer facing application:

• assembled from 6 or more microservices
• with microservices created by 2+ vendors

Sigh.
Never mind...

So, what?  Give up?

When I was a kid, about 7, I came to the conclusion that we had invented swearing. My generation had invented cursing. I didn't hear it at home (much) but there was this 5th grader, Jeremy, that could make a sailor blush.

Since that was my first real exposure to the art of cussing, I assumed that Jeremy, the 5th grader, had started it all.

Around 2005, give or take, I had a young gun from Microsoft come into work for a presentation (on BizTalk, I think) and state categorically that Microsoft had invented distributed computing.


If this is your first exposure to service based development, you might think you're blazing uncharted territory too.   That's fine.    Please let me repeat: this isn't the malcontent of an old curmudgeon who feels like we didn't get our share of credit. I personally had nothing to do with the science, the design of service based design.  I just hopped on the bandwagon.


If I have seen further it is by standing on ye sholders of Giants.

Do your homework.  Don't make the same mistakes or run needlessly into the same obstacles we did.


Don't give up.  Keep working on it.

But I'll close with a suggestion that you keep a George Santayana quote in mind about remembering the past.

Good luck.
May you have more success that we did.