I finished listening to the Hyperfish Microsoft Flow podcast from Jon Levesque and Jeremy Thake this morning, this was recorded around the same time where I had an interview with Jeremy as well - and there's some great contrasts between two podcasts that I wanted to point out, and write them down.

This is a blog post that talks about many but related things.

1. Flow for developers
   Flow as a Serverless Middleware Platform
   Where to start learning Flow, as a developer
    
2. Flow for everyone
   Flow as a Systems Integrator
   Where to start learning Flow
    
3. The plateaus of learning Microsoft Flow

Flow for Developers

Since Jeremy is taking up the challenge to continue the Office Dev Podcast again, we had a really targetted conversation towards Microsoft Flow for developers.

Why would we, as developers, want to learn a tool like Microsoft Flow - it's JSON, it's not even code.  Why?

The reason I laid out is progressive, but simply - because we need a serverless workflow orchestrator that can handle parallel runs, fan-out and fan-ins, and handle remediation steps, providing an out of the box serverless try-catch-rollback-finally condition.

This makes sense the more AzureFunctions we write.  Suddenly we need to chain them, and guarantee they run correctly.  Yes, you can chain or fan-out AzureFunctions with an Azure Queue, or larger message packets with a Service Bus.  But you need the Durable-AzureFunctions extension to handle fan-in.  And you can't handle exponential timeout fallback policies.  Which, is just a drop down choice in Flow.

And the next thing - well, hey there's 300 connectors where we don't have to write any code at all (Jon Levesque says there's 215...  I think he's a bit too low, and I'm probably way too high).  So to me, Microsoft Flow is a Serverless Middleware Platform. 

When I was asked - where should one start learning Flow?  I said we should start on "Logic Apps Workflow Definition Language".  Because to me, a developer learns the language first, that unlocks all the secrets of the system.

https://docs.microsoft.com/en-us/azure/logic-apps/logic-apps-workflow-definition-language

I was slightly worried that we didn't cover the Power-User angle at all in our conversation.  It was very much pro-developer.  My worries evaporated after I listened to the second interview with Jon Levesque.

Flow for Everyone

When asked what is Flow - I was surprised Jon says it is the great System Integrator.  It isn't about workflow or process automation, although that is one of the possible use of the tool.  But to Jon - the key value of Flow is in extending and connecting existing systems.

I was also delighted that when asked where to start learning Flow?  Jon says start on "Microsoft Flow Guided Learning".

https://docs.microsoft.com/en-us/flow/guided-learning/

Jon goes on to explain some of the future ideas for Flow:

1. More seamless when integrating with products (e.g PowerApps)
2. No Expressions - it will go away.

I cheered!  Wait - what?  John, you just recommended people learn Expressions and you cheered when Jon says Expressions is going away?!  Why are you so inconsistent?!

The Two Plateaus of Learning Microsoft Flow

The drawing is Two Plateaus of Microsoft Flow.  This is a drawing mirroring the two areas where we find our learning reaches a plateau and seems stagnant.

The first hill is Expressions.  Flow creators gets familiar with connectors and variables and chaining outputs, then we get stuck on expressions.  It's so weird, there are so many of them, how do they work.  To get over this first plateau, we have to read through the Logic Apps Workflow Definition Language.

The second hill is where we don't have a connector - and this get troublesome, as we now need to extend Flow with your own connector.  I label this hill as "AzureFunctions" and "Swagger".  We write AzureFunctions to fill in a missing connector.  And we write Swagger/OpenAPI custom connectors to link to an existing API (or our own).  The second hill is tough, and more or less a pro-developer task.  Although, I have seen many people having a great time running PowerShell in AzureFunctions to get over the second hill.

The learning path progresses from Left to the Right - learn expressions and we master the hard part of Flow - our only remaining gap is waiting for missing connectors.  Learning Functions/Swagger plugs those gaps too.  Developers coming to Flow from the right, having learn AzureFunctions already, has an advantage in that we may already know how to plug a missing hole.

The work for the Microsoft Flow team is going from the Right to the Left.  Expressions should be simplified - the ultimate Flow creator should not need to know how to write expressions.

I build this Microsoft Flow "Quiz" Form for people to try test their first plateau.  This is the first question.

I feel it perfectly encapsulates where Flow needs to go, where we all need to go.

Summary

So here they are:  two, in-my-humble-opinion, wonderful Podcasts on Flow, recorded nearly at the same time, and asked the same questions by the host Jeremy - yet we have two different angles looking at a product from two sides.

You should listen to the Developer or the Everyone one as it applies to you, and if you intend to listen to both - I suggest listening to the Developer one first with John Liu (as I'm not that polished in talking) and then wrap up with the fluid soothing voice of Jon Levesque, who goes on to sum up the future of Microsoft Flow.

These are great podcasts.  I really enjoyed them, and I swear I'm not that used to my own voice!

PS. Let me know if you want me to finish this Quiz so you can test your ninja Flow skills.