Welcome!

Linux Containers Authors: Zakia Bouachraoui, Elizabeth White, Yeshim Deniz, Liz McMillan, Pat Romanski

Related Topics: @DevOpsSummit, Linux Containers, Containers Expo Blog

@DevOpsSummit: Blog Feed Post

Continuous — Build, Break, and Fix Fast By @HoardingInfo | @DevOpsSummit #DevOps

What Continuous affords us is the ability to break our applications with confidence

Continuous - Build, Break, and Fix Fast
By Chris Riley

This is one of two PagerDuty posts on Continuous. Check out our first one: Are You Ready for Continuous Deployment?

Continuous Overload
If you pay any attention to modern software delivery conversations, it sometimes feels like you are being beaten over the head with a Continuous magic wand. Continuous Integration, Continuous Delivery, Continuous Deployment, Continuous Documentation, etc. The idea is so easy that it’s frustrating: Go fast. But the benefits of going fast are well beyond more builds to your user base. Perhaps the greatest value is long term, and hidden in how you can break the application continuously without fear because you can fix it continuously as well.

What does speed get you in the long term? Over a period of three months, can you say something more about your pipeline than “We had more builds”? More releases are one thing. But a delivery chain that does not support innovation is nothing more than a way to get from point A to point B. To demonstrate real success in a DevOps-driven organization, you need to be able to show that your software quality and functionality increases as well — which means all that cool functionality sitting buried in your backlog finally percolates to the top.

Why Continuous?
What Continuous affords us is the ability to break our applications with confidence — because we know we can rapidly alert on any issues, and iterate to a new build to address them. Teams can now implement a feature that they have been dying to implement but have avoided due to perceived risk.

What break/fail fast really means is that you can be opportunistic about your functionality, which quite possibly is the only way to build functionality that responds to user demands in near-real-time, or to learn how new functionality impacts the application and adoption. Without fail fast, applications may be doomed to purely linear releases, no matter how short your sprints are. And they can fall into the same trap we are all too familiar with — stagnation, also known as the eventual slowing of new functionality in favor of very small changes to existing functionality. When this happens your application gets stale, and can only be addressed with major rewrites, refactoring, or whole new applications. This is not Continuous at all, or at least not sustained Continuous.

Canary Releases
The extreme of fail fast and fix fast is something called canary releases. In a canary release you have one or more new releases of the application in parallel to the existing production version. Once the release(es) are complete, you divert all or sub-segments of traffic from production to the new release environments. The purpose of sub-segments is to do A/B testing on slight variations of the releases.

If anything goes wrong with a canary release, you will know quickly with a robust alerting mechanism. Then, you’ll revert traffic back to production. The exercise might have a small negative impact on your users, but the response is so rapid that it seems like a glitch. New functionality could be developed within day-length time frames.

Because you’ve learned more about the new functionality, you can either drop it, or fix it within that canary release, and rapidly test again. This truly is an iterative model. And it can be set up as not just one iteration, but rather multiple iterations going on in parallel.

This model would also be considered the extreme of continuous deployment, though without some of the automated functional and system testing before releases. These processes can be too long to support the concept. It does assume a few things. The biggest is that your application has a high enough user base and volume to support quick tests of new functionality.

I have not figured out how this can work with a highly distributed microservices application, but I am sure it is possible, if you have:

The Tools to Get It Done
Of course, such an advanced way of looking at both releases and application architectures requires great tooling to execute it. And the top three tools for fail fast are as follows:

  1. Release Automation: Your release automation tool needs to be able to handle several releases at once. They all do, but that is not what I mean. Support of multiple parallel releases requires very good state management, and dashboards to visualize releases. Without this visibility, it’s very difficult to know what releases are where, and when they are reverted, which can result in serious problems. And the additional overhead might not make the process worth it.
  2. On-Demand Cloud Environments: The infrastructure to support this is not about power, but flexibility. Platform as a Service (PaaS) is the most suitable form of infrastructure to support Canary releases, because with PaaS, you are provisioning against a pool of resources, not actual VMs. This makes provisioning faster, but also easier to manage because you do not have to worry about orchestration, etc. Most PaaS environments also support easier traffic swapping. With Infrastructure as Service (IaaS), you will need to control this via your DNS or load balancer, which likely is one additional step. However, there is no reason IaaS should be excluded from break fast processes, especially if you leverage container technology like Docker, which makes it nearly as simple as PaaS. IaaS or PaaS the developers need to be able to spin up and tear down as many environments as they desire, and do so on demand. If the attainment of environments is gated, there is no way to achieve parallelism, or to respond to issues with a new, updated release. The processes i’m pitching require full-stack deployments, so deploying on existing environments is also not an option. With such a rapid release and revert process, it’s very easy to accumulate variables that would contaminate persistent environments.
  3. Alerting: Logging your environments is one thing. It is important to implement logging, but mostly for historical data. However, in canary releases, historical is too late. The responses to what happens to each build need to be quick, and the lifespan of an iteration is very short. So you need a very strong alerting platform that can push alerts to you as they happen. However, the alerting platform must be smart as well. Because of the frequency and number of releases in parallel, too much information can easily become a problem; thus, response to any issue requires a lengthy filtering process.

It Is Not All Technology
The concepts around releasing faster, breaking faster, and fixing faster are not complex. But implementing them in existing environments can be. And this is where any experienced developer, operations and QA person knows that you cannot simply turn on the canary release switch.

Implementation is a journey, but the above process is a goal. And what is nice about the already popular process of continuous integration is that the experimental fail and revert process can be implemented in integration environments. There the impact is only on your internal team. In this case, the impact will mostly affect QA, as they will be responsible for testing releases as soon as they are built, so the biggest organizational change exists there. (Still far less than implementing team-wide and in production.)

The bottom line is the tools are available to build faster, fail faster, and fix faster — a process that will not only increase the number of builds you do a year, but also the innovation that can take place to produce newer functionality and quality. Because the tools already exist, the burden is on the team to find a path from their existing release processes to new processes.

This is one of two PagerDuty posts on Continuous. Check out our first one: Are You Ready for Continuous Deployment?

The post Continuous — Build, Break, and Fix Fast appeared first on PagerDuty.

Read the original blog entry...

More Stories By PagerDuty Blog

PagerDuty’s operations performance platform helps companies increase reliability. By connecting people, systems and data in a single view, PagerDuty delivers visibility and actionable intelligence across global operations for effective incident resolution management. PagerDuty has over 100 platform partners, and is trusted by Fortune 500 companies and startups alike, including Microsoft, National Instruments, Electronic Arts, Adobe, Rackspace, Etsy, Square and Github.

IoT & Smart Cities Stories
In his general session at 19th Cloud Expo, Manish Dixit, VP of Product and Engineering at Dice, discussed how Dice leverages data insights and tools to help both tech professionals and recruiters better understand how skills relate to each other and which skills are in high demand using interactive visualizations and salary indicator tools to maximize earning potential. Manish Dixit is VP of Product and Engineering at Dice. As the leader of the Product, Engineering and Data Sciences team at D...
When talking IoT we often focus on the devices, the sensors, the hardware itself. The new smart appliances, the new smart or self-driving cars (which are amalgamations of many ‘things'). When we are looking at the world of IoT, we should take a step back, look at the big picture. What value are these devices providing. IoT is not about the devices, its about the data consumed and generated. The devices are tools, mechanisms, conduits. This paper discusses the considerations when dealing with the...
Bill Schmarzo, Tech Chair of "Big Data | Analytics" of upcoming CloudEXPO | DXWorldEXPO New York (November 12-13, 2018, New York City) today announced the outline and schedule of the track. "The track has been designed in experience/degree order," said Schmarzo. "So, that folks who attend the entire track can leave the conference with some of the skills necessary to get their work done when they get back to their offices. It actually ties back to some work that I'm doing at the University of San...
Bill Schmarzo, author of "Big Data: Understanding How Data Powers Big Business" and "Big Data MBA: Driving Business Strategies with Data Science," is responsible for setting the strategy and defining the Big Data service offerings and capabilities for EMC Global Services Big Data Practice. As the CTO for the Big Data Practice, he is responsible for working with organizations to help them identify where and how to start their big data journeys. He's written several white papers, is an avid blogge...
Dynatrace is an application performance management software company with products for the information technology departments and digital business owners of medium and large businesses. Building the Future of Monitoring with Artificial Intelligence. Today we can collect lots and lots of performance data. We build beautiful dashboards and even have fancy query languages to access and transform the data. Still performance data is a secret language only a couple of people understand. The more busine...
If a machine can invent, does this mean the end of the patent system as we know it? The patent system, both in the US and Europe, allows companies to protect their inventions and helps foster innovation. However, Artificial Intelligence (AI) could be set to disrupt the patent system as we know it. This talk will examine how AI may change the patent landscape in the years to come. Furthermore, ways in which companies can best protect their AI related inventions will be examined from both a US and...
Enterprises have taken advantage of IoT to achieve important revenue and cost advantages. What is less apparent is how incumbent enterprises operating at scale have, following success with IoT, built analytic, operations management and software development capabilities - ranging from autonomous vehicles to manageable robotics installations. They have embraced these capabilities as if they were Silicon Valley startups.
Chris Matthieu is the President & CEO of Computes, inc. He brings 30 years of experience in development and launches of disruptive technologies to create new market opportunities as well as enhance enterprise product portfolios with emerging technologies. His most recent venture was Octoblu, a cross-protocol Internet of Things (IoT) mesh network platform, acquired by Citrix. Prior to co-founding Octoblu, Chris was founder of Nodester, an open-source Node.JS PaaS which was acquired by AppFog and ...
The deluge of IoT sensor data collected from connected devices and the powerful AI required to make that data actionable are giving rise to a hybrid ecosystem in which cloud, on-prem and edge processes become interweaved. Attendees will learn how emerging composable infrastructure solutions deliver the adaptive architecture needed to manage this new data reality. Machine learning algorithms can better anticipate data storms and automate resources to support surges, including fully scalable GPU-c...
Cloud-enabled transformation has evolved from cost saving measure to business innovation strategy -- one that combines the cloud with cognitive capabilities to drive market disruption. Learn how you can achieve the insight and agility you need to gain a competitive advantage. Industry-acclaimed CTO and cloud expert, Shankar Kalyana presents. Only the most exceptional IBMers are appointed with the rare distinction of IBM Fellow, the highest technical honor in the company. Shankar has also receive...