Baruch Sadogursky

So, you want to update the software for your user, be it the nodes in your K8s cluster, a browser on user’s desktop, an app in user’s smartphone or even a user’s car. What can possibly go wrong?

In this presentation, we’ll analyze real-world software update fails and how multiple DevOps patterns, that fit a variety of scenarios, could have saved the developers. Manually making sure that everything works before sending an update and expecting the user to do acceptance tests before they update is most definitely not on the list of such patterns.

Join us for some awesome and scary continuous update horror stories and some obvious (and some not so obvious) proven ideas for improvement and best practices you can start following tomorrow.

This presentation is a collection of failure stories about software updates with advice on how to prevent those in your systems. As usual with epic failures talks, it’s educational and a lot of fun.

We’ll start by reviewing what are the driving forces behind software updates, how do we update, and why some update multiple times a day while others only update once a year. We’ll continue to review some of the epic fails, including Google WiFi, Knight Capital, CloudFlare, Jaguar and others. The patterns we are going to suggest are Canary Deployments, Observability, Local rollbacks, Feature Flags, and others.

As we have successfully integrated DevOps practices into our software development processes, it’s time to reframe our approach and embrace Developer Productivity Engineering (DPE). DPE focuses on optimizing workflows, automating mundane tasks, and providing real-time feedback to developers, offering a natural progression from the DevOps methodology.

In this engaging and informative talk, we’ll delve into how DPE reframes the foundations laid by DevOps, further enhancing collaboration, tooling, and data-driven insights to improve the overall development process. Discover why mastering DPE is essential for all engineering roles, including Platform and Site Reliability Engineers, as it aligns with core principles such as reducing toil, promoting automation, and implementing observability. Explore how DPE empowers teams to proactively identify and address potential issues, ultimately leading to increased system reliability, improved user experiences, and a more enjoyable and rewarding work environment for engineers.

So, you want more from your build, but want to spend less on migration? Here's a session for you - Migration from Maven2 to Gradle: the easy way.

We'll build a migration todo list, overview existing technological solutions, and see how we can migrate existing builds with minimum effort.
During this session you'll see how to create a basic Gradle script out of a pom.xml file, how to extend it replacing the functionality of Maven plugins with Gradle tasks and plugins and how to keep your Gradle build compatible with other Maven projects/modules it interacts with. You'll learn everything you need to know if you are currently using a Maven build and want to get started on Gralde.

You know about DevOps, you know DevOps is right for your organization, but hey, what can you do? As an individual contributor or a team leader, your authority to transform your organization to DevOps is limited. But your influence is not!
In this talk, Baruch will show how some proven influencing and negotiating techniques can be used to convince critical stakeholders in your organization in the necessity of DevOps.
We look at the arguments, the techniques, and the small tricks, which work in particular situations with particular engineering and business leadership positions and will prepare you to deliver the message of DevOps most convincingly to each.

Hear me out: We solved DevOps. I am not saying that everyone is doing it right (or even trying), but we have the solution if you want to do it right. Here is the theory, the technology, the communities, the docs, and the booksgo knock yourself out. Do DevOps: empower your teams, make deployments a breeze, build invincible CI/CD pipelines, and create production environments that are secure, stable, and observable. Done.

Now, in perfect alignment with DevOps and the Theory of Constraints, its time to turn our gaze to the next bottleneck: the production environments of our production environments. Theyre a mess. We accept soul-sucking toil, slow and unstable tests and builds, and constant distractions as the norm, just as we accepted the insufferable, manual throw garbage between silos all-night deployments of the pre-DevOps era. But, as with DevOps, we shouldnt take these for granted. Its time to rise again and resist our development environments' Pre-DevOps state. Lets engineer better developer productivity for all!