Month: June 2018

Depending on how you consider things, it is the third time that it happens to me.
Being able to design, under certain limits, your own job, is an amazing opportunity.
I will not go into too many details as some of it is work in progress, but the process was amazingly energizing and I wanted to share a bit of that energy.
For my current job, I met my future boss on the recommendation of a former colleague. We discussed many things, from ITIL to Managed Services, and also public cloud and the need to get dev and ops team closer. We went through those kind of talks several times, at least four if memory serves. We went from a job which look like an Ops engineer/ITIL practitioner, to something closer to an Azure tech lead.
In my previous position I also had the opportunity to be offered a promotion, and been able to discuss some of the content and responsibilities of the future role. I was also able to step down when time came for me to admit that it was not an ideal position, for me or for the company. Which was really appreciated, at least on my part.

And once again a few weeks ago, I was called out of the blue by a colleague’s boss. He started to discuss his own future and what he was trying to design. He wanted to build something new, and was searching for a partner to build that together. And in that scheme, he discussed a position very similar to my dream job, and offered it to me.
I almost fell off my chair.
At that point I was ready to accept, without having any more details about the exact role and responsibilities, or even the salary. That’s where my future boss started to ask me what I would include or exclude from that job description, and how I could make it my own. My mind just froze.
It took some time for me to recover and start thinking again. After some lame jokes, we discussed the position, and what we would like to build together. It took us several meetings and calls to see through the fog, as we are really going to build something new together, and we cannot rely much on what exists around us.
The last funny thing to happen was that my next interview was with the CEO of the company, who was convinced by the both of us in less than 35 minutes. I could not believe my luck in getting there.
Anyway, that’s it for the bragging post. I really needed to write that down to make it real (even if I signed and will start by the end of the summer 🙂 )

This is a difficult topic. I have to admit I am still not completely comfortable with all the concepts and functions.
However, the thinking is amazingly interesting, and I will take some time to ingest everything.
First things first, I will use this post to summarize what I have learned so far.

How did I end up reading that kind of work, you ask? Weeeellll, that’s easy 🙂
Brendan Burns, in one of Ignite ’17 sessions, used the comparison “autonomous vs autonomic” to discuss Kubernetes.
This got me thinking on the actual comparison, and aided with our trusted friend, Google, I found a NASA paper about that (https://www.researchgate.net/publication/265111077_Autonomous_and_Autonomic_Systems_with_Applications_to_NASA_Intelligent_Spacecraft_Operations_and_Exploration_Systems) I started to read it, but it was a bit obscure for me, and scientific English, applied to space research, was a bit too hard for an introduction to that topic of autonomic systems.
Some more research, helped by me beloved wife, led to a research thesis, in French, by Rémi Sharrock (https://www.linkedin.com/in/tichadok/). The thesis is available right there : https://tel.archives-ouvertes.fr/tel-00578735/document. This one relates to the same topic, but applied to distributed software and infrastructure, which ends up being way more familiar to me 🙂

The point where I am right now is just over getting the definitions and concepts right.
I will try to describe what I understand here about automated, autonomous and autonomic systems.
There is some progression from the first to the second, and from the second to the third concept.
Let’s start with automated. An automated system is just like an automaton in the old world : something that will execute a series of commands, on the order of a human (or another system). For example, you have a thermostat at home that send the temperature from inside and outside your home to the heater controller.

There is no brain in there, or almost none.
The higher step is an autonomous system. This one is able to take some decision and act on the data it captured. To continue with the thermostat example, you have a heater controller which will handle the current temperature, from both inside and outside, and decide whether to start heating the house, and how.
The short version is that the system is able to execute a task by itself.

And then we have an autonomic system. This is able to have a higher view of its environment, and should be able to control the fact that it will always be able to execute its tasks. I have run out of the heater example, but let’s take a smart mower. The first degree of autonomicity that it has is the way it will control its battery level, and return to its base station to recharge, in order to ensure that it will be able to continue its task, which is mowing the lawn.
There are multiple pillars of autonomicity. Rémi Sharrock described four in his thesis, and I tend to trust him on this :

Each of these four pillars can be implemented into the system, to various degrees.
I am not yet comfortable enough on describing precisely the four pillars, but it will come in a future post!