Ten years ago, I introduced Micro as an open source microservices toolkit.
I’d seen microservices work at the company I was working at. They let teams develop services independently, but each team still needed the same infrastructure for discovery, communication and handling failures. Micro provided those building blocks so developers could get on with writing their software.
The name came from the work. Go Micro was a microservices framework for Go. When it became a toolkit, we dropped the Go.
I wanted to build technology that people anywhere could use. Google and GitHub were reference points for that ambition. Micro’s starting point was developers, because that was the work I understood and the problem I could address.
Over the following decade, I worked on frameworks, cloud hosting and APIs. More recently, I brought a set of services together into a personal server. It could handle mail, store notes, schedule reminders and retrieve information.
Each service had its own interface. As I added services, the product became harder to use. There were too many pages, and too much of the underlying structure was exposed to the user.
The services were useful. The interface needed to change.
Micro is now a personal assistant, available at micro.mu. You describe what you need, and the assistant uses the services to carry out the request.
You can ask a question, discuss something, save a note or set a reminder. The web interface provides a conversation and access to what you’ve saved or scheduled. You can also reach the assistant by email.
The purpose is to reduce the work involved in using these tools. An email may contain a commitment you need to follow up on. A discussion may produce a decision worth keeping. A morning brief can help you prepare for the day. These are ordinary tasks, but they take time and are easy to lose track of.
There are further capabilities I want to add. For a trip, the assistant should be able to check availability and return a few places to stay. I can then choose and make the booking. For an MOT, it should be able to look up the expiry date, remember the vehicle registration and set a reminder when asked.
Those requests have limits. Looking for accommodation does not authorise a booking. Access to an email account does not justify reading its entire history. The assistant should carry out the instruction it was given and make clear when it cannot.
Privacy remains unfinished work. Micro uses cloud-hosted models, and information retrieved by its tools can be sent to those models. Self-hosting does not prevent that. We need controls over what is retrieved, what is retained and what is used for background work. Those controls need to be enforced in the software.
The aim is for Micro to be usable by people who have no reason to know what a microservice or an API is. That is what “for everyone” means here. The hosted service removes the need to install and operate it. The underlying runtime remains open source.
The architecture still owes a lot to the Unix approach: small tools with defined responsibilities, composed to do useful work. The assistant provides another way to use them.
There is more to do before V2 is finished. Accepted requests need to survive a lost connection or server restart. Reminders need to arrive when expected. Saved work needs to be easy to find, and access to personal data needs clear limits.
That is the current focus. Micro is available at micro.mu.