In September 1939, World War II began, causing a minimum of 60mio casualties. Just six years before that, in January 1933, the last free elections were held in Germany – allowing the Nazis to take over and to start their match towards total war.
When there is one thing to take away from that, it is to do the right thing: Go, and cast your vote at the European Elections this Sunday.
There is no sense in remaining at home or in trying to utilize the internet for any kind of outrage or hoping something will change without standing up for it: That will not change anything, because that does not matter in the end, that’s just noise.
Just go and vote, since the moment of truth is at the elections and if you want to convince people of your opinion, reach out to them and talk to them. One by one.
Sitting in Barcelona, Spain. Wearing my Indian shirt. Drinking my US-branded coffee. Paying with my UK-based credit card. Loving my German glasses. Shot this picture with my Chinese-manufactured iPhone XS Max.
Cloudibility is about mindset and culture, about respect and values. We will ensure it stays that way, we will focus on these aspects and will emphasize them even more, even if it might imply some pains. Because, it is worth it. We are worth it.
The long text:
At Cloudibility, we strive to be special. We try to live a different kind of mentality compared to more traditional corporations. We try to work in cross-functional, self-organized teams and with an “If it’s not there, then let’s build it”-attitude. Approaches like “we always did it that way” or “I am the boss and tell you what to do” are not part of our mindset.
But, what is our mindset instead?
Well, our mindset is the mindset of a Startup. We’re active minds. We want to create, shape and solve, instead of griping and moaning. We understand not everything might be in place or working out to our satisfaction – but we don’t see this as an issue, instead we try to set up and create the missing parts on our own, we try to iterate and deliver.
We value the freedom of every individual to learn, to understand and to improve – but we understand this freedom not as something which ends in itself, but something which can only be lived when we also work hard to ensure our stability as a company.
We love our customers, since they allow us to earn our well-deserved money – but we don’t fear them or simply do what they want us to do, instead we’re striving to support them the best we can and with the best outcome possible for them. Supporting our customers is way more than simply accepting tasks – it is about understanding our customer’s needs, seeing issues and solving them, even proactively and perhaps even without ever getting honored for doing so. It is not about sitting in meetings and simply being present, it is about ownership, acting and delivering results.
We love our colleagues and we love working with them, not against them. We’re not trying to “lead” them by expressing negative narratives or by imposing any kind of male dominance, instead we try find solutions and try to convince our fellow team members with arguments. Collaboration, not dominance, is the key for us – even if the better argument might not be our own argument.
It is also about the way we express ourselves – not aggressively or loud, instead being open and respectful to and with each other.
There are many more things that make up for the Cloudibility mentality, have a look at our Leadership Principles and understand them the way they are meant: As principles, to be weighted and prioritized against each other ever and ever again, in each and every situation we are confronted with – not every principle will be applicable to every situation, but it should give you something to think about and to act upon. And try to understand their implications when being lived.
And realize: We insist of living them.
What does this imply?
Cloudibility is very much about mindset, reflection and culture. It is about the way we want to interact, about the way we want to execute our daily business and about the way we want to see ourselves. Since we are growing, it becomes very important to stick to our convictions, to act instead of trying to react, to save ourselves from becoming a more traditional, hierarchically organized and executing company. Because, that’s not what we are and that’s not what we want to be in the future.
We believe in a more modern, agile and active approach to things. We believe in the power of teams instead of embracing those egoistic problem-solvers to be found quite often. We believe in a more substantial, more social, more ecological and more human approach of work and interacting, without being weak or exploitable or allowing others to weaken or exploit us.
And we will grow even more in the next months to come.
And that’s why we emphasize on culture and mindset. That’s why we feel like living and understanding our Leadership Priniciples is that substantial. And that’s why we favour mindset and culture over technical skills and existing expertise.
We are Cloudibility, and we will continue to be it!
(This is the German version of my Dear Clara (*), …-article I posted some minutes ago)
Ich bin nicht der Techniker-zu-Deiner-Verfügung
…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.
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.
…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.
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.
Yeah, we want to do DevOps. We understand this is a critical thing, it is important for succeeding in our Dev- and Ops-projects. We can’t do without.
…we need to get the whole picture first. We need to have a fully featured DevOps-concept. We need some infrastructure. We need top clarify with our Stakeholders.
You know what?
These are only excuses for not doing DevOps.
The best approach to DevOps is by simply starting it. Forget about that fully featured DevOps-concept to be discussed throughout all hierarchy levels of your organization. Forget about providing the perfect infrastructure. Forget about everything – just start it!
DevOps is a process and a mindset. It is an approach to collaboration, to transparency and to knowledge sharing. Yes, it always can be done better, more aligned, deeper integrated, etc.
But nonetheless: The best way to start doing DevOps is to simply start doing it.
I will never ever set up and maintain my environment by hand again!
I will never ever set up and maintain my environment by hand again!
I will never ever set up and maintain my environment by hand again!
If you ignore this advice, you might be ending like a lot of projects I’ve seen in the last years: Unmanageable, unstable, unpredictable and basically unreliable.
Use a tool
If you ever happen to set up a something in your environment, learn about tools like Ansible and perhaps Terraform first. Provision your machines and VMs with these tools, roll out your environment using these tools and version the scripts in a repository.
Do not, ever, later on, do changes or install updates on your environment by hand! Again, use Ansible or a similar tool, to roll out and install updates and components.
The key to automatization is using tools like GIT extensively. Every single configuration file, every single automatization script needs to be put under version control. Every iteration, every change, needs to be versioned as well. Get rid of your local script repositories, keep things in a central, safe place. Share the scripts and configurations, and don’t only document them in your ticketing tool!
Do not use SSH
Of course, SSH is used when working with Ansible or other automatization tools. But you, or any of your team members, should not use it. Using SSH to do tasks on a machine is by definition a manual process, something which has to be avoided! So, forget about SSH as a tool for manually managing infrastructures, configurations, and machines. Script your changes, test your changes, roll out your changes or roll them back – all using Ansible (or other similar tools) and version those scripts as well.
Automatization is key, the tool is not
Don’t feel comfortable with Ansible? Not an issue, use Chef or Puppet or any other automatization framework instead! Don’t want to learn about Terraform? Then go the native route using AWS-CLI or Azure-CLI instead. GIT sucks? Use SVN or CVS or Mercurial!
Regardless of the tool: You need to get the right mindset, and you need to get it, before starting any work! It never worked (and never will work) bringing in automatization and tools later on. You simply won’t be able to consolidate all different configurations without any bigger effort. It’s not gonna work!
Be a developer
Yeah, I know. You are not a developer. You are an administrator. You don’t program things. You don’t write nasty code. You are the specialist, the surgeon.
Well, no. You are a fool if you happen to think so.
You need to think like a developer thinks: Laziness over repetition, scripts over manual approaches, versioning over file-share-based storage. A developer – and believe me, I am one these guys – has a very simple approach: Every repetition of any kind of functionality to be implemented, is basically a wast of time.
A developer tries to write specific code only once, he organizes code in libraries for reusability. He refuses to do things a second time if he could reuse existing code or a library.
Adopt this kind of thinking! Express everything in scripts. Version these scripts. Create your own library of scripts and share it with your fellow colleagues!
Stay in control
I get often asked: What and when do I need to automatize? The answer is simple: Everything, anytime. The moment you SSH into a machine and do any kind of change there, you have lost control. Even if you are unsure about a configurational change being the proper solution to an issue, use a script.
Did I say “Even”? Especially then!
Using an automatization framework, you can roll back the change or set up an environment into a well-known state, allowing you to safely perform changes, test the outcomes and understand the consequences. Since you have versioned everything, you can always revert back to the last known version. Since you have everything in a shared, safe place, you can even lose your computer and your notes – and still remain operational.
And, in case it was not clear enough: This holds true for any kind of environment – Bare-Metal, virtualized, cloud, everything in between.
To stay in control, automatize and version. Everything!