By most definitions, DevOps involves making developers and IT Ops teams work better together. But integrating other parts of an organization, such as legal and public relations, into DevOps is also important. Here’s why.
DevOps has become popular because it helps to speed the delivery of software. The goal is to reach continuous delivery, which means code is changed, tested, staged and delivered to users on a (nearly) continuous basis.
If you think only from a technical perspective, then getting to continuous delivery of software involves only technical people. Developers, IT Ops admins and software testers are all you need.
DevOps in the Big Picture
Yet, to deliver software continuously on a reliable basis, you need to think beyond just technical processes and personnel. Effective DevOps workflows have to involve all of the other parts of the organization that play a role in creating software, delivering it to users and maintaining it once it is in production.
For example, PR teams need to be plugged into the software delivery chain so they know when new features are coming down the pipeline and can prepare to promote them. Legal professionals should play a role as well, since they’ll know when code changes require tweaks to licensing, compliance procedures and so on.
The list can go on. In most organizations, human resources has a role to play in DevOps, since personnel changes can affect the continuous delivery chain. Supply chain managers should be involved, too, since they have a hand in provisioning the infrastructure on which DevOps teams rely.
To be sure, these various non-technical teams don’t need to be as plugged into the DevOps workflow as deeply developers and admins do. Code can be written and tested without their perpetual involvement. Still, at a minimum, all parts of the organization should at least be aware of the state of the delivery chain. Otherwise, visibility and communication break down.
Taking this big-picture approach to DevOps is important because ultimately, despite the relatively narrow purview implied by the term DevOps itself, the value of DevOps lies in adding efficiency and promoting better communication across the entire organization in ways that optimize software delivery.
So, if you want to make the most of DevOps, start thinking beyond just Dev and Ops.
One of the key advantages of cloud-native applications is the ability to quickly push updates into production for specific microservices—giving developers the ability to respond rapidly to changing business requirements without having to upgrade the entire application. Successfully doing this requires far more than just leveraging a continuous delivery platform. Everything from the culture of the development group to the type of testing required to the underlying platform it will run on is critical.
Based on applying DevOps principles across several projects to date, I have found that development teams can benefit from following these seven key strategies before launching continuous delivery and deployment initiatives. By doing so, you’ll increase your opportunity for success.
Culture
Just having the right tools and technology isn’t enough in today’s enterprises. Successfully adopting an agile, continuous delivery and deployment process will require a culture shift within most development shops. Developers are no longer responsible only for their code; they must take full ownership of the development, testing, automation tools and, most importantly, building operational capabilities into the pipeline so the move to production is easier. Getting developers and the operations team on board with this may take some time and training, but the effort is critical, and your projects won’t succeed without this.
Automation Platform
Carefully consider the tool you’ll use for your continuous delivery pipeline because the current tools on the market have different optimal use cases. For example, if you need to do A/B testing you’ll want a tool that has capabilities for phasing the rollout based on the test results. If your application requires multiple updates in a short time span, you’ll need a tool that has advanced release management capabilities including good pipeline visualization and support for the management of cloud environments.
App Architecture
Design your applications so they are cloud-native. This is typically associated with microservices and containers and will enable you to independently and frequently update each service independently. The typical stages of a deployment pipeline are build, unit testing, integration testing (including functional testing), API testing, performance and staging, then, finally, on to production. However, with microservice architectures and advanced deployment techniques, more and more customers are bypassing certain stages and testing in production, albeit very contained production environments.
Each stage also can include the creation of dynamic environments in the cloud, enabling the stage itself to be provisioned, executed and decommissioned as a part of the pipeline. If you choose to do this, look for a tool that has a number of built-in cloud plugins, so creating and destroying environments in AWS, Google Cloud and other clouds can be done easily.
The application and infrastructure stack for each microservice also should be specified. This could include the application Jar file, a Docker file, or server image such as an AMI; any related services such as AWS Lambda functions; and all configurations and policies. These specifications all should be managed in an infrastructure-as-code manifest, which ensures versioning, consistency, change auditing and testing. It also ensures that the build resources, such as baked images, JARs and AWS Lambda functions, are consistently passed to each stage of the pipeline, from testing to production, eliminating the risk of imposing inconsistent environments and configurations. An AWS CloudFormation template is an example of an infrastructure-as-code manifest.
Security
Security is a necessity in the world of increasing threats that we live in; however, the common approach of waiting to test security right before the push to production is the wrong approach. Security should be built in to the pipeline itself and automated as part of the DevOps CI/CD process. It’s essential to validate the building blocks without slowing down the process. For example, leading companies are automating code scanning, template checking and other security tests in within the phases of the pipeline itself.
Insight
Visualizing and tracking pipelines, environment variables, test results, versions, issues and other artifacts allows developers and the operations team to share a common view throughout the project life cycle. This improves collaboration and traceability.
Delivery Strategies
Automating tests is critical to pipeline design and delivery. Without comprehensive, high-quality, fully automated tests of the deployment pipeline, production failures will occur. Code coverage no longer is a good representation of code quality. In the cloud-native world, test cases and test suites need to be mapped to functionality and business outcomes desired to ensure that the test team gives the green light and then everything goes red in production. In situations where time limitations prevent a comprehensive approach, first automate the critical capabilities and flows, then assess the cost-benefit of automating additional tests.
Be sure that the data and environment for testing and automating purposes mirrors the production data and environment as closely as possible. Most pipelines have a “pre-production” stage before pushing software into production. You may consider building multiple stages across multiple AWS regions before pushing the software to production.
If your goal is to update software in production very frequently and without any downtime, make sure your pipeline tool can easily manage multi-region deployments, such as blue/green and canary deployments for server groups and clusters across AWS and other public infrastructure-as-a-service (IaaS) clouds.
Monitoring and Feedback
Finally, it is essential to get continuous feedback on the user experience, response times, performance of key business services, and the technical metrics from all stages of the life cycle—development, QA and production. Only through this continuous feedback can you ensure that no degradation occurs as you push out releases with increasing frequency. This too needs to be built into each phase of the pipeline to understand performance and improve things earlier in the process, where it costs much less.
There’s no doubt that a successful continuous development and deployment process can deliver significant benefits to users, who constantly require new and enhanced capabilities and can’t wait the weeks or months that a traditional development cycle requires By carefully considering these seven strategies, your projects will benefit from reduced application errors, less downtime and much happier users.
About the Author / David Cramer
David Cramer is vice president of Product Management for the Cloud/DCA business unit at BMC. Prior to BMC, David was head of product management for CA Technologies. During his tenure at CA, David was responsible for application delivery, cloud management, virtualization and Infrastructure automation solutions. Before joining CA, David held executive positions at AlterPoint, Motive, NetSolve and Nortel Networks. David’s focus is on continuous delivery, cloud management and web-scale IT. David received his MBA from Southern Methodist University and a BS in Finance from Georgia State University. Connect with him on LinkedIn and Twitter.
Over the past year, I have traveled to and delivered presentations at 18 DevOps events. I’ve also heard that over the past several years, John Willis has participated in more than 200 DevOps events. But not all of us have the time or budget to get ourselves and our teams out to these events where we can learn from other practitioners.
All Day DevOps will deliver 57 practitioner-led sessions over 15 hours and 15 time zones. No vendor pitches are allowed. To break the travel and budget barrier for you and your teams, we are delivering every session live, online and free of charge. Every session will also be recorded. We are doing this because we want to share global DevOps expertise with everyone.
DevOps Brains
More than 3,500 people have now registered for the conference. We have an awesome speaker lineup covering three tracks: Modern Infrastructure, CI/CD and Automated Security. Here is a sample of some of the great sessions being delivered:
CI/CD
Meta Infrastructure as Code: How Capital One Automates our Automation Tools with an Immutable Jenkins, by George Parris (Master Software Engineer at Capital One)
Speaking for the Dead: Critical Positive Lessons from Waterfall and Monolithic Architectures, by Michael DeHann (Former CTO & Founder of Ansible)
I, For One, Welcome Our New Robot Overlords, by Mykel Alvis (DevOps Computational Demonologist at Cotiviti)
AUTOMATED SECURITY
Stop Changing Your Password, by Chris Swan (CTO Global Infrastructure at CSC)
System Hardening using Ansible: Application Deployment + Configuration Management + Continuous Delivery, by Akash Mahajan (Lead at OWASP Bangalore)
Building Codes for Building Code, by Josh Corman (Director of Cyber Statecraft at Atlantic Council)
MODERN INFRASTRUCTURE
Terraforming Your Infrastructure: From Beginner to Semi-Pro in 30 Minutes, Britt Treece (Production Engineer at PhishMe)
DevOps Friendly Doc Publishing for APIs & Microservices, by Mandy Whaley (Director of Developer Experience at Cisco)
Monitoring, Hold the Infrastructure – Getting the Most out of Lambda, Michael (DevOps Evangelist at DataDog)
Don’t Just Listen, Talk DevOps
One of the big pieces of input we have received from the community is that everyone wants an opportunity to interact. This is why we are building a dedicated team room in Slack for you. Every attendee will have the chance to interact with the speakers in the Slack room. Q&A will be live, online and freely accessible. We will also have Birds-of-a-Feather channels set up for those with questions to be helped by those with answers.
If you would like to join us, can you register for free. A big thanks goes out to Alan and his team at devopsy.kinsta.cloud for helping us spread word of the event here. We are really excited to have teams from North America, Europe, Asia, and Australia joining us for the event!
If you read DevOps blogs today, it can be easy to assume that Continuous Integration (CI) and Continuous Delivery (CD) are synonymous terms. People often use them that way. But that’s a mistake.
As an example of conflation of the terms CI and CD, take this page, which purports to be a “history of CI/CD tools.” The author does provide a truly excellent history of CI platforms.
But CI tools are the only subject that the page discusses. It’s not a history of CI and CD. It’s just a history of CI platforms. To work the history of CD into the picture would require discussion of how software testing and delivery practices have changed over time, not just an overview of the history of CI software over the past several years.
I don’t mean to knock the page. It’s a great read, and the mistake the author makes in treating CI and CD as synonymous is hardly rare. He or she is just repeating a common confusion. You see the same lack of distinction between CI and CD on Docker’s discussion of CI/CD, for instance.
The Difference between CI and CD
It’s unclear how this conflation of the two terms originated. But it’s easy enough to clear up.
Simply put, CI is the process of integrating code into a mainline code base. In almost all scenarios today, CI is done using platforms designed specifically for the purpose. Implementing CI is, therefore, as simple as using the right tools.
CD is more complicated. CD is about the processes that have to happen after code is integrated for app changes to be delivered to users. Those processes involving testing, staging and deploying code. There is no single type of tool that does all these things. These processes take different forms, depending on the culture of the team and the type of app it is creating.
In actuality, then, CI and CD share little in common. Besides starting with the same word (“continuous”) and being different stages in modern software delivery pipelines, they don’t have much to do with one another.
Why the Difference Matters
Why is it important to steer clear of this confusion? The main reason is because, by conflating CI with CD, organizations can end up doing only the former but thinking they have implemented the latter.
Setting up a CI server such as Jenkins or Bamboo to integrate code changes continuously does not mean you are doing CD. It just means you are using a CI server.
To get to CD, you also have to organize your software testing, staging and deployment processes in a way that automates them as much as possible and makes them continuous. Doing so requires more than simply turning on a certain type of tool.
How you actually do CD is fodder for a separate, much longer article (or you could just read the book about it). But recognizing that CI is not CD, and avoiding confusing formulations including CI/CD, is a start.
Almost every product we buy or use today goes through some form of extensive testing before it’s released on the market; typically, these tests are designed to replicate the worst-case scenarios that a product may encounter under real-world conditions.
Automobiles, for example, go through extensive hot and cold weather testing in remote locations, and are driven over obstacle-laden tracks designed to push the limits of their durability. Even seemingly mundane objects such as children’s toys are exposed to abusive simulations to ensure that they don’t harbor any potentially hidden and harmful effects.
On the current landscape, applications are the face of your business, often serving as the battleground where consumer loyalty is won or lost. Given this reality, it seems crazy to think that any applications are released having only been exposed to a minimum of tests. Yet, in the name of getting to market quickly, that’s far too often the case.
As disciplines including agile and continuous delivery continue to increase the speed at which development teams can release software, it’s easy to put the crunch on testing in the rush to get an update released. But that’s a costly mistake in the long run, as research has shown that it is 50 percent less expensive to find an error in testing than to address the same error once it has reached production, and more than 90 percent cheaper when addressed in the development/coding phase.
Given the dramatic cost savings of addressing errors in development, clearly the goal of any organization focused on continuous delivery should be to shift testing left so a greater number of defects are found early in the development process. This is what we refer to as continuous testing, and it’s a huge part of the reason why I am so excited about CA’s acquisition of BlazeMeter.
Performance load testing should be a core element of any continuous testing strategy because it is a critical factor in determining system reliability. Similar to the worst-case scenario testing that consumer products undergo, performance testing can quickly uncover applications defects that might otherwise go unnoticed. After all, the manner in which a system operates with a few hundred concurrent users may be very different than how it runs with thousands of users.
BlazeMeter enables today’s development, operations and DevOps teams to conduct this critical performance testing earlier in the development process, saving countless hours and resources. The company is also competing—and winning—in a highly competitive marketplace where it has been pitted against much larger, more entrenched competitors.
Part of the reason BlazeMeter is winning is its focus on offering a SaaS-based solution that is highly cost-effective and easy to engage. Using this model, customers can try out the testing software with a few clicks, and then quickly move forward to broadly adopt the system. Another catalyst to its success: BlazeMeter was built using open source tools, such as Apache JMeter, used widely in the development community for performance and load testing. As a result, BlazeMeter can easily run and analyze JMeter and other open source-based load tests—such as Selenium, Gatling and Locust—within a commercial-grade performance testing system.
This combination of a SaaS delivery model and incorporation of open-source tools, augmenting strong performance testing functionality, make BlazeMeter very complementary to CA’s existing continuous delivery solutions, including its CA Service Virtualization, CA Test Data Manager, CA Agile Requirements Designer and CA Release Automation products.
At CA, we’re committed to providing the most comprehensive, integrated and open continuous delivery ecosystem, allowing our customers to release swiftly, test agilely and constantly increase reliably. The addition of BlazeMeter will further enable customers test continuously, thereby increasing agility and the overall quality of their software, to ensure that applications don’t break down on the side of the virtual road.
Many business leaders are planning to make DevOps the cornerstone of their IT transformation strategy. But, as surprising as it might sound, skepticism abounds regarding how major vendors address the DevOps transformation challenges—they confuse DevOps with continuous delivery (CD) infrastructure.
“We wanted DevOps and we got after a nine-month-long implementation a continuous delivery platform which speeds up IT operations without significant business value. How differently can you help?” the senior business executive of a major financial institution in New York sarcastically asked me during a conversation three months ago.
The business executive is right: DevOps isn’t a technology as I’ve been implementing it, it’s primarily an accelerated application delivery approach implemented in the form of a technology-enabled application delivery operational model. Adam Jacob, CTO of Chef, substantiates that fact in “The Secret of DevOps: It’s Always Been About People, not Technology,” when he says, “DevOps is about bringing together all the people you need to build and run your business effectively, and empowering them to move as quickly as possible towards their goals.”
Agile Admin’s Ernest Mueller in, “DevOps: It’s not Chef and Puppet,” confirms Adam’s point: “Chef and Puppet are individual tools that you can use to implement specific parts of an overall DevOps strategy if you want to use them—but that’s it. They are fine tools, but do not solve DevOps for you.”
How can we implement DevOps in line with business leader expectations? Three Amazon Web Services (AWS) Design Patterns I developed can help to get the best of DevOps on AWS cloud: Software Organization Factory, Digital Organization Factory and CD Infrastructure Factory. This article discusses the Software Organization Factory.
The Foundation of DevOps Value: Consequences to IT Service Delivery
Before delving into these AWS design patterns, a quick reminder of what DevOps is, its value propositions and, more importantly, what changes are needed in how IT services are delivered.
The Ignored DevOps Business Logic We All Must Consider
The combined effect of cloud adoption and the rising digital economy is changing competitive environments; it forces business leaders to focus on innovation and market responsiveness as the competitive differentiators.
The fact of the matter is, by facilitating access to technology, cloud accelerates entrance of several thousands of tech startups that take advantage of the recent technology innovations to substitute traditional products and services into digital. This creates a context where new entrants increasingly compete with established brands, forcing business leaders to seek value paradigms other than IT efficiency.
The business executive argues, “In these new markets, our concern is to increase customer value by delivering the right services to the right segments at the right moment. You guys need to change the IT paradigm; IT alone does not create that kind of value.”
Then, what should be changed in today’s IT approach?
The Two Dimensions of Modern IT: The Operational Model and the Continuous Delivery Infrastructure
The new IT paradigm advocated in my recent book, “Rethink Your IT with DevOps: The Complete Guide to Aligning Your IT to DevOps,” is the idea that business value results from two dimensions: organizational agility and technology efficiency. In other words, it defines modern IT as a two-dimension asset including the operational model and the continuous delivery infrastructure.
The timely delivery of innovation transcends IT issues; it not only cuts across your sales, marketing, post sales, application development and IT operations, but also demands concrete answers as to how to accelerate business prioritization, decision-making and problem solving. The operational model is where business and IT people, processes, practices and tools are combined to create agile and cross-functional environments. The following exhibit shows a typical DevOps operational model:
Typical DevOps Operational Model
Organizational flexibility for the sake of flexibility doesn’t make sense unless technology is leveraged to speed processes. This is where CD infrastructures come into play; throughout the delivery process, they build on IDEs to accelerate coding and testing, on versioning tools to convert software version into releases, on continuous integration (CI) tools to build releases and on delivery pipelines to ensure continuous delivery.
So, what is DevOps?
DevOps is a Technology-Enabled Application Delivery Model
DevOps is a combination of value, principles, processes and practices shared not only by developers and IT operations but also by the business. The goal is to help the organization deliver the right service to the right market segments at the right moment.
DevOps from the Business Perspective
As I’ve been implementing it, it’s a cross-functional application delivery model involving the business and IT and enabled by continuous delivery infrastructures.
By enabling and automating agile practices, the continuous delivery infrastructure makes the operational model agile and provides the business with the flexibility and velocity needed to meet competitive challenges.
Design Patterns as DevOps Implementation Engineering Framework
As suggested by the business executive, today’s DevOps implementations struggle to deliver the promised business benefits. The reason is, the operational model dimension is ignored in favor of tools and infrastructure.
Another reason is, DevOps is young and is still at the early stage of the technology maturity model; the expertise and engineering methodologies to implement it as what it is—a technology-enabled application delivery model—are lacking. That’s where DevOps transformation design patterns help.
What are DevOps Transformation Design Patterns?
In this article, the term DevOps transformation design patterns refers to general reusable architectures addressing specific DevOps strategy. They’re not necessarily implementable solutions, their primary goal is twofold:
Offer a neutral language for designing and implementing technology-enabled operational models
Offer an engineering approach that reduces design and implementation duration and effort
They’re formalized architecture design and implementation best practices for DevOps and platform-as-a-service (PaaS) services.
Design Pattern as DevOps Implementation Engineering Methodology
To meet its goals—technology-enabled application delivery model—the design pattern is structured around four items including purpose, principles, general solution and implementation techniques.
Purpose: Clarifies the purpose of the design pattern along with the DevOps strategy to address.
Principles: Are best practices formulated as rules and beliefs supposed to guarantee expected DevOps strategy benefits? They’re the determinants of the solutions to implement the DevOps strategy.
General solution: Are blueprints resulting from the application of principles? They summarize the functional and technical architecture of the DevOps platform to implement.
Implementation techniques: What are recommended technical approaches, solutions and tools to implement the general solutions?
Why AWS? Why would it be the catalyst for DevOps value?
AWS-ome Design Patterns That Will Change DevOps Implementation
AWS offers such a rich, varied and easy-to-implement services portfolio that it would be unfortunate not to take advantage of it to modernize IT. The rationale underpinning the value businesses can derive from their DevOps transformation experience with AWS is summarized in the following figure:
Rationale of the DevOps Design Pattern
It’s the belief that:
Certain principles determine the AWS services needed to deliver the application delivery model (ADM) architecture that guarantees value.
The implementation of the ADM using these AWS services results in AWS-based DevOps platforms that tangibly deliver expected benefits.
The Four DevOps Principles that Yield AWS Value
Let’s explore the principles I’ve been using to make CIOs happy with their AWS cloud:
Think holistic, not only IT: Reminds that transformation isn’t only about IT but the entire organization’s value stream from marketing and sales to development and IT operations.
Think cross-functional, not only IT: Reminds that the bottom line is to set up a cross-functional application development environments to accelerate business prioritization, problem-solving and decision-making, and meet time-to-value objectives. They’ll be the core value propositions of the DevOps platform.
Make it agile, flexible, and speedy: Reminds that agility, flexibility and speed are the catalysts for competitiveness and business value. They’ll be part of the DevOps platform.
Think PaaS: Reminds that AWS provides varied services for implementing state-of-the-art CD infrastructure.
Let’s illustrate three AWSome design patterns that’ll change DevOps experience with AWS!
Implement a Startup Mindset with the Software Organization Factory
The purpose is to implement DevOps strategies focused on time-to-market and time-to-value. It’s adapted for tech startups.
To implement the startup mindset, the DevOps four principles for AWS are implemented as follows:
Think holistic and cross-functional, not only IT: Relevant business and IT resources are put together in a single and dedicated service development team supported by appropriate Scrum and XP agile practices.
Make it agile, flexible and speedy: PaaS services building on agile practices and AWS infrastructure-as-code are provided to make application delivery processes agile, flexible and speedy.
Think PaaS: AWS infrastructure as code and DevOps tools are combined to implement a CD infrastructure in the form of a PaaS platform.
The DevOps platform resulting from the principles application is illustrated below:
Software Organization Factory
The “Startup Mindset” platform is structured around three components including the cloud-enabled operational model, PaaS and the CD infrastructure.
The operational model builds on a three-stage application delivery life cycle:
Plan & measure: It mobilizes business users, development, QA and operations staff on business prioritization issues using agile practices such as Scrum product backlog planning or XP’s user stories.
Develop & Test: It mobilizes business users, development, QA and operations staff across the development life cycle using agile techniques such as Scrum iterations, XP’s test-driven development (TDD) and behavior-driven development (BDD).
Release & Deploy: It leverages continuous integration practices to build and test releases prior to deploying to production.
Monitor & Improve: It’s outsourced to keep the service development team on its core business: developing software.
The CD infrastructure combines the followings services:
AWS CodePipeline and CodeDeploy to set up the delivery pipeline.
AWS infrastructure as code including CloudFormation, OpsWorks and Elastic Beanstalk to generate the CD infrastructure.
Summing It Up
The DevOps business benefits are real, yet, it’s young and is still at the early stage of the technology maturity model. The expertise and engineering methodologies needed to implement it as what it is—a technology-enabled application delivery environment—are lacking.
DevOps design patterns such as the software organization factory fill the gaps of today’s transformation practices:
They provide the architect team and the executive team a neutral language to discuss the business, technological and technical challenges and solutions.
By pointing out the agile practices to leverage, they simplify and accelerate the design and deployment of the operational model.
By pointing out the AWS services and features to leverage they facilitate the design and implementation of the CD infrastructure.
On Nov. 15, we’ll be broadcasting 54 live sessions across 15 hours and 15 time zones. The All Day DevOps conference will be live, online and free. Anyone who registers can watch.
We have invited some top-notch practitioners from around the world to speak at the event on topics ranging from DevOps transformations, to CI/CD, to automated security, to modern infrastructure (think serverless, microservices and containers). The speaker lineup will include:
Damon Edwards, DevOps Cafe Podcast and Founder DTO Solutions
Sumit Agarwal, DevOps Change Manager at Broadridge Financial
Don’t Watch Alone – Host a Viewing Party!
One of the best parts of attending a DevOps conference is getting to interact with others in the community. We have had many organizations including Capital One, Intuit and Fannie Mae approach us about hosting viewing parties at their offices—and opening the party to the public. Sound intriguing? Here’s how to do it:
Secure the location. Pick your corporate auditorium, cafeteria or open meeting space. Secure it all day for Nov. 15. Make sure you have at least one internet-accessible viewing screen.
Promote the session: One you have the approved locations and times, share them here with the All Day DevOps Conference organizers. We will help you promote your party on AllDaydevopsy.kinsta.cloud and through social media postings, directing them to your registration page.
Invite People to Register: Set up a place for people to register for your location. You’ll want to know how many people to expect because you need to know how much pizza to order. Meetup.com and Eventbrite.com make event registration easy.
Make it Fun. Order some pizza and drinks. We’ll send along some cool laptop stickers from the conference and some of the sponsors. Share pictures from the event online (@AllDayDevOps). Join the conversation in the conference Slack channels. Set up birds-of-a-feather stations. Play some music during breaks. Set up viewing screens for each of the conferences three tracks.
Just to be clear: the All Day DevOps Conference is not a collection of vendor pitches. In fact, we have tried our darnedest to ensure the agenda is purely focused on real DevOps practitioners sharing their craft. Take a moment to look at the speakers participating in each of the tracks and you’ll see what we mean.
Register today. Invite your colleagues to attend. Then plan a viewing party at your office.
Scrum is, by far, the most popular way development teams are organized and work. In fact, well over 70 percent of Agile teams around the world use Scrum. But for those unfamiliar with the structure, Scrum may look like a strange collection of rituals and oddly named designations, such as the “Scrum Master.”
However, behind that collection of ceremonies, roles and rituals, Scrum is a huge opportunity for Operations teams to streamline development and delivery, improve productivity and create a strong sense of team within the group. Not only does Scrum encourage DevOps, but because it is empirical, risk and visibility are first-class citizens.
Scrum Basics, and More
For those wondering how to get started, here are eight things that every operations professional needs to know about Scrum:
Scrum is not focused solely on developing software; it’s about delivering software. The Agile Manifesto describes it as “working software” and Scrum describes it as being “Done,” but ultimately, Agile encourages teams to deliver working software to production frequently. With that in mind, it becomes clear that Scrum is not just about software development, but includes everyone involved in delivering working software to customers.
Definition of “Done” is a DevOps artifact. “Done” describes what it means to be finished with a product backlog item (PBI). Ideally, it describes all the steps necessary to release the PBI to production, or highlights the gap between what the Scrum team thinks Done is and Operations’ idea of what it means to be complete with a piece of work. Operations professionals need to get involved in the formation of the definition of Done (DoD) and work with the team to both improve its reach and validate its use.
The increment should be integrated and deployable. In Scum-speak, the increment is the working software the team produces during a Sprint (a set time frame, from start to Done). If multiple Scrum teams are working on the same product, then it is crucial that the increment be integrated across those Scrum teams. And, when I say integrated, I really mean integrated—as in, tested with processes and practices that are consistent with delivery to production. Thus, the increment is “ready to go.” By regularly integrating the increment, many of the problems that historically have plagued Operations are removed, as teams are, by design, forced into falling in sync much earlier in the life cycle.
The Sprint Review is not a phase gate to production. When moving from waterfall to Scrum, many organizations confuse the Sprint Review with a phase gate to move to production. Rather than being a phase gate for production—or the next phase of the process—the Sprint Review is a mechanism for the team and stakeholders to inspect and adapt at the boundary of the sprint. Ideally, the Sprint Review is executed on software that is being used by real users, in production. This increases the value of the review, as the team and stakeholders get to inspect how real people are using the software.
Continuous integration and continuous delivery automate Done. At the heart of Scrum is the idea that teams deliver working software in small batches to better understand the risks, requirements and solution. Adding delivery to continuous integration (CI) ensures they not only are integrating the software, but also formalizing the deployment processes to ensure there are no surprises. This is a great place for Operations to get involved and help ensure that aspect of Done is consistent with how it views delivering software. This might mean additional steps—or at the very least—a better understanding of operational versus development systems.
Scrum is an empirical process which helps reduce risk. The idea of delivering small chunks of functionality to support learning is at the heart of Scrum. Ultimately, Operations cares about risk. By delivering software in small batches, it is possible to surface risks early and mitigate them. By frequently delivering software, Scrum teams demonstrate they understand the processes necessary to deliver software, thus removing friction from traditional release processes. However, all of these benefits are undermined if the team does not use “production ready” deployment processes or include risk as part of their prioritization of what to work on next.
The Scrum Masters are Operations’ friends. The role of the Scrum Master is to both protect the team from outside distractions and help them to identify and remove impediments. To deliver Done, the team needs to work effectively with Operations and thus, the Scrum Master often will be the person who helps build those relationships. By working closely with the Scrum Master, Operations professionals will gain better insight into what the Scrum team will need from them and how they can deliver Done software.
Helping the Product Owner understand risk. The Product Owner (PO) manages the backlog, which is the place where all work exists. This means the PO is prioritizing the backlog and deciding on what should be done next. Normally, this is accomplished by looking at business value and negotiating with the Development team to determine what can be most effectively completed next. Operations has a great understanding of risk and, by working with the product owner, can add that context to the backlog, allowing the PO to make informed decisions and about value and risk.
Ultimately, Scrum provides a great framework to build bridges between Operations and Development and can act as a catalyst to drive fundamental improvements to the way teams collaborate and deliver business value. However, both sides need to stop hiding behind the “mystery of agile” to avoid each other and embrace the desire to break down things into small chunks, incrementally manage risk and get to repeatable Done software as fast as possible.
About the Author / Dave West
Dave West is the product owner at scrum.org. He is a frequent keynote speaker and is a widely published author of articles, along with his acclaimed book, “Head First Object-Oriented Analysis and Design.” He led the development of the Rational Unified Process (RUP) and then worked with Ivar Jacobson running the North American business for IJI. Then managed the software delivery practice at Forrester research where he was VP and research director. Prior to joining Scrum.org he was Chief Product Officer at Tasktop where he was responsible for product management, engineering and architecture. Follow him on Twitter.
When building DevOps or continuous delivery (CD) practices relying on Docker, you can learn a great deal from others. Reference architectures reveal what choices people made, what practices they put in place and how they connected the dots.
We at Sonatype pulled together a set of 21 reference architectures for folks building CD and DevOps practices using Docker. Why? DevOps professionals numbering 3,500 recently attended our webinar on, “Continuous Integration using Docker,” discussing just one reference architecture example. We recognized then there was a strong interest in the community to learn more. That’s why we assembled 20 more reference architectures into this collection.
A picture speaks a thousand words. Beyond the images, we also share the details of each DevOps/CD Docker reference architecture. In the bottom right corner of each slide, we share the original blog or presentation source for the image. When one of the images piques your interest, you can then dive deep into the source. Cool, huh?
Think of this set of reference architectures as open source. The slides are free to view, download and distribute. Share with others if you find them helpful.
Help Others
Oh, and if you have a Docker reference architecture we should add to the deck, please let us know. We would love to add it to our deck for others to learn from. Just like the others we included, you will be sure to get full attribution for your work.
For those of you not using Docker, we did publish a set of DevOps and continuous delivery reference architectures last year on devopsy.kinsta.cloud. With more than 86,000 views and 3,300 downloads, many people in the community have found it helpful.
The global audience for DevOps is expanding faster than any one person or company can keep up with. While DevOps Days and other regional events provide invaluable support to their local communities, we wanted to create a global event, offering the very best lineup of speakers across North America, Europe and Asia.
We also wanted to make sure that anyone, anywhere can attend. So, we set a high bar for our organizing team, and they delivered: $0 registration.
By creating All Day DevOps as an online event, we are able to get many people to attend and present—many of whom ordinarily would not be available because of time or travel restrictions. We expect well over 1,000 people to attend throughout the day.
15 Time Zones, 15 Hours, 3 Keynotes, 54 Sessions
Nov. 15 will see the first truly global, online DevOps Conference: All Day DevOps. Starting at 9 a.m. Greenwich Mean Time/5 a.m. Eastern Standard Time and continuing through midnight GMT/8 p.m. EST, there will be three simultaneous tracks, each track containing 18, 30-minute presentations, for a total of 27 hours of presentations.
Call for Papers
We are inviting speakers from around the world to participate in this first-of-its-kind event covering 15 time zones. Timing for the conference is set for the EMEA sessions to begin at 9 a.m. GMT, then, at 9:30 a.m. EST, move the concentration of presentations to the east coast of the United States and ending with presentations on the west coast of the United States starting at 11 a.m. PST. All sessions will be recorded, but you will need to register for the event to have access to the recordings.
The Call for Papers is now live. Please submit your paper soon. The deadline for submissions is Sept. 21.
Conference Tracks
The conference will host three tracks: Modern Infrastructure, Automated Security and CI/CD. We’ll have 54 sessions plus three keynotes on three tracks, running continuously for 15 hours.
Track One: Modern Infrastructure
Modern Infrastructure Track Hosts and Moderators: James Wickett, Signal Sciences, joined by Ernest Mueller, AlienVault and Karthik Gaekwad, Oracle
In this track, we will be discussing novel architectures, approaches and tools for building out software and services. We are not looking for the standard approaches, but the way Infrastructure will be in the next three to five years.
Track Two: DevSecOps & Automated Security — Living the Dream
Automated Security Track Hosts and Moderators: Milton Smith, Oracle, and Shannon Lietz, Intuit
You have a well-tuned development and delivery environment or you’re in the process of building one. AppSec is a top business concern. You moved DevSecOps from Big Foot and UFOs to reality, you sold the dream to staff, and now it’s beginning to pay off. This track explores DevSecOps tools and techniques to build a successful automated security program.
Track Three: CI/CD — Continuous Everything
CI/CD Track Hosts and Moderators: Derek Weeks, Sonatype, and Andi Mann, Splunk
Continuous delivery is not magic, but it does take the right effort. The most successful practitioners have taken pragmatic steps to reduce cycle times, improve collaboration and build quality in without burning people out. This track asks you to share your frontline experiences of building CI/CD pipelines, aligning key stakeholders and measuring the results. Remember, what’s now an everyday experience for you is awesome to another pursuing that path.
Conference FAQs
How to I register to attend?
Registration is open now at AllDaydevopsy.kinsta.cloud. The site will be constantly updated, sometimes multiple times per day, with the latest information. You can also follow us on Twitter under the handle @AllDayDevOps and using #AllDayDevOps.
How will the sessions be delivered?
The sessions are delivered over Google Hangouts, allowing us to have an unlimited number of attendees on each of the three channels. All you need to deliver a presentation is a reliable internet connection.
We are also arranging Slack channels for all sessions to host interactive Q&A sessions for everyone.
If my talk is selected, can I post a notice or an article about the conference on my site?
Not only is it OK, we would thank you profusely if you did. You’re welcome to use the banner and the conference icon if you need graphics for the article. Let us know when it goes up and we’ll give you a shout-out.
Who is organizing All Day DevOps?
The All Day DevOps Conference is organized by advocates in the DevOps community. We are working together to deliver a diversity of vendor-neutral sessions and speakers from around the globe to show practical usage and technical solutions of DevOps in small and large enterprises.
David Cramer is vice president of Product Management for the Cloud/DCA business unit at BMC. Prior to BMC, David was head of product management for CA Technologies. During his tenure at CA, David was responsible for application delivery, cloud management, virtualization and Infrastructure automation solutions. Before joining CA, David held executive positions at AlterPoint, Motive, NetSolve and Nortel Networks. David’s focus is on continuous delivery, cloud management and web-scale IT. David received his MBA from Southern Methodist University and a BS in Finance from Georgia State University. Connect with him on 
Dave West is the product owner at 
