Hybrid

2017 trend lines: When DevOps and hybrid collide

Share this post:

Devops and hybridAuthor’s preface: The term Site Reliability Engineering (SRE) is a job function that brings DevOps into infrastructure in a powerful way. Talking about hybrid infrastructure and DevOps without mentioning SRE would be a major omission. For further reading about SRE thinking, explore this series of blog posts.

What happens when DevOps methods meet hybrid environments? Following are some emerging trends and my commentary on each.

There are two major casualties as the pace of innovation in IT continues to accelerate: manual processes (non-DevOps) and tightly-coupled software stacks (non-hybrid).

We are changing some things much too quickly for developers and operators to keep up using processes that require human intervention in routine activities like integrated testing or deployment. Furthermore, monolithic platforms—our traditional “duck-and-cover” protection from pace of change—are less attractive for numerous reasons, including slower pace, vendor lock-in and lack of choice.

The necessary complexity of hybrid development can make it harder to build robust, portable DevOps automation.

Necessary complexity? Yes, that’s 2017 in a nutshell. Traditionally, people consider hybrid to mean operating in split infrastructures such as on-premises and cloud simultaneously. But the challenges of splitting operations is about much more than two or more infrastructures. The reality of hybrid is that there are variations throughout the IT stack that force users to code with hybrid issues, even without straddling clouds.

The pace of innovation guarantees that we will be constantly in a hybrid operations mode.

Robust, portable DevOps automation? We not only need it, automation will absolutely will be required. DevOps is generally presented as cultural and process transformations. But the consequence of that transformation is the need to automate processes to improve system performance.

Modern software development is built using massive collections of reusable modules and services—many open source—that developers carefully assemble into working applications. Since each component has its own release cycle and dependency graph, we must continuously integrate (CI) our applications to make sure that they continue to operate correctly.

It’s foolish to manage your application stack as a manual integration problem. You must automate it.

A critical defense against integration challenges is to constantly patch and update your software. The faster and smaller you can deploy software creates more protection from inevitable changes that cause issues created by both external and internal sources. The practice of continuous deployment (CD) ensures that your development and operations teams can respond quickly—or better yet, automatically—to the inevitable issues in creating software. This means that your applications are more resilient and your teams collaborating on development to production pipelines.

DevOps drive for CI and CD creates robust applications.

Hybrid creates a unique set of challenges for DevOps practices between the exploding complexity of choice. Change makes automation a moving target. I’ve been watching teams’ CI/CD pipelines grow from simple linear flows into Rube Goldberg machines that test multiple operating systems on multiple infrastructures.

These are not gratuitous tests. Teams have a very real need to manage their applications across a rapidly changing IT landscape. This creates a dilemma as they have to invest more and more time chasing issues created by hybrid requirements. But those requirements are not going away because they have commercial ROI and technical rationale.

Variation created by hybrid creates challenges for automation.

We must find a way to contain the work demanded by hybrid, but we cannot simply ignore the hybrid imperative. The clear answer for 2017 is to find good abstractions that protect teams from differences introduced by hybrid. The most popular abstraction, containers, is already revolutionizing workload portability by hiding many infrastructure details and providing the small delivery units desired by CI/CD pipelines.

We must invest in abstractions to help with hybrid DevOps because complexity is increasing.

We’ve clearly learned that DevOps automation pays back returns in agility and performance. Originally, small-batch, lean thinking was counter-intuitive. Now it’s time to make similar investments in hybrid automation so that we can leverage the most innovation available in IT today.

If you like these ideas, please subscribe to my blog RobHirschfeld.com where I explore SRE Ops, DevOps and open hybrid infrastructure challenges.

Add Comment
No Comments

Leave a Reply

Your email address will not be published.Required fields are marked *

More Hybrid Stories

Top 10 Thoughts on Cloud posts for 2015

[View the story “Top 10 Thoughts on Cloud posts of 2015” on Storify]

Continue reading

Cloud innovation in the US federal sector

As federal agencies take their first steps toward cloud implementation, they are beginning to establish their own cloud strategies. These include laying out a framework that will identify different workload profiles and deploy each workload in the most suitable cloud environment. During this planning and design phase, they often realize a need to adopt a […]

Continue reading

Direct Link connection options for hybrid clouds

Companies are striving to implement more cost-effective IT environments using hybrid clouds that include both on-premises and off-premises resources. Direct Link on IBM SoftLayer, introduced in my previous blog post, helps IBM Cloud clients integrate their private, public and hybrid clouds with high performance, security-rich connections. Here’s how Direct Link connects your IT resources. Physical […]

Continue reading