devopsy.kinsta.cloud

Tag: enterprise

Provisioning versus Configuration Example

A few weeks back I wrote about the difference between configuration and provisioning noting, primarily, that there are differences between the two tasks. It remains an important distinction to make because it’s really where the rubber meets the road (or the app meets the network) where it becomes important. As the infrastructure/network side of the house is where we’re concentrating our efforts to apply DevOps, it’s necessary to dig a bit deeper on this topic.

So today we’ll examine couple of concrete examples of the difference – and why it’s important.

Your application is being deployed and it needs, wonder of wonders, a load balancer. Cause, elasticity. Scale. You know, cloudy type stuffs.

So you grab that golden image and launch that virtual machine with Whatever Your Favorite Load Balancing Thing might be (HA Proxy, Nginx, F5, etc…). Voila! You’re ready to go, right?

Not by a long shot. You’ve provisioned a load balancing service, yes. But is it configured? Probably not. In addition to the basic networking needed (IP addresses, VLANs, etc…) there are also a whole bunch of very application specific things that must be configured. There’s no “golden” load balancing service that can be generically applied to your application. Period. At a minimum the virtual server (that represents your application to the rest of the world) needs two things: an IP address and a pool of app instances to select from.

That means there’s some configuration that must occur after the provisioning. There’s no single LB image that will work for all applications, period. Even if all other settings are the same (LB algorithm, L7 app routing rules, TCP options, etc..) you still have to tell it which pool of real servers to select from and what IP address to use so clients can connect.

This is true for pretty much all application services (infrastructure) that support an application deployment. Because there’s no single golden image that just “works” for everything and no way to use dynamic configuration options for everything (DHCP for IP addresses is one thing, but there’s no “dynamic load balancing algorithm selection” service out there yet) there remain a set of options that must be configured after provisioning occurs. Consider application security like a web app firewall (WAF). It has to be configured to protect a specific application. It has to learn the URIs and the data expected to be exchanged so it recognizes when some interaction is out of bounds and potentially dangerous. That’s unique to the application, and thus it requires some specific configuration after provisioning.

It’s important to note this distinction lest we get caught up in believing that we can simply create a golden image of all our network infrastructure and services and put them into production with the touch of a button.

This little reality also helps to understand why it doesn’t really matter whether the network service in question is launched on custom hardware or some server off the shelf. The bulk of the work when automating the deployment of network services is in the configuration, not the provisioning.

While you can minimize the amount of post-provisioning configuration necessary, you can’t eliminate it entirely. That’s why API-enabled, programmable infrastructure is a critical piece of the larger DevOps picture. It is the API, programmable templates and similar capabilities that enable the configuration to be automated and orchestrated so as to not be the bottleneck in the deployment process.

September 2, 2014
Keep Calm and Refactor Operations

Developers have been refactoring forever to gain efficiencies and avoid mistakes. Let’s apply more than just theory to ops to do the same.

There’s about a million articles, blogs, tweets and infographics available today that bespeak of DevOps as this or that or the other thing. But one core truth remains: DevOps in part attempts to apply methodologies like agile to operations in order to gain efficiencies and avoid mistakes. We need the efficiencies because the number of apps that need to be deployed, updated, migrated, and maintained is increasing, not decreasing, and there simply isn’t enough time in the day (or during the monthly change window) to get it all done.

We need to eliminate mistakes because they are, according to data from initialstate, very costly. It takes 30x longer to fix one bug (an error) than it does to write one line of code. Anyone who has ever spent time chasing a wild pointer will immediately say that’s too low an estimate, but anecdotally I’m willing to go with that figure. It is an average, after all. To put that in perspective, the same data indicates that developers must find and fix 100 product bugs per 1000 lines of code. That’s a 10% error rate.

I’ll let you ponder for a moment what that means to DevOps and the desire to treat infrastructure as code.

Exactly. You probably want to avoid that kind of error rate as you go about automating and orchestrating provisioning, configuration and general management of all that infrastructure. Just a few errors can effectively negate time gained by automation. So how do you avoid that?

One of the ways to avoid some of that is refactoring.

Refactoring is most commonly used to extract pieces of code (script) that repeat over and over into composable functions (in a procedural language) or methods (in an object-oriented language) or services (in a micro-service or SOA-based system). It’s a primitive form of abstraction that serves to produce more manageable, extensible code bases.

Basically, you’re taking a set of actions that you repeatedly perform and turning them into a reusable, repeatable “thing”. In the case of operations that “thing” is probably a script.

Say, for example, that every time you deploy an application you’re also deploying a load balancing service because, of course, you’ll want it scalable and/or reliable. You always perform the same set of steps to complete this task with only a few changes – usually IP addresses, host names, or other network and app-specific settings.

But you’re doing it manually, or writing a new script every time. Manually making changes are, in most cases, where errors are introduced. Fat fingers are a common cause, especially when you’re not paying close attention because, well, boring! You’ve done this fifty million times and quite frankly, you’re sick to death of the tediousness of it all.

We’ve all done it, don’t pretend you haven’t both thought it was boring and made a mistake. You’re in good company, trust me.

What developers do when this is the case is refactor the common code and reuse it across the system. Those bits that get changed are parameterized and everything else stays the same. Even DBAs do this, they just call the resulting code a stored procedure.

The result of such efforts are self-contained automated tasks that, when used to orchestrate a process, enable composable operations. You string together a set of these scripts and voila! Provisioning complete, minus the fat fingered errors or missed manual steps.

Refactoring code is much more complex than this, of course, as would also be the case within operations, but the general premise here is that the practical application of DevOps includes the process of refactoring operations. It’s about restructuring it into more composable, logical and discrete tasks that can be automated and orchestrated as a means to achieve more manageable and extensible operations. It’s about identifying those steps in a process that are repeatable and can be refactored into a single, shared executable task.

When starting an initiative that applies DevOps it is likely you’re going to have to prove the time you’re taking is worth the investment. One of the ways to do that is by refactoring those operations that are continually used and reused to enable a more consistent, predictable and repeatable provisioning and deployment process. By choosing those steps that are most often repeated and refactoring them into their own composable scripts, you can gain efficiencies as well as reduce errors (and eliminate the time they require to find and fix).

August 18, 2014
Enterprises, DevOps and Economies of Scale

In infrastructure there are two economies of scale: operational and capital. DevOps should attend to the former, especially in the enterprise.

Soon after cloud burst (sorry, pun not intended) onto the scene we all learned about economy of scale because that, primarily, is what cloud computing’s business model is based on. At great volume, standardization can be used to achieve greater output and, thus, can cost less.

But there’s a second economy of scale at work with cloud; the operational economy of scale. If cloud providers scaled operations in the same way that enterprises traditionally scale operations, well, instance prices would be much, much higher.

What cloud providers recognized is that in order to achieve the economy of scale required to make cloud a success they had to address both the operational and capital economies of scale.

According to research, surveys and studies, operational overhead consumes anywhere from 63% to 80% of IT budgets. That’s just maintenance, management and general “keeping the lights on” kind of things. And each time a new application is pushed into production, that number gets bigger because there are more of everything – from storage to compute to network – to maintain.

To wit, Computer Economics “IT Spending and Staffing Benchmark 2014/2015” indicates that 67% of organizations were increasing their operational expenditures versus only 20% that planned on a decrease. Because IT budgets are generally determined as a percentage of revenue, that means operational budgets are chewing up the business, slowly but surely, and leaving little room for becoming an enabler of business rather than an application assembly line.

The holy grail, as its been described, for IT is to move budget from operational overhead to innovation. To do that means somehow magically reducing the costs associated with operations. Adding more people doesn’t help; that just adds more overhead. The goal is to do more with less; to increase the ratio of systems and services and applications per operator that can be managed. That’s operational economy of scale at work.

To do that, enterprises need to look to DevOps and its leverage of automation tools to enable leaner, more efficient operational processes. That means not just automating, but enabling a self-service model in which common provisioning and deployment processes can be orchestrated at the behest of the app or business owner. It means applying the same “gold image” standard used for provisioning and managing virtual machines to infrastructure; leveraging templates to gather the requisite input from app or business owners and automatically provisioning systems.

Limited variations on an infrastructure deployment template will enable customization where necessary, but otherwise provide standardized (stable) provisioning and deployment processes that can be self-service enabled. By empowering developers, app and line of business owners to provision application required infrastructure services, operations can use technology to scale to meet demand while lowering costs.

The goal of DevOps in the enterprise is not to enable 10 application deployments a day. It’s to achieve operational economies of scale and a more consistent, predictable and repeatable operational environment.

August 5, 2014
Mobile App Development Will Soon Grow More Enterprise-Focused

As the global mobile app market begins to swell, many consumer-focused developers inexperienced in the ways of enterprise development will soon follow the money to become better initiated, a new report out this month explained. Until then, the more mature types of development methods and tools that enterprise developers depend upon are still relatively scarce in the mobile app development community.

According to analysts with VisionMobile, which recently released its Developer Economics State of Nation Q3 report, mobile developers accounted for 12.6 percent of the global developer population in 2013, but the number of developers in these ranks is expected to grow to close to 5 million in the next three years. As things stand at the moment, more than two out of three mobile app developers currently target consumers. And even among those 27 percent who do focus on business users, 11 target individual business users—the independent BYOD early adopter type that many an IT department has struggled to keep up with.

That leaves just 16 percent of the mobile app developer population focused on the enterprise, with about half of them working in the enterprise environment and the other half in third-party or freelance situations.

Given those demographics, it is no surprise how few tools the entire class of mobile app coders uses during development. Currently, just 9 percent of these developers use any kind of automated app testing tools, only 16 percent use crash and performance monitoring tools, and just 21 percent use beta testing tools. Even the use of cloud computing tools lags, with just under 30 percent using services such as AWS or Heroku to aid their development.

It’s a perplexing problem, according to the report’s authors.

” Developer tools add value at every step of the developer journey from prototyping through to customer support,” the report stated. “It makes sense that hobbyists with no intention of making money from their apps would avoid tools that might incur costs at some point. However, 26% of developers that are interested in making money don’t use any third party tools.”

This could potentially change as the economic incentives for more mobile app developers to shift to the enterprise and business users push them to create the more dependable apps features that these users demand.

According to VisionMobile, overall the app economy stacked up to $53 billion in 2012, and its analysts predict 28 percent growth annually through 2016, when the market will reach $143 billion. Currently, the enterprise market leads the pack in terms of revenue generation opportunity, with developers focused on enterprise audiences far and away leading the pack in revenue from their apps, followed by those focused on individual professionals.

“Smartphones and tablets were introduced as consumer-first technologies, which led to developers initially building consumer apps. Now a growing number of enterprises are adopting mobile technology; this is all businesses, governmental and non-profit organizations, not just large corporations with IT departments,” the report said. “The platform owners are providing clear signs that there is much greater enterprise adoption and significant opportunities for developers to come.”

In an earlier report this year, VisionMobile predicted that the business and productivity market will double in size by 2016, reaching $58 billion by then.

July 31, 2014
Provisioning versus Configuration

There’s a ton of hype and excitement surrounding containers, a la Docker, today, much in the same way virtualization took the data center by storm. In both cases, the excitement for operations focuses on the ease with which infrastructure might be deployed and managed via such technology.

Whether container or hypervisor, however, there remains a distinct difference between server and network virtualization that must be considered before getting too excited about the possibilities.

There are two distinct use cases for which virtualization and containerization of anything are considered beneficial: scale and deployment.

Scale

In terms of scale, both virtualization and containerization are excellent technologies. Both can fully encapsulate a service – whether application or network – and enable rapid deployment of multiple instances of the same service with very little (if any) post-provisioning requirements. This is the premise upon which cloud computing and NFV is based: clones of services and applications rapidly deployed to enable elastic scalability that matches demand.

For scalability purposes, virtualization or containerization of services is a match made (mostly) in data center heaven.

Deployment

Enabling rapid deployment of new services using virtualization or containers, however, is not necessarily going to net the same benefits. It is important note that the standardization and APIs associated with virtualization and containers that enable scalability so seamlessly is focused solely on the management of the container or virtual machine. The ability to provision a virtual machine or container is not at issue; APIs enable the rapid provisioning of a container or virtual machine with extreme alacrity.

What those APIs do not do is enable the rapid configuration of those services once provisioned.

Configuration != Provisioning

This is a critical differentiation that must be made lest we assume we can leverage virtualization and containers to enable a self-service style data center, a la IT as a Service. While virtualization and containers make provisioning a service instance a relatively painless experience, configuring those services must still be accomplished. When deploying a new service, existing configurations will not be wholly valid. There will always be some amount of customization that must occur, if only to make sure the service is interacting with the right application.

This means that once provisioning of the service is complete, there is still work to be done. One does not simply launch a load balancing service, for example, without instructing it how to distribute load (what algorithm to use) and to what set of servers (configure a pool).

It is important to recognize the difference between these two steps in the deployment process and take into consideration the impact of configuration after provisioning on that process. Depending on the method of configuration, this step can have a serious impact on the speed and efficiency of the deployment process as a whole.

It is also important to note for monitoring purposes, as virtual machine health and status is not the same as the health and status of the service, whether that be an application or a network service. Both must be monitoring and managed in a virtualized infrastructure to meet MTTD (mean time to detection) and MTTR (mean time to resolution) objectives.

In most cases, the impact from configuration is the greater of the two, with its time requirements most significantly impacting the application deployment lifecycle. It is optimization of configuration processes, not provisioning, that will ultimately provide the biggest benefits for DevOps in terms of reducing errors and improving time to market.

July 10, 2014
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.

June 16, 2014
Enterprise DevOps: organizational change a must

There has been a lot of discussion in the blogosphere, including here at devopsy.kinsta.cloud, lately about the challenges of adopting DevOps in the Enterprise space. These challenges at the end boil down to the need for organization change. There are organizational structures that appear to hinder DevOps adoption in large enterprises, that are inherent to enterprises and smaller companies do not have. In enterprises different functional teams – Dev, Ops, Security, QA, etc. may be under totally different management chains. It is not uncommon to have to go up thru several layers of management to reach a common senior executive. In other cases, there may be an entire software supply chain in place that is made up of not just internal but also outsourced or external suppliers. These suppliers may or may not ‘play ball’ when it comes to the changes in processes required to adopt DevOps. Especially if they are bound by outsourcing contracts that do not make change possible or profitable for them.

DevOps as a philosophy has had as its centerpiece the principle that all the application delivery teams (Dev, QA, Ops, Business Analysts, Architects, Security…) need to align better and collaborate towards the common goal of delivering applications, in a efficient and constantly improving manner. This is a people and organizational principle, not just a process centric principle. To me adopting this is more important when adopting DevOps than any process or tool.

This post discusses key guiding principles on which this DevOps driven alignment of different teams in an enterprise should be based. They are designed to improve collaboration between these teams and to break down the proverbial ‘wall’; to end the water-SCRUM-fall, when it comes to the relationships between the different application delivery stakeholder teams in the enterprise. This is not an easy effort. It depends on the existing culture at the organization, the presence of outsourced suppliers, politics, contracts and above all, the desire to change.

These guiding principles are:

1. Shift Left:

Organizationally the goals of DevOps are to bring all the teams involved in application delivery together closer. Not just at deployment time, as they may do already, but all thru the delivery cycle. It requires Ops to allow Developers to take more responsibility of the operational characteristics of the applications they are building, for example. In turn, it requires Developers to keep Operational considerations in mind while building their applications. It requires analysts and architects to think holistically and work with Dev and Ops teams as they design and enhance the application. This is referred to in the DevOps world as ‘Shift Left’. As in shifting towards the left, Ops responsibilities. Shifting it to earlier in the software delivery lifecycle, towards Dev. It is shifting left the testing of your software to as early in the lifecycle as possible. It is shifting left the point at which collaboration between teams begins. It is shifting left the responsibility to deliver code to production – way left. Can someone in finance be held responsible for code not being delivered on time because they delayed approving a budget line item?

2. Collaborate across all teams:

Different functional teams typically use different tools to manage their projects and activities, for change management and (outside of email) different collaboration tools. In order to better collaborate across the organizational boundaries, all teams should start using the same Change Management and Work Item Management tools or in the worst case, use tools that are integrated. This allows seamless visibility across tools and traceability between respective Change Requests. Real-time collaboration using a common tool is obviously the best scenario.

3. Build ‘Application Aware’ Environments:

As we move towards Software Defined Environments, we have the ability to build, version and manage complex environments, all as code. All of the benefits of this are moot if the environments are not a perfect fit for the applications and more importantly the changes to the applications being delivered. The goal is hence to build Environments that are ‘Application Aware’ or are fine-tuned for the applications they are designed to run. No more cookie cutter Virtual images for all kinds of applications. More importantly, one needs to ensure that the environments are architected in a manner to allow for the evolution of the applications, both as they are developed; as they are projected to change or as they may evolve in the future. This obviously, would require close collaboration between Dev and Ops. Development Architects and Product Managers need to work with the IT Architects and Operations Managers to architect environments and their projected evolution to align with that of the application. Not only that, but also allow enough resilience in the environments to allow for unexpected change. For example, massive change caused by a super successful App. Think Instagram and how the founders had to keep changing their server environment almost daily as millions joined their service.

4. Environment Sprints:

Agile Development Principles prescribe that at the end of every Sprint, developers have a build. An executable build that runs, even if does not do much in terms of functionality. The next evolution of this concept is to extend it to environments. This would mean that at the end of each Sprint, the Dev team would have an executable AND the Ops team would have an environment, a production-like environment ready that the executable can be deployed on. This would allow the build to be tested. That too in a production-like environment. This would also provide immediate feedback to the Ops teams on the behavior of the application in their environment and use that feedback to improve the environment. This requires the Ops and Dev teams to align better. They will both have to use a single Sprint plan for releases – of their Builds and Environments respectively and will provide feedback to both at the end of every Sprint, using which Dev can enhance their Apps to improve functionality and performance and Ops can enhance the environment for the same. Leveraging full stack deployment – deploying at each instance the full stack that includes the environment, middleware and the application being deployed – could very well be called the ‘holy grail’ of DevOps. (Brief commercial break – IBM just announced the new offering UrbanCode Deploy with Patterns that provides full stack deployment leveraging OpenStack HOT patterns).

The Human factor

These principles are designed to foster Application Delivery team alignment from a teaming perspective, from a people perspective. These however do not replace the need for good old team building. Whether it is thru face to face get togethers or in todays distributed worlds, thru regular virtual meetings and online collaboration in real time. The best teams are the ones where the people know each other, trust each other, look out for each other and when there are challenges, know who to pick up the phone (or launch Skype) and talk to.

June 11, 2014
Let DevOps be a business process

I just returned from an amazing time at the first Camp DevOps in Boulder, CO. It was held at University of Colorado, Boulder and in conjunction with Gluecon 2014. This is the first conference I have attended that was singularly focused on DevOps. I found the three track format at the show had something for everyone. A technical track, a business track and some great DevOps round table discussions with great panel speakers. My takeaway was that DevOps is not just a cultural thing as some claim. DevOps needs to be perceived more as a business process or it will just be a passing fancy. Some may disagree with that view but 35+ years of IT industry experience gives me a bit of a long view.

Gene Kim enlightened me on some issues in his recent response in the Wall Street Journal with some facts about what is going on within traditional legacy Fortune 500 companies. They are implementing DevOps strategies in a big way. My take is that it is not noticeable within the Fortune 500 because DevOps is viewed by the Fortune 500 as a business process, as opposed to being an implementable organizational structure. Sort of like the DevOps is not really a job title argument. If it is a business process, no one has DevOps in their title, but it doesn’t mean DevOps is not being done there.

I think most of us want to see DevOps cross the chasm and become a de facto standard. Since Patrick Debois first coined the term “DevOps” there is no question that DevOps has developed into a global movement. Of course DevOps has its cynics. Pessimists say DevOps is a new name for a Sys Admin, the flippant say DevOps is just a front for some fanatical developers trying to liberate the world from operations or DevOps is just some foolish operations people trying to make nice with Developers. That it means the extinction of QA job is another familiar mantra.

I’ve spent a lot of time trying to understand the lack of cohesiveness within the DevOps movement and everyone telling everyone else what DevOps is and what it should be. As with anything else the marketplace will decide the future and fate of Devops. During this process, I’ve begun to notice a common misconception that I think is fueling much of the reactions that some people have to DevOps ideas. Holding DevOps back is not a technology problem or a cultural problem.

In order for DevOps to happen I realized we all need to keep pushing this philosophy forward. We cannot worry ourselves with culture, commercialization or technology. Technology plays a critical role in facilitating solutions to DevOps problems. However, DevOps itself is, at its core, a business issue. The most fundamental business process in any company is getting from concept to completion with the end result of profitability.

If you remove the perspective of the business process, what is left? You’ve got a whole lot of people and groups doing their own thing. Lost is the motivation to battle inefficiency, duplication of effort, turf wars, and disparate groups. It’s a free for all.

If we don’t let DevOps take its course within the market place and embrace the business process, jobs are lost. We are able to do what we do because of the business of DevOps. If we don’t all push the commercialization of DevOps then we have nothing but a chat room to talk philosophy.

The sole purpose of DevOps is to enable, big and small alike, business to react to market forces quickly, efficiently, and reliably. Without the commercialization, there is no other reason for us to be talking about DevOps problems, much less spending any time solving them.

May 29, 2014
DevOps and Enterprises, it’s a culture thing

Today author, DevOps evangelist and devopsy.kinsta.cloud Advisory Board member Gene Kim published an article in the CIO Journal of the Wall Street Journal. The article was a response to an earlier article by Rachel Shannon-Solomon in which the author claimed that DevOps was not likely to be successful in the enterprise at least not at the present time. Rajat Bhargava, CEO of JumpCloud and another Advisory Board member of devopsy.kinsta.cloud wrote the below in support of and amplifying Gene Kim’s thoughts in the WSJ article.

Recently an article was published in the WSJ CIO Journal that DevOps likely won’t work for enterprises – at least not now. The author goes on to state that there are structural impediments to enterprises adopting DevOps including siloed organizations, lack of platform technology, cultural issues, and lack of ROI. I completely agree with the author that enterprises face an uphill battle on the implementation of DevOps. She is right that they have different structural challenges than startups or SMBs.

DevOps bring companies close to customers

However, I have to flat out disagree with her conclusions and many of her data points that are extrapolated into the conclusion that DevOps won’t work in the enterprise. Let’s start at the beginning where the author states that DevOps is “…a software development method that stresses communication and collaboration between developers and IT professionals (QA and ops)”. I’m going to respectfully disagree with that definition. DevOps as a name is a misnomer. DevOps is about collaboration and communication, but not just between developers and ops in the enterprise. This is about communicating across the whole company: sales, marketing, finance, security, and any other relevant area. DevOps is about increasing company performance through better IT execution. The hypothesis is that by more closely aligning what cus with what gets built in a more timely fashion, organizations will sell more products and services. That’s not a small company or SMB issue, that’s an every company issue.

The author continues by saying “…the value of implementing devops beginning in the early days is clear—achieving radically higher productivity at lower costs resulting in more reliable systems.” I have to disagree here as well. DevOps is not about higher productivity at lower costs resulting in reliable systems. That may be a byproduct of DevOps, but the goal of DevOps is to more closely build what customers want in a shorter timeframe. DevOps is about cycling a product or service quicker to have it match more closely what the need is in the market. From there, if that holds, the organization will sell more products and services. DevOps organizations hope that it will be cheaper and more reliable but it very well may not be right away. In fact, DevOps may be more expensive if you factor in the time and energy required by the organization to run much faster product release cycles.

DevOps: a cultural shift

Unfortunately with those fundamental tenets at issue, the rest of the article becomes harder to agree with. The author states that there aren’t any real legacy vendors for DevOps which is a matter of perspective. DevOps isn’t about the vendors or tools ultimately. It is about culture. Every legacy vendor out there is going to adapt their tools to work with DevOps methodologies. Some will succeed. Some won’t. “Shiny” new startups will also compete for the business, but in the end, it’s not about the vendors or tools for enterprises. It’s going to be about cultural change.

The author is right that silos will make a difference in the pace of adoption. Enterprises are big, complex animals. Cultural change at these organizations is next to impossible. Add in departmental and divisional factions and it’s even harder. But cultural change has happened before and it will again. Will it be easy? No. Will it be fast? No. Will it be free? No. But it will happen. Or the company will fall behind, because their competitor will be able to move faster, innovate quicker, and introduce new products and services.

The next challenges described focus in on selling to enterprises and the lack of hard dollar return on investment. The first focuses in on vendors trying to sell to enterprises. The author states that enterprises are predisposed to buy. She’s correct that it’s hard to sell to enterprises, but many startups and larger companies have solved that problem successfully before. Historically, that hasn’t been an impediment to adoption of technologies. Does it take longer? Yes, it does, but if the technology is powerful and enterprises believe that it will help them, they will look for solutions to those problems. The lack of ROI is an interesting observation. As with many things in IT, ROI is elusive and it likely will be with DevOps early on as well. Over time, though, DevOps should be a clearly measurable activity. Product cycle time, defects, and ultimately revenue and profit will be measurable. Whether DevOps is contributing to the bottom line or not will be evident and clear – just maybe not in the short-term.

Fundamentally, DevOps is a different animal at a startup than at an enterprise. This is a topic that we have studied before. The WSJ perspective is an interesting one and can be taken in the right light as a cautionary tale. Enterprises do face different challenges when it comes to DevOps – or any cultural change for that matter. DevOps at an enterprise is a cultural challenge first and foremost. Those enterprises that embrace it as such and focus their efforts on that area first will likely have more success than those who treat it more as a tool issue. There are countless successful enterprises leveraging DevOps. Gene Kim’s response makes that clear. Gene, has been studying these “unicorns” and “horses” and so his response is based on the enterprise DevOps adoptions, successes and failures he has observed. I look forward to more data coming out soon that will shed more light on DevOps in the enterprise.

May 22, 2014
DevOps Needs a Tsunami To Jump The Chasm

All start up business endeavors must go through the phase of crossing the chasm. Most of those business endeavors usually fall prey to the chasm. The chasm is this black hole that everyone claims to understand but no one truly does. We have all seen businesses cross the chasm or fail to cross the chasm and fall into the black hole. But no one seems to understand why and how that crossing happens. The bestselling book by Geoffrey A. Moore titled “Crossing the Chasm,” is all about the heart and soul required to get early stage technology across the chasm, from early adopters to mainstream customers.

There is a big difference between people who are enthusiastic to try leading edge technologies and the rest of the inhabitants, who tend to be much more conservative. The reasons that people spend time trying to figure out how to cross or jump, if you will, the chasm is because that black hole is what stands between them and making their fortune. The early adopters are just a small sample of the market and there is no money in building a business or technology around them. To make real money, you need to cross over into the mainstream.

In Geoff’s model, the innovators are all about technology. You know those people, when a new iphone is released, they spend days standing on line to get latest and greatest new technology. The early adopters are the visionaries that are always on the bleeding edge. The mainstream are the pragmatists, the people who practice risk avoidance. These pragmatists are the key to jumping the black hole, they move the needle.

DevOps first order of business was getting on the curve and to that end DevOps has evangelists. But, understand that what worked in converting these early adopters probably won’t work for the pragmatists. These DevOps evangelists and visionaries want DevOps power tools, as opposed to the pragmatists who simply want to push the button and say “that was easy”.

By all appearances DevOps has been accepted by the early adoption set. Just how does DevOps cross the chasm? Jumping the black hole after all can be quite a daunting task. To do so DevOps has to create what I refer to as the tsunami effect.

The Tsunami effect is where DevOps gains acceptance in multiple industries or markets in what seems like a gold rush, it’s here that fortunes are made. More accurately, it’s where cult communities transform overnight into mainstream communities. Many technologies simply create a single tornado which remains in a silo forever never gaining enough momentum to really emerge. Another common path what I call an earthquake, there is a lot of hype but it tends to fizzle out quickly, if not tended to properly. Right now DevOps has all the appearances of an earthquake, Devops evangelists have created a lot of buzz, but acceptance beyond a set of power tools is still a huge question.

Considering DevOps is in the earthquake phase, as opposed to the tornado phase, DevOps cannot be successful converting one group at a time. The strategy in the tornado phase is convert industries and markets one at a time, via tornados forming within industries or markets. The tactical execution is to get smaller industries or markets committed and therefore the larger industries or markets will then embrace the movement. That is simply crossing the chasm. DevOps has too many cultural implications to convert believers over a long period of time; DevOps requires reorganization, not a subtle shift.

Since I consider DevOps to be in the earthquake phase, crossing the chasm is not an option. DevOps must jump the chasm in a surge of overwhelming momentum, hence creating a tsunami. DevOps has created a very closely knit culture, DevOps needs to push hard to create a tsunami and flood the pragmatic population. But, be advised, DevOps has to be all but universally accepted, there is no almost in bringing together Dev and Ops. But if DevOps wins, it wins big, DevOps will go from being a niche culture to a truly mainstream practice.

So what’s the strategy to create a tsunami? And more importantly, how do you move beyond the earthquake phase? Here’s how I see it according to Geoff, with my DevOps spin: First, DevOps must clearly establish that the mission-critical software development process is broken and is causing management enough pain that it would gamble on unproven methodology that is populated with a bunch of prima donnas. I am not convinced the DevOps cult has clearly established this as fact. Is the development and operations process broken or have just new power tools been created to improve speed and accuracy? Second, DevOps needs to present the total solution, not just tools. Overwhelm the community; each new DevOps tool should leverage the success and technology of the last hence creating a methodology. Even more importantly, because the DevOps tools are closely related, credibility can cross industries and markets and create the momentum required for a tsunami. Once Devops has reached critical mass by providing the total solution in a few industries or markets simultaneously the tsunami is created and DevOps has jumped the chasm.

The tsunami will emerge suddenly with everyone seeming to adopt DevOps all at once. This will result in explosive growth and will pull, willingly or unwillingly, everyone into its path. It’s driven and sustained by the pragmatists. Here, everybody has to get the latest thing all at once; the masses have been converted to DevOps. DevOps needs mass-market success, DevOps needs to become a tsunami and everyone will want to play DevOps.

Now that you know the formula, go forward and create the perfect storm.

If you would like to say something; email parker@devops.com and don’t forget to comment here.

April 10, 2014