Wie sollte man sich als Auftraggeber verhalten, wenn man in Analysen und Projekten aufgezeigt bekommt, dass man über – nennen wir es mal so – Verbesserungspotentiale in Hinblick auf agile Vorgehensweisen, Automatisierung und cloud-natives Monitoring verfügt?
…for reverting the Namespace-configuration of my domain back to some real old version – resulting in this blog being available not at the well-known address.
…dafür, dass ihr die DNS-Einstellungen meiner (bisherigen) Hauptdomain auf uralte Werte zurückgesetzt habt, indem ihr die Nameserver-Konfiguration geändert habt.
(This is the German version of my Dear Clara (*), …-article I posted some minutes ago)
…ich bin nicht der Techniker-zu-Deiner-Verfügung, als den Du mich eventuell ansiehst, weil ich unter Umständen einige Informationen teile, vielleicht Dinge weiß, die Dich interessieren oder wir uns gegebenenfalls mal in der Vergangenheit getroffen haben, ein paar Worte miteinander wechselten oder uns gar beim Turniertanzen gemessen haben.
Wenn Du mich also im sozialen Netzwerk Deiner Wahl etwas fragst, dann gibt es kein Universum, in dem Du von mir erwarten kannst, dass ich Dir innerhalb von Minuten, Stunden oder sogar Tagen antworte. Du wirst Deine Antwort bekommen, jedoch nur zu einem Zeitpunkt, an dem es mir auch passt.
Nebenbei (auch wenn es sich vielleicht anders anfühlt): Ich bin nicht sonderlich aktiv in sozialen Netzwerken unterwegs, ich schaue da vielleicht jeden zweiten Tag hinein, habe keinen FB-Messenger installiert, ja ich benutze noch nicht mal die Standard-Apps für das jeweilige Netzwerk auf meinen mobilen Geräten und habe sämtliche Benachrichtigungen dieser Netzwerke abgeschaltet.
Deshalb tue mir bitte einen Gefallen: Erspare mir, von Dir im sozialen Netzwerk Deiner Wahl gestresst zu werden, und das noch nicht mal 48 Stunden nach Deiner Anfrage. Es wird nicht dazu führen, dass ich schneller oder qualitativ hochwertiger antworte, aber es wird definitiv dazu führen, dass Du dir von mir eine Breitseite und eine geharnischter Antwort einfängst. Und wenn Du Pech hast, dann blogge ich sogar darüber und wenn Du ganz viel Pech hast, rutscht mir sogar Dein echter Name raus, Clara. Deshalb: Frage und frage auch nach – Du sollst Deine Antwort auch haben. Erwarte sie aber nicht in Echtzeit oder zeitnah, deshalb frage lieber zeitiger. Erspare mir Deinen Frust und Deinen Stress, sonst bekommst Du das genau so zurück.
Danke Dir, Clara!
(*) Name aus nachvollziehbaren Gründen geändert
…I am not a Technician-at-your-Disposal, even though I am perhaps sharing quite a lot of information, perhaps may have quite a lot of knowledge in regards to things you are interested in and we perhaps met at some time in the past, had a conversation or two or even battled with each other in a ballroom competition.
So, whenever you ask me something in some social network, there is no world in which you would have the right to expect an answer from me within minutes or even days. I WILL answer your question, but at a point of time, when it fits into my life as well.
Additionally, although it might look differently, I am not following social networks very closely. I am looking into them not more often than every second day, I have no FB-messenger or similar software installed, I actually refuse to use the default applications for such networks and I have turned off any notifications from those networks (Twitter, Facebook, etc.).
Therefore, kindly hesitate to stress me in your social network of choice not even 48 hours after your inquiry. It won’t improve my reaction time, it won’t give you a better answer, but it will guarantee you my frustration and a harsh response. So, do me a favor, Clara: Ask me, but ask me in time. Expect an answer and perhaps remind me of that answer (you deserve it), but don’t bug me or lay your stress and frustration on me, since I will answer you in exactly the same way then.
Thank you, Clara!
(*) Name changed for some obvious reason
This is, what you have to take care of when trying to establish a DevOps-culture: Many, if not most, people being affected by a DevOps-approach, will agree with it. At least as long as it does not force them to change anything and as long as they can sell it to their customers or supervisors since DevOps is very popular these days and is to be implemented by them, not by themselves.
Just last week, we had such a situation: We are in a short-term project with an enterprise customer. We have been hired by the vendor doing operations for that customer in a somewhat-CloudNative-environment (they run OpenShift on BareMetal-machines).
The end-customer sees a lot of – let’s call it that way – potential in the collaboration with the ops-vendor. Or to put it in clear words: There is no transparency, no knowledge-sharing, no automation, no versioning and no proper mindset in place at the ops-vendors teams. As a result, a lot of the infrastructure is somewhat running, but not even close to the standards, the end-customers expects. Rightfully expects, in my opinion.
This was the situation when Cloudibility experts were hired to analyze and fix errors in the environment, the software, and the collaboration. We proposed an agile DevOps-based interaction- and operations-model to our customer (the ops-vendor) and discussed chances for such a model with the end-customer as well. Both parties appeared to be very in close in their expressed opinions – yes, they all want to switch to a DevOps-approach.
One week later…
One week later, one of the two companies still sticks to that opinion, the other one does not.
The ops-vendor changed his mind since we perhaps were too successful and identified as well as fixed a lot of improvement-opportunities. He simply does not see the need to change his processes (which lead to the situation we came in) and his way of executing anymore, since the fixes are actually working and the customer appears to be satisfied.
DevOps now is to be executed by his customer, he will be participating in this „a little bit“ (quote), but only „as long as it fits into our processes and does not imply ourselves to change our approach“ (another quote). Plus: „We want to keep our internal approaches a secret, the customer does not need to know about them or can even expect us to adjust to his way of interacting – he is the customer, we are <Company-Name ommitted>“ (quote). And: „Don’t forget, we are not even required to have a logging and a monitoring in place, by the terms of the contract that customer signed“ (quote).
What could possibly go wrong with such a mindset?
Frankly, we expected this behavior from this customer, but it is frustrating nonetheless since they offer a CloudNative and Enterprise-ready environment and operations-model to their customers – and simply can not deliver due to having the wrong mindset and approaches, which gets only visible once a customer signed the contract (we have seen this several times with this customer). They execute IT the old-fashioned ways, having SDM (Service Delivery Managers), steep hierarchies and ITIL-processes in place, instead of DevOps-managers, experts, and an agile operations approach.
So, be careful when someone tells you about executing DevOps. Chances are, all they want is to get their backs covered and they will refuse DevOps as soon as it would imply to change something in their own processes and approaches.
Are we stopping to help such customers and to propose modern, lightweight, cost-efficient and adoptable processes and approaches?
And we will – of course! – successfully end our mission in that specific project as well. But it is kind of sad to see a chance for establishing better approaches and better processes pass by just because one of the involved parties does not want to change anything on their side.
Sad from a mindset’s perspective. From a commercial perspective, it is not: We are happily there to help with the next failing project. Again.
…to open the Android Emulator or open the Android Device Manager at all, don’t try to fix it.
Simply uninstall the Cross-Platform Development Tools (C#) and reinstall them. Takes some 30mins, but will effectively solve the problem.
Took me a day to figure out.
I am delivering a Xamarin workshop this week. Unfortunately for my sleeping habits, the location is Munich, appr. 550km away from home.
The best way to get there is by train, at least if you don’t like flying. So, my train was to depart at 4.30am. Which implied I would have to leave home at latest at 3.50am.
Well. So much for the theory.
In practice, I left home at 3.55am. Which caused me to directly head on the Autobahn towards Munich. Instead of having a somewhat relaxed trip to the Bavarian capital, I had an unrelaxing one in my car. And instead of elegantly driving with an ICE-train from Munich to Frankfurt and then back home on Friday, I’ll drive back home on Thursday and try to catch the morning train from Berlin to Frankfurt on Friday, since I don’t want do sit in my car for 10+ hours.
This makes five minutes quite important.
And that’s why I try to keep an eye on the details, though I’m the high-level guy at Cloudibility.
I really have no idea why this situation might be called „nerdy“. 😂
I love my cats, I really do. But if you don’t force them out if the bedroom before going to sleep, you’re most likely not to find much sleep.
Cats are night-active animals, and they will show you their love, even is you just want to sleep.
I love the both of them!