A deeper look at Cargo – the package manager and build automation tool for Rust

Read more

This simple rule will make your engineering team up to 30% percent happier.

Read more

I’m happy to announce that I’ll be speaking about service meshes and demoing Istio usage for smart deployment techniques at https://devoops.ru/ in St.Petersburg, Russia – the city I was born and grew up in! The conference will take place on 14.10.2018 and will feature such great speakers as John Willis and Liz Rice among others. And here’s the link to the talk.

by Mikes Photos from Pexels

Blockchain has become the enfant terrible of the tech world. As any conceptually new tech it poses more questions than it provides answers. But the buzz around it is more than justified. Beside the crypto-gold rush that’s definitely been the main hype-driver, this is a technology that provides a promise of a different, decentralized future. A promise of distributed, global trust based on science and technology — not on military force, geographical proximity or national identity. It remains to be proven if such trust is possible, but if it is — world economy is up for a total paradigm shift.

Read more

Icon made by Freepik from www.flaticon.com is licensed by CC 3.0 BY   Today I want to talk about what is probably the most misunderstood concept in DevOps terminology : the feedback loops. As defined originally in “The Phoenix Project” and further detailed in “The DevOps Handbook” – amplifying feedback loops is “the second way of DevOps”. Gene Kim explains in this post that “The Second Way is about creating the right to left feedback loops. The goal of almost any process improvement initiative is to shorten and amplify feedback loops so necessary corrections can be continually made.” Process improvement is exactly what I’ve been doing for the last decade of my career. And what I’ve noticed is that whenever I start talking to teams about feedback loops I get 4 types of misunderstanding: Alert and notification systems are mistaken for feedback loops The importance of feedback loops is completely…

Read more

We Don’t Do DevOps. In most of my encounters with new customers I take the time to explain that I don’t “do DevOps”. Yes, DevOps a convenient name tag. It provides an easy to present packaging that has been feeding me and my colleagues well for the last 5+ years. On the other hand – it definitely looks like the original meaning of the word (as originally coined by Patrick Debois) is continuously eroding. More and more folks in the industry are using it to refer to modern practices of system administration. Those that involve cloud, automation and – in the best case – also continuous delivery. That’s why I almost never relate to what I’m doing as ‘DevOps’. I rather use the term “Software Delivery Optimization”. We’re optimizing the time it takes to deliver software and the quality of the resulting product. By applying systemic analysis. By measuring and…

Read more

A few customers have been asking us for a simple, visual, down-to-earth plan for their DevOps Transformation process. We’ve created this infographic. Feel free to share and comment!

Introduction We live in a world where a commercial organization has to be in a state of constant flux. That is  – if it wants to survive and prosper. This statement is even more accurate for IT companies. (And  – as the popular saying goes – every company is an IT company today) One could of course argue that I’m suffering from a consultant worldview bias. After all – consultants are mostly brought in to help with organizational and technological changes. In the last couple of years we at Otomato have been involved in dozens of projects that all had ‘migration’ or ‘transformation’ in their title.  So yes, definitely – change is all we see. But I’ve spent more than 15 years in IT companies small and large prior to becoming a consultant – and it’s always been like this. With ever accelerating speed. We’ve been changing languages, frameworks, architectural…

Read more

Introduction: Being able to dynamically spin up slave containers is great. But if we want to support significant build volumes we need more than a few Docker hosts. Defining a separate Docker cloud instance for each new host is definitely not something we want to do – especially as we’d need to redefine the slave templates for each new host. A much nicer solution is combining our Docker hosts into a cluster managed by a so-called container orchestrator (or scheduler) and then define that whole cluster as one cloud instance in Jenkins.This way we can easily expand the cluster by adding new nodes into it without needing to update anything in Jenkins configuration. There are 4 leading container orchestration platforms today and they are: Kubernetes (open-sourced and maintained by Google) Docker Swarm (from Docker Inc. – the company behind Docker) Marathon (a part of the Mesos project) Nomad (from Hashicorp)…

Read more

Last week I had the honour to speak about ChatOps at Continuous Lifecycle conference in London. The conference is organised by The Register and heise Developer and is dedicated to all things DevOps and Continuous Software Delivery. There were 2 days of talks and one day of workshops. Regretfully I couldn’t attend the last day, but I heard some of the workshops were really great. The Venue The venue was great! Situated right in the historical centre of London city, a few steps away from Big Ben, the QEII Center has a breathtaking view and a lot of space. The talks took place in 3 rooms : one large auditorium and 2 — smaller ones. It is quite hard to predict which talks will attract the most audience and it was hit and miss this time around too. Some talks were over-crowded while others felt a bit empty. Between the talks everybody gathered…

Read more

30/78