On Thursday (Nov 10), I’m going to be going to DevOpsDays Nashville; I’m excited. This will be the first conference in several years that I’ve attended where I wasn’t either an organizer or a speaker. Hoping to meet some new folks and learn a lot; I’m really pushing myself to get out my comfort zone (databases), and soak up some new knowledge regarding IT culture, automation, and agile operations.
If you’re around and want to say hi, follow me on Twitter: @codegumbo
Last week, I had the privilege to speak at the annual PASS Summit; I got to present two different sessions, but the one I’m the most proud of was my Lightning Talk: Oh, the Places You’ll Go! A Seussian Guide to the Data Platform. I bungled the presentation a bit (sorry for those of you who want to listen to it), but I feel pretty good about the content. I’ve presented it below, with the slides that I used for the talk.
 |
The goal of this presentation was to explore the Microsoft Data Platform from the perspective of a SQL Server professional; I found this great conceptual diagram of the platform from this website a while back, and wanted to use it as a framework. I figured the best way to teach a subject was the same way I teach my 3-year-old: a little bit of whimsy.
Enjoy. |
 |
You have brains in your head And SQL Skills to boot You’ll soar to great heights On the Data Platform too You’re on your own, and you know what you know, And YOU are the one who’ll decide where to go. You’ve mastered tables, columns and rows, OHHHHH MYYYY |
 |
You may even have dabbled in a little B.I. You’re a data professional, full of zest, But now you’re wondering “What comes next?” |
 |
Data! It’s more than just SQL, And there’s a slew of it coming, measured without equal. Zettabytes, YotaBytes, XenoBytes and more All coming our way, faster than ever before. So what should we do? How should we act? Should we rest on our laurels? Should we lie on our backs? Do we sit idly by, while the going gets tough? No… no, we step up our game and start learning new stuff!
|
 |
Oh, the places you’ll go! ARCHITECTURE Let’s start with the Theories, The things you should know Designing systems as services, Are the route you might go. Distributed, scalable Compute on Demand The Internet of Things And all that it commands. |
 |
Infrastructure is base, Platform is in line Software and data Rest on top of design Once you’ve grasped this Once you’ve settled in You’ve embraced cloud thinking Even while staying on-prem. |
 |
But beyond the cloud, there’s data itself. Structured, polyschematic, binary, and log Centralized or on the edge, Some might say “in the fog” |
 |
Big Data, Fast Data, Dark, New and Lost All of it needs management, all at some cost There’s opportunity there to discover something new But it will take somebody, somebody with skills like you. Beyond relational, moving deep into insight We must embrace new directions, and bring data to life And there’s so many directions to go! |
 |
ADMINISTRATORS For those of you who prefer administration System engineering and server calibration You need to acknowledge, and you probably do You’ll manage more systems, with resources few. Automation and scripting are the tools of the trade Learn powershell to step up your game. Take what you know about managing SQL And apply it to more tech; you’ll be without equal |
 |
Besides the familiar, disk memory CPU There’s virtualization and networking too In the future you might even manage a zoo, Clustering elephants, and a penguin or two.
|
 |
But it all hinges on answering things Making servers reliable and performance tuning, Monitoring, maintenance, backup strategies All of these things you do with some ease. And it doesn’t matter if the data is relational Your strategies and skills will make you sensational All it takes is some get up, and little bit of go And you’re on your way, ready to know. |
 |
So start building a server, and try something new SQL Server is free, Hadoop is too. Tinker and learn in your spare time Let your passions drive you and you’ll be just fine DEVELOPERS But maybe you’re a T-SQL kind of geek, And it’s the languages of data that you want to speak There’s lots of different directions for you Too many to cover, but I’ll try a few |
 |
You could talk like a pirate And learn to speak R Statistics, and Science! I’m sure you’ll go far Additional queries for XML and JSON Built in SQL Server, the latest edition. |
 |
You can learn HiveQL, if Big Data’s your thing And interface with Tez, Spark, or just MapReducing U_SQL is the language of the Azure Data Lake A full-functioned dialect; what progress you could make! There’s LINQ and C-Sharp, and so many more Ways to write your code against the datastores You could write streaming queries against Streaminsight And answer questions against data in flight. |
 |
And lest I overlook, or lest I forget, There’s products and processes still to mention yet. SSIS, SSAS, In-memory design SSRS, DataZen, and Power BI All of these things, all of these tools Are waiting to be used, are waiting for you. You just start down the path, a direction you know And soon you’ll be learning, your brain all aglow |
 |
And, oh, the places you’ll go. And once you get there, wherever you go. Don’t forget to write, and let somebody know. Blog, tweet, present what you’ve mastered And help someone else get there a little faster. |
Feel free to leave a comment if you like, or follow me on Twitter: @codegumbo
On Monday, I’m flying out to the Emerald City (Seattle, WA) for the annual gathering of Microsoft database geeks known as the PASS Summit; as always, I’m excited to see friends and learn new stuff. However, this will probably be my last Summit. Over the last few years, my career trajectory has taken me away from database development and administration, and it’s time that I start investing in the things that now interest me (technology management, and operational culture). My goals for the next year are to attend conferences like the DevOps Enterprise Summit and the SRECon; I want and need to learn more about making IT efficient, and managing large-scale applications.
I’m not entirely disconnecting from the SQL community; I still plan to stay active and involved in our local chapter (AtlantaMDF), and part of the organizing committee for our SQL Saturdays. I still want to be a data-driven professional; I’m just not a data professional. That’s a subtle distinction, but it’s important to me. I’ll still sling code part-time and for hobbies, but I’m really trying to hone in on what I enjoy these days, and it’s process, procedures, management, and cultural change in IT (all IT, not just SQL Server).
So, this year will be different for me; instead of trying to network and schmooze and elevate my own SQL skillset, I’m going to hang out in sessions like “Overcoming a Culture of FearOps by Adopting DevOps” ,“Agile Development Fundamentals: Continuous Integration with SSDT“, and
“Fundamentals of Tech Team Leadership“. I may visit some courses on Cloud development and Analytics, but mostly, I want to enjoy spending some time with folks that I may not see again for a while.
I truly hope to see you there; I owe a lot to all of you, so I’m probably going to have a huge bar tab after buying rounds. Should be an exciting week.
While thinking about the Implicit Optimism of DevOps, I started running through some of the cultural axioms of DevOps; I’m not sure if anyone has put together a comprehensive list, but I have a few items that I think are important. Be good at getting better is my new mantra, and now, I’m fond of saying “We are all developers”. I remember eating lunch at SQL Saturday Atlanta 2016 listening to a database developer describing this perspective to a DBA, and hearing how strongly the DBA objected to that label. I tentatively agreed with the developer, but recently, I’ve gotten more enamored with that statement.
Having worked as both a developer and an administrator, I get it; there’s an in-group mentality. The two sides of the operational silo are often working toward very different goals; developers are tasked with promoting change (new features, service packs, etc). DBA’s are tasked with maintaining the stability of the system; change is the opposite of stability. Most technical people I know are very proud of their work, which means that there’s often a desire for accuracy in the work we do. If a DBA is trying to make a system stable, and you call them a developer (think: change instigator), then it could be perceived as insulting.
It’s not meant to be.
Efficient development (to me) revolves around the three basic principles of:
From that perspective, there’s lots of opportunities to apply development principles to operational problems. For my DBA readers (all three of you), think about all the jobs you’ve written to automate maintenance. Think about the index changes you’ve suggested and/or implemented. Think about the reports you’ve written to monitor the performance of your systems. Any time you’ve created something to help you perform your job more efficiently, that’s development.
DevOps is built on the principle of infrastructure as code, with an emphasis on giving developers the ability to build the stack as needed. Google calls its implementation of DevOps principles Site Reliability Engineering, and characterizes it as “what you get when you treat operations as if it’s a software problem”. Microsoft is committed to DevOps as part of its application lifecycle management (although it’s notably cloud-focused). When dealing with large-scale implementations, operations can benefit from the application of the principles of efficient development.
We are all developers; most of us have always been developers. We just called it something else.
One of my favorite podcasts lately is DevOps Café; John Willis and Damon Edwards do a great job of talking about the various trends in IT management, and have really opened my eyes to a lot of different ways of thinking about problems in enterprise systems administration. On a recent podcast, John interviewed Damon about his #DOES15 presentation, “DevOps Kaizen: Practical Steps to Start & Sustain a Transformation“. During that conversation, Damon mentioned a phrase that really resonated with me: Be Good at Getting Better.
At the heart of the DevOps philosophy is the desire to improve delivery of services through removal of cultural blockages. Success isn’t measured by the amount of code pushed out the door or the number of releases; it’s the ability to continuously improve over time. Companies that experiment (even with ideas that don’t work) learn a different way to approach any problem that they face. The freedom to experiment means that failure is not an outcome; it’s a method of improvement.
The optimism of that appeals to me; I think if you’re focusing on continuous improvement, then you’ve implicitly accepted two fundamental principles of optimism:
There’s some beauty in that; if you’re an organization facing overwhelming technical debt, it’s not uncommon to sink into a spiral of despair, where changes are infrequent for fear of breaking something. Mistrust breeds, as organizations point fingers at other teams for “failing to deliver”. You quit working toward solutions, and instead focus on fighting fires and maintaining some sort of desperate last stand.
You’re better than that.
DevOps is a cultural change; it’s an optimistic philosophy focused on changing IT culture while being open to different strategies for doing so. If you can commit to Be Good at Getting Better, you can change. It may be slow, it may be frustrating, but every day is an opportunity to incrementally move the ball forward in delivering quality business services. The trick is not to focus on where to begin, but simply to begin.
Over the last couple years, there’s been a subtle shift in my responsibilities at my day job (and my interests in technology overall). I’ve been doing much less database development and administration work, and more general system architecture work. That’s harder to write up in blog posts than SQL code, so I’ve struggled with writing, but I want to get back into the habit. So excuse the choppiness, and let me try to put some thoughts on digital paper.
I’m pushing very hard for my company to adopt DevOps principles. There’s a lot of material out there about DevOps from the developer perspective, but there’s few resources for those of us on the operations side of the house. In a pure sense, there’s no such thing as sides, but in a regulated industry like healthcare or financial services, old walls are tough to break down, so they’re useful as organizational frameworks for general responsibilities. However, we are all developers, whether or not we sling code or manage infrastructure as code; the goal is to produce repeatable patterns and tools that allow growth and change.
Two great books that I’m reading right now are:
 |
The Practice of Cloud System Administration by Limoncelli, Chalup, and Hogan. Tons of practical advice for building large-scale distributed processing systems, and DevOps philosophy is woven throughout (and specifically highlighted in Chapter 8). This is one of those books that you’ll feel like diving in on some sections, and skimming over others; it’s a through examination of system administration from development through implementation, so there’s lots of conceptual hooks to grab hold of (and conversely, things that you may not have experienced). |
 |
The second book that I’ve recently started reading is Site Reliability Engineering: How Google Runs Production Systems. This book is a collection of essays which explore Google’s method of approaching reliability; like most things Google, Site Reliability Engineering is similar to DevOps, but specific to the ways that Google does thing. It’s also light on documentation (insert joke about Google and beta products here). However, it does offer several insights into day-to-day system administration at Google. While the SRE model is not exactly like DevOps, there’s lots of overlap, and differences may be attributed more to practice than to concepts. |
More to come.
I’m presenting today at DevDataDay in Birmingham. First time in a while for me, but I’m excited about the opportunity to go to sessions again and learn something (more on that in a bit). I realize this blog has been a bit dusty for a while, but I’m gonna try to do better about that.
TOPIC: Theory of Cloud Database Administration
SPEAKER: Stuart Ainsworth
ABSTRACT: The cloud is more than just a marketing term; it’s a model for designing scalable, distributed systems and assigning ownership to various components of those systems. Data is a crucial part of that model, and there are lots of challenges ahead. This presentation will explore the history of cloud computing, the current state of data in the cloud (using SQL Server 2016), and the impact on career choices for data people.
I’ve been rereading the book Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency recently. As I alluded to in my last post, my life has been rough for the last few months. My nephew’s passing took the wind out of an already saggy sail; I’ve spent a great deal of time just trying to balance work, family, and life in general. Some people turn to counselors; I turn to project management books.
The premise of the book is that change requires free time, and that free time (slack) is the natural enemy of efficiency. This is a good thing; if you are 100% efficient, you have no room to affect change. Zero change means zero growth. I’ve been a proponent of slack for a while (less successfully than I’d like); it makes sense to allow people some down time to grow. Just to be clear, slack isn’t wasted time; it’s an investment in growth. Slack tasks include:
In short, slack is necessary in order to promote growth; if you want your organization to stay ahead of it’s competition, cutting resources in the name of efficiency is sure-fire plan for losing. The best advice for slack time is the 80/20 rule; run your team at 80% capacity, and leave 20% for slack. In the case of emergency, slack time can be temporarily alleviated, but it’s the responsibility of management to return to normal work levels as soon as possible.
So what does this mean for me personally? In the name of efficiency, I let slack time go. I work a full time job, a couple of different consulting gigs, act as a chapter leader for AtlantaMDF, and am an active father. I have no hobbies, and suck at exercise. I love to travel, but trips are planning exercises in and of themselves. In short, I have zero slack to deal with emergencies. When something goes wrong and time gets compromised, I immediately feel guilty because I’ve robbed Peter to pay Paul in terms of time. That’s not living,
I’m done with that.
Change is incremental, so I’m not planning on upsetting the apple cart just yet, but I am trying to figure out ways to make my slack time more of a recharge time. Don’t get me wrong; I waste time. I sit and stare at Facebook like the rest of the modern world; I binge on Netflix when new series drop. That’s not slack, and it doesn’t recharge me. Slack is using free time to grow, to change. My goal is to find an hour a week for growth-promoting free time. I’ll let you know how I’m doing.
I’ve been reluctant to write this post for a couple of months now, in part because I don’t usually use this forum for posting personal stuff, and in part because I didn’t know what to say. I’ve got another post in mind, however, and I felt like I needed to give this topic the respect it needed before I could pick up where I left off. Bear with me.
On December 1, 2015, my nephew took his own life.
No matter how many ways I tried to write that previous sentence, none of them seemed to adequately capture what I’m thinking or want to say, so I’ll leave it alone and try to finish this post. Cris was a smart, funny, kind young man with whom I didn’t spend near enough time as he grew up; I really only got to know him over Facebook as an adult, and I loved him.
He had battled depression for years, and he lost the war. He left behind a grieving fiance, a set of in-laws who loved him very much, his mother (my sister), grandparents, great-aunts, great-uncles; all of us were shocked, and I didn’t realize how much I would miss him.
Family is important, y’all. Don’t miss out, and don’t let anything keep you from loving yours.
Me and Cris, circa 1995
I’ve been presenting a lot on Big Data (specifically Hadoop) from the perspective of a SQL Server DBA, and I’ve made a couple of recent observations. I think most people are aware of the fact that data generation is growing at a staggering rate, with some estimates as high as 44 zettabytes by the year 2020; what I think is lacking in the SQL Server community is a rapid movement among database professionals to expand their skills to highly scalable Big Data platforms (like Hadoop) or streaming technologies. Don’t get me wrong; I think there’s people out there who have made the transition (like Michelle Ufford; SQLFool, now Hadoopsie), and are willing to share their knowledge, but by and large, I think most SQL Server professionals are accustomed to working with our precious relational system.
Why is that? I think it boils down to three reasons:
The first two reasons aren’t easily solved; they require a willingness to learn and a commitment to study (both of which are difficult resources to commit). The third issue, however, can be easily addressed by the following graphic.
This is Microsoft’s generic vision of a complete end-to-end analytics platform; for the data professional, it’s a roadmap of skills to learn. Note that relational engines (and their BI cousins) remain a part of the vision, but they’re only small pieces in an ever-increasing ecosystem of database tools.
So here’s the question for you; what should SQL Server people do about it? Do we continue to focus on a very specific tool set, or do we push ourselves (and each other) to learn more about the broader opportunities? Either choice is equally valid, but even if you choose to become an expert on a single platform in lieu of transitioning to something new, you should understand how other tools interact with the relational system.
What are you going to learn today?