Conferences

#SQLSATBR: Database People and #DevOps

Excited to announce that I was chosen to present my session “Database People and DevOps: The Fundamentals” at SQLSaturday Baton Rouge 2019 this August. Very excited to head back close to home this year; I actually attended LSU graduate school for a year before transferring to UGA, so the campus holds a dear place in my heart. SQLSaturday Baton Rouge appears to have grown a lot since the last time I was there, so I’m hoping I can pick ups some ideas for our event in 2020.

This is a fun session for me, and I’ve got some revisions to make after delivering it in Atlanta. I hope folks find it informative, and I give lots of references for future study. This is a summary class, which means I cover a lot of topics at a high level, but I like to build a framework for future study.

Y’all come.

#DOES18 – Tuesday Takeaways

Thoughts from yesterday’s DevOps Enterprise Summit in Las Vegas

  1. Managing workflow is different than managing configuration changes or code.  It’s related, but you can have separate systems for individual team’s processes and procedures (i.e., Azure DevOps for developers, ServiceNow for ops), but you want to make work visible to all affected teams.
  2. Making work visible was a theme I heard over and over again; so much of the “throw it over the wall” mentality stems from the fact that ops does magic. 
  3. Processes are necessary, but they must be as light as possible or they won’t meet the need (they get in the way of rapid response).  People often adapt by ditching the process anyway.

TIL from Atlanta #AzureDataFest

AZURE DATAFEST

I’ve been meaning to write this post since we wrapped up the event, but life, as usual, gets in the way.  Overall, I was very pleased with the whole event; things (for the most part) ran very smoothly.  However, in the spirit of continuous learning, here’s a few lessons (in no particular order) for anyone considering hosting an Azure DataFest in the future. 

Event Management

We used Sessionize and EventBrite to handle speaker submissions, schedule building, and attendee management.  Both tools worked great, but both are a little pricey (Sessionize charges $250 for the event, and EventBrite added a $3.54 fee to every ticket sold).  The benefit is that it was very easy to generate a professional looking schedule, review abstracts, and manage attendees (from fee collection to attendance rosters).  The one downside is that the tools don’t integrate (no way to easily export speakers into Eventbrite), and we really need a central website for people to hit rather than each individual tool.  I also had a small issue where some attendee badges didn’t print; that was probably user error.

Sponsor Expectations

  • I should have added company names to each attendee badge to make it easier for them to see what company attendees were from when talking.
  • I need to explain the email\contact information privacy policies better.  Some sponsors wanted to get more contacts to add to their mailing list.  May need to borrow a page from the SQLSaturday playbook and encourage raffles to get information directly from the attendees.
  • Microsoft SSP’s were on site, and that was a very valuable contribution.  Saw lots of hallway conversations with clients and Microsoft; that’s rare for SQLSaturdays.
  • Need to charge more for sponsorships in general; we had a flat rate of $500, which doesn’t go a long way toward building a community.  Also, I need to provide more structure over what’s included in a sponsorship; we had a couple of sponsors which had 5 or 6 team members show up.  Since food was included in their sponsorship, that literally ate up most of the profit from their sponsorship.
  • Need to find ways to encourage relationships between speakers and sponsors; speaker dinners or vendor parties?

Attendee Management

  • Generally, went well.  Food portions were about right, fee was right for a two day affair, and we had very few snacks and\or drinks left over.
  • Would love to go as paperless as possible; however, I think people like having SWAG bags.  Maybe provide them with an empty bag, and tell them SWAG is available at sponsor tables?
  • Stickers were a HIT!
  • Very different crowd than a SQLSaturday.  In fact, during opening session, only a few people had heard of SQLSaturday or AtlantaMDF.  Need to do a better job of evangelizing both of those, while recognizing that this is a crowd that may not want to give up their weekend.
  • Pretty sizable fall-off on Friday (the second day).  May need to do Monday-Tuesday to see if we do a better job of retaining folks.

Speaker Management

  • As noted above, Sessionize worked great for speaker management.  Abstracts were easy to receive and review, and building a schedule was a snap.
  • Need to be more up-front about the volunteer nature of this conference.  We had a few people that misunderstood, and submitted from abroad, and then inquired about travel reimbursement.  It was cleared up over a few emails, but I should have headed that conversation off earlier.
  • I had a speaker withdraw because we charged $50 to attend the two-day conference;  they felt that didn’t fit as a “community” event, since most community events should be free to the consumer (or offer an optional lunch, like SQLSaturday does).  I get the point, but in practical terms, that’s tough to do with a new event.  No event is free; just different people (sponsors) pick up the tab.  We’ll continue to work on this, but ADF may always have a small fee associated with it.
  • Most sessions had speakers sitting in the audience.  I haven’t seen that happen at SQLSaturday’s in a long time, so I’m hoping that people learned as much as they gave.

Logistics

  • Facility was great, but room capacity != seating arrangement.  I had to steal chairs from sponsors, and actually order more chairs on the first day to eliminate standing room only.
  • I loved having the plenary (everybody in one room) sessions at the start; really need to do one at the end, and then do a wrapup.
  • I could have saved some funds on table linens.  The caterer brought their own, and they weren’t really necessary for the check in tables.
  • We had a few technical glitches, so we need to make sure we keep the facility staff around next year.  They went to lunch and weren’t back in time for the afternoon session, so those were a little rough (maybe promise them free lunch next year?).

#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.

 

“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!

Azure DataFest Boston 2018 – Another Call For Speakers for #SQLFamily

I’ve recently gotten involved with Azure Data Fest, a new tech conference focused on the cloud version of the Microsoft Data Platform.  The second event is being held in Boston on March 1, 2018.  They’re actively looking for community speakers, and their call ends on February 9th.

https://www.eventbrite.com/e/call-for-speakers-azure-datafest-microsoft-azure-advanced-analytics-and-big-data-conference-boston-registration-40984247989

Sessions should cover one of more of the following:

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 HDInsight
Dynamics 365 for Customer Insights
Custom Speech Service
APIs: Emotion, face, Bing Speech, Web Language Model, Speaker Recognition, Bing Autosuggest, Bing Spell Check, Translator Speech, Translator Text

#SQLSATATL 2018 – call for speakers through March 16, 2018

SQLSaturday #733 - Atlanta 2018I haven’t posted much about SQL Saturday Atlanta in a while; things are moving along, and the event is coming back to Alpharetta (albeit a new building) on May 19, 2018.  Lots of folks are busy behind the scenes preparing, but there’s a few key things to keep in mind:

  1. Call for Speakers closes March 16, 2018; f you’ve been sitting on a presentation idea, now’s the time to get it uploaded to the site.
  2. Shortly after the Call closes, we’ll publish the full schedule.  Once that hits, there’s a mad rush to register.  This event sells out every year, so why wait?  Register now.
  3. Pre-Cons are coming; we hope to publish the list soon.  More details to come.

Exciting times ahead; stay tuned.  As always, SQL Saturday Atlanta is brought to you by AtlantaMDF; SQL Server meetings every month on the second Monday.

#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?


#DOES17 San Francisco – Things I Learned

Just spent the last few days at a technical conference that focused more on cultural change and workflow than bits and bytes, the DevOps Enterprise Summit. It was enlightening, and for the first time in a while, I’m leaving a professional conference energized and hoping to implement some of these ideas. The DevOps community reminds me a lot of the SQL Server community; passionate people who just want to help each other grow. There’s so much good content, and I think most of it will be available via YouTube later.

Armed with my handy dandy Rocketbook (I left my laptop in my hotel room each day purposefully), I scribbled notes fast and furiously. At the end of each day, I tried to capture three things that struck me as important, based on everything I’d heard. Here’s my list, broken apart by day:

Day 1 – Nov 13, 2017

  1. You are on the right path, do not fear. Change only happens when you take risks.
    I’m not sure why this struck as so important, but it was a feeling of general acceptance of ideas. I often struggle with being a leader because I think too much about the challenges ahead; that’s fear, pure and simple. The truth is that every challenge in technology has a solution; it may not be obvious, it may not be immediate, but it’s there. Fixate on the goals and successes, and don’t worry about the challenges.
  2. Value Stream Mapping is key to continuous improvement.
    This came out of the workshops, based on the Lean Coffee format; one of the discussion points that came up was the value of value stream mapping. I already liked the concept, but I tend to drift into thinking about the software components, whereas the discussion focused more on the people & process aspects of it. You can’t improve until you know where you are starting from.
  3. T-shapes are the best shapes.
    I had come across the term T-shaped professionals only a few days before flying out to San Francisco, and I was surprised to hear it mentioned in at least 4 sessions today. It aligns well with my vision for Service Reliability Engineering; people can (and should) be experts in a key area, but have some depth in additional necessary areas.

One of the amazing graphic facilitation artifacts done by Christopher Fuller of Griot’s Eye at the conference.

Day 2 – Nov 14, 2017

  1. Start with what you can do, but don’t be afraid to ask what other people are doing.
    This ties back into the first message from day 1 a bit, but it’s a little bit of a twist. Often when I see good ideas, I think “I can’t implement that”, and I may be right; I don’t have control of my infrastructure anymore, for example. However, just because I can’t do it, doesn’t mean that I shouldn’t tell people about something I’ve seen, and ask if it fits into their mental model of where we’re going.

  2. The SRE model works when you focus on people, not technology, and reliability (what you can measure and improve).

    Site Reliability Engineering talks were in short supply at this conference, but it permeated throughout. The fundamental truth of focusing on people, rather than technology still holds true with this model; technology breaks because of people. That’s not intended to be a statement of blame, but rather an understanding that technology does what it’s told to do; when things go awry, there’s an opportunity to understand what humane choices to make; is it a misunderstanding of purpose? Was there a missed signal of pending change? Was a change implemented riskily?

  3. Service Level Objectives (SLO’s) are crucial to monitoring.
    Operations folks are inundated with logs and other metrics; understanding what the expectations are for the business service is key to understanding what metrics to observe (and what to ignore). You cannot measure reliability effectively without some understanding of what up-time means.

Day 3 – Nov 15, 2017

  1. Foundation of journey is based on a three-legged stool: Service Level Objectives, Value Stream Mapping, and Technical Architecture Map.
    I know, the whole DevOps is a journey thing is a bit tired, but it’s an attempt to represent the fact that everybody’s experience with these principles yield different results, and paths. However, for my current work situation, we’re not going to get far without these three things. We need to understand what the Service is supposed to do, how the people interact with the technology, and how the components of the technology are supposed to work together.
  2. DevOps brings joy to technology; don’t quibble over details, but focus on bringing humanity into technical work.
    Gene Kim’s closing comments reminded me a lot of my #sqlfamily; everybody brings a different perspective on technology, and a different method of solving problems, but the people that impact me most are the folks that do so with joy. They have a passion about what they do, and their goal is to encourage others to move forward (rather than focusing on rigid solutions based on their own experiences).
  3. Patience – all change takes time, and the road is uncertain. Don’t expect overnight successes.

    Finally, my head is full of things to think about, and books to read. However, there is no magic pill for implementing change in my organization. It has to happen slow, and it has to be organized by every member of the team who wishes to contribute. It takes time to light a fire, but it is crucial to the success of any DevOps initiative.