From DevOpsDays Warsaw 2015 with a fresh bag of insights

4 minutes read

This time, our continuous goal of frequenting the most interesting events for developers brought us to Warsaw. Read what we learned at DevOpsDays Warsaw 2015 about the hottest trends in programming, system administration and network operations.

DevOpsDays Warsaw 2015 took place between November 24-25 at the Gromada Hotel and was the second Polish edition of the popular international event. The DevOps trend that has developers and IT operations specialists work together to produce, deploy and support quality products is well worth our attention. When you add the participation of some excellent and experienced experts to the mix, you can understand why we were so eager to drop by.

Served fast and fresh

The Warsaw edition of DevOpsDays focused on some of the latest topics in the field of programming, system administration and networks such as automation, monitoring and containerization. The organizers took care so that all the fresh-off-the-shelf insight was served in a unique and lightning-fast way. The ignite talks provided an opportunity for everyone to make their point in a five-minute presentation and open spaces had all the participants cast votes for the most interesting topics and discuss them later in small groups. We made sure to see as much as we possibly could. Below you can find some of our takeaways from the lectures we found the most interesting.

To “containerize all things” is a catchphrase that has been recently making quite a stir in the DevOps culture. Docker is a great tool to create containers, that is, to package a piece of software with all of its dependencies in a way that allows it to run the same way in every environment. Once used mostly for test projects, containers are increasingly employed to develop advanced apps on the production side.

The clustering of the container-based infrastructure and container monitoring are some of the challenges that developers face everyday. Docker solves the former with Docker Swarm – a native clustering for Docker that, as it says on the tin, “allows you to create and access a pool of Docker hosts using the full suite of Docker tools.” As for monitoring, it’s a bit more more complicated. A lot of companies come up with their own unique solutions to the problem. SysDig allows for container monitoring in the way same one can monitor any other kernel process, including resource usage and network activity. CSysDig provides a simple UI for SySDig, with the big advantage of using this solution being that there is no need to configure the containers before any monitoring is possible.

DevOpsDays Warsaw 2015: The Dark Art of Container Monitoring – Luca Marturana

Docker and the magic of Elasticsearch clusters by Rafał Kuć

The Elasticsearch (ES) search server is another developer favorite, used in both small and large projects and talked about constantly despite the fact that maintaining ES in the product environment is not anywhere close to simple or convenient. Combined with LogStash and Kibana in the ELK stack, ES presents a lot of new challenges for developers. This includes having to move the services to separate servers (especially in the case of payload-heavy projects), network configuration and machine-to-machine communication adjustment etc. And that still leaves out all the troubles related to scaling ES.

Struggles with ES is another area where one can use the help of Docker. Containers can be easily joined together and tools such as Docker Compose and Docker Swarm provide a simple cluster configuration language. “Persistent storage containers,” also known as volumes, make it easy to separate application layers and share data. Below you can find an example of a log processing configuration received on port 5043 and the process of sending it to ES.

input {
 lumberjack {
 port => 5043
 ssl_certificate => "/etc/ssl/logstash-forwarder.crt"
 ssl_key => "/etc/ssl/logstash-forwarder.key"
filter {
 if [type] == "hipache" {
 grok {
 patterns_dir => "/etc/logstash/patterns/nginx"
 match => { "message" => "%{NGINXACCESS}" }
output {
 elasticsearch {
 host => ""
 cluster => "logstash"
 # Uncomment the line below if you use Kibana 3.1.0
 # embedded => false

DevOpsDays Warsaw 2015: Running High Performance And Fault Tolerant Elasticsearch Clusters On Docker – Rafał Kuć

The nitty gritty of microservices with Zbigniew Rzepka

And yet another hype – microservices. A lot of developers of modern apps have given up on the concept of large monolithic apps in favor of component-based dispersed services. Each of those services is developed by a separate team of developers and is responsible only for a certain set of functions. Together, they all comprise the entire product. The benefit of this approach is that if one service malfunctions, it usually does not cause the whole system to collapse. However, there is no shortage of challenges. One of them is service discovery, which refers to the problem of maintaining proper communication between all the services that make up the system. For example, if you create a functionality that sends requests to a service that provides access to REST API, you have to know the address and port of the particular service instance. As addresses are more or less static in the traditional architecture, it used to be fairly straightforward. But in modern cloud-based infrastructures one can never be sure to find a service under a given address.

The solution to this problem is Armada. It introduces the concept of a ship, that is, a platform you can place a single container on. With Armada Agent, you can create containers, move them to repositories (so called dockyards) and manage the entire cluster. In Armada, all microservices share an image called the “Armada-microservice image.” The image provides access to many tools, including “service discovery.” Microservices are registered in the Consul catalog. You can find them and communicate with them in many ways, including mini-DNS, local proxy and dynamic queries.

DevOpsDays Warsaw 2015: Armada – technical aspects of highly available microservices – Zbigniew Rzepka

Is continuous integration dead?

That’s the question Yegor Bugayenko, co-founder and CTO of, tried to find an answer to in his short presentation. Bugayenko came up with his own solution to common problems related to continuous integration, which includes a read-only master branch and a set of small branches where the actual integration happens. Take a look at Yegor’s talk on Youtube to learn more.

DevOpsDays Warsaw 2015: Continuous Integration is Dead – Yegor Bugayenko

Each DevOpsDays event is an occassion to brush up on the latest IT trends, but it is the addition of DevOps culture that makes it stand out and allows participants to look at their profession from a wider perspective. The Warsaw edition turned out to be a great experience filled with practical knowledge served in an innovative way. We’re already looking forward to another Polish edition of this famous event. In the meantime, why not visit Los Angeles, London or Seattle? You can find the confirmed locations for the year 2016 on the official DevOpsDays website.

The image comes from the DevopsDays Warsaw fanpage and was taken by Anna Nesterewicz

On-demand webinar: Moving Forward From Legacy Systems

We’ll walk you through how to think about an upgrade, refactor, or migration project to your codebase. By the end of this webinar, you’ll have a step-by-step plan to move away from the legacy system.

Watch recording
moving forward from legacy systems - webinar

Latest blog posts

See more

Ready to talk about your project?


Tell us more

Fill out a quick form describing your needs. You can always add details later on and we’ll reply within a day!


Strategic Planning

We go through recommended tools, technologies and frameworks that best fit the challenges you face.


Workshop Kickoff

Once we arrange the formalities, you can meet your Polcode team members and we’ll begin developing your next project.