devopsy.kinsta.cloud

Author: contributor

The 3 Secrets to Overcoming the Agility-Stability Paradox

Regardless of whether an organization subscribes to a bimodal IT approach, one thing is clear: It’s more important, and more difficult, than ever to fight the agility-stability paradox. Today’s businesses must build on a delicate balance of being compliant, plan-driven and keeping the lights on while also seeking ways to become more fluid and agile with high customer touch. The barriers standing between these two key initiatives are numerous and complex; whether it’s mismatched technology or a lack of mutual understanding, the agility-stability paradox remains.

In a lot of ways, this paradox comes down to a difference between traditional and new forms of IT. Traditional IT can be described as predictable–it’s compliant and plan-driven, with conventional processes and long-term cycles. But as the next generation of IT starts to take hold, today’s businesses must find ways to also fold in a new IT that’s dynamic, fluid, agile and continuous, with short cycles and high customer touchpoints. In this way, traditional IT and new IT are polar opposites, and many companies struggle to find a balance between the two. Competing attitudes, too much change at once and tooling challenges all stand in the way of harmony between the reliability of the traditional approach and the need for agility in the new way of doing things.

Balance is Possible

While there is no magic tool or wand that can solve for the incongruities so many organizations face, balance is possible. Enterprises don’t have to choose reliability, customer experience, uptime and performance over agility, release velocity, new markets and competitive response. The real secret to overcoming the agility/stability paradox lies in establishing who, what and how. What this means is that with the right people, processes and tools in place, any company can achieve the balance between agility and stability needed for success.

Who? People

People serve as the “who” of finding balance between reliability and agility. This is the chance to integrate your culture into solving the agility/stability paradox. Start by identifying how each member of the team needs to adapt and shift to accommodate changes. The real trick to getting the people aspect of things right is communication. Define a communication path and be really clear about why your organization needs to transform, how it will be transformed and when everyone can start expecting to see some real adjustments take shape. Orchestrate a response mechanism across your teams and enable social operations collaboration to facilitate execution. Be sure to provide ongoing updates and encourage feedback.

What? Process

Now that you’ve established who needs to play a role in overcoming the agility/stability paradox, it’s time to talk about what exactly needs to change. Process is absolutely crucial here. There are a few keys to establishing the right process for balancing traditional and new IT models. The first is to identify, and not dictate. Dictating change from the top down is never going to be effective. Instead, work together to determine areas of weakness and highlight them. Use your observations as a guide, not a mandate.

From a more tactical perspective, be sure to streamline workflows wherever you can. Define instead of inheriting urgencies and alerts. Don’t be afraid to rely on automation wherever possible, either. By automating processes that help out on the people side of things, you can free up your team to spend less time on tedious, manual tasks and focus more on innovation.

How? Tools

Tools are your best friend when it comes down to actually making all this change happen. Considering the vast number of tools in the market, choosing a toolset may appear daunting at first. But if you start with strong integration across the operational modes already in place, then you’re already in good shape. In particular, to bring new, agile IT into the fold, you’ll want to incorporate IT service management (ITSM) solutions and establish a DevOps tool chain.

Don’t Boil the Ocean

The most important thing to remember is to start small—you don’t have to boil the ocean. Build a culture where traditional and new IT environments are encouraged to work closely together, where you can build and run software that addresses both agility and reliability to respond to the pressures on the business. Start by defining what is is right for your team and organization and acknowledge the existing culture and people. Don’t be afraid to experiment and create isolated learning environments, either. Just make sure to maintain a clear connection to customer value and use this as your North Star. Finally, don’t forget to celebrate. Celebrate your failures and learn quickly from them.

About the Author / Manish Kalra

Manish Kalra is director of Product Marketing at PagerDuty. He is responsible for driving product marketing strategy, product positioning, launches and collateral development for the PagerDuty incident management platform. Prior to PagerDuty, he served as Director of Product Marketing at companies like Sumo Logic and Splunk.

September 22, 2016
Cognitive Analytics: ‘Operations Thinking’ for Development
In a recent blog post by my colleague Payal Chakravarty, “Synthetic Monitoring – the Start of the DevOps Monitoring Journey,” she discussed how developers, testers and operations staff all need to ensure their internet and intranet mobile applications and web applications are tested and operate successfully from different points of presence around the world.

Continuing our five-part series on “Continuous Monitoring: The Role of DevOps and APM,” this blog post will talk about how analytics can help developers earlier in the DevOps life cycle think about the performance of their applications.

Continuous monitoring is not just about detecting operational problems in production; it is about getting feedback and reassurance that code changes you’ve made have resulted in the intended operational behavior before you deploy to production.

My career DNA is development. So I know, full well, how code changes can have unintended consequences.

Remember the bad old days when development methodologies relied on a series of quality checks (code reviews, various types of tests and release validation) to catch unintended consequences? If caught at all, most operational degradations surfaced long after the offending code was submitted, because the types of validation designed to catch these problems occurred at the very end of the development life cycle, when a “stability test” was possible. These “banana skin” issues were caught late or not caught at all. Either way, clients were impacted (through release delays, increased costs or service degradation) and you were not happy.

Continuous development was great for me, personally. It forced me to look at development in a whole new light and solve the “little and often” delivery problems. It was fun, but despite best efforts, one “banana skin” remained: the stability tests in the staging environment. Just like before, it could cause a late-breaking wobble in the delivery plan to production or, worse still, issues were missed altogether.

I didn’t solve this problem well because I was still thinking like a developer—mainly because I don’t have the skills, time or the interest to think like Operations.

If cognitive analytics are applied to operation problems, you don’t need to think like Operations to benefit from Operations thinking. Your solution automatically will learn what is normal for your application; it will set dynamic thresholds and it will proactively notify you when it becomes significantly anomalous. With cognitive solutions, you can enable operations (continuous monitoring) in staging and detect anomalies long before the stability test fails or before the application hits production! All you need to do is feed it the application metrics. The good news is, your buddies in operations can show you how to do it.

I am a positive person, so I am going to use a positive development scenario:

You have made a code change to improve the performance of your application. When the code is deployed into staging, the expected operational improvement should occur (for example, a response time metric should change for the better). If you are using cognitive solutions, this anomaly (new and unusual behavior) will be detected automatically and you will be informed.
- You get the reassurance that your code changes are having the intended positive impact on the operation of the service in staging.
- You can inform your Operations team that new, anomalous behavior will be seen and why this is actually a good thing.
- Furthermore, since these changes are intentional and the solution is fully cognitive, it will learn the new “normal” over time and the anomaly will simply go away. You do not need to take any “Operations action” such as setting a new threshold level, etc.
The reverse is true, too. If you did not expect a change in a response time metric, or any of the other operational metrics, this would surface quickly, in staging, well before a test (if it exists) catches it. You rapidly can investigate this and take the necessary action before the “banana skin” moment.

Another type of “Operations thinking” that is easily enabled in staging is the ability to alert on patterns in log files.

This feature looks for patterns in logs, in real time, as files are ingested. You create the alerts. You can include alerts for the type of symptoms Operations looks for (again, talk to your buddies—they are the experts) or better still, you know the symptoms of your application starting to fail (you have investigated and fixed enough bugs!). What if you could use congitive solutions to look for these patterns continuously and proactively send you an e-mail if one emerges? Wouldn’t that be good?

Monitoring solutions have turned a corner. Before cognitive, monitoring solutions relied on Operations SMEs to carefully manage the environment. With cognitive solutions the SME is built-in, allowing developers to shift left “Operations thinking” into staging and focus on what they want to do and do best: code, code, code …

Watch a replay of the recently hosted webinar, “Learn Why We Must Shift APM Left in the DevOps Lifecycle.”

About the Author / Sinead Glynn

Sinead Glynn is an offering manager for IBM’s IT Service Management portfolio within DevOps.
Within the IT Service Management portfolio, she specializes in Operations Analytics offerings and the value they bring to both IT Operations and DevOps teams. In her 10+ years at IBM, Sinead has worked in both Development Management and Offering Management, covering both Network Performance Management and Operations Analytics-type solutions. Connect with Sinead on Twitter / LinkedIn.
September 21, 2016
Fixing Flaws: Bridging InfoSec and DevOps

The Road to Creating More Secure Code and Interlocking two Traditionally Distinct Practices

As DevOps continues to expand across verticals, including the financial and government sectors, security has become paramount in the minds of CIOs and CTOs. As such, more organizations have begun to integrate security early in the development process. While security always has been a theoretical part of DevOps, the number of breaches making headlines recently and costing many IT professionals their jobs has taught us that now it is more important than ever for companies to build security into each and every methodology and practice. “Build it in from the start” is a fitting mantra for any developer today—and even more so for his or her boss.

Creating more secure code for products and platforms starts from day one in the planning stages, and some industries are doing it better than others. You must include security—not just in the end product and late development stages, but also throughout the life cycle. Organizations can do this by employing a defined methodology and unified tools that support that methodology, so developers make security not only a consideration for their end product, but something fundamentally baked into their build.

To achieve this harmony between Development and InfoSec, developers and Operations staff must be included in decisions about tools, standards and methodologies that the organization will follow. They need to understand what requirements are coming down the road so they can recognize the need to address those requirements in advance, rather than than being caught off-guard by problems or issues after the fact.

Build a DevOps Toolset with Dev, InfoSec Buy-in

It’s important to recognize that the door swings both ways; InfoSec folks can’t simply give developers a laundry list. Developers must be able to communicate their needs when it comes to security, and also must take an active role in the security of their product.

Part of the importance of this two-way street is recognizing the benefit of having developers involved in security decisions from the beginning. When Dev stakeholders are given the opportunity to participate in the purchase decisions of security tools at the outset of a project, they gain insight not only into the importance of incorporating that tool into their build as well as an understanding of what the capabilities of that tool are. After all, the most expensive part of application security is having to start from scratch because of poor initial planning.

When it comes to tools and security, good security is not necessarily what you buy but what you build. A good place to invest is at the DevOps tool level, where developers can build a process and methodology that allows them to create secure code throughout the process. This is a crucial step that limits point-in-time testing after the product is built—which can lead to expensive re-engineering.

Teach Teams: A Bug Fix is not a Security Risk

One way to keep costs down and priorities straight when addressing security challenges is to keep security issues and bugs separate from each other. Bugs are bugs and we all want them fixed, but a flaw in a piece of software is not necessarily always a security risk and does not necessitate an immediate fix (despite what the stakeholders for that feature might tell you). Finding flaws certainly should be immediate, but the process of fixing those flaws should involve prioritization.

This does mean, however, that evaluating flaws in a very timely manner is important, and one of the first questions you ask yourself when addressing potential flaws or bugs in your software product should be, “Does this pose a security risk?” If the answer is yes, you can quickly pinpoint the source of that risk and address it. The good news is that by doing this, you can greatly reduce the potential of your product having security risks you either a) didn’t know about or b) didn’t think were actually security issues. The challenge is that this is a constant and ongoing process. Be sure though, the benefits are well worth the time you’ll invest.

Recognize Fixing Flaws is a High Priority

It also can be difficult to balance the practice of fixing security flaws versus adding new features, particularly when developers are getting pressure from above to continue adding features and improving the end product.

Again, you need to look at risk. By weighing the benefit of features against the risk of flaws, you will be able to make smart decisions for prioritization. For just about every software product out there, security flaws should be addressed before new features.

It’s also worthwhile to consider the fact that bringing new features into a flawed environment is probably not a great idea. Not only does it mean you still have a fundamentally “broken” product, but that new feature may 1) not work as you expect or 2) increase the security risk further. If the second scenario is the case, now you not only have to fix the initial security flaw, but you also may have to reel that release back in—something you probably would rather avoid.

It’s also important to remember that good tracking, knowledge preservation and collaboration let you pinpoint issues, understand dependencies and determine the trade-offs faster.

Security is not an Option—It’s a Must

If you are looking for inspiration on how to better incorporate DevOps security best practices into your development process, look no further than government, financial and pharmaceutical industries. These industries face heavier regulations than just about anyone when it comes to security requirements, so they are continuously delivering secure software. Not only do they have to include security in their development process, they also must test that security and have defined educational requirements for their developers. In this end, all of this leads to some of the best and most sophisticated security practices in all of DevOps. If you want to gain good insight into how you can improve your security and see some of the latest advances in software development security trends, these are the industries you should pay attention to.

The surest way to provide a poor user experience and to compromise an organization’s success is to allow a security breach that could have been prevented with better foresight. That is why security best practices for DevOps (or rugged DevOps) are so important. By following the recommendations above and employing some of these tactics into your DevOps process, you can decrease risk for you and your company, and ultimately have more confidence in the success of your product.

About the Author / Ward Osborne

Ward Osborne serves as Information Security Officer at CollabNet and has more than 20 years of experience in Information Technology and Security Management. For the past 15 years he has focused on security integration and cloud security and has worked with dozens of companies of all sizes creating a culture of security and using security as an accelerator in business processes. Connect with him on LinkedIn and Twitter.

September 20, 2016
Mainstreaming the Mainframe: DevOps, Automation, Unified Deployment

The mainframe is alive and well. That big metal beast in the data center is not going anywhere anytime soon—nor are its applications.

“If mainframe applications disappeared tomorrow, planes couldn’t fly, people wouldn’t get paid, and the economy would come to a halt,” wrote Forrester analysts in a recent report, “Digital Transformation Needs Mainframe DevOps.”

I couldn’t agree more.

Mainframe systems are the brain of most enterprises. Unfortunately, many mainframe applications have failed to keep pace with technology innovations, forcing enterprises to update them at any cost.

Those “dinosaur” apps need to be modernized so they can become part of the mainstream IT ecosystem that revolves around the web, the cloud, and everything mobile. To make that leap into the modern software world, mainframe apps need to be re-engineered to fit into what is increasingly a cross-platform, predominantly digital world.

Digital enterprises need to apply the same continuous delivery management practices to mainframe environments that they use for their distributed, web and cloud platforms.

Scripting is Not the Solution

Complex, multi-tier enterprise applications often include back-end mainframe applications and data. Upgrades and enhancements of these applications, therefore, require modifications of application code, data interfaces and other components across multiple platforms simultaneously.

Scripts are virtually impossible to audit and typically depend on the knowledge of the individuals who write them. Furthermore, scripts lack the end-to-end process visibility and auditability vital to the success of continuous delivery.

The Need to Re-Engineer Mainframe Apps

DevOps, which mostly revolves around adopting or improving automation, increasingly is being embraced by enterprises. Having initially chosen DevOps for pilot projects, departmental needs and individual applications, big companies now are taking a broader perspective of DevOps—focusing on their needs to drag their mainframe applications into the modern world.

Most enterprises that embark on transforming their legacy applications realize it is smarter, easier and more cost-effective to build a bridge with modern engineering than to start from scratch. Typically, these companies deploy DevOps principles because research and analysis prove they accelerate the delivery of top-quality software. At the same time, they realize their existing investments in their mainframe applications cannot be thrown away or ignored.

Applying DevOps principles to the mainframe application delivery pipeline can help enterprises cut risk, cost and complexity, while improving their responsiveness to ever-changing customer needs.

Unified deployment means that enterprises might need to work with two or three leading vendors to achieve their vision of automated, cross-platform DevOps. Such a vision typically involves unifying COBOL applications, DB2 databases, z/OS processing power and other mainframe assets into a single, shared pool of enterprise digital resources that IT can adapt wherever and whenever they are required by the business, without operational or staffing impediments.

The Need for a Unifying Software Delivery Infrastructure

In enterprises, it is common to have a broad mix of back-end systems, middleware and various platforms from a vast array of vendors. These technologies might be managed by distributed teams and potentially in different parts of the world as well. When it comes to the process of creating and delivering software, the same level of distribution and diversity also is common.

To connect these islands of technology and expertise, enterprises need a unifying technology that sits on top of everything else, connects to everything, and helps to orchestrate, automate and provide visibility into the process of creating and delivering software. Improving traceability, auditability, security and risk compliance through orchestration and automation of the entire stack of applications is critical to any organization.

What that means in practice is that people with different skills in different parts of the world can collaborate easily without having to learn new skills. For example, if you know all about the mainframe but know nothing about middleware or distributed systems, that’s no problem. You can still contribute to the process through a unified pipeline.

In the same vein of thinking, a unifying technology should reduce, if not eliminate, the gap between highly technical and non-technical contributors. That means the unifying technology should provide a solution where people don’t have to write (or even understand) code to make core changes to software.

In Summary

Modernizing the way organizations deploy applications to the mainframe is crucial to their success and very survival. Organizations need to embrace change at all levels of their IT infrastructure and begin automating their processes today. By applying DevOps processes and tools to their mainframes, these organizations will help their “dinosaur” applications evolve and survive under the pressures of modern software delivery processes and deadlines.

About the Author / Sunil Mavadia

Sunil Mavadia is director of Customer Success for XebiaLabs, provider of software for continuous delivery and DevOps. A former customer, he was the head of major DevOps transition projects with his previous company. Sunil runs Client Services, including consulting and implementation of the XebiaLabs product suite: XL Release, XL Deploy and XL TestView.

September 16, 2016
Synthetic Monitoring: The Start of the Monitoring Journey
Under pressure to innovate and deliver rapid updates to their applications, developers often place monitoring as an after-thought. In today’s world, where a slowdown can translate to customer attrition and an outage can lead to millions of dollars in losses and negative press, ensuring satisfactory response time has evolved to be one of the most critical needs in the early stages of development and is a common goal to ensure DevOps success.

The Shift-Left of Monitoring: To study emerging patterns of how and when DevOps teams start monitoring, we interviewed several DevOps squads. Almost unanimously the responses were:
1. They care most about knowing, Is the application up and loading quickly? Are all critical user interactions with the application responding within acceptable standards?
2. They would like to get this information proactively throughout the development life cycle so they can determine if any code check-in impacted the performance/
3. They would like to monitor with minimum setup and configuration and don’t have the time to learn complex tools/
To satisfy these needs, synthetic monitoring becomes the starting point for monitoring.

With synthetic monitoring, DevOps teams can simulate user behavior and proactively detect performance problems from around the world and around the clock, before they impact their users. They can maximize uptime and ensure good response by pinging the application URLs and APIs and running simulations to check if the most common paths traversed by users are responding fine.

Some of the key capabilities of synthetic monitoring that are important to DevOps squads:
- Reports availability, response time and user satisfaction score (such as Apdex) for all web pages, URLs and critical user interactions from around the world, 24X7
  - Runs synthetic tests as often as once per minute or even less than that, to test:
    
    Webpage loads
    
    REST API calls
  - Runs simulated user interactions through scripts once every few minutes
- Requires minimum setup and maintenance with preferably a SaaS solution with globally hosted probes. Private probes are required for monitoring internal applications.
- Incorporated into the DevOps life cycle as part of the delivery pipeline such that synthetic tests can be run in dev/test, staging and then in production.
- Provides granular controls on what tests to run, how often, from where and what to validate in the HTTP response code.
- Easy-to-use scripting tools that do not have a learning curve and preferably open-source. Often, automated regression test scripts used in development can be reused to run synthetic simulations in production.
- Alerts users of issues through not only their preferred channel of notification, such as email or SMS but also through their primary collaboration channel.
- Provides relevant alerts and avoids alert noise by appropriate alert filtering and retries on failure.
- Identifies whether an issue was caused by an application deployment or change by presenting an auto-correlated view of alerts, metrics and deployment activities.
- Isolate quickly whether the problem is in the application code or one of its dependencies such as a network latency issue or a third-party service slow down.
- Diagnoses the exact step of failure by providing waterfall analysis of all page assets, pinpointing slow requests, broken links, large images, slow external API calls and more.
- Accelerates diagnosis with an automated browser screenshot of the failure.
- Compares two versions of applications to enable A/B testing.
- Provides daily, weekly and monthly scores and reports to ensure that target SLAs for uptime and user satisfaction are being met.
Stay tuned for the next blog on DevOps and log analytics in this five-part blog series and don’t forget to register for an upcoming interactive webcast, “Learn Why We Must Shift APM Left in the DevOps Lifecycle.”

About the Author / Payal Chakravarty

Payal Chakravarty is offering leader for the Application Performance Management portfolio at IBM. She has nine years of experience in enterprise technology in various roles including product management, strategy, DevOps and engineering management and software development. She defined and delivered software as a service (SaaS) and on-premises software for Application Performance Management, Hybrid Cloud Monitoring, Data Center Management, and Operational Analytics. Payal has an MBA from Duke University and a MS in Computer Science from North Carolina State University. You can find her on Twitter, where she tweets about all things DevOps and cloud. Connect with Payal on LinkedIn / Twitter
September 15, 2016
Chef Boards the DevOps Express with CloudBees, Others

You often may have more questions than answers as you progress along your DevOps journey. Which tools should I choose? Do these tools work well together? What have other people done in my situation? You’re often left Googling to find the right integrations and piece together an architectural solution.

Today, I’m excited to announce that Chef is joining DevOps Express, a new industry initiative comprised of 14 leading DevOps vendors and service providers. Led by CloudBees and Sonatype, and including everyone from Atlassian to GitHub, this initiative is focused on creating solutions that will help you adopt DevOps practices. Specifically, by defining reference architectures and highlighting best practices, supported integrations and solutions, we believe that DevOps Express will simplify and accelerate DevOps adoption for organizations of all kinds.

DevOps Express uses popular technologies spanning multiple solution components to provide a framework for building reference architectures that are better integrated and supported. Creating reliable and actionable reference architectures for organizations will ease DevOps adoption and minimize risk for organizations.

DevOps is collaborative by its very nature—it’s all about bringing teams together. This includes cultural transformation, breaking down silos between disparate teams and working together around the common goal of adding value for customers. These principles are just as true for us, the vendors providing tools to help you on your DevOps journey. We, too, must break down silos and work together to provide more value for you, our common customer. I’m looking forward to what we’ll build.

About the Author / James Casey

James Casey is vice president of Partner Integration at Chef. His career spans more than 15 years in companies ranging from mobile and finance startups to CERN, the birthplace of the World Wide Web. He specializes in building tools for operating large computing infrastructures. He previously created monitoring tools at CERN for the Large Hadron Collider.

September 14, 2016
Tasktop Survey Shows Customer, Business Needs Must Align
Recently, Tasktop surveyed 120 global IT professionals on their software delivery processes. The results were based on analysis obtained from its licensed Forrester Modern Application Assessment Tool, which helps organizations evaluate where they fall on the spectrum of modern software delivery and offers insight into what needs to happen next.

The survey covered topics such as customer needs, application development and delivery objectives and strategies, business value, metrics, tools and more.

Key Findings

In spite of the increasing adoption of agile and DevOps initiatives, the survey identified the need for stronger alignment with customer and business needs and tools that increase coordination in the software delivery process.

Developers, tech leads, project managers, chief technology officers and other IT titles surveyed reported the following:
- Only 6 percent strongly agreed they could trace the contents of a software release back to business needs or customer satisfaction.
- Just 9 percent strongly agreed their application development and delivery strategies were aligned with business strategies.
- And, strikingly, a scant 15 percent strongly agreed their work management tools assist in coordinating the work of the software delivery team satisfaction.
It seems that in spite of a strong industry drive toward being more responsive to the the needs of the business, there remain large gaps in how organizations realize the benefits of the tools they use to support these initiatives.

Any parties interested in taking the survey and receiving an assessment can do so here.

About the Author / Betty Zakheim ‎

Betty Zakheim is vice president of Industry Strategy at Tasktop and is the vertex between Tasktop’s customers, the company’s product team and marketing team. She has an extensive background in software development, software integration technologies and software development tools. As a software development manager, she was an early adaptor of “iterative development,” the precursor to Agile. As the VP of product management and marketing at InConcert (acquired by TIBCO), she pioneered the use of Business Process Management (then called “workflow) as the semantic framework for enterprise application integration. Connect with her on LinkedIn and Twitter.
September 14, 2016
Enlisting the C-Suite in Disaster Recovery Initiatives
When disasters make headlines, corporate executives often have knee-jerk reactions and call for business continuity solutions to be implemented immediately. However, when push comes to shove, those very same executives tend to put up roadblocks with concerns over budget, priorities, vulnerability assessments and security.

Perhaps more concerning, according to a June 2015 Ponemon Institute report, there are “a large portion of companies who remain vulnerable as a result of lack of executive interest in preparing for worst-case scenarios.” This creates a precarious situation for DevOps professionals that understand the severity and breadth of threats that can trigger downtime—from human error to power outages, cyberattacks and natural disasters.

To expedite disaster recovery initiatives, IT teams must enlist top executives that influence budgeting directly. This often calls for varied approaches that speak to specific executive concerns and issues.

Understand Your Options: Disaster Recovery vs. Backup

It’s very common for companies to confuse disaster recovery and backup solutions. Both are available via cloud, giving teams access to capabilities that were once only available to enterprises with huge IT footprints. When you approach any executive, it’s critical to understand various services and how they can work in tandem to deliver the most cost-effective protection.

Backup ensures companies do not completely lose data because it is backed up with copies. While it is important to have copies of data, accessing and restoring backups can take some time. Therefore, for workloads with important but not extremely time-sensitive data, backup can be sufficient while satisfying budget restrictions. In the fast-paced DevOps world, backup usually falls short.

On the other hand, cloud-based disaster recovery ensures minimal—if any—downtime. Applications can fail over and be up in running in seconds. Further, testing can be done at will without any impact on production environments. For workloads that demand continuity of service and aggressive recovery point objectives (RPOs), disaster recovery solutions are the better option and can also deliver cost efficiencies.

For many operational and regulatory compliance reasons, companies may require a mix of both backup and disaster recovery. When evaluating service providers, check into how easy it is to apply backup and disaster recovery based on your development and application requirements. Take a close look at pricing models associated with each—including any support fees.

CEO/COO – Chief Executive Officer and/or Chief Operations Officer

While CEOs and COOs generally delegate detailed budget decisions to their teams, they are still ultimately responsible for overall company performance and reputation. Anything that threatens ongoing conduct of the business is their purview. Be prepared to discuss risks in real terms, and clarify that a “disaster” can be triggered by something as simple as human error. They will care most about considerations such as:
- Time to business resumption [e.g. near-zero recovery time objective (RTO)]
- Capital investment via pay-as-you-go options
- Ability to prioritize data and workloads, both for budgetary and business continuity purposes
- Data loss estimates, in the case of a disaster
- Testing flexibility, to ensure an operational, reliable solution
- Independent validation from similar customers or analysts that a solution is reliable, proven and cost-effective
CIO – Chief Information Officer

Theoretically, this should be the easiest executive to convince because the CIO has a personal stake in recovery, but remember CIOs have a tough balancing act between controlling budgets and limiting exposure. The 6 Disaster Recovery Doppelgangers quiz and e-book can help CIOs approach their disaster recovery challenges across the organization. CIOs generally focus on:
- Ability to see and manage the recovery process
- Scalability of resources with on-demand access, often honing in on flexible terms
- Security and compliance capabilities and support
- Testing at will to ensure solution performs despite configuration changes to the day-to-day operational environment
CFO – Chief Financial Officer

Everything boils down to financials for CFOs, so they should be approached from a fiscal angle that demonstrates value backed by metrics. Be prepared with unbiased, independent information that appeals to their risk averse nature. What other financial benefits might come from leveraging cloud-based disaster recovery? For example, in some cases DevOps teams are beginning to use the failover cloud as a load testing environment that would otherwise require significant on-premise investments. Disaster recovery-as-a-service (DRaaS) environments with advanced security can also be used to check for possible vulnerabilities to cyberthreats.

CFOs often care about:
- Flexible pricing options that can be tailored at a granular level based on services required
- Pay-as-you-go pricing models that avoid upfront capital investment
- Geographic constraints on their data, particularly if backups or failovers need to be maintained in a specific location due to jurisdiction requirements
- Extended DR use cases that could offset other costs like security testing and quality assurance
CMO – Chief Marketing Officer

On top of branding, advertising and public relations responsibilities, CMOs have key objectives that pertain to customer loyalty and overall corporate reputation. They may not be interested in the details of services, but can be a powerful advocate that can speak to the need for business continuity solutions that will protect brand image, reinforce messages about your technology innovation and maintain excellent customer support. Familiarize yourself with real-world stories that demonstrate how media—both traditional and social—cover outages and their negative impact to business. One need not look further than the recent Delta and Southwest outages.

The concept of DevOps is about culture as much as it is about technology, and communication and collaboration are key. By understanding the needs and responsibilities of all stakeholders involved, teams can cut through politics, efficiently protect business and begin to leverage cloud-based DR technologies for initiatives far beyond recovery, alone.

About the Author / Lilac Schoenbeck

Lilac Schoenbeck is vice president of Product Management and Marketing at iLand. She has nearly 20 years of experience with product management, marketing, strategy, business development and software engineering in the grid, virtualization and cloud domains. She is currently vice president of marketing at iland, a global enterprise cloud hosting provider. Prior to this role, she led cloud and automation marketing for BMC Software and has worked for IBM, Fortisphere, Innosight and the Globus Alliance. Lilac holds an MBA from MIT Sloan School of Management and a Computer Science degree from Pacific Lutheran University.
September 14, 2016
Communication Skills Matter in DevOps

While the precise definition of DevOps is an evolving matter, a simple way to describe it is this: DevOps is a change of mindset toward an agile and inclusive approach to IT. DevOps enables IT professionals to think and work beyond technology silos, thereby deriving meaningful results at a faster rate than with more traditional methodologies.

This involves going outside of our comfort zones and collaborating outside the confines of our own cliques. By working across operational boundaries, DevOps will require an understanding of technical, operational and service aspects of the business. This means the heart of DevOps lies not in technology, methodology nor administration: The heart of DevOps lies in communication, which brings all these together.

DevOps professionals seem to agree. In Incapsula’s DevOps Salary Survey conducted in 2015, the California-based cybersecurity firm identified communication skills as one of the highest priorities for DevOps professionals, almost as much as operational skills.

In other words, effective communication across the organization is considered as important as actually building the product, and it is integral to building the product itself. This means when you’re in the field of DevOps, a smart investment in communication skills will pay off for both individuals and the team.

Communication Fosters Teamwork

There usually exists a disjoint between technical and non-technical departments, particularly in technology companies. Engineers, for example, might be fascinated by an elegant piece of code, an algorithm that automatically governs a process or an infrastructure that does exactly what it’s supposed to do. But to the rest of the organization, those things take place purely in the background and work best when they aren’t noticed at all.

Tech people take pride in the technology, while operations people take pride in business results. The two often find themselves at odds due to a lack of communication about what is really needed, and how to get there. Successful communication in DevOps focuses on finding common ground and working toward achieving this.

For communication to be effective, the emphasis should be on the user of your message. You’ll need to have a deeper understanding of where they’re coming from. No amount of expertise matters if you can’t convey it properly. You can’t gain any growth or value for your career or organization if there is always a unidirectional disconnect.

Bottom line is, you need to correctly identify your intended recipients and find a common ground to better engage.

You Can Increase Your Value as a DevOps Pro

Trust is an essential component of teamwork, which is also important in the development life cycle and in decision-making processes. Being a communicator enables you to better establish trust among your colleagues—something that, unfortunately, is lacking in many IT project life cycles.

This is why pure technologists don’t necessarily make good DevOps professionals—an observation highlighted by the Incapsula survey, which shows that a mix of general and technical skills are essential for a successful DevOps career. In fact, general skills are usually more important in securing higher-paying jobs in this field. These include understanding business operations, developing communication skills and remaining flexible and open to change. In addition, the rising trend in outsourcing DevOps pros across a global talent pool means your communication skills have to transcend languages and contexts.

A good DevOps professional knows that value is not just about the technology, but rather about the product. Even the best technologies in the world are just abstract concepts until you translate them into a product people can actually use and enjoy. Thus, going beyond technical capabilities, you will need to know how to collaborate to transform technologies into useful and marketable products.

You Can Advance Your Career Faster

Chatting up the project managers, glad-handing the operational staff and picking the brains of departmental leaders may not come naturally to pure technologists. However, for DevOps professionals increasingly engaged in conversations across the enterprise, knowing the language unique to the organizational culture—verbal and nonverbal—can make all the difference in terms of career advancement.

Such organizational language can be considered as its own kind of coding. This facilitates everything from a working knowledge of financial reporting, to the listening skills needed to understand the technology goals meaningful to each business unit. It’s also how unwritten rules about business priorities or hierarchies are communicated.

After all, the career survey cites at least 26 job descriptions among DevOps professionals, including project manager and operations manager, among others. This means you don’t necessarily have to get stuck in one position or job description. In an organization that fosters the DevOps culture, your value goes well beyond your technical capabilities, but rather the focus is more on organizational skills.

The Takeaway

Since DevOps involves cross-functional teams instead of compartmentalized departments, everyone will need to be more involved in business operations, product development and support. Being an effective communicator is at the heart of all this, and it can spell the difference between success and failure in a DevOps environment.

It’s easy to think that there is little more to learn in terms of communication, especially if your DevOps integration is already mature and your team is functioning optimally. However, your investment in becoming a better DevOps communicator begins with learning the language and culture of the organization. This also includes a continuous reassessment of skills and the ability to build connections from each and every encounter with colleagues, partners and other stakeholders.

About the Author / Laureen Fagan

A senior PR counsel and thought leader, Laureen Fagan has 15 years experience as a media and PR professional, which includes her stint at CBS and Fox broadcast affiliates in the United States, and in print and wire-service newsrooms in Chicago, Washington D.C., and Jerusalem. Laureen received her MSJ from Northwestern University’s Medill School of Journalism, and completed additional graduate study at University of Notre Dame in Theology / Hebrew Bible that includes French, Arabic and Hebrew study. In addition to tech and business, Laureen creates informed content and deep analysis on international affairs, health care, culture and religion.

September 13, 2016
Top 5 DevOps Practices to Improve Security in Engineering
We’ve all been there … A new application or feature needs to be deployed yesterday and the last thing anyone wants to do is address security requirements. On the flip side, the very last thing anyone wants to address later is a security breach or a cost associated with non-compliance. Not only is it a massive headache but also it’s extremely expensive. According to the IBM X-Force Threat Intelligence Report 2016, the average cost of a data breach in 2015 was $154.20 per record ($363 per healthcare record) with the average total cost of a breach estimated at $3.79 million.

Not only is a breach expensive in terms of cost that can be easily quantified, but there are also costs that are harder to quantify such as the impact to branch image and customer loyalty. According to a new FireEye research report, 76 percent of respondents would likely take their business elsewhere due to negligent data-handling practices. In an incredibly competitive technology space, none of us can risk turning a blind eye to security if we want to attract customers with cool new features and then keep those customers with trust and reliability.

Security seems to be one of those topics that you either love or hate. I’m personally interested in it; however, I realize it’s not an interest shared by all. In the land of unicorns, we want all developers (infrastructure and application) to have more ownership in security, but tight schedules combined with the lack of expertise and reliable controls often can make that strategy unreliable. To make matters worse, a secure system and application isn’t something that is always glaringly visible to an end user or product owner. As a result, security may easily get deprioritized as something that “can be fixed later.” The “fix it later” strategy can be a dangerous decision, as many cybercriminals now are actively taking advantage of those that deploy quickly without adequate controls. How do you balance the customer’s desire to have new features delivered quickly with the fact that they need secure systems protecting their data against malicious threats?

Several common DevOps practices inherently lend themselves to providing a development and delivery pipeline that can improve your overall security posture. DevOps combined with SecOps includes practices that shift operational and management aspects of a system to the left to ensure we are able to reliably delivery and manage secure systems.

5 Security Practices Worth Considering

Below is a list of the top five DevOps practices and tooling that can help improve overall security when incorporated directly into your end-to-end continuous integration/continuous delivery (CI/CD) pipeline:
1. Collaboration
2. Security test automation
3. Configuration and patch management
4. Continuous monitoring
5. Identity management
If you iteratively build in security practices as you move infrastructure and application code through the deployment pipeline, it greatly increases your security posture as well as decreases the cost of future rework.

Collaboration and Understanding your Security Requirements

Many of us are required to follow a security policy. It may be in the form of a corporate security policy, a customer security policy and/or a set of compliance standards (ex. SOX, HIPAA, etc). Even if you are not mandated to use a specific policy or regulating standard, we all still want to ensure we follow best practices in securing our systems and applications. The key is to identify your sources of information for security expertise, collaborate early and understand your security requirements early so they can be incorporated into the overall solution.

Security Test Automation

Whether you’re building a brand new solution or upgrading an existing solution, there likely are several security considerations to incorporate. Due to the nature of quick and iterative agile development, tackling all security at once in a “big bang” approach likely will result in project delays. To ensure the project keeps moving, a layered approach often can be helpful to ensure you are continuously building additional security layers into your pipeline as you progress from development to a live product. An example of building gates in as you progress through your pipeline is shown below. Security test automation can ensure you have quality gates throughout your deployment pipeline giving immediate feedback to stakeholders on security posture and allowing for quick remediation early in the pipeline.

Configuration Management

In traditional development, servers/instances are provisioned and developers are able to work on the systems. Sometimes there is a “golden image” developers use to provision that can ensure that the provisioned servers/instances have a hardened operating system. However, as soon as any additional development and configuration activities happen on those servers, that server is no longer golden. To ensure servers are provisioned and managed using consistent, repeatable and reliable patterns, it’s critical to ensure you have a strategy for configuration management. Your strategy may include Chef for one situation, Salt for another situation, immutable infrastructure, or a combination of practices. The key is ensuring you can reliably ensure and manage consistent settings across your environments.

Patch Management

Similar to the concerns with configuration management, you need to ensure you have a method to quickly and reliably patch your systems. Missing patches is a common cause of exploited vulnerabilities including malware attacks. Being able to quickly delivery a patch across a large number of systems can drastically reduce your overall security exposures.

Continuous Monitoring

Ensuring you have monitoring in place across all environments with transparent feedback can alert you quickly of potential breaches or security issues. It’s important to identify your monitoring needs across the infrastructure and application, and then take advantage of some of the tooling that exists to quickly identify, isolate, shut down and remediate potential issues before they happen or before they become exploited. Part of your monitoring strategy also should include the ability to automatically collect and analyze logs. The analysis of running logs can help identify exposures quickly. The collection and analysis of security logs can identify issues that require remediation as well as provide automatic collection of compliance evidence. Compliance activities can become extremely expensive if they are not automated early.

Identity Management

DevOps practices help allow us to collaborate early with security experts, increase the level of security tests and automation to enforce quality gates for security and provide better mechanisms for ongoing security management and compliance activities. While painful to some, it has to be important to all if we don’t want to make the headlines.

We are all busy keeping up on everything that is emerging in technology and it’s difficult to keep up on all of the latest issues, so relying on reputable tools and reliable sources of information can be extremely beneficial. Some of my favorite resources in this area are The OWASP and SC Magazine. IBM X-Force is another great reliable resource to check out for the latest threat research and services. There are also a slew of tools out there to help with different areas of security in each of the practices covered in this blog. I’d love to hear about some of your favorites at @Shelbee_SE.

About the Author / Shelbee Smith-Eigenbrode

Shelbee Smith-Eigenbrode is a senior software engineer/IT architect at IBM and has been in IT for 19 years. She has worked across varying roles spanning the software development life cycle. Her experience across functional roles as well as performing that work deeply inside traditional silos has contributed to her passion for embracing the DevOps culture and transforming the way teams are delivering technologies by adopting DevOps practices. She is a member of the IBM Academy of Technology committed to driving innovation and technical advancement.
September 12, 2016