Collection of keywords, looks like DevOps roadmap.

Operating systems

Ubuntu LTS or Debian are good for most tasks. I’ve also used to operate CentOS hosts.

Alpine is a great choice for containers.

I try to keep away from any Windows-related activities and in general don’t use it for years.

On my laptop I use Elementary OS which is really good compromise between control and elegance.


I use Python. With pep8 enabled and strong will to write clean code.

Made some integrations projects. Simple in-house things like Alertmanager-to-Jira bridge or general Messenger-to-API bots.

Also developed some internal APIs. For example, I wrote staff directory with existing Google Calc table used as data source. This was quite basic, but allowed us to use some automations until migration to full-sized solution.

I’m also fine with writing utils and daemons. For example, wrote multi-threaded metrics aggregator.


It’s a really bad idea nowadays to build infrastructure where you need to use SSH to solve daily non-disaster tasks. My advice is to use containers and schedulers, deploy everything with templated CI configs, gather metrics and setup alerts. This allows me to think of big picture instead of drowning in endless manual tasks.

I’m good with Docker. Not quite familiar with all those virtualization stuff like VMware, KVM and so on, but sometimes I use VirtualBox or even Kata containers.


Cloud providers like AWS, GCE or Azure are really powerful. We also have DigitalOcean or Linode for relatively simple stuff.

I mostly familiar with Amazon and dozen of it’s abbreviations: from EC2 and S3 to CloudFront, Kinesis and ECS.

Of course, there’s Terraform to take most out of our infrastructure: collaborate, run linters, tests, generate documentation and temporary environments from templated one.

Deploy and Configuration management

I’d say Ansible won the race. It’s simple enough yet flexible to let us automate almost anything.

My secondary weapon is Fabric which is fine for low-scale jobs, e.g. rapid deployment of supportive project.

Salt or Chef are still great tools cause of their pull-oriented model, but a little bit more risky, as it seems to me. Like, whoops, I just commited something bad and there’s no direct control option to cancel deployment.

CI/CD (both delivery and deployment)

Probably, GitLab is the most suitable thing for in-house use. Circle, Travis and GitHub Actions are cool as cloud alternatives.

I don’t like Jenkins cause of Groovy, but in time of needs I managed to write declarative pipeline, yes sir.

Teamcity is just too heavy for most cases, but I was fairly OK to support it couple of years ago.

My personal favourites are Drone and Concourse cause of container-oriented and lightweighted nature. Sadly, both are made for engineers and almost useless if you ever need to provide non-techincal owner with some portion of control.


Kubernetes is really cloud-native, very confident solution with no doubt.

Nomad is fine as general-purpose orchestration for dedicated hosts, too.

For simple cases, Docker Swarm or even Portainer could be enough.


I like Prometheus stack, so Alertmanager is cool when you understand how all those pull-oriented metrics collection works. On other hand, Kapacitor from TICK stack is fairly good for push-based collection.

Once I even used Munin. It was years ago, when I decided to implement basic soultion to get enough time to tune up more advanced system (TICK). Speaking of legacy monitoring systems, I never was in role of Zabbix administrator, but used it as on-call engineer for some time.

I’ve managed simple ELK installations, wrote both Logstash configs and grok patterns.


I did few production MongoDB cluster setups with shards replication.

Managed Redis as cache storage, here I operated cluster setups and replicas too.

Of course, I also managed to operate MySQL, PostgreSQL and even a little bit of replicated SQLite cluster. Yes, latest state is just a joke. Just to ensure you’re still reading.

Couple of times I wrote downsampling continous queries for InfluxDB and tons of queries to obtain data from Prometheus TSDB. Both of those TSDBs are powerful, and in general: metrics are cool. I always expose number of those when I write software.