devopsy.kinsta.cloud

Category: Features

  • Continuous Delivery and Deployment: A Tale of Two Models

    Continuous Delivery and Deployment: A Tale of Two Models

    EnerNOC (Energy Network Operations Center) is an energy intelligence software provider with more than 1,300 employees in its Boston headquarters and international locations. The public firm helps global customers to efficiently consume energy. “Our mission is to change how the world uses energy, helping customers to improve profitability and visibility for better decision-making and sustainability by focusing on how they buy energy and when and how they use it,” says James Nichols, principal engineer and cloud architect at EnerNOC.

    A regular user of Splunk (the company uses other DevOps tools and platforms as well, including AWS and Oracle), EnerNOC has fully automated monitoring in its perpetual drive to move past continuous delivery and on to continuous deployment.

    Embedded in EnerNOC’s story of why it uses continuous development and continuous deployment models is a chapter on its move to fully automated monitoring.

    EnerNOC DevOps Models

    EnerNOC’s DevOps model is in constant transition toward full automation. Currently, it has fully automated deployment, fully automated monitoring and semi-automated quality assurance (QA), which pull the company’s continuous development approaches.

    A change to “builds on commit” of smaller applications within the legacy software monolith at EnerNOC came hand in hand with further automation, targeting what the company calls “trustworthy continuous deployment,” Nichols says. That was the crux of EnerNOC extending itself into deployment automation.

    Wherever the model is not fully automated and continuous in deployment, it remains continuous delivery. “Most of the variance between the approaches is due to aspects of the delivery pipeline that still have manual processes; these parts are usually comprised of the remaining manual testing procedures,” says Nichols.

    Change Control Necessitates Two Models

    EnerNOC develops and maintains mission-critical software that must pass through a change management approval process. This process includes communications within and across the company and customers, as well as user acceptance testing. This is where the manual testing comes in. Only at the end of this approval pipeline can EnerNOC pass the software baton into the hands of production.

    Due to EnerNOC’s tightly yoked systems and the manual testing, change control remains, along with a mix of continuous development and semi-automation with fully automated continuous deployment. “DevOps is a cultural movement as well as a technical one, and so the existing model could evolve with the organization’s quality and maturity evolutions,” says Nichols. If the manual testing and the relationships between systems give way to more fully automated testing and more amenable relationships, QA could more closely embrace full automation.

    Monitoring Challenges/Achievements

    EnerNOC’s application diversity includes hybrid software with a foothold in the Amazon cloud, in EnerNOC’s data centers and on-premises. “We use three tiers on top of Oracle in the data center. In AWS, we use a combination of big data, cloud-friendly and serverless technologies,” says Nichols. Business transaction data traverses many machines that belong to service groups’ stakeholders. “The distributed, decentralized architecture makes troubleshooting, performance management, security operations and production operations challenging,” notes Nichols. Better monitoring was the answer.

    EnerNOC wanted to offer nontechnical users easy access to systems-level monitoring data with transparency into the many systems through a single pane-of-glass dashboard with readily available system notices and troubleshooting abilities. “We would use Splunk to do this and then feedback everything we learned from using Splunk into driving our DevOps and engineering processes into the future,” he says.

    The EnerNOC DevOps performance team built the dashboard that accompanied the Splunk service, ensuring it would register the performance metrics that are of value to the organization. The performance, product management and development teams maintain an awareness of the metrics and receive the related alerts. “The development team incorporates the ongoing metrics early in the development life cycle to improve application performance,” says Nichols.

    EnerNOC first applied Splunk to web logs for operational capacity planning, then used Splunk to give the Ops team transparency into the function of its new real-time data product that was working in production. As new products came on board, the organization added them to Splunk to provide Ops teams with dashboards, at the urgent request of Ops team members.

    Current Status: All Systems Good

    EnerNOC applies Splunk to test and production systems for views into consistency and acceleration. “Splunk is our primary alerting infrastructure for low-level system metrics like CPU utilization as well as for complex business transactions that span multiple systems,” says Nichols. Splunk has eyes on application health, cluster state across machines, expected systems tasks and suspect or known-bad system behavior, as well as the presence or lack of any significant event.

  • Building DevOps Careers: One Man’s Journey, Part 2

    Building DevOps Careers: One Man’s Journey, Part 2

    In Part One of this two-part series, we introduced former SlideShare and LinkedIn software engineer Sylvain Kalache, who shared his career growth within the two companies. In this second part, we’ll look at San Francisco-based The Holberton School of Software Engineering, which Kalache co-founded to better prepare students to work in a DevOps world.

    School Founder, Still a Coder

    Kalache still uses much the same coding skills in his new role as he did as an engineer. “I still manage machines, the ones that host our website and intranet and the iMacs that students use,” he says.

    The Holberton School of Software Engineering founders removed every manual step possible, using software to automate the admissions process and any process that they could. Even in the classroom, automation rules: Computers automatically review student work on projects.

    “Computers test that students’ code works as expected by simulating user interaction, checking syntax and assessing how fast the code executes. For infrastructure in code, computers check for stability, response times and security breaches. By using multiple ratings parameters that are linked to specific skills, the computers collect detailed data about the strengths and weaknesses of each student,” says Kalache.

    “We have a lot of our own secret sauce in software automation running the school for us,” he adds. “This requires all the technical skills I used in my coding days including designing, building, configuring, testing, deploying and maintaining software and systems.”

    Teaching Methods

    The Holberton School of Software Engineering engages students in building each skill they will need for careers in software engineering through use of industry-standard teaching methods. “Methods include deep learning in building features into software products and classical teaching in clear, documented code,” Kalache says. “We have a team of 150-plus mentors who make sure our curriculum is up to date and in sync with what the industry actually does and who coach and share their knowledge with students.”

    The Holberton School of Software Engineering uses fully practical methods with no formal teachers or lectures, only mentors. “Mentors are like managers in a workplace. I mentor, coaching students in their learning journey and giving advice when there are issues,” he says.

    Students engage in peer learning, working collaboratively on software projects, which encompass the skills they will need to demonstrate in their careers. Successful completion of projects, including solo projects, is proof of attaining the required skills. “Students must defend their projects before mentors with mentors ensuring that every student can present and explain the technical aspects of the project; if even one student can’t explain it, then the group fails on that project,” says Kalache.

    “We teach problem-solving and how to learn new skills because there will constantly be new technologies and concepts for our students to understand and master in their careers in the tech world,” he adds. “Professionals who cannot adapt and retrain themselves will quickly fall out of date with technology.”

    Readying Students for Careers from Day One

    The Holberton School of Software Engineering prepares students to be ready to work when they start their careers. “Graduates of other programs whom I have spoken with have no idea what it is to ship code to production and run a production environment. They are used to academic projects that teachers correct for them,” Kalache says. “That is not how it works in the industry.

    “Even boot camps and universities provide minimal practical experience that will make job hunting difficult,” he continues. Smaller organizations don’t have the money to pay someone to learn before starting them working in production. Thus, he says, startups need to execute fast using professionals with mature skills. “Though our students will fail and struggle, they will do it at the school, which will have a much smaller impact than doing it on the job,” says Kalache. Students are exposed to creating, shipping and working with code in production for two years before graduation.

    What’s more, real, workday DevOps requires effective communications skills. “Whether it is to introduce the last tool you built, explain what happened during an outage or convince your managers that your solution to a problem is the right one, you need to have oral and written communications skills,” says Kalache. As such, the school runs students through a series of exercises in public speaking, technical writing and documentation, as well as post-mortem communications when dissecting an outage, prepping them even further for their careers and the world beyond the classroom.

  • DevOps Chat: Gene Kim, DevOps Enterprise Summit London 2016

    DevOps Chat: Gene Kim, DevOps Enterprise Summit London 2016

    I recently had a chance to sit down with author and researcher Gene Kim about the upcoming DevOps Enterprise Summit in London (DOES). This is the first DOES out of the US and Gene and team are planning to make it a great success. Below is the audio of our conversation and below that is a the transcript of the conversation.

    Of course if you are thinking about attending DOES London, you can also attend next week’s DevOps Connect: CD Summit/Jenkins Days and receive a full credit towards a DOES London ticket. A great 2 for 1 sale. BTW, Gene mentions the DevOps Enterprise YouTube channel in our discussion. Here is the link for it: https://www.youtube.com/channel/UCkyYEVVmT9vQ4yPBR4ciFUA

    Enjoy!

    Alan Shimel:                Hi, this is Alan Shimel, devopsy.kinsta.cloud here for a special DevOps chat with Gene Kim, bestselling author, researcher and DevOps personality. Hi, Gene. How are you?

    Gene Kim:                   Doing great, Alan. Oh, my goodness. How about a researcher who loves studying high performing technology organizations.

    Alan Shimel:                Okay. Hi, I’m here with Gene Kim, a researcher who loves studying high performing technology associations and writes a good book.

    Gene Kim:                   Ah, love it. So much better.

    Alan Shimel:                All kidding aside, Gene, it’s a pleasure to have you on our show again. And we’re here to talk about the upcoming DevOps Enterprise Summit, London for 2016.

    Gene Kim:                   I love it. In fact, this has been so fun. It’s our first year in London and so it’s been amazing. Sort of tapping you know the network to find great DevOps transformation stories in large complex organizations. But you know after just a lot of hard work on behalf of the entire programming committee, you know I think it’s shaping up to be just a fantastic conference.

    Alan Shimel:                Yeah. I mean I had a look earlier today at the speakers announced and you know part of me was really happy that I knew a lot of the names of who are these speakers and part of me was really happy that I didn’t know a lot of the names, right. Because you always want to hear new stories and from new people. So I think there’s something for everyone there. But Gene, you know what I’ve had the pleasure and honor of being on a program committee with you for the RSA Rugged DevOps event we do every year and so forth. But a lot of our listeners may not really understand what goes on behind the scenes and how do you get great speakers. Would you give our listeners just a little bit of like pull back the curtain a bit and talk to us about how you always come up with great speakers?

    Gene Kim:                   Yeah. You know in fact, so let me first acknowledge the amazing programming committee that we have. One of them is Owen Gartner who is part of the DevOps initiative at Barclays Capital. Ben Grinnell, he’s at North Highlands Consulting Firm. There’s Marco Swindell from Accenture. There’s Benjamin Wootton from Sendachi Consulting. And then two committee members from the U.S. DevOps Enterprise Summit, which is Damon Edwards and John Willis, who are both a part of the DevOps movement from the very beginning. So the job of the programming committee is really to shape and to kind of form the vision of the conference and shape the talks to help achieve those objectives. And I think what’s been different about the DevOps Enterprise Summit is that you know we really aim to create a vendor neutral conference that really focuses on the technology leaders who are driving DevOps transformations in large complex organizations.

    And so it means that with some rare exceptions, you don’t have a lot of the speakers from the DevOps community speaking because they’re not you know in large complex organizations. And so you know the challenge really was to find these amazing stories out there of people driving these audacious transformations in you know very conservative organizations. And you know for that you need people who aren’t just well networked in the industry and in the local market. And so you know we spent, my goodness, five, six weeks just you know scouring our rolodexes, brainstorming about all these – this is where we’ve heard about DevOps transformations going on and then actively reached out and you know vetted them just to gain some assurance that you know they weren’t just talking a good game, but they actually had _____ to show for it.

    So you know as a first year conference, you know there was just a tremendous amount of work that went into that.

    Alan Shimel:                Sure. And Gene, you know to me it’s obvious why London, right. You know when we look at our own Google Analytics here at devopsy.kinsta.cloud, London is the second biggest city from an audience perspective for us. But I’m curious, why did you pick London?

    Gene Kim:                   You know it was because that was actually one of the feedbacks that we got from our speakers and attendees, that you know because we’ve had the DevOps Enterprise Summit now going into the third year in San Francisco on the West Coast of the United States, that is a very long way to travel from people in the UK or from the European continents. So you know the ask was, hey, can you hold it somewhere in the European Union, whether it’s in the UK or in the EU. And so we were actually considering London, the Netherlands and there might have been a couple other options, but ultimately we decided to do it in London just because that’s where our network was. And when I say the network, that’s where the program committee was and that’s where I think our network was strongest. Which was very important because I think it gave us the best chance for succeeding and generating you know the right programming, the right speakers and so forth, the right transformation stories.

    Alan Shimel:                And you know what, I’ll reiterate it. London is a fantastic town. The DevOps scene there is just happening. Not to date myself and sound all groovy, but it’s a happening scene and it’s a vibrant dynamic DevOps community as well. So I think you couldn’t have picked a better place to do it in, Gene.

    Gene Kim:                   You know it’s just a huge center of economic activity. You have a huge financial services industry. You have basically every type of you know industry vertical that are operating, you know in and around London. So, yeah, I agree, it was a great – and also where so much of the progressive DevOps activity is going on within government agencies. Like the UK.gov, the UK Digital Services, all that pioneered inside the UK government.

    Alan Shimel:                Absolutely. You’re a hundred percent right there, Gene. So, Gene, listeners who are listening to this, maybe they haven’t quite decided if they want to go to does London or not. Give me right now, have all the speakers been released or announced at this point or no?

    Gene Kim:                   No. And we’re about 60 percent announced.

    Alan Shimel:                Right.

    Gene Kim:                   But I can certainly share with you the talks that I’m super excited about.

    Alan Shimel:                Go ahead.

    Gene Kim:                   You know one of them is Ron van Kemenade. You know so he is famous for his work at ING as the Global CIO. And so many of us in the DevOps community were aware of the ING DevOps Days that was held in 2011. In fact, that was probably the event that kicked off the first Target DevOps Days and the first DevOps Days at Capital One. You know it was such a novel concept. And so Ron van Kemenade as the CIO, will be talking about you know their journey when ING back in 2011 was very much like Parts Unlimited and the Phoenix Project. You know it was certainly very different from the organization they’ve become where they’ve created a world class technology organization that is widely admired. And so I’m excited that he’ll be talking about his role as the technology leader and to tell the whole inside story of how that transformation happened. And I’m particularly excited that I’ve asked him to share you know in his mind, what does it mean to be a technology leader. You know it’s not about picking Cassandra over Redis, versus Zookeeper, versus NoSQL, versus you know MySQL, right.

    So what does it mean? I think that’s not well understood and certainly not well understood by me. You know there’s a talk from Robin Hughes from LV. So that’s the Liverpool Victoria Insurance Company. So multibillion pound turnover company. So again, an organization that’s been around for over a century and you know this is just a phenomenal DevOps transformation that was really driven by the operations team. And Robin Hughes will be telling the story about how they transformed one of the largest business applications inside their portfolio and enabled developer productivity. So I think that’s great. Anthony Collard, he’s the Deputy Director at HMRC. So that’s the Majesty’s Revenue Collection. So in the US we would call it the IRS, Internal Revenue Services. And you know they have over 60 scrum teams now working to help make life better for tax payers. Whether it’s the people at home or within businesses. And it’s just an incredible story about genuine innovation and creation of phenomenal efficiencies that you know haven’t been typically associated with the way government operates.

    In fact, I was so inspired by it, I actually wanted to voluntarily pay UK taxes just to reward these amazing efforts.

    Alan Shimel:                Don’t count me in on that one, Gene. Thanks. But it’s good for you. Let me also just throw a couple of other names that I recognize and got me all excited. One is actually a friend of mine that I’ve worked with, Jonathan Fletcher over at Hiscox.

    Gene Kim:                   Right.

    Alan Shimel:                I don’t know how much you know about Jonathan, but he’s brilliant. He’s not the – I don’t want to say the suit, but he’s not the title who leads the entire DevOps transformation there. But that person relies on Jonathan to make it happen. ‘Cause I’ve looked at that organization. This guy, I love listening to him talk about what they’ve done there.

    Gene Kim:                   And it’s another phenomenal story. Another insurance company.

    Alan Shimel:                Yep.

    Gene Kim:                   And I think what makes them so remarkable, so obviously they’re a multibillion British pound turnover company. But again, over 100 years old. And yet they’re growing at 30 percent in certain market segments.

    Alan Shimel:                Yes.

    Gene Kim:                   When that’s happening its putting tremendous pressure on the technology organization, you know for them to deliver what the organization needs. And so here’s an incredible effort initiative, where they – and this one is driven by kind of an operations platform and architecture that is enabling development teams to respond quickly to the market and scale with demand. Yeah.

    Alan Shimel:                Yeah.

    Gene Kim:                   I love that Hiscox story.

    Alan Shimel:                Yeah. No. The thing about Hiscox is you know though they’re UK based most of their business is on the continent. You know they have a large presence for instance in the Caribbean as well as the Western U.S. So this is a global organization dealing with regulations and I mean its insurance. I don’t want to tell well, too much on them and Fletcher, Jonathan is a tremendous, tremendous talent. I’m sure it’s gonna translate into a great presentation. Another one Gene, that I wanted to highlight if you don’t mind me stealing a little bit from you, is Gareth Rushgrove, you know who’s at Puppet now. But you know Gareth, besides curating the DevOps weekly newsletter, you know he has a great security background like we do, Gene. And I can listen to him all day.

    Gene Kim:                   Yeah. And what’s great is that maybe not so well known is that he was part of the early UK.gov effort.

    Alan Shimel:                Yes.

    Gene Kim:                   Where he had to deal with all of the regulatory and compliance bodies inside you know a very powerful central government, as well as the intelligence agencies. And so the fact that he was able to span those boundaries and earn the trust of those agencies and essentially help define kind of the next generation of security standards and strategies, is just a really inspiring one. It’s just a really neat guy.

    Alan Shimel:                Yeah. He’s a rock star. I just wanted to mention two others Gene and they’re from DevOps San Francisco who are I guess coming over to London. And that’s Jason Cox from Disney and Rosalind Radcliffe from IBM. Just two brilliant people and I just appreciate brilliance. So you know looking forward —

    Gene Kim:                   I love them both.

    Alan Shimel:                I’m sorry what, Gene?

    Gene Kim:                   What I love about the conferences if you take a look, this is like a great cross section across you know almost every industry vertical. So you’ve got Unilever from you know the consumer goods on the financial services. You have   Barclays from _____ –

    Gene Kim:                   – insurance companies. You’ve got Pearson Publishers. News UK is another publisher. Thomas Cook Group does retailing and travel services.

    Alan Shimel:                Yes.

    Gene Kim:                   Zurich Insurance. You know actually I never realized we have so many insurance companies. So we have 26 speakers announced. You know I’ll tell you another part of the programming committee is that a lot of these we handpicked from people from our own investigation. But then we also had I think it was about 80 submissions through our call for presenters. And so you can imagine how challenging it is when you have only 25 speaking slots, of which over half had already been taken.

    Alan Shimel:                Yeah.

    Gene Kim:                   You can imagine the vigorous debate about you know which talks really need to be a part of the programming. And I just very much appreciate you know the candor and the fact that everyone had the best interest I think for the attendees in mind as we were trying to figure out how do we create the best program for the technology leadership community around DevOps.

    Alan Shimel:                Yeah. And debate is a kind word. Gene, let me –

    Gene Kim:                   Yeah.

    Alan Shimel:                – pivot a little bit ’cause we’re running low on time. So we’ve got this great lineup of speakers. We’ve hit a bunch of them and there’s more yet. But okay, if they attend DevOps Enterprise London, what are they taking out of it. Give me three bullet points. What are the three lessons? What are the three most important things they’re taking out of their attendance at this event?

    Gene Kim:                   Yeah. I think the most important thing is that they are going to hear transformation stories of organizations that look like them. So I think in the DevOps community we’re very used to hearing stories from you know Google, Amazon, Facebook, Etsy, Netflix and so forth. But if you’re in a large insurance company that’s been around for over a hundred years or a government agency that’s been around for five hundred years, you know they don’t relate very well to those unicorns. So to hear how those same type of technology transformations have occurred in large complex organizations, that is the mission of the conference is to share 30 minute experience reports where each speaker shares what business problem were they trying to solve, where did they start and why. What did they do and what were their outcomes and what do they still not know how to do and what are they looking for help with. So, yeah, I think what I’ve heard over and over again is that you know these stories, when you go to this conference you’re surrounded with people just like us, right. Or rather just like me.

    I think the second thing that they’ll hear is that they’re achieving the same sort of outcomes you know in these large complex organizations that we’ve only typically seen in the unicorn organizations. But there’s an element to me that has a tremendous amount of significance and meaning is that each one of these leaders, even though they were given some degree of air cover, I mean it’s as much true for the London conference as for the two previous conferences in the U.S. Each one of these leaders I think wildly exceeded the air cover they were given. Essentially putting themselves into some degree of personal jeopardy. And so when you ask why would they do that? What you see that each one of these speakers have in common is that if they have a sense of utter clarity and conviction that the capabilities that they’re creating for their organization are needed in order to win in the marketplace, let alone survive in the marketplace. So there’s kind of this other dimension of just the hero nature of these stories that I just find so inspiring. And it’s been an honor to help chronicle.

    Alan Shimel:                Excellent.

    Gene Kim:                   Oh, and I guess the third dimension is like to see the value they’re creating. And I would suspect that in the London conference it’s going to very much match the U.S. conferences, where we’ve observed that one out of four of the speakers at the DevOps Enterprise has gotten promoted in the last three years. Many of them more than twice.

    Alan Shimel:                What a great metric.

    Gene Kim:                   Yeah. This is a reflection of you know I think the value that they’re creating is being recognized by their organizations and they’re being asked increasingly to try to replicate that across a broader portion of the organization and help elevate the state of the practice.

    Alan Shimel:                Fantastic. Well, if that’s not enough to get them to attend to DevOps Enterprise, London, Gene, I don’t know what is. But we’re almost at the end of our time here and we’re gonna have to wrap up. I just want to quickly mention for our devopsy.kinsta.cloud audience, that we will be out there and working with Robin and Todd and the team on setting up an interview area where we’ll be doing interviews with many of these speakers when they come off stage. And much like we did in San Francisco last year and also just hearing some great insights and stories from these folks.

    Gene Kim:                   Yeah. By the way, I’m hoping you’ll post in the show notes, I actually love the devopsy.kinsta.cloud interviews that you did. And so we have them all on the YouTube channel, where you can actually see all of your interviews Alan.

    Alan Shimel:                Yep.

    Gene Kim:                   As well as all the DevOps Enterprise talks from the years past.

    Alan Shimel:                Absolutely.

    Gene Kim:                   So I think it’s just a phenomenal resource for anyone who’s interested in this topic.

    Alan Shimel:                And that’s the DevOps Enterprise Summit YouTube channel.

    Gene Kim:                   Correct. Yes. And the link will be in the show notes.

    Alan Shimel:                Fantastic. I’ll put it in there. And I’ve actually featured many of them over the months on devopsy.kinsta.cloud. You can find articles and embeds and links to it as well. But Gene, let me let you go because I probably took up more time than I was supposed to. I apologize. We’re really looking forward to a smashing DevOps Enterprise Summit in London.

  • Understand Why You’re Doing DevOps

    Understand Why You’re Doing DevOps

    DevOps has been all the rage for a few years now. It has quickly matured from a fringe concept to a mainstream imperative, and organizations that haven’t already embraced DevOps are scrambling to understand and implement it to keep up with rivals and remain competitive. Despite its benefits, though, DevOps may not be for everyone. Before diving into the DevOps deep end, you first should consider what your objectives are.

    To frame the issue more precisely, it’s not that organizations necessarily should avoid DevOps altogether. It’s just important to go into it with your eyes wide open and to understand why some DevOps projects fail. According to Andrew Storms, VP of Security Services at New Context, it’s always for one of four reasons: cultural roadblocks, failure to identify and take action on mistakes as you go, failure to learn from past mistakes and most importantly, failure to include security—either early on or at all.

    Let’s break down those four hurdles.

    Face Cultural Roadblocks

    DevOps is different things to different organizations, or even to different teams within an organization. There are many definitions of what DevOps is or is not. There is a fairly unanimous consensus, though, that DevOps is first and foremost a function of culture.

    Cultural roadblocks, Storms said, are by far the most common reason he sees DevOps fail. “It’s rarely a technical tools problem; usually there’s a disconnect between the DevOps team and executives or other parts of the organization. A concerted effort must be made to get everyone in the organization on the same page. Everyone is fighting for the same thing, but too often, they don’t realize it.”

    Fix Mistakes

    One of the outcomes of the DevOps culture shift is a fundamental change in corporate bureaucracy and the rigid processes that segregate teams and impede progress. DevOps enables organizations to work more seamlessly and produce results more quickly. It also allows issues and mistakes to be identified and resolved on the fly. “Smaller incremental changes are always easier to handle than a large monster of a release, which can include hundreds of changes,” explained Storms. “For example, teams should look for the single change in a monthly release that resulted in an unexpected security hole, instead of thinking they’ll tackle all changes with a huge release down the road.”

    Learn from the Past

    One of the most important things for business in general to help them understand is learning from past mistakes. With DevOps, it’s crucial. Organizations often only conduct investigations and postmortem analyses in the event of an issue or catastrophic failure. In that situation, the teams and individuals involved are immediately on the defensive and likely to go into “CYA” mode.

    To effectively understand and learn from the past the discussion has to be neutral and without blame or consequence. It’s a difficult concept for organizations to grasp. The key to blameless meetings is to conduct them as a regular occurrence rather than a response to a negative situation, and to foster a culture where failure is acceptable as long as it is used as a learning experience.

    Storms also suggests changing the name to “After Action Reports” to remove the negative stigma. “Postmortem implies a dead body. After Actions Reports are imperative after any event regardless of the type of outcome.”

    Start with Security

    Security is an Achilles heel of development in general, but the rapid pace of development in a DevOps environment makes it even more critical that security be integrated from the beginning. Failing to consider security is a disaster waiting to happen.

    Those responsible for security often don’t even know about a project until after it’s already in production. Storms cautions organizations, “Untested and unreviewed code or designs in production represent both a large security risk, but also a risk to the business and your customers. Security needs to be part of the SDLC (software development life cycle) and DevOps from day one.”

    DevOps is not a silver bullet. Nothing is. There are a variety of unique advantages and benefits that come from successfully embracing DevOps, but to realize them you need to start with a clear understanding of your own objectives, and how DevOps can be leveraged to help you achieve them.

  • Jenkins Creator Kohsuke Kawaguchi (KK) at DevOps Connect: CD Summit Dallas

    Jenkins Creator Kohsuke Kawaguchi (KK) at DevOps Connect: CD Summit Dallas

    I haven’t written much about some of the great content and sessions that have been held in our DevOps Connect: CD Summit/Jenkins Roadshow. We have held them in Dallas, Chicago and Boston. Each event was different, but all featured some tip top speakers. One of the “regulars” at our events has been Kohsuke Kawaguchi or KK as the Jenkins world calls him. KK is the CTO of CloudBees and the creator of Jenkins. He is also one of the more intelligent people I have ever had the pleasure to meet. On top of this his humble nature only enhances his overall stature. I wanted to post a short interview I did with KK at the Dallas DevOps Connect: CD Summit/Jenkins Days. We hope to have his full keynote available on our DevOps TV YouTube channel soon as well.

    Below is the the video of my interview with KK and below that is a transcript to read along as well. Also a quick reminder next week (May 23 & 24 and May 25) we are in London and Stockholm continuing this fantastic road show. Next fall we will be in 8 or 9 more cities as well. Check out DevOpsConnect.com for dates.

    Alan Shimel:                Hi, this is Alan Shimel, editor in chief at DevOps Connect CD Summit Jenkins Days in Dallas. Happy to be joined by KK, the founder of Jenkins and CTO of CloudBees. KK, thank you.

    KK Kawaguchi:          Oh, thank you very much for having me.

    Alan Shimel:                Thank you – well, it’s our pleasure to have you, but you are just coming out of the Jenkins track that you delivered, which was a very technical track on Jenkins and your keynote this morning was on continuous delivery pipeline and we spoke about Jenkins 2.0 as well as local Jenkins as a service and Jenkins certification. And what was the last one where we give you the whole package that we’re going to not certify, but what was the word?

    KK Kawaguchi:          So you call that the CloudBees Jenkins platform, private label solution basically.

    Alan Shimel:                Absolutely. So, for our listeners who weren’t lucky enough to be here, can you – I’m not going to ask you to do the whole 45 minutes, but can you give us a – just in five minutes, sort of the highlights of each, of what we spoke about?

    KK Kawaguchi:          Yeah, so Jenkins version two, like, we are trying to move to dial  in three key areas. The one is the continuous delivery through the pipeline of code, so we want people to be able to define this choreography of orchestration, AKA, the continuous delivery pipeline as a series of text files. And then they can put that into version control system and monitor them well. So that’s one of the sort of key features in Jenkins 2.0.

    The second one is this more curated out of the box experience. So we want new people who are starting Jenkins today or tomorrow to start with this 80 percent, like a richer set of functionality that represents the 80 percent of the use cases so they have right out of the box, they get something useful and they can get a lot of mileage from. And then at some point, they would start leveraging this great ecosystem in Jenkins. So that’s this out of box experience is the second part.

    And then the third one is some of the GUI improvements. You know, Jenkins is something people will use every day, so we wanted to make sure that we keep up with this progress in the frontend technology. So that’s something we’ve been doing. So those are the three key pillars to the new release.

    Alan Shimel:                And I think you said that fingers crossed, we’re looking at the Jenkins 2.0 or CloudBees 2.0 in the end of this month?

    KK Kawaguchi:          Yeah, so the Jenkins 2.0, we are – we’ve been working on this for a good while now and we are at the final home stretch. Today is actually the release candidate day.

    Alan Shimel:                Really?

    KK Kawaguchi:          Yeah, and then in two weeks, if nothing bad shows up, and that’s the part where I’m crossing fingers, nothing bad shows up, in two weeks, we are shipping the 2.0 GA.

    Alan Shimel:                So as you mentioned in your keynote, as someone who started this as a little project for your three, four man team inside, I imagine there’s a tremendous amount of price in seeing what this has become and –

    KK Kawaguchi:          Yeah. Yeah. Little did I know that the itch that I was scratching was shared by so many other people.

    Alan Shimel:                Yep, hundreds of thousands, really.

    KK Kawaguchi:          Yeah, exactly.

    Alan Shimel:                What was the number, 100,000 active installs, 400,000 computers?

    KK Kawaguchi:          Yes, that’s right. I think the exact number I believe I think is 120,000 or something, but there’s a massive number of people using Jenkins to, I guess to help move their – to help deliver software faster and I’m really proud of being a part of that.

    Alan Shimel:                Fantastic. KK, one last question. Many of our listeners and readers out there, they’ve heard of Jenkins. They’ve heard of continuous delivery. They may not know how to get started with it. For someone just looking to get started, what’s the best way?

    KK Kawaguchi:          Right. So if you are really new to the whole, you know, whole CICD, then I think that the very easiest place you can start is, well, you know, the install Jenkins, it’s really easy to just really get it installed or you have it installed and so you can start one up and then you put the – like an automated build up on every commit.

    So, everyone already has a build screen because that’s going to run that every time someone commits a change, even something that simple, which only takes like 15 minutes, it’s going to pay a lot of dividend.

    And then once you get this idea across to your team that well, a little bit of automation helps, then you can like incrementally go a little bit by little bit over time. So next step might be running tests. Maybe that could take a lot of, you know, multiple phases. And then that’s how I start on the, like, how Jenkins spreads inside some microsystems is really where that came from. That’s how Jenkins got into so many places and that’s how people are doing it, one thing at a time, sort of a little bit over a little bit.

    Alan Shimel:                Excellent. KK, thank you so much for your time. Thank you for sponsoring, CloudBees for sponsoring our CD Summits and we look forward to seeing you in future CD Summits as well as Jenkins 2.0.

    KK Kawaguchi:          Yeah, thank you very much and me too.

    Alan Shimel:                Thank you. This is Alan Shimel for devopsy.kinsta.cloud.

  • Building DevOps Careers: One Man’s Journey, Part 1

    Building DevOps Careers: One Man’s Journey, Part 1

    In 2011, Sylvain Kalache was a software engineer at SlideShare, which LinkedIn acquired in 2012. Kalache was a senior systems reliability engineer (SRE) at LinkedIn, doing project management and planning, documenting and sharing knowledge tools, and adapting himself and his work to the LinkedIn organization and its technology.

    Today, Kalache is helping build DevOps careers as co-founder of Holberton School of Software Engineering in San Francisco, where students learn to code through “project-based and peer learning,” according to information from the Holberton School website.

    This is Kalache’s DevOps career story, how he worked in and then transitioned from a career in DevOps to a personal and professional investment in helping students to build their DevOps talents toward a lifetime of coding and contribution in software engineering and, hopefully, successful careers.

    Software Engineering at SlideShare

    “SlideShare was a very small company when I joined. The San Francisco office had only 10 people; I was only the second engineer at that location,” says Kalache. But the DevOps mindset was strong there, he says, and the company had bet everything on DevOps methodologies. In fact, it was the commitment to DevOps by SlideShare and its CTO at the time, Jon Boutelle, from which Kalache learned of the development approach and took to it so quickly.

    “Boutelle was looking for full-stack or aspiring full-stack engineers and I was a junior programmer and eager to learn. In a small company like that where you are encouraged to work on every aspect of the product life cycle, it became very clear that I was in charge of taking care of my mistakes,” says Kalache, adding SlideShare expected him to take ownership of his code from design to production.

    “Because I was eventually in charge of a lot that was going on with the infrastructure at SlideShare, I had to build and maintain a lot of systems that were serving billions of slide views per month at what was one of the top 100 most visited websites in the world,” says Kalache.

    People from the Dev and Ops teams there did not only their own work, but also the work of their companion team. In essence, Dev was both Dev and Ops and, likewise, Ops was both Ops and Dev.

    “The SlideShare people were writing their own configuration management code, setting up monitoring of new services and features as they built them, deploying their own code, and troubleshooting code in the production environment,” says Kalache. Ops people helped developers design sound code for acceleration while also giving their code a second look to ensure fitness for operations.

    Project Skynet

    “The most exciting project I built for SlideShare was Skynet, an automated tool to monitor, scale and auto-heal a system in the cloud,” says Kalache. Skynet was developed to meet several challenges in the day-to-day work of simply being SlideShare and doing what SlideShare does. SlideShare acted on, renamed and translated countless files from one type to another to share them on the site. As with other slide technologies, the tool was a fit for teaching and presentations.

    There was no way to know exactly how much users would upload, access or view any slide content at a given time. “There were peaks and valleys in upload traffic with mornings seeing high traffic and low volumes in the evening and on weekends. The SlideShare infrastructure had to scale quickly to encompass and convert common document files at speed. This required adding many hundreds of machines to the infrastructure,” says Kalache, which were virtual  machines that spun up in minutes in the AWS EC2.

    One purpose of Skynet was to enable precise analysis of log files for transparency into everything from individual file conversions to changes in the entire machine cluster as the environment scaled up or down. The other purpose of Skynet was to use the analyses to auto-heal; in other words, to restore the cluster back to its initial size once the peaks were over.

    With many thousands more employees at LinkedIn than at SlideShare, Kalache left many of his duties at SlideShare to others while he dove much more acutely into specific aspects of his work.

    Co-Founding a School That Builds Careers

    In speaking with his colleagues and representatives from various enterprises, Kalache continually confirmed that organizations using DevOps are in need of lots of engineers but they can’t find candidates who are knowledgeable and experienced. “I was actually recruiting for SlideShare and for LinkedIn. What saddened me was to see a graduate who had just spent half a decade and a lot of money on a master’s degree only to be far from employable,” he says.

    Kalache found it hard to find people who knew basic software engineering, DevOps, and how to be an SRE for LinkedIn. “We instead had to hire early graduates who had coding skills and an interest in operations and train them on being an SRE,” he says.

    Kalache decided to combine an awareness of alternative teaching methods with his passion for the coding and ops communities to find a solution to how to better prepare software engineers for careers. “After mulling it over for two years, I decided to quit my job at LinkedIn and create the Holberton School,” says Kalache.

    In Part Two, we dive headlong into the teaching and learning experiences at the Holberton School of Software Engineering to help students learn and understand the DevOps methodologies and increase their chances for success in their respective careers.

  • Scaling Collaboration in DevOps

    Scaling Collaboration in DevOps

    Those familiar with DevOps generally agree that it is equally as much about culture as it is about technology. There are certainly tools and practices involved in the effective implementation of DevOps, but the foundation of DevOps success is how well teams and individuals collaborate across the enterprise to get things done more rapidly, efficiently and effectively.

    Most DevOps platforms and tools are designed with scalability in mind. DevOps environments often run in the cloud and tend to be volatile. It’s important for the software that supports DevOps to be able to scale in real time to address spikes and lulls in demand. The same thing is true for the human element as well, but scaling collaboration is a whole different story.

    Collaboration across the enterprise is critical for DevOps success. Great code and development needs to make it over the finish line to production to benefit customers. The challenge organizations face is how to do that seamlessly and with as much speed and automation as possible without sacrificing quality or performance. How can businesses streamline code development and deployment, while maintaining visibility, governance and compliance?

    Emerging Trends

    First, I want to provide some background and share some data gathered by 451 Research on DevOps and DevOps adoption in general. Cloud, agile and DevOps capabilities are important for organizations today—both in perception and reality. 451 sees enterprise adoption of these things, as well as container technologies, growing—including increased usage in production environments.

    There are a number of advantages to embracing these technologies and methodologies, such as increased flexibility and speed, reduction of costs, improvements in resilience and reliability, and fitness for new or emerging applications. According to 451 Research, organizations also face some barriers including a lack of familiarity and required skills internally, the immaturity of these emerging technologies, and cost and security concerns.

    In the “Voice of the Enterprise: SDI Q4 2015 survey,” 451 Research found that more than half of the respondents (51.7 percent) consider themselves to be late adopters, or even the last adopters of new technology. The flip side of that is that almost half (48.3 percent) label themselves as first or early adopters.

    Those general sentiments are reflected in the survey responses to other questions. When asked about implementation of containers, 50.3 percent stated it is not in their plans at all, while the remaining 49.7 percent are in some state of planning, pilot or active use of container technologies. Nearly two-thirds (65.1 percent) indicated that they use agile development methodologies for application development, but only 39.6 percent responded that they’ve embraced DevOps approaches. Nevertheless, while agile software development has been in the industry for years, 451 notes the impressive adoption of containers and DevOps, given they are emergent trends.

    When asked what the top three IT pain points are, the leading responses were cost or budget, insufficient staff and legacy software issues. As organizations move to cloud, DevOps, and containers issues such as these will need to be addressed, along with how to scale both technologies and collaboration effectively.

    The Current State

    The industry—driven in large part by the DevOps revolution—is in the midst of a sea change, where software development is becoming more highly integrated across the entire business. The creation of software is less segregated and is more and more a function of collaboration and socialization.

    Concepts and methodologies that were novel or niche just a few years ago have matured quickly to become the mainstream technologies and frameworks that are driving value today. Businesses rely on concepts such as agile, lean, virtualization, cloud, automation and microservices to streamline development and enable them to work more effectively and efficiently at the same time.

    To adapt and evolve, enterprises need to accomplish a number of key tasks. The challenge companies face today is how to accelerate development while reducing costs. Organizations need to eliminate the barriers that exist between IT and the rest of the business, and work cooperatively toward a strategy that provides more effectiveness in a technology-driven, competitive environment.

    Agile, cloud, DevOps and containers all play a role in that process, but the one thing that binds it all is effective collaboration. Each of these technologies and methodologies provides unique benefits, but the real value comes from the organization as a whole—and the tools and platforms used by the organization—being able to collaborate at scale. Successful DevOps implementations also require participation from other stakeholders beyond development and IT operations teams, including security, database, storage and line-of-business teams.

    Collaboration-as-a-Platform

    There are services and platforms online—such as GitHub—that facilitate and streamline collaboration. The online platform functions as a code repository, but the value extends beyond just providing a place to store code.

    Such a collaboration platform helps developers and teams collaborate more effectively because it provides a community where the code and process can be shared and discussed. Managers can monitor progress and track what code is shipping next. Developers can experiment with new ideas in a safe environment before taking those experiments to a live production environment, and new ideas and experiments can be effectively communicated to the appropriate teams.

    One of the keys to more agile development and DevOps is to allow developers to test things and gather relevant feedback quickly. The goal is to produce quality code and features faster, not to waste time setting up and managing infrastructure or scheduling more meetings to talk about it. The GitHub platform, for example, enables more effective and scalable collaboration because code review can occur when it is most convenient for the participants. There is no need to try and coordinate and schedule code review meetings, so the developers can continue to work uninterrupted, resulting in greater productivity and job satisfaction.

    Steven Anderson of Sendachi noted that GitHub is a collaboration platform, but it’s also a place for your tools to work with you, too. This means it can help not only with collaboration and continuous integration, but also with code quality.

    One of the benefits of a collaboration platform is that large teams of developers can be broken down into smaller teams that can focus more efficiently on specific components. It also allows things such as document sharing alongside code development to blur the lines between technical and non-technical contributions and enable increased collaboration and visibility.

    Collaboration is Key

    The importance of collaboration can’t be stressed enough. It is a key tenet of DevOps culture, and it’s vital to agile development and maintaining a competitive edge in today’s world. Executive or management support and internal evangelism are important. Organizations also need to embrace the culture shift—blending skills across functional areas toward a common goal.

    With that culture established, though, effective collaboration is crucial. A collaboration platform is an essential element of collaborating at scale because it streamlines productivity and reduces redundancy and effort, and yields higher quality results at the same time.

  • Salvador Partners Bridges Global Gaps for DevOps

    Salvador Partners Bridges Global Gaps for DevOps

    Salvador Partners works on a global scale to help its customers grow their business. The company, which has its own set of products, also focuses on assisting startups in making their vision reality. Indeed, it bills itself as “experts at innovation and exploiting innovation.”

    The company started life as a subcontracted electronic components manufacturing company, slowly broadening its lineup to include security products and patents and evolving to become a provider of technology for banking, financial services (fintech), defense and mechanical systems, says Lewis Daniels, founder of Salvador Partners. The company also serves as an incubator and capital arm for new technologies.

    Salvador builds circuit boards and technology products, working across artificial intelligence (AI), augmented reality and blockchain technology, together with its other endeavors. Across its projects, wherever software is part and parcel with its products, Salvador Partners’ international team of developers are hard at work.

    The firm has built a DevOps culture across its organization despite geographical and language barriers. devopsy.kinsta.cloud explores the Salvador Partners devops culture that works in an umbrella fashion among these international developer groups.

    The Global DevOps Culture Challenge

    Salvador Partners works with development teams in Russia, China, India, the U.K. and the United States who build software prototypes, which can sometimes prove tricky: There are challenges to getting foreign teams to plug themselves more deeply in to existing domestic teams for future projects. “There’s an obvious value in their experience from the build of your prototype that you then want to tap. The question is whether they want to be a part of your longer-term vision,” Daniels says.

    The company also grapples with the location question—whether to consider moving some of its operations to those countries, closer to those teams, or move some or all of them to its domestic operations. “Perhaps the world has become small enough through the use of tools like Slack and [project management] tools that you can let the technology bridge any gaps,” says Daniels. The tools so far have helped disparate development teams make the leap, including addressing any time zone and language issues that appear.

    Delineating the Salvador Partners Culture

    Salvador Partners uses an agile approach. “If each client wants a unique tweak, we simply badge up a boutique offering where we can innovate, collaborate and deploy in an agile environment to suit the client requirements,” Daniels says.

    As development teams work together more frequently, they reuse code and proven approaches more often. “We often find tricks that get carried over to the next application or dashboard,” says Daniels.

    Tools are the answer. “Things have changed in recent years. In terms of a culture, I think it’s pretty easy to leverage tools such as Slack and Dropbox to make the team smaller, regardless of where in the world they are positioned,” he says.

    Salvador Partners developers also use Trello for sharing project plans and Skype and Uber conference for team collaboration calls. “We use a secure mobile app we developed internally to communicate on some of the new, high-tech or sensitive topics. WeTransfer is also pretty useful for sending larger files,” says Daniels.

    Though Salvador Partners looks at its DevOps culture as a whole rather than by region, there are some unique, regional aspects. “We have a real good team based in India and they just go get things done, whereas some of their counterparts we use sometimes get caught up in planning the plans. This can make it difficult to pull a number of pieces of a project together,” says Daniels.

    Other Solutions to Challenges

    Locations, languages and distances present other challenges as well. Because some projects work with encryption protocols that by law can’t be shared beyond certain countries, the development work can happens only inside the U.K., the United States, Australia, Canada and some European countries, Daniels notes. In these cases, the company simply keeps the work internal, within the countries permitted.

    Language barriers can also present issues. “Such was the case where Salvador Partners had Canadian companies working on something and had a French speaker cause a few problems for his English-speaking colleagues,” Daniels says. For language challenges, the company simply whiteboards the project or uses translators.

    Time zones can also trip things up. “It creates challenges when you have a New Zealand head office dealing with partners in Singapore and developers in Russia and California. We have had conference calls where participants are going for dinner and at the same time another having their first coffee,” Daniels says.

    However, time zones and geographies are less an issue as the available toolsets to solve communications barriers have evolved.

  • London Calling: DevOps Enterprise Summit and DevOps Connect: CD Connect/Jenkins Days, 2 for 1

    London Calling: DevOps Enterprise Summit and DevOps Connect: CD Connect/Jenkins Days, 2 for 1

    As is to be expected from a world capital city, London is also a hotbed of DevOps adoption. The local London DevOps community is thriving with a near constant stream of DevOps conferences. There are however two great events coming up that are can’t miss. DevOps Connect: CD Connect/Jenkins Days in May and Gene Kim’s DevOps Enterprise Summit in June are both in London. Now you can attend both for the price of one!

    Right now due to the devopsy.kinsta.cloud sponsorship of DOES London and the generosity of the sponsors of both events, if you sign up for the full £179 two-day ticket for DevOps Connect: CD Summit/Jenkins Days you will receive the full £179 back in the form of a credit towards your ticket for DOES London. You wind up attending CD Connect/Jenkins Days for free!

    So what do you get from attending DevOps Connect: CD Summit/Jenkins Days and the DevOps Enterprise London? Glad you asked. Let me give you some of the highlights to look forward to.

    First DevOps Connect: CD Summit/Jenkins Days:

    1. Two-day event, day one features keynotes and three tracks, plus lunch, refreshments, exhibit area and demo theater.
    2. Day two of the event are deep dive workshops on Jenkins, DevOps Transformation, automating deployment in Hybrid Clouds, DevOps Foundation and DevOps Lift off and the Nexus World Tour: Rugged DevOps Heroes Assemble. You can pick and choose which of these workshops to attend, there is on price for admission to all of them.
    3. The event is being held at the KIA OVAL, KENNINGTON OVAL,SE11 5SS LONDON, UNITED KINGDOM.
    4. The keynote and headline speakers for the event are pretty amazing:

    sacha-laboureySacha Labrourey, CEO and Founder CloudBees, former CTO JBoss speaking on “Why Jenkins Has Become the Engine of Continuous Everything.”

     

     

     

    sanjeevSanjeev Sharma, CTO & Distinguished Engineer for DevOps, IBM on “Adopting DevOps at Enterprise Scale.”

     

     

     
    garyGary Gruver, Author of “Leading the Transformation”, Previously executive IT positions at Macy’s and HP, speaking on Leading the Transformation: “Applying Agile and DevOps Principles at Scale.”

     

     

    After this great morning of keynotes, there are three tracks all full of great speakers and topics after lunch.  You really don’t want to miss this event and if you were planning on going to the DevOps Enterprise Summit London, you can go to CD Summit/Jenkins Days for free.

    Why go to DevOps Enterprise Summit London? Well if you want to hear about the experiences of large enterprises in adopting DevOps, there is no better place. In the previous two Summits held in San Francisco, Gene Kim and team have done a great job of shining a light on “horses” DevOps transformations. This first London edition of the franchise promises to be equally as great. It will be held at the Hilton Metropole in London.

    Some of the speakers scheduled to present include:

    geneGene Kim, Author, Researcher and Founder of IT Revolution.

     

     

     

    gareth

    Gareth Rushgrove, Senior Software Engineer, Puppet.

     

     

     

    jasoncox

    Jason Cox, Director, Systems Engineering, The Walt Disney Company.

     

     

     

    This is just the tip of the iceberg really. There will be over 25 speakers at DOES London, as well as community space, breakout sessions and more.

    While London has more than its share of DevOps events, I am not sure it has experienced the likes of these two events before. Please don’t miss them and look forward to seeing you there.

  • Why Is There No DevOps Manifesto?

    Why Is There No DevOps Manifesto?

    Let’s start with a brief story:

    There’s a scene in a movie called “A Few Good Men” in which a lawyer is questioning a cadet. The lawyer directs the cadet to turn to the page in the thick Marine Code Manual that explains where to find the canteen. And the cadet replies, it isn’t in there.

    And the lawyer says, “Well, you eat, don’t you?”

    And the cadet says, “Yes, sir, three times a day!”

    The meals for everyone aren’t served by the book because the canteen isn’t included.

    This isn’t a history for the term DevOps or of the many people who’ve led, presented, written and interviewed about the DevOps movement. I’ve got a footnote below with some pointers for that. This is simpler than that: It’s why today there is no DevOps Manifesto and why I don’t think there will ever be.

    Now, I think I understand the desire for a DevOps Manifesto. I’ve met a lot of folks, company executives and analysts, who still dis DevOps a bit because it lacks a certified definition, an official manual or a definitive statement. Basically, a manifesto; you know, a canonical thing you can put on a shelf.

    Manifestos can be nice. They lay down the vision, the intent, the mission. They can appeal to a wide range of people, from revolutionaries to functionaries to dignitaries. It isn’t for sparking conversations so much as for orderly setting down of intent. A manifesto can bake in the meaning and content of something.

    A manifesto has that “rule of law” book feeling to them. Manifestos also have provenance and pedigree—some group of some renown sat down to discuss some topic for some specific resolutions and wrote the sum of it up. Manifesto wording can be checked to ensure real-world compliance.

    You can almost slap a copy of a Manifesto on a table to settle an argument about the manifesto’s topic. And assuming the words were crafted carefully enough, it will be the end of discussion. And that’s exactly the problem with a manifesto with respect to DevOps.

    I say: That’s not what DevOps is about.

    DevOps begins with stopping the nightmare scenario pitting Ops against Dev—or any other part of the organization. But it comes so much further. It’s for a new age of computing at webscale, using tools, teamwork and techniques to get to better, happier, more engaged outcomes for customers. Some of it is so new we are still figuring out words for it.

    The DevOps movement isn’t slowing down, either. Analysis of the Google results page shows it:

    DevOps searches over time Sep2015

    In all of this time, no one of any significance in the community has attempted to create a “manifesto for DevOps.” I’d say the Godfather of DevOps himself, Patrick Debois, was super insightful on how he went about ensuring no official manifesto could get written. (I’m not going to review the lessons learned from “The Agile Manifesto,” although good lessons were learned from the things created in the wake of having an Agile Manifesto.)

    If you have a manifesto for something, then all conversation in the domain will, rather quickly, go back to the manifesto for resolution instead of everybody working together. That’s not handy in an ever-fluid, often on-fire, scale-up fast, resilience-oriented, rapidly changing and evolving IT situation.

    As Andrew Clay Shafer (@littleidea) said recently, DevOps is about optimizing for people. With the pace of IT and tech ever accelerating, no manual or manifesto could keep up. Which reminds me of one of my favorite quotes:

    Companies die because their managers focus on the economic activity of producing goods and services and they forget that their organization’s true nature is that of a community of humans.

    — Arie De Geus

    One thing you should know for sure about DevOps: The community likes to enhance, educate, enliven, inform and energize people. Basically, everyone is wide open to embracing anything that helps out because webscale is hard. So yeah, DevOps now aligns with “microservices” because microservices can further the DevOps cause. Just like kanban, Docker containers, automated configuration and InfoSec. And anything that enables Dev and Ops to deliver more, better, faster to customers. It’s about serving the customers.

    Meanwhile, if you’re looking for more, you’ll usually find a bunch of folks … figuratively speaking … over in the kitchen at the canteen, serving up awesome and working hard on doing it better and faster.

    And everyone interested is welcome to sit down and enjoy what’s served.

    Seriously. Join in. You do not need a manifesto to.

    P.S.  It was with deep hesitation that I wrote this. There are simply so many awesome people who’ve made all this happen and I am not one of them. Literally the finest collection of technologists—and in many cases, human beings—I have the honor to know who make this community what it is.

    You should check out, in no particular order:

    • The amazing (and amazingly modest) Patrick Debois
    • The writings and teachings of Mark Burgess (one of the most under-recognized geniuses I have encountered)
    • The CALMS write-ups by John Willis (@botchagalupe) and Damon Edwards (@damonedwards)
    • Damon’s five-minute video on DevOps history
    • John’s frank exploration of the issue of burn-out in IT (and that is directly related to why we are having DevOps conversations)
    • Mary Poppendeick’s lean development work
    • John Allspaw and John Hammond’s 2009 Velocity keynote that sorta kicked this whole thing off
    • Ben Rockwood’s (@benr) comprehensive LISA11 keynote
    • The many videos of Andrew Clay Shafer (@littleidea) and his brilliant guidance. Sometimes with katana and sometimes with gattling gun.
    • Jez Humble’s books (particularly “Continuous Delivery” and “Lean Enterprise”)

    And works from folks including:

    • Jeff Sussna (@jeffsussna)
    • James Turnbull (@kartar)
    • Adam Jacob
    • John Vincent (@lusis)
    • Bridget Kromhout
    • Adrian Cockcroft
    • Gareth Rushgrove
    • Kris Buytaert
    • J. Paul Reed
    • Ernest Mueller
    • James Wickett
    • Ines Sombra
    • Karthik Gaekwad

    I mean, this is a global phenomenon, were you expecting a short list? This isn’t even complete!

    Oh, and the VisibleOps guru Gene Kim, who came and showed us all a way to really blow the doors off the DevOps news.

    These people are helping all of us do better Dev, better Ops, better IT, better business so that you can have better customers. It’s amazing. It really is. And it’s wonderful.

    Also, if you get a chance to spend time at a DevOps Days anywhere, you should.