DEV Community: aaron aldrich

Ending 2020 with a new start at Red Hat

aaron aldrich — Fri, 18 Dec 2020 22:47:44 +0000

It's December. The last month of the year and a time where we look back at the year past, the ups and downs, missteps and lucky breaks, and look forward to the year to come full of hope at it's raw potential. This past year has been particularly hard for all of us with COVID washing over the United States in late March, locking us all inside and away from family and friends, massive civil unrest in response to police violence and more emboldened, mask-off threats of fascism and wild fires blanketing the west coast driving people from their homes. And on top of that, we've all had our own personal struggles exacerbated by ::Gestures Broadly:: all of it.

// Detect dark theme var iframe = document.getElementById('tweet-1327025398958448640-215'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1327025398958448640&theme=dark" }

Personally, I started this year still working for Elastic as a Developer Advocate, briefly hung out with some friends at Launch Darkly, and ultimately ended up where I am now, starting as a Cloud Adoption Specialist at Red Hat in November. It's been quite a journey with more than a fair share of ups and downs.

On-boarding anywhere in a pandemic is weird. We've got Zoom Calls and Google Meets and all manner of connection technology, but it still feels a bit surreal. As much as I try to wash myself daily in the culture of Red Hat, there's certainly no substitution for those on campus intro weeks where you're thrown right into the thick of it all. Pile on that the fact that I'm making a small shift from a pure community focus to a kind of enterprise targeted role and it's been a whole lot to try to absorb amidst the final two months of what promises to be an unforgetful year in all the wrong ways.

I'm really thrilled to be in this team. Since I dove into hosting DevOpsDays Hartford back in 2017 (which feels like ancient history after this year) my goal was always to help expose the enterprises to the way Things Could Be. Seeing the way my startup friends and colleagues were reducing the toil of ITOps and starting to work alongside their Dev counterparts to really change the way software was written, delivered and operated and living my whole life at that point in central Connecticut around the Optums and Aetnas, I longed to fill that gap. Things could be better, even for the enterprise.
And I was even lucky enough those many years ago to be connected with the wonderful folks at Chef software and Optum to see something truly amazing. Chef came into Hartford to host a sort of "how we devops" session. I got to sit in and be a fly on the wall as I watched a massive enterprise sit and listen to an upstart infra-code company about how they do business. And I got to hear from that enterprise about how they were starting to shift the way they think about tech shifting not just their applications from top-down monstrous monoliths, but their teams were becoming more agile, being able to focus less on day to day toil and more on innovative change.

The end goal of every DevOps project was always been Serverless

So here I am now, getting to work alongside the folks who are building OpenShift. Which, if I'm honest I hadn't thought much about previously, but getting to know the platform, it's exactly the kind of thing I've talked about when discussing why Dev and Ops folk need to start getting on the same page about observability. More and more the shift is to Operations teams maintaining an application delivery platform (either operating the whole thing, or consuming it as a service and shifting to SRE and Release Management style roles, or some combination thereof) and Developers getting to focus on getting quality code into production quickly and being able to own their uptime. Or to put it as I remember Andrew Clay Shafer did at DevOpsDays ATL 2019, "The end goal of every DevOps project has always been Serverless." I find it absolutely thrilling that all of this is on the back of Open Source.

And I mean not just that open source software is being used in the enterprise, that's sure neat, but not new. What's truly exciting to me is seeing that the open source model of collaboration is winning. The core tennants of DevOps (CALMS) are bookended by Culture and Sharing. The style of empathetic collaboration that makes DevOpsDays so welcoming is starting to catch on and prove (through Measurement like the Accellerate State of DevOps Report) that it doesn't just feel good, but it's good for you.

So, it's been a rough 2020. For all of us. But there's some light here. This crisis has served as a wakeup call to businesses that they cannot possibly continue or return to operations as usual. Here's to a new and better normal, a DevOpsy future. See you next year.

A Reflection on Borrowing from Yourself

aaron aldrich — Fri, 24 Apr 2020 22:19:40 +0000

This is a repackaging of a twitter thread I posted starting with this tweet here:

So if you've already read all of that, this isn't going to say anything new, but I thought it might be easier to digest and more long lived and anyway I haven't written a blog post in far too long. It starts much the same way:

Liquid error: internal

Some context, Failover Conf & cognitive load

This week I "attended" the aptly named Failover Conf from Gremlin. "Attended" is in quotes because the conference was virtual given the current context of the COVID-19 global pandemic. (That last part is there for all of you reading this from the future who won't be so IN that context all the time like we are now.) There were a number of good talks here, but one particular moment from one particular talk stuck with me and kept echoing in conversations I was having in various communities around the web. It came from J. Paul Reed's talk on Resillience and in a half throwaway moment.

The context is talking about Cognitive Load and more specifically, how do we deal with being overloaded, what do we do when there is just too much to do or think about given our capacity. Generally observed we do one of four things:

Shed load
Sacrifice thoroughness
Shift work in time
Recruit more resources

The first two options are considered tactical choices, they're ones we can easily make that generally only affect us personally and generally don't require consulting anyone else in the organization before making them. The last two are considered more strategic, they have some organizational impact, missing deadlines or moving people to work on a new task meaning their existing task is left undone.

The commentary was "we're probably all doing some form of [thoroughness tradeoff] right now" due to the consistent cognitive load of COVID-19. The assumption here is, assuming you can't just let things NOT get done, we're probably all being a little less careful in order to meet our deadlines.

Home-self & work-self & self sabotage

While all of the above is true, I think there are some additional choices we're making that I hadn't initially considered. And I think those choices are unhealthy in the long term. They're sort of "afterburner" options. You can't do it all the time or you run out of fuel, but you could do it once in a while to boost performance as needed in the short term.

Generally speaking, I think the 4 choices above, and their consideration for Tactical or Strategic choices, make an assumption that work gets done in the work context, a finite framing that affects only the people at that place and in that context. But, with all this social distancing and a dramatic increase in working from home, we've suddenly slammed our work lives into our home lives giving additional tactical choices.

Instead of dropping work tasks, I can choose to drop home tasks. I could, say, just not shower this morning and get a little extra time. Or I can now shift work in time on my own schedule, by getting a task done well beyond my normal "end of day". I can work 12 hours today instead of the normal 8 (or even maybe right now we should be doing more like 6 or 7 given the circumstances), or I eat lunch at my computer, maybe I can get that job done on time.

We're calling in extra resources, but from our selves. We're asking our home-self to do additional work, but not necessarily considering the tasks that home-self was already doing that are now not getting completed because we're asking for them to help us get work done with our work-self. I can work 16 hour days to get as much done as I used to, but I'm definitely going to be miserable and fall apart within a week or two.

Adjusting to make healthy choices

Given this consideration, what can we do? I think that's going to depend greatly on what roles you play in your work-org.

Individual Contributors

Ask for the time off that you need and work with your manager to reset expectations on how much you can get done in a given day. It is OK to feel unproductive. Your new success metric is what I have heard of and like to call a "Non-Zero Day". Just get one thing done and you've had a successful day. I've often found that when I compress my ever-growing, overwhelming set of expectations into just one task, I can get started easier. And once I get that done, I might surprise myself and find that I have a lot more time left and maybe I can actually do 2 things today.

But you know what? It's OK to have a day where you cannot get work done. It's OK to have an All-Home-Self day. That Home-Self is doing important work for you, too, and sometimes they need to borrow your work time so they can get Just One Thing done.

Managers

Hear your employees and do some self reflection, too. We are all being overburdened just with the news. And then we still have to sign into the Work Slack and meet deadlines for deliverables. People will throw themselves unhealthily into work to try and feel like they're just as productive as they've always been, to try to feel a like they're normal again. Make it explicitly clear: This. Is. Not. Normal.

Let your reports hear you say, "It is OK not to be OK. It is OK to have a day where you Just. Can't.

Reset deadlines and expectations and assume by default that any given person can only give you about 50% of their normal capacity at best and go from there. Make sure you look out for and prevent people from burying themselves with work.

Employers & Leadership

Be abundantly clear about your mental health care packages and encourage their use for all employees. Remember, you don't have to wait until you're falling apart to see a therapist, a lot of the time it is excellent and necessary preventative maintenace. As Leadership teams, honestly, maybe even talk about going to therapy yourself or how you just had to talk to someone the other day to deal with it all. Set the example with your own vulnerability.

If your organization doesn't already provide some sort of extra mental health coverage, cinsider offering to pay for employees to use one of the easy-to-sign-up, realatively-in-expensive online options like BetterHelp or TalkSpace or see if your healthcare provider covers something like this. Please know that even if your health insurance covers mental health services, it is incredibly difficult to find an in-network service that is available and taking appointments right now, offering quick and alternative options is a huge benefit to your employees.

Many of you at least have some sort of Employee Assistance Program that can offer some amount of these services or help direct your employees to those services. Have a Workshop/Lunch & Learn/Whatever on how to make use of it. Really, step-by-step, too. Where do I go to get help? What group numbers or account numbers am I going to have to know? What exactly is offered and if its limited, can they help me find additional assistance? Record that meeting and pin it and all the information in text format, too, in your standard announcement portal or in Slack. Make it font and center and easy to find.

Resist the urge to make mandatory fun meetings. It's OK to have optional video chat happy hours where people get to talk over Zoom or Skype or whatever just for fun, but resist the urge to try and cheer everyone up all the time. Things are hard, and sometimes we need to be sad and angry and scared. Sometimes we even need to be sad and angry and scared together and that's OK. Remember Inside Out? It can't all be about Joy.

The role of Home-Self

All of this is to say, be careful about how you or your reports or your employees or all of the above are borrowing resources from hour Home-Self. Even though they feel a lot like your Work-Self right now, they have a distinct and different job to accomplish.

Home-Self is helping you cope with a global pandemic. Home-self is helping you deal with the fear for your health, your loved ones, the loneliness you have of only being able to view your friends and family through glass and from six feet away. Home-Self is helping you deal with the anger you feel at your normal being taken away. Home-Self is trying to learn all-new coping mechanisms because the old ones just aren't working any more. Home-Self is helping you get through this, maybe battered and bruised and in recovery, but mostly in one piece. Do not sacrifice that resource.

If you absolutely must borrow some time from Home-Self for Right Now to reach a looming deadline, something that affects more than just you, it's OK to do that, but it's like the afterburner. You have to turn it off again. And make sure you t ake the time back later to refuel.

I'm probably going to be working late tonight or this weekend to get some tasks done that I need to have completed by Monday, but I'm probably also going to ask for an extra day or two off to make up for it. I can't sustain it otherwise.

I love you.

Be safe out there.

We're all in this together.

Launched: Elastic (ELK) Stack Integration

aaron aldrich — Mon, 20 Apr 2020 18:30:53 +0000

I’m happy to announce we’ve launched an integration for the Elastic Stack! Coming from Elastic myself, I was thrilled to draw upon my experience and help build something useful right out of the gates.

Looking at all the existing integrations for LaunchDarkly, I could see the obvious themes of Observability. Of course, if your distributed systems start getting wonky and acting all out of sorts, you want to know why. Probably 80-90 percent of the time, it’s because someone made a change. Wouldn’t it be great to see that annotated on top of your error rates right before that huge spike occurs?

With our Elastic Stack integration, you can navigate to the LaunchDarkly dashboard, find the annotated flag, and turn it off. Systems move back towards stability in less than 200ms. Customers are happy again, and your boss is thrilled.

If you’re using Elastic for observability, go ahead right now and enable that integration on our integrations page. Check out our documentation for how to get started quickly.

That’s really just the beginning of this story.

Elastic provides a tremendously flexible search platform that can perform analytics on any arbitrary data you send it. You could make use of Elastic’s Watcher feature to create robust circuit breakers, measure the impact your increased use of feature flags has on system resilience, or analyze how your decreased downtime and streamlined software launches have improved customer satisfaction and increased revenue.

The Elastic Stack integration can get your feature flag data into Elastic. What you do with it from there is up to you.

Stay tuned as we offer even more insight into some advanced configurations and how you can leverage LaunchDarkly data alongside your existing observability tools, to improve the resilience of your distributed systems and improve the safety of your software deployments.