Socio-Technical Approach to building Microservices - Series Part 2

Once the initial approach is selected, the next challenge is defining teams and how to manage the key challenges to attain velocity and sizing within teams.

A socio-technical framework is being used more and more when building complex systems, especially those that deal with the principles of working in teams and agile environments where adaptability is the key. Below are a few common questions that the teams need to dwell upon and ask themselves?

How big a microservices application has to be? Should it be a Micro, Macro or even a Mini service?

How to keep in context without swapping out or referring documentation, or human intervention?

How to embrace changes in the application? How to build software that is faster time to market?

How to bring in a new person and develop without any wait times?

The concept of “Cognitive Load” is getting used quite often when sizing microservices. The concept has been borrowed from the psychological dictionary where the cognitive load refers to the information one keeps in the head without referring to something else. It’s a universal concept used for learning and to help maintain optimum load on the working entity. It can be defined as a temporary working memory like a Cache or Ram.

“Producing maintainable software depends on readable information be it code, modules, or documents, and readable information depends on controlling Cognitive Load.”

There are three types of Cognitive Loads defined

• Intrinsic Load is related to the complexity of information that a team is paying attention to and processing. It’s bae skills and demands on specific tasks or technology that one is grasping and the difficulty of learning the task itself. In building microservices this can be the initial load that is required to create an end to end service.
• Extraneous load is completely unrelated to the learning task. These are all the negative distractions and additional effort imposed on the team or system.
• Germane load is the mental processing effort and is directly going towards supporting of development of schema and long-term memory. In building software, it is the repeated decorative knowledge and conglomeration on how this thing to play in a more complicated system.

Intrinsic and Germane load are considered “good” and Extrinsic is “bad”.

Always in teams try to find and offload those extrinsic loads that affect the teams.

The extrinsic loads identified in the teams that I was part of included environmental issues, complicated subsystems, unnecessary complex or business Logic, complex code, misfit teams, team meetings, etc….

Many a time, it could also be as simple as spending time on unnecessary documentation that no one reads or to over-complicate the code or even spending hours contemplating method and object names.

Too much Germane load makes learning a new task harder and slower.

Microservices have a handful of moving parts at the same time and more the moving parts, to begin with, the complicated it gets. Systematic tradeoffs need to be made by teams when building services. Teams have to communicate and learn from each other.

The Intrinsic load should reduce over time as new lower-level knowledge and experience are formed and documented.

Always try to complete that initial simple microservice end to end, and deploy it in production with a database, CICD, alert and monitoring system, testing strategies and version control in place. This makes the subsequent services to be carved out more easily. After a few services spinning up new services and it becomes a cakewalk.

As the experience increases handling cognitive load gets more mature and achievable.