devopsy.kinsta.cloud

Author: Michael Schmidt

  • 5 Prerequisites for a Successful DevOps Initiative

    5 Prerequisites for a Successful DevOps Initiative

    There are certain tools and attitudes that are essential to any successful DevOps transformation.

    The manner in which a DevOps transformation is performed will have huge implications on the level of agility the company is able to achieve. However, before that point is even reached, some vital foundations must be laid. It is from that foundation that any innovation occurs. With that in mind, each of these elements are equally important, and should be regarded as such.

    Consensus

    Your first achievement on the road to successful DevOps should be an agreement on what DevOps means to your company and how it should be applied to your needs. Consensus on a strategy is almost as important as the strategy itself and must be in place before a detailed road map is constructed. Remember that DevOps is subjective and its implementation should vary from company to company. Consensus hopefully will be easy, but if not, it must be built by persuading doubters of the need for certain principles and practices selected.

    This is the first step on a cultural journey; the collaboration between Dev and Ops staff and their consensus on a plan could make or break the DevOps idea. The concepts behind the initiative need to be agreed on from all corners of IT, as well as the business and any other key stakeholders such as suppliers. It is important the cons and pros of switching to DevOps are made clear for a balanced proposition. The argument for a shakeup on this scale needs to be compelling and justified for it to go ahead.

    Consensus also involves handling expectations. To keep everyone happy there must be metrics and approximate timelines set in place so everyone knows what to expect and when, to avoid conflict further down the line. Only once consensus has been achieved and the basics are put in place can a more detailed road map be built.

    Flexibility

    A thorough road map is the skeleton that allows its muscular teams to flex independently toward a common goal. However, flexibility without allegiance to the agreed principles can cause chaos. The DNA that runs through all teams stays the same but applications vary, and so teams need to work autonomously if they are to cater for the specific needs and nature of the app they are working on.

    While the road map gives a structure and handles expectations, DevOps culture needs to be tied to business outcomes and not formal internal milestones. Each DevOps team needs to be trusted to interpret the road map as it suits the specific project they are working on. Agile methodologies must be used, of course, but their interpretation is devolved to the teams themselves. This license and trust is key in allowing DevOps teams to react quickly and mold around the needs of the individual application.

    Teams need freedom in terms of what tools they use and to an extent, how they use them. The methodology used to achieve the agreed core principles should have an element of flexibility. Tool-agnosticism is a must when choosing an automation solution for effective DevOps. Teams are happier and work faster when allowed to choose the tools that suits them best, making them more successful.

    Automation

    As C. Little said, “DevOps isn’t about automation, just as astronomy isn’t about telescopes.” An automated continuous delivery pipeline should underpin any DevOps initiative, adding consistency and reliability to flexible delivery methodologies. Tribal knowledge from Dev and Ops is gathered to create a pipeline that is the sum of the knowledge of its contributors. The pipeline is repeatable, and over time is made more efficient by rooting out inefficient manual processes. Modelling into a workflow helps all involved visualize where a team is in the app life cycle and what next steps need to be taken next and by who.

    Trust in application release automation can be a big deciding factor in how companies achieve successful DevOps practice. Sometimes there is a culture within a company of wanting to have manual control over certain processes that inevitably slow things down. Automating any and every manual task possible is essential to speed up DevOps. If a manual intervention is needed, the relevant member of staff can be notified by the automation solution itself, which automates out the remainder of the task for which manual intervention is not required. Over time, manual interventions will disappear altogether.

    The ability to give DevOps teams freedom in their tool selection keeps staff productive but adds yet more complexity and leads to a highly heterogeneous workplace. It’s important your automation solution has approved integrations to all tools DevOps teams might choose and also releases free integration to new tools quickly, so you can stay on top of the latest trends and continue to be successful.

    Cooperation

    Unless you’re a startup with heavy investment, you’ll likely be changing the structure and workload of your existing staff rather than hiring a new team suited perfectly to their individual roles. The success of DevOps depends on the ability to make positive change in the way team members collaborate.

    Resistance to change may occur due to staff being accustomed to working in one particular way for a long time. However, this could also be down to personality type. As it is Ops and Infrastructure staff who face the biggest changes and are used to limiting rather than encouraging risk, often they can be the most resistant to change. Often devlopers do not have to change the way they work to the same extent, so fewer feathers are ruffled.

    I have seen big corporations that do not have compliance from everyone, so their DevOps is limited in scope and unfortunately they will never reach full agility. Sometimes you must adjust your teams to ensure positivity to DevOps and receptivity change in general.

    Rethink Architecture

    I’m not saying DevOps cannot be implemented in legacy systems, but there are elements of legacy systems that make it hard to instill full automation and continuous delivery. What is important is that the organization is open to a certain degree of architectural change. Monolithic apps can certainly slow down a DevOps initiative—often it’s mainframe apps that are not built with a service-orientated architecture—so it’s important to know how to adapt them to fit your strategy.

    A full architectural revolution is not needed to be successful. Obviously this is where cloud-native startups have an advantage as they can assemble their infrastructure from scratch, but there is no need to rip and replace existing systems for the sake of it and waste money. Certain elements of even the most monolithic systems can be modernized—for example, Siebel deployments can be fully automated so operations staff are free to concentrate on more demanding aspects of the cultural change DevOps involves.

    DevOps applications can interact with legacy systems if we use the right techniques. Make sure your automation solution has integrations with the likes of SAP, Oracle and Siebel, and so enables legacy systems to be enablers on your digital journey rather than obstacles that will stand in your way as you seek to reach full DevOps and end-to-end continuous delivery.

  • Does the Future of DevOps Lie in NoOps?

    Does the Future of DevOps Lie in NoOps?

    Why DevOps is more a bi-directional rather than a simple top-down approach

    DevOps is one of those buzzwords that nearly everyone wants to discuss these days. However, it often is interpreted as an extension of Development’s influence to the detriment of Operations teams.

    So much has changed in the past few years that it is conceivable we will see another major shakeup: Could Operations teams disappear altogether? Or to put it another way, is “NoOps” the future of IT? While DevOps promotes faster delivery of new digital services and a blurring of the lines between Dev and Ops, in reality, is Dev consuming Ops entirely?

    Before DevOps was called DevOps, the two disciplines were growing further apart. Agility has been driven by Developers since the turn of the century, with the famous Manifesto for Agile Development. Meanwhile, Operations formalized repositories of good practices into frameworks such as ITIL or COBIT, which were implemented by most large companies in the mid-90s. Those two approaches seem to oppose, as DevOps advocates the acceleration and multiplication of changes and ITIL tends to monitor and control them.

    NoOps, or the End of Operations?

    If you believe everything you read, then Operations is a dying art. But in practice, Development does not want to be involved with infrastructure, while few organizations would trust developers to manage their data centers, whether physical, virtual or cloud. So breathe easy: DevOps does not mean the end of Operations teams.

    On the contrary, Operations remains essential throughout the DevOps approach. Production infrastructure is a complex and delicate stack of technologies, often with a discreet mix of modern architecture and historical applications. It often is impossible for Development to replicate these types of environments. And that is why an application successfully tested in a qualification environment often does not work properly in production. However, it is crucial to validate new developments in a representative replica of the production environment.

    So is DevOps doomed to constant failure because of lack of continuity between qualification platforms and production systems? Well, this is probably the case if we merely consider DevOps as a simple top-down approach from Development to Operations. Focusing on producing changes at a higher frequency only shifts and grows a bottleneck that sits in production, without producing the added value expected by the company. As a consequence, DevOps must also be seen as a bottom-up process. In other words, if we consider DevOps, we must also take very serious look at “OpsDev” (OK, it doesn’t flow off the tongue, but you see my point!).

    DevOps or OpsDev?

    For a successful DevOps approach in practice, Development must position itself as a consumer of turnkey infrastructure environments. Operations then adopts an OpsDev approach and provides infrastructure on demand for all steps of continuous integration, from compilation to qualification, through unit testing.

    If DevOps is a radical change in how Development works, OpsDev would also revolutionizing common Operations practices. It comes with more agile “declarative” infrastructures (described and built from source code), an even more sophisticated level of automation and the ability to provide self-service infrastructure for developers.

    The adoption of DevOps does not mean that Operations will disappear or will be replaced by Development, but rather the emergence of bi-directional agility that needs to be supported by more sophisticated automation. In fact, DevOps implies OpsDev rather than NoOps. Finally, whatever you consider your release process under the ITIL or DevOps angle, isn’t the end goal exactly the same: delivering zero-default service to customers?

  • Release Automation: Bigger than DevOps

    Release Automation: Bigger than DevOps

    Why DevOps is not for everyone and how release automation helps in bimodal world

    So am I really going to write a blog calling DevOps a big hoax?

    Well, not exactly, but as a follow-up to my previous blog on the difference between DevOps and Continuous Delivery, I want to alert you to a few key facts:

    1. DevOps is not always the right methodology for developing and delivering software.
    2. Agility and speed can be achieved even in a waterfall method if the right tools are in place.
    3. Release automation is bigger than DevOps (yeah, I said it!).

    Say No to DevOps?

    Okay, so here goes: Why is DevOps not always the right way to go? Simply because not all systems are born equal. For a back-end master customer data system, stability trumps iteration. Fail fast and roll forward simply aren’t sustainable in many of today’s most core business applications such as banking, retail, media, manufacturing or other industry vertical. Clearly, these enterprises still need to innovate and provide new and exciting ways for their customers to engage through web and mobile, but not at the risk of a terminal business failure at the back end.

    Delivery capabilities for these back-end systems need speeding so they don’t become the bottleneck for the entire business. However, restructuring teams and changing development along with test and release into tens and hundreds of small/tiny parallel updates cannot be supported by a legacy technology stack (say Siebel or SAP at the back end). It is likely not even advisable at all.

    This doesn’t mean we should accept the realities of the last century, resort to the status quo and leave our release cycles to once or twice a year for key applications. Slowly and surely we would lose any competitive edge.

    Luckily there is a middle ground, and this is why I believe release automation is bigger then DevOps. That middle ground is release automation. I will explain why, but I need to start by examining DevOps a little more first.

    What is DevOps?

    At its core, DevOps aims to get new ideas and functionality into the hands of users quickly and iterate fast. It achieves this by fixing two traditional weaknesses in the software delivery life cycle, namely “overhead” and “rework.”

    Overhead is anything that developers do that isn’t directly related to developing new features or improving existing ones (manual deployments would be a big item in the overhead column for sure, as would debugging production deployment issues or handling configuration problems).

    Rework occurs anytime developers have to go back over a piece of code they already have worked on. However, this does not include bug fixing, so rework occurs when test cycles take a long time and developers already have been working on new functionality, which now needs to be reworked to address a newly found problem.

    DevOps tackles these challenges by attempting to shorten the cycles—for example, by adding smaller changes that developers and testers can test in real time or by using tools such as Puppet or Chef for provisioning quickly to test while ensuring consistency across systems.

    This relies on Devs owning updates and rollouts across the life cycle, including production, which challenges everything in the way enterprise teams are traditionally organized. It calls for completely new processes, which often are a great fit for newly developed applications and modern architectures, but can be a complete misfit (and regulatory obstacle) for so many other core systems.

    I’m sure you can see where I am going with this. Much like the story, “The Emperor’s New Clothes,” DevOps isn’t what people believe it is.

    Why Release Automation is Bigger Than DevOps

    The goals of DevOps are sound, however, which leads me to my last point: Release automation is bigger than DevOps. Done right, release automation can accommodate diverse organizational needs and different types of applications in this new, bimodal world. It improves the software delivery process and its final product by rooting out manual work, improving cycle times, reducing overhead and rework.

    Crucially, release automation enables incumbent businesses to stay competitive and ensure survival without forcing them to completely abandon their DNA across the board in a “big bang” fashion. Such a process could put the very existence of a large enterprise at risk.

    Before signing off on this blog entry I want to make one last thing clear: The argument I am raising here isn’t trying to downplay the benefits of DevOps as a valid methodology. Nor am I denouncing any of the DevOps tool chain technologies out there, which are all welcome advances, of course. This year, 2016, is (according to most industry experts) the year in which DevOps adoption goes mainstream, and I fundamentally believe that it is release automation that drives this adoption, not just pure DevOps conversions.

    Stay tuned!

  • DevOps and Continuous Delivery: Not the Same

    DevOps and Continuous Delivery: Not the Same

    DevOps and continuous delivery are the same thing, right? Far from it. We peer through the fog to understand the difference between the two related but distinct methodologies.

    We live in an era of apps. More and more of our personal, social and work life is governed by apps—communicating with one another through social apps, booking cinema tickets through your mobile device or scheduling a business trip through the airline app. This digitization of services has arrived. Organizations that understand this sea change have a unique opportunity to jump ahead of their competitors, acquire customers more quickly and grow revenues.

    The battleground for this service development is DevOps. It’s not a product, but rather a methodology for helping organizations build teams and build software. DevOps is a culture, movement or practice that emphasizes the collaboration and communication of both software developers and other IT professionals while automating the process of software delivery and infrastructure changes. It creates a culture and environment where building, testing and releasing software can happen rapidly, frequently and more reliably.

    Organizations are marching with their feet. According to a recent study, market demand for DevOps skills is growing, and DevOps engineers are among the highest paid IT practitioners today. And it looks set to stay that way. Research in the U.K. shows that 30 percent of 300 organizations surveyed in the run up to the 2015 DevOps Summit had either started to implement a DevOps strategy or had already merged Dev and Ops, with another 13 percent planning to go down this route.

    Two Related Children: DevOps and Continuous Delivery

    So now we arrive at continuous delivery. If DevOps is about accelerating the delivery of new, high-quality services, surely continuous delivery is the same thing, isn’t it? In other words, ensuring a steady stream of new services? You might look at it as a manufacturing production line: DevOps is the machine that builds the service, while continuous delivery is the conveyer belt that rolls the services off the production line—one big unified service development cycle.

    That’s not the case. Although the distinction between DevOps and continuous delivery can be a little grey and cause confusion, there is in reality clear water between the two. Continuous delivery has become an essential ingredient for teams doing iterative and incremental software delivery. It is an approach whereby teams ensure that every change to the system can be released, and that any version can be released at the push of a button. Think of it this way: Continuous delivery aims to make releases dull and reliable, so organizations can deliver frequently, at less risk, and get feedback faster from the end users until deployment becomes an integral part of the business process and competitiveness of the enterprise.

    Gartner summed up the distinction between DevOps and continuous delivery very neatly with a report that stated, “DevOps is not a market, but a tool-centric philosophy that supports a Continuous Delivery value chain.” The analyst argues that bimodal and digital business strategies stimulate demand for improved speed and effectiveness of software delivery.

    Continuous delivery and DevOps do share common traits, though. Both methodologies are aimed at agile and lean thinking: each delivers small and quick changes; each relies on tight business an IT collaboration; and each share the common goal of faster time to market for new services.

    However, the goal of DevOps is merge dev and ops roles together—and the processes they manage—to achieve business goals. It’s all about a common, shared culture and enhanced collaboration. About clearly defined business processes.

    Automation has an essential role to play in both DevOps and continuous delivery. Automating DevOps helps your organization manage and secure continuous delivery to the business and IT users. The result is a faster, low-risk migration to a new world of composite applications, faster business innovation and better support for rapidly changing business process needs.

  • Are You Ready for Your DevOps Transformation?

    Are You Ready for Your DevOps Transformation?

    You’re done with missed release deadlines, long release cycles and risky releases. If your objectives are continuous application delivery to achieve fast feedback loops and reduced waste, DevOps practices provide the means to reach them.

    DevOps is all about agile transformation, which reaches beyond agile development into production to achieve continuous delivery. DevOps practices provide help for the necessary next step after agile development to leverage the full potential of agile and avoid massive post-delivery changes through the development teams, but before they are ready to go into production.

    The challenge is to navigate that DevOps transformation—and make it happen faster and at less risk. The speed and direction of that transformation depends on individual circumstances—for example, the type of technology you have deployed, the shape of your organization structure and processes, and what your overriding business and IT requirements are.

    Beginning the Transformation Journey

    Only once you have assessed your organization’s current DevOps maturity and orientation can you begin to scale your DevOps implementation—and move faster on the transformative journey toward continuous delivery. In other words, to know where you’re going, you need to know where you are now.

    transformationBy measuring your status across each of these dimensions on a scale of Level 0 and Level 4 (see diagram), you can benchmark where you are today and derive recommendations and measures for future improvements.

    Culture and Strategy: DevOps requires a strong vision and strategy and its success will depend on the awareness, knowledge, skills and motivation of your employees. This pillar addresses the effectiveness and alignment of your awareness-building and enablement programs as well as your incentivation system with regard to agility in all involved units, dev and ops. It also includes a snapshot of the sentiment and motivation of people to make such a change reality.

    Automation: This pillar addresses the maturity of your organization in terms of IT automation as an important prerequisite for continuous delivery. Both the application architecture and the DevOps automation tool chain are assessed. Relevant automation capabilities in application configuration, provisioning, deployment, test, infrastructure and application monitoring are included in the assessment. The maturity is assessed across the tree layers infrastructure, platform and application, and by technology stack—for example, your SAP platform, .NET or Java stacks—and then combined into a single level.

    Structure and Processes: The current organizational structure and methodologies and processes in use within all involved units are assessed with regard to their effectiveness for continuous delivery. This focuses on their agile fit and maturity. Governance and how agile teams and processes are embedded into the broader organization are part of the assessment scope as well.

    Collaboration and Sharing: Collaboration and sharing between development, operations, infrastructure and middleware teams are crucial to accelerate the delivery process and make it leaner. The assessment looks at particular sharing vs. redundancy of tools (e.g., tools used for deployment), information (e.g., the status of a package in the delivery pipeline), processes (e.g., an ITIL release process and a development release process) and functions (e.g., a release engineer in development and a deployment expert in production).

    Now you have the facts at your fingertips. The DevOps Maturity Assessment Service presents all of this as documented findings, to include a series of recommendations on how you can scale and mature your DevOps activity.

  • How Mature Is Your Automation Strategy?

    How Mature Is Your Automation Strategy?

    Working in Operations can sometimes feel like walking up a down escalator. The business puts relentless pressure on your team to overcome bottlenecks, accelerate the overall delivery process and grow the volume and frequency of deployments. You’re also faced with a growing number of service level requirements and demand for higher release velocity—all stretched across different platforms and increasingly complex deployment scenarios, on premise or hybrid.

    The answer to these challenges is IT automation. Scaling your automation not only secures continuous service delivery, it also frees your resources to focus on core activities and industrializes more service management processes, such as self-service portals for infrastructure provisioning.

    However, many organizations are still on low automation maturity levels because of various barriers, including:

    • Organizational inertia
    • Lack of process capability maturity
    • Lack of the right technology expertise
    • Mistrust and fear of getting replaced

    Do you recognize some of these barriers to automate faster, better and more in your organization?

    Here’s the problem: You can determine how much and where that IT automation is needed only after you understand the current state of your automation. Are you still at the manual stage (level 0), copying new release files in the production environment, adjusting parameters and restarting the application service via a management console using manually entered parameters, for example?

    Are you automating repetitive tasks through scripts, but need to do all the preparation work to run the script, frequently modify the scripts and script parameters based on changing context, start scripts manually, monitor their execution individually and look at the outputs each time a script runs? If so, you are on level 1—and you can do much better than that.

    Are you connecting scripts into sequences and deploying new releases using a run book automation tool (level 2), where integration with other tools in the release chain is still manual and context-specific parameters have to be set individually for each execution?

    Or have you scaled the heights of process automation (level 3), where you benefit from the automated deployment of the entire process, including automated retrieval of the right parameters at the right time and in the right context triggering of automated deployments (either using commands or driving run book automation tools), confirming completion and updating records? If so, you are doing very well and can reach the last (final) maturity level by adding dynamic composition and configuration of processes based on the real-time context.

    Understanding your automation status and barriers helps you decide how and where to invest in the next automation steps. Having a baseline means you can build a business case, apply goals and targets to your organization, and measure your success as you progress.

    An Automation Maturity Assessment Service can be applied to create this baseline, identify gaps and provide recommendations, which result in lowering the manual effort and increasing your IT automation maturity and operational efficiency. Consultants initially review your current IT infrastructure and your software delivery processes and release management processes. Next, they perform discovery interviews to gather information on core processes relevant for automation. Services are subsequently rated in terms of their automation maturity and their potential for automation. The qualitative results are then correlated with operational measurements and KPIs to understand the impacts of low maturity on service levels and competitiveness.

    The assessment might find, for example, that your development team changed its deliverable for a particular application to a Docker container, which is currently not integrated in your automation release and deployment process. Your tool already supports Docker, the assessment finds, and it can be easily integrated. The benefit to do this is assessed as ‘medium,’ while the cost is ‘low.’

    Based on the results, a business case can be created or a DevOps roadmap can be crafted.

    You already know the benefits of IT automation. By allowing your automation to mature, you open the door to even greater cost savings, increased efficiency and lower risk.

  • Continuous Operations: Implications on IT automation

    Continuous Operations: Implications on IT automation

    With the increased adoption of cloud-based services, users are now accessing their applications through multiple channels and device ‘endpoints’. User experience expectations, which are constantly rising, now have to be met across multiple channels to avoid customers dropping of your website or app and never returning again. Minutes of service downtime or response slowdown may result in thousands of prospects and millions of revenue lost. This imposes enormous challenges on the operations of the applications and services, which have to ensure the permanent availability of applications and services.

    A continuous truth

    This means that operations of applications and data services need to be continuous without interruption. Availability and Performance cannot suffer from ongoing releases, updates and patches – downtime is a luxury of past times. Continuous monitoring of infrastructure, applications and services has to be tied to automated remediation. Events raised from monitoring trigger automated processes to add server nodes, storage or network capacity in a “hot” mode without service interruption or to re-distribute load to different locations and data centers to fix performance issues.

    All of this is impossible without a solid automation architecture. Orchestration of automation is key.

    Orchestration of automation has to ensure that different tools and systems in the operations management chain are properly connected and hand-off points are automated to achieve end-to-end automation across silos.

    The operations management tool chain includes monitoring tools for the different layers as well as network and storage management, server virtualization, database management, application server management and IT service management.

    With the right automation platform in place you will be able to connect these tools into fully automated end-to-end processes and at the same time ensure that these processes can be monitored and controlled in a reliable manner.

    In addition, pay specific attention to automation of release and deployment.

    It is hard to escape the increasing demand for faster releases to constantly introduce new features, improve usability, fix defects and security loopholes. At the same time, service interruption is not an option.

    Only with the right deployment architecture and tools in place you will able to handle this challenge.

    Continuous operations means users never even know upgrades have happened — until that is they start to enjoy the additional functionality experience that comes from the upgrade itself.

    The end-to-end challenge

    The challenge today is an end-to-end one. As Gartner research director Robert Naegle has said, “Gartner research shows that it is still more common to see automation technologies popping up in functional islands, with I&O management later attempting to aggregate and orchestrate disparate technologies, scripts and workflows.”[1]

    The imperative now is one that centers on bringing continuous automation technologies to bear an end-to-end basis. In this way they can facilitate the seamless integration from the business processes through the IT services supporting those processes and the delivery of applications to differentiate the business.

    [1] Gartner, ‘Hype Cycle for I&O Automation, 2015’, Robert Naegle, Gartner, 7th July 2015

  • How to accelerate your production integration activities

    How to accelerate your production integration activities

    IT Operations is often accused to be the bottleneck in application release processes and a general constrain to agility. But why is that, what are the root causes of this issue and how can we address them?

    There is indeed a very big gap between the desired world of DevOps with Infrastructure-as-Code, Docker, Microservices Architectures, Private Cloud and the Software-Defined Data Center and the realities of most software delivery in enterprise IT today.

    Ideally tools are shared between dev and ops, information flows in real-time, everything is measured and visualized through dashboards and release pipelines are fully automated.

    In reality, however, each major release of enterprise software requires a myriad of preparation activities from IT operations and infrastructure to ensure the operational readiness of the release in production. We call the set of these activities production integration.

    We put these activities into four groups:

    1. Batch automation. New application releases often require new jobs and changes to jobs and job plans. Their impact on existing production chains must be assessed and controlled.
    2. Data Migration automation. Operations and infrastructure frequently has to support the data migration process and provide the technical foundation and automation.
    3. Deployment automation. Changes to deployment plans and application components will impact existing deployment scripts and routines. They need to be updated and re-tested.
    4. System Provisioning and Configuration. In the course of a new release, it is often required to add infrastructure such as servers, storage and network bandwidth. On top of it, middleware and databases need to be prepared for the new release.

    Through over 300 customer interviews we identified the main reasons:

    • Lack of software engineering methodology: Employees with sound software engineering skills are very rare in ops departments. However, sound software engineering practices are critical to build re-usable and modular automation frameworks and libraries. Without that, the risk is high that automation is created again and again for similar purposes without cleverly re-using what is already available.
    • Priority Conflicts: In many organizations, the same teams work on production integration and production support. Urgent production issues cause shifts in priorities and delays in integration activities. The problem is exacerbated, because specifications for production integration tasks are often received late in the process, not leaving enough of time for the teams to deliver.
    • Organizational Constraints: Over-specialization causes bottlenecks. We all know this database administrator, who is the only person in the company able to identify and find the root causes of performance problems, or this application server expert, who exclusively owns the deployment scripts. Also, dislocation of teams causes communication overhead and slows down the process.

    We have identified a set of measures to address the most obvious obstacles to more agility and speed in the production integration process and increase its transparency. We call this the DevOps Production Integration toolkit. It is based on three pillars.

    Agile Enablement of ITO: We recommend organizing the delivery of production integration tasks through a tailored version of Kanban. We have developed a methodology to integrate Kanban-driven ops with SCRUM-driven development in a scaled organization.

    Kanban is based on managing a pipeline of tasks and visualizing their flow. With Kanban, team members pull from a prioritized backlog, and available delivery capacity is managed to avoid the occurrence of bottlenecks. Kanban allows for constant re-prioritization of tasks in the pipeline.

    All activities of a team – including both the analysis and resolution of production problems and production integration tasks – are managed through a single pipeline of tasks. Color-coding helps to separate different releases and production issues, as well as identifying dependencies. The Kanban board is organized by swim lanes to account for different roles and skill sets in the team, for example database administrators, middleware administrators and production control experts.

    A single prioritized backlog may be implemented either each Kanban team or across multiple Kanban teams. The backlog contains all items these teams are responsible for: all production integration requirements (we call them automation stories) and all production issues, which need to resolve.

    The backlog is managed by a product owner (PO), who has to collect and maintain requirements from all stakeholders – development, operations, security, first line support and others – and is responsible for their constant (re-) prioritization to create and maintain a fully ranked list of items. Requirements from development are typically retrieved in the development sprint planning meetings.

    The PO writes automation stories, which cover the “what” and the “why”, adds them to the backlog and works with the Kanban team on the creation of tasks.

    Version Control for ITO: While advanced version control is part of every application development team today, it is not yet wide-spread in IT ops and infrastructure. However, with an increasing release velocity, the number of script versions and other automation artifacts, which are created, used and modified within different environments, increases significantly and automated version control becomes very important.

    Modern version control systems support storing, tagging, branching, comparing and merging of multiple or many versions. The most recent generation of these tools such as git is based on the concept of de-centralized repositories and pull rather than push.

    However, IT administration UIs and consoles of ITOM (IT Operations Management) software often do not support out-of-the-box integration with git or other version control systems. They usually store objects in proprietary databases. Quick and easy integrations of version control with these UIs and consoles become elementary.

    Agile Metrics and Dashboards for ITO: Today, availability indicators such as MTBF (Mean-Time-Between-Failure) are the most commonly used performance indicators in ITO. However, to incentivize and motivate your teams towards more agility, it is important to combine them with agile indicators. Examples of agile indicators are:

    • The wait time of a requirement in the backlog until it is processed
    • The cycle time of a task through the development pipeline
    • The relationship of idle time to processing time for tasks in the pipeline

    Most agile collaboration tools make it easy to measure and extract this data. It is useful to

    1. Combine selected agile and availability indicators into KPIs; their relative weights depend on the context and the objectives of the organization
    2. Measure their current baseline
    3. Set realistic KPI targets
    4. Implement an automated measurement system
    5. Extract and visualize consolidated data through a dashboard
    6. Perform regular performance reviews or improvement meetings to analyze performance and performance trends, identify root causes for weak performance and measures to improve it

    The DevOps Production Integration toolkit will not solve all agility constraints in ops, but complemented by automation tools and other measures it can be a powerful answer to many DevOps challenges. It can be implemented locally in ITO and does not require a major replacement of tools or organizational re-design.

    Click here to learn more about implementing a seamless and efficient DevOps Product Integration ToolkitClick 

  • How to align your DevOps and Cloud Initiatives

    How to align your DevOps and Cloud Initiatives

    Infrastructure-as-Code (IaC) practices, which in turn are made possible through infrastructure or platform clouds (IaaS or PaaS), solve many important issues related to continuous delivery and DevOps. Therefore, the implementation of IaaS and PaaS in a private, hybrid or public cloud model should always be aligned with your DevOps initiative. In a previous article, I argued that OpenStack is the ideal habitat for DevOps. After all, OpenStack is backed by some of the biggest companies in software development and hosting, as well as thousands of individual community members. Indeed, many argue that OpenStack is the real future of cloud computing. However, that cloud environment might also be based on proprietary VMware technology, hybrid Amazon Web Services (AWS) or similar. Whichever you end up choosing, the cloud is an important enabler for companies looking for continuous delivery in agile environments.

    Why? Why is IaaS an ingredientfor a successful DevOps strategy? Through IaaS and ultimately PaaS, the bottleneck of infrastructure provisioning gets resolved; No more dependency on busy ops teams with long task backlogs and not enough of people, who are able to script and automate. Infrastructure provisioning is required to create all sorts of environments on-demand, including development, test and integration environments, all of which are required in different phases or steps within the continuous delivery chain or release pipeline. These environments can be created in isolation and dependencies from other projects, which are responsible for so many delays in a release, disappear.

    Test automation is critical for continuous delivery, but benefits are diminished if the provisioning of the necessary test environment takes days or weeks.

    Tips for DevOps-cloud alignment

    So we’ve made the case for the cloud as part of a DevOps strategy. How do you now go about aligning your DevOps and cloud initiatives together? What factors do you need to take into consideration as your developers instantly spin up environments at any time?

    First, start with IaaS. IaaS is easier to implement and more commonly applicable than PaaS. For quick wins, use public IaaS such as through AWS or Microsoft Azure. Get the necessary compliance and security aspects for dev or test environments settled and create a couple of deployment scripts on top of these services. Either prepare ready-backed images with middleware, application servers and databases or leave it to developers to install these components on their own. Alternatively ops can also prepare necessary install scripts and provide them to development.

    Second, build your own IaaS, based on OpenStack or other technologies. The toolsets and interfaces used by the agile development teams and the team responsible for the IaaS infrastructure need to be synchronized. For example, if you’re using OpenStack for the cloud environment, align your provisioning tools around that, possibly using Chef or Puppet. The good news is that many of these technologies really work together well.

    Third, once your IaaS implementation is mature and has been adopted, move towards PaaS. PaaS is the champion’s league in private cloud and usually requires an organization to commit to certain standards for databases, middleware, application servers, deployment architecture and more. It makes it super-easy and fast to provision not only a server, but really the complete runtime environment of an application and deploy the application on top of it.

    In all phases there needs to be tight collaboration between the departments. Your agile development, IT operations and infrastructure teams responsible for delivering the private cloud all need to be aligned around the common goal: delivering quality apps and updates to market more quickly. That means working as one to build a reliable, fast and adaptive cloud infrastructure in support of agile services delivery. It is imperative to understand and track individual development milestones. There’s no point in relying on the ‘big bang’ approach: the cloud infrastructure needs to be synchronized with all the development timelines.

    It has been proven particularly useful to use agile methods in structuring the infrastructure teams: Each platform gets a product owner, who works with development teams and manages all the requests developers have for the platform, i.e. the required APIs and their signatures or supported versions of specific technologies in a common backlog. This is done in the same way as product owners in development are managing their backlogs for the business.,

    Finally, make sure you have the right skills in place. DevOps and private cloud infrastructures command new skills sets—operations engineers, for instance—to prepare, manage and develop your private cloud and the application platform. There’s no point in buying in skills half way through the agile development process: they need to be built into the business plan from the start.

    DevOps,IaaS and PaaS go together like the PC and the keyboard; apps and the iPhone; Windows and Word. Together, DevOps within an IaaS infrastructure enables you to harness faster development and move to continuous delivery.

  • Where will DevOps be in 10 years’ time?

    Where will DevOps be in 10 years’ time?

    What will the DevOps landscape look like in 10 years’ time? Ten years ago, Agile was seen as new and different. Now it’s part of everyday life of most developers. Will it be the same with DevOps? It’s time to clasp the crystal ball and unravel where the future is headed.

    First things first. DevOps is here to stay. The overwhelming trend towards the digitization of services accelerates the need for agility and shorter release cycles with DevOps as an invaluable building brick: think the Uber vehicle booking service, the Airbnb property rental service—even Amazon’s move to take the terrestrial version of Top Gear and launch it as a digital-only, on-demand broadcast service. Services are going digital. And so are companies: banks, retailers, telcos and others are increasingly positioned as software-driven businesses where IT makes the difference.

    These organizations will need to develop and deliver compelling, customer-centric apps quicker than ever before. Agile development will become the battle cry of every business. Dev and Operations teams will increasingly need to shake hands in a middle ground of rapid development and reliable, high performance services delivery.

    At a technical level, DevOps enablement will be driven by increased public and private cloud adoption: Infrastructure, Platform and Application Service Clouds are all important enablers for DevOps practices. Moreover, DevOps will also grow through the replacement of IT Operations Management tool chains – including automation, monitoring and service management – from non-DevOps to DevOps-enabled and DevOps-ready tools.

    If agile is a journey, DevOps can be seen just as another part of it; one, that suits companies, which successfully completed the first phases of agile transformation and are now looking at ways to further enhance their agile maturity levels and accelerate releases. The increased adoption of agile development methodologies and the increase of related maturity levels thus will also fuel growth. Gartner, for example, has indicated that agile development is essential for mobile application development, arguing that the traditional methods used to define and develop desktop applications will not work with mobile application development.

    Still not convinced? Then how about this. Research by Computing in the UK shows that 30% of 300 organizations surveyed in the run up to the 2015 DevOps Summit had either started to implement a DevOps strategy or had already merged Dev and Ops, with another 13% planning to go down this route.

    Awareness of existing DevOps success will also fuel this continued growth. Recent research, for example, shows that high-performing IT organizations are deploying code 30 times more frequently with 50% fewer failures using DevOps practices. And demand for DevOps skills is soaring too: DevOps engineers are among the highest paid IT practitioners today, according to APM Digest.

    Make no mistake, the software delivery chain will continue to accelerate and change cycles will shrink. In many competitive scenarios, an advantage can only be sustained through organizational agility. In fact, agility can make such a competitive advantage sustainable. Since IT is so important already in the “legacy” enterprise and becomes even more so in the digital economy, existing IT systems and methods will need to move towards agile.

    Here’s another thought. I predict that within the next 10 years the split of ‘Mode 1’ and ‘Mode 2’ companies will disappear. Mode 1 is the traditional approach to development, emphasizing scalability, efficiency, safety and accuracy. It’s the blueprint for how IT Operations works. Mode 2 meanwhile is non-sequential, emphasizing agility and speed. And it requires new thinking and processes around issues such as investment management, governance and collaboration.

    It will disappear for two reasons. First, distinct cultures and operational modes are not sustainable within the same business. Second, if agility is not a requirement, the service should not be operated within the boundaries of the firm for strategic reasons. Own “mode 1” operator companies should be used to outsource non-differentiated IT services.

    In due course, bimodal IT will flourish within organizations, servicing two modes of IT, each designed to develop and deliver information- and technology-intensive services in its own way. Success in both modes demands smarter, more flexible tools that support today’s complex IT operations. Bimodal IT is not without its risks and challenges, but it will be increasingly powerful in helping companies meet ever-growing customer expectations. DevOps will help firms help them bridge these two modes.

    Market demand for DevOps skills will continue to grow too in the next 10 years. Research indicates that DevOps engineers are among the highest paid IT practitioners today and aggressive hiring of people with DevOps expertise will continue in the years to follow.

    One final, more controversial thought. In 10 years’ time, we might not even be talking about DevOps anymore. By then, all stakeholders will understand how to work holistically to achieve business value through the end goal of delivering high quality applications and services to customers. So DevOps might even become redundant. But continuous delivery will be the norm.