What is Mity

Mity (pronounced like mighty) is an idea to develop a tool to invoke workflows that are orthogonal to each other but from the perspective of a team are all related to their functions and activities.

So what really is Mity? It's not one tool per se; it's an idea to build a similar tool for your team. I may build such a tool for my own home lab and may even open source it.

Let's take my home lab as an example. I use Terraform, Ansible, Vagrant, make, sh, Python, and other tools to orchestrate workflows in my home lab and for my servers in the cloud. All these workflows are disjointed. Each task is performed independent of others. If I laid out all my code repositories in a consistent manner on the file system, I could write a command line interface (cli) tool to run these workflows much more easily.

I provision servers in Digital Ocean with Terraform and configure them with Ansible. I cd to the directory where my code lives and run make targets to execute a task. I also provision my home firewall with Ansible in a similar way: cd to the directory and run make targets. What if I had a single Makefile, for example, with appropriate targets to run these workflows? That Makefile would be the implementation of the concept behind Mity. Now instead of a Makefile I could implement it in Python. The implementation doesn't matter here; pick the tool that your team likes best.

Let's take this one step further. In my day job as a Site Reliability Engineer (SRE) I interface with multiple systems. Some are built by my team, most are built by others (both in the company and outside). As newer systems expose Application Programming Interfaces (APIs) to manage them, it makes my job easy as I can automate and orchestrate as needed. Mity could be used to combine this automation and orchestration with a single tool. For example, running Ansible playbooks and testing infrastructure are orthogonal but my team could invoke them from a single binary maybe concurrently but mostly independently and separately. It doesn't necessarily have to be a cli or Graphical User Interface (GUI) tool. It could be implemented as containers on Kubernetes or as functions in serverless.

Since I am a big believer in DevScale my implementation of Mity would be a cli tool. The benefits of this implementation as numerous. It becomes the smallest unit of implementation and can be easily run by a single operator (such as a person). It can be run in a container on Kubernetes or in a CI system. It can even be run in AWS Lambda or kin. But the focus of the implementation remains on a single tool.

This idea was inspired by a talk by T-Mobile's Amreth Chandrasehar and Thom McCann at KubeCon + CloudNativeCon North America 2018 titled Observability at Scale (recording). They have an orchestration platform called Conducktor that integrates services such as Continuous Integration and Continuous Delivery (CI/CD), logging, telemetry, etc.

So go ahead and build your own implementation of Mity. You don't have to share it with the world but do share your experiences of building and operating such a tool. We can all learn from and inspire each other.

Edit: I have created a companion implementation in Python, also called Mity. I plan to work on this tool as a proof of concept.