Stuart Ainsworth

#Azure DataFest Sessions I want to see: @sqlgator #Cortana and #PowerBI

There are still plenty of seats left for the inaugural #AtlantaAzureDataFest2018, so I thought I’d try to drum up some interest by posting about a few of the sessions I really want to see.  First up, Ed Watson‘s session: “With Power BI and Cortana, You Can Take Over the World”.

I love the thought of integrating voice control with reporting; have no clue what that means, but it definitely satisfies the whimsical nature of this conference. Let’s build something together just because we can, not necessarily because it satisfies a need.  Ed is a crazy fun presenter to watch (and a good friend).  I’m excited to see him push the envelope a bit.

Join us!  Seats start at $50 for two days of jam-packed training on Aug 16-17th, 2018.  Tell your boss you’re being forward-thinking; they love that.

 

The Definition of Service

As I’ve blogged previously (The S in #SRE), I’m in the process of transitioning my team from database and system administration to a team focused on service reliability. As I’m continuing to evangelize DevOps and Service Reliability Engineering within my business unit, I’ve realized that I need to have a good strong definition of what exactly a service is. I figure if I’m going to work through this, might as well do it in my blog so I can find it later.

A Service:

  1. Is an abstraction of value. Services are containers for delivering value to a customer, either internal or external.
  2. Has a consistent definition. It’s comprised of people, products, and processes, and while the relationship between those elements can change, but the inputs and outputs of a service are relatively consistent.
  3. Requires a backup strategy. Disaster Recovery Plans and Business Impact Analysis are foundational tools for the management of quality associated with a service. While a DRP may contain multiple recovery strategies, a Service should be able to be recovered entirely.
  4. Should be continuously improvable. This means that a service is only fixed at a point-in-time; components should be versioned so that management processes (including recovery) are synchronized with the delivery of value at a given time.

More to come.

#Azure DataFest Atlanta #ADFATL – Call for Speakers Now Open!

As I’ve mentioned on twitter (what, you don’t follow me?), I’ve been involved with a new conference that’s focusing on the Microsoft Data Platform – Azure DataFest. It’s still very much in the works, but there’ have been a few events around the country so far, and we’re bringing one to Atlanta in August (as well as working on a national standardized presence). If you want to help build a community of data professionals that are passionate about the next generation of analytics and data science, please feel free a topic. Text for the CFP is below, but the actual call for speakers is here: https://sessionize.com/atlanta-2018-azure-datafest-microsoft.

More details to come (after I get through Atlanta SQLSaturday).

Atlanta 2018 Azure DataFest: Microsoft Azure Advanced Analytics and Big Data Conference

This is a call for speakers for the inaugural Atlanta Azure DataFest: Microsoft Azure Advance Analytics and Big Data Conference, a 2-day event to be held on August 16-17, 2018, 9:00AM to 5:00PM at the Microsoft Technology Center, 8000 Avalon Boulevard Suite 900, Alpharetta, GA 30009.

We are looking for 10-12 speakers to present on the following Azure Advanced Analytics and Big Data topics:

  • Azure Data Services
  • Azure Data Warehouse
  • Power BI
  • Cosmos DB
  • Azure Analysis Services
  • HDInsight
  • Machine Learning
  • Stream Analytics
  • Cognitive Services
  • Azure Bot Services
  • Data Lake Analytics
  • Data Lake Store
  • Data Factory
  • Power BI Embedded
  • Data Catalog
  • Log Analytics
  • Apache Spark for Azure
  • Dynamics 365 for Customer Insights
  • Custom Speech Service  APIs
  • Spark

Planned Schedule (Thursday, August 16)        

We plan on delivering a keynote, and three sessions to the at-large audience, then breaking into tracks after lunch.

8:00AM – 9:00AM – check-in/breakfast/networking

9:00AM – 9:50AM – Key Note, Room # All/Combined

10:00AM -10:50AM – Session 1  Room # All/Combined

11:00AM -11:50AM – Session 2 Room # All/Combined

12:00PM – 12:50PM – Partner/Sponsor Lunch and Learn – Room # All/Combined

1:15PM – 2:15PM  Breakout sessions

2:30PM – 3:30PM  Breakout sessions

3:45PM – 4:45PM Breakout sessions

Sessions should be 1 hour in duration, level 300 or higher. You can use best practices, case studies, demos, chalk talks, etc.

Planned Schedule (Friday, August 17)
The second day is intended to build on the first day with workshops, allowing attendees to have hands-on experiences with the applications.

8:00AM – 9:00AM – check-in/breakfast/networking

9:00AM – 11:50AM Workshops

12:00PM – 12:50PM – Lunch – Networking

1:00PM – 3:50PM Workshops

Workshop sessions should be 3 hours in length, and relate to material covered in the sessions on day one.  If you would like to submit a workshop session,  please ALSO submit a single-hour session for the first day.

The session submission deadline is Friday, July 13, 2018.  We will announce the speaker list and alternates on Monday, July 16, 2018.     

If you have questions, please contact stuart.ainsworth@azuredatafest.com

#DevOps – Lead by example, but set the right example.

Last weekend, I missed a data center migration.

It was a scheduling conflict; for Christmas last year, my wife had bought me tickets to High Water music festival (which was great, btw), and when they set the dates for the data center migration, I was worried. The tickets were expensive, and we had booked hotels, etc; I couldn’t change plans to work with the schedule, and there were too many teams involved in the migration for them to pick a different date. We’d done this migration once before (6 months ago), and I was confident in my team’s ability, but still… I was worried. You see, missing an after-hours deployment or a maintenance window of this size wasn’t usually considered to be an option before (by me). I’ve always been a firm believer in the management rule of: Don’t Ask Others to Do Something You Won’t Do.

So, every migration, every deployment, every maintenance window… I was there. Weekends, mornings, evenings… I was there. When our first major data center migration blew up a year ago, I was there for 26 hours. I THOUGHT I was sending the message that “I’m here for you… I’m leading the way… I’m being a team player.

That’s not the message I was sending.

What happened while I was away is that others stepped up and filled the void left in my absence. They didn’t do things exactly like I would have done, and they had to take on some additional responsibilities during the migration, so their timing wasn’t as efficient as if I had been there. But the work got done, and we survived without me. I could have looked at that and said “aha; I’m not really necessary; there’s some waste savings there!”. Instead, I realized that what I thought was a four-person job was really a three person job, and that meant that the fourth person could do what was more important than work; life.

You see, the message that I was sending by being at every activity outside of work was that I Expect Y’All to Give Up Your Free Time for Your Job, Just Like I Do. I didn’t mean it that way, but my employees picked up on it. I was there; they were there. Every time. And that’s no way to work.

What I realized this weekend is that Leading By Example also means Resting By Example. If the job really is a three person job, then four people don’t need to show up to do it (or else work will expand to make it a four person job; a variant of Parkinson’s law). And while I should still be willing to do the job, I need to be willing to do it when it’s my turn. I’m now scheduling rotations (I’m in one of those rotations as an engineer), and letting my team understand that it’s not just OK to not be at every maintenance window activity; it’s expected. A job is what you do to pay the bills and enjoy life. If I believe that for myself, then I need to set that example for my team as well.

“Presenting” at #SQLSATATL – #LeanCoffee #DevOps

My supplies for my workshop!

On Saturday, May 19, 2018 at SQL Saturday Atlanta, I won’t just be an organizer; I’m a presenter! My session, “All (Data) Things Considered: The Lean Coffee Workshop” is something I’m very excited to “present”. I use that term loosely, because the whole point of a lean coffee workshop is that it’s a structured, but agenda-less discussion. I participated in one of these at the DevOps Enterprise Summit in 2017, and it was a fun, and inspiring way to engage with other people who were facing very similar problems as I was.

The way it works is that there will be a brief introduction at the beginning of the session, but people are expected to form several small groups. A seed topic will be presented, but each small group will have a moderator (and thanks to my volunteers) who will make sure that their group stays on track. Every group will:

  1. Set up a personal Kanban board.
  2. Identify topics
  3. Vote & discuss.

That’s it. Easiest presentation I’ve ever done, but the goals are really deep. I want to encourage people to engage with each other; that’s one of the original goals of SQLSaturday, and I think traditional classroom settings don’t do enough of that (conversations are usually instructor -> audience, or audience -> instructor). This puts people around a table in a small, safe environment, and that leads to long term possibilities for relationships.

Second, I’m more interested in conversations about improving work, rather than just how to do work. I think coffee talks foster that because you’re not looking at a tool or a piece of code; you’re talking to a person, and hearing what they think. That sharing of perspective can spark new ideas, and new ways of looking at the forest, rather than individual trees.

Looking forward to seeing you there!

One Weird Trick to Build a #DevOps Culture

I know it’s clickbait, but I really did want to reinforce the simplicity of this post. I think building a DevOps culture can sometimes be daunting for most folks from traditional IT backgrounds because, well, people aren’t systems. You see, both developers and system engineers are comfortable with technology; it’s usually predictable, and it’s relatively easy to manipulate.

People (and processes) are messy. The social aspect of a sociotechnical environment is full of friction: different backgrounds, different perspectives, differences of opinion. It all creates a challenge for solving business problems quickly because it takes energy to build and maintain a relationship. However, once those relationships are established, the benefits multiply. When you are challenged by a peer you trust to defend an idea, it makes the idea better. The old adage of “iron sharpens iron” is true; smart people make smart people smarter.

But how do you build trust? The first step is easy.

Be thankful.

That’s it; acknowledge when people take a risk, and thank them for stepping of their comfort zone. Be thankful when they offer an opinion that’s different than yours, even if you don’t take the advice. Specifically acknowledge their contributions that make your job easier, and let them know why. It takes some time (and occasionally some effort), but it establishes a pattern of trust. This is particularly important when you’re in a leadership position, and they are not; the best ideas come from people who feel like they can contribute on a regular basis, especially to people in power.

Take the extra time to say “Thank You”, and establish a foundation of trust.

Goal – 52 blog posts a year

I’m sure nobody but me has noticed, but you may have seen an uptick of blogs on my site lately.  Most are short (like this one will be); many of them have little of interest to anybody but me.

It’s all part of a goal of mine to get out of a writing funk.  I’m trying to blog at least 52 time this year, even if it’s only a few lines.  I figure writing SOMETHING is better than sitting in a stupor, and letting my brain rot.  Creativity is mostly inspiration, but there’s also some discipline required.  So bear with me (if you want) as I struggle to find something interesting to write about.  Hey, at least it’s better than the alternative.

 

Friend of Red Gate 2018 – @redgate

I’m super excited to have been named a Friend of Red Gate again in 2018; I often wonder why they keep letting me back in because they do so many super awesome things with so many super awesome people.  However, I’m grateful as always.

They are an amazing company, and have always been very supportive of the SQL Server community.  Thanks so much for bringing me along on the ride, y’all.