The promise of speed and autonomy in development comes at a cost.

We are won over by the idea of coding with abandon. We can write beautiful pieces of code. Each is a widget running in its robust little container on some virtualized compute complex, virtually interconnected. Secured from within and outside.

It looks like this.

Here the developer is the lord of his or her realm. Wardens of their land. I mean, their data and address space. They call up APIs for external services as if they are sending ravens with messages. They are micro-minions holding on to data in their small realms and processing it; offering services to others.

It is fairy-tale living until the world comes crashing down in “Ops”.

Oops! Everything was perfect in “Dev”. Things got ugly in “Ops”.

Why? Stuff happens in Ops. It is real-life out there.

Microservice is Not Lone Wolf!

Fragments of business logic can be created in isolation, but making the business logic fragments work together requires collaboration. Collaboration in release, change management, audits, integration, tuning…Collaboration is not for lone wolves.

What! All that freedom and we can’t do a thing on our own?!

That’s right. We all find ourselves in dire straits if you are a lone wolf programmer and we rely on your microservice.

Code Reuse does not a Microservice Make

The lone wolf threw in their towel and said “Okay. I’ll just focus on code reuse then.”

Sounds good? That is like adopting the other kingdom’s dire wolf and trying to tame it in our kingdom, giving it all our food after killing off our own messenger ravens.

Will you share your precious data and address space with another dire wolf? Does this wolf have access to the other kingdom’s data? Doesn’t that defeat the very purpose of autonomous fragments of distributed business logic?

We are back to separate data and address space kingdoms. Back to having to play nice. Back to collaboration to avoid the “Oops” in Ops.

No dice, Mr. Reuse!

What are we to do?

Where is the Choreographer?

Enter the Hand of the King.

He or she choreographs your logic, stitching the fragments using the APIs to make the realm function as one. Soon, ravens are flying all over the place.

Like this:

 

Problem solved? Well, the Hand of the King may be a maestro in orchestration, but they are no wizard. This problem won’t vanish with the shaking of a wand.

When things go Oops in Ops (which we know it will!) how do they diagnose problems. Is it the micro service itself? Is it the container? Is it integration fabric? Is it the virtual network connector (which itself is a VNF, virtualized network function)?

Should we go Serverless?

Sure thing. Already it feels like there is no king. Might as well go serverless too and hope the new RPC (remote procedure call) fixes our problems.

Yes, some of the Ops problems can be avoided, such as provisioning and scaling. Still, you must choreograph your minions. Then there is the minor matter of run-time costs and transaction costs per message, and the major matter of lock-in’s if you are paranoid about being able to check-out anytime you like from one cloud realm and check-in to another.

Moral of the Story

Many morals actually.

• Do microservice, but don’t be a lone-wolf
• Have a choreographer or be one
• Think Ops and troubleshooting
• Choose deliberately when to go serverless

First published in ITNext