devopsy.kinsta.cloud

Tag: devops

  • Continuous Testing vs. Test Automation: 3 Key Differences

    Continuous Testing vs. Test Automation: 3 Key Differences

    Testers have been wrestling with test automation for years, yet most teams are not satisfied with their current level of test automation or the overhead required to maintain it. Additionally, the past few years have brought a sea change in the way that applications are architected, developed and consumed—increasing both the complexity of testing and the business impact of software failures.

    How can software testing professionals help the business control risk in light of the increased complexity and pace of modern application delivery? Enter continuous testing.

    What is Continuous Testing?

    Continuous testing is the process of executing automated tests as part of the software delivery pipeline to obtain feedback on the business risks associated with a software release candidate as rapidly as possible.

    Test automation is designed to produce a set of pass/fail data points correlated to user stories or application requirements. Continuous testing, on the other hand, focuses on business risk and provides insight on whether the software can be released. To achieve this shift, we need to stop asking, “Are we done testing?” and instead concentrate on, “Does the release candidate have an acceptable level of business risk?”

    Why Do We Need Continuous Testing?

    Today, changes across the industry are demanding more from testing while making test automation more difficult to achieve (with traditional tools and methods, at least):

    • Application architectures are increasingly more distributed and complex, embracing cloud, APIs, microservices, etc., and creating virtually endless combinations of different protocols and technologies within a single business transaction.
    • Thanks to Agile, DevOps and continuous delivery, many applications are now released anywhere from every two weeks to thousands of time a day. As a result, the time available for test design, maintenance and especially execution decreases dramatically.
    • Now that software is the primary interface to the business, an application failure is a business failure—and even a seemingly minor glitch can have severe repercussions if it impacts the user experience. As a result, application-related risks have become a primary concern for even non-technical business leaders.

    How Is Continuous Testing Different From Test Automation?

    The main differences between continuous testing and test automation can be grouped into three broad categories: risk, breadth and time.

    Risk

    Businesses today have not only exposed many of their internal applications to the end user, they also have developed vast amounts of additional software that extends and complements those applications. For example, airlines have gone far beyond exposing their once-internal booking systems. They now let customers plan and book complete vacations, including hotels, rental cars and activities. Exposing more and more innovative functionality to the user is now a competitive differentiator—but it also increases the number, variety and complexity of potential failure points.

    Large-scale “software fails” have such severe business repercussions that application-related risks are now prominent components of a business’ public financial filing. Given that notable software failures resulted in an average -4.06 percent decline in stock price (which equates to an average of negative $2.55 billion loss of market capitalization), it’s not surprising that business leaders are taking note—and expecting IT leaders to take action.

    If your test cases weren’t built with business risk in mind, your test results won’t provide the insight needed to assess risks. Most tests are designed to provide low-level details on whether user stories are correctly implementing the requirements—not high-level assessments of whether a release candidate is too risky to release. Would you instantly stop a release based on test results? If not, your tests aren’t properly aligned with business risks.

    To be clear: We’re not suggesting that low-granularity tests aren’t valuable; we’re stating that more is needed to stop high-risk candidates from going out into the wild.

    Breadth

    Even if a business manages to steer clear of large-scale software fails that make the headlines, even seemingly minor glitches can still cause trouble these days. If any part of the user’s experience fails to meet his expectations, you not only risk losing that customer to a competitor—you also risk brand damage if that user decides to take his issues to social media.

    Just knowing that a unit test failed or a UI test passed doesn’t tell you whether the overall user experience is impacted by recent application changes. To protect the end user experience, you need tests that are broad enough to detect when an application change inadvertently impacts functionality which users have come to rely on.

    Time

    Now that the speed at which organizations ship software has become a competitive differentiator, the vast majority of organizations are turning to Agile and DevOps to accelerate their delivery processes.

    When automated testing emerged, it focused on testing internal systems that were built and updated according to waterfall development processes. Systems were all under the organization’s control, and everything was completed and ready for testing by the time the testing phase was ready to start.  Now that Agile processes are becoming the norm, testing must begin in parallel with development; otherwise, the user story is unlikely to be tested and deemed “done done” within the extremely compressed iteration time frame (often two weeks).

    If your organization has adopted DevOps and is performing continuous delivery, software may be released hourly—or even more frequently. In this case, feedback at each stage of the process can’t just be “fast”; it must be nearly instantaneous. If quality is not a top concern for your application (e.g., if there are minimal repercussions to doing a rollback when defects are discovered in production), running some quick unit tests and smoke tests on each release might suffice. However, if the business wants to minimize the risk of faulty software reaching an end user, you need some way to achieve the necessary level of risk coverage and testing breadth—fast.

    For testing, there are several significant impacts:

    • Testing must become integral to the development process (rather than a “hygiene” task tacked on when development is complete)
    • Tests must be ready to run almost as soon as the related functionality is implemented
    • The organization must have a way to determine the right tests to execute at different stages of the delivery pipeline (smoke testing upon check-in, API/message layer testing after integration, end-to-end testing at the system level, …)
    • Each set of tests must execute fast enough that it does not create a bottleneck at the associated stage of the software delivery pipeline
    • A way to stabilize the test environment is needed to prevent frequent changes from causing an overwhelming number of false positives

    Continuous Testing> Test Automation

    If you only take one idea away from this article, we hope that it’s this:

    Test automation ≠ continuous testing

    Continuous testing > test automation

    Even the teams that have achieved fair levels of success with traditional test automation tools hit critical roadblocks when their organizations adopt modern architectures and delivery methods:

    • They can’t create and execute realistic tests fast enough or frequently enough
    • The constant application change results in overwhelming amounts of false positives and requires a seemingly never-ending amount of test maintenance
    • They can’t provide instant insight on whether the release candidate is too risky to proceed through the delivery pipeline

    It’s important to recognize that no tool or technology can instantly “give” you continuous testing. Like Agile and DevOps, continuous testing requires changes throughout people, processes and technology. However, trying to initiate the associated change in people and processes when your technology is not up to the task will be an uphill battle from the start … and ultimately a losing one.

    If your organization is starting or scaling your continuous testing automation efforts, we encourage you to review two new pieces of research by Forrester and Gartner. Both reports provide insight into continuous testing and test automation trends as well as how the top continuous testing tools compare.

    About the Author/Wayne Ariola

    Wayne Ariola (1)Wayne Ariola, CMO of Tricentis, is a recognized thought leader on software testing topics such as continuous testing, risk-based testing, service virtualization, and API testing. Wayne has created and marketed products that support the dynamic software development, test, and delivery landscape. He has driven the design of many innovative technologies and received several patents for his inventions. He has been a contributor to the software testing space for fifteen years and in the software industry for more than 20 years. Connect with him on LinkedIn.

  • Atlassian Builds a DevOps Stack for the Enterprise

    Atlassian Builds a DevOps Stack for the Enterprise

    One of the major challenges associated with DevOps is that it’s not something an enterprise IT organization can buy. Because of that issue, it’s often challenging for IT organizations to forecast what types of DevOps tools they are going to need. To make it a lot easier to cope with that issue, Atlassian has announced Atlassian Stack, a suite of software that makes Atlassian DevOps tools available in a single package.

    Sean Regan, head of product marketing for Atlassian, says this approach will make it easier for enterprise IT organizations to embark on a DevOps journey without having to worry about what type of tool they may need now versus in the future. For example, an IT organization may opt to get started using the Atlassian Jira software to track software development projects and then work its way up to deploying Atlassian Bamboo continuous integration/continuous deployment (CI/CD) software. From there, Regan says, a DevOps team may opt to embrace collaboration software to streamline communications across their various teams.

    The move to launch Atlassian Stack comes after the company updated a slew of its DevOps offerings, including the release of Bitbucket Server and Data Center 5.0 and Bamboo 6.0. In addition to tightening the integration between both DevOps tools, the company added capabilities for verifying commits, smart mirroring and the ability to define a Bamboo configuration as code.

    Rather than making DevOps teams acquire each tool individually, he says, many senior IT leaders now request a means through which the entire Atlassian portfolio can be made more readily available. That shift in purchasing behavior suggests that the level of DevOps maturity inside many organizations is advancing considerably, he notes.

    Of course, there are many who would contend that level of DevOps maturity has been a long time in coming. Web-scale companies have been employing DevOps tools for years to accelerate the rate at which new applications are released and updated. In contrast, traditional enterprise IT organizations have been slow to implement DevOps processes. In fact, it’s taken the pressure arising from digital business transformation initiatives that have accelerated application deployment timetables to get enterprise IT organizations to fundamentally rethink IT operations. Business leaders are making it painfully obvious that their patience with extended rollouts for new applications is at an end.

    Naturally, the rate at which those transformations are occurring within organizations will still vary considerably. However, the silos that exist within enterprise IT organizations need to be consolidated. The next issue is determining to what degree altering those processes needs to come in the form of a DevOps edict from above versus letting teams come together of their own accord to meet a specific application deadline. Whatever the approach, the way enterprise IT has been managed historically is no longer up to the digital business transformation tasks at hand.

    — Mike Vizard

  • Survey: DevOps Divide Grows a Little Wider

    Survey: DevOps Divide Grows a Little Wider

    The gap between the number of organizations that have invested in DevOps is starting to narrow, and IT organizations that made the transition to DevOps earlier are starting to see accelerated returns on that investment, according to the latest survey by Puppet.

    The annual “State of DevOps Report” finds that out of 3,200 IT professionals surveyed, only 11 percent were part of organizations that could be considered high DevOps performers. High performers are deemed to have higher deployment frequencies, lower lead times for changes, better mean time to recovery (MTTR) and better change failure rates. The higher performers in this year’s survey are deploying applications 46 times faster than the same designated group of higher performers were last year.

    The survey also finds that higher-performing organizations have automated 72 percent of all configuration management processes. Those same high performers spend much less time (28 percent) employing manual configuration processes. Lower performers are spending almost half of their time (46 percent) on manual configuration.

    Just over a quarter (27 percent) of the respondents self-identified themselves as being part of a DevOps team, according to the survey. In contrast, only 16 percent said the same last year. Puppet CTO Nigel Kersten says those results suggest that understanding of the power of DevOps is increasing. It’s also apparent the early implementers of DevOps processes are enjoying a level of IT agility that is much greater than the average IT organization.

    In general, Kersten says that while much DevOps progress has been made, most IT organizations have automated only various pockets of silos. Developers, for example, may have automated some processes on their own, while IT operations specialists may have developed a custom script to automate the configuration of a handful of servers. Kersten notes IT leaders should be cognizant of the technical debt their organizations are incurring every time different elements of the IT organization employ different tools to automate the same basic processes time and again.

    Very few have automated their operations within the context of a continuous integration/continuous deployment (CI/CD) pipeline, says Kersten. That becomes more challenging to accomplish as new computing models based on containers, for example, are added to the enterprise mix. On a more positive note, Kersten says more processes are being well-defined, as they are bounded by an application programming interface (APIs). Those APIs then become the core technology over which IT automation frameworks are then laid.

    The issue many IT organizations have yet to confront is the degree to which they want to stumble toward DevOps versus implementing a concerted plan of action. Much of the DevOps progress to date has been driven from the bottom up inside many organizations. The time is now approaching for IT leaders to imbue DevOps as a part of the IT culture that permeates the entire organization.

    To one degree or another it’s a safe bet every organization will implement some form of DevOps going forward. The challenge  will be figuring out how to transform all those isolated instances into something more akin to an actual IT strategy.

    — Mike Vizard

  • Spurring the DevOps Adoption Journey

    Spurring the DevOps Adoption Journey

    Every few years, the IT canvas is splashed with a new initiative that sparks enthusiasm among businesses and technologists alike. DevOps is one such philosophy gaining significant momentum in today’s digital transformation landscape. At the same time, the concept remains misunderstood and adoption is slow.

    DevOps embodies Development plus Operations within software development. Traditionally, these two parts of an organization have operated siloed from one another with marked differences in both ethos and approach. The result: delays in launching products and releases to the market. The fundamental principles of DevOps are to reduce barriers between Development and Operations; increase Development autonomy; and to automate Development and Operations activities to reduce wait time (and waste from a customer’s perspective), thus enabling faster time to market—all while keeping the end customer at the center.

    Planning the Adoption Journey

    Here are four different aspects an organization should consider before starting the DevOps adoption journey:

    Conduct an as-is continuous delivery assessment on product development practices and processes within the organization

    This will best determine an organization’s current maturity level across several different parameters, including:

    • Culture and organization
    • Build management and continuous integration
    • Environments and deployments
    • Release management
    • Testing and verification
    • Data management
    • Design and architecture
    • Information and reporting

    This process also includes identifying current automation levels and opportunities to automate, inclusiveness of tools and environments supporting continuous delivery, and an assessment of existing product design to determine if it lends itself to frequent and fast deployments.

    Map the journey of a piece of code from a developer’s desk all the way to when the consumers use it

    Utilizing a development pipeline assessment to study the life cycle of a piece of code through its journey from a developer’s desk to production will best identify “waste” during the life cycle. This assessment should bring out critical information, including the number of environment hops, test pyramid maturity and level of continuous testing, level of provisioning and deployment autonomy and its automation.

    Establish a culture of inclusiveness, autonomy and a sense of a ‘common goal’ within the organization

    Product management, development and operations teams should have a common mission and goal for the product, sprint or release they are working on. The definition here should be the value delivered to the customer as opposed to the value of code, test results, or individual deployment steps. Including operations roles within a close-working scrum team benefits this cause by:

    • Bringing in common views on what a product, release or sprint is intended to deliver.
    • Creating an opportunity to bring forward and address operations needs during the development cycle.
    • Creating a better understanding of mutual expectations and empathy for delivering outcomes that meet customer expectations.

    Measure and track

    Finally, determine parameters the organization would like to establish to track progress towards a successful adoption. The key here is to have a few, simple metrics that truly reflect “value to the end customer.” Here are a few commonly considered metrics:

    • Production deployment frequency: The number of product releases within a specified time.
    • Average lead time for a production change: The typical amount of time it takes for a piece of code to traverse from a developer’s desk through production.
    • Average production recover time: The time taken to bring back production systems after an incident involving a release, release rollback or system outage.
    • Change failure rate in production: The number of releases that did not stick in the live environment and needed either a rollback or an immediate emergency fix.

    The goal and a true measure of successful adoption would be an improvement of all these parameters over time. Internally, they would require strong engineering rigor and cultural realignment to be able to improve these customer-facing metrics.

    Navigating DevOps adoption successfully is neither easy nor fast for a number of reasons. DevOps encompasses different parts of the organization, which historically may have operated in silos and with different ethos. DevOps also questions the status quo regarding engineering roles and practices, and focuses on automation and reskilling, all of which need both upfront time and effort investment. Finally, DevOps believes in and propagates continuous learning and improvement, whereas many organizations may have more stepwise-based programs in place.

    For a midsized IT organization, it could take anywhere from 18 to 24 months or more to be able to reach a reasonable steady state. That’s why it is important to carefully craft a charter that encompasses the above parameters before embarking on this DevOps adoption journey.

    About the Author / Amit Gupta

    Amit Gupta is leader of Ness Digital Engineering’s DevOps practice. He has several years of software delivery background. He has keen interest and has developed deep expertise in establishing practical software development processes especially for globally distributed teams. Amit currently leads Ness Digital Engineering’s DevOps practice, and engages with several customers on such areas as improving engineering effectiveness, engineering tools and process transformation. Connect with him on LinkedIn.

  • DevOps 2.0 for Digital Transformation

    DevOps 2.0 for Digital Transformation

    We already know that DevOps is a culture, a movement, a philosophy of software development and delivery. It focuses on the communication, collaboration and continuous integration of the entire organization—a new conception of software development whose adoption is not easy. It aims to streamline software delivery by removing barriers between developers and IT operations teams. It also aims to reduce the inefficiencies of processes, adopting new tools, and even proposing changes in business architecture.

    Agile practices allow development teams to deliver iteratively more frequently, among other things. In DevOps, the entire process cycle is automated to achieve continuous integration and continuous deployments (CI/CD). The test and safety teams are involved from start to finish following an end-to-end strategy. At the same time, with the principles of Lean, we have removed from the whole process what does not add value. Thus, it is getting more productivity, maximum value and improvement in the time to market.

    Talking about DevOps is thinking about techniques, patterns and good practices. It will help us to provide our organization with an efficient software architecture—an architecture based on microservices, with everything-as-a-service mentality (XaaS). We are talking about container, automation, elasticity, self-scaling, infrastructure such as code, monitoring, configuration management, self-sustaining and adaptable systems and ecosystem, all of which allow us to deliver value with fast, reliable and frequent developments, not to mention zero downtime and, of course, the ability to undo the changes.

    How Do We Prepare to Meet User Expectations?

    DevOps aims to help an organization to produce software products and services quickly. But end users are becoming more and more demanding. We must use techniques that allow us to make faster, functional deliveries to the production environment, mitigating the risk involved.

    At present, we face users with greater technological knowledge and greater expectations in the dynamic and interactive experience than we used to some years ago. This has evolved and given rise new one called DevOps 2.0 or BizDevOps (business, development and operations).

    DevOps 1.0, as the origin of the movement, was focused on operations teams giving continuous feedback to development teams as well as to SQA teams. However, DevOps 2.0 is now focused on extending the benefits of feedback to the entire organization (marketing, sales, product, etc.). This is what will allow a greater adaptation to the IT boom and the digital transformation (IoT, intelligent platforms, big data, etc.). Additional benefit of DevOps 2.0 is faster continuous software deliveries, without compromising the stability of systems in production.

    Toggling Features or Feature Flags

    At this point, the key is to use techniques that helps to decouple the software delivery of new functionalities. In other words, it is about making these new functionalities available to the end user based on business rules instead of the operation teams. The idea would be that, for instance, marketing and sales department can decide, using “flags,” when to release or enable a new functionality to the end user. It will allow us to deploy new functionalities to the production environment more frequently without enabling them to the end user. This removes the “fear” generated by the daily deployment processes in production environments. This is what is known, in DevOps 2.0, as the rollout.

    Using this simple best practice for development, called Flag Driven Development, we do not make available the new functionality to 100 percent of users. It will be delivery in stages, starting with 1 percent of users, then with 10 percent, then with 30 percent, etc. with the ability to quickly enable or disable the functionality when something does not work as expected. In addition, it allows us to make available different versions of a functionality for different types of users (customer segmentation). There are several SaaS models and open-source solutions we can use to implement this type of techniques like Feature flags, toggles or controls.

    What are the Benefits of DevOps 2.0 Techniques?

    The use of this type of techniques during the development process provides these benefits:

    • Quick scaling
    • Stability of the system
    • Integrity of the applications is not compromised.

    This way we succeed in reducing the risk associated to each new delivery of functionality, in any productive environment. Business stakeholders can control when new features are available to end users, who continuously demand new changes and improvements.

    For organizations, DevOps 2.0 will bring DevOps power to non-technical teams such as marketing, design, sales and business. Now all teams will have the skills and responsibilities that are required in a DevOps culture. It enhances the confidence, communication and feedback that is needed from all teams in a DevOps strategy.

    Therefore, one of the major pillars of the DevOps 2.0 approach is the ability to control, through a control panel interface, the launch of new features of applications in production environments. This process would be launched in a controlled way by both technical and non-technical people. Also, the process will be separate from the development and continuous deployment.

    At the same time, this type of coding techniques will allow to perform real-time analytics, making changes to the functionalities of a system that may also impact in the application performance monitoring (APM) tools. This makes it possible to determine when a particular functionality is degrading the global system performance and needs to be disabled quickly, as well as identify which functionalities are improving the end user experience (UI/UX).

    There are a lot of articles about these “Fast Feedback” practices. I hope this article help you better understand the potential impact of DevOps on your organization.

    About the Author / Jesús Pérez Franco

    Jesús Pérez Franco is an Operations Manager at Gfi Spain. His big passions are Agile Development and DevOps Continuos Delivery (Continuous Integration, Deployment, QA Automation and Infrastructure as Code, etc.). Connect with him on Twitter and LinkedIn.

  • Q&A: Michael Beckley, CTO/CCO, Appian

    Q&A: Michael Beckley, CTO/CCO, Appian

    Recently I had the chance to speak with Michael Beckley, chief technical officer and chief customer officer at Appian, about his company’s move to go public and the DevOps space in general. For those of you who don’t know Michael, he is a founder of Appian and leads the company’s technology vision and oversees customer initiatives worldwide. He also serves on the Industrial Advisory Board for the University of Virginia’s Computer Science Department and is a member of the University of Maryland Advisory Board in Computing. He has an interesting take on the IT space and DevOps in particular. Read on for our discussion.

    Alan Shimel: Michael, what do you think has been the “special sauce” that has led to Appian’s success to date?

    Michael Beckley: With Appian, companies build unique business applications up to 20x faster and mobile-enable and modernize existing systems. For example, a company like Ryder was able to build a web and native Android tablet application that cut the time it took to rent a truck in half.

    But the “special sauce”? That’s Appian’s culture of innovation. Our engineers think long-term and invest in breakthrough tech like our patented SAIL UI technology for zero code native mobile apps. Thanks to SAIL, the web apps you configure in Appian automatically deploy to iOS and Android as native, full-featured apps or specialized micro apps we call “Sites.” As long as we get the culture right, we expect to continue to deliver enduring value for our clients.

    Shimel: With becoming a publicly traded entity, some companies have found “managing to the street” does not match their own long-term business plans and their customers needs, how does Appian avoid this?

    Beckley: Companies, like people, are an aggregation of their habits. Appian’s habit has always been to hold to our long-term vision of enabling every company to be a software company. We are not your typical Silicon Valley tech company. Our roots are in DC, we largely bootstrapped this business, and learned to be good stewards of capital while helping to support the core missions of federal agencies and some of the world’s largest brands. The proceeds following this IPO will be invested back into our business to benefit our customers.

    Shimel: What do you see post-IPO being the biggest areas for growth as it relates to new products and services?

    Beckley: We  plan to invest in innovating and enhancing our platform. While our platform is industry-agnostic, we have recently made, and plan to continue to make, investments to enhance the expertise of our sales and marketing organization within our key industry verticals of financial services, health care and government. We have made, and will continue to make, investments in research and development to strengthen our platform and expand the number of features available to our customers. As we continue to increase the functionality of our platform and further reduce the amount of developer skill that is required to build robust applications on our platform, we believe that we have the potential to expand the use of our platform.

    Shimel: Digital transformation is a term that is being used a lot these days. How far along the adoption curve are we on digital transformation?

    Beckley: While many speculate that digital transformation is just a tech industry buzz word, in reality, digital transformation is a living, breathing effort. According to a recent survey, digital transformation is a C-level priority and is considered a top focus for almost 50 percent of all companies this year.  From Appian’s perspective, we believe that the utilization of low-code software to drive digital transformation is still relatively new and our customers will be able to succeed in their digital transformation efforts by incorporating low-code development.

    Shimel: Where does the DevOps market intersect with the Appian business model?

    Beckley: Organizations are turning to DevOps to accelerate development and bring an application’s capabilities to a user quicker. The Appian low-code development platform fits into the DevOps model and supports the seven major DevOps categories including code, build, test, package, release, configure and monitor.

    Overall, our business model supports the DevOps market; we’re living in a world where citizen developers are playing such an important role in the enterprise and our platform empowers the citizen developer while alleviating developer resources to focus on the more challenging, business-critical developer work.

     Shimel: What about containerization and microservices? How do these technologies affect Appian?

    Beckley: Appian already uses containers and microservices. Appian’s enterprise customers often require a mix of cloud, hybrid cloud, and on-premise installations. We view containers and microservices as enabling technologies to support the diverse workloads and deployment models required by our enterprise clients.

    Shimel: What about security? What challenges does cybersec pose to Appian’s development of their platform?

    Beckley: Appian works with some of the nation’s most important and highly regulated industries, therefore we have built a comprehensive security and compliance structure that meets several industry standards. We frequently undergo third-party audits to ensure that we are always operating effectively to protect our customer data.

    — Alan Shimel

  • DevOps Needs a New Cloud Solution for Best Practices

    DevOps Needs a New Cloud Solution for Best Practices

    Imagine this scenario: You are a company building modern software which is a key driver of your business. To support this, you have grown your infrastructure organically over time by adding servers, storage, networks, security, virtualization software, monitoring, alerting and analytics tools. You have also added a plethora of other middleware, databases, messaging and operating systems that your developers need to build, test and deliver their applications.

    Because of this unplanned organic growth, there is no consistency in the environment. You manage, maintain and operate much of this environment manually. Your various specialist teams (storage, networking, security) begin to form fiefdoms around their respective functional areas. Change becomes extremely difficult and automating across silos turns into a maintenance nightmare. You over-purchase to meet the demand and risk under-utilizing resources. Your costs spiral out of control. You are now finding it a hopeless challenge to meet the needs of your developers—which was the primary purpose of doing all of this in the first place.

    Moving to a Modern Platform

    A modern DevOps platform should address the requirements of both your development and IT/operations teams. It should give software development teams an easy way to consume on-demand compute, storage and networking as well as provide easy access to continuous integration and continuous deployment (CI/CD) tooling and software services that help increase their development throughput and shorten product delivery. In addition, the platform should also empower operation teams to manage, maintain and operate the entire infrastructure environment with very few people using smart software that drives automation and intelligence into the entire stack.

    In short, it should have the ability to break the silos within your IT environment and between development, QA and operations teams. By doing this, you can increase the velocity of software development, improve infrastructure utilization, increase overall operational efficiency and reduce costs.

    Requirements for a Cloud Infrastructure That Streamlines DevOps

    There are several requirements for a modern, cloud-based DevOps platform. Let’s look at the key essentials of such a solution.

    Self-service API-driven infrastructure is a fundamental requirement to enable infrastructure as code, a key attribute to enable DevOps best practice. It allows developers to write code (which can be done using their favorite programming language) and make RESTful API calls to the underlying programmable infrastructure to manage initial deployments and configurations. It also enables them to manage ongoing automated dynamic provisioning of infrastructure, auto-scaling, monitoring and alerting.

    All this automation removes the confusion and error-prone manual steps for the entire application delivery process, including development, testing, staging and production deployments. This, in turn, accelerates software delivery and increases quality.

    However, building such a self-service API-driven infrastructure by yourself is not easy. The key component that drives up the cost is the operational complexity and the cost of experts needed to build and operate it.

    Smart software that drives intelligence into the stack. Very few solutions in the market automatically handle the full life cycle (deployment, upgrades, monitoring, alerting and ongoing resource management) of infrastructure and also allow seamless migration of workloads between private environments and public clouds. Additionally, if self-service is available as a SaaS-based delivery model, it is easy to add more features and workflows very quickly without having IT perform a major upgrade. If your solution comes with an on-premises install, ask how much work IT has to do to maintain this environment and how often new features will get added.

    Hyper-converged Infrastructure (HCI): Eliminating silos in the infrastructure. As mentioned earlier, silos impede velocity because they lead to complexity of operations, lack of consistency in the environment and lack of automation. A hyper-converged cloud design with a software-centric architecture tightly integrates compute, storage, networking and virtualization resources and other technologies from scratch in a commodity hardware box supported by a single vendor. This approach eliminates silos and lowers costs and complexity. It also makes it easy to start small and grow on demand while staying tightly right-sized on capacity and cost.

    A built-in browse-able categorized application store. DevOps engineers need readily accessible CI/CD tools such as Jenkins, Git, Maven or JUnit to automate the development and test pipelines. Additionally, tools such as Ansible, Puppet and Chef help with automated configuration and lifecycle management of workloads. Application developers need to quickly integrate and deploy middleware services such as RabbitMQ, Redis or storage back-ends including MySQL, Postgres, Cassandra or MongoDB. Single-click deployment of such services and other complex multitier network tools and applications greatly automates, accelerates and simplifies the development process.

    Seamless migration between private and public clouds. Developers and testers often need much greater capacity than is available on-premises for scale testing, and they should be able to move their application to a public cloud for such purposes. Alternatively, they may already have some applications running on a public cloud and they may want to bring them back to their private cloud for cost savings or better performance. For these use cases, a private cloud solution should offer seamless bi-directional migration between the public cloud and the private cloud.

    Dashboards and visibility for troubleshooting. One of the key advantages for a private cloud is that you can get complete visibility across the infrastructure and applications. In a public cloud, you can only get VM-level stats but have no control or visibility below that. Make sure that your private cloud solution can provide visibility to developers directly. Many vendors only provide access to IT, thereby controlling what developers can do and making IT a bottleneck in the application development and deployment process.

    Better insights to improve efficiency and capacity management. A cloud requires capacity planning, utilization monitoring, right-sizing of workloads and detecting zombie VMs and unused resources. Look for a solution that comes with built-in analytics, management tools and insights. An even better approach would be having a solution where you don’t have to install the management tool on-premises so that it can deliver its value as a service.

    To meet the needs of application developers and development frameworks and to create an efficient DevOps platform, companies should look at consistent converged architectures managed via smart software. This empowers application developers and operations teams to leverage a consumption model they want, while providing control to IT and making them relevant to your business success.

    Integrated intelligence and insights delivered as a service ensure that you never have to use spreadsheets to decide what to purchase and when. Cloud solutions with smart software ensure that you never have to make a Level 1 support call again; your management software can do that for you.

    About the Author / Kamesh Pemmaraju

    Kamesh Pemmaraju leads product management, product marketing, and technology partnerships at ZeroStack. Kamesh is a seasoned product management/marketing leader with a strong engineering and consulting background. In his most recent product roles at Mirantis and Dell, he focused on delivering private and hybrid cloud solutions to enterprises. He holds a Master of Science in Computer Science from Indian Institute of Science. Connect with him on LinkedIn and Twitter.

     

  • Improve IT Security by Improving Company Culture

    Improve IT Security by Improving Company Culture

    All around the world, cybercrime rates are rising, and it’s clear that traditional criminals are constantly developing new ways to attack. These days, wreaking havoc requires nothing more than internet connectivity and a pronounced lack of scruples. With a lowering barrier for entry causing an increase in the pool of malicious actors, many enterprises are struggling to protect themselves.

    Buzzwords such as “cybercrime” and “black hat” are now commonplace, and global spending to combat cybercrime reached $80 billion in 2016. Despite these efforts, only 38 percent of organizations surveyed for ISACA’s “2015 Global Cybersecurity Status Report” were confident in their ability to defend against cybercrime attacks.

    Why Does Security Still Suck?

    With high levels of cybercrime awareness and direct steps being taken to address these challenges, it begs the question: Why does IT security still suck?

    One of the primary reasons many enterprises struggle with cybersecurity is a lack of cultural support in the workplace. C-suite policies often hinder success more than they help by pushing employees to the brink and creating an environment that leaves their businesses susceptible to human error and attacks.

    While Brooks’ Law can serve well as a guide, it’s often a harbinger of bigger problems in many enterprises: When a software project is running late, leadership often brings another employee onto the project and, as a result, slows things down even more. Between the security system add-ons and services and the human capital involved in taking time to understand the issues as they arise, productivity takes a major blow—without any measurable benefit to security. This traditional tactic has attempted to ignore the crucial fact that 77 percent of professionals said that their information security policies and teams are slowing IT down.

    Compounding these issues is the fact that traditional security tools require an immense amount of time and manual labor. Because these legacy platforms do not have the ability to automate even basic functions, IT professionals are often required to monitor security tasks and patch vulnerabilities around the clock. This is a major responsibility, as the costs of an attack or other breach can be devastating to an enterprise.

    Further, IT security professionals are rarely rewarded for successful efforts. This is challenging for two reasons. First, no one is congratulated for creating a security-sound app, as the consumer expects nothing less. Second, it can be difficult to convince corporate leadership of the need for improved, automated security tools before an attack occurs. Painting a realistic depiction of a hypothetical situation (in this case, the damage caused by a cyberattack) is hard to do, and professionals often struggle to demonstrate their value without resorting to scare tactics. Scare tactics, independent of statistical supportability, have a shelf life and are subject to diminishing returns. Corporate leadership teams don’t regularly identify or prioritize security problems until it’s too late, so they don’t consider the cost to their employees who are fighting these battles on a daily basis. Together, all of these factors add up to fatigue, frustration and burnout for IT security professionals.

    It’s safe to assume that we all want to do our best work. When we don’t have the tools and support necessary to do quality work, attitudes and culture suffer.

    To stay ahead of security concerns, C-suite policies must not tackle IT issues or adjust to new regulations as they arise, but ensure that efficient, effective security practices are baked into agile DevOps processes rather than bolted on. It is essential for leadership to be proactive, rather than reactive—once an enterprise falls behind the curve, its software applications and valuable data are at increased risk until vulnerabilities can be patched.

    Perhaps not surprisingly, this proactive attitude does not always come naturally. Management often wants to do things the way they’ve always been done, but they need to become more agile as well. Security within an organization will benefit from pushing awareness across the enterprise, rather than keeping security professionals siloed within their own department. There’s a fine line between educating employees and using scare tactics, but leadership must be informed of vulnerabilities and necessary steps for shoring up weaknesses.

    However, education can only go so far; automation is the real key to taking the risk out of the hands of security professionals. Modern tools will allow your team to rest easy at night while proactively focusing on your enterprise’s rapidly evolving applications. This makes your employees happier, your security stronger and your business better.

    About the Author / Ash Wilson

    Ash Wilson is a strategic engineering specialist at CloudPassage. He has been a paid tech worker since March 2000, and a hobbyist long before that. He came to security via network engineering and systems administration. Ash spent the last five years in post-sales engineering and strategic engineering for security product companies. Connect with him on LinkedIn and Twitter.

  • DevOps Doesn’t Stop at the Database

    DevOps Doesn’t Stop at the Database

    DevOps has moved into the mainstream and practices such as continuous delivery now are being widely adopted. But what about the database? Applications often have a back-end database that needs to be developed and maintained at the same time.

    At first glance, there doesn’t seem to be an issue. The recent “State of Database DevOps Survey” from Redgate showed that 75 percent of companies have developers in their team who work across both applications and databases.

    Investigate a little deeper, however, and the cracks start to appear. The survey also showed that while version control is used by 81 percent of those in application development, it falls to 58 percent for the database. The same is true for continuous integration and automated deployments—39 percent and 33 percent for the application, 20 percent and 21 percent for the database.

    What’s going on? If developers are increasingly responsible for the database as well the application, why can’t the principles of DevOps be applied across both areas? That way, rather than the database being the problem at the end of the pipeline that can (and many times does) cause releases to fail, it becomes part of the pipeline.

    Especially when you consider that the biggest downside of traditional siloed database development is the downtime often experienced when introducing changes. That’s not to mention slowing down releases and preventing companies responding rapidly to changing business requirements.

    A typical DevOps workflow looks something like this:

    Code is version-controlled so different developers can work on multiple branches at the same time. When it’s checked into the version control system (VCS), often at the end of each day, it triggers a continuous integration process that builds and validates the changes. Once the changes are complete, a release management tool then pushes them through the testing, QA and staging environments and there’s a final review before the changes are deployed to production.

    Not every company does all of this, but many do different parts of it and plan to extend DevOps practices into other areas. They might start with version control, for example, get the team accustomed to checking in changes, and then move on to continuous integration.

    It works too. The “2016 State of DevOps Report” from Puppet found that organizations practicing DevOps deploy 200 times more frequently, recover from failures 24 times faster, and have a 3 times lower change failure rate. DevOps has moved from a developer-led approach to one that businesses are actively encouraging.

    Thing is, database development can be part of the same picture as application development. Let’s take another look at that DevOps workflow:

    The same workflow, but this time with database development included. Note that there are no extra boxes or arrows, there are no asterisks with caveats, and the only difference is that database development has been added to application development and a DBA has stepped in to the frame.

    But how can database development be added to the DevOps mix when it requires new tools, separate processes, a different mindset? The answer is to think about integration not separation, and extending the current infrastructure not replacing it.

    Application development teams, for example, will use a VCS like Team Foundation Server (TFS) or Git, a continuous integration system like TeamCity or Jenkins, and maybe a deployment automation tool like Octopus Deploy. They’ll also have a favored IDE for application development, probably Visual Studio, and if they do database development, they may well work in SQL Server Management Studio as well.

    Ask them to add to their workload with unfamiliar tools and development environments, or enforced policies and processes, and the shine of DevOps starts to lose its luster. What was freeing them to perform better is now tying them down to an unwelcome way of working.

    Ask them, on the other hand, to use the same tools and processes but extend their capability to database development and it’s a different story. If they already version application code using TFS, for example, there are database version control tools out there that plug into it so that database development becomes an additional part of the process, not an extra process.

    The same is true for continuous integration, release management and deployment. At every step of the DevOps workflow, database development can join application development so that it’s a natural partner rather than an unwelcome guest.

    But just how realistic is this approach? When development teams are already facing the challenge of introducing DevOps, is it a pipe dream to think the database will even be considered as part of the picture?

    According to Microsoft, no. When Visual Studio 2017 was launched in March, the Enterprise edition included Redgate Data Tools in the installer to make it easier for users to implement DevOps practices when building, deploying and maintaining their SQL Server databases.

    As Shawn Nandi, senior director for Cloud App Development and Data product marketing at Microsoft said at the time: “We think this is an important step forward to help companies extend DevOps practices to all parts of their applications.”

    So if you’re considering adopting DevOps, remember the database can be part of it, too.

    About the Author/Matt Hilbert

    Matt Hilbert is a technology writer at Redgate Software with 20 years’ experience working for lots of the world’s biggest tech companies – and many of the smallest. He has a particular fascination for emerging technologies and is on a continuing mission to decompile, untangle, and explain techspeak to a wider audience, and excite people about the endless possibilities technology offers.

     

  • Achieving True Automation is a Marathon, Not a Sprint

    Achieving True Automation is a Marathon, Not a Sprint

    But It Starts in the Cloud

    Arguably, the most important goals for companies seeking to get into cloud today are agility and flexibility to innovate at speed and scale. Adding cost savings to the mix makes the possibilities all the more attractive. And these three pillars can only be achieved with automation.

    But while many companies may believe they’re automating (and thus attaining these three goals), they’re really not. In the rush to cloud adoption, they fail to see that this type of investment takes time and work—a lot of work. Think of it as a marathon, not a sprint.

    While it’s a significant step toward achieving scale and speed, simply moving an application to cloud is not enough to attain true automation. Adding genuine automation to your server means enabling it to spin up or down as needed, react to scaling requests and shut down when not in use. Only when these processes are in place can you then start seeing the cost savings and agility promised by cloud.

    While there is no simple road map to achieving true, seamless automation (near-Nirvana), there are clear and well-worn steps that organizations seeking these goals can take. Looking at it from a broad perspective, automation in the cloud depends on two major initiatives.

    Long-Term Value is in App Automation

    The first step is to figure out where automation will provide the most value (from an application perspective). In most cases, at least as far as what we’re seeing across the marketplace, the answer to this will likely revolve around infrastructure.

    The second step gets a bit trickier. You essentially want to connect automation to the applications themselves (replacing the manual task of writing a script). The challenge then becomes pulling the application back into the larger architectural context so that it can respond to an event without human intervention. This phase involves making the application cloud-ready—that is, furnishing it with the ability to trigger automation without someone sitting at the controls.

    This second phase bears closer scrutiny—it’s here that the people on the ground start to lose faith, because with some applications automation may seem all but impossible. Let’s face it: A fair majority of applications were not designed with automation in mind. Legacy applications in particular (which typically constitute the bulk of most companies’ IT estate) are fairly fussy when it comes to automation. This is when organizations start debating the value of opening code and making changes—whether the investment of time and capital is really worth it.

    Which brings us to the two biggest barriers to automation—costs and culture. Yes, it can be expensive to implement the processes and skills to achieve game-changing automation in the short-term. It requires moving application development specialists to new roles, a massive shift in culture and skill sets within IT. This is particularly true for code development, which has been manually focused for so long. Many companies fail because they don’t see automation as an ongoing true software development program (which, of course, it is).

    Attaining DevOps

    The Holy Grail of automation is achieving a seamless Development-Operations environment (DevOps), one in which software developers and the IT folks are continuously collaborating and communicating to automate software delivery and infrastructure changes. One of the chief goals of DevOps is to create a culture and environment where building, testing and releasing software happen frequently, rapidly and reliably.

    Achieving a true DevOps environment means that you are a functioning automated shop. Automation does not end with the first deployment. In fact, it is only the beginning. You will continually face new upgrades and changes in service, requiring near-constant tweaking. But automation smoothes the process, loosening the friction of life cycle management. Automation becomes embedded into the very fabric of your entire IT estate.

    For some companies (mostly startups), automation is not a luxury but a necessity. Look at Netflix (which, in some respects is less of a startup and more of an established player). The only way the company could scale and stabilize to meet customer demand with the success it has over the past few years was to automate. It would be physically impossible for Netflix to serve its customers any other way.

    Same with Amazon. Jeff Bezos figured out early on the value of automation in the cloud and built the flexibility into Amazon’s infrastructure to grow and scale according to exponential customer expansion.

    We’re seeing this happen increasingly across industries—from the financial sector to the healthcare industry.

    One large global financial institution is changing its very culture by putting automation at the very core of everything it does, from loan applications to payroll. It has taken the bold step of only adopting applications that can be automated. The simple rule of thumb here is, “If we can’t automate it, we’re not going to do it.” This has resulted in the financial institution being able to provide an improved customer experience, providing features for customization of services via their mobile banking app.

    Another is Avalon Healthcare Solutions, a laboratory benefit management company. The organization wanted to accelerate service delivery with a 100 percent cloud-based claims editor. So it developed a portal for providers, patients and health plans to offer appropriate access to data, claims and prior authorization. Avalon can now edit from 28,000 to 38,500 per hour in a single environment with 99.99 percent uptime and 99.95 percent accuracy,

    The lessons here are clear. By pacing their race with an eye for the long-term goal, Avalon, Amazon and Netflix—among others—trailblazers across industries, are reaping the benefits cloud-automation offers. Namely, they are scaling, becoming more agile, innovating and delighting their customers all at the same time.

    About the Author / Chris Wegmann

    Chris Wegmann is Managing director for Amazon Web Services Practice & Relationship lead, responsible for helping Accenture cross-industry enterprise clients leverage the power of Amazon Web Services including through the Accenture Cloud Platform. He has 20 years of experience in technology consulting and specialization in technical architecture, infrastructure design and engineering, legacy system migrations, cloud application architectures and systems operation. Connect with him on LinkedIn and Twitter.