Category: Enterprise DevOps

  • The DevOps Devil is in the RFP Details

    The DevOps Devil is in the RFP Details

    The request for proposal (RFP) process in IT outsourcing is, at its best, a challenging, time-consuming process rife with pitfalls for both customers and outsourcing providers. The process is made even more complicated if customers are unable to provide clear and detailed requirements because of haste or inexperience in software development outsourcing.

    In my work matching companies that need to outsource their software development to international partners, I’ve seen this particular challenge, where less mature customers do not offer potential partners enough of the needed detail in the RFP process for determining an accurate estimate. The question remains, What is the best way to navigate a situation like this?

    There are two key considerations at the very start. First, because IT outsourcing can mean several types of services, including help desk, cloud enablement, network monitoring, etc., outsourcing of custom software development is a type of IT outsourcing that has specific best practices for engagement, methodology and process. Second, I recommend dropping the word “vendor” from your lexicon to refer to a company you hire for custom software development; instead, use the term “partner.” In my experience, treating your software outsourcing partner like a vendor inevitably leads to an adversarial relationship that shuts down creativity and innovation. For software development outsourcing to work, it is absolutely critical to maintain good communication between equal partners. A good working relationship cannot be underappreciated as a key element of success.

    From the provider perspective, there is no ethical way to respond to an RFP that lacks details with an accurate time estimate and cost quote. Any proposal offered should be for a discovery phase, where the service provider uncovers the details the customer is unable to provide on its own. The customer can use the deliverable from a discovery phase to have a more realistic discussion with multiple service providers and receive credible proposals. If the prospective customer is unwilling to pay for the discovery phase or provide the required details, then the service provider should turn down the opportunity.

    From the customer perspective, the answer to the question of how to resolve unclear requirements, then, is to require that the contract governing the relationship be for a dedicated agile development team that can start developing software as the highest priority requirements are defined. The team may grow or shrink over time to accommodate changing priorities, and the release plan can be updated every three or four sprints as you learn more about the requirements and what users want.

    The customer should be prepared to commit contractually to providing a dedicated, easily accessible and available product owner to resolve questions and issues quickly. A “local” product owner can also be on the outsourced team to facilitate communication when developing apps with complex software requirements, but he or she should not be considered a replacement for the customer’s product owner.

    The provider, then, should be prepared to provide at a minimum:

    • Team ramp-up time
    • Monthly rates per developer at various levels of seniority
    • Historical retention or attrition rates of team members
    • References to other customers using similar software technologies and/or domain experiences for what is needed for a particular project
    • For customer experienced with agile development, an estimated velocity of story points per sprint

    An additional challenge from the client perspective is to be able to define the IT outsourcing speed that is needed for the task at hand. The recent concept of two-speed IT defines two kinds of IT software development—slow and fast. Each kind can be outsourced, but with different types of service providers.

    Slow IT outsourcing is most typically used for the careful update of legacy software systems that are changed slowly over months and years to maintain the stability of the business. Fast IT outsourcing is most frequently used for product development and digital transformation and requires an agile approach that includes UX design, user testing, development and DevOps. By recognizing the distinction between fast and slow IT outsourcing speed approaches, you’ll be able to select a partner company with the right experience.

    By abiding by a few key parameters, customers and providers alike can make the RFP process a constructive and productive experience. While it’s true that customers always seek the best possible deal in an outsourcing bid, they don’t always offer the information required during the RFP process to help providers meet their needs. An RFP should be viewed as an opportunity to build a relationship, rather than executing a transaction, and a commitment by both customer and provider to trust and transparency will go a long way toward long-term success.

    About the Author / Steve Mezak

    steve.005Steve Mezak is CEO of Accelerance, a Silicon Valley firm that, since 2001, has matched hundreds of U.S. companies needing software development with international, outsourcing partners. Steve has more than 30 years of experience in the IT industry, from writing software code to facilitating and managing software development teams. He’s authored two books, including most recently, “Outsource or Else! How a VP of Software Saved His Company” (June 1, 2016). Contact Steve by email: steve@accelerance.com; or Twitter: @SteveMezak.

  • 7 Pillars of DevOps: Essential Foundations for Enterprise Success

    7 Pillars of DevOps: Essential Foundations for Enterprise Success

    As indicated by the “2016 State-of-DevOps Report,” multiple compelling enterprise business performance improvements provided by well-built DevOps solutions are driving IT transformations for development and operations across many industries.

    While some enterprises have implemented DevOps to gain near-term efficiency benefits, DevOps is becoming a competitive essential for all enterprises to implement DevOps. Enterprises that fall behind risk long-term success in their markets. Yet, many organizations are struggling to get DevOps working effectively. What is the secret to success with DevOps?

    A solid foundation for DevOps requires mastery of seven areas that we at Trace3 refer to as “The Seven Pillars of DevOps.” These pillars are all necessary to support effective DevOps delivery pipelines together with end-to-end orchestration of all pipeline stages and workflows. If any of the pillars falter, the DevOps pipeline will fail to produce high-performing benefits of the most successful enterprises.

    So what are these essential seven DevOps pillars?

    1. Collaborative Culture: End-to-end goal alignment and cooperative workflows are essential. No amount of technology will suffice if Dev, QA and Ops leaders and teams do not cooperate.
    2. Design for DevOps: DevOps prefers products that are designed in modular fashion using microservices, 12-factor apps and containers—those are easily integrated into high-performance DevOps. That is not to say legacy products cannot benefit from DevOps, but modular, immutable architectures are most readily suited to take full advantage of DevOps.
    3. Continuous Integration (CI): Merging forward quickly with competent integration practices that minimize rollbacks, interruptions and costly delays in the pipeline.
    4. Continuous Testing (CT): Relevant quality testing at speed requires multiple strategies that ensure efficient coverage throughout the pipeline with minimal failures delivered to production, yet quick enough to not bottleneck the pipeline.
    5. Continuous Monitoring (CM): Real-time lifecycle intelligent active monitoring and analytics are essential to accelerate real-time decisions at each stage of the pipeline and avoid bottlenecks.
    6. Elastic Infrastructure: Infrastructures that are resilient and elastic perform much better. DevOps applies to most types of infrastructures including private data centers, special purpose bare-metal systems, virtualized functions, containerized packaged applications, private and public clouds and hybrid cloud environments.
    7. Continuous Delivery (CD): Modular delivery packaging preparation and deployment solutions with orchestration of virtualized and containerized applications are preferred over monolithic mutable applications.

    While DevOps implemented with all seven pillars provides a strong foundation for long-term enterprise business improvements, it is important to understand also that DevOps is not an island. Enterprises implementing DevOps should be aware that DevOps interoperates with other IT systems and practices. Enterprises are well-advised to choose tool-agnostic IT partners that can provide solutions that best suit the needs of each unique enterprise and can integrate and evolve DevOps together with all enterprise IT systems.

    We believe DevOps is an essential part of enterprise success. Keep a look out for future blogs describing best practices for each of the seven pillars of DevOps in coming months.

  • Engaging Adoption of DevOps

    Engaging Adoption of DevOps

    Executive mandate does not immediately translate into a change in behavior. Organizations inherently grasp the value of embracing DevOps, but the timing of exactly when it begins and is completed is another matter. The devil truly is in the details—or rather, in the ability and willingness of the organization to adopt a change in thinking and a change in the actions that follow.

    “Adoption” is then a common term to describe the measurement of how far along an organization is in its transition between legacy and future, between the beginning and the completion of embracing DevOps services. As you might guess, adoption does not happen overnight, nor does it occur because of mandate or willingness. These factors influence the speed of adoption in some cases, but can act as deterrent in others. Adoption—like most other services provided to a given organization—occurs because its value proposition is sufficiently defined and resources are budgeted and assigned to it.

    The level of resources you dedicate to tracking and facilitating adoption of DevOps in your organization is directly proportionate to the complexity of your development efforts. If for example, you have a new development team well-versed in cloud technologies and comfortable with using software-as-a-service (SaaS) tooling with only few applications under development (small app portfolio), your proportionate adoption efforts will be small, and transition should occur very quickly. However, if you have a large number of applications spread out across a wide variety of hardware platforms and are using a wide variety of development languages or tools, your proportionate adoption efforts will be far more substantial to keep the timeline manageable. In either example, a complete lack of attention to adoption results in elongating the timeline two to eight times longer than it would have been if formally engaging adoption was considered.

    Adoption Engagement 101

    So what do these adoption/engagement resources do from day to day? The primary focus of the folks assigned to this duty breaks down into three major categories of work efforts:

    1. Communications conduit: The first responsibility of the folks on this team is to develop and implement a communications plan to keep all stakeholders up to date on what is going on with DevOps services. This includes metrics-based information such as how many applications have been fully onboarded to DevOps. It also may include how many applications have been onboarded into a particular level of automation within the stack, from code to OS. A company may want to know how many apps have gotten their database efforts automated, as an example, or perhaps how many apps are fully automated with middleware messaging systems. But the communications also must include keeping executives up to date on the ROI progress, and what areas of the company may be exhibiting resistance (for both legitimate and non-legitimate reasons). Expressing these outcomes can be sensitive and should be done with a modicum of care, so the folks assigned should have these skills to start with.
    2. Information Preparation & Follow-Up: When a given application in the portfolio is targeted for onboarding to DevOps, a significant amount of information is usually gathered about it. While a company can create an automated system for development engineers to provide the data into an electronic web page or other means, very often questions arise about “how” to respond. You do not want to have your DevOps services engineers constantly deterred from their work to answer basic questions such as this, so having an adoption team able to provide the data quickly facilitates the overall goals. In addition, often the development engineers are too “busy” to provide the DevOps team the data they need. Again, someone needs to follow-up to ensure questions are actually answered. While it is easy to assume engineers will behave professionally and respond accordingly, that assumption in the real world results in long delays and interrupted workflows across multiple teams.
    3. Training & Feature Expansions: Finally, the tools and architecture practices behind them need to be communicated effectively to the practitioners and participants of the DevOps services. When new programmers are hired, for example, they should have access to training materials on accessing to the DevOps toolsets and using base functionality, what governance procedures will impact them and more. On occasion, to facilitate adoption, an application executive sponsor and his or her immediate direct report engineering team leads will request a demonstration of a given DevOps tool or function. The adoption team should handle these requests and not divert a production DevOps engineer from his or her duties. And when a DevOps tool is updated or upgraded, the adoption team should develop the method to communicate the new ability, edit the existing documentation and ensure every practitioner is notified about the new features and how to use them.

    Adoption Engagement Financials

    Deciding how many people to dedicate to this function is a mix of your development environment complexity and what you have currently to complete your DevOps rollout efforts. If you want a 24×7 rollout, then you will need staffing levels to accommodate three shifts, seven days a week, with additional folks for vacations, holidays and sick leave. If you are only rolling out a 9-to-5, five-days-per-week effort, staffing numbers drop significantly. Resources, then, can be organized as one per line of business or one resource for every 50 applications in the portfolio (higher ratios are supportable). Whether you align the resources to the services you provide or to the customer audiences you support won’t matter nearly as much as having at least some resources dedicated to these efforts. As I stated earlier, a complete lack of resources dedicated to this function results in greatly extending the timelines for adoption of DevOps; worst case, in the failure of the transition entirely.

    This kind of function is inherently considered overhead. Most DevOps leaders (generally emerging from an engineering background) naturally don’t consider this more administrative function as necessary. It doesn’t strictly add to the engineering capability or skills of the main onboarding teams, so they simply do not include it or divert budget to more “necessary” folks during planning. Organizations that don’t actually provide a guided DevOps service—that is, they simply install the tools and tell the developers to have at it—find their adoption efforts lagging quite a bit as well. The early adopters jump right on without coaxing, but the folks too busy with their own efforts to “try something new” never seem to get around to it. Finally, the guys who think, “Since it ain’t broke, don’t fix it,” will never adopt. Even in this kind of tooling-only services deployment, dedicated adoption resources would have resolved these issues in a far more timely manner. The overhead may be painful, but the alternative is far more painful. Once a company or division experiences a failed DevOps rollout, it rarely returns to try again, and the overall costs could be doubled or worse.

    For organizations with the vision and perseverance to employ dedicated resources to facilitate adoption, the converse of the problems outlined above becomes the norm. Developer teams have the information they need to understand their own need and, more importantly, the benefits of adopting DevOps. The work relations between DevOps service provider and DevOps service consumer become highly efficient and mutually beneficial. The entire organization benefits from effective communications from the executive sponsors at the top to the engineering practitioners at the bottom. Execs know the costs, the progress, what is new and how it will help them reduce costs or speed up delivery. Practitioners know how to use the tooling, why it will help them and how to stay current on the changes that come along (and they invariably do). Practitioners appreciate being current on a given tool or skill set; this provides a way to do just that.

    Impacts to the Bottom Line

    Discreetly measuring the ROI for the application of adoption/engagement resources is a bit squishy. As a general estimation, take the timeline of the DevOps rollout you originally planned and multiply that by two to three. The cost of that delay in timeline (plus the risk of complete failure) is the cost delta to measure against hiring a few more folks (or allocating them from lesser-used areas already on staff). Usually the cost of failure far outweighs the benefits of expanding the overhead support teams as needed. In addition, the cost of a failed communication effort can grow over time. At the outset or launch of DevOps, the communications, whether in document or oral forms, will be fully up to date. But over time, as vendors add new features and new versions of the tooling emerge, practitioners won’t know how to take advantage of the new capabilities. Since many of these new features enhance speed or accuracy, the tendency to not use them—or use the inconsistently for lack of knowledge—will add up.

    I find the resistance to the idea of adoption or engagement resources often is founded in the notion that engineers are plenty smart enough to figure this stuff out on their own and they will naturally gravitate to it, as ultimately it makes their lives easier and better. Yes, the engineers are smart enough and some will. However, engineers often build their own “ecosystems” of how an application should be built (which few others could understand or improve upon). They often are reluctant to tear this down in favor of corporately implemented templates (that everyone could understand and improve). They fear the loss of unique skills the company must depend upon. They fear the loss of being “special” and needed. Even though DevOps standardization makes builds and deployments consistent, reduces trouble tickets and improves quality and speed—which ultimately translates into fewer 2 a.m. phone calls for engineers to come fix—they are still reluctant to change (just like the rest of us). Having dedicated resources to help them through the value of this, and assure them of their continuing value in a differing area (the code we want them to write), can make a world of difference and ensure a transition does occur.

    To continue the conversation, feel free to contact me.

     

  • Tales of DevOps Discovery, Part 3: Q&A and Explanations

    Tales of DevOps Discovery, Part 3: Q&A and Explanations

    This is part three of the series, Tales of DevOps Discovery. To catch up, Read part one and part two.

    In preparing for a DevOps transformation a critical first step is to perform upfront discovery, often asking even the most fundamental, seemingly obvious, questions of stakeholders. The major portion of such discovery should be done in a group setting. Asking stakeholders these fundamental questions in a group setting can provide key insights into differing perspectives and even differing objectives regarding a planned DevOps implementation. Sharing these different perspectives during the discovery phase sets the stage for mutual empathy and enables stakeholders to identify and align, an important step to aligning on shared objectives. In this article we will outline common questions asked, share real-world answers and offer guidance on interpreting and applying the results.

    Discovery Question: What do you want to achieve with this transformation/DevOps?

    One of the first things to consider is, “Why are we doing this?” as this establishes the goals and objectives. Accordingly, I usually begin by asking the stakeholders during discovery what they expect to achieve through the transformation to DevOps. The answers I receive to this question often differ distinctly, depending on the role of of the person answering. Understandably, they are heavily influenced by the unique perspective of that role.

    Answers:

    CIO: “We want to increase our ability to “scale-up” delivery as we shift to a primarily SaaS (software-as-a-service) model and see a rapid increase in business. These means we have to increase developer productivity, and respond to customer requests faster, all while reducing our number of Severity #1 issues.”

    Operations:
    “We want to reduce technical debt, to minimize firefighting and increase our ability to adopt modern best practices such as Infrastructure-as-code. We have to be able to keep the lights on while delivering applications to production.”

    Development:
    “We would like to minimize customer-specific one-off work, which is resulting in painful complexity in development, QA (quality assurance) and deployment, and is an overall source of inefficiencies. We would like to be able to spend more time improving user experience, performance and increasing valuable functionality. But, instead, we are chasing bugs and reworking misunderstood requirements.”

    Guidance:

    Not surprisingly, executives often respond with a focus on business-oriented goals such as increased productivity and customer response, while Operations focuses on stability and minimizing firefights and Development wants to innovate. But within these differences we see some commonality that can be harnessed, such as productivity. For example, one point of commonality is productivity:

    CIO: “We have to increase developer productivity.”

    Operations: “… minimize firefighting and increase our ability to adopt modern best practices …”

    Development: ” … spend more time improving user experience, performance and increasing valuable functionality.”

    Another point of commonality in the CIO, Development and Operations answers is the focus on quality:

    CIO: “ … reducing our number of Severity #1 issues.”

    Operations: “We want to reduce technical debt … keep the lights on …”

    Development: “… instead, we are chasing bugs … ”

    These points of commonality can be used to establish common goals with cross-functional buy-in, such as:

    • Our effort will result in increased productivity and minimize overtime and firefights (across teams)
    • Our efforts will result in increased application quality and uptime

    They then can be used not just as driving principles that inform decisions such as process or tool choices, but also to establish key performance indicators (KPI), which will be used to quantifiably measure success of the transformation. Example KPIs may be:

    • Reduction in cycle time, from story acceptance to user acceptance (or release)
    • Number of Severity 1, or Severity 2 production issues per release
    • Defects per build
    • Defects per release
    • Hours worked by Development? Operations?

    Discovery Question: Do you practice agile today? If so, how do you define done for a story or sprint?

    Continuous delivery (CD) and lean practices are foundational to a successful, sustainable DevOps transformation (though not required to meet the some definitions of DevOps.) If we look at CD and lean practices as a pipeline through which we need to manage a continuous flow of changes represented by work, then it is important to consider what work is sent into the pipeline, how the work is initiated and how the changes are managed. Accordingly, it is important during discovery to ask customers high-level questions about development methodologies used and overall practices for definition, planning and coding.

    The answers given vary between different levels of, “Yes, we are agile,” “No, we are waterfall,” and, “We practice both.” Most Most often, organizations’ answers describe adherence to a form of agile with room for improvement.

    Answers:

    “We practice agile and/or scrum. We work in two-week iterations, planning the work for a sprint at the end of the prior sprint.
    We consider a story done once the code has successfully been committed and merged to a team branch, and is successfully built. We consider a sprint complete when all stories for that sprint are committed and successfully built.

    “Roughly every three months we integrate code from team branches to trunk and perform a mix of automated and manual regression and acceptance tests. Once the build passes QA we manually deploy to preproduction environment, validate and schedule a manual deployment to production.”

    Guidance:

    This is a classic story of agile adoption in traditionally waterfall organizations. The organization adopts agile within Development without involving other key functional teams such as QA or Operations. Usually, this is because it simply is easier. There are a number of obstacles to overcome in extending agile practices across organizational, technical and cultural boundaries, so the obstacles are avoided by limited the agile adoption to these boundaries.

    This is a case of confining the adoption to “agile upstream” while practicing waterfall or legacy “downstream.” Studies show that less than 33 percent of organizations have adopted “agile upstream” and exercise agile or iterative development practices for the planning, coding and team builds, yet only 13 percent of organizations have adopted agile downstream, and follow practices such as continuous integration (CI), CD, automated provisioning testing and deployment.
    Screen Shot 2016-07-18 at 11.07.34 AM

    The negative effects of limiting agile adoption to agile upstream are multifold, but can be summarized as, “You never really know when you are done-done.” As a result, you cannot accurately measure progress, introduce deferred risks or disrupt the development plan to address issues found during the downstream portion of the process, such as poorly understood requirements surfacing during acceptance testing or runtime issues discovered during deployment to a production-like environment or, in the worst case, issues found in production by the end user.

    A seminal book on DevOps is, “The Phoenix Project,” by Gene Kim, which presents three ways of DevOps thinking. The first way, “Systems Thinking,” addresses to this gap between agile upstream and downstream, Dev and Ops, business and customer by taking a systems view across the traditional boundaries and establishing “flow” of the system through the boundaries.

    Screen Shot 2016-07-18 at 11.05.09 AM

     

    Discovery Question: Do you practice CI today? What types of validation do you perform?

    As CD is foundational to DevOps, CI is foundational to CD. CI can be scene seen as the connection point for agile upstream to agile downstream, and the pump that fills the CD pipe. It is both the practice most organizations say they follow and the practice that most often is implemented incorrectly. So when surveying a customer’s current state during discovery, it is important to know whether CI is currently part of the picture.

    Answers:

    “Yes, we practice continuous integration. Each team has a Jenkins CI server. Developers commit their changes multiple times per week. Jenkins then builds the changes as part of a nightly build.”

    “We do some unit testing, but we do not track code coverage. If the nightly build fails we may continue to commit, but we usually fix the issues within a few days.”

    Guidance:

    This is a common answer and an example of how CI can be improperly implemented. CI is more than having a shared Jenkins CI server and running scheduled builds. CI can be defined as:

    “A a software development practice where members of a team integrate their work frequently, usually each person integrates at least daily – leading to multiple integrations per day. Each integration is verified by an automated build (including test) to detect integration errors as quickly as possible.” — Martin Fowler

    The benefit of practicing CI includes identifying integration and quality issues close to the source of the issue, thus reducing the time to correct and enabling higher-quality software to be developed more rapidly.

    Essential elements of properly implemented CI are :

    • Integrating changes frequently, ideally multiple times per day or even per change.
    • Performing consistent validation of quality through component level testing, code scans, etc.
    • Always maintaining a working build, suspending development when a build fails, and not resuming development until the issues is corrected or reverted.

    Teams that allow a broken build for “a few days,” deferring commit or builds to just “multiple time per week” or that do not validate consistently through testing practices are not practicing CI and will not yield the benefits of CI.

  • Baselining Metrics to Measure DevOps ROI

    Baselining Metrics to Measure DevOps ROI

    Assessing the ROI of DevOps normally is done against a company’s baseline cost. The problem is, most organizations do not collect or evaluate the cost of “automating and delivering” innovation; they usually are more focused on the innovation product itself. As an example, if a company creates an application hosted on the web that offers its customers the ability to purchase inventory, the company usually is obsessed with knowing how that application performs: How many people are using it? How often does it fail due to bugs? How many sales are made? The company typically focuses on the end product—on the application as it touches customers and potential customers. The delivery process that precedes the application being loaded into production is not usually the subject of intense scrutiny. At least, most organizations are not evaluating the speed of delivery and process effectiveness of delivery prior to an embrace of DevOps methods and tools.

    This lack of scrutiny results in the lack of a baseline to compare against. Say, for example, a typical programmer (prior to DevOps) uses a mix of scripts, human intelligence and human verification to create and verify a build. Prior to DevOps, the goal is simply to create the build and get it out there to look at it, and decide what to do next. Most programmers are not obsessed with how efficient this entire process is; for them, it is a means to an end. So most programmers do not keep records of the average amount of time it takes to create the build from beginning to end. This is even more true of the deployment process. Once a build has been created (again prior to DevOps), getting it deployed to the target environment might involve a few different teams (depending on the class of test environment that is targeted). The process may involve email requests to other support teams or filling out a ticket to get it done. Once again, most organizations spend little time tracking this process from end to end; it is only ever a means to an end.

    If, in fact, an organization was watching closely how long it takes to get a build created and how long it takes to get a deployment completed, that organization would be running toward DevOps at full speed to see improvements it otherwise could not achieve. It is the things we do not measure that receive little attention—until they break. Once our deployment process has become so onerous or so complicated or so burdened with approvals required that nearly nothing gets deployed, then we begin to look at it. This creates a culture of “squeaky wheel syndrome,” which makes both our development and our operations teams focus only on reactionary issues, while proactive concerns die on the side of the road. There is no time to invent proactive improvements when you are constantly fighting the fires of something else that is seriously broken. This culture must also change if DevOps is to succeed broadly in your organization, so keep note of how far it may be infected in how you run things today.

    Preparing for Collection

    Given that most companies lack a real baseline to compare against in this area, realize that collecting one will take an investment itself. This baseline metrics collection cost is usually added to the cost of the investment in DevOps. It is a bit unfair, as you are effectively saying, the soap company will also have to bear the cost of determining how dirty we are before we invest in the soap that will clean us. The makers of soap tend to think you already have a sense of how dirty you are, or you would not be looking at buying soap in the first place. But without an accurate assessment of knowing the extent of the problems (in this case, the investment of time you spend today), you will never know the ROI of having made the improvement of DevOps (the after picture).

    Also, keep in mind that measuring anything manual is difficult. This sounds like a saying from Captain Obvious, but consider that manual work efforts require additional manual work efforts to capture them and record them in some kind of system. If, as an example, my typical programmer spends 15 minutes of every build doing human verification of the build, this amount of time is reflected nowhere. Hourly employees typically record how many hours they work per day, not what tasks they spent during the day. Even the employees who log work hours more discreetly tend to record only that they spent “x” amount of hours doing “development,” not what general task categories occurred within the heading “development.” So there are no electronic records out there that can be gathered automatically that will reflect the 15 minutes spent doing human verification of a generic build of an application. The only way to know this is a personal interview, followed by someone keying the data into a collection system of some sort.

    Knowing that the information you seek for a baseline will come in human interactions as well as some automated logs, start the collection using a tool that allows for maximum flexibility for those efforts. Spreadsheets come to mind. When the effort to collect a baseline begins, you will have some ideas about the kinds of data you wish to collect and how it might exist in your organization. But it is impossible to know exactly how the resulting efforts will be completed. In short, you don’t know what you don’t know. While you collect metrics you will invariably come across someone who reveals critical metrics-related information you were not “planning” to collect. But once the revelation is made, you will need to incorporate the “new” information to really provide an accurate baseline assessment.

    Determining the Baseline

    The next step is to begin the collection process itself. The critical data to examine usually can be gathered by looking at “human” time involved in a given core “process” of the automation and delivery of innovation, and then the “machine” time involved as well. For example, the time a programmer must spend prior to the launch of a build (not the coding time)—all the prep work doubling checking that the system is ready to launch the build scripts (or ready to manually push the buttons)—would be considered “human” time. The execution of the scripts to create the build would be considered “machine” time. Then, all the work done after the build is created to verify it and make sure things are as the programmer expected, again can be put into the “human” time category. DevOps will systemically automate both the pre- and post-time activities the “human” currently invests, so all that time will count in the ROI.

    The above example is good when one person has full control of a process from end to end. When other teams must get involved to complete a task, the “human” time begins to skyrocket. If, for example, a programmer or release manager, must get a request email (or ticket system equivalent) to deploy a particular build to a particular target environment, the entire life cycle of that ticket becomes part of the “human” time you need to track as your baseline metric. Even when shops create a two-day service level agreement (SLA) for turnaround, it still represents two days of delay (due to “process” time) in the life cycle of a deployment. The time “humans” actually spend reading requests, approving requests and routing requests is all time that DevOps will automate and eliminate. Finally, when the correct support team (usually Ops) pushes their own script buttons to do the deploy, that part of this process is once again “machine” time. As you can imagine, the end-to-end time of a given deployment can be days in the pre-DevOps methods and only minutes in the post-DevOps methods. Self-service deployments can reduce this time even farther, removing handoffs, reducing risks and delivering innovation at will.

    Further classification of this metric data can be useful as well. For example, you may wish to break down “machine” time into its relevant subcategories such as build script execution, deploy script execution, test script execution and release script execution. You also may want to break down the “human” time a bit further as well into pre-build/deploy verification, post-build/deploy verification and test script results evaluation. Finally, you may wish to break “process” time down further into request generation, request routing, request approval, request declination and request notification. DevOps will be able to give you discreet visibility into the time you saved in these subcategories, although since baselining is generally a one-and-done effort, you may not want to hunt this level of detail. It is down the road where this kind of subclassification becomes useful—for example when you are trying to determine if one set of tests runs faster than another or one cloud provider runs faster than another.

    Evaluating the Baseline

    Having gone through this exercise, a hidden or secondary benefit emerges. Your organization begins to understand much better what it has been investing in the current delivery of innovation processes. Generally, immediate areas of concern emerge and provide the DevOps services delivery with a road map for which areas to attack first to provide the company with the biggest bang for the buck. Without a baseline effort such as this in place, your DevOps services delivery plan will be based on anecdotal thinking or on executive mandate that may not be substantiated by the data on the floor. Having a baseline provides a road map for delivery based on concrete evidence on what should matter most to the business in making improvements. No one can argue with the numbers (assuming they were collected with care). The road map may reveal which applications in your organizations portfolio should be targeted first for DevOps.

    Also, your organization now understands much better “what” data in this process it sees as relevant to continue collecting even after DevOps is implemented. As DevOps is primarily an automation set of tools and methods, DevOps should be able to deliver these metrics in an ongoing basis. This allows continued metrics efforts to be automated without further human labor and can provide continuing proof of the value of DevOps to the organization, as over time the numbers continue to improve. Since the lion’s share of manual tasks disappear with DevOps in place, there should be no reason to have to manually collect metrics data as you move forward.

    Finally, having an automated metrics collection system put in place by DevOps, should lead to the next evolution in thinking: simulation. Well after the initial ROI for DevOps services has received the accolades it is due, an automated metrics collection system should provide all the raw data needed for some predictive analysis. Tweaking variables or process points or “machine” effectiveness should result in increased speed of delivery that can be measured (even before it is reality) based on the data you have been collecting systemically. Understanding the impacts of these changes is worth more than its weight in gold, because you can weed out the planned changes that simulation advises against before they even hit the road map, let alone occur in your world.

    Impacts to the Bottom Line

    There is already enough anecdotal evidence in existence to entice companies to embrace the DevOps journey. However, as your strategy begins to look to deepen down the stack from application code level to middleware, database and operating system, each layer could be assessed against a baseline to determine if your road map is sound and, more importantly, in the right order for your best ROI. This applies as well as you look to expand your DevOps journey laterally with additional services such as automated testing and evaluation, gated progression, automated provisioning, release orchestration, configuration management database (CMDB) integration, production provisioning on demand and monitoring integration. Each new service can be assessed against a baseline to determine if its ROI still meets the demands of your finance department and if your road map here is in the right order for biggest bang for the buck.

    The subtle win by performing baselining is the culture change it dispenses through your entire organization. Baseline metrics tell your development team and your operations teams (as well as the business units looking on) that you intend to measure performance and improve it systemically. Just because something was not examined before does not mean it will remain so, and a forest fire does not have to be the motivation to do so. DevOps is a proactive improvement to your delivery of automation. Collecting that baseline for your ROI, begins to seed the idea that proactive improvements are important to your executive teams. It is a demonstration of action over platitudes. It begins to eliminate the forest-fire responses in your employees, and creates a new forward thinking point of view. This cultural change is worth more to your company than any implementation of any one given tool or method, it goes back to changing how you think about delivering innovation in your individual job. That is what DevOps can do best.

    To continue the conversation, feel free to contact me …

  • Can DevOps Be Applied to Production Networks?

    Can DevOps Be Applied to Production Networks?

    The key goal of DevOps is to bring development and operations together, bound by a common set of practices. For this to become reality, developers need to think more like the operations team—focusing on stability and reliability—while operators need to think more like developers—focusing on agility and speed. But how widely can this be applied?

    We say regularly the goal of application development is to deploy new features into production continuously—daily, weekly or monthly, if possible. But what about the production infrastructure itself? Can we apply DevOps practices to making changes to the production infrastructure on which these applications run?

    Recently, I met with customers who want to implement DevOps practices to how they manage their operational network, applying continuous deployment to the production network. For example, they would like to design, test and then deploy new network services such as load balancing and firewalls into production immediately to enable new applications and services—actions that currently could take weeks or months. Is this kind of continuous deployment to be expected, or is it pushing DevOps too far?

    Let’s look at how key concepts of DevOps might be applied to adding network services to a production enterprise network:

    1. Virtualize services: To enable rapid deployment of applications, it was first critical that they be enabled with virtualization and in the future, with containers to make them portable. We would need to apply this same approach to production network infrastructure if we expect to enable rapid deployment of new infrastructure. Unfortunately, there is no standard way to make physical network equipment portable. Of course, shifting heavily to software-defined networking (SDN) enables virtualization for free, but it doesn’t make even virtual network equipment “standard.” In the world of networking, there are a number of “standard” interfaces and modeling languages: SNMP, NetConf, Yang and TOSCA (though not originally designed for networking), to name a few. Using one of these standard interfaces, in combination with virtualization, potentially could enable the agility required for continuous deployment of network services.
    2. Automate: DevOps success depends on automating the entire process of development, test and deployment so the process can be continuous. The same level of automation would need to be provided throughout the process of designing, testing and deploying new network services onto production networks. Network testing is very similar to other types of hardware and software testing so most test automation frameworks can be applied. However, network testing requires automation of the environment setup, and it also requires traffic generation to test with realistic network conditions.
    3. Continuously deploy: While this is still a dream for many companies attempting to achieve DevOps nirvana, a key requirement for using DevOps for production network configuration is to be able to deploy new services continuously into a live production network. Most of the configuration management tools available today are good at configuring servers and software, but are more immature when it comes to configuring networks, which are far more complex and inter-dependent than a single server. A tool would be required that allows the configuration of the tested network to be deployed automatically in exactly the same way within a production network.
    4. Monitor Operation: A good DevOps practice monitors applications in production and uses that information in planning new services. While it would seem that network monitoring is quite mature, an open question is whether that data is useful in planning future network services for improved operation.

    Sandboxes for Network DevOps

    Sandboxes are tools for defining and testing infrastructure configurations (physical, virtual and application). A good sandbox allows users to model any infrastructure, including any type of network infrastructure. This model also can serve as a way to implement “virtual services.” Models can be created in Yang or TOSCA, and under the covers these models can automate access to network infrastructure using CLIs, SNMP and/or NetConf where appropriate. This allows network services to be defined and tested using a high-level model, rather than the low-level interfaces.

    Sandboxes also address automation by providing a context for automating not just individual network components but also entire configurations and connectivity that are required for a “network service.” In addition, automation can encompass traffic generators and test tools as part of the testing process.

    Sandboxes also are designed to set up and tear down a network service automatically so they can be used for continuous deployment of new services. The same automation used to create the sandbox for a network service also can be used to deploy it into production.

    Finally, monitoring used in production also can be performed in the Sandbox to compare performance between testing environments and production so future services can be improved.

    While applying DevOps to production infrastructure and services is challenging and immature, in principle it can provide significant improvements in the speed of deployment of new network services—and the applications that depend on those services.

    About the Author / Joan Wrabetz

    Joan-CasualJoan Wrabetz is the Chief Technology Officer for Quali. Most recently, she was the vice president and Chief Technology Officer for the Emerging Product Division of EMC. Ms. Wrabetz holds an MBA from the University of California, Berkeley, an MSEE from Stanford University, and BSEE from Yale University. She has taught as an adjunct faculty member at the University of St. Thomas, St. Mary’s University, and at the Carlson School of Business at the University of Minnesota. She holds patents in load balancing, distributed systems and machine learning classification and analytics.

     

  • What ‘Star Wars’ Can Teach Us About DevOps Automation

    What ‘Star Wars’ Can Teach Us About DevOps Automation

    Perhaps no movie has ever received the same level of hype as “Star Wars: The Force Awakens.” Longtime fans yearned for the latest episode of the sprawling saga to bring back some of the magic of the original movies, while paving the way for the next generation of the “Star Wars” universe.

    In this way, the current state of “Star Wars” provides a useful way for understanding the infrastructure evolution situation that many IT organizations now find themselves in.

    ‘Star Wars’ and DevOps Automation

    Just as “Star Wars” has lots of previous characters and concepts—from Han Solo to the Force itself—to weave into its new properties, DevOps-minded teams have their own legacy infrastructure (admittedly, not as glamorous or nearly as profitable as the 1970s vintage “Star Wars” canon) to bring into a future defined by virtualization, automation and cloud orchestration. This modernization effort can go several ways depending on what approach is taken:

    • Organizations may quickly run into difficulties if they treat their DevOps initiatives as simply a new type of silo, one that is focused intensely on virtual and cloud assets without ample attention paid to legacy and physical infrastructure. You could say that a similar tack was taken with the first Death Star: Despite all of the focus on its planet-destroying weaponry and enormous tractor beam (which hauled in the Millennium Falcon), the space station’s designers neglected its basic heating infrastructure, eventually settling on a small exhaust port that was vulnerable to torpedo attack (and, indeed, was destroyed in that exact way).
    • On the other end of the spectrum, creating a culture of collaboration supported by highly capable technical tools can ensure that DevOps innovation takes hold and facilitates business agility. Think of this ideal as being similar to the relationship between R2-D2 and Luke Skywalker when the latter was piloting his X-Wing Fighter. There was not only a good understanding between the two of them, but also the powerful automation capabilities provided by R2’s advanced circuitry.

    The new Star Wars movie provides an occasion to see how old and new infrastructure, such as that inside the Millennium Falcon, can work together.

    Overall, we can see here both a “dark side” and “light side” approach to DevOps transformation. An old joke about the Force is that it is a lot like duct tape: it has a dark side and a light side and it holds everything together. Something similar could be said about the variety of infrastructure types that support critical business applications. They can cause a lot of problems (e.g., they probably can’t match the credit card-swipe convenience of Amazon Web Services), they can provide some key advantages (e.g., by being easy to control and secure on-premises) and ultimately they are essential cogs for supporting a wide range of applications, especially within bimodal IT setups.

    Why the Millennium Falcon Would Have Benefited from a Better Self-Service Portal

    Since we are on the subject on supporting and holding things together, we should talk a little about the Millennium Falcon, a ship that always seemed to be on the verge of breaking down in the original films. Its hyperdrive for making the leap to lightspeed was spotty at best, and it took its fair share of bruises. Keeping it in working order and out of the clutches of the Empire was a full-time job for Han and crew.

    Part of the problem was the Falcon was this weird mix of old and new technologies. It could travel at warp speed, fire lasers and make the Kessel Run in less than 12 parsecs. But it also required human pilots and gunners; plus, it was accurately labeled a “bucket of bolts” by Princess Leia Organa during a critical escape sequence.

    Maybe the Millennium Falcon would have run a lot more smoothly if it had a self-service portal that helped keep tabs on what was going on around its decks. Are the ship’s countless modifications playing nice with its older components? Is there a technical problem hidden in one of its smuggling holds? Is the holographic Dejarik table from Episode IV eating up too many resources? Having a centralized automation platform would have helped with these issues of accountability, visibility and IT governance.

    One could say that the Millennium Falcon was already a rough approximation of environment-as-a-service (EaaS), since it passed muster in automating a lot of heterogeneous infrastructures implemented and modified by its various owners. But it could have gone further in bridging the gap, just as many IT organizations can take additional steps to ensure DevOps automation success by working with software such as CloudShell.

    The takeaway: “Star Wars: The Force Awakens” provides an occasion to do more than sit back and enjoy the lightsaber fights —it’s also a moment to see how old and new infrastructure, such as that inside the Millennium Falcon, can work together. With an EaaS and self-service automation solution, IT organizations can bring their legacy, physical, virtual and cloud assets together into a more agile combination.

    About the Author / Hans Ashlock

    HansHans Ashlock joined Quali in 2013 and heads Quali’s worldwide technical marketing.  Hans has more than 15 years of software engineering, product management, marketing and sales experience in automation software solutions addressing, cloud, networking, telcom, data center, federal, and semiconductor industries.  Before Quali, Hans was a founding member of a global engineering services company, developing products and services for enabling adoption of automation technologies. Though he only holds one patent, he’s glad he didn’t have to pay for it. An engineer at heart, Hans is passionate about the transformation to software-defined everything and its impact on business and technology. Connect with him on LinkedIn, Twitter, and SlideShare, or at www.qualisystems.com.

     

  • Training & Certification Implications

    Training & Certification Implications

    Changing culture does not happen by osmosis, it happens through incessant education. The DevOps continuum of services your organization originally intends to create and implement is a journey more than a concrete destination. It will evolve over time no matter what your original plans were, no matter what your vendor of choice tells you, and no matter what resistance you meet along the way. If anything, resistance within your organization will push your journey left or right from its originally intended path. The lack of features in your tooling, or the introduction of those same features over time, will impact the journey of DevOps your organization will embrace. Culture is fluid. DevOps is fluid. So managing the impact they will have on each other should warrant dedicated concentration, and resources, in the form of training and education.

    Audience Educational Considerations

    It is not just your practitioner base that will need perpetual education to use your DevOps services to maximum effect. It is also the business community that relies on DevOps information and the executive community that may have sponsored the journey into DevOps in the first place. Education for the non-practitioner is more than just a matter of managing expectations, although that is a big part of it; it is a matter of helping this community learn to watch “change” or innovation as it moves from idea to production. DevOps will make an extraordinary impact on the speed of innovation delivery, as well as the quality or reliability of delivery. Engaging your business community and training them so they see this, comprehends what it means to them, and keeps them informed of the improvements will be critical to the long-term success of your efforts.

    Consider how managing expectations will impact adoption of DevOps services from a business point of view. When you first start on your DevOps journey, usually only the build and deployment services are launched as the “core” of the service. As you do this, you will need a way to keep your business community (i.e., the audience of what you do), informed as to your progress, and what key features or functions remain on the drawing board. How you communicate this information will be key to managing the expectations of your audience.

    For example, your initial efforts at build and deploy may only include the application code as its target. But over time you may begin to deepen what can be automated down the stack—say databases or middleware—as your next target. Eventually you are automating server O/S or even network definitions. If this is the services plan your organization takes on, you need to outline the timeline for expansion to the business community—not just in bullet points on a chart or timeline graphic, but specific benefits they should expect to receive at each milestone (i.e., why they should care).

    As your actual journey of DevOps begins, you may find, as an example, that you never get to network definitions in your automation efforts for one reason or another. Why you’re not reaching this goal needs to be explained, as well as the impacts of this. What drives this conclusion should also be explained; it might be for a very good or legitimate reason. But altering the DevOps journey needs to be ingrained in the business culture. Taking small steps, minimizing risk, learning from mistakes, and moving on—all are key lean concepts, agile methods, and ultimately they ensure the success of your DevOps efforts. The need to communicate changes in your plans to the business community helps manage expectations, but beyond that, it teaches the business community that information will be flowing constantly—and will be important constantly, even if it is brief in each segment.

    Whether your organization plans to expand DevOps services by moving down the stack, or perhaps by adding more capabilities laterally, you will need the ability communicate direction as well as “how” to take advantage of the expansion of DevOps you offer. So for example, if you are expanding your DevOps service by moving down the stack from app to operating system (OS), you will need to show the business community how to watch changes at each level (app, middleware, OS) or, if you are expanding your services laterally, adding automated testing, then release orchestration, then monitoring integration, and finally production provisioning automation. You need a plan for communicating each success, as well as “how” the business community can take advantage of what is accomplished.

    This communication plan should manage expectations, inform of changes in strategy or direction, inform of success/failure/alteration, and teach the business user how to use what you have done. Your communications plan may be looking at new data that was not previously available, or tracking innovation change differently. But educating your business community base will not be a “one-time” event; it will be a perpetual activity. Therefore, how you create this process should be built for perpetual delivery, not just a one-and-done delivery.

    The frequency of offering it will depend on the specifics of your organization’s needs. But the frequency should always keep pace with the changes and successes of your DevOps services delivery. If that is weekly, then weekly, if that is monthly then monthly. What you do to communicate, and how, will depend partly on that frequency and the size of your audience. Keep in mind your tooling vendor is also constantly enhancing its toolset with new features. The frequency of delivery may also need to incorporate those impacts as well.

    Practitioner Educational Considerations

    Educating your practitioner community generally is focused on tooling proficiency. But that may be a limited view. The architecture of your DevOps services is arguably more important than the specifics of how you use the build tool. Consider how your DevOps practitioners intend to accomplish the ability to scale build automation, as an example. I could just train the practitioners on how to use the build tool and then turn them loose, automating builds armed with little more than a cursory understanding of my preferred build tool. And over time using this training method, I will have as many methods to construct build automation as I have engineers who touch my tools, namely “n” methods. Having that much diversity in “how” I construct build automation creates variability that, with a large portfolio of apps, does not scale and is difficult to sustain without constantly throwing labor at it.

    Conversely, my architectural approach to build automation established by the DevOps team instead might be that each kind of technology uses a master template, or framework, as its approach. This information has little to do with a specific build tool and everything to do with the  organization’s “strategy” for build construction. That information becomes much more important than specific tool usage, because it affects “how” engineers use the tool according to company standards and practices. Training and creating a communications plan for reaching every member of your practitioner community on these items becomes critical to longer term success. This includes hiring new talent, departmental transfers and contractor augmentation.

    The additional consideration here is how you want to manage your intellectual property. “How” your company constructs build automation may be a proprietary advantage for your firm. This is particularly true if your architecture team is top-notch and able to create structures in your tooling that less experienced practitioners would not have even considered. If you train outside contractors on your methods, you are in effect giving away some of the farm. Non-disclosure agreements may keep a contractor from purposely sharing your methods with a competitor, but it will not prevent the engineer from learning how to make a better mouse trap while working with you. The contractor leaves your employ, a much more well-educated engineer than when he or she started.

    Once overall strategy education has been planned for and imparted to your practitioner community (another perpetual delivery method required), most companies focus on tooling proficiency. DevOps is still a relatively new phenomenon. And as such, certifications that are common in the networking world, for example, do not exist in the DevOps world. Gaining proficiency from vendor tools should be provided by those vendors as part of the licensing purchase agreement. If the vendor is unable to provide it in a formal delivery method, beware: The toolset is probably a new acquisition or too new in the market. If you are using open source tooling, a fully in-house model for training must be created and managed on an ongoing basis.

    Impacts to the Bottom Line

    Changing culture on a wide scale will require a focus of resources for training and education across your company. Engineers typically do not make the best communicators—that might be a DNA thing—so you may want to pair training and communication resource employees with the DevOps team to deliver what will be needed in an ongoing basis. The main consideration here is to realize that because DevOps services constantly will be evolving, communication plans need to keep pace with their evolution. And yes, I realize, this is additional overhead costs that almost no DevOps delivery person believes he or she needs when the services are first launched.

    But like all things, an initial publication or announcement is not sufficient to keep track with something that changes on a highly frequent basis. Adoption either can be facilitated by a good communications plan or thwarted by the lack of one. If it takes your company 15 months longer to get fully onboarded to DevOps because of delays in the rate of adoption (based on poor or non-existent communication), you must consider the costs of that delay in contrast. If after onboarding to DevOps, your business audience is ill-informed about how to use the services to maximum effect, what will that inefficiency cost the company? If your practitioners are only exposed to tooling proficiency once and without architectural oversight, what will the cost of the variability they produce in their automation be to the company?

    Investing in training and constant communication may not raise revenue, but it will certainly avoid costs. The measure of how much cost it avoids is difficult to track. Most companies who make the investment understand intrinsically what the alternative would be, and choose not to go down that road. The only admonition I would offer is that I have seen clients make this decision late in the cycle, and every one of them did so because the pain motivated it. Your strategies for DevOps should be comprehensive in perspective, if you need help crafting or improving yours, contact me—I am looking at the moment.

    To continue the conversation, feel free to contact me.

     

  • Mobility and Quantum Adaptation

    Mobility and Quantum Adaptation

    As you look at the preponderance of DevOps tooling solutions available today, you notice similarities in deployment automation and how they work. DevOps is purported to be the most significant catalyst for change in how we innovate in the last two decades. Yet, as you examine the tooling and the strengths and weaknesses of each, so many products are strikingly the same. It seems to me that if DevOps is to ingrain itself in IT culture, it must use its own principles to remain current, or remain fresh in the coming years. The doctors of IT must learn to use the tool of change to change it once again, and then again, and so on.

    Case in point: The deployment discipline of DevOps is premised largely on a “controlled” rollout. Deploying versions of code and versions of applications into production is a fully controlled event. Our entire release orchestration (RO) discipline is merely an extension of our basic deployment tooling. RO tools add governance and quality assurance (QA), segregating it directly from a specific deployment and handling it more broadly in a release event. But whether we are examining a deployment tool or release orchestration software, both rely upon a premise of controlled distribution of applications to their respective destination.

    The Mobility Disruption

    Mobility, or mobile apps, disrupt this thinking. The platform our Apple partners have given us (in its current form, though I understand that is evolving as we speak), is based on an “at will” acceptance of a new version of a given application. When I look at my phone, I see a red balloon informing me of how many application “updates” are available for me to accept. I can decline an upgrade just by not taking any action. This is true, even of the newest version of the Apple OS (the foundational building block of application capabilities). Or, when I am home on my Wi-Fi network, I can at my leisure begin downloading and updating the various software application versions to the latest offerings. All are my actions, determined completely by my choice.

    It’s a little different on my PC—I have more flexibility of what version I have running on this platform, at least in terms of rollback. If I do not like the next version of my web browser, I can pull up the site and choose an older version to use on my PC, until the errors that bothered me are resolved in the latest offering. Mobile apps, in the mobile catalog so many of us use on our phones, offer no such options. Once I have updated the application to the latest offering, I am stuck with it, errors and all. If it becomes too intrusive to my work efforts, I would have to pick something else to take its place, or just stop using it and wait until a new version is available again.

    DevOps deployment tooling is foreign to this model. The servers in production do not get a choice about whether they intend to accept our deployments, and when they might get around to it. They do what we tell them to do, and when we tell them to do it. But it seems updating our servers, upon which future versions of applications will rely, does not cover the last mile of our application delivery. Mobility is accomplished ad hoc, by consent, and without controls on my part.

    This has an immediate impact to my thinking about application distribution (and how DevOps will play in this new world). If I make a catastrophic change to the servers my mobile apps rely upon (that is, a change where only the new version of the app works), it will require my users to upgrade, or stop using the product as it sits today. This is dangerous if my application is utilitarian (not critical to daily life), and could be replaced by a competitor. It might mean that my applications must seek out version-specific back ends if I want to have multiple versions still working until people get around to upgrading. That costs time, money and support. Either case forces me to think differently about distribution.

    You can imagine how angry you might be if your online banking software just stopped working. Mobility in its current form also makes rolling back to a previous version a near impossibility. So if the new version of the app has a bug in it that prevents key functionality, I am going to get a huge black eye with my customers, and must race to produce a new version minus the old bug, even assuming universal adoption. Alternatively, my customers may be using the buggy version for a while before they choose to upgrade to the bug-free version.

    There is tooling for corporations to more tightly control a provided device or even govern what happens to personal devices for corporate software. But the ability for DevOps deployment solutions to integrate with a mobility platform requires a new way of thinking. The limitations and the new capabilities must be taken into account specifically before any vendor can legitimately offer a holistic solution for DevOps for mobile.

    The Quantum Obliteration

    Quantum computing is likely to prove once again to be another disruption to our DevOps model. Evolution will help us bridge the gaps and minimize the impacts. But consider that quantum systems are not based on a foundational binary model. This is not like English speakers having to learn the Cyrillic version of the alphabet to read and write in Russian. No, it is more like communication will be telepathic from now on. The entire constructs of binary will eventually fade into the history books, and a new construct will emerge in its place.

    Today we use binary-based computing systems to attempt to converse and control the quantum systems built so far. When you don’t know how to communicate telepathically, you use what you do know: reading and writing. But it will take a long time before the power of quantum computing is truly unlocked; until then, we have to constrict its capabilities with binary-based computing methods. When native quantum languages, and perhaps hardware, are let loose, the true power of the platform will be better understood and impacts experienced.

    How will DevOps play in a quantum computing environment? Will the fundamentals about deployment and distribution once again evolve to incorporate the impacts of new quantum platform capabilities such as entanglement? Or will we experience what we have in the mobile platforms of today: a series of catchup steps to deal with what is different? If we use our catalyst of change in DevOps to begin to think differently about our own future and the capabilities our tools should provide, perhaps DevOps will still be unlocking possibilities none of us dream of today. If not, I foresee DevOps becoming only another fad, replaced by the term we give to the next wave of innovation thought needed to unlock our future.

    To continue the conversation, feel free to contact me.

  • Call for Papers Now Open: CD Summit and Jenkins Days Fall Tour

    Call for Papers Now Open: CD Summit and Jenkins Days Fall Tour

    After a successful spring run, devopsy.kinsta.cloud, where the world meets DevOps, along with premier sponsors, CloudBees, the enterprise Jenkins Company and IBM, today announced that their DevOps Connect: CD Summit/Jenkins Days roadshow will continue this fall with seven dates in the United States and Europe. The call for speakers to appear at these events is now open. Today we are announcing the shows will be coming to Atlanta, Denver, Austin, Seattle, Los Angeles, Berlin, and Amsterdam.

    I began my employment at devopsy.kinsta.cloud as a web admin and social media manager. Shortly thereafter, I became marketing and media manager. I had decent education surrounding web scripting (HTML/PHP/CSS/Photoshop), but none about DevOps and software engineering. I attended the spring events and had a front-row seat to the summits and what they had to offer. The keynotes offered a plethora of information surrounding Jenkins, BlueMix and how to undertake a DevOps transformation at the corporate level. We were honored to have Kohsuke Kawaguchi, CTO of CloudBees and founder of Jenkins, offer his unique perspective on the growth of Jenkins, joining CloudBees, and the development of recently released Jenkins 2.0.

    Our other two keynotes featured individuals we were lucky to have. Gary Gruver, who led the transformation at HP and Macy’s, outlined what he walked into, how he changed the company, and what happened when we walked away. He gave a clear-cut story about the transformation he embarked on when joining those companies. The third keynote came from Mustafa Kapidia of IBM. Mustafa was such a captivating speaker who really knew how to gauge his audience’s knowledge surrounding DevOps and continuous delivery.

    The breakout sessions in the afternoon following lunch offered a bit of something for everyone. There were three separate tracks: technical, management and Jenkins. The technical track was just that: a track devoted to the more technical-oriented crowd such as engineers and developers. The management track was devoted more to those looking to undergo transformations, incorporate DevOps at their workplace, and manage DevOps teams. The Jenkins track focused solely on information that was connected to utilizing Jenkins in the workplace.

    In addition to the summit itself, CD Summit and Jenkins Days feature a day dedicated to workshops on DevOps, IBM BlueMix and Jenkins. These were a hit from the get-go, pulling in people of all levels, from developers to executives wishing to broaden their knowledge. The fall will feature the workshop day as well.

    I met a lot of people during my time at these events, cementing the fact it is a great place to network and learn about different companies and how they are doing devops. Prior to attending these events I only knew a small chunk about DevOps/CD/CI based on the articles we publish on devopsy.kinsta.cloud and from my interaction with professionals in the industry. By attending the events I expanded my knowledge, greatly improving my capacity to understand what occurs from the junior level to the executive level at a company utilizing DevOps practices and principles.

    According to the press release, “These events are designed for Enterprise Managers and Buyers along with Developers, Engineers, Sys Admins, and Architects. With three main tracks focused on IT managers, technical engineers, and Jenkins practitioners, attendees will get access to the best minds in CD and DevOps. The presenters are experienced developers, build managers, QA, DevOps practitioners, IT managers/executives, architects and IT operations who are luminaries within the DevOps community.”  I would recommend attending this event for anyone who fits this description, and for anyone outside the realm of this description who wishes to learn more about DevOps or continuous delivery.

    Today we are opening up the Call for Papers for the fall events. Anyone who would like to submit their entry can follow the respective links below for each city:

    For more information please visit http://www.devopsconnect.com

    Link to the press release: https://devopsy.kinsta.cloud/2016/06/27/devops-connect-cd-summit-and-jenkins-days-fall-schedule-announced/