devopsy.kinsta.cloud

Author: contributor

  • DevOps is a Risky Business

    DevOps is a Risky Business

    I spend a considerable amount of time with clients discussing DevOps and the potential value it can bring to them, but there is one theme that always resonates: the ability of a DevOps approach to eliminate risk. While many of us understand the benefits in terms of being faster (improved productivity), cheaper (reduced cost) and better (improved quality), I find that a conversation based around risk, especially when talking to the business or department heads, usually gets straight to their concerns in a language they understand.

    IBM’s definition of DevOps is not simply about connecting development and operations; it is fundamentally about providing a capability that: 1) allows lines of business to connect with their customers (which may be internal employees) quickly, and 2) facilitates rapid feedback from their customers so relevant adjustments can be made. DevOps, therefore, embraces the philosophy of iterative (and incremental) development and delivery, whereby solutions are delivered through a series of incremental releases.

    DevOps is a Risky Business_1

    By ensuring all aspects of a solution (requirements, designs, code, executables, tests, etc.) evolve over time as each increment is completed, DevOps is fundamentally focused on addressing risks including:

    • The risk of not knowing the requirements (have you ever tried to write down and freeze the requirements for a mobile app?)
    • The risk of not knowing the solution (especially when it’s new, you’re defining a new architecture or you’re embracing new technologies)
    • The risk of not knowing the effort (especially when the solution is novel for the organization)
    • The risk of not delivering on time (when the pace of the team, for example, is an unknown)
    • The risk of not providing the right level of quality (and the impact this may have on customer sentiment)
    • The risk of adopting inappropriate practices (meaning that the approach being taken by the team is not working for them)
    • The risk of having an ineffective delivery environment (including automation through the use of delivery tools)

    I could go on. There are so many risks that can be addressed simply by delivering working software iteratively, that it’s surprising how many organizations continue to fall back to a “waterfall” mentality—even in high-risk environments where much is unknown.

    The tack I’ve taken here originates from my time at Rational Software Corp. (which IBM acquired in 2003), where we would emphasize the need to deliver software iteratively and progress was measured based on the results achieved (i.e., working software) rather that the documents produced. My favorite graphic from that time is the one shown below, which shows how a modern approach changes the risk profile associated with a delivery project, since it focuses on removing risk as early as possible in the life cycle.

    DevOps is a Risky Business_2

    In summary, incremental and continuous delivery evident in a DevOps approach allows us to call out risk early and determine its resolution. DevOps often is used along with “lean startup” thinking (and its build-measure-learn cycle) and monikers such as “fail fast” since these are, at their heart, also focused on addressing risk.

    Take the DevOps self-assessment to find out where are you on your DevOps journey

    About the Author / Peter Eeles

    Peter Eeles

    Peter Eeles is an Executive IT Architect in the DevOps Global Tiger Team, IBM Hybrid Cloud, where he helps organizations improve their IT delivery capability in order to drive tangible business value. He has a particular interest in the adoption of architecture, agile, DevOps and cloud as innovation enablers. In the IT industry since 1985, Peter comes from a delivery background and was previously chief architect of IBM Rational’s Worldwide Solution Delivery organization, where he led many large-scale transformations in a variety of industries. Peter has written many papers and several books, including “The Process of Software Architecting” (2009), “Building J2EE Applications with the Rational Unified Process” (2002), and “Building Business Objects” (1998). He runs his own website at www.architecting.co.uk.

    Connect with Peter on LinkedIn and Twitter.

  • Preserving Bottom-Up Innovation in DevOps

    Preserving Bottom-Up Innovation in DevOps

    Balancing top-down control and oversight with bottom-up innovation and autonomy

    The driving force behind DevOps adoption in the enterprise is the idea that it will enable faster and more frequent delivery of better quality software. If all goes well, DevOps should result in higher customer satisfaction and lower costs, but the journey to get there can be challenging. Unfortunately, only a minority of organizations that attempt to implement DevOps actually fully deploy it.

    There are many barriers to overcome before organizations can realize the benefits of DevOps. One of the main challenges is retaining sufficient top-down control and oversight without hampering bottom-up innovation. 

    From Start-Up to Enterprise

    The root of this problem lies in the fact that many ideas in DevOps were developed in environments with small teams and flexible organizational structures. In such setups, where everyone can see what everyone else is doing, visibility and control seldom are an issue. Adapting this approach to an organization with hundreds of geographically distributed teams, in industries with a lot of regulatory baggage and diverse legacy systems, is an entirely different prospect.

    How do enterprise organizations find a structure that enables individual teams to unleash their innovation and maintain a feeling of responsibility without losing oversight and control? If DevOps teams are not empowered to make their own decisions and free to move swiftly, then they’ll struggle to realize the benefits that drive adoption in the first place. 

    Walking the Tightrope

    Individual DevOps teams should be free to make local decisions, but these need to be in alignment with business goals at the management level.

    You don’t want to hamper the speed and reliability that automation brings, or the innovation that can come from autonomous decision-making, so you need to find a way to balance tools, processes and team structure to maintain control and visibility. Avoid flying under the radar; instead, aim for maximum transparency in what your DevOps teams are doing. Set goals and measure, because visibility for management will prove that the new approach is working, build confidence and secure more top-down investment.

    Connecting the Dots

    A large enterprise will have a number of DevOps teams, but they shouldn’t be completely isolated. Requirements such as audit trails, security access logs and compliance controls must be met by all of these teams. There’s little sense in making each individual team responsible for solving the same problems over and over again. Offer a set of standards and tools, but be careful not to shut down choice.

    That same logic applies to competence development, so offer your DevOps teams access to best practices and enable them to learn from each other. The size and structure of an enterprise organization does present unique challenges to DevOps adoption, but there’s also opportunity here to benefit from the scale by sharing and collaborating. Sharing and standardizing the right things will eradicate redundancies and free your DevOps teams to focus on improving their products and innovating, so the business derives maximum value from their efforts. 

    Finding What Works

    The right answer will be different for each organization, but there are some things everyone should keep in mind when building or shopping for tooling. It needs to support a large, diverse environment. Look for support for the platforms you use and consider extensibility, so you can add the functionality you need.

    A key factor here for orchestration tools—especially those that define and execute your delivery pipelines—is that they must be accessible for management. You shouldn’t need to be a technical expert to dip in and get an overview, or compile a report that provides the insight you need. Ensure you collect diverse metrics and present information in a digestible format so you can find bottlenecks and identify successes and failures and really deliver the best experience possible for the end user.

    About the Author / Andrew Phillips

    cropAndrewPhillipsAndrew Phillips is VP of DevOps Strategy for XebiaLabs, provider of software for continuous delivery and DevOps. He is a cloud, service delivery and automation expert and has been part of the shift to more automated application delivery platforms. He contributes to a number of open source projects including Apache jclouds, the leading cloud library, and is a co-organizer of the DynamicInfraDays container community events.

  • Embracing a DevOps Culture, Part 2

    Embracing a DevOps Culture, Part 2

    In Part 1 of this series, we discussed the fact that more organizations are looking to embrace the “DevOps culture.” However, unlike ITIL, implementing DevOps into an organization does not happen overnight. DevOps is more a philosophy than a procedure, and choosing the right leadership team is as important as choosing the right tools.

    In Part 2 we look at other important elements of organizations successfully embracing the DevOps culture.

    Without Proper Collaboration, DevOps Initiatives Will Fail

    A good test to determine if your organization has truly embraced the DevOps culture is how well your IT department responds when a major incident occurs in the product environment. For example, an e-commerce company’s dramatically slow website, a hospital’s unresponsive electronic medical record (EMR) system, and a malfunctioning airline reservation system. In these chaotic situations, every minute counts and all Dev and Ops hands need to be on deck to keep your organization afloat.

    When incidents occur, it’s critical that your organization’s Dev and Ops teams work together to resolve the problem and restore failed service as quickly and efficiently as possible.

    Incident Response: The Critical Incident Team

    An international company with global operations may have network operations centers (NOCs) in the United States and the U.K. that support more than 50 mission-critical business applications, development centers in China and the United States and a service desk in the United States. When an incident occurs, the company’s service desk is flooded with alerts, ranging from various IT monitoring tools and customer phone calls to open tickets from online users and inquiries from stakeholders. When that happens, the only concern of the service desk is to fix the issue—not tracking down a department head on the other side of the world that may be responsible for the problem.

    DevOps should enable an organization to assemble its critical incident team in only a few minutes. The Ops team should know exactly what team(s) to contact for a given incident, and who from those teams is assigned to application support. They should know who is on call based on the time zone and day of the week, and have the correct phone numbers easily accessible.

    Next, the team should review the technical details of the issue provided by the incident manager. The universally used DevOps toolset enables everyone to speak the same language, quickly identify the root cause, put a remediation plan together to have approved by the emergency cab, deploy the fix, test it out and confirm service is back up and running.

    IT Communication: The Glue That Holds Dev and Ops

    To be successful, organizations need to be able to respond as quickly as possible during a major IT incident to limit the negative impact on the business. This is achieved when Dev and Ops works together to create a central communication and collaboration center to ensure proper communication with key stakeholders.

    An organization’s ability to effectively mitigate the impact of an IT issue relies heavily on its ability to access and communicate critical information, and to ensure the right people can analyze it and initiate the appropriate actions to keep the business running smoothly. The communication hub equipped with an IT communication solution will facilitate:

    • Reaching out to the right on-call people among all the different teams: infrastructure, server, system administration, middleware, network, DBA, QA, support team, service desk and the application developers.
    • Because emails don’t wake up people, they will be able to leverage the IT communication solution to reach out to people via multiple channels until they respond (voice, SMS, email, push notification app, paging, etc.), or automatically escalate to the next resolver on the on-call list.
    • Providing the right information so the IT resolvers start investigating the issue, identify the root cause and put a resolution plan together without wasting time.
    • Get people to collaborate together using the same telecommunication and collaboration tools whatever the time zone and wherever they may be located.
    • Contacting a third-party vendor in case the problem is not attributable to the company but caused by an external piece of software.
    • Informing the other departments if the business impact grows so big that it affects the company profitability or reputation, such as a cyberattack leading to a data breach for instance. The CEO, legal and marketing may need to be informed to anticipate the consequences.
    • Informing end users or customers to limit the number of incoming calls into the help desk.

    The benefits of quick collaboration and not just handoff between the teams don’t even have to be demonstrated. Removing the broken pathways, obsolete delivery methods and redundant platforms will improve significantly the organization’s ability to communicate during critical moments. Becoming more efficient and removing the time wasted will automatically have a huge impact on the mean time to know (MTTK) and, in turn, on the mean to resolve (MTTR), hence minimizing the disastrous impacts on the business and keeping the company’s execs sleep at night.

    DevOps Culture Can Happen

    Embracing a DevOps culture is not a Big Bang change that happens overnight. This is a journey that will be more or less difficult to pursue based on the existing culture and the history and maturity of the IT organization. Even more importantly, it will depend on the level of commitment from upper management to introduce a new culture. Leaders need to embark on this journey keeping in mind that not only will it require new common tools and new common processes, but also they’ll need to convince people of the value of such transformation. To achieve this goal, management should consider IT communication as a key element, which will be the glue that binds Dev and Ops together. And because there always will be room for continuous improvement, the road to DevOps will have no end.

    About the Author/Vincent Geffray

    vgVincent Geffray is Senior Director of Product Marketing at Everbridge with focus on IT Service Alerting & Communications Automation and IoT.

    He has more than 14 years of experience in the information technology business, designing, promoting and selling Enterprise IT Operations Management solutions, including Critical Communications, Application Performance Management, IT Process and Workload Automation. He also has international experience as he started his career in Europe. Vincent holds a Master of Science (Mechanical Engineering and Computer Science) and executive certificates from the MIT – Sloan School of Management.

    Vincent’s LinkedIn: www.linkedin.com/in/vgeffray

    Vincent’s Twitter: @vgeffray

     

  • Hello, Security. Meet Agile

    Hello, Security. Meet Agile

    Illumio Chief Commercial Officer Alan S. Cohen recently wrote in his blog, “Go, Slow and No: Bringing DevOps Speed to IT Security,” “There are reasons why security and risk professionals often react with a ‘no.’ When you are tasked with assessing and reducing risk, going fast might not be the first instinct.”

    Many InfoSec practitioners adhere to accreditation and certification programs such as ISO27001, SSAE-16 SOC and PCI compliance. This ultimately means they follow strict policies and procedures for software development. These procedures go through many gates, including risk analysis, design and code reviews, penetration testing and ITIL-based change-management processes. InfoSec teams live in a world where they have to plan their changes months in advance, and this world often is in direct conflict with agile development and DevOps concepts.

    Agile is all about focusing on flow and end-to-end cycle time, releasing very small changes fast, early and often. It’s not about the number of things in each sprint, but rather what’s needed now for MVP and iterating. For agile and security to be in alignment, there needs to be a fundamental shift in the principles and values that enable the business over governance and process.

    In particular, security:

    • Embraces some uncertainty. You will never build a perfect piece of software. The key is to build guardrails and to have the required adaptive enforcement and monitoring in place to capture and correlate metrics that help you quickly respond, evaluate factors of compromise and leverage your deployment automation to remedy risk exposures quickly.
    • Is part of the project team, either embedded or as an adviser. There must be a dedicated resource that understands the team’s mission of delivering value. Somebody on the team should be wearing the security hat, helping to guide each project.
    • Is a risk adviser inside the organization. Don’t compartmentalize information. There needs to be a culture of trust, sharing and transparency about potential vulnerabilities to the service.
    • Trusts the decision-making of engineering teams. Informed and capable engineers aren’t reckless with security decisions.
    • Is part of everything. It’s the design of the entire service and therefore is the responsibility of the entire team, not just the security team.
    • Improvements do not add complexity to the user experience. Security that degrades the user experience will force people into insecure practices.

    Bringing Agility, Security Together

    Embracing agility and DevOps opens the door to new possibilities that can improve security posture without hindering the business. Security will quickly discover a new set of best practices:

    • Look to microsegmentation software that is adaptive and intelligent, to replace manual management of firewall rules and policy.
    • Decouple security from the infrastructure to gain a continuous enforcement pipeline that adapts to new hardware, with strong versioning that proceeds in lockstep with product releases, monitoring and infrastructure configuration.
    • Build security into the service stack; don’t bolt it on afterward.
    • For change auditing, don’t rely on the change management database alone. This is highly prone to error and discrepancies. Look at the the git history integrated with the automated deployment system. Change management databases should be integrated with the git pull requests and commit logs. Infrastructure automation tools such as Chef and Puppet keep logs for unapproved change drift. Make sure those logs are being captured and reported on.
    • In the area of developer support, DevOps is enabling the self-service/self-responsibility revolution by building wrapper abstraction layers for engineering teams to consume infrastructure across public and private data centers, using interfaces such as chat to trigger administrative actions and query metadata information on their instances. These wrappers can also be harnessed to present security grading for every server instance, promoting awareness and corrective action to each individual owner. You can quantify the grade by looking at patch vulnerabilities, images used to build, inbound/outbound port rules and configuration standards.
    • For data at rest, data in motion and data in transit, everything should be encrypted, everywhere. For example, use Illumio SecureConnect to encrypt data in transit via IPsec between workloads. Automation and the right secrets-management infrastructure can enable frequent rotating of SSL certs and keys.
    • Every time you commit to the code base, run a set of very basic security tests via your favorite continuous integration tool. Use automated tests to ensure common security mistakes don’t leak to production.
    • Perform red team exercises as an attempt to gain access to a system by any means necessary. Try to mimic the same processes that a motivated attacker would follow to map out an organization’s infrastructure, perform reconnaissance at key physical installations, and then test the physical, cyber and social defenses all at once through a staged exercise.

    Security can become an enabler. It no longer has to be stuck being the department of “No.” InfoSec can now be the team-building tools and systems that enable development teams to do what they want in a secure way.

    About the Author / Alfred Garcia

    alfredAlfred Garcia oversees DevOps for Illumio, where he is responsible for all preproduction and production cloud/infrastructure engineering and site reliability. A technology and operations executive with more than 18 years of experience, Alfred is an aggressive advocate of DevOps and of deep operations and engineering collaboration, from design to code/test and release to production support.

  • Balance: The Key to Successful DevOps

    Balance: The Key to Successful DevOps

    In the realm of IT buzzwords, DevOps is in a league of its own. The pervasiveness of the word is matched only by the variety of its definitions. Over time, much like the parable of The Blind Men and the Elephant, it has slowly taken shape out of the void, albeit in a backwards fashion. Associated terms such continuous delivery, integrated quality assurance and deployment automation have helped backlight the beast’s silhouette, but there is much more to discover.

    Generally, DevOps is defined by how it is used rather than what it is. This is helpful for those already familiar with the amorphous nature of the movement, but can be a confusing introduction for the uninitiated. To achieve a better understanding, it is important to grasp the underlying need driving the shift to a DevOps model.

    Currently, the world of IT is barreling toward a future dominated by increasingly specialized and inherently complex automated solutions. Software is taking a front row seat in ways never before possible. (Insert here)-as-a-service offerings and the demand for instantaneous and consistent deployment turnaround is at an all-time high. The days/weeks required to shuffle a solution between development and engineering is a luxury that most companies can no longer afford and is less tolerated by customers. This level of expectation is something that the traditional IT org chart was not designed to cope with. Tech companies everywhere have felt the strain of this increasing momentum, with many at a loss of how to handle it. Demanding that teams work harder, faster, longer will only get so far. And inevitably, increased intensity results in a rise in mistakes and an inferior product.

    Balance: Dev’s Yin to Ops’ Yang

    Clearly, change was and is needed. The path from development to operations needs to be streamlined at a fundamental level. However, dissolving the barriers between two longstanding departments is not without its perils. As any IT veteran will tell you, development and operations each have their own cultures, quirks and personalities. But the differences in each help create the perfect balance.

    In its purest form, development is the trailblazer, forging into uncharted territory and unearthing hidden gems. Ever the innovator, Dev values progress and change above all. This constant forward momentum is Dev’s greatest asset as well as its Achilles’ heel. The habitual urge to tinker, tweak and create can lead to frivolous or wasted effort. The results of this misguided effort can be seen in retrograde patch releases, hotfixes and other “band-aid” measures needed to undo the damage.

    On the other end of the spectrum, the operations mantra can be summarized with the idiom, “If it ain’t broke, don’t fix it.” Pragmatic to the core, stability and consistency are the guiding forces behind Ops. Change requests are usually met with a Treebeard-esque, “Don’t be hasty.” Taken to the extreme, this mindset can quickly lead to an environment running outdated, unpatched software and end-of-life hardware.

    On the surface, the differences between these two groups appear to be on the verge of irreconcilability. However, in this diversity the beauty of DevOps emerges as the strengths of each team balances out the weaknesses of their counterpart. Development is free to innovate and create knowing that their efforts will be guided by feedback from operations. Like stabilizers on a rocket, operations is able to focus on maintaining a reliable infrastructure with development providing the forward momentum. Working in unison, this duo forms a unit far greater than the sum of its parts. And with it, a company is left with an agile and stable launch pad from which to tackle the latest wave of IT challenges.

    Admittedly, the combining of development and operations into a single cohesive unit is just a piece of the entire DevOps puzzle. However, it is an important piece that is frequently overlooked. Understanding the forces and motivations at work within your teams is a pivotal step on the road to a successful DevOps transition.

    About the Author / Jared Perry

    Jared PerryJared Perry is a cloud engineer at iland, where he is responsible for maintaining the virtual infrastructure and a number of disaster recovery solutions. He holds a Bachelor of Applied Science in technology management and a Bachelor of Science in IT administration and management from Texas A&M University.

  • 3 Ways to Become a More Agile IT Organization

    3 Ways to Become a More Agile IT Organization

    In 1960, the average life expectancy of a Fortune 500 company was 75 years. Today, the average lifespan is just 15 years and declining further. So what gives? We only have to look as far as the “Uber-effect” to understand why so many companies fail. Uber very simply and quickly disrupted a centuries-old industry with the touch of a button—making cab service part of the On-Demand Economy, where consumers get what they want, when they want it, with no delays. Today, agile companies are winning.

    So, ask yourself, is your company a disruptor or a disruptee? The reality is, most companies are the latter, with IT organizations under more pressure today than ever before. Whether it’s the fear of being “ubered” by the competition, or business demands to pick up the pace, IT organizations face a balancing act of ensuring the operation of core applications and being innovative. But the truth is, innovation and maintaining the efficiencies of legacy systems can co-exist.

    While the prospect of competing with born-on-the-web companies such as Uber or Airbnb might seem daunting, there are a few things you can do to become a more agile IT organization:

    Automate manual processes

    How long does it take your organization to deliver a simple, new feature in an application? Two days? A week? A quarter? Traditional approaches to software delivery are too slow for today’s speed of business. These often-manual processes are fragmented, error-prone and time-consuming. A recent Forrester Total Economic Impact study revealed organizations that automated their app deployments experienced an increase in speed-to-market and reduced development cycle times up to 75 percent.

    Take a look at your delivery pipeline and assess where you’re testing and deployments could be automated. Are developers able to easily deploy applications to a test environment, or are they bogged down with unnecessary wait times and manual deployment and configuration steps that are susceptible to errors? If you’re facing a development-testing cycle of two to five days, that’s simply too long. Look to adopt DevOps by automating release and deployment processes wherever you can and aim for continuous delivery, so you can push apps out quickly and be more agile.

    Lean and Mean Equals Agile

    No company will risk its core systems of record for the sake of innovation. At the same time, you cannot invest in becoming innovative if the delivery and maintenance of your core systems are inefficient. The goal is to make these core systems as lean as possible by automating repetitive tasks, freeing resources that can be directed toward speeding innovation. Today there are cloud technologies and services and API management systems that can help organizations streamline the maintenance and operations of these core systems and expose their services as APIs for consumption by new applications.

    Create a multispeed IT process

    While you’re making your core systems as lean and agile as possible, create a second layer, where innovation and agility are the key focus. As your core systems are exposed as APIs, you can begin to use their business functions and services to experiment and innovate. Cloud-based development platforms allow organizations to stand up complete development, test and production environments quickly to incubate and deliver new, innovative applications that consume these services from the core systems, delivering new and innovative business capabilities in a fraction of the time traditional methods would take. These innovative apps can be delivered and decoupled from the speed of delivery of the core systems, enabling what is known as multispeed IT.

    While the status quo might seem like an easier option, by doing nothing, you risk not only being passed by the competition, but your line of business leaders may bypass you altogether, turning to “shadow-IT” and outside vendors to meet their needs. While this hypergrowth of the tech industry is unprecedented, it is not a fad. The pace of innovation will only get faster and your only options are to fail or adapt and be agile.

    About the Author / Sanjeev Sharma

    sanjeev-sharma

    Sanjeev Sharma, CTO and Distinguished Engineer – DevOps Technical Sales and Adoption, IBM Cloud Unit, is a 20-year veteran of the software industry with expertise in DevOps, mobile development and UX, lean and agile transformation, application lifecycle management and software supply chains. He is a DevOps thought leader at IBM and speaks regularly at conferences. He has written several papers and is the author of the “DevOps for Dummies” book.

    Connect with Sanjeev LinkedIn | Twitter

  • Trust, You Must: 8 Tips for Adopting CI/CD

    Trust, You Must: 8 Tips for Adopting CI/CD

    We have done continuous deployment (CD) for four years, and enable many of our customers to do continuous deployment with quality assurance (QA). We’ve helped tons of companies adopt and optimize their CD setups. We’ve found that continuous deployment is all about trust — augmented with processes and infrastructure.

    To that point, here are some common tips for adopting continuous integration (CI)/CD that I find myself sharing frequently:

    Use a CI Tool

    This sounds obvious, but you’d be surprised at how many companies try and roll their own. Don’t. There’s no upside for your company—and infinite downside. We love Circle, but there are plenty of other great options. Most are at least somewhat prescriptive when it comes to workflow, which is important when you’re getting started.

    Do Unit Testing

    It’s always worth reminding everyone that continuous deployment is simply continuous integration applied to deployments. To do continuous integration, you need good unit test coverage. If you haven’t got a solid base of unit testing and continuous integration already, you’re not ready for continuous deployment.

    Have Solid Production Monitoring

    Bugs and regressions will get shipped; it’s inevitable. Put a system in place, by looking at the data in production, to tell you when a regression or bug was shipped. Tie this into automated rollbacks, so that if a significant performance or key performance indicator (KPI) regression (i.e., signups per minute) appears, your CD system rolls back to the most recent stable version while your team investigates.

    Trust Your Team

    We talked about the infrastructure requirements, but if you don’t have trust, then continuous deployment isn’t going to work for you. Trusting your team is about giving your developers the freedom to make mistakes, deploy as they see fit and check each others’ code. It is possible to combine continuous deployment with a culture of hierarchical permissions, but we have yet to see that truly work.

    Remove Red Tape from the Code Review Process

    Your team should review code changes, typically through a pull request, which goes hand in hand with trusting your team. Developers should be trusted to choose the most qualified and insightful person to review their code. One of the most common mistakes among teams trying to adopt continuous deployment is that they only let one or two “senior” developers review the rest of the team’s code, “bottlenecking” all releases. Don’t make this mistake.

    Involve Developers Closely in Production Operations

    The most common mistake we notice among companies that don’t make a successful transition to continuous deployment is that their development organizations are siloed. Dev and Ops should be joined at the hip. Have your developers deeply involved in the setup and definition of your CD infrastructure, and half the battle is already won.

    Shift Left: Test Early and Often

    Your team needs constant feedback. Think of your QA objective as getting the right feedback in the right hands at the right time. When it comes to deployments, this means knowing what’s working and what’s broken as the breaking change is made. The sooner you uncover the bug after it’s created, the easier it is to fix. The best companies doing continuous deployment have comprehensive unit test and integration test coverage that runs before any code hits the staging server.

    Treat Staging as Your Holy Place

    The final pre-production environment is usually known as ‘staging.’ A common mistake is to have developers ship new code direct to staging, while figuring out if the new code is ready to go live. This is a terrible idea. As soon as more than one developer is trying to ship their changes, your Slack channel will blow up with cussing and recriminations. Isolate the pre-production environments to each project, and enforce the “staging as ready to go live” philosophy. This way, integration testing can happen at a self-defined pace, without anyone else’s release being blocked.

    About the Author / Fred Stevens-Smith

    fredstevenssmithFred Stevens-Smith is Co-founder and CEO of Rainforest QA, a quality assurance-as-a-service startup backed by Storm Ventures, Rincon, Andreessen Horowitz, Morado and Crosslink.

  • Putting the ‘Biz’ in DevOps

    Putting the ‘Biz’ in DevOps

    I was having a conversation with a client recently and we both came to the conclusion that DevOps, as used in some conversations, is misnamed. DevOps, by virtue of its name, implies that the focus of improvement is aimed at development and operations. While this is true, I believe that DevOps, at a higher level, is to improve the practices of getting business needs into production more quickly and reliably. The picture below illustrates this higher-level life cycle.

    pic 1

    The goal in any meaningful DevOps practice is to reduce the time and improve the efficiency in moving from the “Business Need” on the left to the “It’s Live!” on the right. This is why I’ve been such a fan of using lean approaches to improve the solution-delivery processes.

    So where does business get involved? Clearly, the business should be involved with the “business needs,” but organizations with good DevOps practices have the business working across the whole life cycle. The ability to do course correction and steering during the lifetime of a project is so important. We know that things change and what we plan on building may be different than what we actually deliver. Having the business in close affinity to the Development and Operations team is a good step to helping drive this alignment. If we get things right, we might be able to build a much simpler DevOps delivery cycle that looks like this:

    Pic 2

    It is also important that we should be measuring things that matter to the business. By doing so, this will also aid in improving the alignment across business, development, and operations. Below are few business oriented metrics that I have used to improve solution delivery processes for my clients. These might be good to put into your “BizDevOps” measurement strategy:

    Metric  Details Benefits/Impact
    Deployment Frequency  How frequently are new releases reaching your user? This metric should be stable release to release. Your end users should see a steady cadence of bug fixes, new features, etc., that build confidence in the products you deliver.
    Change Volume  How many new stories (or features) are in each release? Your end users should see new features being released consistently.
    Renewals, User Volume, New Users  Is your user base increasing, decreasing or staying the same? A growing user base shows if your product is being viewed as useful.
    Revenue per user  Is revenue or cost changing over time with your user base? This is another indicator that shows the value and economic impact of your product.
    Client Experience KPIs
    •  Customer Ticket volume
    •  Incident Severity Ratios
    •  Availability of Systems
    		 These metrics give you a perspective on the overall quality of your product.

    Adopting the right business-oriented metrics that are meaningful for your team and projects will help you expand your DevOps capabilities into a broader, more meaningful “BizDevOps” practice!

    For more information on metrics that are relevant, take a look at my blog, “How project managers can measure a cloud project’s success.” Also, refer to Forrester Consulting’s report on the Total Economic Impact of IBM UrbanCode at https://ibm.biz/BdXUjt 

    About the author / Rick Weaver

    Rick Weaver

    Rick Weaver is a Director in IBM Cloud leading the US East Cloud Advisors. Rick has extensive experience working with some of IBM’s largest clients around the world. Rick has led work in helping clients around the world improve their practices around DevOps, software engineering, agile adoption, automation and cloud implementation.  In prior roles, Rick has led Rational Lab Services for AP and China, IBM’s SOA Tool strategy, helped drive the internal transformation of IBM tool development and integration, and has led the worldwide technical sales team for WebSphere Tools. Rick lives in Dallas, Texas and has worked for IBM for 25 years.

    Connect with Rick LinkedIn | Twitter

  • DevOps by Osmosis — Is That Even Possible?

    DevOps by Osmosis — Is That Even Possible?

    “We don’t do DevOps. We can’t, as our development plans are agreed so far in advance and our priority from a production point of view is to keep our systems available 24/7.”

    I heard this comment from a pal of mine as we had a quiet beer over the weekend, but I’m sure this comment, or a variation on it, has been uttered many times in many places. Here’s the irony: I had met my pal, who works as a developer for a major financial services company, after he had had the week from hell. His group tried—and succeeded—to fix a major system issue that had come out of the blue. He had certainly earned the beer that week.

    So, I asked him: “How did you get the problem sorted in the end?”

    “Well, we had to form a Tiger Team,” he replied. “Pulled together some of the DBA team, the key developers and the Ops guys, worked throughout the night and managed to keep the systems up and running the next day, while we used that time to address the root cause.”

    “How did you get around the Governance guys?” I asked.

    “Well, we brought one of them into the team for a few hours, and she was able to get us past some of the key bottlenecks,” he said.

    “And how about QA?” I asked.

    “Oh, they knew this was a major issue and so we cut out a lot of the QA and just went ahead,” he replied. “It was a bit risky, but we had all the right guys in the room to fix anything that cropped up.”

    “So, you manged to get a major change through in a couple days, kept your systems up and running, kept your customers happy, and earned that beer,” I said.

    “Yep, that’s about it, alright,” he said.

    “So, that’s pretty much what DevOps is all about—minus the emergency element,” I pointed out. “Seems to me like you guys are already on the DevOps road.”

    It was about then that the penny dropped with my pal. He suddenly realized that yes, they could do changes quickly, yes, they could do them in an orderly manner and yes, they could keep their systems up and running while all that happened. But, as quickly as the penny dropped and the realization dawned on him, the light went out again.

    “There’s still no way we can do DevOps in our place,” he said. “There’s too many hurdles to overcome, too many guys used to doing things the existing way, which to be fair, has worked well for us. To be honest, there’s too many guys who would feel under threat if we suddenly changed how we do things.”

    And that, in a nutshell, sums up the major challenge facing people promoting a DevOps approach. I have spent many years in the IT industry; I go so far back that I wrote my first code using punch cards (look them up) so I’ve seen change come and go, and change has been the one constant. I think many people in the IT industry have become too focused, whether it’s on the latest tools in their area of expertise, or on the newest piece of kit that has been bought, or indeed on the latest problem the business has put in front of them. The industry has become mature—if we compare the IT world to a field such as medicine, you pay passing attention—if you even notice at all—to things outside your specialty field.

    Now that’s right and proper. I don’t want an orthopedic surgeon trying to fix the problem with my eye, and I don’t want a DBA to write me some code. But when something comes along that affects the whole industry, I want them to pay attention and not ignore it.

    Daysha ran a lunchtime seminar last week, and we titled it “BizDevOps – DevOps isn’t compulsory but neither is survival.” We wanted to use this seminar to engage business people who, let’s face it, are the people we support and who need to understand how IT can make things better. Somewhat disappointingly, while we attracted a great crowd, they were all IT people. No one from the business attended. Now maybe we advertised this event in the wrong places, or maybe we held it in the wrong place, but here’s the thing: We attracted IT people from major companies, and none of those IT guys said to their business people, “You need to hear about this, come along for lunch.” I hope that after our seminar they went back to their business people and said just that, and maybe the next lunch will have the business people in the majority.

    When PRINCE came out into the project management world, it was not bought into by a majority of project managers. The same happened with ITIL. And the same will happen with DevOps. It is fair to say that PRINCE and ITIL are pretty much standard on a worldwide basis. I am old enough to remember the time I first heard of them, and the time I did my first course and passed my first tests, but nowadays, they’re part of the furniture—taken for granted, and rightly so.

    I think people are a little bit afraid of DevOps, and I can see why this is the case. Think about it for a second: Someone is now saying that the way we have done things for years has to change. That we can do things better, faster, with higher quality, but we just can’t do the massive 12-month long project in the same way. We might need some new tools, primarily on the Ops side. We might need some new skills—again, primarily on the Ops side. But, by the way, we’re not going to do away with the Ops guys (so don’t expect to make major budget savings there). But here’s the thing: Our end customers will notice the difference, and so will not be tempted by the new kid on the block—who, as it happens, is probably using a DevOps approach to develop his application, which is threatening our business.

    Change is scary, it’s not easy, and making a major change while you’re still having to churn out the new business requirements, and keep the current systems running … now that’s really scary. But, like my pal whom I shared the beer with last weekend, maybe you’re not as far away from that change as you think you are, maybe it’s not as scary as you think it is, maybe it will affect people positively, maybe you just have to do it.

    About the Author/John Brophy

    eJohn Brophy is currently Head of Professional Services at Daysha Consulting in Ireland, where he leads a team of 25 project managers and business analysts working on projects in blue-chip clients. He is a 35-year veteran of the IT industry, starting out as a database systems programmer, moving onto leading a team of systems programmers looking after what were then called midrange systems. He then became a senior project manager with a global IT company and followed that up by running his own IT infrastructure support company for 6 years. His background is Ops – and he is proud of that!

  • Why Your SaaS Ecosystem Isn’t Delivering

    Why Your SaaS Ecosystem Isn’t Delivering

    Cloud computing and -as-a-service deliverables such as SaaS have the potential to be transformational, but their value depends on whether you see them as tactical, single-purpose tools or as part of a larger and more strategically integrated ecosystem.

    The cloud today is embraced almost universally at some level and seen as an essential component of nearly any enterprise, making it easier to enter new markets, transcend physical barriers and gain access to vital services. The most common, basic approach to SaaS may best be described as a JBOS approach, or “Just a Bunch of SaaS.” In this model, SaaS is used throughout the enterprise, but only as single-purpose tools, deployed to meet the needs of a particular siloed requirement. SaaS in that respect is a quick fix, a Band-Aid, lipstick on a pig—and it has not reached its full potential.

    There is a point however, where SaaS and DevOps intersect—that point where an integration framework is superimposed over a SaaS catalog, and enterprise users now gain the advantage of each SaaS being part of a greater whole. At this point where SaaS apps and data become integrated strategically, we begin to see collaboration between IT professionals, developers and line-of-business managers; we see a higher level of automation; a more agile solution that takes full advantage of the cloud model; and finally, an overall cultural shift—all components of the DevOps movement.

    SaaS’ Potential

    The potential of SaaS is well-known and includes lower costs, agile sourcing and deployment, lower CapEx and more functionality to a wider group of users. But, the greater potential has been lost on many corporate users. IT is moving to the cloud, but is it doing so for the right reasons? By focusing on the “quick fix” aspect of SaaS, companies are missing out on the bigger picture. A more successful SaaS strategy defines the future of the business, using SaaS to stay agile and to align with business needs not just the individual SaaS instances but the entire SaaS ecosystem.

    The greater potential of SaaS is achieved when it is deployed strategically, with an integration framework—and then the benefits go far beyond lower costs and CapEx. At that point, SaaS becomes transformational.

    Unexpected Results

    With all the potential, the rapid uptake of SaaS throughout the enterprise has had a few unexpected results. In addition to a marked increase in siloed information and isolated functionality that results from a lack of integration, the “dark data” phenomenon looms on the horizon, especially as the Internet of Things creates millions of new data points that never before existed. IBM Research’s John Kelly, known as the “Father of Watson,” noted recently at the San Francisco Cognitive Colloquium that 80 percent of data remains dark, and by 2020, the number will reach 93 percent.

    With the vast majority of this unused data being generated from SaaS apps and IoT deployments, the unexpected result is an enormously untapped potential. Regardless of what the app’s intended purpose may be, who it was meant to benefit and which department deployed it, useful data is being orphaned at the source. In many cases, that data may have practical uses beyond the original intent, but those uses are never seen because it never escapes its own little corner of the enterprise.

    In addition, incumbent integration platforms do not lend themselves to the cloud and lack the SaaS adapters necessary for ad hoc integration and line-of-business usage, and the solutions that do exist still lack tools for governance, API management and IoT integration support.

    The Role of IT is Shifting

    The IT department’s role is shifting dramatically. The need for agility and flexibility, along with a growing dependence on the cloud and as-a-service software, means IT no can longer continue its centralized role, lest the benefits of the cloud be thwarted. In a recent survey conducted by NetEnrich, respondents’ greatest concerns included IT is losing its relevance (18 percent) and  business applications are crashing more because IT is not involved (22 percent).

    While businesses recognize the shift, still, 39 percent are facing difficulty integrating traditional IT, cloud and DevOps, and there is no DevOps team in more than half of the IT departments surveyed.

    The Solution

    With more than half of companies lacking a DevOps team to accommodate the integration of traditional IT and the cloud, the most pressing need is to continue re-evaluating IT’s role from one of build-and-deliver to one of facilitator. Use of an as-a-service integration framework that can be guided by and facilitated by IT but used by ad hoc integrators or developers—whose specialization is not integration but have a need to connect applications and systems quickly from time to time—is the obvious next step to resolving the issues of a SaaS ecosystem that isn’t living up to its potential.

    Such a framework can be deployed effectively using a bimodal, do-it-yourself integration approach. Those integration platforms that have begun to emerge may still be inadequate to accommodate the pervasive requirements of this major shift, since they still require IT specialists to manage the integration. The use of integration platform as a service (iPaaS) overcomes this limitation by providing a framework that empowers non-specialist IT users. Specifically, IT’s role as facilitator of this self-service platform comes into play by creating and maintaining the integration platform and a library of connectors, which then can be used not only by the integration specialists, but also by ad hoc integrators and “citizen integrators” or power users within the lines of business. As a result, the inefficient priesthood of IT is then replaced with a new balance of power between IT specialists, IT non-specialists and line-of-business users, encouraging more flexibility of integration in response to different priorities.

    The iPaaS approach brings a new level of efficiency to the many new projects that are generating storms of data, such as IoT, and it supports a move away from the older IT approach that lacks the speed and agility required in today’s environment. To make the best use of SaaS, it’s time to rethink our approach and, through universal integration platforms, bring it out into the open.

    About the Author/Renat Zubairov

    Renat photoRenat Zubairov is CEO and co-founder of elastic.io, a leading innovator in as-a-service integration.