Category: Doin’ DevOps

Breaking the Cycle of Dependency
While technology is an important component of DevOps and accelerating delivery, there are other aspects of process and culture that are critical to keeping the cycle moving to realize the goals of reducing lead time to become more responsive to the needs of the business.

If you go to most agile teams and ask the question of what is stopping them from going faster, they will typically respond that they are waiting for “something.” Something can include:
- Waiting for work to enter their backlog
- Waiting for environments
- Waiting for another development team to provide some service or capability that is needed
These obstacles include:
- Large batch sizes
- Lack of continuous flow of work into Agile teams’ backlogs
- Calendar-based gated releases
- Test environment complexities
- Environment availability
This manifests itself in the current state as shown below as the vicious cycle. When teams are only delivering system releases a few times a year, then the business believes it needs to pack everything it can think of into that release, since waiting for the next release incurs a delay of months. The leads to large complex releases with many dependencies. This, in turn, slows down the development and testing of these releases and requires a lot of release coordination, resulting in long lead times and the inability to release frequently. And this leads into the cycle repeating.

So what are the countermeasures needed to break this cycle? They include:
- Smaller batch sizes
- Architectural, design and development decoupling techniques
- Increased automation
- Readiness-based release capability
Smaller batch sizes require applying MVP (minimal viable product) techniques. When IT gains the trust of the business to deliver more frequently, the business will be more open to focus on the minimal product set of highest priority items it believes can deliver business value. Accelerated delivery provides the ability to test business hypotheses and gain feedback from customers more quickly to determine what worked and what needs changed. The enterprises that can turn this crank more quickly gain a huge advantage in the marketplace.

Modern web architecture techniques (e.g. microservices, APIs), along with design techniques such as feature toggling to enable dark- and canary-launching allow applications to be deployed independently and with direct control of customer impacts. This increases development velocity due to simplifying and reducing the lifespan for managing feature or release branches in the code base.

Increased automation combined with a move to readiness based releases allows application releases to be deployed when ready rather than waiting for calendar-based change windows. They key here is not sacrificing quality, auditability or security but rather building those capabilities into your applications and delivery pipeline and requiring those certifications are earned before an application can be released.

About the Author / Carmen DeArdo

Carmen DeArdo is the director of Build Technologies at Nationwide Insurance. He is responsible for helping drive accelerated delivery utilizing Lean and DevOps techniques across the end-to-end delivery value stream. One current focus area is the creation of an integrated delivery pipeline capability.
December 20, 2016
How Continuous Can Integration Be?
My blog, “7 Pillars of DevOps,” identified seven essential best practices areas that make up successful DevOps. One of the seven pillars is continuous integration (CI). The blog explained that the pillars are not silos, but rather foundations that need to be kept in balance. A well-balanced CI implementation performs integrations that are fast enough to fit within the time budget for an end-to-end DevOps pipeline.

Compared to older waterfall processes in which large software changes were integrated occasionally, the DevOps CI concept of frequent, small, incremental integrations has many merits. Quick feedback on frequent integration problems enables a release consisting of many individual changes to be built incrementally with confidence. The root cause of integration problems can be isolated much faster when the changes are integrated incrementally. Since faster integrations are better, just how continuous can integration be?

Contrary to the name, integration is never truly continuous. Even if a continuous stream of changes to integrate existed, typical CI process steps (listed below) require a non-zero amount of time. These steps absolutely interrupt the continuous integration cycle to some extent.

• Merge changes in the integration repository
• Check integration repository entry criterion
• Run static analysis scans of the integrated source code
• Orchestrate the build resources
• Create the build
• Save build the artifacts to artifact repository
• Run unit tests
• Save unit test results to artifact repository
• Release the build resources back to the pool
• Orchestrate the functional build test resources
• Run functional tests
• Perform analysis and assessments
• Save functional test results to the artifact repository
• Remediate any problems discovered during the above steps
• Promote the build to the delivery stage
• Release functional build test resources back to the pool.

For CI to perform as continuously as possible, there are three categories of CI best practices:
1. Modularize the product design to support modular CI processing
- Modular code designs, using 12-factor-app principles, allow incremental changes to be integrated.
- Microservice architectures enable each portion of a product to be integrated as available rather than requiring the entire product to be integrated at once.
- Using containers can help to optimize infrastructure orchestration.
- Re-factoring build schedules to remove any unnecessary build dependencies between modules or microservices eliminates time delays.
- All changes are checked into a common trunk branch. This requires the ability to toggle feature changes on and off quickly and easily to enable a release whenever it is needed.
1. Optimize the CI Infrastructure
- Vertical and horizontal scaling of both the CI build resources and test resources creates an infrastructure optimized for each CI stage run.
- Predictive orchestration of CI infrastructures enables CI and test resources and processes to be set up in advance.
1. Accelerate CI processes
- Pretest and pre-check integration deliverables prior to integration to trunk, to minimize costly remediation delays.
- Pipeline CI build and test processes to eliminate setup delays between processes.
- Use Fail fast to prioritize the most important tests as early as possible.
- Use accelerated testing techniques such as risk-based specific test selection to speed up CI testing.
- Use in-process analytics that can detect threshold exceptions prior to the end of the CI build or test process.
- Remediate problems fast using automated rules for roll-backs or targeted problem reporting.
- Establish a policy for deciding when and how to revert changes that break CI processes so that the pipeline doesn’t get stuck when check-in breaks the trunk.
The above CI practices commonly reduce the time for CI from many hours to minutes per build. While minutes is still not truly continuous, for most practical purposes CI processing in minutes is fast enough to suit even the most aggressive end-to-end DevOps delivery pipeline goals.

Summary

What do you think? Do you agree with the above CI best practices? Are there others you recommend?

While DevOps implemented with all seven pillars provides a strong foundation for long-term enterprise business improvements, it is important to understand DevOps is not an island. Enterprises implementing DevOps should be aware that DevOps interoperates with other IT systems and practices. Enterprises are well-advised to put in place governance policies that encourage the selection of tool-agnostic IT partners with solutions that best suit the needs of each unique enterprise and can integrate and evolve DevOps together with all their IT systems.

— Marc Hornbeek
December 16, 2016
Confessions from Fannie Mae, Liberty Mutual and Capital One
Learn from real-world stories from presenters at the All Day DevOps conference …

True Story

Over the past few years, Fannie Mae transformed the way in which it delivered software. Deploys increased from 1,200 per month to 15,000 per month. At the same time, productivity increased by 28 percent while costs were reduced by 30 percent.

But, how did Fannie Mae do it?

During the All Day DevOps conference, more than 13,500 practitioners from around the world came together to learn from their peers in the industry. Barry Snyder, senior manager of DevOps at Fannie Mae, was one of 57 practitioners who shared his real-world journey through his enterprise transformation.

Choke Point or Checkpoint?

Eddie Webb, director of Software Delivery Platforms at Liberty Mutual, also shared his organization’s journey into DevOps. Eddie described how Liberty Mutual evolved its organization, tool chain and processes to go from 20 percent of builds being deployed to 60 percent over the past 18 months. He described how the company documented its value delivery chain and identified all of its choke points in the continuous delivery process that would need to be automated to achieve its new velocity and quality targets.

Run the Gauntlet

The All Day DevOps conference recorded more than 57 practitioner-led sessions (30 minutes each) including those from Barry and Eddie. Every session is now posted online and is free to watch. The conference itself had three tracks: CI/CD, Automated Security and Modern Infrastructure, including:
- Application Secret Management with KMS – Andrey Utis of Capital One
- Getting out of the Job Jungle with Jenkins – Damien Coraboeuf of Clear2Pay
- Serverful Computing – Taking One for the Team – Paul Czarkowski of Blue Box Group
One of the best ways to learn about DevOps is to hear from the experiences of others who have run the gauntlet. Take 30 minutes this morning, at lunch or at home this evening to watch your first online session with All Day DevOps On-Demand.

— Derek E. Weeks
December 14, 2016

DevOps Survey Says! State of DevOps, Reliance on Scripting and IT Automation

What our surveys told us about the state of DevOps, Reliance on Scripting and IT Automation

DevOps Survey Results: Scripting & IT Automation

A lot of IT Operations teams including application owners, configuration managers, middleware specialists and database administrators are managing infrastructure configuration change with manual processes, spreadsheets and scripts. They are spending a lot of time writing and maintaining a lot of scripts. Even with all those scripts, spreadsheets and processes and the resources they consume, teams are still not getting the visibility, control and error-proofing that they require.

That is the message from five recent surveys conducted by Orcaconfig among IT industry pros. Perhaps these results should not be that surprising. But several years into the DevOps and IT automation movements, there is still plenty of room for improvement.

About one-third of respondents said they spent more than half of their time writing and maintaining scripts.

In complex application environments with multiple relationships and dependencies between applications, databases, middleware and operating systems, “changing this can easily (and unwittingly) change that.” Gartner refers to this as a domino effect. So, scripting to deploy changes becomes more and more tricky and thus, requires more and more time to do, test, redo and retest.

what_percentage_of_time_is_spent_writing_or_maintaining_scripts_-_survey_from_orcaconfig-com_2

Because of the risks involved with release or configuration-related scripting errors in production environments, some organizations hand these typical operations responsibilities to developers. The question is worth asking: Is release and configuration-released scripting the best use of Dev or Ops’s time?

how_do_you_maintain_scripts_when_the_author_is_no_longer_available_-_survey_from_orcaconfig-com_3

With all these scripts holding key configurations together, are organizations at risk of “losing the recipe” if key employees leave? Apparently so. In our surveys, 30 percent of respondents admitted, “It’s a problem, we don’t really have a solution in place,” when asked about maintaining the spaghetti-works of scripts if some of those key employees suddenly leave the organization. Nearly half mentioned that they rely on transfer of information (TOI) before a key employee leaves.

Employees exit companies for a number of reasons and some are in a bigger hurry than others to move on. Does TOI provide all the safeguards needed for the enterprise?

Scripting might consume a great deal of IT resources and introduce a considerable risk with the loss of key talent. But does it at least accomplish the functionality that teams need? The next few charts provide insight to how well scripting achieves the visibility and error-proofed automation that teams need.

Ecosystem Visibility

Configuration Drift Detection

For performance, security and audit reasons, organizations have an ongoing need to maintain configuration compliance in their application ecosystems. So detecting configuration drift is essential. Automatically detecting configuration drift is the goal. Despite complaints about the method, approximately half of respondents relied on scripting to accomplish drift detection.

how_does_your_organization_detect_configuration_drift_in_complex_application_database_middleware_environements_-_survey_from_orcaconfig-com_2

how_do_you_know_which_databases_are_being_used_by_which_applications_across_your_ecosystem_-_survey_from_orcaconfig_2

Mapping Databases to Applications:

Sometimes IT operations are asked simple sounding questions such as, “What are all the applications that use this database?” and vice versa, “Which databases support this application?” Once again, nearly one-third of respondents admitted, “We really don’t know which databases are being used by which applications. Wish we did.” Another 36 percent relied on scripting or other manual processes to get that answer.

Is it reasonable (in 2017!) to still rely on scripting to get basic information about interrelationships between applications, databases and middleware? Is it acceptable to operators, managers and auditors simply do without this information? Will Visio and similar static files always provide up-to-date information that IT Operations needs?

Automation & Error-Proofing

Environment-Aware Releases
When moving an application through pre-production stages and into production environments, Release Managers want to ensure that the new release will just work … as planned … drama free. This requires among other things that

the configurations are up to date and production-ready, and
that those business-critical applications are promoted simultaneously with their production-level configurations.

how_does_your_organization_achieve_environment_aware_releases_

Thirty-eight percent of respondents said they relied on scripting and other manual processes to try to accomplish environment-aware releases. To ensure ‘everyone is on the same page’ many organizations use multiple planning meetings, sharing and updating spreadsheets and SharePoint files with (hopefully) the latest configuration information. Even among this group, respondents commented that scripting just does not work well for them.

Despite the security, compliance and performance implications of configuration and release problems, 15 percent of survey respondents admitted they “really don’t achieve environment-aware releases.”

Scripting isn’t Free; IT Ops Needs More

Scripting is quite naturally the go-to method for many application owners and IT Ops teams. The cost of scripting or even finding and fixing a scripting-based error hardly ever appears clearly in budgetary line items. In the moment, it can feel like it is free. But over time, maintaining scripts and homegrown tools can build a hidden but costly mountain of technical debt. It might well be worth these costs and risks if scripting effectively resolved ongoing operations needs such as ecosystem visibility and drama-free deployments. However, time and again our respondents said they lacked basic capabilities such as configuration drift detection, mapping applications to databases and middleware or ensuring environment-aware software releases.

— Scott Turner

December 2, 2016

Adding Usability Testing to the CD Pipeline

Do you include usability tests in your continuous delivery pipeline? If not, you could be making a big mistake.

Usability testing, which entails having actual users test an application for user-friendliness, intuitiveness and accessibility, gets easily lost within the DevOps conversation. If you want to do continuous delivery, waiting on manual usability tests may seem like a major barrier.

Why Usability Testing Matters

Yet, DevOps teams that ignore the importance of usability tests do so at their peril. Continuously delivered apps will provide little value if they are difficult for ordinary people to use. Users have little tolerance for applications that lack usability.

It’s worth noting, too, that DevOps makes usability testing even more important than it would be within a waterfall delivery chain. When you do continuous delivery, your software changes more quickly. That increases the chances of introducing a change into production that negatively impacts app usability.

How to Do DevOps Usability Tests

So, how can you do proper usability testing without slowing down your continuous delivery pipeline? Unfortunately, there’s no easy solution. Unlike integration and unit tests, usability tests cannot be easily automated.

You can, however, work closely with your in-house QA team to perform usability tests before changes reach the production stage of your pipeline. This will work as long as your QA team is able to replicate real-world usability conditions well.

Alternatively, you could release changes to a select group of users before making them generally available. Those users would then test for usability issues quickly and report them to you before your updates reach the wild. This scenario would essentially mean doing a very fast beta release for certain users. If that seems unfeasible, keep in mind that, as long as each of your continuously delivered changes is minor, quick beta testing is manageable.

Whatever you do, the most important thing is to avoid ignoring usability testing. Otherwise, all of the hard work you put into continuously delivering your app could be for nought.

— Chris Tozzi

November 29, 2016
A Ferrari and DevOps: More Similar Than You Might Think

In a world where customers aren’t short of options, all businesses are characterized by the need to achieve customer delight. From a technological standpoint, a large part of that hinges on fast-tracking the release of high-quality software. A release every quarter is being replaced by a release every week and sometimes even sooner. Expectations have skyrocketed while the timelines have shrunk even more. It is now imperative for all the different components to sync together effectively to create a competitive advantage for the business that can be sustained over a period of time.

All the water-cooler talk around DevOps notwithstanding, it’s true identity still varies vastly based on the passionate opinions of participants with varied schools of thoughts. It also bears mentioning that while all of their varied opinions carry a sliver of truth, they also are significantly separated from the heart of the matter.

To better understand the situation, let’s jump into a story: Once upon a time there was a monk who owned a Ferrari and had no interest in selling it. Every morning when the monk left to teach his mindfulness class, there were three blind men who were captivated by the sound of its engine and the smell of burning rubber. And, yet, they couldn’t see the very object that had captured their fancy. So, one fine day they decided to touch the Ferrari and exchange notes.

The first man touched the broad wheels of the Ferrari and exclaimed that it was a large contraption made of soft rubber. The second man ran his hands across the exquisite curves of the car and said it was like an ancient Greek statue, while the third one placed his hand on the Ferrari’s windows and concluded it was a moving glass palace on wheels. Although each was right in his own way, none came even remotely close to capturing the essence of a Ferrari.

By now, you don’t need a monk to tell you that the story of DevOps is very similar. For some, DevOps is all about inculcating the right culture so that different groups can work together seamlessly to achieve a unified goal. For others, it is about establishing the right processes and practices that are in sync with an organization’s business goals. And for those with an axe to grind or proprietary tools to sell, DevOps is all about achieving automated nirvana.

However, the ground reality is that software development teams constantly are facing increased pressure from business leaders to deliver faster than ever before. The business leaders, in turn, are under the hammer of market forces that require them to accelerate or die. The need of the hour is to deliver high-quality software at the rate of knots, while untangling any that might impede the time to market.

Continuous Everything

We at Happiest Minds believe the simple approach to DevOps is one that is “continuous” and at its core has the agile mantra of “people over processes and processes over tools.” The idea of continuously evolving and adapting to changing requirements and demands has been captured in what we call the 7Cs of DevOps:

The main objective is to ensure agile delivery by embracing continuous planning, continuous development, continuous Integration, continuous deployments, continuous testing, continuous monitoring and continuous feedback.

However, the cultural component of DevOps cannot be overemphasized. A large part of the success or failure of any DevOps engagement depends upon how willingly it is embraced within an organization and the kind of executive sponsorship it receives from the powers that be. The three widely recognized cultural models that most organizations come under are pathological, bureaucratic and generative. Needless to say, organizations that are riddled with a pathological or bureaucratic culture are likely to experience the least amount of success with DevOps because such organizations tend to cover up failures and eventually pin them on the most susceptible scapegoats.

The breeding ground that DevOps needs to flourish is a generative culture where information is shared freely and openly, the leadership encourages employees to learn and experiment with new ideas and failure isn’t looked at as the end of the world but rather an opportunity to learn and grow.

Eventually, organizations will have to embrace DevOps as an integral part of their strategy and not just as a liberal, forward-thinking experiment that scores them some brownie points. But it will take some doing, both at the grass roots and in the board rooms. One has to remember that a lot of people are easily attracted to a Ferrari, but perhaps not to the grind that goes into owning one.

The idea of having a successful DevOps program is much the same—it’s not just about engaging the best vendor or choosing the right tools or paying lip service to creating the right culture; ultimately, it requires overcoming organizational inertia, resistance to change and making a long-term commitment to the philosophy that takes a larger view of how DevOps can help businesses stay one step ahead.

About the Author / Arsalaan Kashif

Arsalaan Kashif is associate director of Marketing, Product Engineering Services at Happiest Minds Technologies and has a keen interest in all emerging areas of technology and innovation. Having worked with Unisys, Oracle and HCL Technologies for over a decade, he has experience with taking to market products and services across areas as diverse as application services, cloud computing, DevOps and big data analytics to name a few. Outside of work, Arsalaan enjoys watching noir films and reading John Irving classics. Connect with him on LinkedIn.

November 28, 2016
Infrastructure Management in the Age of DevOps
DevOps has emerged as the de facto cure-all for all that’s wrong with enterprise IT, breaking down silos and replacing them with agile and transparent relationships between developers and operations and seamless, fast workflows that drive greater efficiencies across IT. But legacy IT systems still need tending, even in a DevOps world. They must be secured and scaled, load-balanced, configured, backed up and monitored for compliance, without interruption to the enterprise—all considered infrastructure management tasks.

And that’s a problem, because these tasks often are handled manually using pre-DevOps processes, which breaks down the very promise of agility, speed and rapid service delivery that DevOps delivers.

Oleg Chunikhin, chief architect with EastBanc Technologies, emphatically agrees. “If an organization goes down the DevOps path, invariably old habits get carried over into the new world over. For example, if there’s a glitch with release management or a broken disaster recovery process, these problems are dealt with as they occur, or not at all, until they reach a point of critical mass.”

Chunikhin and I sat down to further discuss the issues and infrastructure management options available to any organization embarking on a DevOps strategy. Here’s our conversation.

Wolf Ruzicka: Why do infrastructure management tasks pose such a risk to DevOps success?

Chunikhin: One of the key problems is that there is a limited set of clear leaders in the DevOps tools and architectures market. There are tools for one thing (e.g. containerization) and tools for another (software configuration), and so on. But the market lacks a repeatable, standardized, off-the-shelf solution for infrastructure-level problems.

Instead, organizations could look to re-architect what’s already there. But this can turn out to be a risky, painful and expensive business. So, you’re left with few options.

As a result, making the move to DevOps becomes a challenging and risky endeavor for any CIO. If they take that risk, they end up attached at the hip to the time-consuming and manual processes that they already know—which go against the very promise of DevOps.

Ruzicka: What are the key DevOps infrastructure management considerations that IT needs to bear in mind?

Chunikhin: First and foremost, don’t delay. CIOs must recognize the problem of infrastructure management in a DevOps environment, before it’s too late. As they explore DevOps, forward-thinking organizations need to consider how its concepts and challenges can fit their organization:
- How can manual processes be eliminated?
- How can you strike a balance between the demands of the business and the need to operate in a compliant, stable and secure environment?
By addressing these challenges early on, you’ll ensure that each of these co-interdependencies is manageable. Before processes break down and critical systems are out of sync.

Ruzicka: Don’t emerging trends like cluster management and containerization address this very problem?

Chunikhin: Yes and no. Cluster management is an important part of any DevOps architecture. By abstracting out everyday management tasks, such as backups, and using orchestration to introduce efficiencies into complex environments, it’s a useful tool. But, cluster management software is notoriously difficult to set up for production use. While it can help developers manage many aspects of complex production environments, it isn’t a complete solution in and of itself.

Containerization helps with multitude of DevOps-related problems (software configuration, package conflict resolution, dependency management, etc.), but containerization alone is also not a complete solution.

Cluster management software combined with containerization, a.k.a container orchestration technologies, on the other hand, is the most recent and very promising development in the area of DevOps technologies. It promises out-of-the-box SaaS-like capabilities for fast service delivery, production quality, reliability, security, disaster recovery and so on—with less expertise needed for overarching DevOps workflows. This relieves much of the pressure on DevOps teams by eliminating the need for custom software development, lowering maintenance costs and introducing automation.

Although each solution has its benefits, neither is a panacea for DevOps infrastructure management. Today’s cluster management software, containerization and container orchestration systems differ wildly in their capabilities and are often incompatible with older/legacy software. The task of integrating each with existing back-end systems and ensuring compatibility with existing environments is a perpetual challenge in hybrid deployments, where everything must work together for seamless DevOps. In our experience, each presents unique issues that prevent them from becoming standard on any client project.

Ruzicka: Without a standard “one-size-fits-all” offering, how do organizations address their DevOps infrastructure management challenges?

Chunikhin: There are several key capabilities that organizations should be looking at:
- Portability and vendor-independence.
- Extensibility and openness, i.e. compatible with widely used modern DevOps standards.
- Easily deployable business components (such as data storage systems, deployment and release cycle automation tools, application server clusters, etc.)
- Ease-of-use and immediate readiness for production deployments.
That’s a lot to check off, but key to this approach is a combination of best practices and the use of open-source DevOps containerization and cloud technologies such as PaaS. PaaS is critical here since it uniquely provides the extensible and ready-to-use pluggable infrastructure services needed to easily configure new services, introduce development efficiencies and take care of the operational concerns that can impinge any DevOps strategy.

DevOps automation and container orchestration technologies also augment cloud strategy and multiply its benefits by an order of magnitude.

About the Author / Wolf Ruzicka

Wolf Ruzicka is chairman of EastBanc Technologies, joining the company in 2007 as CEO. During his tenure, he has overseen the organic growth of the company, taking it from 35 employees to more than 150, with staff turnover of virtually zero. He serves on numerous boards and groups, including the Microsoft Customer Advisory Board for Microsoft Azure and the World Economic Forum’s “Partnering for Cyber Resilience” initiative. Prior to joining EastBanc, Wolf served as president of APIphany (now part of Microsoft) and held leadership positions with MicroStrategy, Mercedes Benz, Lufthansa and more. Wolf holds an Master of Business Administration from Ingolstadt School of Management.
November 18, 2016
Are We Leaving Developers Out of DevOps Spinoffs?

SecOps. DataOps. NetOps. Reading these terms, you get the sense that the key to IT efficiency is to make IT Ops work with everyone else. But that’s a mistake, because it leaves developers out of the picture.

It’s no secret that the DevOps movement has generated a number of other *Ops initiatives, including those listed above. The driving idea behind all of them is that IT Ops teams should work more closely with security teams (in the case of SecOps), data analytics teams (in the case of DataOps) or networking teams (in the case of NetOps). These are only a sampling of *Ops movements; the list could go on.

To be sure, there are advantages to gain by having IT Ops collaborate more closely with other parts of the organization. But there are an equal number of advantages in doing the same thing with developers.

To optimize security operations, you need developers, IT Ops and the security team to work together. If Dev is left out of the picture, it’s much harder for the other two parts of this equation to make sure that the code the organization deploys and manages is secure.

For similar reasons, DataOps, NetOps and almost all the other *Ops you can come up with work well only when Dev also participates. The people who actually design and write the applications are important.

Rethinking Ops

Why does this matter? My point is not merely that terms like SecOps and DataOps are misleading because they don’t mention developers.

On the contrary, giving equal weight to developers is important because if you don’t, you risk isolating developers. Some are already complaining that DevOps is “killing” them. The trend of defining new *Ops practices that don’t mention developers is not helping.

So, maybe we should start mentioning and thinking about developers more prominently when we are talking about ways to extend the DevOps philosophy to other parts of the IT organization. This is already being done somewhat in the case of SecOps, which you sometimes hear called SecDevOps. But Google lists nearly 13.5 times as many results for “SecOps” as for “SecDevOps.” The numbers are similar if you search for “NetOps” as compared to “NetDevOps.” And I’ve never heard anyone say “DataDevOps.”

The takeaway is this: Developers are as important as IT Ops to DevOps. Don’t leave them out.

— Chris Tozzi

November 15, 2016
Debating the Future of DevOps

Change happens at an astronomical pace in the DevOps world, and I constantly see organizations shifting in their needs as the weeks and months go by. One week, the most essential need will be a specific configuration management tool and the next, it will be an urgent requirement to work on containerization.

Many companies forget that simplicity often is the key and the focus should be on transferring to engineers the requirements of the business and product owners. It’s not always about implementing every new tool just because another awesome engineering team is using it—they might have different business needs and end goals than yours.

Whether you are consulting for another client or working on your own internal applications, is your focus on how exciting the new container management system is or how to build the best possible end product that the business requires? Your DevOps organization should be focused on understanding these needs as well as the needs of every team across the technology function and more. So how, then, do we find the line between leading, following or resisting trends to create the most competitive advantage for our organizations?

The DevOps movement will continue to break down silos and increase collaboration. I see DevOps and big data coming closer together; for example, our DataOps teams will have the usual deep understanding of infrastructure, the ability to automate processes, write scripts, build CI pipelines and continuously deploy new code. However, there also will be increasing demand to work with the likes of Splunk and Hadoop to process large sets of data as well as monitoring and logging.

The cultural idea of bringing our teams closer together, to understand each other and to increase productivity will drive such shifts in skill sets. Other technology touchpoints such as containerization and serverless architecture will continue to spread deeper into organizations, while security and privacy may creep further up our list of priorities as we continue adopting more technologies into our organizations. However, it may take some tough learning curves before we really understand the implications caused by not taking SecOps seriously.

Every organization has different needs based on the stakeholders, the tech stack, the infrastructure architecture and more. DevOps will continue to shift, take on other aliases and functions, but the truth is that the future of DevOps is simply the future of your organization.

Understanding what that future holds, however, is up for debate. That’s why we’re hosting an event designed to push DevOps thinking beyond current boundaries among practitioners of varying backgrounds. The Future of DevOps Debate, an invitation-only event, is happening Nov. 10. Salt, host of the event, plans to share footage of the event as well as posting further blogs and articles, providing everyone a glimpse into the day’s conversations and, well, debates.

The day includes a dedicated session discusses the pain points, experiences and successes leaders have had in their past and current positions. The day’s conversations will be in debate-style format so that everyone gets their opportunity to share thoughts and contribute. The core focus is to work toward the future of DevOps.

This is the first Future of DevOps Debate, and Salt plans to run a series of events on a quarterly basis. It also contributes to the local New York DevOps community, sponsoring events such as DockerNYC and hosting ServerlessNYC, to name a few.

It’s clear we are at an inflection point in DevOps, as new technologies and processes strive for attention. Together, we can help shape the future of DevOps and push the industry well beyond its current boundaries.

About the Author / Conor Delanbanque

Conor Delanbanque is managing consultant and head of DevOps USA at Salt. Previously, he was supporting and consulting clients across Europe with their DevOps transformation efforts. Connect with him on Twitter at @ConorDevOps.

November 10, 2016
Don’t Be Samsung: Here’s How You Can Protect Yourself

Imagine a factory building 100,000 units a day, and you can see how a small error can have huge consequences. Now imagine that factory is a database.

The world’s top smartphone maker this month pulled the plug on its $882 Galaxy Note 7 after phones overheated and caught fire, concluding in a disastrous recall for Samsung that could cost the company as much as $17 billion and shutter a global revenue stream. In an unprecedented move, Samsung has told mobile carriers to halt sales or exchanges of the device, requested that users to shut off their phones and issued a mass recall while the South Korean manufacturer investigates reports of fires in original and replacement Note 7s.

This a scant two months after the Galaxy Note 7’s launch, a device that one TechCrunch consumer electronics expert raved as “undoubtedly one of the most iconic handsets around.” While it is not clear what caused these fires, there is speculation that it was due to a faulty component that interacts with the battery, rather than the battery itself.

It goes without saying that there are ample opportunities for error in the assembly of a smartphone. The complicated, highly coordinated process is fraught with thousands of input touchpoints, from hard- and software components to tightly controlled manufacturing processes to manual labor. And though there may be countless checks and balances in place, mistakes do happen. What may seem to be an innocuous error, such as not sufficiently tightening a screw or the shorting of a circuit, in this case has led to epic consequences.

The truth is, these instances happen more often than we think, and to technologies even more vital to the population than a personal smartphone.

Consider today’s era of big data and cloud applications, where enterprise applications ingest and process vast amounts of information from various sources, often in real time, to deliver critical analytics, contextual information or business insights.

This data has weight. It can influence whether fleets of airplanes are grounded at gates all across the country. It can restrict customers from accessing funds from online banking. It can dictate whether millions of online retail dollars go unspent. The reliance on accurate data, and its grip on lives and business, is growing at an exponential rate—like ever-widening ripples in a lake.

To support all of this data, new applications (such as real-time analytics, internet of things, ecommerce and others) are developed and deployed on scale-out, non-relational databases or ported from traditional relational databases.

But, like the manufacturing gaffs experienced by Samsung, corruptions and operational errors by developers occur in enterprise IT environments. Enterprises know this, and billions have been invested in traditional backup and recovery and data protection products to protect against such “err” moments. However, the irony is that data protection products like those that exist for traditional relational databases do not exist for today’s modern, next-generation scale-out databases supplying the new types of data that increasingly control our lives. We’re essentially trusting that the Ma Bell rotary phone repairman will be able to recover personal data—such as contacts, photos and messages—after your Galaxy Note 7 starts smoldering.

So how did we get from the world’s most explosive phablet to distributed databases and big data? Because, like the Galaxy Note 7, the tiniest data error can rapidly expand into magnificent, catastrophic consequences.

Enterprises are adopting cloud applications that gather large amounts of data at a high-ingestion rate and process that data in real-time to deliver actionable insights. These applications are deployed on non-relational databases. As migration to cloud and multi-cloud application environments increases, enterprises also must be able to manage and recover at scale without data loss or corruption and with minimal application downtime.

However, enterprises today face a significant gap in addressing their data protection requirements. Their most valuable data, often needed 24/7 and without fail, runs absent any point-in-time backup options for that ‘“Houston, we have a problem”’ moment. Most studies suggest that more than half of data downtime and loss is triggered by human error, corruption or virus attacks. And yes, while native replication helps enterprises meet business continuity and disaster recovery requirements by providing protection from hardware failures or even natural disasters, it is insufficient (meaning it cannot scale) to meet next-gen enterprise data protection demands. Case in point: If a minor schema corruption impacts the primary data copy, it causes a multitudinous ripple effect that impacts all replicas down the line. Yet, even without protection, industries continue to adopt and deploy scale-out database systems at an accelerated pace.

So just as Samsung witnessed an error replicate itself into such a massive meltdown of global proportions that it threatens to kill an entire product line, organizations also must understand how replication-based protection mechanism can actually act like a virus—spreading a corruption uncontrollably across non-relational, cloud databases.

Samsung’s troubles won’t end with the simple recall of a single product, and their predicament should resonate. There will be punitive measures, and perhaps even a total enterprise shift from the smartphone market. It is not an enviable position, but is does offer a clear example of how a peripheral manufacturing error can swell to engulf an entire brand.

For enterprises rushing to deploy scale-out databases, let Samsung serve as a warning: that deploying any infrastructure that could potentially lead to exponential, irreversible corruption of all data copies is a recipe for harm (if not disaster). As enterprises make the switch to next-gen applications running on scale-out, non-relational databases, an assembly line e-stop needs to be built in, in the form of a point-in-time, version-friendly data protection solution.

Data corruption is not a matter of “if,” but “when.” So have a kill switch ready.

— Brian Yin

November 3, 2016