devopsy.kinsta.cloud

Tag: devops

Awkward questions for those getting started with automation
This blog asking awkward questions for folks jumping on the microservices bandwagon was enlightening from the perspective that many of the same questions are applicable to operations as they begin to tackle operationalizing all the things in an application lifecycle.

For example: “What is your deployable unit?”

Great question, isn’t it? What is your deployable unit of automation? Is it per service? Per device? Per cluster of devices? Per container?

Wait, but there’s more from this great list of awkward questions:

Is it acceptable for another team to take your code and spin up another instance of your microservice?

Can team A use team B’s microservice or are they only used within rather than between teams?

Do you have consumer contacts for your microservices or is it the consumer’s responsibility to keep up with the changes to your API?

Is each microservice a snowflake or are there common conventions?

How are these conventions enforced?

How are these conventions documented?

What’s involved in supporting these conventions?

Are there common libraries that help with supporting these conventions?

All these questions are applicable to devops, in particular, as you go about building out automated scripts, systems and orchestrating processes that operationalize the data center and make it a lean, green deployment machine.

You are going to have some kind of code, whether it’s a script or a recipe or a template of some kind, and questions regarding the usage of that code is important. Can others use it? Change it? Claim it as their own? Are they useful in a general, “here’s a basic load balancing provisioning and configuration script” or are they specific, as in “this is a piece of code that provisions and configures the networking required to ensure all 18 tiers of this very specific application can communicate”?

And as you’re developing those scripts (that code) are you documenting it? Are there <gasp> comments? Do you use a standard convention for code formatting (cause let me tell you, where you place your brackets is a matter of great technical religious significance)?

Most of those jumping into automation head first aren’t thinking of the long term ramifications of the choices they are making right now. Proof of concepts turn into pilots that turn into systems upon which all of IT relies. Rarely are you given the opportunity to go back and put any kind of standard conventions or practices into place. That’s what builds technical debt in software and, no matter what you think you’re building with those scripts, you’re building software.

Adopting the technical and methodological practices of agile development is a good thing, but let’s not ignore that along the way from waterfall to agile developers have learned a lot of lessons the hard way. That means we should, as practitioners of software-related activities within operations (and that means any one of the four operations groups in IT), pay attention to those lessons and try to avoid the pitfalls that developers have already encountered and, one hopes, overcome.

To do that, don’t just ask the awkward questions; answer them.
January 7, 2015
Top Skills for Enterprise DevOps
There is one question I hear almost every time I talk with my large enterprise customers about DevOps:
1. What skills do my people need to be successful with DevOps?
Talk of DevOps almost immediately focuses on culture – like having empathy for fellow workers, being flexible and adaptable, seeking continuous improvement, building relationships, etc. However, while critically important in DevOps, culture is an outcome, not an input; and such attributes are mostly either innate or acquired slowly. Culture cannot easily be taught.

At the other end of the spectrum, we often look at technologies – agile development, coding languages, virtualization/cloud platforms, management tools, etc. Again, these can be important, but while learning these skills might make you a better dev or op, they may not make you a DevOps practitioner.

Like most transformations, DevOps will need new people, process and technology skills, so in this post I take a look at a handful of the most important, pragmatic, and trainable skills in all three areas for practitioners looking to adopt DevOps, especially in large and more complex organizations.

People Skills
- Communication skills – while this may not come easily to typically introverted IT staff, both written and verbal communications, within and across the organization, and even with customers, are essential to a strong DevOps approach. This skill is learnable from formal courses, groups like Toastmasters, direct mentoring, social activities, or informal sessions like ‘lunch and learn.’ For extra credit, jump on stage for open mic night at a local comedy club!
- Business alignment – much of a dev or ops life is spent embedded in the technology of software delivery, rather than the business need. This can cause many issues, and is something DevOps tries to address. Understanding the business strategy, goals and priorities is essential to DevOps, helps drive and easily trainable. A ‘big picture view’ helps everyone collaborate on common objectives to deliver high-value business outcomes – a key tenet of DevOps
- Workplace history – “an appreciation for history, both technical and organizational”* will help staff understand the critical antecedents of DevOps, so they can internalize its principles not just rote learn its actions. For example, understanding hierarchical and network structures, why we adopted open work environments (and why it hasn’t always worked), and the antecedents of DevOps in things like The Toyota Way will help staff not just to act predictably in known circumstances, but adapt appropriately to new ones. (*Thanks to @garethr for input on this!)
Process Skills
- Agile development – it may be possible to take a DevOps approach in a waterfall environment, but it is almost definitely less effective. DevOps arose out of the Agile movement, and they pair so well that it is sometimes referred to as ‘agile for infrastructure.’ Teaching on one or more specific agile approaches (Scrum, Kanban, Kaizen, etc.) will give staff an approach and mindset informed by agile practices to help teams work together to improve flow, delivery and quality
- Lean approaches – ‘lean’ theories born in the manufacturing world (see ‘history’ above) give a pragmatic foundation for applied DevOps, not just new-age ideals. Concepts like Just-In-Time, Toyota Production System, Design for Manufacture, Theories of Constraint and Waste can be learned from original texts, courseware and many business courses. Some are also revised in modern IT-specific texts like The Phoenix Project or Implementing Lean Software Development
- Process reengineering – DevOps is as much about refining and improving ‘flow’ in the SDLC as it is about encouraging a sharing culture, so classic learning about how to effect change in business processes is invaluable to early stage DevOps adoption. Understanding how and why to analyze needs, identify problems, and effect change in software processes, organizational structures, teaming etc. is essential to DevOps and a long-established body of knowledge
Technology Skills
- Coding/scripting – in its current iteration there is a lot of focus on helping operators to understand coding languages; and teaching developers to use script-driven operations tools. From JavaScript (eek!) to C# or .NET, any coding or scripting skills will help both dev and ops to have empathy for each other’s jobs, and help to develop the elusive ‘T-shaped people’ that are so well-suited to a DevOps approach
- IT Automation – Enterprise DevOps especially will likely involve (require?) a raft of technologies in an automated tool chain. Because DevOps is concerned with end-to-end flow, such skills need to cover the whole SDLC. Look to provide training in Portfolio Management, Agile Project Management, Source Code Management, Version Control, Test Automation, Test Data Management, Service Virtualization, Continuous Integration, Release Automation, Cloud Provisioning, Configuration Management, Process Automation, Performance Monitoring and Event Management, whether through formal training or informal knowledge transfer
- Workflow mapping – smaller organizations might get away with pen and paper, or even a whiteboard/flipchart, but to document, share, analyze and rationalize the SDLC for large, complex, enterprise applications, you will need to learn to use workflow mapping tools. This will allow team members across the org (and the world) to take ownership of the end-to-end process, and start to collaborate on continual improvement
This is of course a (very) short list, but should give you a starting point for developing essential skills for enterprise DevOps practitioners. As always, please feel free to drop a comment and tell me what I missed, what is more important, or even what I got wrong. I am always interested in discussing ideas and learning new things!
January 5, 2015
Tips to change culture (at least in your team).

DevOps is all about automation, enhancing the Application Lifecycle Management and culture change. In the last few years there have been tons of conferences and articles about the benefits of a cultural change on a project, but I have yet to read a paper about how to actually change culture.

How do you manage to get people to change the way they think and act towards each other and professionally? This is a huge challenge that most DevOps leads will have to overcome. Here are some of my ideas.

Create cohesion.

The first thing to keep in mind when trying to implement DevOps (or on any other kind of project for that matter) is that people who don’t have fun at work will not perform as good as they could. How to make people happy to go to work is up to you, but I find that simple activities such as team exercises and/or after-work beer work best.

Whenever a new member comes to a team, try to get everyone together to have fun and talk. Take them out to a game of laser tag, get some sumo suits and make people try wrestling amongst other sports. Try to identify a common interest for a sport and have everyone play together. Remember, this is not a competition, do not force people to participate if they don’t feel like it. There are neither losers nor winners, so try to balance the teams as well as you can.

Another way to get people to know each other and ease potential tension is to take people out. Take your team out to discover a new restaurant or pub and discuss the place together, what they would have changed in the decoration, which Belgium beer is missing from the menu, why on earth do they serve foie gras on a scallop… The point once again is to try to discover others’ interests and behavior outside of work. This specific activity however needs some rules; try to limit the alcohol intake and by all means – do not talk about religions or politics. While those two topics can be fascinating with your friends, some people might get offended, even if they say they don’t mind.

Back on the project, the use of Scrum is highly recommended. Even though the benefits are debatable, I find that shy people tend to open up and contribute more during those sessions than they normally would. On top of that, Scrum meetings include everyone on the ladder, from bottom to top. Only one rule here: no matter what, remember to actually do your daily stand-up, if you can’t do it personally, get one of you team members to conduct it and check afterwards that is has been done. Delegating is not a sign of weakness; it just shows trust in your team.

Create incentive.

People make mistakes, always. There are, however, ways to get to get people to make fewer of them. Pointing fingers and blaming people is definitely not a solution. Making people pay for their mistakes is more efficient. Say each team member has to pay 50 cents (adapt to your own country and project) for every mistake (new bugs, fail in commit, forgot to write a comment in SVN/Git at commit…) they make, and things might start to change. The point here is not to rob your employees, so you will have to find a creative way to use that money. You could for example gather that money at the end of the month to buy candies for everyone. But then that’s just punishing people, which does not make it fun, so you have to come up with a way to compensate for that too. If the management doubles every penny in game, then everyone is involved and there starts to be some interest. But then again, you might get extra bugs because everyone loves candies, so you could triple the sum of gathered money when there are fewer problems than the previous month.

At that point of reading, you might think it’s actually costly and doesn’t benefit anyone except dentists. Well you’re wrong. In the worst case scenario we’re talking about tens of dollars a month, and given that you will actually get some accurate metrics about this, this is a no-brainer.

If candies are not popular in your project (is that possible?), you can also get the good old “employee of the month” award to whomever created the least problems and reward him/her with cinema/theater tickets, a dinner for two… Please note that on high stress periods, dinners for two, even though a lot more expensive than regular rewards, are a lot more appreciated as they might represent a good opportunity to ease work related tension in a couple.

Develop people.

Don’t see your colleagues, especially the young ones as just resources, rather think of them as potential wonders. Everyone aspires to shine and it’s all up to you to make it happen. Do not ever take someone else’s ideas and get the glory. That would be idiotic, mean and potentially a good way to get your colleagues to quit or resent you. Instead, go on, try to encourage people to speak up, make them give technical presentations, make them speak and give them a positive feedback (even on failures, there are always good ways to explain how one can improve).

Once again, Scrum can help you with that. Identify the elements in your team who need some help and pair them with some others that are more comfortable for some small sessions of peer-programming, peer-presenting, peer-testing… once a week. It can cost some time in the beginning but the benefits are potentially huge in a long term perspective. There is nothing better than a team that has learned to work together and where the first reflex when someone ask for help is to actually help, not to ignore.

Demonstrate values.

One of the things that really is important to remember, is where you come from. No matter your position today, you didn’t start at the top and you’ve had to learn all the values that you try to get your team to demonstrate today. So show them every day, what it means to create DevOps; a potentially highly stressful job, especially in the beginning, where tension between people should not exist. Smile as much as you can, take time to help others even if you that means staying later at night, be proactive once again, try to identify potential bombs and defuse them before they are seen by others. All in all, be nice to others, treat them as you would like them to treat you.

But what if you are faced with a pigheaded team member? Someone who is convinced they are right, no matter how many people disagree? Well once again, do not ignore them; that will only create frustration. Instead, get some documentation or an expert and talk openly about the topic without being aggressive. In the end, the team member should be respectful of your efforts and have won some valuable knowledge in the process.

The biggest piece of advice I have is this: Do not ever be arrogant, do not ever be pompous. Help others, always, and do it nicely and in a humble way. The leaders we like are not the ones that talk too much but the ones that are the nicest to work with.

Changing a culture on a project is a tough thing, but it can be done with a few tricks and a lot of time spent helping others. Luckily, smiles and good atmosphere have a tendency to spread fast and the tight links between Dev and Ops can be strengthened quite fast with some goodwill.

December 11, 2014
You Might Already be Doing DevOps in the Software-Defined Data Center
I was out reading the Internet and came across a report from EMA (Enterprise Management Associates) regarding the state of the Software-Defined Data Center (SDDC) in 2014. After perusing the data and highlights, I was surprised (and yet should not have been) to find so much DevOps-related content and concepts within. Neither should I have been surprised to find significant mention of software-defined networking (SDN). It makes sense, in a puzzle-fitting-together kind of way, that SDDC comprises software-defined operations and software-defined networks (and probably software-defined storage but it’s too early in the day for me to contemplate that).

In any case, a significant percentage of organizations take advantage (today) of software-defined operations and networking, based on the report:

Which of the following technologies, structures or processes does your organization take advantage of?

4. Cross-functional processes to orchestrate provisioning and management of storage, network and server resources (57%)
5. Solution for server administrators to provision their own storage volumes (56%)
6. Continuous/centralized capacity management for physical, virtual and cloud resources (55%)
9. Policy-based automation of infrastructure for routine adjustments without human intervention (50%)
10. Software Defined Networking (virtual overlay network) (48%)
11. Software Defined Networking (separated control plane from delivery plane) (46%)
13. APIs for developers to provision their own app environments (servers, network and storage) (42%)
14. Configuration management solutions (Puppet, Opscode Chef, SaltStack, ServiceMesh, etc.) (41%)

More telling, perhaps, of how critical DevOps is to enabling the SDDC is the emphasis put on not just automation but on process. When asked what respondents believed were the “most important aspects of the Software Defined Data Center”, number 2 and 3 focused on deployment and automation of applications and infrastructure:

Best-practice, repeatable configurations of software and infrastructure for workload deployment (46%)

Orchestration and automation to easily deploy applications across silos (44%)

In case you weren’t entirely convinced, yet, “operational analytics” (we might call it “measurement” or “metrics” here in DevOps land) came in number four with a respectable 42% of respondents.

There’s more in the report, some less relevant but for the most part, reading this SDDC report left me with a decidedly DevOps after taste. Which was kind of a minty chocolate coffee taste, in case you were wondering.

The concepts typically associated with DevOps are not necessarily peculiar to DevOps or SDN. They’re generally part of a larger trend to operationalize all the things: the network, the storage, the compute, the security. The business goals of SDDC are strikingly similar to those promoted by DevOps and SDN – reducing risk, lowering opex, improving stability and time to market. The collaboration through creation of interfaces designed to promote repeatable, consistent (and measurable) handoffs between groups is present and looms as large in SDDC as it does in DevOps.

The point is that DevOps may, in fact, be in the adoption process right now under the guise of another name in an organization near you – or around you. If you hear someone saying software-defined something, check it out. You may be surprised to find out that someone has snuck in DevOps through another door, under a different name.
December 10, 2014
DevOps Sometimes Means Kill It Before Fixing It
The public attention for DevOps is having a very positive effect on many areas of IT with regard to improving their ability to deliver for the business. Yet, I see little attention being paid to an integral part of this desire to change, which is to assess and baseline the current approach and then strategically select those areas where attention needs to be paid. Alternatively stated, many DevOps efforts are focused on improving current approaches without even determining if the current approach is appropriate for the business.

In their book, “The Lean Mindset: Ask the Right Questions,” the authors question the focus on productivity as an aspect of implementing lean or agile methods. This comes up quite often in discussion with customers regarding DevOps adoption. There’s a misconception that becoming more productive is the way to fulfill demand from the business. But productivity is not the right question or answer. Regardless how you approach the problem domain lack of infinite resources—money, time and people—the demand will typically exceed the ability to fulfill.

The way for IT to help the business achieve agility is to deliver the right set of features at the right time, which means the first step has to be looking at what you’re doing today and being willing to stop spending time and effort where there is minimal value or gain. The authors of “The Lean Mindset” have some interesting anecdotes around the realities surrounding this in enterprise settings.
- Politics – one company decided to financially incent development management to deliver agreed upon features on a behind schedule project even though it meant that testing would suffer and the final product would be unreliable. When later asked if they could have reduced the feature set and delivered fewer high-quality features, the team stated that it could have been done as less than 50% of the features were being used in the final deliverable anyway. The politics of delivering what was agreed upon was more important than delivering fewer high-quality features.
- Can’t Say No! – many IT executives find it difficult to push back on the business and, hence, end up attempting to deliver all that is already on their plate plus new requests that arise during the year. In many cases, much of what is already on their plate is no longer needed or provides minimal value to the business. Without a system of measurement around cost to deliver versus value delivered, IT cannot justify to the business the need to shift resources elsewhere to ensure optimal value.
For these reasons, among others, any attempt at DevOps needs to start with an understanding for where resources are being applied today and where they should be applied in the future. Doing useless stuff faster doesn’t help IT and it doesn’t help the business. It’s also why IT/Business alignment is a critical part of any DevOps adoption strategy. IT needs to work with the business in an open manner to select the most important features, capabilities, systems, etc. that will deliver value for the business. This also means IT is responsible for instituting the necessary systems to measure resource consumption and provide the business with the necessary data for them to make intelligent choices about where they want to spend their IT capital.

There’s a great Peter Drucker quote in the book, “There is nothing quite so useless as doing with great efficiency something that should not be done at all.” So, if your IT Operations team spends six weeks automating deployment for a system that really should have been sunset, that’s six weeks lost that could have been better spent on a more business critical function. Of note, this is not the IT Operations’ fault. If that system is not going to be sunset and has been the bane of their existence consuming time due to outages, then they have driven improvement. The failure is on IT management and the business having not taken the necessary steps to allow these resources to be focused on more important initiatives once again illustrating the importance of executive sponsorship for DevOps initiatives prior to tooling, automation, process improvement or organizational shifts.
December 4, 2014
DevOps: What It is and How to Cook It

What is DevOps?

DevOps is a funny concept.I have spent the last few months trying to find an accurate explanation of what it is, reading books, articles and participating in discussions which led me to the following personal definition: DevOps is a set of processes which aims to enhance the Application Lifecycle Management (ALM) of an Agile project by creating tighter links between the different actors (Developers, Operations and testers) through the use of automation and communication. Wow!

Why DevOps?

The traditional development cycle of an Agile project usually leads to two to four major releases a year which means the delivery of a lot of new functionalities, tons of bugs fixes and therefore a lot of testing pre and post production. Such releases can prevent the good visibility of specific problems in the application itself; create a huge stress on the people involved as it is not conceivable to miss a deadline with two releases a year, and create an ever-extending list of requirements for the next release.

While many important projects succeed in this approach, many major companies such as Facebook, Amazon or Flickr have chosen to perform shorter cycles of over ten deployments to production a day. That process enables them to have a very specific scope per release and with the help of automation almost everywhere, especially in testing, creates higher quality deliveries.

How to DevOps?

One important thing to remember here is that you cannot call Merlin and ask him to send you a “DevOps person” to solve all your problems, including your personal ones.

In order to achieve a successful transition from a two-releases-a-year cycle to a ten-releases-a-day one, it’s going to take time, a lot and skill, a lot. The team in charge of the changes will have to study the way you work, analyze the current process, identify potential problems and then make a list of recommendations

Those recommendations usually include breaking the different walls between people. One big goal of DevOps is to make people realize that whatever their role, their objective is common with the rest of the project: to deliver quality and to do so efficiently. Imagine for one second that a bug is found in pre-production (it happens). Usually the sysadmin will perform an analysis within its domain and if he cannot find the cause or identifies it as a “not my fault”, will forward the bug to the development team who as usual will answer “it worked in dev., must be environment related”. The pointing fingers game will take some hours maybe days before someone finally jumps in and finds the problem.

Now imagine the same bug handled by people on a project where DevOps is used correctly. When the bug is identified by testers, developers and operations are contacted together and retrace all the steps. Is it due to an error in the specifications? Can we reproduce it in other environments? What changes in the code triggered that bug and so on and so on. By having people working together instead of one after another, you create ownership of the product and a strong team feeling. If everyone is concerned when a problem arises and if everyone understands the application from the conception to its application, problem solving becomes a breeze and an actual good way to create natural collaboration between people of different groups.

The other main changes that come with DevOps are related to automation. Maybe easier to implement than mentality changes, setting up automated releases, testing, deployments requires expertise and a lot of testing on the way but can lead to great time sparing.

DevOps in Real Life.

One my favorite thing in life is food. Eating it, making, talking about it… Let’s use food as a simple example of how to use DevOps.

Imagine yourself in a starred restaurant kitchen; there is the executive chef, a sous-chef, a saucier and a vegetable chef.

The chef has envisioned a dish and asked his new staff to do their parts based on what he explained to them. Ideally this would go well but: the sauce is too acidic for the vegetables and the plating is terrible with the shapes and colors making the dish look sad. Everyone blames each other and the utensils for not being adapted.

Add a zest of DevOps to the recipe and try again.

Now the vegetable and saucier chefs work together and make sure that what they produce respects the wishes of the chef while working perfectly with the protein produced by the sous. It doesn’t happen instantly but they all try the overall dish together and after many iterations, manage to produce an experience that is visually astonishing on a plate and which flavors combine divinely in a way that is neither too heavy nor too light. To be able to cook and plate correctly, they had to buy more adapted utensils that everyone in the staff could use if needed.

One month goes by and the head chef asks them once again to repeat the operation on a new dish.

This time the whole staff knows how to work together and while everyone is working on his own specialty, they all work together from the beginning, sharing their experience with the utensils and understand which way to go, tasting their creation as they progress, leading to another perfect dish done in a much shorter time.

DevOps is not magic.

Many things can go wrong in a project and DevOps might be one possible solution to solve some specific problems but it is important to remember that implementing new processes, changing mentalities and using new tools can take a very long time and be really expensive.

You have another definition? You don’t agree With me? Feel like adding something? The comments are here for that, please let me know what you think, sharing is caring!

December 3, 2014
SQL vs. NoSQL – Unsettled Debate & DevOps Pitfalls

Big Data, a relatively new phenomenon driving the industry hype-cycle is a mainstay in the database business. IT companies are convinced over the endless value proposition of the operational insight that comes with leveraging Big Data ( or Big Small Data ), so much so that it’s easy to overlook its impact on traditional database technologies and practices.

(more…)

December 1, 2014
The Conundrum of Adopting DevOps within Organizational Constraints

I wish I had a dollar for each time I’ve now heard, “we’re adopting DevOps, but we have to operate within the constraints of what the business is ready to accept.” Basically, this is becoming the battle cry of many enterprise IT professionals that are DevOps believers, but are stuck with the limitations of operating within a complex, political and immovable business structure.

One on hand, it is very pragmatic to approach adoption of new methods, techniques, technologies, etc. on a small scale and then expand based upon success. However, what is the result of a DevOps initiative in which existing organizational constraints and bottlenecks continue to remain in place?

If you’ve been in the business world for more than a few years you’ve probably already had the experience of having a really good idea only to come to the realization that implementation of that idea requires cooperation of another organization. For example, Marketing might have a great concept for how to acquire new customers, but would require sales management to provide incentives to the sales team for it to succeed. For purposes of this example, let’s assume that marketing has made its case to sales and sales rejects the proposal (many times there is a perception that the idea will be rejected limiting those from even trying; this is a worst-case scenario for any business). In this case, Marketing might attempt to operate around the need for the sales incentive and, ultimately, come to the realization to abort the plan or lower expectations for results.

Is anything more debilitating to morale then end up with these two outcomes as the only choices? What would you do if you were in the position of driving this for Marketing?

Often times in businesses there is no grievance committee. To steal a line from “A League Of Their Own”, “there’s no crying in business!” What DevOps is surfacing is that business is about relationships and managing cross-departmental and extra-departmental relationships is not something that many IT professionals have had to or want to foster. Ultimately, this will have a detrimental impact on DevOps adoption.

In most cases, DevOps requires that some leader within IT steps up with the idea to foster a frictionless ideation-to-operation lifecycle. By frictionless I mean the removal of as many bottlenecks and constraints for transitioning from the idea phase to a production-ready support application. Like Marketing in my earlier example, this may require this leader to “sell” their idea to the heads of IT Operations, Application Development, Quality Assurance, Information Security, and potentially C-level executives. A “No” response by any of these teams will result in the leader working around this limitation resulting in no change for the processes and work output of that particular group or attempting to do what they can within the organizational boundaries within their control.

Hence, business agility is tied to velocity of accepting change, which is further dependent upon individuals fostering a strong enough personal relationship–at a minimum one of mutual respect–to be willing to accept risk in support of a larger goal. I believe many would see this as a high-risk constraint on the business agility deliverable.

One way to increase likelihood of avoiding this trap? DevOps needs to be sponsored from C-level management from the start inclusive of the necessary incentives required to help drive the changes that will lead to more rapid adoption of DevOps practices and speed the way to business agility. There’s enough evidence now available to convince most C-level executives that a DevOps program is a worthy investment in moving their IT organization toward greater alignment with their business goals, producing faster, reducing operating overhead and improving quality.

As with most changes within IT, and DevOps adoption is no different, there is a requirement for bottom up support as those closest to the work need to believe, and there is a top-down requirement that provides the coverage, financing. motivation and accountability to the business to allow the change to occur.

November 20, 2014
Detours Ahead: Overcoming DevOps Challenges

Saying that you’re interested in DevOps is another way of saying you’re interested in change. That’s what DevOps promises any organization. No matter the problems a company is trying to solve or the goals it’s trying to reach, DevOps depends on a willingness to embrace some big changes. Sure, it can help you streamline software deployments, but it requires shaking up a company’s usual processes and routines. As we all know, change can be complicated, so before your organization transitions to an agile culture, it’s best to prepare for the likely challenges ahead.

Breaking Old Habits for Continuous Delivery

Many of the procedures we follow at work each day are second nature, and what’s familiar carries a certain comfort with it. Even when we realize a more efficient process is within reach, old habits are tough to break. For an organization that employs hundreds, any change can be a challenge.

And DevOps offers no shortage of challenges. It entails overhauling a company’s deployment process, its communication patterns, its department structures and even the roles of individuals on a team. Yet unless an organization is willing to let go of its old habits, the benefits of continuous delivery won’t ever be achieved. When acclimating people to this new procedure, it’s important to convey that the old procedure – one team throwing code over the wall to another one – will be left behind for actual collaboration in which Development, Operations and possibly other departments work together, not just in silos.

Getting Past the Resistance to Change

Encountering some reluctance to change will be natural, and a smooth transition depends on making everyone aware of why DevOps will be a big step forward. This includes communicating what the advantages will be for individuals, departments and the company as a whole. With an agile plan in place, greater efficiencies will become the norm, and a team will have the ability to spot and fix problems more quickly, so 3 a.m. phone calls to the system admin won’t happen anymore. Once managers through C-level folks are aware of these potential advantages, resistance will gradually turn into acceptance and enthusiasm.

Combating the Myths and Rumors

Many think DevOps is only for the well-known unicorn companies, such as Etsy and Facebook, or that it’s an exact science that will produce the same results for everyone. Some even believe the rumor that DevOps only works with certain operating systems. The truth is that continuous development can take place anywhere as long as the company culture is right. As detailed in the Rackspace-sponsored e-book, The DevOps Mindset: Real-World Insights from Tech Leaders, many DevOps practitioners went through their own uphill climbs to become more agile, and they have the firsthand experience to resolve many popular misconceptions.

“You don’t have to be in Silicon Valley to embrace the DevOps culture,” says James Kenigsberg of 2U. “In fact, many new firms these days have a bad habit of building shiny technology because it is shiny, which goes against the DevOps principles of communication and transparency.”

Jeff Hackert of Chef dispels the myth that DevOps is a one-size-fits-all solution. “It is not a set of proscriptions or a recipe that will give you a defined best practices outcome,” he explains. “Your best practice is the collective wisdom of the very smart people you’ve hired to solve your problems. And if what you have is a siloed or broken environment, you want to increase the communication, not impose new rules.”

Getting Automated Without a Struggle

When an organization is considering DevOps, they may find that the opportunities for efficiency not only involve employee collaboration, but technology as well. Most IT departments would jump at any chance to save time when it comes to coding procedures, and automation is a means of making this happen. By offloading these processes to an automated system, people can tackle other tasks, and businesses that release several deployments a day can greatly simplify their rollouts. For those who might not be familiar with the ins and outs of automation, receiving some guidance from a trusted IT provider can be a good first step. Finding an advisor to guide your initial automation efforts can prevent the expense of hiring a DevOps engineer with automation knowledge.

Finding a Path Around DevOps Obstacles

Every company’s DevOps strategy will be unique, and every company’s plan for overcoming challenges will be just as unique. Whatever the circumstances, communication will be crucial to any adoption, as it ensures that everyone understands why such a change is necessary. Getting acquainted with the success stories out there will dispel any myths circulating among team members, and stumbling blocks can be avoided by the understanding that familiar silos will be replaced by more efficient collaborations.

Despite its challenges, DevOps can be the catalyst for a variety of improvements, from productivity to employee morale. Those who are the most successful at being agile will not only have the right culture in place, but be able to negotiate the challenges that DevOps has in store for those ready to embrace change.

November 19, 2014
Nationwide banks on DevOps to drive towards Continuous Delivery

The Financial Services industry is fast moving, highly regulated and customer-centric. The general perception in our industry is that any change in processes implies risk and delay, neither of which we can afford. But at the same time, we are faced by the mammoth task of needing to continually introduce new products and services to stay competitive and cater to the growing needs of our customers. This is unthinkable without a fast software delivery lifecycle, as our business is highly dependent on technology. The best way to accelerate software delivery in a complex, fast moving environment like ours is to adopt a DevOps approach.

As a speaker at a number of events, I have discussed the ongoing transformational journey at Nationwide and shared our approach with other enterprises who want to understand how they can follow suit. I recently had the opportunity to co-present with Hayden Lindsey from IBM at the DevOps Enterprise Summit (Oct 21 – 23) hosted by Gene Kim. You can watch a replay of our joint session Patterns for Enterprise Success: The DevOps Journey at Nationwide below.

From humble beginnings as a small auto insurer serving the farming community, Nationwide has grown into one of the world’s largest insurance and financial services companies. Like many businesses today, we saw that we needed a better way to respond to changing market requirements and regulations, to increase speed to market, and to support new channels for customer interaction. Mobile, cloud and big data technologies were further raising the pressure on us to facilitate rapid digital innovation. What we required was not just a solution, but a change in culture (the way we look at things), processes (the way we do things) and tools (the technology we use). DevOps gives us the capability to achieve all of this—and more.

The immediate challenge was to achieve these changes by leveraging our existing heterogeneous tool suite. We partnered with IBM DevOps, which has played a significant role in our success. We were already working towards agile transformation. With IBM’s support, we were able to use the DevOps approach to application development and delivery across our distributed and mainframe environments. While a DevOps approach as supported by IBM enables organizations to start anywhere based on their specific needs, we at Nationwide decided to address all four adoption paths across the software delivery lifecycle: Steer, Develop/Test, Deploy and Operate.

DevOps enabled our IT department to perform continuous integration of its code and continuous deployment into its development environment several times a day. Teams can also perform acceptance testing of customer requirements within the same iteration as development. IT managers can show their internal customers, in near-real time, what developers are producing. This capability became a game-changer as we became more agile as a business and more responsive to customers. We achieved a 50% improvement in code quality, a 70% reduction in system downtime and were able to move 58% of our teams into the top quartile in key productivity measures. I believe that, the more agile we can be from an IT perspective, the more agile the business can be in terms of going from the development of an idea to the deployment of a customer-facing product.?

The next step in our DevOps journey is to build on the gains generated by the adoption of Agile and Lean practices across the entire SDLC. This is where technologies such as TaskTop and UrbanCode come to the fore by providing the integrated continuous flow and visibility needed for a continuous delivery infrastructure. By creating this delivery highway, we are giving Business Areas the ability to deliver as fast as they need to based on their own determination of cost, risk and value. Time-consuming manual processes based on out-of-date information are replaced with automated deployment policies that use real-time information synched from systems of record. The combination of dashboard and dials gives the business the visibility and control to drive at a much faster pace than is currently possible. Lack of trust in development outcomes has historically been an impediment to speed. Our new automated approach is giving us the confidence to move faster to serve the business without compromising the quality of our deliveries.

IBM was a great partner for us here as they share our support of the open standards approach, which gives us the ability to work with a heterogeneous set of tools, across the full lifecycle, allowing us to determine holistically the best tools, the best architecture and the best approach to meet our goals of high quality, high productivity and faster delivery for our customers.

By balancing speed, cost, quality and risk, DevOps is helping us increase our capacity to innovate. That in turn helps us get to market faster and be more competitive. I mentioned during DevOps Enterprise Summit that the phrase “time is the new currency” resonated with our goals of optimizing the path from “concept to customer value”. We need to ensure we don’t let it slip through our fingers. We have long been dependent on manual processes, but in this new digital age they are only going to slow us down. This is the time to be agile, competitive and pragmatic. It’s time for all of us to break the age-old shackles and embrace the opportunity for change that DevOps represents.

About the Author

Carmen DeArdo is the Director of Application Development Tools and Technologies at Nationwide Insurance. Carmen is responsible for driving continuous delivery utilizing DevOps, Lean and Agile techniques across Mobile, Distributed and Mainframe and other technologies. This includes recommendations and implementation of technologies used across the development life cycle (e.g. IBM Rational tool suite, open source technologies).

November 12, 2014