DevOps Pro Vilnius 2017

Let’s do DevOps because it sounds cool and you are cool if you do it. But how to implement DevOps? Can you implement DevOps? What is DevOps anyway?

DevOps is not an implementation. You cannot just simply give the command “sudo install DevOps”. Moving towards a DevOps organisation is a journey. A journey with a lot of success and even more failures.

This talk will bring you on this journey of successes and failures and provide you insights of real DevOps transitions.

It’s a situation many of us are familiar with: a large legacy, monolithic application, limited or no tests, slow & manual release process, low velocity, no confidence… A lot of refactoring is required, but management keeps pushing for new features.

How to proceed? Using examples and lessons learned from a real-world case, I’ll show you how to replace a legacy application with a modern service-oriented architecture and build a continuous integration and deployment pipeline to deliver value from the first sprint. On the way, we’ll take a look at the process, automated testing, monitoring, master/trunk based development and various tips and best practices.

Many teams don’t yet have a basic build let alone an automated DevOps pipeline. In less than 90 minutes I will take an application from local builds to fully automated release pipeline with automated testing and full traceability of requirement quality.

Although almost everyone understands that they have to add DevOps practices at some point, many still don’t start with them. Yes, you should have Source Control, an automated Build, automated Release, and monitoring in place almost before you start your project. Come and find out how easy it is to ditch Sprint Zero for a Sprint Awesome on day one!

In our job as DevOps consultants, we are frequently asked a question by our clients: “What does DevOps consist of?” Acronym CAMS is not suitable enough to make DevOps sell, because nobody wants to buy “culture” and “knowledge sharing”. So we recommend to our clients the following practices: Infrastructure As a Code, Continuous Delivery, Continuous Monitoring, Test Data Management and Automated Testing. In my presentation, I will talk about what we mean by those practices and also tell some of the cases of our work with the big Russian enterprises.

The very small 2-person DevOps team within Red Hat Performance/Scale Engineering has developed a set of Open Source Python-based systems and network automation provisioning tools designed to end-to-end automate the provisioning of large-scale systems and network switches using tools like Foreman, Ansible, and other Open Source bits.

QUADS – or “quick and dirty scheduler” allows a normally overburdened DevOps warrior to fully automate large swaths of systems and network devices based on a schedule, even set systems provisioning to fire off in the future so they can focus on important things like Netflix and popcorn or not read your emails while your datacenter burns in an inferno of rapid, automated skynet provisioning. QUADS will also auto-generate up-to-date infrastructure documentation, track scheduling, systems assignments and more.

In this talk we’ll show you how we’re using QUADS (backed by Foreman) to empower rapid, meaningful performance and scale testing of Red Hat products and technologies. While QUADS is a new project and under constant development, the design approach to handling large-scale systems provisioning as well as the current codebase is consumable for others interested in improving the efficiency and level of automation within their infrastructure.

Utilizing Docker & Container technologies we can bring following capabilities closer to the app layer:

•  Monitor: How to collect IDS/NetFlow data from both network devices and hosts
• Analyze: How to analyze NetFlow and various other log metrics utilizing ElasticSearch
• Detect: How to detect anomalies and aberrant traffic/activity
•  Respond

These capabilities were previously only available at hardware/switch layer, now we’re seeing SDN (Software Driven Networking) transformation thanks to Dockerization of our platforms.