Professional Development

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

2017-10-18 by Conferences DevOps Professional Development SQLServerPedia Syndication 0

Changes… #DevOps, #SRE, and #Management

As many of you know, I’ve been slowly changing focus from database administration to DevOps, management, and service operations. Over the last few years, I’ve been heavily involved with migrating our datacenter to a private cloud infrastructure, and focusing on methods to improve the overall reliability and scalability of my company’s service deliverables. I’ve been a bit of an evangelist for organizational changes, and it’s finally official.

On October 1, my job title and responsibilities will officially change from Manager of Database Administration to Senior Manager, System and Network Administration. I think that title’s a bit funny, because I won’t be managing system or networks; our infrastructure is managed by another team, and my team is responsible for applying principles of Site Reliability Engineering to operating our complex business services. Unofficially, we’re calling ourselves Service Reliability Engineering in order to remind ourselves (and others) of our foci:

  • Identifying issues that impact the reliability of customer facing services;
  • Tracking and documenting complex relationships between applications used in that delivery; and
  • Coordinating efforts with other teams responsible for developing and operating those services

The title change itself is a minor issue, but it’s an important distinction to me. It represents a significant shift in my career path. Although I’ve been acting as the IT Operations manager for the last two years, it’s always felt a little odd because I was still known as the DBA manager. With the move to the cloud, most of our administration (like backups, DR, and maintenance) are handled by another group, and we’re responsible for making sure that the applications (all 84 of them) perform appropriately. We’re not coders, but we need to be able to identify coding issues. We’re not network or sys admins, but we need to know how systems work, and be able to propose solutions to scalability issues. We’re not DBA’s, but we need to be able to express data requirements to the new DBA team. In short, we’re an integration point for a loosely coupled set of applications.

I plan to blog more on Service Reliability Engineering in the future, but for now, I’m excited about what’s happening.

2017-09-29 by Professional Development 0

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

2017-08-21 by Blogging is FUN! DevOps Professional Development SQLServerPedia Syndication 0

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.

2017-08-11 by Professional Development SQLServerPedia Syndication The Social Web 0

The DBA is dead; long live the DBA!

Been reading some interesting arguments over the future of DBA jobs lately, and as usual, I find a lot of truth somewhere in the middle. Let me try to sum up the positions of the three authors that impressed me the most:

Thomas LaRock – Why I’m Learning Data Science:

Tom kind of kicked off this discussion with his post; the three main takeaways I got from it are:

  • The traditional role of the DBA is being automated away, right in front of our keyboards.
  • As computers get better about self-tuning, it will be difficult to justify the expenditure of a dedicated database administrator
  • Computers are only good at providing answers; humans are good at asking questions.

Brent Ozar – Twitter Posts

Brent responded via twitter to “a couple of emails” stating that “the DBA career has a time bomb”. The three key points I got out of the thread are:

  • The tools are getting better, but the problems are getting harder.
  • SQL Server still ships with some legacy baggage that require hands-on experience to adjust; if computers were smart, why hasn’t that been fixed?
  • Even as the technology gets better, adoption is slow.

Grant Fritchey – There Is A Magic Button, A Rant

Grant took the humorous route, telling the tale of the “Run Really Fast” button that all database administrators know about once they achieve a certain level of competence.

  • Tools are getting better, but they can’t fix problems with design (both software and hardware).
  • Automation can reduce drudgery, but design is fundamental.
  • DBA’s are all secret alchemists.

Where I sit…

All three of these guys are smart folks that I respect a lot, and honestly, I see a lot of truth in what they’re all saying. The tools ARE getting better, and I do believe that automation is going to significantly change a lot of different jobs in IT, including database administrators. The role of a DBA is particularly susceptible to this because of the hybrid nature of the work. There’s elements of design (system and software), development, and operations associated with that role, and the stack is getting increasingly complicated. The Microsoft Data Platform now sits over relational and non-relation data, and encompasses analytics, visualization, reporting, integration services, high availability, disaster recovery, and much more. The stack is getting too complicated for the average DBA to be a master of all of it.  However, it’s hard to deny the necessity of expertise, particularly with all of the technical debt associated with a product like SQL Server.

But what if we sliced the stack differently?

The cloud paradigm talks about breaking the computing stack up into various services, each acting as a black box to the level above it; Software as a Service is built on top of a Platform as a Service, which in turn is built on top of an Infrastructure as a Service. As enterprises begin to embrace the cloud, they will reorganize resources along these lines. Why? Because it lays the foundation for consolidating resources where it counts, and allows for future portability. In other words, companies can start at the bottom of the stack, and port their Platform and Software services over to cloud providers without significant alteration of those upper level. Likewise, as technology matures, migrating the Software layer to a new Platform provider will get easier over time (we’re not there yet, but it’s coming).

I would argue that the current role of database administration straddles the line between software and platform; traditional maintenance and server configuration task are part of the Platform layer, and database design are part of the Software layer. The term DBA will mean multiple things to multiple people, depending on where that role sits along this divide. In other words, a DBA that works at the Software layer will tend to focus on questions of database design, data software performance tuning, and architectural issues associated with the ever expanding set of options for databases beyond just the relational db. DBA’s at this layer need to become full-fledged member of the development team, which may eventually lead to a fuzzier distinction between application and database developers. DBA’s at this layer will need to be well-versed in the concepts of multiple data management technologies (and possibly other development technologies). Opportunities should abound here, but diversity should be valued over full-stack mastery of a single product.

DBA’s at the Platform level will change roles as well; they’ll no longer need to be steward of data, or responsible for tuning bad code. Their job will be to make the Platform support contracted levels of performance, and identify and correct resource utilization and configuration issues. Automation will have a huge impact here; Platform DBA’s will be responsible for supporting multiple instances of SQL Server, including support for high availability and disaster recovery. Scripting skills are highly desirable, as is mastery knowledge of specific products. I would expect job opportunities to slow in this area, but experts will still be needed in the future.

In short, I don’t think the role of a DBA is going away, but I do think that it’s going to split. That’s exciting, because it means that people have options.  We still need experts, and there will still be opportunities for folks who love data to find meaningful work; their expertise will just become part of a different structure than we’re accustomed to now.

Now, where’d I put that Philosopher’s Stone?

2017-08-04 by DevOps Professional Development SQLServerPedia Syndication 3

#DevOpsDays & #SQLSaturdays

I’ve been meaning to write this post for a while, but life rolls on, as it always does. I had the privilege of attending DevOpsDays Atlanta back in April. This was my second DevOpDays event to attend (the first being Nashville), and overall, I’ve enjoyed the events. However, as a long-time organizer and speaker with the SQL Saturday events, it’s hard for me not to compare my experiences between the two conferences. They’re both community-run, low-cost, voluntary technical events; however, there were some things that I really like about the DevOpsDays format (and some things I wish were different).

Cost

The cost models of the two conferences are different; in short, SQLSaturday’s are free to the attendees (although a lunch fee is usually provided as an optional service), and DevOpsDays charges a small fee ($99-$150). Both rely on sponsors to pick up the tab for the bulk of the expenses (usually location fees). Speakers are volunteers, as well as event management staff. The benefit for the attendee is guaranteed swag (an event t-shirt is typical) and a great lunch (food was fantastic at DevOpsDaysAtlanta).

Charging a higher fee does a couple of things; it allows organizers to get a more accurate attendance estimate; if an attendee pays more to go to a conference, it’s more likely that they’ll show up. This has a trickle effect on luring sponsors; it’s easier to justify sponsoring an event if you know that you’re going to get a certain amount of foot traffic. A fee also guarantees amenities that are important to technical folk; good Wifi, and livestreams (although sessions weren’t recorded at the Atlanta DevOpsDays event). You can also direct some of those funds to getting a premier meeting space.

On the other hand, a free event with a nominal lunch has the potential of bringing in a much larger audience; DevOpsDays Atlanta was hosted in a 230-seat theatre, so attendance was probably around 250 (with standing room, vendors, and speakers). Last year’s Atlanta SQL Saturday had over 600 attendees, and this year’s event had slightly over 500 attendees. Attendance counts shouldn’t be considered a metric of superiority, but it does provide a different incentive for pursuing sponsors. As an attendee, I like the SQLSaturday model; as an organizer, I like the DevOpsDays model.

Parent Organization Involvement

DevOpsDays is a highly decentralized model (true to the agile underpinnings of the movement). The parent organization appears (from the outside) to be very hands off; local event organizers handle their own sponsorships, registration, and other details. This allows for a lot of fluidity when it comes to branding, networking, etc. For example, see the differences in advertising logos for the DevOpsDays organization, the Atlanta 2017 event, and the upcoming Nashville 2017 event:

DEVOPSDAYS (GENERIC) ATLANTA 2017 NASHVILLE 2017

In contrast, PASS (the Professional Association for SQL Server) retains tight control over the marketing of SQLSaturday; registrations and event planning are handled by their internally-developed tools, and the branding has recently evolved to provide a more consistent association with the parent organization (although not without some concerns).

PASS LOGO SQLSATURDAY LOGO

From an attendee perspective, branding probably doesn’t make much of a difference; however, the tools used for registration are highly visible. Both DevOpsDays events I attended used EventBrite, a well know tool for managing, well, events. SQLSaturday relies on a custom registration site that has improved over time, but still often leaves attendees confused (despite all the best guidance from organizers). Furthermore, if a SQLSaturday event has a precon, those events are usually managed by EventBrite, which leads to an additional disconnect between the precon event and the actual SQLSaturday. Despite my love for SQLSaturdays, I think the DevOpsDays approach to branding and tooling is better.

Educational Delivery Format

One area that SQLSaturday feels more comfortable to me is the format of the sessions. SQLSaturdays typically follow the traditional multi-track model in a single day (not counting pre-cons), where attendees can choose from multiple sessions at the same time; for example, SQLSaturday Atlanta 2017 had 10 concurrent tracks, each with sessions lasting about an hour. Note that this format is not required; smaller events may only have a single track, or have multiple tracks with longer sessions.

In contrast, the DevOpsDays standard of delivery is multiple days, with a single track in the morning of longer talks, followed by a single-track of short talks (“Ignites“), and then open-space sessions in the afternoon. For me, this is a mixed bag of effectiveness; bringing everyone in the conference together to hear the same discussion can (in theory) promote better cross-communication between the various stakeholders in the DevOps audience. For example, having managers and deployment specialists hear a programmer discussing pipelines may promote perspective-taking, one of the fundamentals of good communication. In reality, however, my experience has been that many presenters don’t do a great job of relating to all of the stakeholders in the audience, making it difficult to bridge that gap. Granted, I’ve only been to two events, but of the 16 main talks that I heard across the two events, about half of them seemed relevant to me. Ignites have some of the same limitations, but the time constraints mean that they hold attention spans for longer.

Most people either love or hate open spaces; letting the audience drive discussions is a great concept in theory; in reality, discussions are typically dominated by a few extroverts in the group, and most people merely observe. Although there are usually self-appointed moderators, the dynamic selection of topics just prior to the discussion makes it difficult to engage or guide. When they work, they work well; however, too often open spaces lend themselves to the seven-minute lull Ideally, I think the most effective method of delivery would be a blended approach; a couple of keynote sessions in the morning, followed by a few Ignite sessions. Do multiple tracks in the afternoon, including open-space discussion, both free-form and guided. However, this is mostly a matter of personal preference; I’d love to try it and see what people think of it.

Conclusion

I’m enjoying the transition of my career away from being a SQL Person to a DevOps person; both communities seem vibrant and engaged, and I plan on attending more DevOpsDays conferences in the future (and perhaps even help with planning one). Events like these offer a lot of opportunity to learn high-quality material in a low-cost setting, and I only expect them to get better (or I’ll get better) over time.

2017-07-27 by DevOps Professional Development SQLServerPedia Syndication 0

#FAIL

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.

Summary

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

2017-06-08 by Professional Development SQLServerPedia Syndication 1

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.

Experiences

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.

Beliefs

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

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.

Circumstances

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.

2017-05-08 by Professional Development SQLServerPedia Syndication 0

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).
2017-01-11 by Book Reviews Professional Development SQLServerPedia Syndication 0

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.

Summary

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.

2016-12-12 by DevOps Professional Development SQLServerPedia Syndication 0