SQLServerPedia Syndication

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.

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.

Finally hanging up the shingle (part time)…

Let me get this out of the way first; I haven’t quit my day job. I’m VERY blessed to work at a great company that lets me work from home, balance work & life responsibilities, and has great pay and benefits.

However, I’ve had side gigs for the last 15 years or so; at first it was to make extra money, and then after my divorce and child support payments kicked in, the side hustle became crucial to my financial survival. Once I satisfied those obligations, the side gig is not really necessary, but man, it’s nice to have to spring for the extra vacation here or there. As such, I finally decided to make it real, and have now established myself as an LLC in the state of Georgia.

I feel so grown up.

The real irony of this is that shortly after I filed the paperwork, I was notified by my longest running bread-and-butter side gig that they had been bought out, and my services would be phased out by November. I went ahead and filed for the LLC anyway, but it just strikes me as funny that now that I’ve finally got a “real” business, I don’t have any clients.

I’ll just keep on keepin’ on, but there is a small sense of satisfaction knowing that there’s now a CODEGUMBO, LLC. Anybody need a SQL slinger for hire? Project Manager?

#SQLSaturday – Is it really about the tools?

There’s been some interesting conversation on the SQLSaturday slack channel regarding the admin tools for SQLSaturday. It was spawned, in part, by this great set of ideas proposed by the Godfather of SQL Saturday, Andy Warren, regarding changing the way that software development for the tools is handled by PASS HQ:

“So if that is all the way on one side of the scale (super closed system), the far other side is  to open source it. Open source is also not simple. If you’re on the PASS Board you have to care about the potential loss of intellectual property. Scoff do you? No, there is no magic in the code, but it’s sweat equity and it’s a substantial part of what drives new members (and new email addresses for existing members) into the mailing list. Do you really want people forking it and spawning variations under different names?

Is there a middle ground? Sure. Let’s put together a straw man of what it might look like:

  • PASS puts the source code into a private Github repo (because all devs love git!) along with a masked data set they can load/restore
  • Write an agreement to get access to the source code and agree to not republish the code, plus convey to PASS the IP rights to new stuff
  • Write the governance process. This is the hardest piece. Who will approve pull requests? Who decides which features get added? Who will do the testing? How often will releases be done (since PASS has to coordinate that)? Code standards. Rules about fonts and logos – all the stuff you deal with any dev shop.
  • Down the road a little build a true dev environment where the latest code can be loaded and tested.”

It should be noted that Andy wrote (or oversaw) most of the original code for the SQLSaturday admin tools, so he’s no crackpot; he knows software development, he knows SQLSaturday, and he knows how to get things done. In fact, as I was writing this post, I went back and read some of my original posts about SQLSaturday #13 (back in 2009), I found myself reminiscing about all the advice he’s given to me (and countless others); when Andy proposes something, it’s usually a good idea to listen. And, when Andy says he wants feedback, he means it.

So here’s my feedback, based on the events I’ve helped run (I’ve lost count; it’s somewhere around 15); I question whether PASS needs to be in the admin tools game at all. 2018 is a very different landscape than 2007 (the very first SQL Saturday). Tools like EventBrite, Meetup, PaperCall.io, and Sched.com can provide a lot of the support required for the daily activities of running a SQLSaturday. Most are free for smaller events. All come without the cost of maintenance and support that are currently required to run the current admin site. By the way, I think the current tools are fine, but there do seem to be some ongoing reliability issues.

I brought this up on the Slack channel, and Steve Jones had some great counter arguments, including issues with integration and the recurring cost of these tools. I’m not sure that integration is an issue; I think that events have four different audiences, with four different needs:

  1. PASS needs members. They want email addresses from attendees to build their membership.
  2. Sponsors need leads; email addresses are great, but interested people are better (that’s usually achieved by the raffle system).
  3. Speakers need to manage submissions, and know where they’re supposed to be.
  4. Attendees need to register, order lunch, and see the schedule.

I’m not sure that having a single system to try and do everything is needed. I can envision PASS setting up a website and an email address, and then sponsors using a tool like Eventbrite to manage registrations. They can supply those email lists to PASS after the event to be imported into PASS’s databases. They can use a tool like Sched.com to manage speakers calls and build schedules. Eventbrite can be used to build the equivalent of Speedpass natively.

Thoughts?


The S in #SRE

As I’ve blogged previously, my responsibilities at work have shifted to focus more on the application of Site Reliability Engineering principles to the delivery of our business services to our customers. Unofficially, we’re calling my team Service Reliability Engineering for a few reasons. I thought I’d take some time to explain what the differences are, and why I think the name matters. I realize I’m just one lonely guy in the wilderness, and I’m going up against Google, but I think one word in the title is wrong. Before I explain why, let me explain what I do like about the title.

Engineering defines consistency of methods.

I realize that engineering is an interesting terms these days, with lots of different definitions; you can even be sued if you call yourself an engineer inappropriately in the wrong jurisdiction. However, the term itself is widely used in technology careers to describe the systematic design and operation of complex systems. Most modern applications are actually comprised of several smaller applications, all in varying states of underlying complexity. Furthermore, the delivery of an application to an end user (particularly web applications) can span the entire spectrum from infrastructure to platform to software. Additionally, applications can vary in terms of scalability, configuration, and location. Engineering addresses complexity, not just complication through systematic processes; engineers experiment, learn, and integrate consistent practices into their daily processes.

Reliability refers to purpose.

When your job title identifies reliability as a name, it means that you have a specific goal in mind, and that goal is not limited to a technology. Reliability engineers work with networking equipment, operating systems, applications, middleware, and/or database systems. They may specialize in a area (e.g., database reliability engineering is now a thing), but a robust team is comprised of necessary skill sets required to meet service level objectives across the entire technology stack. Reliability as a goal must first be defined, and then measured, and SRE responsibilities are responsible for measuring and addressing reliability across the entire spectrum, from infrastructure to platform to software. However, reliability measurement must also account for not only technological issues, but also the processes and people responsible for developing and operating the system. There’s a reason that a just culture is an integral part of the SRE experience (and the DevOps movement at large); people are responsible for how well technology performs, both in terms of defining expectations and day-to-day delivery of service. It only makes sense to look beyond technology when examining reliability, and that leads to where I disagree with the standard SRE nomenclature.

“Site” implies a technical focus; “Service” implies a business function.

The word “Site” in the IT domain typically refers to either a physical location (data center site) or an application (web site); however, the heart of the definition is sociotechnical, not strictly technology. From an undated (seriously, Google?) interview with Ben Traynor, the founder of the SRE movement: “… we have a bunch of rules of engagement, and principles for how SRE teams interact with their environment — not only the production environment, but also the development teams, the testing teams, the users, and so on.” While the previous paragraph of that interview specifically focuses on the type of work that’s being done by Google’s SRE team, these rules of engagement show that SRE’s should be concerned with the entire value stream of service delivery including not only operations, but development, testing, and ultimately the end user experience.  In, other words. SRE’s are concerned with the reliability of the whole service, not just the technical parts.

#DevOpsDays #Nashville in the books

Headed back home after a successful Ignite presentation at DevOpsDays Nashville. This was an awesome conference; I’ve blogged in the past about some of my concerns with the single track format, and finding speakers that manage to reach a very diverse audience of engineers, managers, coders, analysts, etc. I had no such concern this time around; I feel like I got something out of every presentation I heard. Very well done.

On a personal note, IGNITE TALKS ARE HARD, Y’ALL. 5 minutes, 20 slides is tough to pull off, particularly when you have a penchant for verbosity (editing is NOT my favorite thing to do). I originally proposed this as an Ignite talk because I’m just really starting on my DevOps journey, but in hindsight, I spent WAY more time editing and preparing for this discussion than any SQL Server presentation I’ve ever done. The plus side is that I can reuse a lot of this material in educating my team when discussing the depth of these directions.

Headed home with lots to think about.

Presenting at #DevOpsDays #Nashville

Very excited to be presenting an Ignite talk at #DevOpsDays #Nashville (October 17-18, 2017): Tactical Advice For Strategic Change In A Brownfield

It’s only a 5 minute presentation (20 slides; slides change every 15 seconds), but I’m stoked about it. It’s going to be my first DevOps talk that has absolutely nothing to do with SQL Server; finally starting to go in a new direction, and focus on Culture, Lean, and Sharing. It’s a great little conference, and I’m grateful to go back for my second year (this time as a speaker).

Now, I just got to develop the slide deck J

Using @AnyDo for tasklist management

Trying to stay in the habit of writing, and this seemed like a quick post, so here goes; I’m not really in the habit of writing product reviews, but I’ve found this one to be useful, so I thought I’d share.

Task management is something I’ve always struggled with; I’ve tried various systems from Trello to LeanKit to Kanbanflow, and they’re hard for me to use consistently. At work, I use a homegrown SSRS report connected to our helpdesk system as a kanban board, but it’s clunky for ad-hoc requests. It takes way too many clicks to create a ticket for a simple to-do item like “set up a meeting”.

I recently got an Amazon Echo Dot (and later a Tap), and I was intrigued by the to-do list functionality; suddenly it became quite easy to jot down a quick task for either business or personal work. I just shouted out “Alexa! Add do something awesome to my to-do list”, and was immediately gratified with a task appearing in the Alexa app on my iPhone. Excellent. Except for when I was away from my desk (and my Echo Dot). I could open the Alexa app and add a task item manually, but typing seems so old school. And then I remember, Siri could do reminders too. Guess what? Integration with Any.Do.

Long story short, I can now manage nearly all of my to-do items by voice. If I have a brilliant idea while sitting at my desk, I ask Alexa to note it for me. In the car? Siri’s my friend. The beauty is that they both go to the same repository in Any Do, and I can mark them as completed as I knock them out. The only downside is that the app places them in different lists, but I can view them in one combined list (see screenshots below).

Visibility is only part of the battle; organization is equally important. One of the features that I really like about this product is the “Plan My Day” option. Basically, if you have several tasks scheduled for today, you can run a little wizard to cycle through all of them and decide if they’re really going to get done today (or not), and schedule them accordingly:

I try to keep it to 3 tasks a day; this gives me the flexibility of responding to issues as they come up, and still feeling like I’m getting somewhere. I usually add more tasks as I work, but if I finish with a clean slate (three planned + x unplanned), it’s a good day.  Lots more features to explore, including calendar integration, subtasks, and task assignments, but I try to keep it simple. I’ve been pleased with how well the voice integration works, and how natural it is to manage my to-do list now.