There’s a huge number of books written about how to get things done. Some of them are about personal development, some about project management, some about business strategy, and some are just pragmatics for the general case.
Skipping the computer aspect, just leaving instructions for people is tricky. For instance, something as basic as washing laundry has dependencies and can interleave with other things.
A home washer/dryer example. It would seem a checklist would work:
- place dirty laundry in washing machine
- add soap
- pick cycle
- start machine
Pretty basic. Except it’s not. The cycle is automatic and may finish in 34 minutes for instance. During that time, then, the person can do something else.
They can interleave the task of doing laundry with another task. They aren’t multi-tasking, per-se, but they can have the washing machine running, they can then load and start the dishwasher (while the washing machine runs) and then do something else, then move laundry from washing machine to dryer …
In short, even simple things in the real world have relationships and temporal inter-dependencies.
How, then, do we let a computer create a plan or schedule, since it would have to be told all of these things?
I’ve been pondering a common misconception: Microservices are synchronous. Or, Microservices are asynchronous. Both are actually missing the point!
The use of common libraries when implementing microservices using HTTP as a transport has many characteristics of synchronous coding. A request is made, and then one blocks until the result is availble, and then processes the result of the request. That sounds like synchronous code.
However, it’s only the way the code is written that makes it synchronous. For instance, if instead of using a library that takes the request details and returns a set of results, one could use a library that issues the request and then returns without waiting for the eventual results. That would shift the model to asynchronous programming.
So, are microservices synchronous or asynchronous?
What’s the real difference? Actually, it’s easier to show than tell …
Today I’m working with a founder who is struggling with a common problem. Their application (still running dark, please don’t ask) provides automation for data capture and evaluation for mission critical repetitive tasks.
It’s hard to get time with the people who do the work (my client understands not to ask their boss!) but time was arranged with one of the many people who do the job and will run the application. The client knew not to ask “What are your processes and workflows?” because that question makes no sense to most people. Instead, the question was “What do you do to carry out the task?”
Now, it gets interesting, because other experts must take the same set of inputs and produce the same result … but from less formal earlier sessions it’s clear that each of the experts do things differently.