Leon Adato
Developer Relations Advocate, Itinerant I.T. tale-spinner
Cleveland, Ohio, United States
Actions
Leon Adato is a Developer Relations Advocate and has held multiple industry certifications over his 33 years in IT including Cisco, Microsoft, A+, and more. His experience spans financial, healthcare, food and beverage, and other industries.
Leon has been speaking, blogging, and creating content in the monitoring and observability space for almost a decade. His expertise in IT began in 1989 and has led him through roles in classroom training, desktop support, server support, network engineering and systems automation before landing in monitoring and observability over 25 years ago.
Area of Expertise
Topics
What Stan Lee taught me about working in tech
When learning a new so-called "hard" skill - whether it's coding, hardware, networking, or something even more esoteric - guidance is often plentiful and straightforward. There are docs, forums, videos, bootcamps, and more.
But when it comes to building our career in tech - including the way we navigate day to day interactions and challenges - things are rarely so simple. We're left struggling to find a how-to on surviving a rough day; a guide to become a good team member; or a primer on overcoming impostor syndrome?
But it turns out those lessons appear in lots of places, if you know where to look. Including comic books.
Whether they're leaping from the pages in a single bound or soaring off the screen like a bird or a plane, superhero stories have always contained deeper themes and more nuanced insights than one might expect given their spandex-and-cape-clad trappings.
If we take the time to really listen, we discover relevant and compelling examples of how to handle all types of real-world challenges, including the ones we face in tech.
In this talk, I'll unmask tech problems masquerading as two-dimensional comic book villains; unlock the x-ray vision to analyze their true nature; and unleash the inner strength needed to defeat them.
The Four Questions (Every Monitoring Engineer gets asked)
For most of us, "monitoring and observability" falls into two buckets - the stuff that watches our stuff; and the stuff that watches other people's stuff. Whether your work focuses on the former or the latter, it's only a matter of time when you fall into the trap of playing a game of "what just happened?" whack-a-mole. You'd think the answer would be clear (you DO have a monitoring solution for that exact reason, after all!) but often tech practitioners are left with more questions than answers.
Having working with monitoring systems for over 20 years, I've realized there are just a handful of those questions and that, once answered, the monitoring solution improves and actual problems are solve faster as a result.
I call them "The Four Questions,” modeled after the four questions traditionally asked by the youngest person at the table during Passover. But it turns out there are other connections, lessons, and insights that the Passover meal, or Seder, has to offer both DevOps generally, and monitoring/observability specifically.
In this talk, we'll explore the four questions and their answers, and learn how to structure your solutions to answer the questions appropriately. Along the way, we'll consider bits of knowledge gleaned from Torah, Passover, and the wisdom of the sages.
Technical Empathy
From software to sneakers to sofas, the best designs are executed from the point of view of the user, maintainer, or owner - NOT from the point of view of the designers themselves. The terms "usuability", "intuitive", and even "innovation" are (or should be) inextricably linked with the perspective of the recipient, not the creator.
As IT practitioners, we solve for this by taking time up-front to nail down the desired feature; by creating small incremental changes rather than sweeping monolithic updates; by collecting metrics on usage and flow; and by maintaining a "fail fast" mentality where we can pivot quickly. But all that might miss a key point: do we understand how the intended beneficiary of brilliance thinks? Do we know not only what they want, but why they want it? Or how they want it?
The ability to see things from this perspective is called "technical empathy". In this talk, I'll define what technical empathy is; describe how having technical empathy enhances our design choices, smooths the road to execution, and leads to better outcomes; and provide ideas on how developers and engineers can build technical empathy in themselves and foster it within teams.
Looking back at a lifetime of poor tech choices
or: "When you stare into the face of failure and success smiles back."
Working in tech is a never-ending stream of choices: from the language, platform, and framework we use to the vendors we put our trust (and money) in. Many of us live in fear that our next choice will turn sour, and will end up being a resume-generating event for us.
In reality, there is often a lot more good than you'd expect from those seemingly bad tech choices. In this session, I'll look back on several failed implementations, poor calls, and wasted weekends to see, with the benefit of hindsight, how they turned out to be decent decisions after all.
Getting Away from it All - Living an Unplugged Life as an IT Pro
Most IT professionals spend some of their weekend on work stuff. Check email, work on a design, do some research, or on a "fun" project.
After 25 yrs in IT I finally realized that rarely does this help me get ahead. Mostly it makes me feel crushed, rushed, and stretched to the limit.
Not too long ago I started disconnecting for one day every week - totally unplugging. Not just me, but my whole family. Unsurprisingly, doing this did not drive us to the brink of madness.
This is my story, and the lessons I've learned.
Alerts Don't Suck. YOUR Alerts Suck.
The SRE handbook defines alerts as "A notification intended to be read by a human and that is pushed to a system such as a bug or ticket queue, an email alias, or a pager. Respectively, these alerts are classified as tickets, email alerts, and pages." and I just want to scream. Not because the definition is wrong, but because it's not enough.
First off, if you go from that definition, many devs think (and rightly so) "Why bother?". Who wants an unscheduled interruption when there's no intrinsic value. Because, you might notice, the value of the alert is completely missing.
Second, and conversely, many practitioner see alerting is seen as the entire reason for monitoring and observability. If you can’t get an alert when something is going wrong, why bother monitoring at all?
But those of us who revel in the I.T. sub-discipline of monitoring and observability know that alerts are only one piece of the puzzle. Drawing on decades of experience designing, building, implementing, and supporting solutions from a range of vendors in a variety of settings, I'll expose the places where alerting often goes wrong, how to avoid common pitfalls, and how to dig yourself out if you're already neck-deep.
"Network Observability" Overlooked, Underappreciated, more important than ever
Remember the network? Long before "infrastructure as code", container orchestration, cluster management, or death by 1,000 clicks in some labyrinthine cloud configuration console, the network was an essential layer (or 3) of IT operations.
This may cause some to call for their fainting couch, but I never the less must inform you that the network never went away, became irrelevant, or was simplified to the point where it didn't matter.
The network - good old route and switch, packets and bits (and more importantly flow) networking - is alive and kicking and more important than ever to those of us who care about the performance and availability of our applications.
More to the point, not only is the network the metaphorical plumbing through which all your precious non-metaphorical observability and monitoring data flows; it holds secrets you'll never find in the traces, events, metrics, and logs of typical application observability solutions.
In this talk I'll reveal the observability secrets hiding in plain sight within your network; suggest ways to access that information; and highlight the insights and value you're missing if that data remains invisible, unused, or ignored.
Please note that Sessionize is not responsible for the accuracy or validity of the data provided by speakers. If you suspect this profile to be fake or spam, please let us know.
Jump to top