staging-devopsy.kinsta.cloud

Category: Features

  • The DevOps Equation: Agility + Empathy = Quality

    The DevOps Equation: Agility + Empathy = Quality

    I had the chance to catch up with Jeff Sussna (@JeffSussna), founder and principal of Ingineering.IT, ahead of his keynote address on continuous design, scheduled for DevOps Days Atlanta, April 26-27.  He discussed the importance of designing for service, responding to the unexpected, and the importance of building empathy across teams.  

    Derek Weeks (@weekstweets): Today I’m really happy that we have Jeff Sussna joining us for the latest in this series. Jeff, why don’t you introduce yourself?

    Sussna: Sure. Thanks for having me. I’m an independent consultant. I’ve been around, since rocks were young or the 80s, whichever is older. My particular background is that I have built systems and led organizations across the entire development, QA and operations spectrum. So, I’m a little unique in that respect.

    My current focus is on helping IT organizations and digital businesses really bring together their ops and design thinking so they can not only go faster and not only be more resilient, but provide more customer value at the same time.

    Weeks: Let’s talk about that a little. How is continuous design—a subject you have written a lot about—coming into play? How can it help us be more resilient.

    Sussna: Just to explain a little about what we mean by continuous design. It’s basically bringing together the entire organization and a unifying design in operations. It’s taking what we are doing in DevOps and expanding it to include product, design and support. It lets the whole organization really have an agile conversation with a market and with its customers.

    The issue that we face is that we live in a service world now. The point is no longer delivering products like cars coming off an assembly line. It’s much more about responding to our customers and having relationships with them. This is happening in a world that is more and more complex while less and less is in your control. We can’t figure everything out in advance. We have to have the ability to respond to the unexpected. We have to be able to do that at every level.

    “This is happening in a world that is more and more complex, while less and less is in your control.”

    I will give you a couple of examples of things that are perfect illustrations of this:

    I recently wished a friend of mine happy birthday. The reason I did that was that because there was a notice on my calendar that said it was her birthday. It was wrong. It wasn’t her birthday. I had no idea where that notice came from. Did it come from Skype? Did it come from LinkedIn? Did it come from email? I had no idea.

    We face that in IT, too. Systems are becoming more complex. We develop microservices. We use public and private clouds at multiple levels. We’re no longer in a situation where we can control things. We have to be able to respond and respond at all levels.

    When we make design and operations unified and continuous, we are able to say, “Where did we think we were going? Where would we need to go? and what do we do next?”

    What I talk about in my book, in my workshops, and all my work is that this needs to happen at every level. It’s not just a matter of designing for failure inside the data center or inside the infrastructure. We also have to do it at other levels.

    Here is another example:

    I was trying to get paid recently by a large enterprise client in Europe. They were trying to wire money internationally and my bank wasn’t really set up for it and they were having problems. They just kind of gave up. I kept getting these messages saying, “Sorry, we tried paying you and it didn’t work.” That was the end of it.

    I started to get frustrated and my client within the enterprise started to get frustrated to the point where they sent a scathing email to our AP department which they CC’d me on, saying, “Why can’t we take the lead to get his guy paid?”

    That’s an approach that is based on resilience in the sense of assuming that something can go wrong and figuring out what he can do to fix it when it can go wrong. As opposed to the traditional approach where we’ve been trained to push certain buttons and take certain actions. If those actions don’t work the way they are supposed to, well, I guess that is someone else’s problem.

     

    https://www.youtube.com/watch?v=ISSMHmwIMtA

     

    Weeks: This brings to light some recent conversations I was having with Paula Thrasher at CSRA. She was talking about developing systems and how to make them more resilient. She is using pictures as part of her conversations with people to help visual their work. What work steps are there? What work is flowing? What is communicating with what?

    Are you taking similar approaches with continuous design in how you work with clients to pursue it?

    Sussna: Well, I try to introduce them to the principles and I also try to introduce them to a set of practices which actually comes out of Mark Burgess‘s work on promise theory. It is really a conceptual model for how we think about success and failure and how do we think about service. For example, Amazon helps you get everything you need in your life from shaving cream to batteries to snow tires to books as quickly and easily as possible. In order to keep that promise they make a whole variety of other promises. Some of which filter all the way down to a promise to be able to go over and make a change to production as quickly as possible.

    Once you take that mindset. The interesting thing about a promise and the reason we use that word is because it is very intuitive. We all know what a promise is. We all make promises to each other every day. On the other hand, when we think about it in terms of service, IT, or whatever it may seem a little odd. The thing about promises is that on the one hand we are making commitments to do things and on the other hand promises sometimes get broken. That is actually good because it forces us to think. If I promised to pay my vendor. What do i do if I’m not succeeding in paying my vendor?

    The thing about promises is that on the one hand we are making commitments to do things and on the other hand promises sometimes get broken. That is actually good because it forces us to think.

    It’s sort of flipping our mind. Again, we are doing this in DevOps world where you start thinking about things like mean time to repair (MTTR) instead of mean time between failure (MTBF). We shift from how do we create a situation to how do we create a situation from where nothing will ever break—which becomes less and less possible. When then need to shift to a situation where we can respond more and more quickly.

    We go to executives and say, “We don’t want to worry about how often stuff breaks anymore,” and they freak out. We have to teach them and we have to teach ourselves that we can’t prevent things from breaking. Instead, let’s be able to fix them so quickly that maybe no one notices. My focus is on really helping people shift their mindset from thinking about ourselves to thinking about who we are helping. And from thinking about what we are doing to thinking about how well it succeeds and how well it overcomes problems.

    We have to teach them and we have to teach ourselves that we can’t prevent things from breaking. Instead let’s be able to fix them so quickly that maybe no one notices.

    Weeks: You talked about delivering on promises as quickly as possible. How does continuous design account for doing things as quickly as possible but making sure the quality is there at the same time?

    Sussna: In two ways—one way is that when you do things in small increments you are able to find problems more quickly. This is classic; it comes out of lean. It comes out of integration. It’s pretty basic stuff for our community now that it’s much easier to find and fix a bug five minutes after you change a code than five weeks after you change the code.

    When you put things like Linux, agile, DevOps, and design all together, they all focus on incremental feedback loops where you discover the gap between what you think you’re accomplishing and what you’re actually accomplishing very quickly. Secondly, when you take this all to the way to the marketplace and you make it part of the relationship with your customer, you can reduce a tremendous amount of waste.

    The way to think about continuous design is: it’s all about steering. Think about a boat and you’re trying to sail across a bay. You can’t just point the boat at the other side and say go because the winds are changing and you’re going to be able to respond to things that you can’t predict. If you sail for 20 minutes then discover you had pointed in the wrong direction, you’re going to be way off-course. You’re then going to generate a tremendous amount of energy getting back on course.

    What continuous design says is just an extension of continuous integration and continuous delivery taken all the way though the business. When we steer continuously we steer efficiently.

    What continuous design is really just an extension of continuous integration and continuous delivery taken all the way though the business. When we steer continuously we steer efficiently.

    Weeks: I know you’re going to be keynoting DevOps Days Atlanta coming up in April. Chris Corriere, one of the guys on the organizing committee, tells me that you’re leading a full day workshop on continuous design before that. Maybe you could tell some of the people that are attending DevOps Days Atlanta why they should be there a day earlier for your workshop and what things you’re going to address during that time.

    Sussna: To some degree what I am going to address is everything we have been talking about for the last 10 minutes or so—relative to DevOps. I think the key thing is, and we need to think about it. We need to think about more than just going fast. One of the big misunderstandings that I see with DevOps is this notion that it is primarily about delivering application changes to production faster. That’s only half of it. We really need to think about from the perspective of providing service.

     One of the big misunderstandings that I see with DevOps is this notion that it is primarily about delivering application changes to production faster. That’s only half of it. We really need to think about from the perspective of providing service.

    You know what we are talking about is essentially developers and operations people providing better service to each other. As a result, they can deliver better service to the business.

    Where we talk about microservices. You know that word service is in there for a reason. If all you do is you kind of shatter your organization and shatter your architecture into a bunch of little pieces, you still have to figure out how those pieces come back together into something coherent. The answer to that is taking a really deep service-oriented approach. That is very much what my workshop is about. What does that word even mean and how do we do it?

    Weeks: You mentioned thinking about interactions as delivering better service to one another within the organization. How does empathy come into your thinking around DevOps and Continuous Design?

    Sussna: I’d like to say agility plus empathy equals quality. What I mean by that, in particularly empathy, I think it’s important to take a minute and clarify. When we talk about empathy we are not talking about wallowing in someone else’s pain. We’re not even necessarily talking about things on an emotion or feeling level. It’s very simply the ability to see things as if from an other’s perspective. I will give you a prime example of where that comes into play and how it’s important and how it helps.

    Agility + Empathy = Quality

    When I work with clients, I tend to look at their process using their organization from the product beginning to the support end. Often times I see support getting the short end of the stick. I see places where they get phone calls from customers with features that they don’t even know exist yet. They sometimes get talked down to by development or product or even operations. They say things like, “Well you’re just supposed to support the stuff. You’re the young people. You’re the less experienced people.”

    When we have the ability to see things from their perspective, we can think about how support is actually experiencing our delivery process. If we don’t think about them when we go through the process of delivering new features, they will be lost. Them being lost will show when customers call for help. That will significantly affect customer satisfaction and then even beyond.

    The reason we need to empathize with support is so we can empathize with the customer. Often times when we build things and we don’t think about the notion that our customers might have trouble with it. On the one hand we have the illusion that if we design it and we build it really well, they won’t have trouble. We can’t perfectly predict who they are, what they need or what they will encounter. There’s an inevitability to the idea that they are going to need some amount of help.

    Weeks: I think that is probably the best description of empathy within a DevOps environment that I have heard anyone talk about. Jeff it has been a great conversation. Thank you very much. I really appreciate it and we look forward to seeing you at DevOps Days Atlanta coming up.

    Sussna: Thanks. It has been great talking to you and I am really looking forward to the conference. It will be fun.

    If you want to learn more about continuous design from Jeff, be sure to join us at DevOps Days Atlanta. I will also be at the event giving an Ignite Talk, titled, “Real Heroes Draw Pictures,” focusing on lessons learned from the 31 DevOps and continuous delivery reference architectures I assembled.

  • DevOps in 2016: Mainstream Momentum Ahead

    DevOps in 2016: Mainstream Momentum Ahead

    I believe that 2016 will be the year that DevOps takes mainstream foothold in the enterprise. And I base this assertion on seven sweeping changes that — from my vantage point — are taking hold and dramatically changing the digital world.

    1. The Job of IT Will Change From Infrastructure to Innovation. In the past, IT has been about providing compute infrastructure and applications to run the internal workings of a company. But this has been radically shifting as digital transformation penetrates nearly every company of significance across the globe. As a result, IT is increasingly about driving innovation and customer value through software. We see this every day from our work with large enterprises; indeed, almost half of the global 500 use Chef in some manner. And, in our interactions with enterprise customers, over 75 percent cite innovation, velocity and agility as top priorities for IT — and the company. The common ingredients behind this are almost always automation, cloud and DevOps. In fact, while these three elements are, in many ways, distinct, they form a magic IT trinity in service of innovation-led organizations. If you need further proof that IT is on its way to becoming the pointy end of the innovation-creation spear inside large-cap companies and organizations, just look at the auto industry, where CES may actually be more important than the Detroit Auto Show, where GM is investing in Lyft, and where Google is doing state-of-the-art R&D on a self-driving car.
    1. Continuous Delivery (CD) Will Become Ubiquitous. CD is the practice of rapid software development and iteration through fast, small-batch releases. In its purest form, developers can drive small, incremental software releases quickly, sometimes as often as every few minutes for some very well known Web sites. Not long ago, CD was exclusively the domain of big Web innovators such as Facebook, Amazon, Google and Yahoo! Not long ago, making even several releases a day sounded insane. And not long ago, a CIO told me that it was ridiculous to contemplate bringing CD into the enterprise. All this has changed, and today it makes absolutely no business sense to shy away from CD because it’s one of the keys for unleashing an organization’s software development innovation engine. The point is that the whole stack — infrastructure, compliance, security, microservices and applications — is being expressed as code now, and  it’s the same as you deliver with work-flow. In the end, whether your company needs to release frequently all the time, or not, every aspect of IT is charged with a business requirement to do something quickly some of the time. CD is a very important piece of the puzzle.
    1. The Public Cloud Will Triumph in the Enterprise. You may think the cloud is old news, but it’s not. In 2016, the enterprise is going to move beyond public cloud experimentation and project-based work and start migrating entire data centers to the public cloud. We’re also going to see more hybrid cloud initiatives (whatever the composition) because dual adoption helps companies avoid vendor lock-in. As for private cloud projects, there are definitely some good teams and technologies out there. But, having said this, I believe that the public cloud will win out. Many of the lingering public cloud issues, like security and governance, have begun to evaporate. And the ease of use, affordability and effectiveness of the public cloud will simply triumph in the enterprise over the next 12 months at the expense of the private cloud.
    1.  We Will Enter a New Era of System Administration. The world of systems administration has changed forever. In the IT world that I grew up in, a human being logged onto a system to manage, update or fix it manually. Since then, compute scale has grown exponentially for most organizations, thanks, in part, to both server virtualization as well as the cloud. Most of our enterprise customers have, excluding desktops, tens of thousands of compute nodes. Some have over 100,000. A few have over 1,000,000. Administering systems manually by having humans act on systems is no longer viable or tenable. In the new era, humans act on code and code acts on machines. In fact, code is the system. In other words, humans act on compute resources through code. And this reality creates a whole new universe for the world of system administration. The bottom line? The job and role of the system administrator will change significantly. Watch this trend play out in 2016.
    1.  Peace Will Break Out Between Developers and Security / Compliance Officers. This has been a long-running battle inside the enterprise, and there are several theories behind the conflict. One is miscommunication — the  security team doesn’t think the dev team gets it, and the dev team doesn’t think the security team gets it. Another hypothesis is that developers just want to be left alone to write code for the business, but the business is increasingly worried about security — not just IT security. And, lastly, there’s this explanation for the hostility — developers want to go fast, and security teams want to slow everything down to a safe speed. Whatever the reasons, I believe that developers and security / compliance officers will find much more common ground in 2016 because we’re learning that compliance and velocity aren’t necessarily in conflict with each other.  In fact, high-velocity IT organizations can deal with security threats more quickly by assessing vulnerability, creating a fix, testing it and then deploying it rapidly before the damage is done. We’re also seeing the early beginnings of what I believe will be a very important trend in our industry: compliance defined as code. Today, compliance is all too often defined in binders or text documents; what’s a developer going to do with this? But we’re seeing a new idea emerge: define compliance — either to your own security standards or external, regulatory standards in code. If you can define compliance as code, you can then use that code to create a test that can simply be moved into the software release process and managed like any other automated test. Forward-leaning compliance officers will shift their gaze and embrace their developers because it’s through their software developers that they’ll be able to take their craft to a new level.  Keep an eye on this in 2016.
    1.  Executives Will Move Into the DevOps Tent. The DevOps tent will expand to include the executive suite in 2016, and executives are excited to join the practitioner-born DevOps movement. “DevOps” makes one think of only “development” and “operations,” but it’s really a movement focused on how we build and operate high-velocity organizations. Frankly, DevOps is meant for the entire enterprise. The results are both clear and definitive. Mature DevOps organizations see increases in both innovation and quality that flow through to business results, including profit and shareholder value — and, quite possibly, security and safety as well. Executives have seen what code can do, and they’re fervently embracing the far-reaching organizational changes that have accompanied this technology revolution. The good news for DevOps practitioners is that they’re going to find strong support in the executive suite and many will see good things happen to their careers in 2016
    1.  Container Technology Will Be Improved and Grow Even More. Containers — which bundle entire run-time environments into packages that make it much easier to move applications from a developer’s laptop to the test, production and end-user stages — are becoming invaluable, especially in homogeneous green-fields, because they abstract so many problems away. But most enterprises aren’t homogeneous green-fields, so the challenge is how to deal with a variety of legacy technologies without re-writing all the applications that run. I believe that this problem will be addressed in 2016, and container usage will expand by leaps and bounds as a result.

    There will be other big changes in IT during 2016, but, when combined, I believe these seven represent a truly significant tipping point that will catapult enterprises toward the future with a velocity and vigor that can only enhance and enrich growth.

    Abouth the Author/Barry Crist, CEO, Chef

    Barry-Crist-620x930Barry Crist is CEO of IT automation company Chef. Barry has more than 20 years of experience in driving enterprise customer success and adoption with both open source and DevOps software solutions. Prior to joining Chef, he was CEO of Likewise, a company with a strong open source to enterprise go-to-market model that had wide industry reach including OEM agreements with VMware, Dell, HP, Riverbed, and EMC. Likewise was acquired by EMC Isilon in September 2012. Prior to Likewise, Crist served as Vice President of the Application Management group at Mercury, now a division of HP, where he grew North American sales from less than $1 million to more than $75 million. Crist led enterprise sales organizations at Network Associates (now McAfee) and was in various sales, technical, and international roles at Apple.

  • Jenkins Founder Kohsuke Kawaguchi Talks DevOps Leadership, part 1

    Jenkins Founder Kohsuke Kawaguchi Talks DevOps Leadership, part 1

    Kohsuke Kawaguchi, founder 0f open source continuous integration tool Jenkins, was an early leader in DevOps, guiding the development of the Jenkins Project during his time at Sun (and later, Oracle) and plotting the course it would follow.

    “This project started as a hobby while I was at Sun,” Kawaguchi says. “From the project’s inception, it was not popular. During those early days, my leadership was really just to keep the project going. It was easy for me because the project was so useful that I didn’t need any external encouragement.”

    Once Jenkins steadily gained acceptance, Kawaguchi worked on polishing it and making it more user-friendly. “Writing software that works for you is much easier than writing software that works for other people, especially first-time users,” he says, noting he drew from his experiences supporting users to make Jenkins a better tool.

    Kawaguchi applied his previous open source project experience to make Jenkins an application/project that others could join, invest in and enjoy using. “As the project grew even more popular, I expended more conscious effort into those initiatives, specifically into extensibility and incentivizing sharing,” says Kawaguchi.

    Kawaguchi’s Vision for Extending Jenkins & Incentivizing Sharing

    Kawaguchi decided to use a plugin model for extensibility to solve the potential bottleneck of using an increasing number of contributors while managing change. Sensible software development does not permit unbridled change; developers must propose changes or at least innovate in an environment where they can retract changes that create issues.

    To attract more contributors into Jenkins, Kawaguchi decided to let people add whatever they wanted to it, through plugins. “Selling me on a software change need only happen when a change affects my use, so if we can split things up such that your change is in your plugin, I’m not affected by your change so long as I don’t use your plugin,” explains Kawaguchi. “This enables developers in the Jenkins Project to go from idea to implementation without getting blocked by someone, which reduces organizational overhead and encourages innovation.”

    But while this approach solves the extensibility issue, it also can create a new one. Without any incentive to share plugins with other users, extensibility can lead to siloed development in which only the group that created the plugin benefits from it. It then becomes difficult for the open source community to locate, leverage and improve on others’ advances, leading to plugin abandonment should the developer of that extension relocate to another project.

    Kawaguchi pressed for an update center and set a rule that plugins listed in the update center must be available to the entire community. “This created a positive feedback loop that encourages users to install plugins through the update center and developers to bring their plugins to the community,” says Kawaguchi.

    Breaking Down the Walls

    While extensibility and sharing accomplished much, the Jenkins Project faced another hurdle. Other projects such as the Apache Project use apprenticeships (the “committerships”), an approach designed to create a stable of tried-and-true contributors. But it also can be a hurdle, discouraging many developers.

    The Jenkins Project, however, simply asks that contributors apply good judgment when considering whether a plugin/change is good for the larger open source project and its community. “This might sound scary to some, but it really strikes the right balance between the speed of progress and quality,” says Kawaguchi. “Besides, everything is version-controlled, so if we later find a problem, we can always roll things back.”

    Stay tuned to staging-devopsy.kinsta.cloud for the rest of Kawaguchi’s DevOps journey with Jenkins.

  • DevOps in 2016: The Year of Implementation

    DevOps in 2016: The Year of Implementation

    DevOps is the default software delivery approach for modern IT organizations and hyperscale startups that have incorporated the culture into their everyday integration and delivery activities.

    However, over the past year, these organizations have also started to recognize and acknowledge that there are challenges in certain aspects of the DevOps approach, including precarious security infrastructures, R&D team member burnout, and the need to close gaps between operations and development with dedicated personnel such as site reliability engineers (SREs).

    In 2015, we saw larger enterprises beginning to migrate to Amazon Web Services (AWS) and sketch out their plans to incorporate agile and DevOps methodologies. The implementation process necessitates changing cultural norms, and incorporating new tools and organizational processes. And with DevOps’ great benefits, my prediction is that in 2016, these enterprises will move from the drawing board to implementation.

    1. Companies will stop talking and start implementing. In 2016, DevOps culture will finally become mainstream (and not only for startups and tech-savvy companies) as more traditional enterprises jump on the bandwagon and start implementing real DevOps principles. IT leaders will need to figure out how to restructure their teams, adapt DevOps values, concepts and tools, and incorporate continuous integration and continuous delivery practices to do a better job of meeting user expectations of fast and agile delivery.

    Having said that, traditional IT organizations that deal with sensitive data and tight change management processes — such as those in the health, finance, and some government sectors — cannot compromise their strict IT delivery standards, especially if they have to comply with security and compliance protocols. Therefore, 2016 will still be just the beginning for enterprise-grade DevOps implementation in several specific industries and verticals

    2. SREs will bridge the gap. The growing movement of site reliability engineers (SREs) is being led by Google and has been introduced to the world as part of a practical and more mature DevOps adoption. SREs are software engineers who work in operations and are in charge of availability, change management, emergency response, and monitoring (among other things).

    Even early DevOps adopters such as LinkedIn have begun looking for dedicated individuals to fill SRE positions, which require ops as well as code-level management skills. In 2016, we will see an increasing number of discussions on SREs as well as more job opportunities for them, making this new class of engineers key players in DevOps implementation.

    3. High demand will mean high salaries. What we have seen within our company as well as among our customers is that dev and ops engineers with strong experience in working with and implementing DevOps are still a rare breed. As more and more IT leaders recognize the need to move to DevOps, the higher the demand and compensation will grow in 2016 for the limited number of experienced engineers.

    According to Puppet, DevOps engineers make noticeably higher salaries than most other IT positions and 55% of U.S. DevOps engineers earn $100,000 per year or more. While large IT organizations are building their own education and training plans in anticipation of the move to DevOps, the demand for experienced engineers will still continue to grow in 2016 and beyond.

    4. We will have more Big Data benchmarks. Over the past two to three years, the IT industry has embraced Big Data. Technologies such as Hadoop and MongoDB are commonplace now when it comes to extracting values from large data repositories. Today, companies in industries ranging from Adtech to online gaming to finance are already utilizing Big Data to enhance their core capabilities.

    Over the past year, we saw the rise of more solutions that help with implementation and presentation that aid in generating insights and enhancing user experience. Beginning next year, these big data solution vendors will leverage their unique positions and advanced technologies (such as machine learning) as well as their vast amounts of data to create specific industry benchmarks and best practices that will ultimately enhance customer satisfaction.

    5. Some companies will reverse-migrate to on-premise. Don’t get me wrong, we’ll still see AWS, Azure, Google Cloud Platform (GCP), and others continue to grow their user bases among next-gen companies as well as traditional organizations such as, the Guardian, which recently failed to build an OpenStack private cloud and consequently decided to go all-in with AWS.

    However, companies that have been using the public cloud for the past year or two will see their cloud bills start to soar (if they haven’t already) and look around for cloud solutions that better meet their resource-utilization levels and business model. I think we’ll see more of this so-called “reverse cloud migration” as the cloud business matures in 2016. This is actually a sign that this market is maturing and that people are past the super-hype phase and seeing the pros and cons of the public cloud.

    In Summary

    Of course, no one can predict the future, but the events of 2015 may hint at what we will see in 2016 — and that points toward an increasing implementation of DevOps practices.

    Some companies will manage to complete their DevOps cycles and have full-blown, continuous deployment straight to production. However, the majority will be challenged by even the basic implementation processes and needs such as which DevOps tools to use, how to reconstruct their organizations, and what state of mind to have.

    Still, DevOps will eventually be the norm when it comes to software development and delivery — it is just a matter of time.

  • Continuous Delivery versus Continuous Deploy

    Continuous Delivery versus Continuous Deploy

    Getting a solid grasp on the meaning of DevOps requires a clear understanding of the terms used to describe it. Over the last several years, we have seen a paradigm shift in the way software is developed, moving away from a waterfall approach, with monolithic releases, to an agile approach with incremental releases.   This shift has changed the way in which the Application Lifecycle (ALM) is managed. Focus around what we normally would refer to as ALM is now more accurately described as Continuous Delivery. Continuous Delivery is not a set of tools, it is an emphasis on people (culture), tools and processes. The change from ALM to Continuous Delivery includes three very basic principles:

    • The software is always deployable which means you prioritize keeping the software deployable over adding new features. To do this requires smaller, less risky changes released overtime instead of all at once.
    • A feedback loop of the build, test and deploy steps expose the readiness of the software allowing anyone from development, test or production to determine that an immediate release of the software to any environment can be approved.
    • Automation of the build, test and deploy process is critical in order for the process to be repeatable and to support a higher frequency of builds, deploys and test cycles.

    So like ALM, there is an awareness of a lifecycle (Dev, Test, Prod). But unlike ALM the lifecycle should not be seen as linear. With Continuous Delivery, a software update may move from Development directly to Production without having entered the Test phase. Because Continuous Delivery principles support keeping the software in a deployable state, with a visible feedback loop to determine the readiness of the software, software can be confidently moved into any environment at any time.

    This change between a linear, waterfall approach, to an non-linear agile approach is far more realistic in the way organizations manage their software. Over the course of my 20+ years’ experience working with both large complex enterprises and small software teams, the need to be able to perform a release, into any environment at the ‘drop of a hat’ has been consistent and problematic. The principles behind Continuous Delivery defines a more realistic approach to software development.

    Moving from a linear application lifecycle approach to Continuous Delivery includes making changes at many levels. First, developers must begin embracing Agile practices, managing smaller, incremental releases. Because Agile increases the frequency of builds, testing and deployments, DevOps tools must be in place to support the automation of these tasks. In the waterfall approach, teams had the luxury of time to get build scripts to work, execute test manually, and write a deploy script for every environment. Continuous Delivery does not offer that luxury therefore automation of these tasks becomes critical. This is why Continuous Build, Continuous Deploy and Continuous Test tools are implemented. Continuous Build addresses the frequent building of code changes, updating binaries upon a check-into version control, and reporting on what artifacts were impacted providing feedback into the readiness of the build.

    Continuous Deployment automates the movement of those binaries to any endpoint in any environment and supports server configuration management, all performed on an incremental basis with feedback showing the inventory and the changes. Continuous Test automates testing so developers and/or testers can run through critical functional test, and code analysis to provide feedback on the readiness of those binaries.

    To maximize on automation, these steps are chained together using the workflow engine of the Continuous Integration Server. The workflow can be triggered upon a source code check-in, kicking off a compile/link (build), running code analysis, deploying to an endpoint and running test. In Continuous Delivery, each environment may have their own Continuous Integration workflow that performs the steps needed. For example, a Production CI workflow may just perform activities related to moving the code to hundreds or thousands of endpoints, with database updated, but not execute a build or test.

    Not all is perfect in the Continuous Delivery approach. Automation continues to be a bottleneck. As with most paradigm shifts, changes in behavior and adoption is a major hurdle. In most companies, the use of manual scripts to perform builds, deployments, test automation and manage infrastructure are still called under the covers of the Continuous Integration workflow. These are the same scripts that were used in the waterfall approach, except now there is not the luxury of time to fix the scripts or update them to adjust to software changes. To support Continuous Delivery, the build, deploy, test activities must be elastic, automatically adjusting to code changes, database updates and server configurations.

    To create a more dynamic Continuous Delivery process, DevOps tools are moving away from the need for coding one-off scripts and instead moving to a model driven approach with Playbooks and Plug-ins. Many developers still hold on to these scripts with the argument that they do not want to be at the mercy of a ‘vendor’ or ‘tool’ to manage these low level tasks. As Continuous Delivery pushes the frequency of releases, this final paradigm shift, moving away from the old approach to one-off scripting, will need to move into full automation. Continuous Build will be supported by Build Automation, Continuous Deploy will be supported by Application Release Automation and Continuous Test will be supported by Testing Automation and Virtualization. The automation tool chain will be orchestrated via a Continuous Integration Server and the entire process will become a reliable and fast Continuous Delivery process.

    About the Author/Tracy Ragan

    tracy-clr-128x124pixelsMs. Ragan has had extensive experience in the development and implementation of DevOps for large organizations. She began her consulting career in 1989 on Wall Street specializing in build, testing and release management for the distributed platform. It was during her consulting experiences that Ms. Ragan recognized the lack of standardized development procedures on open systems that was common on the mainframe. In the years leading to the creation of OpenMake Software she worked with development teams in implementing a community driven standardized build and deploy process that enabled frequent builds and releases, automated around version control. Her knowledge and experience contributed to the creation of OpenMake Meister, the first commercial Build Automation solution. Ms. Ragan served on the Eclipse Foundation Board of Directors as an Add-in Provider Representative for 5 years. She has been published on numerous occasions and regularly speaks at conferences including CA World where she presented for 15 consecutive years. She holds a BS Degree in Business Administration, Computer Technology from California State University, Pomona.

  • The DevOps Dozen

    The DevOps Dozen

    After over 2500 votes cast in the final round and almost 5000 votes in total we are very proud to present the winners of the inaugural DevOps Dozen awards. These companies were voted by you our readers as the top companies in the DevOps market. They are not companies that are necessarily using Devops internally (though many of them are and have had their own DevOps journeys).  They are the companies/organizations who are producing the tools and services that are helping make DevOps the force for change that it is.

    Also a quick word about all of the companies that we nominated for these awards. There were originally something like 100 companies to choose from. We then narrowed it down to the final 32.  Any one of the final 32 were worthy of being in this list. of the DevOps Dozen  At some point yes it is a popularity contest. Some companies are better at turning out their voters then others (just like in real elections).  But on the other hand there were some companies that didn’t campaign at all.  They are here because by consensus they belong here.  With so many votes cast, you have to believe that  the companies that made the final 12 do belong here.

    Congrats to the 12 companies/organizations listed below!

    (Please note that you can download

    [seoslides embed_id=”0e545f934454″ script_src=”https://staging-devopsy.kinsta.cloud/embed-script/dd-finalists-final/10755/” overview_src=”https://staging-devopsy.kinsta.cloud/slides/dd-finalists-final/” site_src=”https://staging-devopsy.kinsta.cloud” site_title=”staging-devopsy.kinsta.cloud” title=”DD Finalists Final” /]

    In the coming months we will hold additional DevOps Dozen awards for companies that are leveraging DevOps most successfully and for those individuals who are the current leaders of the DevOps movement. Stay tuned for those after the first of the year.

  • Dice Breakers: using DevOps principles and nerdery to reimagine Team building

    Dice Breakers: using DevOps principles and nerdery to reimagine Team building

    Software is a young industry, and not a very traditional one. Your team can’t always be expected to behave like teams in other fields.

    So it’s no surprise that when a development team hears the phrase, “teambuilding exercises” for most of them it conjures up the idea of a room full of awkward people marginally engaged in a trite set of activities.

    But given the resonance of ideas like DevOps it is apparent that the benefits of teambuilding are still sorely needed. Software companies can fall into a very ‘silo’ed mentality.  This is often to our detriment, and tearing down those barriers is a big part of a DevOps philosophy.

    So there is an impasse; prepackaged, standardized teambuilding exercises fall short of a development team’s needs, and the need for the lessons those exercises try to get across is unmet.

    Last year, when I was working on Release! the Game, I realized something; the things we do outside of work, still resonate inside of work.  That led me to think that Office Game Nights might be an interesting, albeit nerdy,  solution to this issue. But before I explain my dice driven solution, let’s talk a little about traditional team building.

    Classic Teambuildingtrust-catch

    For the sake of discussion let’s say that by and large teambuilding activities all have a similar set of goals:

    • Encourage communication
    • Create easy references for actual on the job problem solving
    • Relieve stress
    • Provides a structure for complaints and socializing

    How they try to accomplish this varies, but as a general rule they set forward an infrastructure for interaction that is easily explained, and with a mechanic for comparison to the real work day.

    For example, in the classic Trust Fall exercise, one person is called out, to fall backwards while their team is called to catch them. Takes a minute to explain, and the concept that we have to rely on and trust our coworkers is applicable almost everywhere.

    It’s a fairly simple formula, get the whole office together, present a challenge, collaborate to meet it, and then discuss the vagaries of how you worked together. Your team bonds a bit, and gets some reinforcement on general work principles.

    Why doesn’t that work for Softwareliz-lemon-giphy

    In the case of software development teams we actually wind up seeing these results:

    • Sighs, scoffing, and somewhere in the dozens of eye rolls, depending on team size
    • Some variation on the phrase, “I could be getting real work done now.”
    • Some variation on the phrase, “At least I’m not doing real work right now.”
    • One or two sincerely interested participants

    Why?

    Whatever your place on a development team your job will revolve around creating or manipulating complex logic chains to overcome some hurdle.  This, in and of itself, is not that much different from any other job, the difference is code.

    Code is abstracted, it is just the logic. Code doesn’t need a teambuilding exercise it just needs to be formed correctly, tested reliably and it just works. If it has a problem, communication or otherwise, there is a distinct and detectable source of that issue, and one that, most of the time, has a methodical solution.

    That’s a simplified explanation, but the key there is that there is an identifiable problem, and an identifiable solution. That just isn’t the case for the social systems that operate outside of the code. Navigating the personalities and relationships that form in a workplace simply doesn’t have the same amount of landmarks that navigating code does.

    The pit fall is in thinking that the software you produce, and your company are the same creature, or at least have the same needs.

    Teambuilding isn’t about the product. It’s about establishing a better system for the people who work on that software, and helping them make the connections that will make production run smoother.

    Teambuilding and DevOps

    DevOps principles demand strong communication between the members of your team. The tools, the methodologies, all need the right environment to be applied in.

    So if you want to build a team that can really talk to each other, you need to step away from the standardized techniques, and pick up some new tools.

    For team building ideologies to function they require a sincere investment on the part of the participants, but, in most cases, they are so pre-packaged that the exercises themselves lack sincerity.

    Openly acknowledge the goals that your teambuilding program is trying to achieve and don’t couch it in the window dressing of corporate training. There are plenty of structured activities that get folks talking, let them blow off some steam, and foster a sense of teamwork that can be easily reflected during your regularly scheduled workday.

    My Answer?game-shelf

    (spoiler alert: this is where it gets nerdier)

    Board games: sweet dice rolling, card shuffling goodness.

    Game nights (or days) are a great place to do some socializing, have a necessary structure around that socializing, and encourage creative problem solving either through cooperation, or competition. There are also a lot of them. The landscape of modern tabletop nerdery isn’t just defined by Napoleonic conflict, or real estate monopolies, there really is something for everyone.

    Setting up some gaming is pretty simple. Set aside a few hours, pick out a game or two, pick up and pizza or two, and get a few coworkers on board. Don’t worry if everyone doesn’t jump on board, give it a few iterations to build steam.

    Here you can take a lesson from a DevOps release strategy, if your first night didn’t achieve your results, try again with some small updates, a new game, different toppings, etc…

    Chances are someone in your office already is into games, especially in the software fields. But, if not, don’t worry it’s pretty easy to get nerds on the hook.

  • DevOps and continuous innovation accelerate the evolution of technology

    DevOps and continuous innovation accelerate the evolution of technology

    DevOps tools and principles have dramatically increased the pace of innovation and enabled the organizations that have embraced them and used them most effectively to achieve a major strategic advantage over competitors. The more the world runs and relies on software, the more DevOps can be the engine to automate and facilitate change.

    There was a time it took almost half a day to build a single car. Henry Ford managed to bring that down to two hours and 30 minutes thanks to the assembly line, but for over a hundred years most of the changes year to year in automobiles have required retooling manufacturing plants so updates and modifications are developed at a relative snail’s pace. Then Tesla came along with a car that is more or less just a framework for the software that runs on it and that can have new features and capabilities the next day through over-the-air software updates.

    John Jeremiah, technology evangelist and team lead for HP Software, was quoted in a post earlier this year saying, “It was just a few years ago when nobody had heard of Uber. Now, every single taxi company or taxi service is under pressure to react to a company that owns no taxis. Why is that? It’s because they’ve used software.”

    Tesla has an advantage over other automobiles because it can change the way its vehicles work or improve them with new features at the push of a button. Uber has an advantage over the traditional taxi industry because it has streamlined its service through a mobile app available on hundreds of millions of mobile devices and it can modify and improve the way it works with a simple update. Software has increased the ability for organizations to adapt more quickly and DevOps accelerates that evolution even faster through continuous innovation and the automation of routine tasks.

    There will still be things that require physical change—an updated vehicle frame in the case of Tesla or a new feature that relies on cutting edge technology only available in the latest smartphone models in the case of Uber. Software alone can’t do it all.

    The areas where software makes a difference, though, DevOps has a major impact. A recent study conducted by Gene Kim and a team of researchers found that organizations that have embraced DevOps tools and principles effectively have 8,000 times faster lead times and 30 times more frequent deployments than their peers. They also have 12 times faster mean time to recovery when issues arise and are twice as likely to exceed profitability, market share and productivity goals. Those are all significant statistics that impact the bottom line and separate the companies that win from their struggling rivals.

    Companies that can harness the power of DevOps and continuous innovation to develop new apps and capabilities faster and that have the capacity to push those updates out to existing customers have a significant advantage over competitors still slogging through “innovating” the old-fashioned way. It’s hard to compete with companies that are deploying 30 times faster than you and have twice the profitability and market share.

  • OCP is a victory for CoreOS and Containers in general

    OCP is a victory for CoreOS and Containers in general

    A broad coalition of major tech companies have joined forces to create the Open Container Project—or OCP. The move to develop and maintain common standards around software containers vindicates the CoreOS split from Docker and reunites the two in a common cause that will make all container platforms and technologies stronger.

    A press release announcing the Open Container Project explains the overall vision for OCP. “Housed under the Linux Foundation, the OCP’s mission is to enable users and companies to continue to innovate and develop container-based solutions, with confidence that their pre-existing development efforts will be protected and without industry fragmentation.”

    Docker and CoreOS are at the heart of OCP but they’re by no means alone. A veritable “Who’s Who” of DevOps and container technologies has enlisted to support OCP, including Amazon Web Services, Cisco, EMC, Google, HP, IBM, Linux Foundation, Microsoft, Red Hat, and VMware.

    At one point Docker had a Standard Container Manifesto that spelled out some basic attributes it felt all containers should have. The Standard Container Manifesto called for containers to operate in a standard fashion, be content agnostic, infrastructure agnostic, and designed for automation among other things. When Docker removed the manifesto and seemed to shift to a more proprietary strategy CoreOS split off and launched its own container technology to continue the vision of a container standard.

    “An open, well-defined specification is required for the overall success and adoption of containers. At CoreOS, when we started the App Container spec (appc) our goal was to have a well-designed software container specification. With the OCP, we have now come together with Docker and many industry giants in an effort to unify this goal.”

    The launch of OCP and the laundry list of companies backing it show that CoreOS was not alone in its pursuit of the vision for a container standard. “We are excited to support this effort to bring the industry together to agree on a core standard for containers, which we feel will benefit all customers no matter what cloud provider they use,” said Jason Zander, CVP, Microsoft Azure. “Through our close work with Docker over the last year we have demonstrated our commitment to openness and welcome this opportunity to help create an open platform for customers.”

    “Customers need an open, interoperable future for software containers and we are happy to see the industry coming together to establish a common standard,” explained Kit Colbert, vice president and CTO, Cloud-Native Applications, VMware. “Our participation in the Open Container Project reinforces our goal to help customers innovate more rapidly and benefit from containers as they adopt the technology in their environments. We look forward to working with the community on container portability and security which are areas of focus for enterprise IT.”

    According to the OCP press release Docker will donate the code for its software container format and runtime—as well as the associated specifications—to the project. The leadership team from the Application Container spec (appc) will also contribute technical leadership and support for OCP.

    Ben Golub, CEO of Docker, summed up by acknowledging the effort and support for OCP. “We’d like to thank the many people in the industry who came together to support this important initiative. Our thanks to the Linux Foundation for the incredible work they have done in helping to pull this broad group together. Given the criticality of the intersection of containers and operating systems, we’d also like to thank Red Hat and Microsoft for their early leadership on this initiative. Our sincere appreciation to IBM and Intel for their ongoing encouragement of open governance. Finally, we’d like to recognize the members of the appc community, including Google and CoreOS, for their willingness to join all of us to constructively address these critical issues.”

    Now that all of the major players are united in a common cause to define and maintain an industry standard for containers it will be much easier for developers and organizations to embrace container technologies without reservation. The confidence that your investment of time, money, and effort won’t be wasted or paint you into a corner is very liberating.

  • ProfitBricks shakes things up with new Docker hosting platform

    ProfitBricks shakes things up with new Docker hosting platform

    Organizations and developers that want to leverage Docker containers have a variety of cloud platforms to choose from. Rackspace, Amazon, Azure and others all support Docker containers. There’s also a relative newcomer in the mix looking to shake things up.

    ProfitBricks is an infrastructure-as-a-service (IaaS) company that believes it has a unique value proposition for companies that want to take advantage of cloud infrastructures and Docker container technology. ProfitBricks was co-founded by its CEO, Achim Weiss, and its CMO, Andreas Gauger. The two previously founded the Web hosting service 1&1 Internet.

    Weiss and Gauger launched ProfitBricks four years ago to solve a perceived problem. They saw the value of cloud infrastructure and cloud services, but felt that the existing platforms suffered in the areas of performance, flexibility, usability and cost. So ProfitBricks was born.

    ProfitBricks claims to have more speed and provide better value compared with rival cloud platforms. It calls its platform Cloud Computing 2.0.

    ProfitBricks Docker Hosting

    Docker has become a household name virtually overnight—quickly establishing itself as the de facto standard for container technology. David Bartletti, a principal analyst for Forrester, recently wrote in a research report, “Docker helps developers package code for quick assembly and hand-off to quality assurance, testing, and production release teams with greater confidence that their app will run consistently as it moves through the release process…The Docker open source community is growing quickly, with strong representation from nearly every major cloud vendor…As Docker containers proliferate, developers and operations teams alike will demand management tools that help organize and orchestrate hundreds or thousands of containers.”

    With so much momentum behind Docker and container technologies, it makes sense for a cloud infrastructure provider to integrate Docker into its ecosystem. Last week ProfitBricks announced its new Docker hosting platform. The platform features dedicated resources, redundant block storage, and 80 Gbps networking. It allows developers to choose images, link containers, and expose ports. The free tier offers customers 2,500 CPU Core hours as part of the Early Access Preview with up to 4 CPU cores, 8 GB of RAM, and 100 GB of storage.

    “When we first embarked on our Docker product architecture, we knew that it would not only need to meet the standards of existing Docker platforms, but also incorporate new, industry-leading features that addressed existing problems encountered with Docker,” said Achim Weiss, co-founder and CEO of ProfitBricks, in a press release. “Docker has been taking the DevOps world by storm since its widespread introduction to the community in 2014, and our platform will combine its impressive features with our flexible and painless cloud computing infrastructure.”

    ProfitBricks says that one thing that sets its Docker hosting apart from the competition is autoscaling. The ProfitBricks cloud infrastructure will ensure that resources are automatically managed to meet the demands of the Docker containers running on it. Developers don’t need to rely on standalone applications or custom scripts to scale resources because those capabilities are integrated seamlessly into ProfitBricks.

    ProfitBricks claims to be the best value in cloud computing. It offers a bold promise for the price / performance ratio on its site. “We guarantee that any workload deployed on ProfitBricks will cost less than the same workload running at the same performance level on the IaaS platforms of Amazon, Google or Microsoft.”

    You can check out the new ProfitBricks Docker Hosting for yourself. Visit this link for an Early Access Invite and find out if ProfitBricks can really deliver.