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!
I said this quite often during several projects over the last years – and often directed to persons being „difficult“ with regards to discussing hard, having different opinions, contradicting a Product Owner or an Architect with thoughtful arguments. This is something you will have to accept, even if it is hard to do so. And it is exhausting, it is stressful working with such people on a day-by-day basis.
But, I changed my mind.
Or, to put it differently, I am now in a position where I want to have such characters around me. Here at Cloudibility, we want persons having their own ideas and their own minds, we want them to contradict us and to proove us to be wrong.
We want to have such minds around us. Of course, they will have to stick to our rules of respect and culture, they will need to be compatible with customers and the team. But besides this: Have your own mind, contradict, improve, overtake us!
Cloudibility is a company focused around knowledge and heads. We are not limited to a specific location – our German employees are located in Berlin, Magdeburg, Brunswick, Frankfurt, Karlsruhe, etc.
Today, we expand that a little bit and welcome our first Indian team members. They are located in Faridabad, next to Delhi, in the offices of our long-lasting partner AppFlow Solutions Pvt.
Public Domain, https://en.wikipedia.org/w/index.php?curid=23473510
Different to other approaches, we don’t treat them as a remote team working for us, but as our team-members working a little bit down the road. They will be participating in our processes, meetings, etc. and will be a core part of our team.
Our Indian team members are „hand-selected“ the very same way as our German stuff – they have to have the same culture, the same approach to cloud-native infrastructure and processes and the same greed for excellence.
Within the next four weeks, our Indian team will be extended to at least three employees, but we are actively looking for even more of them.
So, if you want to be a part of our journey, contact me or Pradeep, the head of our Indian partner!
50mm F/6.3 1/1250s ISO200, Sony Alpha II with Canon FD 50mm F/1.4 vintage lens, filtered using Adobe Lightroom Classic CC
Once upon a time (some 30 years ago), you had to wait up to 18 years for such a car – usually, the East-Germans ordered one after having given birth to a child. The Trabant was the only affordable car in East-Germany and was a super robust vehicle, which still runs today to thousands.
I do often get this question when providing our specialist’s profiles to possible customers.
Well. No. We can’t. And we won’t.
Let me explain that bold statement a little bit. There are plenty of reasons for saying so. The most important one: We have some of the best specialists here at Cloudibility.
We love our experts.
We provide our bright minds with an environment which allows them to shine – a good work-life-balance, paid educational hours, etc. We do this, since we would have liked such an environment ourselves when being employed. But it was not possible due to calculation issues. Which forced us to quit our jobs.
Therefore, we want to pay our experts reasonable salaries and want them to gain even more knowledge. We want them to stay motivated and hunt for solutions instead of billed hours. We are investing a lot into our experts, and we are very happy and proud to do so. We know, that you deserve the best expert and the best approach for your project.
But it’s still expensive, though.
Do you know how much it costs, to do without good experts? Or to simply opt for the cheaper alternative since it is … cheaper? Can you really afford the second best or a somehow okayish solution? Just for the sake of saving some bucks forehand?
Our experts are worth their money.
They are experts and bright minds, they are able to solve problems, they are able to think outside the box. They save you time and money and nerves, they bring knowledge and experience into your projects.
So, no. We won’t do special prices.
We already have the best prices in the market since we have the best experts and the brightest minds here at Cloudibility.
Situation: I wanted to buy a Surface Book 2, since I was able to find a buyer for my Surface Book with Performance Base and I was offered a really good price for the SB2. So, I went and ordered the replacement unit. I was terribly tired and did not check the order receipt.
Next day, I went to the shop to collect my shiny new Surface Book 2.
But I was confronted with a larger box than expected and it read „Surface Book 15-inch, 256 GB storage“.
I immediately checked the receipt and figured: Yes, I actually ordered the 15-inch variant. I did not notice since the 15-inch and the 13.5-inch variants differed not by price but by SSD-size (and I did not check this one). They were presented side-by-side online, and obviously, I was too tired to realize.
So, I had two options: Don’t accept the device or go with the bigger one having the smaller SSD. Very surprisingly(?), I went with the latter option and now I own a Surface Book 15-inch.
I don’t own it. I love it.
It immediately replaced my 2017 MacBook Pro 15.4-inch, which is on sale right now. And it replaced the 13.5-inch Surface Book with Performance Base, since the differences in size and weight are acceptable. It is – for now – accompanied by the 12.5-inch ThinkPad X260 and – for another two months – by an Apple iPad Pro 10.5 (which will be replaced by a Surface Go later this year).
If you wonder, why I love this device so much, here are some reasons:
Gorgeous keyboard. I mean, really gorgeous. On the older-MacBooks- and older-ThinkPads-Level. That gorgeous.
Fantastic display. 15 inch, 3×2-ratio. Nice colors. Nice viewing angles. Touch. Close enough to a MacBooks-display.
Battery time. 5 hrs of watching videos – around 50% of battery left. Several hours of writing and surfing, again with a modest battery drain. Compare this to a MacBook Pro 15.4 inch, whose battery is empty after 4 hours, regardless of what you do.
USB-A-ports. Not only USB-C/Thunderbold-ports.
Lightweight device, less than 2kg for a 15-inch device.
Versatility: You can use it as Laptop, as Tablet, as anything in between.
The Pen. Just nice.
That Graphics Adapter. 6 GB RAM, GeForce GTX 1060. Play highly demanding games in natural resolution!
Because you shut down your VMs at night. Automatically.
Because you have a Jenkins-installation.
Because you are moving to a cloud environment.
Because you have set up a „DevOps“-team.
Because you have a lot of meetings with stakeholders.
Because you want a Development team to run a software since the approach is often described as „You build it, you run it“.
Because you know about this nifty image on top.
Turns out: No.
You don’t do DevOps.
You just shut down your VMs at night, you just happen to have a Jenkins-installation, you’re just moving to a cloud environment, etc.
But this is not DevOps. At least not in the sense we at Cloudibility understand it and explain it to our customers and set it up with them. To us, DevOps is not about any specific technology or setting up a team.
DevOps is a mindset.
It is an approach to thinking about, developing and running software collaboratively. It is about the way you interact from the start to the end of a project with each other. It involves getting rid of this „throwing over the fence“ mentality. It involves a process for collecting and maintaining knowledge in an ever-changing team and agile approaches to development and operations. It is about the way a team is set up and how it evolves, it is about the way we set up and execute operational processes. DevOps even is a way to organize collaboration in a whole company.
So, DevOps is way more than putting Dev and Ops on the same table. Or than moving into cloud environments. Or than being agile. Way more.
In the following months and weeks, I will give you insights into our approach to DevOps. I will give you some tips and hints. I will help you to see the whole picture. I will do this on a per-issue and per-aspect base, and it will be a loose series of articles.
At Cloudibility, we are currently growing enormously – by mindset, by knowledge, and by headcount.
Last week, our team was expanded by three bright minds (in no particular order:
Sandra Sandra was a Developer once (and a very good one!) and decided to opt for DevOps. She has very strong development skills and is able to transfer this into DevOps-territory. She likes working with CI/CD-components, ELK / EFK and Kubernetes. And from time to time she will be giving presentations and trainings and speeches. She joined our team as Senior DevOps Engineer.
Ronny has a profound knowledge in DevOps-technologies as well as Kubernetes. He is doing deep dives with technologies such as Linux, Docker, Ansible, Teraform, Vagrant, Virtualization (VMware, etc.) and many more. He has joined our team as Senior DevOps Engineer.
Emilie is part of our sales team. She as an impressive track record of sales even in difficult environments, can handle customers and partners and is a very positive person. She has joined our team as Sales Manager.