DevOps will disrupt management styles, speed the end to ancient IT practices, and flatten away processes that don’t focus on doing more with less. But DevOps is not the only dev-led movement that will impact and reshape the High-Tech industry. So called “growth hacking” will also disrupt organizational charts by bringing development tools, methods and practitioners into roles previously filled by marketing, sales, and customer success pros. As DevOps and growth hacking become more mainstream, the inevitable result is developers ruling the world.
Tag: devops
-
The DevOps value stream is not SOP
#devops #lean Don’t confuse doing something faster with greater efficiency.
Much of the focus on DevOps remains at the implementation level – on gaining efficiencies through automation of tasks and orchestration of processes. While this is not a bad thing, such a micro-focus on the moving parts can result in the loss of efficiencies to be gained at the macro-level.
One of the biggest inhibitors of a timely release cycle is not the moving parts, but rather the process in which those moving part are executed. It’s not necessarily the actual push into production that’s problematic, but the length of time it takes to accomplish certain tasks when they cross internal organizational boundaries.
For example, many years ago we began the process of pushing a new application into production – a web application. This required, perhaps obviously, changes to the corporate firewall. The “process” for accomplishing this change – essentially opening a port on the firewall for the intended public IP address – required no less than five different signatures across networking, security and architecture teams. There were only two security roles allowed to approve such a change, and the process was noted as taking up to 15 days to get a signature on a piece of paper and subsequently a rule change.
This was not a task level problem. It was not implementation issues. It wasn’t even difficulty in making the change on the firewall. It was all about the process. Scheduling a release meant taking into consideration not only the readiness of the application itself, but its supporting services – including networking.This is why DevOps should start with a review of the processes used to release an application into an environment (whether test, QA or production). Mapping out the process is the first step to finding where the bottlenecks might be that are causing delays in moving that application to the next phase of its lifecycle.
Simply automating an existing process may not provide the value expected or touted by DevOps supporters, because if the process is poor, you just end up doing something poorly much faster.
In other words, the value of DevOps is not necessarily in simply automating SOP (Standard Operating Procedure).
The initial Value Stream Map captures the current process as it exists. This is known as the “As Is.” It is the actual process flow and should be created through observation of the current flow and with participation of those who are in the process. Do not make the mistake of pulling a process map from the procedural manual (SOP). The best technique for mapping is to be the unit (the “thing”) coming through the process. For example, in the insurance industry it might be the policy. In the auto industry, it may be the car. In each instance, the Value Stream Map begins with the request for the unit i.e. insurance policy or car. [emphasis mine]
http://www.goleansixsigma.com/how-to-visualize-a-process-with-a-value-stream-map/
For application deployment, the “thing” is … an application, and the process should be mapped based on what’s actually happening. Only when you have the process mapped can you evaluate it for bottlenecks and understand the steps of the process at which each group adds value. Value is defined as any step that moves the thing (the application” toward the end goal. Efficiency is then measured as a percentage; specifically it’s the value added time as a percentage of the total time it takes to complete the process (the cycle time).
Don’t confuse doing something faster with greater efficiency. If every step of the cycle is automated, the actual process efficiency hasn’t changed. The ultimate goal of DevOps should be about improving the efficiency of these processes, not just doing what’s always been done faster.
Some of the opportunities for improvement in efficiency that will surface is certainly interfaces with other organizational groups. Perhaps it’s that a process step might not take as long if you had relevant data or information up front. If you’re wasting time waiting for some piece of information, that’s not value added time. It’s just cycle time. More cycle time reduces the efficiency of the overall process by overloading it with wasted time. Better information gathering up front can help reduce the wait time and immediately provide greater efficiency of the process.
It is these opportunities for improvement that will be particularly helpful in the enterprise arena, where the issue is not so much attempting to hit ten deploys a day, but rather the predictability and efficiency of the processes that enable teams to hit a specified change window as desired.
DevOps is not about the tools, or the automation of manual tasks. It’s about the big picture, and that means gaining greater efficiencies through process re-engineering and orchestration as well as automation. Focusing on the micro aspects of DevOps will only ensure that if you’re doing it wrong, you’re doing it wrong faster. Step back and look at the big picture, and find those process steps that are really causing inefficiencies in your organization.
-
Five Top Tips for Cloud and DevOps Automation
A while back, I overheard someone asking why many of the ‘cloudy people’ have moved on to DevOps.
One reason is certainly that cloud is at the heart of DevOps. Many of the grounding principles of DevOps – rapid iteration, agile development, automated testing, continuous delivery and continuous integration – are barely even possible without cloud. However, I think it runs even deeper than that. DevOps and Cloud are both fundamentally enabled by the same technology I have been working with my entire career – automation.
When IT leaders get excited about cloud, it is mainly because of automation. Sure, cloud providers get excited about essential characteristics like broad network access and resource pooling, because that is how they maximize reach and minimize costs. Similarly, CFOs get excited about the measured service, because that means they only pay for what they use.
However, according to a recent Luth Research study, most IT leaders prioritize the higher-order values enabled by on-demand self-service and rapid elasticity – faster innovation, superior performance, better scalability and higher resiliency. These capabilities are deeply rooted in automation – of provisioning, deployment, configuration, scale-up/scale-out and other processes.
Similarly, DevOps – beyond a certain point – also builds on a foundation of automation. As Rackspace CTO John Engates noted in his recent column in this journal, “DevOps is more than a set of automation tools.” He is right, of course. You can achieve a great deal through cultural and structural changes – better collaboration, shared goals, team building, process improvements, etc.
However, tools for release automation, configuration automation, process automation, test automation, service virtualization and provisioning – just to name a few – are adding tremendous value with a rapidly maturing DevOps automation toolchain. Indeed, in recent research from Vanson-Bourne, over half of senior IT decision-makers worldwide rate automation as the most important DevOps component – above such putative stalwarts as agile development, collaborative teaming and process alignment.
Looking at the history of enterprise automation, and considering my own experience, I believe there are many common principles that you can apply to both cloud and DevOps. Here are just five of my top tips:
Don’t Automate Bad Processes
Automating bad process just makes bad things happen faster. This seems obvious, but I often see automation that only encodes (and accelerates) a bad existing practice. To avoid a high-speed train wreck, first identify, catalog, document, review and refine key manual processes to make sure you are automating the right activities, at the right time, in the right way. Solve for simplicity, speed and throughput, even before you apply automation. Remove friction across silo boundaries – departmental, technological and disciplinary. Start simple, be inquisitive, and iterate methodically. Then make sure you automate deeply, thoroughly and efficiently.
Cross-skill Existing Resources
Great people are hard to find and salaries for cloud- and devops-relevant skills are amongst the highest in IT. This explains why, according to the same Vanson Bourne research, over 70 percent of DevOps leaders are retraining existing personnel, while only 50 percent are hiring new resources. Look for staff with a history of automation in their resume, through multiple waves of technical change, rather than specialists in one automation technology or product. Find the IT equivalent of a “good athlete” rather than a “position player”.
Security Cannot Be an Afterthought
Automation systems and the staff responsible for them have always needed highly privileged (and frequently shared) user IDs, whether automating a mainframe IPL or scripting a production code release. This is an audit red flag, and can result in high-impact incidents, whether accidental or malicious. Identity and access management provides essential audit and control, while giving users (including automation tools and APIs) easy access to the resources they need (locally and in the cloud), when they need them.
Document, Measure, and Backup
If you do it right, automation quickly becomes pervasive and mission-critical. Without documentation, you create inscrutable systems, tribal knowledge, the hero and other ‘anti-patterns‘ in your Cloud or DevOps machine. Without measurement, you cannot know if (or when) complex autonomous systems run amok or stop working. Without backups, critical systems are prone to irrecoverable failure. Cloud and DevOps teams must value and prove traditional disciplines like documentation, measurement and backup – painful as they may be.
Build Awareness into Automation
As automation becomes mission-critical, it must be resilient to errors, failures, exceptions and other unexpected conditions, and still deliver a correct result. Remember when ‘autonomic computing’ was a thing, when we dreamt of ‘self-aware’ systems? Similarly, concepts like ‘desired state’ and ‘idempotence’ go back at least as far as mainframe and server automation. Similar concepts apply to cloud computing and DevOps too. In both, it is critical that automation routines are aware – of their own state and of the surrounding environment – so that they can test for and accommodate unexpected conditions, and still deliver the expected results.
Given the depth of history in automation, and the many parallels with modern computing, some may claim that cloud is nothing new, that we have been doing that since the mainframe; while others will say something similar about DevOps. I think they are wrong, but there are definitely parallels, and George Santayana has a point – we should be at least informed by history, if we are going to try to write the future, while avoiding the mistakes of the past.
-
The 7 skills Ops pros need to succeed with DevOps
There’s a lot of confusion about what DevOps exactly is, and what it takes for enterprises and individuals alike to succeed. Some argue it’s about successfully using collaboration toolsets. It’s not. DevOps is about collaboration between software developers and IT operations teams. DevOps grew from the need for a more agile organization, and to knock down the barriers between development and operations so that applications and IT resources could be delivered more quickly, and improved through steady iteration.
What does all of this mean, specifically, to operations professionals – and the skills they need sharp to thrive? The walls coming down are a bit of a culture clash for most large enterprise operations and development teams. And both developers and operations professionals need to ensure that they have the right skills in place to succeed in this new environment. In this post, we’re focusing on those skills ops members need in the years ahead.
The skills that are important may surprise some. Consider the findings from CA Technologies’ recently commissioned a study, What Smart Businesses Know About DevOps. “The most in-demand skill requirements for success with DevOps were actually soft skills,” says Andi Mann vice president of strategic solutions at CA Technologies. “I expected to see skills like programming or scripting; experience with specific tools for provisioning, configuration management, release automation, or shared monitoring; or even an understanding of Agile or Lean practices. In fact, those skills were much lower,” Mann says.
More on the results from the CA study below, but first we want to share the results of our informal anecdotal survey of a handful of DevOps experts and practitioners, well known here at devopsy.kinsta.cloud. Here they are:
First Up: The Soft Skills
Interestingly, it is these soft skills that are both needed and often derided. “Everyone doing DevOps, whether Dev, Ops, security, QA, project management all need [soft skills],” says David Mortman, chief security architect and distinguished engineer at Dell, Enstratius.1. The ability to communicate clearly and concisely
“Sharing is a key tenet of DevOps and if you can’t share what you know and what you’ve learned, then having that knowledge is effectively useless. You’ve just made yourself a bottleneck,” Mortman says. The other skill Mortman cited along these lines is striving to actually understand the shoes in which your fellow enterprise collaborators stand. “I can’t emphasize enough the value of having empathy for everyone else and what they need to get done. Every role has its challenges and empathy for those challenges goes a long way to a more congenial workplace,” he says.2. Collaboration techniques
New collaboration techniques are essential, explains Donnie Berkholz
IT industry analyst at RedMonk, and council member and Sr. developer at Gentoo Linux. “Ops will need to learn effective, distributed collaboration techniques such as those used in open-source software development. Leading-edge DevOps organizations make heavy use of online chat and shared tooling to log both communication as well as action. In some pioneers, this even involves so-called “ChatOps” where you can make changes to infrastructure through calls to an automated bot in an online chat. Typically this includes asynchronous communication in preference to phone calls, both long-form (e.g. email) and short-form (e.g. IRC), in an archived and searchable form,” he says.This enables, Berkholz says, on-call ops during any crises or fires that arise, as well as eases the ability to identify and brainstorm infrastructure changes, where everyone can easily contribute their ideas.
3. A flexible mindset
We’re not necessarily talking about advanced forms of mental Yoga, but certainly the ability to change as knowledge and conditions change, whether those changes are technical or business driven. “The willingness to make changes and to evaluate alternate options is key to DevOps. Things are going to fail, you or a decision you’ve made are going to be the cause of that failure. Or things just won’t work as well as you’d hoped or thought. Be willing to change your mind and look for better options,” says Mortman.4. Good enough is never enough
It’s about consistently seeking continuous improvement. “This mindset is laser focused on continuous improvement daily,” says BEHR. “It is the ability to unlearn and acquire new more relevant knowledge in light of complexity and emergent information – then disconfirm it with the scientific method and move on to application only where relevant,” says Kevin Behr chief science officer at CXO advisory and board advisory practice Assemblage Pointe, Inc.Next up: The Technical Skills
Understanding of modern software engineering
5. “To move to a world of “infrastructure as code,” where all systems are maintained using configuration-management tools such as Puppet or Chef, including version control, unit and integration testing, agile software development, as well as continuous delivery and deployment models,” says Berkholz. “Traditional sysadmins may still live in a world of login prompts and manual edits of configuration files, so this will be perhaps the largest hurdle in terms of knowledge,” Berkholz estimates.“The technical mindset I look for are skills which allow a team to treat servers more like cattle and less like cats,” says Andrew Storms Sr. director DevOps at CloudPassage. “To work effectively at that kind of systems mentality, DevOps engineers need programming and systems architectural skills. Whether that means Ruby or Python or whatever is needed to effectively work with orchestration tools, APIs, and automation. It’s less about needing to know a specific programing language more about understanding programing algorithms and robust systems design,” Storms says.
6. Modern software architecture
This includes cloud deployment and administration as well as distributed systems. “As we move to a cloudy world of software, ops will need to deploy, maintain, monitor, and troubleshoot production problems with this infrastructure. And yet in many cases it’s much more complex than the previous equivalent, although it brings with it significant benefits in agility and uptime if done right. Ops will need to familiarize themselves with cloud instances and services, as well as lower-level software infrastructure such as Linux distributions and databases when deployed in a cloud,” says Berkholz.That also includes taking a step back from the trees to consistently stay aware of the forest. “Seeing the system and its boundaries rather than just the tasks and their due dates. This understanding of the interactions between the various actors in a system and [understanding] just how those interactions are making value occur is fundamental,” he says. “Without this understanding we will not know when to push harder versus be silent,” he says.
7. Understanding that security incident response are continuous efforts
Security and safety in the new DevOps environment needs to embrace new ways of addressing security and QA. “This requires continually emergent solutions rather than using ‘tried and true best practices.’ The effective team will evolve through relentless self evaluation, study, and application of more relevant and effective methods to work in complex infrastructure environments,” says Behr.That’s all great advice, and certainly not all inclusive of the ideal skillsets. We also found it interesting that CA Technologies’ survey of 1,300 senior IT decision makers echoed the need for broader business and so-called soft communication skills when it came to DevOps success.
These included: knowledge of business priorities/strategies/metrics (47%), knowledge of current business processes (42%), communication skills (36%), and project management and people skills both scoring 30%. In fact, experience with specific tools was dead last in the survey at 12%.
-
Lean versus the bandwagon, lean wins
I’ve just finished reading “The Phoenix Project,” by Kim, Behr and Spafford. To be honest, it was on my reading list but had I not picked up a copy at Camp DevOps I don’t know that I would have ever read the book. My main issue with books of this ilk, such as “Who Moved My Cheese” and “The Energy Bus,” is that the story is often contrived for purposes of delivering the learning points. So, I was surprised by how much I was able to relate to the issues in Phoenix giving it an air of reality I was not expecting.
Phoenix follows the life of a new VP of IT Operations through his early weeks on the job. Plucked from obscurity as the Director of Mid-range Computing after his management chain was seemingly asked to depart the company, Bill’s eyes are opened to a world of heroics and chaos that surrounds him in IT and has had detrimental impact on the company’s financial and competitive performance. For anyone who has logically questioned, “how can that happen?” in their own companies, the authors do a great job of illustrating the paths that lead to the unimaginable outcomes we see every day in our own IT world.
That said (spoiler coming), I ask the authors, did we really need to make Bill’s dad an alcoholic? Sorry, completely tangential point, but interestingly, one of the few times where I thought the authors had reached into their “drama box” for reasons that are still unclear. Nonetheless, after reading this book, I reflected upon the content that is being created around DevOps movements and realize that there is a polarization effect occurring.
Camp 1 I categorize as the “lean camp”. This camp represents those that believe DevOps should be the application of lean manufacturing principles on IT. In this perspective IT is represented as a critical hub through which business is enabled and transacted. In accordance with this perspective, work enters the hub through multiple endpoints and must be prioritized and coordinated in order to ensure that a) critical IT resources are sourced appropriately and with maximum value to the business and b) constraints and bottlenecks are minimized, thus allowing work-in-progress to complete successfully. Anyone who has studied any aspect of logistics, manufacturing or supply-chain management understands the number of variables involved in this type of scheduling, but applying this to IT is significantly more challenging since it requires the cooperation at both the 30,000 foot view and the 10 foot view, with the latter required to understand the impact of scheduling conflict and help foster collision avoidance that could lead to outages.
Camp 2 I categorize as the “bandwagon camp”. This camp represents individuals that are using DevOps as a lever for their careers. Certainly, DevOps is the hot topic of the day and having it on the resume is certainly good for a few extra brownie points and higher salaries. Ask these individuals what DevOps is about and you hear answers, such as, “it’s about changing the culture in IT,” “it’s about getting development and operations to cooperate more effectively,” or my personal favorite, “it’s about automation.” The truth is that DevOps needs aspects of all of these factors but driven under an umbrella of work described in the Camp 1 description above. Acted on independently under the guise of DevOps and we will see DevOps nose dive into Gartner’s trough of disillusionment very quickly.
Will things get fixed in Camp 2? Probably. Certainly implementing controls around who can make changes and when they can occur may help many businesses limit the unplanned work that is crippling their ability to address other work efforts. However, since this is not the focus of the DevOps effort, unplanned work will continue to come from other areas, it’s just the nature of the beast and without correcting the actions that foster unplanned work, it will continually have a negative impact on the business.
The authors of Phoenix have done a fantastic job of providing IT leaders with a goal for their DevOps programs. If they are wise, they will rapidly adopt the principles defined therein and make sure that all other so-called DevOps efforts in the company are aligned for purposes of reigning in the chaos and free-wheeling efforts of rogue IT employees. I recently met with a VP of IT for one of the major food distribution companies. I was awed by how effectively his IT organization operates, but now I realize, that his company is primarily a logistics and supply-chain company that happens to move food. It only makes sense that the principles they use to run their business would be adopted for IT as well; especially with their IT leaders coming from other parts of the business. In combination with Phoenix, the meeting locked it for me that the lean principles are key to positioning IT as the business enabler needed to be competitive in the current era.
-
Your End Users Want Everything: Here’s How to Give it to Them
In today’s application-centric business environment, the end user is king. Whether we’re talking about being first to market with the next big thing or adding new capabilities and features to an existing application, so much of our current development time, resources and energy is spent on trying to meet the needs of end users.
It’s not difficult to see how we got here. The proliferation of social media and mobile and other connected devices has empowered end users to make their voices heard – and whether their opinions are positive or negative, we have no choice but to thoughtfully consider them if we want to produce market-leading applications.
At this point, you might be thinking, “How is this different? End users have always been king.” You’re right, but the difference between then and now is that we used to build roadmaps and select features based on what we thought they wanted. Now, thanks to social forums, user reviews and other avenues for collecting feedback, we know exactly what they want. The trick, of course, is finding ways to deliver on that knowledge quickly and at a high level of quality without breaking the budget.
Taking Agile to the Next Level
Agile was one of the first methodologies to incorporate user feedback directly into development. You know the drill: choose a small set of capabilities to develop, release the build to a select group of users, collect and incorporate feedback into another build and continue iterating until the application is ready for production.
One of the goals of DevOps – which CA defines as best-practice application delivery methods that improve communication, integration and collaboration between development and operations – is to enable Agile-like development practices that incorporate end-user feedback from after an application is on the market.
We talked a bit earlier about collecting such feedback. Whether you read forums, poll customers or even collect usage data directly from the application, you know that getting the feedback isn’t the hard part – it’s incorporating that data into the development lifecycle in a way that meets your speed, quality and cost requirements.
Starting with Pace-Layered Approach
When it comes to being nimble in the software development lifecycle (SDLC) and reacting to the marketplace, one of the challenges many enterprises have is that their IT infrastructure is complex, comprised with legacy and modern technologies that have been assembled over time. According to a major analyst firm, the key to speeding development in such environments is to segment the infrastructure into layers: namely, systems of record, systems of differentiation and systems of innovation.
For systems of record, think foundational technologies like mainframes that have typically lengthy development periods, versus systems of innovation, such as mobile apps or cloud services, that have a lighter footprint and are more flexible. Once you’ve categorized your components into these layers, you’ll be able to react to customer feedback most quickly with your systems of innovation – and there are two types of tools to help you do just that.
Application Delivery Tools That Speed Development and Delivery
With a service virtualization tool, you can simulate constrained or unavailable systems across the SDLC, allowing developers, testers and performance teams to work in parallel for faster delivery and higher application quality and reliability. In other words, service virtualization enables you to decouple your systems of innovation from the slower moving systems of differentiation and record, so you can quickly deliver on customers’ requests, even amidst all the change and complexity in your IT environment.
To further accelerate the SDLC, a release automation tool can automate complex, multi-tier release deployments through orchestration and promotion of applications from development through production. This tool is your assembly line, driving the application from code development to production, so you can get new innovations into your customers’ hands faster than ever before.
Addressing end-user feedback is an ever-evolving, constantly moving target. But if you follow Gartner’s pace-layered approach and plug your systems of innovation into the right application delivery tools, it’s a target you’ll always be able to hit.
-
Enterprise DevOps is Real and Here to Stay
A recent column in the Wall Street Journal’s CIO Journal argued that while DevOps is gaining inroads in small and mid-sized businesses, it’s facing a much less rosy future in large enterprises. The story cited organizational challenges, many of which we covered, such as large siloes, regulatory compliance, and resistance to change as great impediments enterprises embracing DevOps.
The column also spoke of the buzzword “DevOps,” how it’s a software development methodology, and spoke about “holistic” DevOps tools. Interestingly, that’s not how we view DevOps. Not at all. DevOps is more a movement about organizational collaboration and driving improvement.
Still, the author wasn’t completely wrong. There are significant hurdles to overcome when moving to a DevOps culture, and those that the author cited are the primary obstacles for both enterprise and SMBs – mainly cultural changes the processes to support it – and they are being overcome. Just, typically, at a slower pace among larger organizations.
“I think the SMB vs. enterprise is the wrong axis to use,” says Donnie Berkholz, an analyst at Redmonk. “Like any change, it’s going to be a lot easier for greenfield teams and projects, so new startups will have an easier time starting from scratch with a DevOps mindset. And there’s also no guarantee that SMBs are new — in fact many of them have been around for a long time and have similar inertia, relative to their sizes, as large enterprises do,” says Berkholz.
And, as Berkholz explains, one of the big challenges for companies considering DevOps is whether the benefits of the move exceed the switching costs. “Fortunately we’ve got growing data, such as the Puppet Labs survey, showing that DevOps greatly accelerates time to delivery, although quantifying “first to market” in terms of dollars can be challenging,” he says.
Bigger ships turn more slowly, but they still turn
Jeff Sussna, founder of the IT service innovation consultancy Ingineering.IT, concurs and says change always happens more slowly in enterprises than SMB’s, simply because they’re larger and more complex. And just because enterprises are bigger ships that turn more slowly, they’re still turning, though it may be more difficult to perceive immediately. “I think people are confused and [they] think DevOps requires either smashing org charts and mushing everyone into shared teams, or else rolling out some big expensive overarching tool across the entire organization,” he says.The reality is DevOps is manifesting when teams collaborate and partner much more closely – no matter their size within the enterprise or if such change is occurring at a sweeping pace, at first. It’s when operations teams seek developers’ input, and when developers reach out proactively to operations. When teams are working to improve continuous QA, they are performing DevOps. “I think the fundamental problem with DevOps at the moment is we think it’s a destination, when really it’s a path,” says Sussna.
And Berkholz adds that just because it’s a slower and more cautious in the enterprise doesn’t mean it’s not transformational. “Like any other organizational transformation, the path of least resistance tends to be one of incremental change rather than a wholesale shift. Switching one tool at a time to a tool chain that encourages DevOps-style behavior and discourages silos can help catalyze that transformation. Continuous integration and continuous delivery/deployment pipelines are great examples of this,” he says.
And those are exactly the kinds of transformations underway at the enterprises we speak with every day.
Big rivers often begin as small streams
As for the business benefits, many organizations view it as a matter of survival. “I think over the years folks have been amazed how long (not to mention how expensive) it has taken just to bring basic levels of good, let alone best practice in to IT. There have been more than enough failed Bataan Death March style best “implementations” to make any executive wary of the next new thing. In my opinion this is the real opportunity cost of old scientifically disproven mechanical metaphors for human organizations,” says Kevin Behr, chief science officer, at enterprise opsflow consultancy Praxis Flow, and co-author of The Phoenix Project and Visable Ops.“I believe if your org can not improve at the individual level it is incapable of getting much from DevOps, or anything else for that matter,” Behr says. That is why I have focused on first evolving some sort of continuous improvement form or kata using the scientific method as its base. This capability starts day one helping to create resilience, which is the ability to handle change. With that you can “improve into DevOps” iteratively and within the guardrails of your organizations overall direction and strategy. We call this approach Opsflow, as you’re flowing Ops in to Dev, then to test, then to infosec, and then on to the rest of the business,” says Behr.
And the data increasingly show that the move to DevOps is in fact well underway. And happening it already is, at least according to numerous and recent studies. One is the Vanson Bourne study (funded by CA Technologies) of 1,300 senior IT decision-makers, at enterprises with $100 million in revenue, and within financial services, healthcare, manufacturing, public sector and telecommunications industries from 21 countries around the world. In that study, a decisive 99% see a greater need to move foreword with DevOps.
Additionally, the 2013 State of DevOps Report by Puppet Labs found that the majority of those that have implemented DevOps have found significant benefits including improved quality of software deployments, more frequent software releases, improved visibility into IT processes, cultural change, and IT being more responsive to business needs. -
Who’s side are you on anyway? DevOps Culture
Shame on you! Yes you, because there is a good chance you are thinking about DevOps all wrong. If you are a developer you might be thinking DevOps means IT goes away and you control all the infrastructure. If you are from IT you are thinking that DevOps is just automating what you already do, more. You’re like a seagull from “Finding Nemo”, trying to claim ownership of this DevOps thing. “Mine!”. And both of you are wrong.
-
Simplify and expedite server management
Deploying, managing, and maintaining servers can be tedious. Deploying, managing, and maintaining thousands, or tens of thousands of server instances is overwhelming—bordering on impossible—without the right tools. Thankfully, the right tools exist.
The Pain of Doing Things the Hard Way
I know I am dating myself, but when I was an IT admin for a dot.com startup, I had to deploy servers the old-fashioned way. UPS would show up with a box from Dell. I’d unpack it, and mount it on the rack in the datacenter. Then, I’d begin the process of configuring the operating system, and installing the application software. Each server was essentially a full-day project, and we seemed to constantly be adding new servers, so my full-time role was basically “racking and stacking” for a while.
Adam Jacob was experiencing similar obstacles when he developed Chef. Working as an IT infrastructure consultant, Jacob was frustrated by the configuration tools that were available, and the lack of a simple, repeatable process. Rather than starting from scratch and reinventing the wheel for each client, he developed Chef to enable IT admins to create modular, reusable “recipes” that automate the process.
Server management doesn’t end with deployment and initial configuration, though. You also have to maintain the servers, and resolve issues that might occur. When an issue arises, it could mean hours of troubleshooting to identify the root cause, and another few hours to work out and implement a resolution.
I used to get into philosophical debates with management and other IT personnel because it was my opinion that we should just skip the troubleshooting and rebuild the server from scratch. My theory was that it might be nice to know what caused the problem, but from an operational perspective I knew I could rebuild the server and restore normal operations in a couple hours. Troubleshooting, on the other hand, was an unknown—both in terms of whether or not it would even be successful, as well as how long it would take.
The Beauty of Doing Things the Easy Way
Tools that automate configuration and deployment of server instances automatically solve both of these problems. They expedite deployment and configuration, and simplify management and maintenance—freeing IT admins and IT personnel to focus on more important, less mundane tasks.
Tools like Chef help IT manage complexity. It is great from a DevOps, automation perspective to have a tool that enables you to quickly deploy and configure servers, but the real value comes from the ability to maintain a stable, dependable network with minimal effort.
Chef nodes “phone home” periodically to ensure the configuration matches the recipe it has been assigned from the Chef server. Any deviations are automatically overwritten—so any changes that may have been made locally on the node are erased, and the server remains configured as it should be.
In order to implement lasting configuration updates, the changes have to be made to the recipe at the Chef server level. The bonus is that once the recipe is updated, all Chef nodes working from that recipe will be automatically updated.
When an issue occurs on a server instance, it should ostensibly be corrected automatically when the node communicates with the Chef server and overwrites the configuration. However, even if that doesn’t happen for some reason, the use of DevOps tools like Chef still makes the task of troubleshooting and/or resolving server issues much more efficient.
With the push of a button, you can just deploy a new server—properly configured and ready to go. You could choose to kill the server experiencing issues and just replace it with the new one, or you could launch a new server to take over the roles and responsibilities of the affected server while you take the time to troubleshoot if you really need to understand what the root cause of the problem was.
Embrace simplicity
Apparently, I was an IT admin at the wrong time, and I got out of that career path right when things started to get interesting. Necessity being the mother of invention and all that, Adam Jacob created a platform with Chef that reduces the complexity and tedium of deploying and managing servers.
Chef isn’t alone. Tools like this form the foundation of DevOps because a culture that combines development and operations, and iterates new releases on a rapid scale needs to have this sort of automated IT infrastructure to keep up.
-
Avoiding Parrot Processes
One of the things devops practitioners are tasked with is the provisioning and configuration of all sorts of infrastructure. Application servers, web servers, load balancers, proxies and database servers are among the lengthy (and no doubt growing) list of “boxes” devops needs to get up and running to support just about any given application today. One of the key value propositions of a devops approach to operations is that it can reduce the time it takes to get applications to market by getting them up and running in production faster. That’s increasingly important as we move into the Era of Things, driven by extreme connectivity of everything, because all those “things” need are going to need to be talking to applications on the back side.
So speed is of the essence, but not at the cost of accuracy. We’re encouraged, then, to automate tasks and orchestrate processes to achieve that speed. The side effect of codification of tasks is higher accuracy (aka fewer mistakes).
So far so good.
But you may notice that I have (and will continue to) clearly delineate between “automate” and “orchestrate”, between “task” and “process”.
The reason for that is that, simply, they are not the same thing. We should strive not to confuse these two because while the two share some benefits, there are other benefits that are achievable only by one or the other – or the combination thereof.
Process optimization, for example, can’t be achieved by simple automation. Automation is concerned with a single task – launching a web server, configuring a web server, stopping a service. Orchestration, however, is concerned with automating, if you will, the execution of a workflow – of a process. A provisioning process may be comprised of multiple tasks and involve multiple systems. An “application” is not just a single server, after all, it’s likely several servers – web, app and database in a traditional three-tier architecture.
The goal of orchestration is not just to automatically execute a service, which brings speed to the deployment process and gets applications into production faster. It also affords an opportunity to streamline – to optimize – those processes for even greater gains in deployment velocity.
One of the simplest ways to optimize a process is to eliminate repetitive steps. This entry on Vagrant explains it fairly well :
“We could just SSH in and install a webserver and be on our way, but then every person who used Vagrant would have to do the same thing. Instead, Vagrant has built-in support for automated provisioning. Using this feature, Vagrant will automatically install software when you
vagrant upso that the guest machine can be repeatably created and ready-to-use.” [emphasis mine]— Vagrant Docs “Getting Started | Provisioning”
Now certainly the step of installing a web server on a new box with vagrant is hardly all that time consuming, it’s just a single line of text. But every line of text must be manually typed, and that introduces the possibility of fat fingering the command, which either consumes time in fixing it or introduces an error into the system. Neither are desirable results.
Ensuring that the process is repeatable and orchestrated by automating all the tasks that comprise that process can optimize it by eliminating redundancy. That results in greater deployment velocity.
So while you’re “doing devops”, remember to evaluate the processes and consider whether or not they’re repetitive, and how you might be able to eliminate that repetition through more modern architectures or toolsets.
