When embracing the change that accompanies any platform modernization project, it’s important to have a workable plan and execution strategy for cloud migrations.
Read Story
Growing up, my dad would often encourage me to focus on the small and simple things in life. It was his hope that with this knowledge I would accomplish great things. By playing, working, and socializing, the small things we learn create patterns of behavior. We are creatures of habit and the more we repeat a habit, the harder it is to break. Pair that with this age of rapid technological change, and we face the problem of what was right yesterday is not what’s best, or even close to efficient today. Old habits, once revolutionary, became outdated very quickly. We are so attached to them however, that we forget to adapt and grow.
During college, I learned the Software Development Life Cycle (SDLC) using the Waterfall Model. I found this approach organized and methodical, but it didn’t leave much room for error. This approach has been used by the tech industry for decades. For example, an app development project would be drawn out over the course of two years, with nothing released until the one-time massive implementation. This process ensured internal testing but had no practical testing in the field. As such, high numbers of bugs would occur at the time of release, overwhelming database and development teams. Customers felt very unsatisfied when the release wasn’t as flawless as planned. The process for deploying the code (app, database, and infrastructure) was manual and error-prone and did not easily transfer between individuals. Companies designed entire software suites to aid in managing the code deployment process.
As a Database Architect (DBA) with over 15 years’ experience, I have a unique perspective on change and the need to adapt. DBAs are an interesting breed; we’re smart, but many carry massive egos. In most work cultures, the DBA role is the only one stopping critical, database-dependent systems from crashing and burning, effectively taking the company down with it. Because of this responsibility, I became very good at reviewing & deploying code, architecting disaster recovery plans, and stopping developers from hurting my databases with inefficient, or even dangerous, SQL code. I felt honored, a sense of purpose, and was fulfilled by these responsibilities. All was well in my little world of command and control. However, the unintended, but natural consequence of my role lead me to slowly become the enemy of the developer, and even the whole IT industry. As our industry progressed, developers, managers, and companies wanted a faster, and less bug-prone, approach to testing and deploying code than the Waterfall Method. Developers felt blocked by DBAs and this dysfunctional relationship tended to fester for years. Developers taking shortcuts to bypass DBAs lead to even greater problems. We needed a single team with common goals and both operational and developmental expertise. Little did I know, I would be schooled and humbled in this very lesson.
Several years ago, I was approached by a gentleman my company called a “Scrum Master”. He wanted to chat about adopting a new process of giving developers permissions to push code into production themselves and allow them to introduce new database platforms other than SQL Server into our environment. He also requested that I give some of my time to attend a daily scrum meeting. It was his opinion that coupling my operational expertise with empowering developers would lead to such efficiency that nothing could stop us from accomplishing all our business and departmental goals. Surprised by his request, I dutifully replied that I could not support what he asked me to do. I had a thousand objections. What he was asking me to do violated the long-standing tenet of the DBA code of conduct: keep our production environments isolated and protected. Not to mention, and more importantly, the thought of giving away control offended and scared me. I asked myself the following questions: What value would I have if this was allowed? What damage could an unchecked developer do? There are over 400 developers and only five DBAs, how would we have the time to attend every scrum meeting? What about SOX, PCI, and HIPPA protocols? Indeed, the Bill Murray quote Ghostbusters was not that far off the mark: “Human sacrifice, dogs and cats living together…mass hysteria!”
The conversation continued, and I will admit, it became contentious. The Scrum Master viewed DBAs as controlling, close-minded, and eager to hold onto power. I viewed him as an inexperienced radical who was not only threatening the stability of our databases, but my career as well. I asked him where he received the authority to enact such a change? He told me that if I was worried about authority then this process won’t work at all. We both just stared at each other. Two people could not have communicated more poorly. We left the meeting agreeing to disagree.
Shortly after my meeting with the Scrum Master I brought his request to my manager’s attention. His response (more of a rebuke) was a career changing epiphany for me:
“Dustin, if you don’t adapt you will get left behind. Your vision is short-sighted, selfish, and you are denying your company the possibilities of running a thousand-fold more secure and efficient system by not being open to exploring this new process. The Scrum Master wants to help you, but in return needs your help as well. He needs your expertise to keep the systems secure and you need him to empower the developers to do great things.”
I hadn’t considered that my approach was incorrect, or that there was a better way. I concluded that both my expertise and the developers’ experience was valuable. We needed to work together. I began to realize how dysfunctional the communication between ops and dev were and I felt embarrassed. Together we could do fantastic things that were good for our product, the company, my career, and even the industry as a whole.
I couldn’t escape the feeling that automation was the answer. If we were going to empower developers, we needed to create a less error-prone process of deploying and managing our code and infrastructure. We needed short and measurable goals plugged into a long-term vision, that could be course-corrected along the way. We needed collaboration in order to teach each other. I decided to do some research. I googled “Information technology unity” and, after scrolling through a few pages, I found the term DevOps. I read about Pipelines, Continuous Integration/Continuous Delivery, unit testing, cloud and on-premise deployments, culture shift, automation, authority, stability, success, monitoring, PaaS, and IaaS. I was an instant convert.
It wasn’t about me anymore; it was about progress and I wanted to be a part of it because I knew this was not only good for my employer but would be fantastic for my career. But where could I start?
Read about the personal aspects of the DevOps conversion here.
Read more about my own conversion to the DevOps model here.
You hear the word “DevOps” thrown around quite a lot. It has become a buzzword which is unfortunate because the term holds significant meaning. The level of potential reduced risk coupled with developer and administrator empowerment is astounding. When a DevOps methodology has been properly implemented, egos are pushed aside, teammates learn from each other, and they create great products through measurable, clearly defined goals. DevOps nearly eliminates risk and a symbiosis occurs between the business and IT. You may feel I am waxing poetic (perhaps I am), but there is truth to this successful model.
DevOps Defined
The process of systematically breaking down the historically hindering wall that separates Ops, Dev, and business entities from their goals & each other. This is accomplished by utilizing automation, collaboration, Agile and/or Kanban methodologies, and aligning operation and development teams with the same goals on the same team
Key Differences Between the Waterfall Model and DevOps
| Metric | Waterfall/Separation | Agile/DevOps/Pipelines |
| Planning Scale | Long Term | Short Term |
| Disconnect between customer and developer | High | Low |
| Length of time between idea and implementation | Long | Short |
| Software Stability Risk | High | Low |
| Ability to respond to change quickly | Dreadfully slow | Quick |
| Project Scheduling Risk | High | Low |
| Long Term Planning Risk | High | Low |
| Developer satisfaction | Varies | Lots of wins, limited losses |
| DBA satisfaction | Extremely Stressed, tired | fulfilled, satisfied |
| Communication between Ops/Devs/Managers | Limited/Contentious/Contentious | One Team |
| Cost | High or even undefined | Lower, very well defined |
Adapting to a DevOps model isn’t always easy. But below are eight steps you can take to ease into the conversion in your own career:
- Destroy your ego
Accept that change is necessary. Fully embrace the DevOps process and commit to the ideals and the work necessary to be successful in the DevOps culture. Be willing to give up your earlier fears and be humble. - Training
Get formal training in the DevOps culture and process. Become familiar with both Agile and Kanban Methodologies. The Linux academy is a great place to start. - Lead by example
Begin to implement your own DevOps practices slowly by integrating appropriate tools and rituals into your own weekly planning process, even if this doubles your planning work. Look for the little wins in this process that begin to prove the success. Market those wins by demoing at lunch and learns. The more you get the word out the easier the shift will become for others to join you on the journey. - Start Building Automation (on your own time if you must)
Build a working pipeline that incorporates automation of a manual process that will be a huge time saver for the team. You may have some Late nights, but the power that comes with this is unmatched. Prove why it works, demonstrate why it is the only way. This is the quickest way to convince someone that automation holds value - Build a coalition
Seek out likeminded people within your organization (in both dev and operations teams) who will help you support and implement DevOps. - Seek out Sponsorship
If possible, engage managers or other respected authority figures in your organization who will support a cultural shift. Hold meetings and be open about it. (Yes, be that person). Get people on the same page and provide data to show the efficiency. - Put it all on the line
Go against the grain. Unfortunately, there may be times you need to put your reputation on the line and push harder than you feel comfortable to promote the cultural shift. Amazing progress only comes through perseverance. - Faith
Along this journey have faith that a great prize is waiting for you and your team at the end of the initial conversion. The end result will be a more stable product, better relationships between coworkers (across all teams), and more job satisfaction. You will sleep better knowing this process in place.
The change curve is real and can be a horrible hump to overcome, but when you see the first signs of efficiency, it fuels you for the next obstacle. DevOps requires faith in the journey as the rewards only come after some pain is felt. As with all things taken on faith you can’t see the benefit until you can reap the rewards of your hard work.
Read more about the DevOps conversion and what it means for businesses here.
Personal changes and mental shifts aren’t the only changes that need to happen in order to convert to an IT DevOps Model. There are serious business adjustments that need to be made as part of this process. Admittedly, this process starts out overwhelming (the change curve is real), but you will get there, I promise. And you’ll never look back once established. The following five obstacles are most common you’ll encounter on your journey to a full DevOps implementation.
- Denial
As demonstrated in my previous posts, you need to undergo an epiphany, realizing that things need to change. Allow others to go through this process as well; it will take time because change is fundamentally hard. You will encounter strange obstacles such as fear, pride, laziness, and even depression. Remember, people have worked their entire careers supporting the Waterfall Method and you’re asking them to give up something that pays the bills and defines their career. - Automation Ridiculousness
Get your teams used to the idea that the first two questions they should always ask themselves when presented with a new task is “Can this be automated?” and “Should this be automated?”. Most DBAs thrive on manual work, so this may be a big change for them. Invest in developing your automation processes but guard against the isolation of the experience wherever possible. Try not to isolate the DevOps experience to a new team, instead start with an existing team. As time goes on make a soft requirement to only allow the creation of an automated process when it is attached to a deliverable (customer request). Your Product Owners can help with this. It keeps eyes on the prize and avoids wasted efforts as well as measurable results. - DevOps Isolation:
- A New DevOps Team
A select group of people (we will call them the enlightened ones) will go off and create DevOps in their own make-shift team, effectively increasing the isolation from both Ops & Dev departments. Don’t worry, this is natural. The trick is to not let it go too far, avoiding an even larger isolation problem. Guide the team in choosing a real project with a real deliverable and integrate with an existing team as quickly as possible. There may be a need to develop an automation framework, but don’t let this take too long before integrating with a real team. - Does Operations Provide Value?
This is the most dangerous obstacle. Developers realize they are empowered and create some neat automated processes. They create a pipeline that builds every component from the infrastructure all the way through to the software deploy. Everything is scripted, and it works. This is where we may need to fight off a bit of ego. Make no mistake: Sr. DBAs, network engineers, and application engineers are worth their weight in gold when the fires come. They are critical to include on the DevOps team. - Reinvent
Changing titles is a place to start, but that’s just the beginning. Your operations people should be called DevOps engineers. This is where the culture can really change. As an example, teaming the ops team with dev team in a new agile process is a great way to get their feet wet. Offer training to your admins on scripting and best development practices. They will feel empowered when they can speak the same language as the devs. Tell your devs they need to rely on the operational expertise of the admins. Have the team focus on what each person does best. Encourage cross-team training to understand the entire pipeline, and your overall system stability will sing.
- A New DevOps Team
- Departmental Transformation
At this point we have grown up quite a bit. We have some wins under our belt. Upper management is actively noticing less bugs and quicker release times, and the overall stability of IT is better than it’s ever been. Build on this progress by re-questioning everything you’ve done so far. This is a good opportunity to destroy your ego once again. It will be easier this time, I promise. Bring in a couple of new Sr DevOps engineers and allow them to question everything. What is working? What isn’t? What are the time wasters? How can we take this to the next level? Is all of IT included in our process? How can we get everyone involved? - Natural Consequence: A High Performing Organization
This is the fun part. You can now deploy, often with minimal risk, across multiple stacks. Bug changes can be fixed in a matter of hours, rather than months. Teams are focusing on what they enjoy, and operational knowledge is freely shared with developers and vice versa. Executives embrace the stability of the IT department, and your team and processes are being recognized at company townhall meetings. Your department now laughs at the thought of going back to the previous structure.
Seeking advice and education along the way is imperative to long term success. The key to success is faith in the process and allowing it to work itself out over time. The natural consequences of the DevOps journey are worth the effort. Keep in mind that DevOps is not the same for any two organizations. Each culture will adapt to create their own unique process. As long as your team follows the fundamental principles, the end result will be increased efficiency, overall personal and team satisfaction, happier customers, and company-wide wealth creation. DevOps is truly the greatest management tool to ever hit information technology.
The most rewarding conversations are found in discussing failures and successes. For it is only out of failure that we truly grow. Contact Fortified Data to help you and your organization reach your DevOps goals.
Lastest Stories
MySpace – an unfortunate disaster recovery failure
Learn our thoughts surrounding the technical and business lessons of this story, but more importantly, how your company can avoid this kind of press.
Read Story
DevOps and the Spiritual Awakening
Growing up, my dad would often encourage me to focus on the small and simple things in life. It was his hope that with this knowledge I would accomplish great things. By playing, working, and socializing, the small things we learn create patterns of behavior. We are creatures of habit and the more we repeat […]
Read Story
The Personal DevOps Conversion
Read more about my own conversion to the DevOps model here. You hear the word “DevOps” thrown around quite a lot. It has become a buzzword which is unfortunate because the term holds significant meaning. The level of potential reduced risk coupled with developer and administrator empowerment is astounding. When a DevOps methodology has been […]
Read Story
The Business DevOps Conversion
Personal changes and mental shifts aren’t the only changes that need to happen in order to convert to an IT DevOps Model. There are serious business adjustments that need to be made as part of this process. Admittedly, this process starts out overwhelming (the change curve is real), but you will get there, I promise. […]
Read Story
Fortified Data makes Inc.’s 5000 Most Inspiring Companies 2018
We are excited to make Inc.’s 5000 most inspiring companies for 2018 with 405% growth over the last three years. To us this showcases how our model of results-driven managed services can result in real success. Fortified Data’s team approaches managed services as a partnership, pairing a strong methodology with a commitment to transparent reporting. We […]
Read Story
SQL Server Service Broker—Security
There are 2 types of security in Service Broker: dialog and transport. Dialog security establishes a secure, authenticated connection between Service Broker Services or dialog endpoints.
Read Story
SQL Server Service Broker—Sending & Receiving
Service Broker uses TCP/IP to communicate with other Service Broker services on the network.
Read Story
SQL Server Service Broker—Internal Activation
The other way to automate this stored procedure is by attaching it to the queue itself so that it Service Broker directly executes the procedure in a process called activation. With activation Service Broker starts an application whenever there is work to do (e.g. when messages are in the queue).
Read Story