Tag: devops automation

  • Start Automating Now

    Start Automating Now

    A bit of feedback I received from last week’s post is that I didn’t provide any background, I just jumped right in with examples. So let’s take a step back and talk about the bigger picture.

    It is always a surprise to me when I talk to enterprise friends and associates and hear that automation has not taken over their DevOps processes. Yes, we still (and might always) want the ability to have a person review what is being done and make course corrections if the automation has something wrong, but most of the automation that is available for DevOps is no longer new and should be a no-brainer.

    The ability for a build to block based upon any given criteria and notify Jira or ServiceNow—or whatever issue tracking system you use—while alerting the people responsible for the build is simply obvious … and yet, some organizations aren’t even that far yet. The ability to stop a build, create a ticket, assign it to the appropriate person and give it a priority is built into most of these products. It should be looked at to see if it’s suitable to the organization.

    This goes on and on. We’re now to the point where everything in the toolchain can be automated. IaC and GitOps are tackling the broad operations end, and if the application is 100% public cloud-based, CloudOps simply solves the problem. Automation from check-in to production is possible, with very few places where intervention from humans is needed.

    Given that most of this technology is mature—even though some of it has not been around as long but has broad enough adoption that it can be considered mature (Flux and Argo come to mind here)—it is time for enterprises to start another round of automation. Just like AI won’t eliminate most development jobs this year, automation won’t eliminate jobs, either. But we’ve been so strapped for time for so long that this may be a surprise. Automation might reduce the need to scramble for new team members while asking current employees to give a bit more … over and over.

    So get started. The math that made DevOps appealing in the first place—streamlining to reduce time to market and free up IT hours—is the same math that applies to the current round of automation. The more that can be automated, the more time team members will have to perform more productive work.

    Having mentioned AI in passing, I’ll use that as a segue to include AI in the “automation” discussion. At this time, nearly all of the tools we call AI are simply advanced automation tools and should be considered in the process of increasing IT automation. The ability for an app to run, learn your systems and improve them (be that improvement in development, security or ops) is just advanced automation. In the places where it works well in a given environment, it should be adopted. It is highly unlikely that AI will get worse over time, so even marginally acceptable AI results make it worth implementing, counting on technology advancements and continued training to improve that benefit moving forward.

    So, start automating now. Free your time, take a holiday at the beach, do the same job in less time or, to quote a previous generation, “Work smarter, not harder.” You’re doing the job that keeps the servers humming and users coming, now do it with less effort. And keep rocking it.

  • Building Amazing Apps, Part 2: Optimizing the Back End

    Building Amazing Apps, Part 2: Optimizing the Back End

    This is part two of a series of three articles on building and delivering amazing apps at the edge. To read part one, click here.

    There are millions of apps available today, and it’s incredibly easy for any user to download and install any of them with just a few taps on a screen or click of a mouse. If you want to build and deliver an app that will amaze users, you need to be able to differentiate from the rest of the pack.

    Over the past 14 years, I’ve been working closely with the top companies delivering the most popular apps, helping them optimize their apps for speed and scale so users get a great experience. In this three-part series, we’ll explore the fundamental steps you must take to build and deliver your own amazing app at scale that will keep users coming back for more.

    We’ll break these steps down into three key areas:

    • Front end: Covers the parts of the app that end users interact with.
    • Back end: Looks at the required origin infrastructure to support the app, including databases, application, web servers and more.
    • Middle-mile: Explores the internet, where all the information needs to traverse back and forth between the front end and back end.

    In this article, we are going to explore five things you can do on the back end.

    Distributed Architecture

    In a nutshell, distributed architecture means having origin (back end) infrastructure that is geographically dispersed to maximize availability and performance.

    There are three main types of back end configurations:

    • On-premises: This is where the hardware and software are owned and managed by your organization. This type of back-end architecture is often more expensive and resource-intensive to maintain but offers a higher degree of security and flexibility because you have full control of the hardware and software.
    • Cloud-hosted: This is where the hardware and software are hosted on a third-party cloud provider. This type of architecture runs on dedicated or multi-tenant servers, and is usually more cost-effective to create and manage because some of the cloud providers include efficient infrastructure configuration/orchestration tools.
    • Hybrid: This is where your architecture is a mix of on-premises and cloud-hosted. This is the most flexible and common solution, since most companies that traditionally have relied upon all on-premises architecture are slowly migrating some of their back end to the cloud. For this type of solution, it’s best to use open source, multi-cloud tool solutions.

    The goal for your configuration should be having a back-end system that is geographically dispersed enough (with most locations close to your users) to ensure low network latency, while at the same time avoiding a single-point-of-failure to ensure the service runs, despite any localized outage.

    Regardless of your configuration, the general idea of distributed architecture remains the same: Using data centers where the load is distributed via a global load balancer, and where critical information is replicated across the data centers via fast, fiber-optic private links.

    Here are some concepts you can research that will help you to choose the most optimal, distributed architecture for your needs: virtual machines, containers, microservices, data replication, stateless apps, serverless, distributed processing, etc. devopsy.kinsta.cloud is an excellent resource to learn more about them.

    Generally speaking, you can simplify your origin infrastructure and maximize end-user performance by putting a content delivery network (CDN) between your end users and your back end. A CDN is a super-distributed network of reverse proxies that allows you to put your content very close to end users, minimizing network latency to achieve rapid app interactions, especially when the CDN caches your content on its edge servers.

    Auto-Scaling

    You can optimize costs and performance by choosing an architecture that auto-scales (up and down) depending on current traffic demands. To implement this effectively, you need to monitor global traffic and set triggers that launch infrastructure on-demand so it is ready when needed. Most of the largest cloud services companies support auto-scaling services, and some of them even allow you to tune your settings to favor either costs or performance. One of the easiest ways to implement effective auto-scaling is with CDNs, which can automatically scale traffic with minimal effort just by configuring a set of rules that define what content should be handled completely by the CDN (either dynamically generated at the edge or cached) and what content should be pulled from your origin infrastructure.

    Continuous Monitoring

    Continuous monitoring helps maintain the quality of service. There are many open source tools for continuous monitoring that fall mostly into the following four categories:

    • Infrastructure monitoring: This allows you to keep track of compute resources, storage, network usage, etc.
    • Cloud providers: Most of the largest cloud providers have integrated tools for monitoring your back end in each respective cloud platform.
    • Application performance monitoring (APM): To monitor your application’s framework.
    • Aggregators: Tools that allow you to aggregate and analyze data across several monitoring tools.

    In addition, it’s a good idea to complement server-side monitoring with real user monitoring (RUM) tools to identify whether a specific code deployment impacts performance.

    Performance

    A faster back end makes for a faster front end, and, as we know from part one of this series, performance is a major contributor to user experience. In addition to focusing on improving metrics including latency, throughput and errors (all of which are directly correlated with back-end performance), it’s critical to have a “culture of performance” in your company. José Pérez provides an overview of that concept in his article, “Fostering a Web Performance Culture.” This is a perfect example of how you could implement a culture of performance in your organization, by having performance tools integrated into your IDEs—this can provide instant feedback to developers on how new code performs against a defined performance baseline so that any code that might degrade performance is identified before it is deployed.

    For content that is not personalized, such as a product catalog, news or media assets, you can easily improve performance by putting a CDN in front of your back end (and caching that content on the CDN’s edge servers). Those edge servers are distributed around the world, located much closer to end users than your back-end infrastructure, to minimize network latency and maximize throughput.

    DevOps Automation

    Finally, a big part of setting up monitoring that works (and in responding to failures quickly) is DevOps automation. Building automated DevOps tooling allows you to react to changing conditions automatically, in real time.

    For example, you can use DevOps automation to alert your team via a chat system such as Slack when a deployment impacts the service, with an option to roll back easily the deployment within the chat app. Another great example of DevOps automation is Pinterest’s implementation of a “performance detective” that runs a binary search (similar to git bisect) to determine the offending commit that is degrading app performance after a release. If you combine these two automations, you could detect a performance degradation caused by a release; let the DevOps team know that it has been rolled back and track the offending code in the version control repository. That’s just one specific example among the many ways that DevOps automation can further optimize your back end.

    Coming up next in this three-part series: Everything you need to know about optimizing the middle-mile.

    — Javier Garza

  • Mphasis Acquires Stelligent, the DevOps Automation Services Specialist in the Amazon Web Services (AWS) Ecosystem

    • Mphasis Stelligent boosts Mphasis’ end-to-end capabilities in public cloud with a focus on DevOps and Containerization; further augmenting its managed services capabilities
    • Mphasis Stelligent combines best-in-class DevOps and DevSecOps solutions on Amazon Web Services (AWS) and delivery at scale with customer-centric digital transformation and hyper-personalization to enterprise clients

     New York / Bangalore, November 8, 2018

    Mphasis (BSE: 526299; NSE: MPHASIS), an Information Technology (IT) solutions provider specializing in cloud and cognitive services announced today its acquisition of Stelligent Systems LLC, a technology services company specializing in DevOps automation on Amazon Web Services (AWS). Headquartered in Reston, VA, Stelligent provides DevOps and DevSecOps solutions on AWS. The company is a Premier Consulting Partner on AWS Partner Network (APN) and holds both AWS DevOps and Financial Services expertise in deploying their customers’ applications on AWS with greater speed, agility, and security. The acquisition is an all-cash deal valued at USD 25 million.

    Since inception in 2007, Stelligent’s driving mission is to ‘help their customers gain the ability to continuously deploy their software when they want to and with confidence’. The company has been providing leading enterprises, including Fortune 500 companies, with continuous integration and delivery solutions on AWS and has built its brand as a pioneer and visionary within the AWS ecosystem.

    “The advent of public cloud infrastructure and SaaS software has elevated the importance of rapid automation in product development and product engineering for enterprises moving to the cloud. Together with Stelligent and its community heroes in the AWS ecosystem, we believe we are uniquely positioned to take advantage of this market opportunity. This allows us to join forces with an equally technically-deep company, bringing innovative, in-depth cloud solutions to enterprises in all Mphasis client segments,” said Nitin Rakesh, CEO and Executive Director, Mphasis.

    “Stelligent is very excited to further its DevOps capability across a broader range of clients and become central to Mphasis’ AWS go-to-market strategy. Our engineers will greatly benefit from being part of a larger, complementary tech-centric community; as well as serve enterprises in end-to-end AWS DevOps, DevSecOps and additional AWS cloud services,” said Bill Santos, CEO, Stelligent. 

    Stelligent’s team of over 50 engineers hold over 100 certifications and significant experience and expertise in DevOps Automation as well as one of a select few consulting partners with two AWS Heroes – an AWS Community Hero and an AWS Hero for Containerization.

    Safe Harbor: 

    Certain statements in this release concerning our future growth prospects are forward-looking statements, which involve a number of risks, and uncertainties that could cause actual results to differ materially from those in such forward-looking statements. The risks and uncertainties relating to these statements include, but are not limited to, risks and uncertainties regarding fluctuations in our earnings, revenue and profits, our ability to generate and manage growth, intense competition in IT services, wage increases in India, our ability to attract and retain highly skilled professionals, our ability to manage our international operations, reduced demand for technology in our key focus areas, withdrawal of fiscal governmental incentives, political instability, war, legal restrictions on raising capital or acquiring companies, and general economic conditions affecting our business and industry. We may, from time to time, make additional written and oral forward-looking statements. We do not undertake to update any forward-looking statement that may be made from time to time by us or on our behalf.

    About Mphasis 

    Mphasis (BSE: 526299; NSE: MPHASIS) applies next-generation technology to help enterprises transform businesses globally. Customer centricity is foundational to Mphasis and is reflected in the Mphasis’ Front2Back™ Transformation approach. Front2Back™ uses the exponential power of cloud and cognitive to provide hyper-personalized digital experience to clients and their end customers. Mphasis’ Service Transformation approach helps ‘shrink the core’ through the application of digital technologies across legacy environments within an enterprise, enabling businesses to stay ahead in a changing world. Mphasis’ core reference architectures and tools, speed and innovation with domain expertise and specialization are key to building strong relationships with marquee clients. Click here to know more.

    About Stelligent 

    Stelligent provides DevOps automation professional services on AWS, enabling engineering teams to focus on creating software users love. Our goal is to work closely with customers to develop fundamentally secure infrastructure automation code, deployment pipelines, and feedback mechanisms for faster, more consistent software and infrastructure deployments. For more information, please visit: www.Stelligent.com.

  • The Past, Present and Future of DevOps Infrastructure

    The Past, Present and Future of DevOps Infrastructure

    Infrastructure automation enables organizations to set up operating frameworks that allow smooth functionality with enhanced usage, minimal scope for error and faster deployment of code. The process of infrastructure automation eases development and operations processes by introducing good deployment practices such as computerized testing and versioning.

    The need for automation was realized when the demand for deploying error-free applications at a faster rate increased. Additionally, competition from similar businesses forced organizations to look for a way to bridge the gaps between development and operations to deploy applications that would serve their business needs.

    The Challenge of Implementing DevOps Practice

    The following challenges present a roadblock in bringing out the best results of DevOps practices:

    1. The disparate work cultures of the development and operations teams.
    2. Non-involvement of DBAs in release cycles.
    3. Failure in deployment of error-free codes.

    The Emergence of DevOps

    The introduction of DevOps practices resolved a lot of problems in terms of increasing business operations efficiency. It created a common operating framework where disparate teams including development and operations teams can work together and deliver applications faster that will, in turn, result in effective business operations and an increase in ROI.

    Adopting DevOps involves:

    1. DevOps experts outlining of traceable metrics for creating a roadmap by visualizing the desired outcome.
    2. Creating a pilot framework that will include the tools of both development and operations teams further integrating these existing tools with the DevOps experts’ robust ecosystem,
    3. Analyzing, designing, constructing, automating and implementing the network based on the metrics and resources collated.

    DevOps Tools:

    The DevOps infrastructure automation process uses several tools that define and drive the success of the implementation process. Here is a short overview of some of the more well-known and widely used tools.

    • Jenkins – A Java-based continuous integration (CI) tool contributes to the faster delivery of applications. Jenkins must be aligned with a version control system such as GitHub or SVN. Whenever the code repository receives a new code, a Jenkins server builds and tests the new code and informs the team about results and any changes. Over time, Jenkins has moved from being just a CI tool to being used as an orchestration tool that builds pipelines for application provisioning and deployment.
    • Chef – A ruby-based configuration management tool, Chef includes cookbooks that code infrastructure in domain service language (DSL) in combination with a little bit of programming. Chef creates virtual machines and customizes them in accordance with the rules listed in the cookbooks. An agent residing on all the servers that need configuration extracts the cookbooks from the chef master and runs them on the server to get the desired results.
    • Puppet – Also, a ruby-based configuration management tool, Puppet was developed with system administrators in mind. A configuration code is written using Puppet DSLs and is wrapped in modules. Puppet performs a similar function to Chef but, unlike Puppet, Chef is a developer-focused tool. It runs a puppet agent on all servers that require configuration and extracts the compiled module from the puppet server and installs required software packages as prescribed by the module.
    • Ansible – An agentless configuration management and orchestration tool, Ansible can be used for cloud computing. Ansible has configuration modules called “Playbooks,” which are written in YAML format and are easy to compose in comparison with other configuration management tools.
    • Docker – Docker, a process-level virtualization tool, creates isolated environments for applications known as containers. These containers can be transferred to any other system without making any application changes. Docker has evolved as the next step in virtualization. It is beginning to become a favorite of many DevOps practitioners and leading cloud experts.

    The Future of DevOps Infrastructure Automation

    A lot of organizations are beginning to benefit from the implementation of DevOps infrastructure automation. And with the pace at which the demand for DevOps services is increasing, infrastructure automation has a long way to go.

    As per statistics, by bringing DevOps practices into the picture, organizations can benefit by deploying code up to 30X more frequently and reduce the deployment failure to less than 50 percent.

    — Veritis

  • Datadog Monitoring and JIRA Integration

    Datadog Monitoring and JIRA Integration

    Operations uses monitoring to provide early detection of issues with systems/servers/networks. Among those monitoring options is Datadog, a software-as-a-service (SaaS) cloud service/application monitoring tool that allows Operations to be notified of issues with their applications in near-real time. Development teams, meanwhile, use JIRA to track tickets and manage overall agile development.

    But what if your product is the very thing that Operations manages? The sweet spot for DevOps is that location where the app is internally developed, and managed by Operations, because the entire stack is under IT management.

    That’s why Datadog and JIRA are now integrated.

    Datadog can monitor an infrastructure and application on a variety of levels at a variety of locations in the infrastructure stack, from disk availability to response times to memory usage. Datadog has the ability to monitor and emit alerts when things are abnormal or out of specified ranges, or they outright fail.

    JIRA is Atlassian’s Agile project management software, with issue tracking and all of the usual agile tools in one place.

    From Datadog Monitoring to JIRA ticket.
    Configuring Monitoring’s alerting to JIRA.

    Now, Datadog can create JIRA tickets, update them as more information becomes available and populate them with relevant information from the running systems.

    Say, for example, one cloud instance runs low on memory and passes over a threshold. Datadog detects the issue and opens a ticket in JIRA that shows what system and when, as well as whatever other information Operations has defined. That ticket is now in the system like any other, and a developer can grab it and look at memory use for the portions of the overall application that run on the instance in question.

    According to the press release, these are the three automations included in this integration:

    1. Creating JIRA tickets when performance issues are detected within Datadog.
    2. Populating JIRA tickets with pertinent information about identified issues.
    3. Updating existing JIRA tickets when new information surfaces.

    I’m an analytical person, so my first thought was, “How cool,” and my second was, “But what if it spams JIRA with non-development issues?” Since Operations configures what goes to JIRA, and Datadog supports alert rollups (multiple alerts in one or two notifications), it is possible to keep such spamming under control. An overzealous Operations staff initially might configure the reporting to send too much, but as experience grows, this should become a viable way to automate bug reporting. In particular, tagging of Datadog-generated events should show quickly what alerts are creating too many tickets, and give the team opportunity to change the way tickets are created—or, if it turns out they’re created because of a serious application-impacting error, raise the priority of the fix.

    Which brings us to the updating status part. In Datadog, operations can leave a comment on an issue with an “@jira-update” tag and JIRA will get notified of the comment. That means Operations can raise awareness of an issue that may seem mundane but has larger impact than is obvious, or add detail to a JIRA ticket if needed, all from within Datadog.

    It is interesting that Datadog is also integrated with BitBucket, another Atlassian product, so it is possible that opened tickets can be marked as “in test” when an integration build includes reference to the ticket. In short, BitBucket integration means that Datadog’s monitoring is aware of commits and checkouts, and Operations staff will be able to correlate that to issues that occur. Adding in JIRA integration means that Operations sees the commits, gets the alerts and updates JIRA. The wealth of information is such that you’ll want to use their various filtering techniques just to make certain you’re getting the important stuff.

    There are some areas that are intriguing to me, such as the impact of a particularly complex set of queries/reductions on a big data platform. I haven’t tried the Hadoop integration, but it appears that this agent would be able to communicate that a given reduction is the source of the problem to the JIRA interface. Even if these complimentary integrations aren’t there yet, you can feel it coming to where “This reduction caused systemwide issues” is what is generated in JIRA. That’s pretty cool.

    Overall, the integration of Datadog and JIRA is a DevOps dream come true, tying Operations closer into Development, and allowing Development changes to be tracked closer in Operations. After all, the point is to keep the systems running as close to peak efficiency as possible, and automate as much as can be. The issues spawning from Datadog alerts into JIRA tickets also pretty much guarantees increased need for development and operations to talk, as problems that crop up by the automated system are discussed and researched.

    If you’re dedicated to a cooperative environment for Dev and Ops—even if you aren’t calling it DevOps—the Datadog/JIRA integration is worth a look.

    — Don Macvittie

  • DevOps: The (Absolutely Critical) Cloud Enabler

    DevOps: The (Absolutely Critical) Cloud Enabler

    A couple weeks ago, I gave a talk titled, “DevOps: The Cloud Enabler” at a conference. As I was putting together some requisite materials previewing my session, I made a few mistakes. (Yes, I’ll readily admit it.) I used the words “should” and “can” and “consider.” Instead, the words “must” or “not optional” or “operationally imperative” make better sense.

    Companies are moving to the cloud (or at least endeavoring to); that’s a fact of IT life. If you’re not doing it, your competitors are lapping you. That may not be what you want to hear, but hey, reality bites. The cloud is simply the most scalable, flexible, efficient way to run a business these days. Cloud was just a buzzword for the longest time, but companies in all industries are actually putting it to work now. If your CIO isn’t at least in the midst of forming an application migration plan to the cloud, it might be time to light a fire under him or her; otherwise, start reading the writing on the wall and look for a new gig.

    Easier said than done, though, right? I’ve heard many a CIO say, “We’re going to have all our apps in the cloud by 2018!” No, you’re not. You don’t know how. You don’t have the tools and road map to get there. Let me enlighten you with some of those stronger, more urgent words I mentioned earlier. In your move to the cloud, DevOps MUST be the conduit. Period. Stop. End of argument. Game, set, match. Not optional; it’s imperative.

    Here’s why: One of the most fundamental problems that’s part and parcel of a move to reliance on the cloud is that IT orgs want every scrum team to have its own environment, complemented by an individual database instance. Eventually, that leads to creating a distinct database instance for every single developer. You probably can see where this is headed.

    I’ve used this comparison time and time again, but cloud and database instances become like the wire hangers in your closet you accumulate every time you pick up clothes from the dry cleaner. They multiply over time and, all of a sudden, you seemingly have a million on your hands, with no idea where they came from and no good way to get rid of them. To compound things, once the proliferation begins, it’s hard to stop. Shut down a database instance (as with an application instance), and you lose the underlying data. No can do.

    That reality spells disaster for the database administrators (DBAs) being flooded with thousands of development SQL scripts and database changes across multiple app release cycles across multiple environments. For DBAs to attempt to keep pace with this rise in change requests, organizations all but have to go through DevOps’ economies of scale. DBAs need reprieve, and DevOps can be just that. David Linthicum put the solution thusly: “Stop separating the development and operations skills; they are tightly coupled and need to be peers. You’ll find this is the hardest part of the process of moving to devops and the cloud.”

    Spot on. To be more prescriptive:

    • Developers need to understand what DBAs are dealing with as part of the cloud migration and know how their work rolls downhill.
    • Automation needs to reign supreme, removing manual work.
    • Developers need to have the ability to be involved directly in cloud ops and enact 95 percent of changes themselves.
    • DBAs need to be freed to oversee the 5 percent of changes that truly need their attention and management skills.
    • The flow from cloud application updates to cloud DB changes needs to be seamless.

    In bringing development and DBAs into sync, DevOps then becomes the vital remedy, the critical cloud enabler.

    TL;DR: If you have DevOps alignment, processes, responsibilities and tooling properly implemented in advance, then when you decide to move to the cloud, you can simply flip the switch from on-premise to the cloud. One click and you won’t miss a beat. Seriously, it’s that easy. Sound appealing? I know.

    If you truly want to get to the cloud, you must have a sound DevOps strategy that encompasses application development, web and the database. Without that in place, swim at your own risk. This is the year that we’ll see much more of the true impact of DevOps. And that’s coming just in the nick of time, because without DevOps, CIOs and their IT orgs would be in for some nasty surprises in their all-important moves to the cloud.

  • Surprise! Broad Agreement on the Definition of DevOps

    Surprise! Broad Agreement on the Definition of DevOps

    For the past few years, the conventional wisdom has been that DevOps has no agreed upon definition. Instead, everyone has their own interpretation. However, the conventional wisdom is wrong.

    While everyone supplies slightly different words, the same working understanding of DevOps is nearly universal. Our understanding of DevOps goes back to a handful of common touch-points. There is the “CAMS” (Culture, Automation, Measurement and Sharing) acronym popularized by John Willis and Damon Edwards. CAMS has been extended repeatedly – Eveline Oehrlich of Forrester is now discussing CALMSS. Gene Kim offers his “3 Ways” and Patrick Debois has codified “4 Areas”. Allspaw and Hammond had 10 deploys a day, and Etsy made technologists fascinated by a virtual crafts bazaar.

    Analysts, authors, industry, and community leaders all agree. The ideas are big and mutually supportive. In short:

    • DevOps exists to help the business win
    • The scope is broad, but centered on IT 
    • The foundations are found in Agile and Lean.
    • Culture is very important
    • Feedback is fuel for innovation
    • Automation helps

    Why: To help the business win

    The most popular DevOps book today is The Phoenix Project, with a subtitle “A Novel about IT, DevOps and Helping Your Business Win”. DevOps is not a navel gazing IT methodology for making IT better for IT. It is focused on how stuff involving the technologists can deliver better results for the business.

    As Patrick Debois writes in his excellent post,”DevOps Areas – Codifying devops practices“:

    As rightly pointed out by Damon Edwards, devops is not about a technology, devops is about a business problem. The theory of Constraints tells us to optimize the whole and not the individual ‘silos’. For me that whole is the business to customer problem, or in lean speaks, the whole value chain.

    At IBM, our definition of DevOps calls out enabling the business to “seize market opportunities”.

    Today, technology is critically important to how a wide variety of companies compete. Retailers who neglected e-commerce have gone out of business. Logistics companies like UPS find a competitive edge by creating software to shave miles off delivery routes. In the automotive space, Ford is at tech conferences recruiting companies to write apps for its cars and Tesla’s first fix for their flammable battery problem was an over the air software update.

    DevOps is a response to what the IT is experiencing – from a back-office concern that needed to “keep the lights on” to key part in how the business competes every day.

    Who: A Broad Scope, beyond development and operations.

    Yes, DevOps is a portmanteau that brings development and operations together. Yes, the classic DevOps concern is the Wall of Confusion between development and operations. However, with the focus on business value, the scope must include everyone who is involved in taking an idea through IT to business value.

    In recent years, there’s been something of a cottage industry of community leaders and analysts writing, “No, no it really should be Dev_____Ops” where the blank is filled in by their own specialty. Examples: DevQAOps, DevOpsSec, DevSecOps, BizDevOps and of course Bussdevtestqanetsecnetops.

    When a Finance department must approve the provisioning of each new test environment, slowing the delivery of new applications by weeks or months, there is a DevOps problem that leaves narrow confines of development and operations. It leaves IT. Patrick’s quote above talks about optimizing the whole value chain. In that post he describes DevOps as being about “collaboration, optimization across the whole organization. Even beyond IT (HR, Finance…) and company borders (Suppliers)”.

    Based On: Agile and Lean

    In answering why he didn’t support a manifesto for DevOps, Patrick Debois points people back to the Agile manifesto and asks them to reread it more broadly. Agile’s shift towards a faster delivery of software, and focus on the end goals make it a natural spiritual ancestor for DevOps. However, from the perspective of Ops teams, Agile represented the barbarians at the gates. Agile generally took root in development side of the house, enabling it to create something the business wanted faster. But with operations still moving at a pace suited to waterfall, pressures grew and the need for something like DevOps became clear.

    Where much of DevOps energy seems to come from its Agile roots, the intellectual side of the movement is more rooted in Lean. It seems no accident that many of the Phoenix Project’s lessons are taught away from the cube farm and instead from the factory floor. While we can intuit that faster feedback is better, and the “continuous” in CI and CD is convenient because it lets us map feedback to fewer changes, it is in the Lean literature where we encounter Little’s Law. It provides the queue theory mathematics supporting the idea that smaller batch sizes supports shorter cycle time. And so Reinertsen’s “The Principals of Product Development Flow: 2nd Generation Lean Production Development” has become popular in DevOps circles and is well cited by Jez Humble in his new Lean Enterprise book.

    Culture: Collaboration and Experimentation

    The Agile and Lean roots show through in the DevOps culture as well. Lean and Agile are both focused on people first, systems second and heavily cross-train or work in cross-functional teams. They also emphasize continual improvement (kaizen) through approaches like retrospectives.

    In DevOps circles, collaboration is preached as an antidote to thinking in siloes which has resulted in antagonism between development and operations. For the systems thinking required to deliver for the business, teamwork is required. Developers make better decisions when they take advantage of operations knowledge (Patrick’s Area 3) and operations does better when application knowledge is embedded with them (Area 4).

    The other cultural emphasis is a push towards experimentation, constant learning and improvement. This is Gene Kim’s third way of DevOps. The Lean Startup ideas of Eric Reis permeate the DevOps world. Intuit has made great strides in showing how these approaches work in established companies by running experiments in the midst of tax season resulting in improved business outcomes.

    These cultural trends come together in things like blameless postmortems discussed by Etsy and Jake Loomis in Web Operations. When things go wrong, organizations need to understand why and take corrective action. In troubled corporate cultures, the messenger reporting the problem might be shot, and the hunt to assign blame for the problem will begin. Healthy organizations look to learn from failure and try to improve the systems that allowed (or guided) people to make a series of mistakes that lead to the failure.

    Feedback: Yes. Lots please!

    Experimentation, adaptation and learning tend to do better when there is ample feedback. Otherwise, there is too little to learn from. Developers tend to be more productive as well with rapid feedback. Their thirst to know whether the latest change diminished quality led to the practice of continuous integration and the tools that support CI and continuous delivery. That CD ends up facilitating faster delivery of value to the customer is something of a happy accident.

    Amplifying feedback loops is Gene’s “second way“. The “CAMS” concepts of measurement and sharing point to feedback. You gather lots of information, and make sure people see it so they have an opportunity to learn from it. And when Elisabeth Hendrickson presents at DevOps Enterprise 2014, as Cloud Foundry’s Director of Quality Engineering at Pivotal, she describes her job as “to see to the care and feeding of the feedback cycles“.

    As expected with a collaborative culture with ample sharing, feedback must cross the traditional silo lines. That means the awesome production monitoring that had lived in Ops land, is radiated back to development. This is “Area 2” in Patrick Debois codification.

    Automation: Of course.

    The “A” in CAMS is automation. Patrick’s “Area 1” points to continuous delivery techniques, well described by Dave Farley and Jez Humble in their book. A Lean initiative looking at IT will find waste in wait times, errors, and more and move towards automation as a natural result. Feedback craves automated deployment of changes, and automated tests or production monitoring that validates them. Automation is what makes a lot of DevOps possible. It doesn’t make cooperation between development and operations happen, but tensions are reduced when Ops gets out of the business of arguing about the SLA they have with Dev around server provisioning and instead provide Dev a button to press.

    DevOps isn’t about automation. Automation is just the natural result of DevOps.

    Additional Resources not cited above

    DevOps for Dummies – by Sanjeev Sharma

    8 Best Practices for DevOps – Ashok Reddy’s overview of the Forrester Report

     

    About the Author/ Eric Minick

    ericMinickEric Minick is a Technical Evangelist. He joined IBM through its acquisition of UrbanCode. He has spent the last ten years helping organizations – large and small – adopt continuous integration, delivery and now –DevOps. He is a frequent speaker on the topic, and co-authored Application Release and Deployment For Dummies.

    Prior to consulting, Eric was a developer, test automation engineer and support engineer, and has contributed to multiple generations of UrbanCode products.  Follow him on Twitter at @ericminick.