devopsy.kinsta.cloud

Author: contributor

Performance Testing: The Unexpected Missing Link in DevOps

It is no secret that DevOps and continuous delivery goes hand in hand in the enterprise, but how do processes such as performance testing fit in to the equation?

Many enterprises still harbor the traditional way of thinking—that the QA and performance testing group is completely separate from the development group. A widely held myth is that each has different roles, responsibilities, backgrounds and areas of expertise. However, with DevOps gaining popularity in the enterprise, the distinct separation between testing, development and operations is no longer. In fact, to successfully implement performance testing, the once-siloed departments must work together.

Creating a Culture for DevOps

The most common purpose of DevOps is to have an automated pipeline of software and application deployment updates. An enterprise cannot implement DevOps unless all are on board, from the top down. To do this, there must be buy-in from not only the software engineers and technology buyers, but also the C-suite. This ensures DevOps processes and strategies are being implemented appropriately.

However, it’s not just about getting the tools needed for DevOps; there must be a culture shift toward collaboration for it to be effective. That is when an enterprise gets the most from the shift to DevOps and becomes the most agile.

Once DevOps is embraced, experts and power users can help facilitate how it is being used to drive maximum benefit and help the organization get more from it. The key way to determine and evaluate this maximum benefit is through continuously testing throughout the development process. While the first thought may be for “functional” testing (to ensure code operates without errors and to provide fast feedback to developers when things go wrong), no organization can afford to release applications that deliver slow user experiences, and so “performance” testing with fast feedback is equally critical. Continuous testing is only scalable and sustainable if it is automated.

DevOps Makes Load Testing Easier

A key benefit of DevOps is that automation makes everything—from implementation to functional and performance testing—faster and more predictable. Tool chains ensure that the “right things” are done with every code push. A concern commonly cited by those who have not yet implemented performance testing is that it is “too time consuming” and they will be unable to facilitate different tests at the rate they need to be done to be effective. But surprise! Organizations that already practice DevOps are in a better position to add performance testing to the mix, in a fully automated fashion. A solution like BlazeMeter takes just minutes to get API tests up and running, by just adding the HTTP transaction for specific pages or endpoints to test. Once set up, these tests will continuously run automatically and will notify the team when there are any problems or potential problem areas. When there are known surges in website traffic, more Uniform Resource Identifiers (URIs) can be added to the test, but this will not impact the autonomy of it.

Another key function of DevOps is scalability through the enterprise, and scalability of user traffic is extremely important. While performance testing would still scale without DevOps, operating on the same principles makes each concept more relevant to the folks who are analyzing the outcome of both. The key is to integrate performance testing directly with an already existing continuous delivery or integration pipeline, such as Jenkins or CircleCI. Here, fast, small-scoped performance tests are able to run in parallel to ensure performance is as expected before promoting a build to the next stage. Tests run in staging or QA environments, such as IBM BlueMix or Chef, can also be automated and integrated.

Performance testing is also important not just because of its easy integration into DevOps practices and how it fits into the CD pipeline, but the overall customer experience as well. A properly functioning webpage or mobile application is the connection between your brand and your target customer, and if it doesn’t load properly or in a timely manner, you may lose a customer to a competitor. Performance testing ensures the user doesn’t experience slowdowns or the dreaded downtime, which is often the result of a poorly functioning back-end system. Incorporating performance testing into workflows creates a centralized environment where all team members have what they need to design, run or analyze tests, while communicating quickly and clearly with each other and everybody in the enterprise.

Performance testing and DevOps are not opposing forces; and performance tests run automatically within the tool chain save time, rather than consuming more. The reality is that during this age of rapid software delivery, testing is the glue that keeps the development process on track and high quality. Performance testing should be part of every software delivery workflow, and DevOps is allowing that to happen.

About the Author/Michael Sage, Chief Evangelist

Michael Sage brings a 15-year career of enterprise software pedigree and customer success to BlazeMeter. Prior to BlazeMeter, Michael (better known as “Sage”) was a solutions architect and consultant in software delivery and performance management. He has worked with industry-leading companies including Mercury Interactive, Hewlett-Packard and New Relic, helping teams implement integrated solutions that enhanced the performance and experience of their customers. A self-taught hacker and open source evangelist, Sage always has the pulse on the cultural zeitgeist inflected with a heathy dose of humor.

February 11, 2016
At the Intersection of Git and DevOps

Everyone knows Git. It’s a favorite developer tool and for good reason. Developers love its flexibility, speed and ability to branch locally and in place. It also appeals to the attraction to community development.

But as developers adopt Git within enterprises, IT managers face the challenge of reconciling the needs of developers with the needs of the larger organization, especially when it comes to DevOps. In this article, we will examine some of these challenges and suggest best practices that can alleviate them.

Performance

IT organizations often rely on performance and low latency as key indicators of the adoptability of any solution. Speed tests run against Git’s network operations generate impressive results, since the Git protocol for transferring data is highly optimized. Over time, however, an internal implementation reveals limitations that can impact the speed and efficiency of the delivery pipeline.

First, Git works very well for small projects. Yet, when projects grow larger, many teams will feel the pinch of its all-or-nothing architecture. A developer who needs to work on a project must retrieve (or “clone”) every file associated with it. For enterprise software, this necessity is not always feasible or desirable. Large projects can require a lot of disk space and time to clone, even though much of the repository content may not be relevant to that developer. The all-or-nothing approach of a Git clone also compromises security—users will have the same access to the whole repository, whether they should have it or not.

Second, Git is optimized for fairly small assets, such as code and configuration files. But many organizations need to version large binary files such as images, videos and CAD designs. Large binary files are also often the product of the build system. Such content can quickly bloat the size of a repository and, by extension, the file systems of contributing developers. A less obvious issue with large files is the fact that some Git functions require the calculation of hash values over the contents of the repository. As a result, large binary assets can inexplicably reduce some operations to a crawl while others execute almost instantly. To address these issues, you should employ an external store for your large binary assets. There are no formal standards for external asset stores, but there are options available, including git-annex and Git LFS.

The solution that Git offers is to separate components into dedicated repositories or to use Git submodules. Both approaches lead to what is known as Git sprawl, a condition that increases complexity and risk. Git sprawl can be avoided using the narrow cloning approach. Narrow cloning enables developers to retrieve just the subset they need from the contents of a code repository. Although the developer community has long requested this feature, Git currently provides no support for narrow cloning. For these reasons, you should standardize on a Git management system that offers narrow cloning, while using shallow cloning as much as possible to limit file revisions.

As long as repositories are logically divided along component lines, developers might not experience any immediate problems with Git sprawl. Build and test teams, by contrast, are likely to feel the pain immediately. Trying to find all the correct and related revisions of files from many different repositories is an expensive and risky process. Builds will frequently fail if the input files are not correct. The ideal agile workflow supports build and test on every check-in, especially on the mainline. If builds frequently fail, the build and test system will not be able to keep up with the development pace and will slow down the entire DevOps pipeline.

Another bad practice that can result from Git sprawl is having inconsistent or conflicting branching models for different teams or repositories. Dealing with the idiosyncrasies of individual developers or teams is needlessly frustrating and inefficient for the build and test teams. But Git provides no support for defining or enforcing branching strategies across multiple development teams. For this reason, it is critical to define an overall branching strategy, socialize it throughout the organization and review practices on an ongoing basis.

Hosting

Hosting options for cloud deployments of Git are plentiful. Organizations embracing Git need to evaluate these options carefully because the choice will impact not only information security but also DevOps. Developers generally seek options that make it easy to create new projects, clone or fork and push their work, preferably with great review tools and a simple method to deliver units of work to the master branch.

The developer’s desire for ease of use is often at odds with DevOps’ need for scalability. Available Git management systems vary significantly in their capacity to support enterprise IT, with capabilities ranging from single-server topology all the way up to clustering and, in some cases, high availability. Note that none of the solutions supports disaster recovery. Therefore, organizations need to identify tools for backup and recovery, while also defining internal processes to ensure the system can be restored after a catastrophic event.

Security

Developers’ need for speed and customizability also often run counter to the enterprise’s need to protect the intellectual property locked away in Git. The key issue is that Git lacks a robust and manageable mechanism for fine-grained access control. Git is limited to providing security in the form of authentication; users must present credentials (username/password or SSH key) to access private repositories. Once the user has accessed the repository, Git has no way of controlling what that user does. While this works well for democratized, community-based open source development, it creates security holes and compliance problems for enterprises.

For these reasons, it is critical to think through the necessary roles and permissions that will enable developers and DevOps to do their jobs, while minimizing the risk incurred by hosted Git solutions. Personnel should always be provided with “least privilege” access to assets—that is, they should be given only the permissions necessary to complete their tasks. For compliance purposes, it is often necessary to provide logs showing who did what when. This requirement is especially true for enterprises in regulated industries such as health care and finance. Git, however, gives users the ability to destroy virtually every form of historical evidence. Again, this is useful for developers, but detrimental to information security and governability.

In summary, DevOps is penetrating enterprise IT departments at the same time that Git management solutions are proliferating. The differences among competing Git management solutions become most apparent in the context of DevOps. Remember, DevOps has to manage everything across the application lifecycle. Evaluating Git solely from the perspective of development teams, without considering the requirements of DevOps, can be a recipe for the failure of your DevOps initiative.

About the Author/Mark Warren

Mark Warren is Product Marketing Director at Perforce, based in the United Kingdom. Mark has more than 25 years of experience working with development and product management teams in software development tools and configuration management.

February 10, 2016
Force Multiplication
Recently, I have found myself reflecting on the statement, “Be a force multiplier.” This usually comes to mind when faced with some sort of burnout: hearing it indirectly from a colleague or friend, or experiencing it firsthand. The intent is good and aligns well with some core tenants of DevOps. Force multiplication fits into the DevOps ethos by encouraging the need to cross-train and collaborate. By working together and sharing knowledge about respective domains (development or operations), team members gain empathy for each other. This in turn has a downstream effect of now enabling better collaboration around the repair/growth/operation/expansion of the delivery pipeline.

The only challenge I have seen over and over again is that one or more major bottlenecks exist by the time this idea of “force multiplication” is needed in a team. These bottlenecks are often real and result from an imbalance of resources: servers arriving faster than there are resources to rack/stack/configure/turn up. Database administrators cannot handle the number of schema changes needed to be reviewed/tested/deployed. Developers must wait on a certain person or people who have access to publish a package before it can “go live.” You probably have your own bottleneck that you see very clearly in your own mind.

The next question: Have you (or someone you know) attempted to be a “force multiplier”? The answer always is complex, but a there is always a common theme in noble attempts at team cleanup: lack of training. Think about it: Have you been taught how to be a force multiplier? How to build well-formed teams? How to effectively pass on knowledge? To compound issues even further, our current incentive structure actually celebrates the “heroes” and “unicorns” of the world, calling out these as examples of success. Our economy rewards those first to market, and team-building and normalization often are not high priorities for budding startups today. Unless improvement efforts have a direct impact on the bottom line, often it isn’t a priority. The folks that are brave enough to still even take on the challenge of being a “force multiplier” in these conditions often find little success because knowledge transfer must happen in synchronous fashions: code-pairing, over-the-shoulder demonstrations, etc. These are expensive activities in both time and energy. Opportunity cost is now lost because one resource is cross-training another. Eventually the benefits will be realized, but not today …

The amount of work is too large. As a result, the can is kicked down the road until such a time that the pain is unbearable and something must be done. At this point, everyone wants to burn down the offending code and start again. But next time, we’ll learn. We won’t make the same mistakes we did last time.

Bite-sized changes

The problem is that when looking at the road in front of you, you’re constantly optimizing for the next day or week as opposed to months and years ahead. In the world of quarterly returns, this is the incentive that drives us. Thus, by the time problems are real problems, it is easy to immediately begin the bikeshed conversation and begin designing v2. The next step is to re-adjust the optimization factor. Growing the meat-cloud and getting additional resources often takes too long (three-to-six month onboard time, at least), the time cost of cross-training can be too much, and overworking resources can only go so far. What is the answer?

Level the playing field

One of the ideas that I share around ChatOps and Event Driven Automation is to expose small tasks to users. By doing this, you allow team members and others in your company to “consume” actions that you curate. As the curator, you can expose safe actions to users and allow them to do things once relegated to a single individual or team. I’d like to share a real-world story with you and show you how we solved it.

Bottlenecks at StackStorm

Recently, our team was bottlenecked in releasing updates to our Puppet module for StackStorm. The team could make changes all day long in the test environment, but getting changes out to the world depended on a single person releasing code to the Puppet Forge. Obviously, this was not ideal.

Let’s break it down. To release a module to the forge, a user must know:
- Know how to make a change to the puppet module
- Update module itself
- Update metadata
- Update git repository (tags)
- Know how properly package up the module for release to the forge
- Know the credentials for the Puppet Forge
At face value, this seems minor—just throw these commands into a README, and let others just copy/paste commands. But, my team is not full of Puppet experts. They are developers, eager to help solve interesting problems. But because of this barrier to release, the natural reaction was to shy away from making changes—not because of capability or willingness, but to avoid the pain of friction involved with releasing the code. This meant that any change to the codebase usually required at least two people (change and release). Likewise, any changes that were small or simple naturally got relegated to Puppet people because they knew how to manage the debt and navigate the waters.

Instead, let’s sprinkle some magic ChatOps dust.

The Setup

First, let’s set up our user interface: ChatOps. User experience is a topic that will come up over and over again with ChatOps, so the best place to begin is to decide how to expose commands to colleagues and users. The first thing to set up is the ChatOps Alias.

Source: https://github.com/stackstorm-packs/st2-publish_puppet_forge/blob/master/aliases/publish-puppet-st2.yaml

I want an all-encompasing command that a user should have to input a minimal amount of information toward. The goal is to have a big red button that can be mashed, and magically a Puppet module is released. This should now happen anytime a user types in !puppet publish puppet-st2 … StackStorm will run the stackstorm.publish-puppet-st2 action with the branch attribute set to whatever the user types in. We choose to reuse the puppet namespace since it is already populated with similar actions.

The next step is to set up some accompanying Action Metadata for the new stackstorm.publish-puppet-st2 action. We’ll want this to run a new workflow that will take care of all the actions we discussed above. The only variable that I need to get from the user is the branch parameter, so writing the metadata should be a snap. We’ll only take a look at the workflow today.

Source: https://github.com/stackstorm-packs/st2-publish_puppet_forge/blob/master/actions/workflows/publish-puppet-st2.yaml

At the top of the file includes our vars section. The puppet-blacksmith application was not built to be run with multiple users, so our workflow needs to be able to adapt. As such, we need to know that the gem will expect a credential file (forge_file) with a username (forge_username) and password (forge_password). We also need to know where our staging directory is (repo_dir), where the upstream target is (repo_url). Simple enough. The next few steps, clone-puppet-module-from-git, bootstrap-puppet-module, cleanup-vendored-gems and set-puppetforge-credentials ensure the build host is setup properly. These actions serially download the repository from Upstream, runs all bootstrap commands, attempts to ensure a pristine directory, and then sets up the puppet-blacksmith forge file. At this point, nothing has actually been done, just some preparation.

It’s important to note the third step here (cleanup-vendored-gems): This was a small step that often was forgotten and ended up creating archives in the size of megabytes as opposed to kilobytes, which is more reasonable and expected.

The final steps—tag-puppet-module, build-puppet-module, upload-module-to-forge and push-git-tags—are where the bulk of work occurs. The next steps are focused on running several rake tasks, as well as then tagging the git repository and republishing the package upstream. Most of these actions were enabled by the puppet-blacksmith gem, but now are encapsulated in a nice workflow that is easily consumable.

And sure enough, if you build it, they will come …

slack slack_1

Techniques like this directly enable force multiplication within your team. Essentially, your role shifts from a person “responsible” for delivering to the person for “enabling” delivery. This is a very small example, but powerful. Enabling others on your team to be a force multiplier enables them to keep working, enables you to focus on more important things and also creates a new degree of transparency that may not have existed before. Everyone knows when software is released; anyone has the ability to do this. Add up enough of these small building blocks, and suddenly team members are more apt to take risk and help drive change knowing there is a safety net behind them.

Worth consideration

Two very interesting points were presented to me that are worth discussion here:

Agile Manifesto, rule #1: Individuals and interactions over processes and tools. Tools that try to enforce a workflow of a human? GTFO!

How far does this paradigm extend? For sure, “process” is the worst. When invoked, it usually means a large amount of paperwork or rules that must be strictly adhered to. The downside is that many of said process are manual in nature and, as a result, error-prone. Likewise, in companies that implement a tool before understanding what they want to achieve or, at the very least, defining a set of principles, the tools end up shaping how the company works rather than the other way around. The point here is that humans are in charge.

Agreed. What is unreasonable here is the underlying expectation that exists here and across the IT industry: technologists must know an immense amount about an immense number of things. Even in my own domains of expertise, I can think of nothing more demotivating than trying to remember how to deploy code that I haven’t touched in three-plus months. Eventually I’ll remember, but it’s a drag and introduces unnecessary friction. Now, play that out in a larger team and multiply.

‘I will become redundant’: I have yet to see this happen. What instead happens is collaboration. Developers can focus on shipping and keeping their code up to date without bugging operations, and operations can care about aggregate problems (capacity, power, storage) as opposed to transactional tasks such as “push this code” or “reset this password.” Most devs I know are not afraid to get dirty, but it’s not where they would rather spend time. Devs want to develop. If you can enable them with better tools to do exactly that, everyone wins. The glucose you were once burning on smaller tasks can and often do become self-service, and you get to go and create even more cool interfaces for users to consume.

Wrap Up

Bottlenecks exist. They can and will continue to pop up as companies grow and expand. Sometimes you may find yourself in a situation where bottlenecks accumulate over time as a result of technical debt, while other times you join a new team and that debt may already be gaining interest on amounts owed. Either way, the situation exists where something needs to be done. Instead of going directly for the RPG, burning down the house and starting over, consider smaller approaches to enable others to do the things you do.

Some thoughts to take with you today:
- Tend your technology garden: curate, don’t operate
- Make small, transparent changes for lasting effect
- Grow it together: don’t control the change
Until next time!

About the Author/James Fryman

Now a senior DevOps engineer at StackStorm, James most recently worked at GitHub assisting in the development and curation of systems scaling within the Operations group. James is also a frequent speaker on the topic of automation at conferences throughout the world.

Twitter: @jfryman

LinkedIn: https://www.linkedin.com/in/jamesfryman

email: james@fryman.io / james@stackstorm.com
February 5, 2016
IT Governance at DevOps Speed: Time to Shift Gears
Technology plays an incredibly important role in the idea economy, where business innovation is dependent on the software that powers the business. Speed and agility in IT are key to a competitive advantage in this modern economy, in which small startups with disruptive ideas are competing with well-established enterprises and industries. Consider how Uber and Airbnb are challenging taxis, rental car companies and hotels, all based on the power of an idea and software. Yet, traditional enterprise IT struggles to deliver at the speed business demands.

Have you ever heard a business leader say, “Our IT teams are extremely responsive and very fast”? The typical response is quite the opposite. IT is commonly viewed as a bottleneck to business innovation and, in many organizations, the business simply avoids IT and instead creates some form of shadow IT.

IT Governance, the Old Way

The principles and practices of DevOps creates the potential for faster delivery and higher quality. However, one of the largest sources of friction is the traditional focus on IT projects and project governance. Consider this definition of a project from the Project Management Institute:

“A project is temporary in that it has a defined beginning and end in time, and therefore defined scope and resources. And a project is unique in that it is not a routine operation, but a specific set of operations designed to accomplish a singular goal. So a project team often includes people who don’t usually work together – sometimes from different organizations and across multiple geographies.”

Given that projects can be expensive investments, and because of limited resources, enterprises justifiably carefully prioritize and plan which ideas and initiatives should be approved.

Faced with limited resources, enterprises expend significant effort to prioritize, optimize and fund only the most important projects. But no matter how well-intended, this governance approach also struggles to respond to the speed and velocity required in the idea economy. Indeed, the typical portfolio-planning and project-management approach is often an underlying cause of dysfunctional IT behaviors such as excessive requirements, throw-it-over-the-wall deployments and questionable quality—none of which are pleasant.

Consider how the business approaches user stories and requirements management. In a traditional, project-driven world in which the project is a one-time opportunity, businesses often are given an exhaustive list of ‘must have’ features in their user stories. This behavior is understandable—given the ‘feast or famine’ nature project, funding businesses need to make sure their future needs are included, even if the need isn’t immediate.

Sadly, this introduces both technical debt and excess complexity from the very beginning. Especially, when you consider that only a fraction of those ‘must have’ requirements will ever be actually used. In fact, a recent IEEE paper noted that 28 percent to 45 percent of software features often go unused.

Consider how “project success” is typically measured. Project teams typically are evaluated on their ability to deliver on time and on budget, along with other various quality and satisfaction measures. The emphasis on schedule and cost can drive sub-optimal decisions, as deadlines and cost pressures loom. As a result, testing is often abbreviated, as the schedule compresses. Sometimes the scope is reduced to conform to the deadline. This routinely leads to challenged releases in which the service desk is left holding the bag, which ultimately degrades trust and teamwork.

After the project is completed, the project team often redeploys to other projects, depending on demand for specific skills. The accumulated knowledge and wisdom of the team is lost and there is no further incentive to invest in automation or process improvements because the team has disbanded.

The DevOps Shift

DevOps is a very different approach that requires rethinking how work is funded and governed. Fundamentally, a DevOps team is charged with delivering small, high-quality releases, very quickly. The team embraces fast feedback to remove bottlenecks and waste and utilizes relentless automation to make tasks repeatable and efficient. Given that the team will deliver dozens or more releases per year, it is incentivized very differently from the traditional “project” team. The DevOps team often “owns” the application in Development, Test and Production, and has a shared accountability for the value it delivers. The team reduces handoffs and delays and implement small, frequent changes in response to business demand, customer feedback and system performance.

The friction of traditional governance needs to be addressed using DevOps to enable the enterprise to thrive. One of the ways to remove the governance friction is a paradigm shift from projects as described above to products. It is vital to focus on value and business results along with employee and customer satisfaction. The key difference is that a product is funded for the long haul:
- A product team delivers ongoing value and the business can count on improvements to meet market demand.
- A product team does not form and disband depending on funding.
- A product team is focused on delivering value through the product and will naturally enhance and improve their processes. CIOs and senior leaders need to consider using the Product model as an alternative way to fund and govern their initiatives.
I’ve talked with several IT leaders who are exploring how to evolve the concept of the traditional project toward a longer-term product orientation. Some organizations explicitly make the change to products, and others are taking a more evolutionary approach. Regardless of the path, the need to evolve the funding model is clear.

Consider how product governance is different from projects. The product team, in partnership with the business, is funded for a sufficient period of time (year, half-year, perhaps quarter) depending on the business needs. The product team then delivers fast releases of business-driven innovation and rapidly updates the system based on feedback from continuously assessing the product. As the team remains intact, it is able to learn and improve while also accelerating delivery. Additionally, because the product team is able to deliver quickly, the incentive to overload releases with “nice to have” features is greatly reduced.

Here’s how the mindset is different:

Project                                                                         Product

Short time frame                                                   Long term commitment

Limited funding                                                     Predictable funding over time

Team disbands                                                      Team owns the product and results

No incentive to automate                                   Automation improves quality and speed

Incentives based on schedule/budget            Incentives based business value

This does not mean there won’t be projects in the future, but there will be a combination of products and projects in most large enterprises. Most likely, we will see projects will be the way new products are proposed, evaluated and conceived. However, once the product is launched, the product team then will operate under a product model and mindset.

About the Author/John Jeremiah

John Jeremiah leads the Digital Research Team with the HP Software Applications Delivery Management team. He is a software professional with over 20 years of experience including a variety of leadership roles with the U.S. Navy, IT consulting and Fortune 500 IT organizations. His previous roles span from application developer, project and program manager, Director of Testing Services, and Delivery Process and Methodology Director. Prior to joining HP, he was director of Testing Services and Project Delivery Services for Thrivent Financial for Lutherans, where he led the adoption of CMMI Maturity Level 3 process framework.
February 4, 2016
IT DevOps: One Size Does Not Fit All

As absurd as this may seem, some in IT may be longing for the good old days of the mainframe. After all, the hulking machine, with its dumb terminals and thousands of punch cards, gave IT complete control. No citizen developers or business analysts allowed.

Things got more complicated with distributed desktop computing and its different operating systems and requirements. Server-based web apps simplified things once again, but now mobile has made development more complex than ever. Instead of just updating the server, you also now have to update each mobile device—creating apps that work on each and getting changes out to the entire mobile population.

What’s IT to do? Applied properly, DevOps can help.

The Evolution of DevOps

Coming on the heels of agile development—a term first coined in 2001—is DevOps, which was first popularized in Belgium in 2009. Today, 15 years into agile development and six years into DevOps, it is becoming clear that these intertwined terms are quite broad, encompassing attitude and approach, platforms, tools and solutions. Agile development, with its Scrum meetings and quick turnaround cycles, did speed development but made deployment more difficult, because many organizations just couldn’t support fast cycle deployment.

DevOps, with its platforms, tools and practices emphasizing collaboration between IT and development, targets application delivery with continuous testing, ongoing feature development and ongoing maintenance to deliver apps faster. While the intention is well and good, the DevOps process must be task-specific to succeed.

Today’s development environments can be broken down into three categories: low-code, deployment-centric apps and, in a class by itself, mobile. Delivering apps in these three environments involves a broad range of skills and tools. Therefore, the approach and degree to which DevOps is utilized must vary as well—from virtually no DevOps in low-code environments to extended DevOps in mobile.

Low-Code = Zero Ops

In cloud-based, application performance-as-a-service (aPaaS), low-code environments, DevOps can take a back seat. With the vendor managing, maintaining and controlling the deployment environment, the citizen developer or business analyst is empowered to work on GUI development and other features and functions with little involvement from IT or development. In these environments, power users can easily push out low-code apps. A strong DevOps presence here is not necessary because the separate environments typically required to propagate apps does not exist. The business analyst simply makes the changes and pushes them through to production.

Here, IT is best utilized as gatekeepers, getting involved only when needed. We characterize these environments as zero ops—the less DevOps the better. This leaves business users, IT and development free to focus on their strategic areas and core competencies, funneling resources appropriately and enhancing productivity across the board.

Deployment-Centric = Controlled Ops

High-transaction, highly scalable, business-critical global apps fall into the deployment-centric category. The goal of DevOps in these code-intensive environments is to free developers from deployment issues, enabling them to focus on their key competency of writing code. Well-executed DevOps can effectively move apps from development to deployment, enabling tight collaboration between development and IT. In this environment, a well-managed DevOps process can make it easy for the DevOps team to deploy the apps and to manage the deployment moving forward, scaling apps automatically with rules that scale automatically based on usage.

That is why we characterize DevOps in these environments as controlled ops, a collaboration tightly controlled by development and IT.

Mobile = Extended Ops

From development to deployment, maintenance, monitoring and analysis, mobile has introduced new levels of complexity to application delivery. Developers have iOS, Windows and Android to deal with, not to mention multiple versions within those environments. Then there is the development environment itself—web, native or hybrid. Compounding it further are the devices—countless phones and tablets. And deployment options—public app stores, private app stores, file-sharing services. Finally, the end user is engaging the device in ways never before imagined, placing the need to build responsive and compelling user experiences front and center.

This environment calls for extended ops—a highly collaborative environment where development, deployment, maintenance, support and business stakeholders are all integral to an app’s success. In mobile, everyone needs to have a place at the DevOps table, as mobile apps are literally iterative apps—constantly on the move, morphing and changing, driven primarily by end-user feedback. The ability to make seamless updates and user-driven changes at record speed can spell an app’s success or failure. The collaboration, platforms and tools DevOps offers in this environment have never been so critical, as business users now must be involved in the design and development of the app and in analyzing how the app is used, which will dictate changes moving forward. Successful, extended ops welcomes business users, but does not involve them in the DevOps process itself—that’s for IT and development.

In Summary

DevOps can have an impact on the entire application delivery cycle. From improving deployment frequency—which can lead to faster time-to-market—to shortening lead times for new releases with lower failure rates, the goal of DevOps is to maximize the predictability, efficiency, security and maintainability of the simplest mobile app to the most complex transactional system. The key to successful DevOps is applying the right level of collaboration and employing the right tools to ensure that DevOps improves quality and productivity rather than hinders it.

About the Author/Mark Troester

Mark Troester is the Vice President of Solutions Marketing at Progress Software. Mark has extensive experience in bringing application development and data integration products to market. Mark previously led product marketing efforts at Sonatype, SAS and Progress DataDirect. Before moving into marketing, Mark worked as a developer and developer manager for start-ups and enterprises alike.
LinkedIn Google+

February 3, 2016
Unifying Applications into One System
Let’s talk about a real problem that all of us have faced at one point or another: keeping track of a single thread of work across many disparate tools. Regardless of the industry a company operates in, as a company grows it accumulated back-office applications that support of the business.

Many knowledge-based companies have some sort of communication tool, project tracker and support tracker, all designed to help improve business process. Conversations suffice until they do not, and tools are implemented as the need arises. Every added tool has its purpose, solves a critical need and makes you and/or your team more productive.

At some point however, this changes. Discovery becomes a major issue, as usage patterns between different tools leaves silos of data. It becomes difficult to correlate the different company pipelines that ultimately drive your business—the pipeline to care and communicate for customers, the pipeline to deliver new features, and the human interfaces involved in each. This is only intensified by team members who work on different projects with different tools and people, team members who work in different time zones, the sheer quantity of work to be done …

How many ways can you name how not just conversations are lost, but context as well?

Commonly, teams attempt to solve this in a few ways:
- Rules! Specific guidelines (sometimes suggestions, sometimes mandatory) on how and where to have conversations and to store data.
- Integrate! Write data transforms to move data from system X to system Y as necessary.
- Go all in! Choose a suite of tools that takes care of all of these for you.
- Make it problem for “Future You” — It’s fine as is, and not really an issue.
At StackStorm, we ran into this problem. We have two ticketing systems (GitHub issues and Jira), a service desk tool (reamaze), and a chat client (Slack). The solution we use at StackStorm is one that I borrowed from my time at GitHub. One of my colleagues set up a really cool hook into Hubot that listened in our chat rooms for conversations we were having related to a GitHub Issue, a Pull Request or even a code commit. When someone mentions one of these things, Hubot would grab a chat log plank, and cross-link the permalink to the Issue or Pull Request.

But, that’s just GitHub. Context matters across all tools, and gives team members additional flexibly in learning and gaining knowledge on their own. So, we took our Support Tool, re:Amaze, and did the same thing.
- In times of speed, breadcrumbs allow you to piece together puzzles from where travelers have once voyaged. It may not be the entire puzzle, but having background greatly helps.
- In times of documentation, those breadcrumbs allow you to use the same investigative skills to assemble a better history.
This is one part of a set of behaviors that helps create a dynamic web of information. By seamlessly having a mechanism to associate conversations and issues/pr/tickets/whatever, it becomes much easier for conversations to happen whenever they need to (serendipitous interactions ftw) and still get context to team members when they’re available.

This matters because: There is only one system.

Before we get started …

Full disclosure: I am affiliated with StackStorm, the company building StackStorm the tool. That being said, the ultimate goal here is to illustrate the pattern of how to harness the recent chat culture change using an event-driven framework with the hopes of regaining just a modicum of sanity in your daily life. If you’re interested in learning more about StackStorm and how it ties into the overall automated troubleshooting and autoremeditaion space, take a look at our ChatOps Pitfalls and Tips by Dmitri Zimine. That should give you a good background on why we used StackStorm instead of, say, just a small script.

Ok, on to business!

The Sensor

This workflow begins with a sensor. Inside of the StackStorm-Slack integration is a sensor class that connects to the Slack Real-Time Messaging API. The first place to begin is with Sensors. The official Slack pack contains a sensor that uses the Slack RTM to connect to Slack and listen for messages in rooms it is associated with. Each message is then sent as an “event” to StackStorm, and I can create rules that will trap certain events and kick off.

Rules

Now that the sensor is emitting triggers into the system, I need to find a way to take an action when someone mentions an issue or ticket. The mechanism here is via a rule. Rules check triggers emitted into the system via sensors against a series of checks, and then executes an action or workflow if matched. A trigger can match to many rules.

Let’s create a rule to watch Slack for discussions related to reamaze
- Source: https://github.com/stackstorm-packs/st2-crosslink_chat_with_applications/blob/master/rules/crosslink-slack-to-reamaze.yaml
The first element in the criteria block is trigger.text. In the rule, the trigger itself is just referred to as trigger as opposed to slack.message.text. We want to see if the text properly contains a pattern related to our reamaze issue tracker. I chose contains out of the large list of comparison operators, and made sure the pattern matches what I’m looking for.

Last but not least is the action block. This block is basically the next operation. Here, I can choose a single action or a workflow to kick off, and even grab data from the trigger payload to pass to the action. In this case, I opted to create a new workflow for my purposes here, and made sure to grab a few keywords that I needed to do processing.

At this point, I have a rule matching and now I need to create the action necessary to process the trigger.

Actions and Workflows

Next, we get to creating the actions. The goal is to ensure that anytime a discussion randomly breaks out about a re:Amaze support ticket, that @estee-tew posts the Slack permalink to the support ticket. With the trigger payload extracted in the above rule, the workflow will need to:
- Take the text of a user comment and extract reamaze issue URL.
- Calculate the Slack Permalink URL of the matched message from the collected data.
- Post the Slack Permalink on the matched reamaze issue ticket.
Inside the reamaze pack, I can see that I have the ability to create_message. This action takes three parameters: slug,message, and visibility. In our rule above, the action that was kicked off when the criteria matched desired slack messages is stackstorm.crosslink_slack_to_reamaze. As of right now, this does not exist, so that is the next step. For brevity’s sake, you can take a look at the action metadata on GitHub.
```
---
chain:
  -
    name: "get_permalink"
    ref: "stackstorm.get_slack_message_permalink"
    params:
      channel: "{{channel}}"
      timestamp: "{{timestamp}}"
    publish:
      permalink: "{{get_permalink.result}}"
    on-success: "sanitize_message"
  -
    name: "sanitize_message"
    ref: "stackstorm.sanitize_slack_message"
    params:
      text: "{{text}}"
    publish:
      sanitized_text: "{{sanitize_message.result}}"
    on-success: "get_reamaze_slug"
  -
    name: "get_reamaze_slug"
    ref: "stackstorm.get_reamaze_slug"
    params:
      text: "{{sanitized_text}}"
    publish:
      slug: "{{get_reamaze_slug.result.slug}}"
    on-success: "crosslink_slack_to_reamaze"
  -
    name: "crosslink_slack_to_reamaze"
    ref: "reamaze.create_message"
    params:
      slug: "{{slug}}"
      message: "{{permalink}}"
      visibility: "internal"
```
- Source: https://github.com/stackstorm-packs/st2-crosslink_chat_with_applications/blob/master/actions/workflows/crosslink_slack_to_reamaze.yaml
This is a simple Action Chain, inasmuch as it just does one task after another. The tasks here are designed to be small and portable so they can be reused. Let’s quickly inspect each of the actions and walk through what it is that lies before us now.

Step 1: Permalink to chat history

The goal is to create a way to crosslink a Slack permalink, so let’s start there. This starts with the get_permalink action above. While the history permalink is not in the trigger payload (or even in the official API, for that matter), Slack permalinks actually are not too terribly difficult to figure out. The first action takes two parameters (channel and timestamp), and then spits us out our permalink. We know we’re going to publish the permalink variable that now can be globally used in the workflow in the future. In addition, the next step takes us to the sanitize_message task. You can take a look at the python code for this action upstream.

Step 2: Get support issue data

The next step actually happens in two tasks: sanitize_message and get_reamaze_slug. The immediate next step,sanitize_message, is necessary to clean up the output from Slack. In the message payload, URL data is sent to us as a special “escape sequence,” which doesn’t do the rest of the actions much good. This action, detailed below, is simple enough to be reused in several other workflows. Again, take a look at the action itself: The run() method in this python-runner task is the entry point from StackStorm, and this cleans up the text and returns it back as a plain URL, which we can then pass to the next action, get_reamaze_slug. This returned information gets us what we need to call our final action, reamaze.create_message. We’re able to publish the permalink slug that was shared and discussed in chat. Now we know what is being discussed.

Step 3: Post the crosslink

In this step, a the link is actually created. Here we are! The finish line! Woot! The only thing that is essential to do is to make sure we only set the note as an Internal Only note to avoid sending weird links to our friends. The next step is thecrosslink_slack_to_reamaze action. At this point, we have all the data we need, so it’s just execution.

Permalink from Slack. Crosspost to re:Amaze

and now, with GitHub…

The premise is simple enough. Included in the upstream repository also includes examples for how to setup similar context mapping with StackStorm. Take a look at https://github.com/stackstorm-packs/st2-crosslink_chat_with_applications. Same process, code reuse, and the same end effect.

Unknowns
- This workflow is not for everyone.
- We expose internal-only links that are not accessible by users, and it may be confusing to see random links in issues around GitHub. Why?! What are they?!
- Aliens!?
There are many more that will come up, but the key factor to address here is that it’s not difficult to put this together, and it’s not that difficult to change. And that’s ok. We’ll have questions to be answered, but being able to try something out super quickly was indeed satisfying. (In truth, the workflow went up faster than this blog. :P)

Wrap-up

For many reasons, it isn’t feasible to capture many fluid conversations in many different tools. The answer is not to move data around, but to leverage humans and provide them a helping hand. This is by no means a solution, but it does provide less friction in the daily work. Over time, add enough of these friction reducers, and then suddenly it’s no longer a panic issue. This also reinforces the idea that there is not a collection of systems, but rather a single system. The single company. The tools you selected are obviously necessary, as we defined at the beginning, but tools should not be dictating the communication structures of your teams, but rather informing them. Removing the ability for silos to form allows data in both bits and ideas to flow and move around. This can even be expanded to do much more.

Until next time!

About the Author/James Fryman

Now a senior DevOps engineer at StackStorm, James most recently worked at GitHub assisting in the development and curation of systems scaling within the Operations group. James is also a frequent speaker on the topic of automation at conferences throughout the world.

Twitter: @jfryman

LinkedIn: https://www.linkedin.com/in/jamesfryman

email: james@fryman.io / james@stackstorm.com
January 29, 2016
Testing: Mind the DevOps Gap
If DevOps is a continuum, it starts with planning and development, and ends with deployment into operations. Much of the focus in DevOps and within the DevOps toolchain has been on application build automation (development) and deployment of apps into operations. But, for DevOps to pay off, there must be a continuous flow and automation from development all the way through to operations, and that means providing automation for the steps in between these two.

What is in the gap between development and production delivery? Testing. Not surprisingly, when Gartner surveyed its clients in 2015, more than 50 percent of them ranked the need for test automation as one of their top priorities for DevOps success. This really illustrates the recognition that DevOps cannot succeed if only one part of the DevOps continuum is automated. Companies that have started to focus on DevOps recognize that they must “Mind the Gap.”

Closing the Testing Gap

Why is automating the various testing steps (regression, performance, stress, GUI, QA, interoperability and security testing) so difficult? There are five key components that must be automated successfully:
1. The infrastructure – It starts with one very important characteristic critical to testing that is not automated – the ability to mimic the infrastructure in which the software (or hardware) being tested is expected to run in when it gets to production. Having the ability to give each tester (or set of automated tests) their own personal replica of the target production infrastructure—a “sandbox”—is critical to ensuring the software coming out of test can be deployed into production automatically and continuously. Automating tests is not nearly as difficult as automating the underlying infrastructure in which those tests run.
2. The production environment workload – Often overlooked in automating testing is mimicking the workloads that would be common in production. This includes the network traffic, other application workloads and network security profiles. These activities need to be automated within the sandbox to create a more realistic environment for testing.
3. Test automation – Of course, the tests themselves also must be automated and there are a variety of tools to assist in this process. As software gets more complex, automation continues to be a challenge, with mobile testing replacing GUI testing as the most challenging type of testing to automate.
4. Reporting and result analysis – To provide continuous automation from development through testing to delivery, it is important to see and analyze test results automatically.
5. Tool Integration – Finally, automation into and out of testing needs to be enabled. This means that sandboxes and test automation suites need to be API-driven so they can be started by a previous tool in the DevOps tool chain and can also initiate a tool that follows testing in the tool chain.
DevOps projects tend to start in one part of the continuum from development to operations. There is nothing wrong with taking this approach. However, it is also important to “Mind the Gap” and work to expand automation across the continuum continuously. One way to ensure that automation can expand easily is to deploy sandbox technology across the continuum, beginning with development and continuing through configuration and release management. The sandbox ensures that at each step, the production configuration and workload is being replicated.

Sandboxing technology has been used in development in the past, but is relatively new to the entire DevOps process. As more companies move to continuous integration and continuous deployment, however, the need for sandboxes is growing.

The sandbox should provide the following:
- The ability to create an accurate replica of the real production environment that deployment is intended for. This can include the physical, virtual and cloud infrastructure as well as applications, network traffic and load.
- The ability to initiate a sandbox via APIs so that the sandbox can be triggered by DevOps tools as an integral part of a complete end-to-end DevOps automation.
- The ability to automate DevOps processes inside of the sandbox (e.g. automated regression testing), as well as to automate the teardown of the sandbox and trigger the next step in the DevOps cycle when those processes complete.
- Business intelligence about everything that happens inside of sandboxes so that DevOps processes can focus on continuous improvement.
- The ability for many people to have their own sandboxes running simultaneously with isolation in shared labs.
DevOps depends on continuous automation from development, through test and QA, to configuration management and production deployment. Sandboxes provide a common automation environment that can be used at each step of the DevOps cycle to close the gap between development and deployment.

About the Author/Joan Wrabetz

Joan Wrabetz is the CTO for QualiSystems. Most recently, she was theVP and CTO for the Emerging Product Division of EMC. Joan received her MBA at the University of California, Berkley, and MSEE at Stanford, and a BSEE at Yale. She has held teaching positions at the University of St. Thomas, St. Mary’s University and the University of St. Thomas, St. Mary’s University. Joan holds patents in load balancing, distributed systems, and machine learning classification and analytics. Her experience inclues: founder and CEO of Aumni Data, CEO of Tricord Systems, Vice President and General Manager for SAN operations at StorageTek, Founder and CEO of Aggregate Computing, Management and senior technical positions at Control Data Corporation and SRI International, Partner with BlueStream Ventures.
January 28, 2016
DevOps Roundtable & Networking Sales Events – February 11th, Costa Mesa, CA

DevOps Roundtable & Networking Sales Events

Do you want to deliver software projects faster and with greater efficiency? If so, you are not alone. Many teams are tripped up by manual deployments, inconsistent environments, and slow hand-offs. We will lead a discussion bringing together experts from IBM, partners, customers and others to discuss DevOps approaches for delivering continuous innovation.

At these events we will cover:
•Application deployment and release management with UrbanCode
•IBM’s BlueMix Garage Method and transforming your organization
•Building the business case for DevOps transformation including Hybrid Cloud
•Real customer case studies, including people, process and product implications
•Demos showing how to define, wire, and automate continuous application delivery

“I attended the DevOps Networking Event in Portland, OR and it blew my mind. I enjoyed the opportunity to network with local colleagues that are also focused on DevOps. This is the future of IT!” -Nick Wylde, DevOps Specialist, Daimler

Typical Agenda

8:45am-1:45pm
8:45 Networking & Breakfast
9:30 DevOps Introduction
9:45 “Why DevOps?”
IBM DevOps SME
10:15 DevOps Customer “Case Study”
10:45 Networking Break
11:00 “Understanding DevOps”,
IBM DevOps SME
11:45 Open Discussion
12:15 Lunch w/ UrbanCode Product Demonstrations
1:30 Conclusion and Wrap-up

January 21, 2016
Application Monitoring in the Age of Big Data
Operations (or ops, as it is known colloquially) has been necessary since the first shared systems came online in the ’60s. While the job title didn’t necessarily exist, the same questions needed answers then as they do now:
- Is it up and accessible?
- Is it responding in a reasonable time frame?
- Is it performing better or worse now than previously?
In a simple system, say a static web site, these questions are answered easily by requesting the page. In an automated fashion, of course.

However, when you look at any “late model” technical infrastructure, you’ll find many, many moving parts. These range from border routers to web servers, work queues to databases and data caches to big data clusters. There are thousands upon thousands of computing instances, software processes, network storage devices and network links that can go down, up or just plain wonky. This means potentially millions of places where things can go wrong.

How do you keep an eye on all of these potential issues? How do you know if they’re responsive? How do you know if things are getting better or worse?

Some Monitoring Progress

The “old” method was to write some sort of monitoring script that polled some data that you thought would represent the overall health of that component. Through the years things have gotten more granular. Our monitoring script libraries have grown and we’ve even instrumented our applications with counters (statsd, librato, etc.) and come up with big data storage (opentsdb) to house all of these data points.

The question remains, Do we have any more clarity than before? We unarguably have more data points. So we must know more about the performance of our systems, right?

Turns out, in practice, we just have a lot of data and a lot of people attempting to decipher what that data means. If you’ve worked in operations you’ve been up at 2 a.m. looking at status dashboards with green, yellow and red icons and many, many graphs, all in an effort to answer the question: What is going on?

Sure, some incidents are easy: An instance was retired, or a fiber line was cut somewhere in Kansas.

I’m talking about the ones that aren’t so clear cut, so to speak:
- Site feels slow
- Median response times are up 25 percent from yesterday
- Usage is down week over week compared to some relevant time frame
How do you answer those questions in a haystack of data points, up/down status and, in some cases, just plain noise? Application performance managers (APMs) came along and gave us tooling in the app frameworks and the browser. Now we have visibility into which calls are performing poorly and how our app “feels” to the end user.

This has helped by breaking down the haystack into smaller haystacks and provided a way to search and sort potential performance issues. However, most APM tools depend on instrumenting code such as Java, .Net or Ruby, and are not able to provide monitoring insights for the rapidly growing open source frameworks such as Grails, Akka, Netflix OSS and the like. We’re still left with the haystack problem: What is going on?

When I’m up at 2 a.m., stumbling over to the computer to find out what issue PagerDuty has alerted me to, I don’t really want to pore through page after page of graphs and up/down status. What would be really helpful is a system that can aggregate all those monitoring data flows and statuses, actually apply some intelligence. Then it could tell me, “Look at this response time of this component, and this metric is reporting something anomalous. This is most likely causing your issue right now.”

In other words, it would be helpful to have a system that can show both the symptoms and the root cause of the issue. That system also would provide high-quality, high-value information about my infrastructure and combine anomaly detection with root cause analysis to provide real root cause detection.

One new startup, OpsClarity, is hoping to make troubleshooting more accurate and efficient by combining data science and anomaly detection with root cause analysis.

Perhaps this is the long overdue beginning of the next age in monitoring.

About the Author/Michael Hobbs

Michael Hobbs is the director of Technical Operations at Expa, a startup studio based in San Francisco. Significant experience in building, operating and automating highly scalable application infrastructures has allowed him to contribute to the success of Infusionsoft and Stumbleupon, among others. Michael continues to put that expertise to work at Expa by advising and assisting the next generation of Internet companies. Michael is also a significant contributor to many open source projects, including dokku and herokuish.
January 19, 2016
3 Ways to Develop the Perfect DevOps Culture

DevOps is not a new concept, but it is still maturing.

In the seven years since the first “DevOps Day” took place in Europe, DevOps’ influence has spread to every corner of the world. Many organizations have embraced the concept, and it’s changed the way business is done. These companies have benefited from removing the gulf between development and operation teams—we have seen companies consistently churn out better software, in shorter time periods, to achieve new levels of efficiency.

However, this success has not been replicated for all sectors. Federal agencies, for example, have been slow to adapt to DevOps. For other companies, a rush to implement DevOps has led to ongoing issues that prevent them from realizing the true benefits of DevOps.

Building a DevOps Culture

Many companies are moving in the right direction to implement DevOps successfully, but critical barriers still remain in developing the perfect culture. Here are three ways you can make the vision of DevOps a reality:

1: End the Culture of Fear

Much like previous aversions to cloud, the biggest barrier to implementing DevOps is the fear of change. This is a common problem across sectors, because trying something new can be daunting. This is true for federal agencies protecting national security or private companies attempting an ambitious new project. Successful DevOps begins with buy-in from the highest levels of management—but how do you get them on board?

The best approach is to start small by moving forward with a low-risk, high-reward pilot program. This is an opportunity to get the development and operations teams in the same room and allow them to work together toward a common goal. Once executives see the positive results—reduced time-to-value, efficiency gains and cost savings—they’ll be more apt to double down on establishing a companywide DevOps culture.

2: Find and Establish Talent

A DevOps culture is different and requires a shift in mentality. It also requires talented people with unique skills and experience. Since DevOps is still a relatively new concept—even by technology standards—talented people are scarce and in high demand. But companies can bridge the talent gap through a targeted strategy that incorporates both recruiting and training.

We are starting to see more companies provide educational support programs to develop talent. That must continue if companies want to build the next generation of DevOps leaders. These programs allow employees to grow their skills to better meet the needs of DevOps, which will fuel their career growth while helping their company improve its efficiency.

In parallel with training, companies must aggressively recruit tech talent from top universities that have DevOps classes. Recruitment of tech talent has rarely been more fierce, and it will only intensify as more federal agencies implement DevOps and compete for talent. The commitment from federal agencies to emerging IT strategies, including DevOps and agile development, will make them far more attractive to the best STEM talent.

3: Measure, Measure, Then Measure Again

The ability to deliver impactful ROI metrics is one of the best aspects of DevOps, because it removes all the guesswork whether it is making an impact. The numbers will tell you daily.

The first step is to measure your current metrics, whether you’re struggling to make DevOps work or implementing it for the first time. Companies must know how efficient—or inefficient—existing software development processes are before beginning to change. With the right talent in place with the right frame of mind, it’s time to track the improvement.

Also, understand what results to expect and plan accordingly. Based on our experience, deployment should be eight to 10 times faster with 50 percent uplift in quality (measuring reduction of incidents and incident duration), while software builds should be three to four times quicker.

If you properly set up the perfect DevOps culture, the results can be astounding. We’ve seen a company institute a DevOps structure and reduce release windows from two days to two hours, simply through repeatability and scalability.

The Goal: Break Down Barriers

Despite DevOps rapidly growing in importance, questions remain from those skeptical about its effectiveness. It reminds me of a line I hear frequently at conferences and shows that always gets a laugh: “To err is human. To err on 10,000 servers in 10 minutes is DevOps.”

The truth, however, is that DevOps is a very simple concept about working together and working smarter. It is the realization of a more efficient, more productive organizational model. It’s time for all companies to break down barriers, create a modern culture, and deliver better software in shorter cycles.

About the Author/Raj Ananthanpillai

Mr. Ananthanpillai is the Chairman, CEO and President of InfoZen and has been with the company since January 2004. Previously, he served as the Chief Strategy Officer of ePlus, a business process automation and financial services company, responsible for technology, marketing, analyst relations and business strategy. Prior to that, he was the president and CEO of NetBalance, a venture capital-backed multimillion-dollar software company, which was successfully sold in 2000. You can connect with Raj on twitter or on linkedin.

January 15, 2016