#SQLSatATL, #DevOps, #Cloud, & the Future of the DBA

Last weekend was SQLSaturday Atlanta 2017, and I was not only an organizer, but a presenter. In the future, I’ll need to balance that a little better (especially when we’re dealing with a lot of unknowns for the day, like a new building). Overall, I think my presentation went well; had a lot of great hallway conversations with folks later, and got some good feedback. You can find the slide deck here, or look on the Code, etc tab above.

However, during my presentation, a couple of questions came up that I didn’t have a great answer for; mostly it was revolving around the first bullet point on this slide:

Why, if DevOps as a philosophy encourages better communication between development and operations, do I believe that there will be increased segregation between those roles? I fumbled for an answer during the presentation, but then went back and realized what I left out in my explanation, so I thought I’d take a stab at rebuilding my argument and explain where I was going with this:

DevOps is built on a Service-Oriented Architecture (SOA) model.

Services logically represent business activities; they are self-contained, and the inner workings of each service are opaque to the consumers. Services can be built using other services, but that rule of opacity stays true; when you consume a service, you don’t care what it’s doing under the covers. It just has to provide a consistent output when given a consistent input.

The Cloud Paradigm is also built on a SOA model.

Software-as-a-Service is built on a Platform-as-a-Service, which is in turn built on an Infrastructure-as-a-Service. Communication between service layers must be consistent and repeatable, but processes and procedures within each services should be opaque. Furthermore, the consumers of a service are not the same; for example, if you have a web portal displaying account information to a client. The client consumes Software-as-a-Service; they just want to see their account information. They don’t care how many servers are involved or how the network is laid out. Software-as-a-Service consumes from the Platform layer; they may have a requirement that they use a particular database system, or OS, but specific configuration isn’t exposed to them. Software engineers define performance expectations (e.g, “we need to commit 1000 transactions per second”), and leave it up to the Platform (and Infrastructure) engineers to meet that expectation.

The traditional tasks associated with SQL Server Database Administration can be roughly divided into two roles: Development and Administration (Operations).

From this slide, I outline the general breakdown between skills:


SQL Server as a product spans the top two layers of the Cloud Paradigm:

Basically, I believe that traditional development skills belong to the Software-as-a-Service Layer, and traditional administration skills belong to the Platfom layer.

So by segregation of responsibilities, I mean that as companies embrace the Cloud paradigm, the current role of a DBA will fork into both Software-as-a-Service engineering (Dev) and Platform-as-a-Service engineering (Ops). I need to clarify that thought more in future presentations, because I may be using those terms differently than others would.

Thanks for reading, and if you attended, thanks for coming!


July 19, 2017 · stuart · No Comments
Tags: , , , ,  · Posted in: Conferences, Development, DevOps, SQLServerPedia Syndication


There’s been some great discussion in the #SQLFamily after Brent Ozar published a recent blog post: I Failed 13 College Courses. Lots of comments on Facebook about it, and other people soon came forward with their own brief tales of academic failure (and subsequent successes). I was particularly touched by Mike Walsh’s video (What Advice Should I Share on Career Day?), where he talked about dropping out of high school. Most of the conversations were about the struggles in academia, but there was real underlying thread: You can succeed and be happy after facing failure.

I’m friends with a lot of smart, successful people, and for those of us that are engaged in information industry, failing at an intellectual exercise (like college or high school) can be perceived as a mark of shame. I think what Brent, Mike, and others are showing is that recovering from failure is not only possible, but normal. We all fail at something, and that often puts on a new path to figuring out something else. Failure teaches us more than success.

My Story…

(Note: I just realized that my last blog post touched on this story briefly. Must be on my mind a lot lately.)

I didn’t fail in high school (WMHS, 1989).

I didn’t fail during my Bachelor’s degree (ULM, 1993 – B.A, RadioTVFilm Production).

I didn’t fail during my first Master’s degree (ULM, 1995 – M.A, Communication).

I didn’t fail on my coursework for my doctoral degree. (UGA, PhD coursework completed in 1999).

Nope. I waited until I was 28 years old (with a wife and two kids depending on me) to fail at my first academic exercise. I bombed my doctoral comprehensive exams not once, but twice over a 6 month period. In April of 2000, I was waiting outside my major advisor’s office to discuss my options for a third attempt. I waited for two hours, brooding over the shape of my life at the moment. She never came, so I walked out the door and didn’t go back (stopping at a bookstore on the way home to purchase two books on SQL). I didn’t hear from her until a few years ago when she friended me on Facebook, and we’ve never really discussed it. I’m happy, and she’s moved on to greater successes as well.

As an aside to this story, I had been working at the American Cancer Society while going to school; my official title on most publications was Research Assistant, but I was the shadow DBA for the Behavioral Research Center. I had been working with Microsoft Access to manage contact information for cancer registries as well as using SPSS with SQL to analyze data. I parlayed that interest in data management into a new job in August of 2000; I had decided that I wasn’t cut out for anything academic, and I wanted to move into IT full time.

I did go back in 2001 to finish a second Master’s degree in Education (UGA, 2002 – M.Ed. Instructional Technology). Yes, I have three college degrees, and none of them are in information Technology.

What I Learned…

Lots of lessons I picked up out of this.

First, I learned that the fear of failure often motivates me to pick the easier path. Looking back over my academic career, I’ve always been smart enough to know what my limitations are, and lazy enough to not challenge them. I got a degree in Radio Production, not just because I enjoyed the theatrical end musical elements but also because I knew I didn’t have to take harder courses (like Chemistry, Physics or Calculus; all of I which I had managed to avoid in High School). I used to think it was working smarter, not harder; in hindsight, I just didn’t want to fail.

Second, a fear of failure often blinds me from looking at the bigger picture. When I’m scared that something is going off the rails, my instinct is to drive forward at full speed and force it to succeed. Over time, I’ve learned to be sensitive to those warning signs, and try to put the brakes on and redirect. At several points in my graduate career, I knew that I was in the wrong field. But I had a job in academic research, and I had never failed before, so I was going to see this through and will it to be. That obviously didn’t work.

Third, fail early, because failing late in the game is expensive. I racked up over $120,000 in student loans in my doctoral program; if I had recognized early on that I wasn’t going to be happy, I could have avoided that. If I had challenged myself earlier with smaller risks, I might have predicted that academia wasn’t for me. Hindsight is amazingly clear; in the thick of it, however, I’ve learned that it’s best to take small risks when possible, and fail often. Failing at something gives you two choices: you challenge yourself to try something different and succeed in the future, or you curl up in a ball and “accept your limitations”. It’s easier to bounce back when the consequences of the failure are small.


I’m no guru; I’m just a guy trying to figure it all out just like you. I’ve gone on to have other epic failures, as well as some incredible successes. I will say that my own personal journey has resonated with my perspectives on software and service development recently. Below are some great reads about failure.

Successful Failure

Fail Fast and Fail Hard

Blameless post mortems – strategies for success

June 8, 2017 · stuart · One Comment
Tags: , , , ,  · Posted in: Professional Development, SQLServerPedia Syndication

The Technical Manager

I used to present a session called Managing a Technical Team: Lessons Learned (Alexa: Remind me to update and submit this session again); the point of it was to reflect on some of the lessons I learned early in my career transitioning from a database developer into a management position. I was trying to give a view from the trenches, mostly to help other folks get a perspective on what it’s like to fumble through a career change. Management, like development, is a process of learning and continuous improvement; the difference is that other people have some expectation that you know what you’re doing (and often, you don’t). Inevitably, I’d get asked some version of this question:

“Can I still be technical and manage a team effectively?”

I used to have a quasi-canned answer, something along the lines of “at some point you must choose your path; management is about people, not technology”. I still kind of believe that, but recent experiences in my own career path have caused me to reconsider giving an answer. Instead, I’ve started asking the questions:

“Why does it matter? What’s your goal for your career? What do you think you should do?”

The truth is, I don’t know what’s best for you, but I trust that you do (that satisfies my libertarian soul). Everybody’s got different experiences, different beliefs, different goals, and different circumstances. When you bundle those things together, it makes for a very complex decision tree; even a simple question about how you want to conduct your day-to-day affairs becomes overwhelming for someone sitting on the outside to answer. That being said, I still want to help, so I thought that I would share some of my decision factors using the four buckets above.


Here’s some of experiences that have gotten me to this point:

  1. I don’t have a technology-related degree; I have a BA in RadioTVFilm Production, a MA in Communication, and a MEd in Instructional Technology. I got into database work when I flunked out of a PhD program in Health Communication (and salvaged some of those hours into the MEd). I had failed my comprehensive exams twice, and had a meeting set up with my advisor to discuss a third attempt. She never showed; I drove off campus that night, bought some books on SQL and relational design (having done stats work as a grad student), and started looking for a job.
  2. In my first IT job, I worked for a good manager (a developer running a support organization). When he left, I worked for an awful manager (a project manager who had no clue about anything related to computers). I try to emulate the former and check my actions to make sure I’m not acting like the latter.
  3. I’ve been with the same company for almost 15 years since then. Different roles, different responsibilities, different owners.


These are some of the core beliefs I have about management and technology; these will be tough to change.

  1. Management is more about people than tools.
  2. Management should be more strategic than tactical. While a team may be responsible for specific operations, the manager of that team should understand the unit’s role in the bigger picture.
  3. Technology is used to solve business problems; a good manager will focus more on solving the problem than on the tools used at any point in time. SQL Server is the tool I’m accustomed to using, but the problems I’ve been focused on lately aren’t database problems (they’re IT infrastructure and networking issues).


Goals are tough for me, because I believe they should be a mixture of both long-term and immediate. As such, they change more often than you would think (at least for me).

  1. I want to be forward-thinking; I want to keep being exposed to new tools and technologies.
  2. I want to be compensated well, and I want to continue gaining new responsibilities.
  3. I want to feel like I’m making a difference; I’m not interested in continually addressing the same problems over and over again. I want to make a change and move on.


Everybody’s got different external factors that influence their decisions; managers are no different. For me, the following things are true:

  1. I’ve been a remote worker for the last 8 years; it would be tough for me to go back to having a daily commute.
  2. I’m project focused, not time-focused. I like having flexibility to get things done without a set schedule.
  3. I’m a dad, and time with my kids is critically important. That means that I’ve had to pass up on opportunities because I’d rather take time for them.

What does this all mean?

For me, it means that I don’t want to be a single-technology manager; I want to figure out how to make technology work for business, even if it’s a technology that I’m unfamiliar with. The logistics of scale means that I can’t be the single source of authority when it comes to implementing technical solutions. I scale out by relying on my team to be the experts, and I want to keep building teams that can handle lots of different problems.

More to come later.

May 8, 2017 · stuart · No Comments
Tags: , ,  · Posted in: Professional Development, SQLServerPedia Syndication

#DevOps: Remote Workers and Minimizing Silos

Been a while since I’ve posted, so I thought I’d try to put down some thoughts on a lightweight topic. I’m a full-time remote worker; I have been for the last 10 years). My company has embraced remote workers, and provides lots of tools for people to contribute from all over the country (including the wilds of North Georgia); tools include instant messaging clients, VOIP, remote presentation software, etc. Document sharing and discussion is easy, but as you probably know, DevOps is as much about relationship building as it is about knowledge sharing. How do you minimize silos between teams when teams aren’t physically located near each other?

Here’s some different methods:

  1. 1. First, in-person communication provides the greatest avenue for relationship-building. Bringing a remote worker in from the field from time to time can greatly reduce isolation. If your chief developer is in Wisconsin, and your main sysops guy is in Georgia, flying both in periodically is probably the best way to create opportunities for conversation. Better yet, send them both to a conference somewhere in between.
  2. If in-person conversation is the gold standard for discussion but isn’t an option for economic or practical reasons, seek methods to emulate that experience. Conference calls or web conferencing tools are common, but video conferencing adds an additional dimension to discussions. In general, the higher the bandwidth, the better because it forces “presence” in conversations.
  3. Encourage remote employees to add depth to relationships by providing them with a virtual space to connect. Internal blogs (with personal pictures or activities), or slack channels for goofing off provide teams with meta information beyond their work ability. Knowing that another person loves Die Hard as much as you do gives you a common place to start building relationships.
  4. Organize virtual non-work events, such as multi-player gaming marathons (Leeroy Jenkins would be proud; NSFW) or virtual parties.

The main point is that while face-to-face interaction is desirable, it isn’t necessary. Employees (and companies) can thrive if they actively seek methods of encouraging high-bandwidth interactions with depth. Distance increases difficulty, but it’s not insurmountable.

Feel free to drop a suggestion for enhancing remote communication and decreasing silos.

March 13, 2017 · stuart · No Comments
Posted in: Blogging is FUN!, Development, DevOps, SQLServerPedia Syndication

#DevOps: Embrace the Ops

If you’re at all in touch with the DevOps community, you’re probably aware of the GitLabs Incident on 1/31/2017; I won’t spend too much time rehashing it here, but GitLabs has done a great job of being transparent about the issue and their processes to recover. Mike Walsh (Straight Path Solutions) wrote a great blog post about it entitled DevOps: Don’t Forget The Ops, which covers a lot of ground from a database administration perspective. Mike ultimately ends up with three specific action items for DevOps teams:

  1. Plan to Fail (so you don’t)
  2. Verify Backups (focus on restores, not backups)
  3. Secure your environment (from yourself).

I agree with all of these ideas; I think Mike is spot on about the need to Remember the Ops in DevOps. However, I want to go a step further, and encourage DevOps adoptees to Embrace the Ops.

What do I mean by that? Let me start with this; Brent Ozar posted this on Facebook yesterday (the image will take you to the job description):

Now, it’s obvious that GitLabs had a backup strategy (they detailed it in their notes), so I don’t mean to imply that they didn’t expect administrative tasks from their database people, but I do think we can infer that administrative tasks were not prioritized as much as other tasks (high availability, performance tuning, etc.). Again, we know that GitLabs had strategy for backups, so it appears that this is a cultural issue (at least based on this flimsy evidence and the outage). And to some degree, that’s understandable; one of the longest running challenges on the operations side is being labeled as a cost center as opposed to development being viewed as a revenue generator. This perception is pervasive in traditional IT shops, so it’s probable that even Unicorn shops share some of this mentality. Development (new features) makes money; Operations cost money.

However, in a true DevOps model, the focus is on delivering quality services to customer, faster. New features may bring new clients, but reliable service retains clients; both are revenue generating. So while it may add some cost to deliver quality service to customers, cutting corners in operations risks impacting the bottom line. From this perspective, I’m arguing that DevOps shops should not only remember the ops, they should embrace it. The entire value stream of a business service includes people, procedures, and technology split into teams; the fewer the teams per service, the fewer silos. So how do we embrace the ops?

  1. If Ops is part of the Value Stream, then apply consistent Development principles to it. I’ve written before that “we are all developers“, and I believe that; administrators are creative folk, just like application developers. Operations includes backup, monitoring, and validation. We should apply development principles to these operations, like creating reusable scripts, finding opportunities for automating validation, and logging (and investigating) errors with that pipeline. We should use source control for these tools, and treat the operations pipeline like any other continuous integration project (automate your backup, automate your restores, and log inconsistencies).
  2. Include operational improvements as part of the development pipeline. I’m borrowing a lot from Google’s SRE model; SRE is what you get when you treat operations as if it’s a software problem (see point 1 above).  However, the SRE model is usually a self-contained bubble within operations; they have their own pipelines for toil reduction. I think if DevOps wants to truly embrace operations, developers need to include toil reduction in the service delivery pipeline. If operations folks have to flip 30 switches to bring an app online, development should make it a priority to reduce that (if possible). It goes back to the fundamental rule for DevOps: communicate. Help each other resolve pain points, and commit to improving everything in the value stream.
  3. Finally, balance risk and experimentation with safety. Gene Kim’s The Phoenix Project provides the Three Ways, and the Third Way is all about creating a culture that rewards risk and experimentation. This is great for developers; try something new, and if it breaks, you can deliver a fix within hours. However, as the GitLabs incident shows, some fixes can’t be delivered, and risk needs to be mitigated by secure data handling processes and procedures. While I’m a big fan of controlled failures (e.g., shutting a server down hard in order to see what the impact is), you don’t do that unless you can test it in a lab first and make sure you have good mitigating option (how do you recover? What error messages do you expect to see? Are you sure your backup systems are working?). Don’t forsake basic safety nets while promoting risk; you want competitive advantages, but you also want to stay in business.

February 3, 2017 · stuart · 2 Comments
Tags: , , , ,  · Posted in: DevOps, SQLServerPedia Syndication

5 #DevOps Books I plan to finish this year

New Year.  Resolutions, etc. 🙂

I’m notoriously bad about starting a book and never finishing it, particularly when it’s a technical book.  My goal this year is to finish the following 5 books:

The DevOps Handbook: How to Create World-Class Agility, Reliability, and Security in Technology Organizations

Gene Kim is perhaps best known for his novel “The Phoenix Project”, which lays out the fundamental precepts for DevOps.  The Handbook (by Kim, Patrick Debois, John Willis, and Jez Humble) gets great reviews, and I think it does a good job of translating theory into practice.  I’ve only finished about a third of it, so I’ve still got a lot of reading left to do, but I hope to finish it soon.

Site Reliability Engineering: How Google Runs Production Systems

This one might be a little easier to cheat on my goal; I’ve already read most of it.  It’s a collection of papers written by various SRE’s within Google, and gives some great insights into their vision of applying developmental principles to operation problems.  While it could be argued that the SRE model is distinct from DevOps, there’s enough overlap that it makes sense to apply these techniques to my DevOps study.

Level Up Your Life: How to Unlock Adventure and Happiness by Becoming the Hero of Your Own Story

This one’s a bit of a stretch for most DevOps folks, but if you think of it an approach to personal continual improvements, then it makes sense why this book belongs in a DevOps collection.  I started reading this one last year, and quickly off the bandwagon.  My goal is to try and finish it by the middle of the year, and hopefully begin to apply some of the principles to my personal and professional challenges.

The Art of Capacity Planning: Scaling Web Resources in the Cloud

I heard John Willis at DevOpsDays Nashville this year, and he recommended following and reading John Allspaw (among other people); the second edition of this book is coming out this year, so I’ll probably wait till it arrives.  While I don’t do much with either web or cloud development, the principles of scaling is relevant to all kinds of applications.

Team of Teams: New Rules of Engagement for a Complex World

Damon Edwards actually recommended this book during a webcast I saw a couple of months ago, and while it’s not a technical book, it speaks to the art of transforming a large, complex organization with entrenched policies into a nimble, responsive team.  Brownfield to greenfield (with military references).

January 11, 2017 · stuart · No Comments
Tags: , , , , , , , , ,  · Posted in: Book Reviews, Professional Development, SQLServerPedia Syndication

Geek Sync: #DevOps, the Cloud Paradigm, and the Microsoft Data Platform

I’m pleased to announce that I’ll be presenting a Geek Sync webinar (hosted by Idera) to talk about what I see as the evolution of the DBA in light of movements like DevOps and the Cloud Paradigm.  Registration’s free, so please feel free to join on January 25, 2017 at 12:00 EST.

The Future of the DBA: DevOps, the Cloud Paradigm, and the Microsoft Data Platform

We’re on the cusp of exciting times for database development and administration; data storage is set to explode in volume over the next 5 years by as much as 500%. Companies are struggling to manage traditional relational databases and several forms of Big Data, including dark, binary, and streaming data. New theories of development, administration, and data management have matured, but what impact do they have on DBA’s? What are the concepts and skills needed for future career growth? In the (paraphrased) words of Dr. Seuss:

“Oh, the places you’ll go!
You have brains in your head
And SQL Skills to boot
You’ll soar to great heights
On the Data Platform, too”

Join IDERA and Stuart R. Ainsworth as we explore how DevOps and the Cloud Paradigm have developed to address modern software delivery challenges. We’ll also examine how the Microsoft Data Platform provides a framework for career enhancement for SQL Server professionals.

Stuart Ainsworth (MA, MEd) is an IT manager working in financial information security. Over the past 20 years, he’s worked as a research analyst, a report writer, a DBA, a programmer, and a public speaking professor. He’s a chapter leader for AtlantaMDF, the SQL Server user group in Atlanta, as well as a speaker at SQLSaturdays, PASS Summit, code camps, and user groups.




January 10, 2017 · stuart · No Comments
Tags: , , ,  · Posted in: SQLServerPedia Syndication, The Social Web

My Challenges with #DevOps

As I’ve alluded to in earlier posts, my career goals have transitioned away from database development and administration into DevOps implementations; it’s been a bit of a challenge for me, because I feel like a stranger in a strange land all over again. Looking at familiar problems turned on their sides isn’t for me, and my day job has some particular challenges that I need to figure out appropriate solutions for. All of that being said, I’ve enjoyed it. However, in an attempt to help me wrap my head around things, I wanted to list out the struggles I’m facing, and include my current “solutions”; these may change over time, but it’s where I’m at today.

  1. It is what it is…

One of the challenges of describing DevOps is that it’s a conglomerate of technical and cultural changes. System and software engineers can easily understand the technical components of iterative software deployment, but it’s tough to describe the organizational and procedural changes necessary to implement a rapid deployment environment (“You want the developers on pager duty? How will they administer the system?”). Most engineers have a tough time interpreting The Phoenix Project, because it’s not a technical manual; they’re used to step-by-step guides, not cultural strategies.

My solution is to describe DevOps as a philosophy, not a methodology. Philosophies have general principles that you agree to abide by (such as seeking efficiency through automation, increasing feedback, and documenting problems without blame); methodologies are strategies for implementing philosophies. What this means is that as a manager, my method of implementing DevOps is probably different than yours, and there may even be differences within the organization; the key focus should be on reducing or eliminating silos through communication. Where those silos must remain (say, in a highly regulated environment where development and operations need to be separate), workflow in each silo needs to be as transparent as possible.

  1. Brownfield change is harder than greenfield development.

Greenfield projects are new software projects or initiatives; brownfield development is a revitalization of an existing project. While each has challenges from a DevOps perspective, the technical and cultural debt that is associated with brownfield development often slows down adoption of DevOps practices. It’s tough to maintain a system while making suggestions for improvement, particularly when multiple departments are involved, all with their own goals.

For me, it all goes back to two principles: tight focus, and increased communication. As a change agent, I need to carve out time each week to focus on one small, incremental change that I can make to increase efficiencies; for example, I’m currently working on developing a standard postmortem practice for tracking issues with our business service (using this free guide from VictorOps). The point is that I may not have opportunity to make sweeping changes, but I can do a little bit at a time (and encourage my team to do so as well).

  1. Compliance is a constraint.

Working in the financial industry brings some unique challenges to implementing DevOps; while philosophically the ideal DevOps process is to build automation pipelines from development through deployment, regulatory policies are written to dictate separation and control between environments. The thicker the wall, the more likely you are to successfully pass an audit, but those walls make it tough to attain rapid development. If your developers have one set of goals (deploy new features) and your operations team have another (keep the system stable with few changes), you’ve got to figure out a way to reconcile those.

Communication is key, and that includes have a common issue tracking system to report operational issues to development as soon as they occur; I don’t manage the developers in my business unit, so I can’t set their priorities. But I can make them aware of the pain points, and the expenses associated with those struggles. I can also find ways to make our infrastructure more predictable so that developers can develop code faster, and our QA teams can automate tests with some assurance. It’s tough, but it’s my goals.


I realize that this post may not be that insightful, but I’m looking at it as an effort to keep writing and thinking about these issues. Expect more from me in the future as I continue to try and learn something new.

December 12, 2016 · stuart · No Comments
Tags: , , , ,  · Posted in: DevOps, Professional Development, SQLServerPedia Syndication

#DevOps – Starting the path

Last week, I had the pleasure of attending my first DevOps conference (DevOpsDays Nashville), and the first conference that had absolutely nothing to do with SQL Server since graduate school. The conference was great; I met some new folks, and had some great moments of insight early on. The DevOps community is a very welcoming community, but as a relatively new explorer, I quickly got lost. The sessions ranged from culture to technology, and somewhere in between; the speakers were very casual, and to be honest, a little unstructured. It was very different than my previous experiences at tech conferences, where even professional development talks were goal-focused.

One the last day of the event, during one of the keynotes, I encountered the following tweet:

Paul Reed’s piece is interesting, because it helped me begin to form a schema around all that is DevOps; he defines the following frameworks underneath the umbrella of DevOps:

Automation and Application Lifecycle Management – basically, the tools needed to insure micro-deployments and increased time-to-market. The focus here is on Continuous IntegrationDeploymentDelivery, and Configuration Management.

Cultural Issues – Reed breaks these out into a relatively fine grain in a manner that he didn’t do with technology, but he defines three subsections of culture: Organizational Culture, Workflow, and Diversity. Each of these areas has a slightly different area of focus, but they all deal with the “soft, fuzzy, human interactions that lie just beyond the technology.” Organizational Culture can refer to breaking down silos, restructuring, and/or management & leadership. Workflow refers to the application lifecycle methodology, such as the conjunction of Agile and Lean methods.  Diversity is a focus on bringing different voices into technology, including feminist, LGBTQ, and minority perspectives.

The Indescribable – finally, Reed finishes with basically an “everything else” definition. Some organizations which have pioneered DevOps practices don’t really call them that; they’ve just organically grown their own processes to focus on efficiency, including minimizing silos and rapid delivery.

I have to admit, it helped me to reframe my perspective on various lectures using this structure; that may not be true to the spirit of DevOps itself (which de-emphasizes artificial constraints), but it’s given me some room for thought in terms of the areas I want to study and learn. The technology is interesting, but I don’t see myself working in those areas anytime soon; my real focus will be on organizational culture and workflow. As a manager, I want to increase my efficiency by building a team, and I think the path I’m on is to figure out how to push my team of system engineers and database administrators to prepare for continuous integration.

More to come.

November 16, 2016 · stuart · No Comments
Tags: , ,  · Posted in: Conferences, Professional Development, SQLServerPedia Syndication

Getting my #DevOps learn on…

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


November 7, 2016 · stuart · No Comments
Tags: ,  · Posted in: Development, Professional Development, SQLServerPedia Syndication