Tag: automation

  • Keep Applications Running by Testing Early, Continuously

    Keep Applications Running by Testing Early, Continuously

    Almost every product we buy or use today goes through some form of extensive testing before it’s released on the market; typically, these tests are designed to replicate the worst-case scenarios that a product may encounter under real-world conditions.

    Automobiles, for example, go through extensive hot and cold weather testing in remote locations, and are driven over obstacle-laden tracks designed to push the limits of their durability. Even seemingly mundane objects such as children’s toys are exposed to abusive simulations to ensure that they don’t harbor any potentially hidden and harmful effects.

    On the current landscape, applications are the face of your business, often serving as the battleground where consumer loyalty is won or lost. Given this reality, it seems crazy to think that any applications are released having only been exposed to a minimum of tests. Yet, in the name of getting to market quickly, that’s far too often the case.

    As disciplines including agile and continuous delivery continue to increase the speed at which development teams can release software, it’s easy to put the crunch on testing in the rush to get an update released. But that’s a costly mistake in the long run, as research has shown that it is 50 percent less expensive to find an error in testing than to address the same error once it has reached production, and more than 90 percent cheaper  when addressed in the development/coding phase.

    Given the dramatic cost savings of addressing errors in development, clearly the goal of any organization focused on continuous delivery should be to shift testing left so a greater number of defects are found early in the development process. This is what we refer to as continuous testing, and it’s a huge part of the reason why I am so excited about CA’s acquisition of BlazeMeter.

    Performance load testing should be a core element of any continuous testing strategy because it is a critical factor in determining system reliability. Similar to the worst-case scenario testing that consumer products undergo, performance testing can quickly uncover applications defects that might otherwise go unnoticed. After all, the manner in which a system operates with a few hundred concurrent users may be very different than how it runs with thousands of users.

    BlazeMeter enables today’s development, operations and DevOps teams to conduct this critical performance testing earlier in the development process, saving countless hours and resources. The company is also competing—and winning—in a highly competitive marketplace where it has been pitted against much larger, more entrenched competitors.

    Part of the reason BlazeMeter is winning is its focus on offering a SaaS-based solution that is highly cost-effective and easy to engage. Using this model, customers can try  out the testing software with a few clicks, and then quickly move forward to broadly adopt the system. Another catalyst to its success: BlazeMeter was built using open source tools, such as Apache JMeter, used widely in the development community for performance and load testing. As a result, BlazeMeter can easily run and analyze JMeter and other open source-based load tests—such as Selenium, Gatling and Locust—within a commercial-grade performance testing system.

    This combination of a SaaS delivery model and incorporation of open-source tools, augmenting strong performance testing functionality, make BlazeMeter very complementary to CA’s existing continuous delivery solutions, including its CA Service Virtualization, CA Test Data Manager, CA Agile Requirements Designer and CA Release Automation products.

    At CA, we’re committed to providing the most comprehensive, integrated and open continuous delivery ecosystem, allowing our customers to release swiftly, test agilely and constantly increase reliably. The addition of BlazeMeter will further enable customers test continuously, thereby increasing agility and the overall quality of their software, to ensure that applications don’t break down on the side of the virtual road.

    — Aruna Ravichandran

  • Q&A: BDO’s Coffman on Change Management, Security and DevOps, Part 1

    Q&A: BDO’s Coffman on Change Management, Security and DevOps, Part 1

    DevOps’s best asset is swift and valuable change, which also may be its biggest risk factor. DevOps certainly challenges change management and security. We recently discussed these challenges and the solutions with Deena Coffman, managing director at BDO Consulting’s Technology Advisory Services practice. Here is part one of that exchange.

    David Geer: What kinds of challenges does DevOps create for change management? Can you illustrate with an example?

    Coffman: By combining the sysadmin and developer functions, DevOps can lend to “shortcutting” the change management process in the interest of expediency. It may also undercut the value of having a critical eye from both a distinct system administrator and a distinct development reviewer. DevOps is designed to move quickly, and while the pace of change is accelerating, speed is often an ingredient for a security incident. Much like having the same individual who approves invoices also issue a check, DevOps makes for a faster, but not always secure, process.

    When the system of checks and balances can be purposefully circumvented, that privilege tends to be invoked more often than necessary. As a result, developers may bypass change management altogether far too frequently. The collaborative benefits from DevOps integrating typically siloed functions such as QA, software development, security and information technology operations are important, so long as they aren’t offset by compromises in quality and security that result from the reduction in the review and approval process.

    The expedient nature of DevOps can also lead to error, given the absence of human experience involved in the evaluation process. Before DevOps, if a developer needed to change a setting on the web server, they would submit a change request and wait for approval. Under a DevOps structure, though, the developer simply scripts the change and commits it to the repository—automatically kicking off the build process. The process runs unit testing, integration testing, functional testing and regression testing against the new code, and then pushes the new code to the staging environment and finally, to production.

    Geer: What kinds of challenges does DevOps create for security? Can you illustrate with an anecdote?

    Coffman: The biggest security challenge in a DevOps environment is that speed becomes paramount, which reduces critical evaluation on security risks. Developers incentivized to quickly deploy new capabilities are naturally pushed toward productivity and efficiency, which often run counter to security. DevOps can skew that balance so that security is only lightly or sometimes insufficiently considered. Automated testing will test for known exposures, but a trained, experienced human may be able to anticipate a risk before it materializes.

    Geer: How can flaws in change management in DevOps approaches lead to security issues?

    Coffman: Flaws or inefficiencies in the change management process reinforce the views of those who are prone to bypassing what they perceive as tedious process requirements. If a change management process is too burdensome or seen as lacking value, people will avoid it at any opportunity—not just when an exception permits a bypass. Since technology professionals tend to have a bias against waste and inefficiency, introducing a process requirement that consumes time and effort without returning value has a high probability of triggering a wholesale negative reaction.

    Geer: What kinds of things do DevOps shops and teams need to be doing to address change management so that they continue to meet the expectations of the business?

    Coffman: When it comes to ensuring that change management meets business expectations, it really comes down to several key ingredients: flexibility, speed, efficiency and risk management.

    DevOps teams should design and manage the change management system to be efficient, responsive, and flexible enough to accommodate cursory reviews for low risk scenarios and careful, in-depth reviews for other changes. Leadership needs to also set a tone of support for the change control process so it is not dismissed or marginalized. Additionally, engaging outside expertise and/or including additional quality and security measures for higher risk projects are recommended.

    A risk review that identifies projects with security and privacy risk and distinguishing types of changes supports the automation decisions and builds a DevOps program that balances its benefits with risk management.

    Stay tuned for part two.

  • DevOps Storytime: The Line, The Loop and The Cube

    DevOps Storytime: The Line, The Loop and The Cube

    In a time not so long ago, but long enough to be before the mainstreaming of magical ideas such as “configuration as code” or “platform as a service (PaaS),” in a period where the enterprise IT shops were ruled by the one-two punch of Six Sigma and ITIL, there were three magical artifacts sought by the people who spent their working days lubricating the gears of the consulting, development and operations factories throughout the lands of corporatedom.

    The three mystical objects consisted of The Line, The Loop and The Cube. Each were first envisioned as possibilities by “automation zealots” as they roamed the corporate cubicle farms in vain attempts to provide enlightenment to their enterprise brethren. As the quest to drive evermore efficacy out of technology shops of all shapes and sizes has progressed, strategists, designers, architects and developers have been slowly creating these possibilities into being. Much like the legend of the Deathly Hallows, if these once-mythical objects come fully into being, the enterprise that can behold all three of the artifacts can create the nigh invincible product/technology factory as it becomes the master of time.

    Continuous Integration – The Line

    In conceptual land, The Line was just what it sounds like: a singular line, never bending and never deviating from its course. It connected the space from development to production. The idea of The Line has been around a long time—long enough for many shops to now have working implementations running as standard operating procedure. But it wasn’t always this way.

    circlesquareIn reality land, The Line was a patchwork of open-source frameworks, glue code, xml files and a few engineers unlucky enough to be tagged with role of “Build Master.” Woven together by the Build Master, these transformative robots and would take coders’ output, compile it into a workable build that merges all of the developed functionality, run and validate test harnesses against it. Once validated, the newly minted build then would be promoted to the higher-level environment, ultimately moving from dev to test, test to stage and, lastly, from stage to prod.

    The tools to build and manage The Line have been through many iterations since it first came into use and many shops have progressed far enough into the advanced territories of The Line to call themselves masters of the once-mythical Line. The shops exploiting The Line are now so prolific and the tools have advanced enough that it’s no longer an onerous task to get change-resistant enterprises to try it out.

    The Line has transformed from mythical artifact to concrete reality so much so that the believers now outnumber the holdouts. The end result is that shops not embracing the basics of continuous integration risk losing credibility in the eyes of their staff and any potential recruits.

    OODA is a Way of Being – The Loop

    When someone starts talking about “getting the right information to the right person at the right time,” that person is talking in fairly vague terms about the the long sought-after grail of The Loop. The Line is a good start, but the robot watching the line is only as smart as the humans who created and configured it. This is one of the many reasons to chase The Loop.

    What is the use in “shifting left” if you can’t get the alerts and metrics to the people who care? How can the metrics from “shifting left” be acted upon if they can’t be pushed into the view of those who can act upon them? The Loop is the answer, because it is the mechanism to determine many things beyond “the right person.” The Loop knows how to get messages to all interested and responsible parties. The Loop has mechanisms to account for an ever-fluid organizational structure and backup delivery methods for backup delivery methods.

    All enterprises have feedback loops. The key differentiator for moving toward mastery of The Loop is the degree to which you have automated the and abstracted the mechanisms inside the feedback loops.

    Many people and enterprises are resigned to life without The Loop. The signs are easy to see if you know where and how to look. Are mail distribution lists and org charts always a pain in your organization? Are executive-led fire drills the norm when systems are down? Are system alerts dropping on the floor rather than getting to the first responders and application owners?

    If you answered yes to any of the above, your enterprise has not committed to developing and leveraging The Loop. Basic “loop-like” alerting functionality is commonly available from alerting vendors, but true mastery of The Loop cannot be achieved without robust identity management and synchronization technology. Without this critical integration point, alerts and information flow can only be as effective as your manual processes that update the myriad data islands in each and every alerting system within your enterprise.

    When enterprises grow, being able to have the enterprise robot army seamlessly drive information flow without requiring sieve-like manual processes is also the key to tightening the enterprise OODA (observe, orient, decide and act) loop. Done with full mastery, one could imagine the possibility of acquiring the last of the three magical grails and maybe the most sought after: The Cube.

    Perceiving the Matrix – The Cube

    The story of The Cube begins with a question: “What defines the so-called ‘right’ information?” When enterprise technology and design evangelists talk of The Cube they often wax poetic and describe it as all things to all enterprise people at every level within the organization. It provides not only the integrated matrix of the fully faceted enterprise from an organization perspective, but also extends beyond operational information rights into decision rights, affinity groupings and cross-functional teams.

    cubeWe have begun to see promising beginnings of The Cube pop up within medium and large enterprises through popularizing algorithms and outfitting teams with ubiquitous mission control-style dashboards and screens in team areas. But it is only when these dashboards can integrate and harmonize wide varieties of development, operational and business KPI data that we will be able to claim that we have delivered full and timely context (i.e., “the Right Information”) to the staff sailing the enterprise ship.

    The hard part of creating The Cube is not so much the technology required to achieve its development and integration. The really difficult part is coaxing the organizational will to define and maintain the KPI taxonomies for each organizational unit and the integration points between them. Given that a fully mastered Loop doesn’t necessarily understand how KPIs, infrastructure and applications interrelate and affect each other, the Loop will forever be but a required stepping stone to The Cube.

    Will a Unicorn be Required for Unification?

    The current landscape of open-source and vendor tools to wield and tie together these ungainly enterprise models may not, as of yet, be sophisticated enough to both integrate and simplify the provisioning and cultivation of The Lines, The Loops and The Cubes. The sultry, siren-like call of the Unicorns, however, will likely beckon the cloud builders of today and tomorrow to create not just development to deployment pipelines, but also fully integrated feedback loops with intelligent understanding for how the data connects to form perspective.

    It is odd to think about, because with the idealized future state so close to actual possibility, it begs a new set of questions. Hordes of IT professionals around the world have been working to find faster and more fool-proof ways to deliver meaningful perspective into the hands of decision makers and first responders. We are so close now to that mission being accomplished that there are a few instances of the perspective itself not only being generated by “the robot” but also being handed to “the robot” to take the necessary remediation steps.

    The ending we are approaching, much like the beginning, circles around a question: “If we truly automate all the things, will there be any more work to do?”

  • DevOpsQA NJ Meetup – Test Automation Tech Talk

    DevOpsQA NJ Meetup – Test Automation Tech Talk

    DevOpsIMG_9994QA NJ just held our AIMG_9990ugust Meetup on Test Automation Tools and Processes with Polina Rodov and Kamlesh from Medidata, Anil Jaising from JP Morgan Chase and myself, Tanya Kravtsov, from Audible.   The venue, food and refreshments were provided by  Audible at a state-of-the-art, vast office space in
    Jersey City with amazing views of the  NYC skyline.  The main topic of the meetup was Testing and Test Automation tools and processes and how they are used in different companies.


     

    Takeaways from QUEST and StarEast    

    After fun netwIMG_9988orking over pizza, wine and beer, I kicked off with an overview of my takeaways from Quest and StarEast QA Conferences. I gave a brief summary of the session that I presented at the conference titled “The Road to DevOps” followed by highlights from the most memorable sessions on Test Automation, Metrics and Mobile Testing. I focused on the importance of identifying and addressing the bottlenecks in the product delivery cycle which include manual processes such as test data management, environment configuration and test IMG_0001execution.


    WOW (W-What we do O – on time W- with tools) at Medidata

    Next, Polina and Kamlesh from Medidata presented Tools and Frameworks used at Medidata (which provides cutting edge clinical solutions).   The unique presentation style portrayed the overall solution as a cooking pot, with tools presented as ingredients and testing as degustation. Medidata solutions are built on top of Service Oriented Architecture and utilize tools such as Jasmine and Cucumber for automation, Github, TravisCI and HipChat for CI, Medistrana and GoCD for deployment, Mist, JIRA Capture and Bug Magnet for testing, and SumoLogic and NewRelic for monitoring. IMG_0010Polina and Kamlesh also spent some time describing VCR, an alternative way of mocking APIs.   VCR allows to run the tests against prerecorded response, but still faces challenges if cassette files become stale due to backend service changes.   The session was followed by intense Q &A covering Code Coverage tools, PACT and minimizing cycle time.


    Acceptance Test Driven Development

    Our last session of the day was ATDD (Acceptance Test Driven Develoment) with Anil Jaising, Executive Director at JP Morgan Chase. Anil set the background by talking about history of Lean which came from manufacturing, specifically Toyota factory. It isIMG_0004 very important f
    or Testers and to be able to pull the chord whenever they find a critical defect. Anil suggested reading the IEEE paper by Robert Martin and Grigori Melnik, the primary point of which is that we need to start thinking about testing while requirements are still developed and avoid assuming that testing is testing.   He then gave a great definition of ATDD – from user stories to business value, ATDD is a team sport as opposed to test driven development which is more individual.

    At the end of the sessions, we had some great conversations with group members who stayed behind.    Looking forward to our next session. To learn more about exciting opportunities at Audible visit http://about.audible.com/

    IMG_0012

  • How DevOps Can Help Improve Security

    How DevOps Can Help Improve Security

    Automation and standardization along with development-inspired reviews can address the three top risks to IT security.

    The term “DevOps” these days tends to evoke images of automation and push-button application deployments whenever app dev wants. It’s anarchy, it’s chaos, and it’s a frightening notion to those for whom stability and security of the core business network is their top priority. After all, folks in the DevOps camp routinely cheer on a “Chaos Monkey,” whose sole purpose is to break things in the production network. On the surface, that hardly seems conducive to stability or security.

    So, it might be surprising to discover that the seemingly laissez faire approach to building and delivering apps with DevOps is actually one of the best ways to combat significant risks to IT security.

    Not kidding.

    top 3 risks it security spiceworks surveyFirst, let’s consider the survey, conducted by SpiceWorks, in which IT pros were asked to rank a set of threats in order of risk to IT security.

    According to the report, the respondents ranked the following threats as their organization’s biggest three risks to IT security as human error, lack of process and external threats.

    All three of which DevOps can positively impact, without negatively impacting stability or reliability of the core, business network. Let’s examine how, shall we?

    Human Error

    We’ve all fat-fingered configurations and code before. Usually we catch them, but once in a while they sneak into production and wreak havoc on security. A number of “big names” have been caught in this situation, where a simple typo introduced a security risk. Often these occur because we’re so familiar with what we’re typing that we see what we expect to see, rather than what we actually typed. We’ve entered that command a hundred times, after all; we know what it’s supposed to look like and we aren’t as careful as we (likely) should be because it’s Friday and it’s almost 5 o’clock. Whatever the reason, we’ve done it, and it’s the repetitious nature of the beast that actually ends up biting us in the proverbial derriere.

    Codifying those commands into scripts or, even better, into templates means once it’s right, it’s right. The inescapable reality that we will fat-finger something eventually is reduced to virtually nil because we aren’t typing it in over and over and over, each time with less and less attention. The reliance on codification, on templates and APIs and scripts as a means to automate tasks, is not just about speed but also repeatability. And accurate repeatability at that. That’s the kind of assurance you need to prevent “human error” from exposing apps—and the business—to a wide range of risks.

    To reduce risk from human error via DevOps you can:

    1. Use templates to standardize common service configurations;
    2. Automate common tasks to avoid simple typographical errors; and
    3. Read twice, execute once.

    Lack of Process

    This is probably my favorite risk (and not just because it lets me talk up Six Sigma and some really hairy mathematical equations) because it encompasses such a broad category of problems. First, there’s the fact that there’s almost no review of the scripts that folks already use to configure, change, shut down and start up services across the production network. Don’t let anyone tell you they don’t use scripts to eliminate the yak shaving that exists in networking and infrastructure, too. They do. But they aren’t necessarily reviewed, they are certainly aren’t versioned like the code artifacts they are, and they rarely are reused. Everyone has their “own” favorite language and scripts, and they are the Frank Sinatra of IT: They do it their own way. (Yes, I know you’re probably too young to get that reference, but until your musical icons have a better one, that’s the one I’m using because my generation didn’t have a better one, either.)

    The other problem is simply there’s no governed process. It’s tribal knowledge. Bob does X and then Alice pushes Y and someone from Team Rocket* pushes button to make it go live. What can happen—and sometimes does—is one step is simply overlooked. It isn’t that there is no process, it’s that there’s no real standardization and no overarching governing process. There’s no one coordinating between Bob and Alice and Team Rocket to ensure the process goes smoothly. The thing is that the app might go live and actually work in production minus a few services, but if those services are related to security in any way (such as locking down a port), then your lackadaisical approach to the deployment process just put the business at risk.

    To reduce risk from lack of process:

    1. Define the deployment process, clearly. Understand prerequisites and dependencies and eliminate redundancies or unnecessary steps.
    2. Move toward the use of orchestration as the ultimate executor of the deployment process, employing manual steps only when necessary.
    3. Review and manage any scripts used to assist in the process.

    External Threats

    At first glance this one seems to be the least likely candidate for being addressed with DevOps. Given that malware and multi-layered DDoS attacks are the most existential threats to business today, that’s understandable. There are entire classes of vulnerabilities that only can be detected manually, by developers or experts reviewing the code. There’s DevOps in that, but it doesn’t really extend to production, where risks becomes reality when it’s exploited.

    More extensive testing, and development of web app security policies during development that can then be deployed in production is one way that DevOps can reduce risk. Adopting a DevOps approach to developing those policies—and treating them like code, too—provides a faster, likely more thorough policy that does a better job overall of preventing the existential threats from being all-too-real nightmares.

    To reduce the risk of threats becoming reality:

    1. Shift web app security policy development and testing left, into the app dev life cycle.
    2. Treat web app security policies like code. Review and standardize.
    3. Test often, even in production. Automate using technology such as dynamic application security testing (DAST) and when possible, integrate results into dev life cycle for faster remediation that reduces risk earlier.

    There is no technology, methodology or approach to IT security that will completely eliminate risk short of a complete power outage. Given that’s not a viable option, the best approach is one that reduces risk to acceptable levels (where acceptable is defined by your business’s tolerance, regulatory requirements and how much your MBO is based on not being hacked this quarter). DevOps and security are a good fit, as the former can help standardize, codify, automate and expand security practices across production and dev/test.

    So get out there, and put some DevOps in your security. And while you’re at it, put security in your DevOps.

    * Yes, that’s a Pokémon reference. I figured I needed something more modern after tossing Frank Sinatra in there. If you got both, give yourself +5 geek points.

  • Electric Cloud Announces Industry’s First End-to-End DevOps Release Automation Platform with Native, Push-Button Rolling Deployments

    Easy access to rolling and other advanced deployment patterns makes large-scale, mission-critical application releases safe, reliable and repeatable throughout the entire lifecycle

    SAN JOSE, Calif., July 19, 2016 – Electric Cloud (http://electric-cloud.com), the leader in DevOps Release Automation, today announced its latest version of ElectricFlow, now the industry’s first and only end-to-end DevOps platform to provide native, push-button support for advanced deployment strategies (such as Blue/Green, Canary, and Rolling Deployments). This enables IT to frequently and reliably deploy mission-critical applications at scale and avoid service interruptions to their end users.

    “DevOps implementations are highly individual, and what works for one may not work for another, creating disparate DevOps tool portfolios and resulting in a need for greater investment and skills,” wrote David Paul Williams and Thomas E. Murphy in a March 2016 Gartner Research Report*.

    “We appreciate the effort it typically takes for Application Support teams to provide superior quality of service and zero-downtime for their hundreds or millions of demanding end-users,” said Steve Brodie, CEO of Electric Cloud. “This latest version of ElectricFlow fully automates the process of creating and executing advanced deployment strategies, making them error-free, easy to adopt, and simple to use.”

    As a significant upgrade to what is otherwise achieved with cumbersome scripting or complex, ad hoc, and environment-specific workflows, the new Rolling Deployment capability in ElectricFlow provides a robust, model-based approach and intuitive GUI, making it easy to configure and re-use Rolling Deployments across many projects and pipelines in the enterprise.

    Today, Rolling Deployments are mostly confined to Production environments, where the scale (and risk) of application deployment is the largest. By providing Rolling Deployments as an integral capability, ElectricFlow enables teams to “practice” rolling deployments even in lower environments (such as QA, Staging, or Pre-Production), without requiring additional management overhead or investment in specialized resources. The result is faster, more reliable and rehearsed deployments at enterprise scale, with zero-downtime.

    “Our customers expect always-on access to high-quality applications,” said Marc Priolo, Software Configuration Manager at Urban Science, a global high-tech consulting firm. “Being a leader in this competitive market means we need to release feature-rich software updates more often and at less cost. ElectricFlow’s intuitive approach to application and environment management has allowed us to reduce deployment times, costs and increase visibility across many client environments. Extending this approach to include advanced deployment strategies will help us not only release faster and safer, but allow us to do so with zero-downtime and less risk to our clients.”

    In addition to the breakthrough push-button Rolling Deployments capability, the new version of ElectricFlow includes a number of other new features, such as:

    • Environment Reservation and Calendaring – increases visibility and reduces the chance for cross-team conflict during deployments through a new rich calendar view. This allows users to reserve environments for applications, pipelines and releases; define black-out/maintenance windows; and, offer policy-driven prioritization and conflict handling.
    • Automated Environment Discovery – reduces onboarding time and effort while eliminating errors. A “one-click” automated process accelerates modeling; automatically populates resource and environment parameters; and, offers a new extensible plug-in architecture.
    • Full-stack Dependency View – provides IT-Ops and App Support teams a way to model and visualize dependencies among applications, middleware and infrastructure. Users can define middleware and their infrastructure requirements per application; capture and report on infrastructure/middleware capabilities across environments; and, ensure dependencies are met.
    • Built-in IDE for ElectricFlow DSL with Object Export enhancements – makes it easy to define, debug, version and store your “Process as Code” in any Source Control Management system. The built-in IDE provides an efficient way to modify application models, deployment processes and release pipelines as code and instantly see the changes reflected in the graphical interface.

     

    The new version of ElectricFlow with Rolling Deployments is now available through Invitation Program and will be generally available in August 2016.

    To learn more about ElectricFlow, download the Community edition at http://electric-cloud.com/products/electricflow.

    To learn more about Electric Cloud, please visit: (http://electric-cloud.com).

    Share This: .@electriccloud eliminates failed releases for large-scale deploys w/ industry-first push-button Rolling Deployments http://bit.ly/295WDCt

    *Gartner, Avoid Failure by Developing a Toolchain That Enables DevOps, March 16, 2016.

    About Electric Cloud, Inc.

    Electric Cloud is the leader in DevOps Release Automation. We help organizations developing enterprise web/IT, mobile, and embedded systems deliver better software faster by automating and accelerating build, deployment, and release processes at scale. Leading organizations like Cisco, E*TRADE, Gap, GE, HP, Intel, Lockheed Martin, Sony and Qualcomm use Electric Cloud solutions and services to boost DevOps productivity and Agile throughput, while providing a scalable, auditable, predictable, and high-performance pathway to production.

    #

     

    Contact:

    Jeremy Douglas

    Catapult PR-IR

    303-581-7760

    jdouglas@catapultpr-ir.com

     

     

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

    What ‘Star Wars’ Can Teach Us About DevOps Automation

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

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

    ‘Star Wars’ and DevOps Automation

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

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

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

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

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

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

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

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

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

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

    About the Author / Hans Ashlock

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

     

  • On Building Self-Driving IT

    On Building Self-Driving IT

    More CIOs than ever are moving their data centers to the cloud. Some have decided to maintain their on-premises data centers and move cloud-first with all new deployments, while others are moving more aggressively to all-cloud and are retiring on-premises hardware and software as quickly as possible. Both types of enterprises also are working to automate as much as they can to not only cut costs, but also improve their user satisfaction and the productivity of their organization though higher efficiencies.

    Aater Sulemen, co-founder and CEO of Flux7, a DevOps and cloud consulting firm, is an expert in hardware architecture and performance optimization, and has spent more than 10 years working with cloud. He calls that hyper-automation “self-driving IT.” This push-button IT works much the same way many expect self-driving cars to work in the not-so-distant future: Push a button, summon a car, instruct it where you want to go and it takes you there.

    In this view, when business users wants an app, a database or even more infrastructure, they reach out and request it. They fill out a form, the system determines the proper security and governance policies that should control such systems and data, they push a button, and it’s delivered.

    And rather than IT enforcing these rules manually, developers build the right tools to enable this, enabling developers to be autonomous. As the theory goes, technology gets deployed much more quickly, and when the systems are built properly, compliance and security are improved.

    devopsy.kinsta.cloud: What does “self-driving IT” mean to you?

    Suleman: It’s about achieving successful DevOps through automation. It’s not about dictating rules, or what should be done, but making the processes associated with DevOps seamless.

    Self-driving IT means that the business does not wait for developers or operations to get things done, and they don’t wait for each other. If someone needs something, from an application, to expanded infrastructure, to test and development environments, they should be able to push a button and get it done.

    Self-Driving IT is a way of automating the repetitive events and all of the process overhead and the auditing and logging systems, when someone needs a new application or service they can just get it, and it’s ready. They don’t need to wait weeks, or longer, to provision the apps, storage, servers that they need. Just like a self-driving taxi, they call it and use it.

    devopsy.kinsta.cloud: What are some of the challenges that organizations face when moving to “self-driving IT?” themselves?

    Suleman: There are known hiccups, and there are areas companies know how to smooth very well. Typically, the hiccups within enterprises are in terms of skills necessary to essentially provision infrastructure and make infrastructure provisioning very automated. Then there are the skills needed to create the tests that need to be created, and the automation that can be done around that. We don’t see such a fundamental issue there. Usually the issue that people have is a skill-set issue—They don’t have the skills or the right mindset and place for building self-driving IT themselves.

    I think, generally, most organizations run into trouble when they have to make major changes to the infrastructure and how they will support that. There are a lot of changes that need to be made, and they may not be ready.

    In most cases, if you’re making such a major change that there is going to be a brand new infrastructure designed and built, organizations are going to need some guidance and support through that.

    Another aspect here is that the infrastructure isn’t always the highest priority. So the focus isn’t always there to automate it. But when you need a database, you need a database. There’s no getting around it. So it’s a higher priority and it actually gets done, and the underlying change to the infrastructure that needs to get done to automate doesn’t get done.

    devopsy.kinsta.cloud: Where do you see this heading in a year to 18 months? Do you see more companies moving down the path to self-driving IT?

    Suleman: That is a very interesting question. We have been having a lot of discussion around this very subject lately. There are actually two kinds of customer perspectives. There’s the, what I call, IT view of automation. So IT cares about, “I can create a server with one click, backups happen automatically and I don’t care what’s run inside the server, because to me, these are just boxes. I have 80 boxes on-premises and now I have 80 boxes in the cloud. And this is self-driven IT because I can press a button and spin up a new server.” That’s a fair definition from an IT perspective.

    This is where the continuous integration/continuous delivery and (CI/CD) becomes interesting. When you wear your DevOps hat is when you see that there’s a whole new world inside those boxes. Well, what IT likes to think as boxes. And self-driving IT now has a whole new meaning: code deploy, configuration management, patch management … the stuff that is inside the virtual machines becomes very different.

    A new class of customers has started emerging. This is as recent as early this year. They used to think of virtual machines as boxes. “I don’t know and don’t care what’s in there. What I care about is I have a box in the cloud,” they’d think. And now they have evolved to just wanting to move huge segments of their enterprise to cloud.

    We’re actually working with a lot of this right now. It’s not DevOps, because it’s automated Ops. This is a new level of discussion; this isn’t an app team moving to the cloud or modernizing. It’s CIOs calling and saying that they don’t want to build another data center, that they want 5,000 virtual machines migrated.

    devopsy.kinsta.cloud: That’s fascinating. This sounds like it’s the natural evolution of cloud and DevOps?

    Suleman: Exactly. To us, self-driving IT has been synonymous like cloud, just like DevOps is. In fact, cloud has always been means to achieve DevOps, and CI/CD and configuration management follows. Now it’s a different mindset. They’re looking for a way to not deal with the servers. So, now what is happening is, when it’s time for a refresh, they are either going to call a hardware provider and ask for 5,000 boxes, or they’re going to decide to move to the cloud. And if they have a tight deadline, like under a year or six months, they don’t have enough time to “DevOpsify” 500 applications. They end up wanting a one-to-one migration, so that they don’t have to invest in a new data center or upgrade their current data center.

    It’s a very interesting conversation, and it’s front and center with a lot of enterprises now.

  • Give Test Automation the Respect It Deserves

    Give Test Automation the Respect It Deserves

    One of the key mantras of DevOps is “continuous.” Effective DevOps relies on automating routine tasks. Any step in the process that requires human intervention or manual input becomes a roadblock that can slow or halt productivity. To the extent that it’s possible, anything and everything should be automated—and that includes testing.

    Test is like the Rodney Dangerfield of DevOps—it gets no respect. It should, though. Test—and test automation—is a crucial element of a successful DevOps program. A recent Gartner survey found that 50 percent of respondents listed test automation as one of the top enablers of DevOps success.

    Joan Wrabetz, CTO of Quali, is focused on automating test capabilities and ensuring that testing gets the respect it deserves in DevOps. DevOps isn’t really a process with a beginning and end. It’s a continuum—a self-perpetuating cycle. When test teams take the lead, they need to find ways to push automation back into development and forward into staging and production. “In fact, the problem of test automation is particularly difficult, and this means that the team that implements test automation is in a great position to lead DevOps initiatives beyond test,” Wrabetz says.

    That self-perpetuating cycle “starts” with planning and development and “ends” with deployment into operations, but that flows right into monitoring and management, which leads to discovering issues and identifying new feature requests—and that takes you right back to planning and development. If done properly, test falls somewhere in the middle of that cycle, so it’s imperative to streamline and automate that functionality as well.

    “Sometimes test drives DevOps. Test organizations have been focused on automation already for 10 years, so often they are the driver for DevOps,” explains Wrabetz. “When test is the focus of DevOps, it is called continuous integration. However, it is also important to work to continuously expand automation outside of test.”

    Key Drivers

    According to Quali, there are five key components that are essential to successful automation in a DevOps environment:

    1. The infrastructure. It starts with one very important characteristic that is critical to testing and often is not automated—the ability to automatically mimic the production infrastructure in which the software (or hardware) being tested is expected to run. Having the ability to give each tester (or set of automated tests) their own personal replica of the target production infrastructure—a.k.a. a “sandbox”—is critical to ensuring that the software coming out of test can be deployed automatically and continuously into production. Automating tests is not nearly as difficult as automating the underlying infrastructure in which those tests run.
    2. The production environment workload. Often not considered in automating testing is the requirement to mimic the workloads that would be common in production. This includes the network traffic, other application workloads and network security profiles. These activities need to be automated within the sandbox to create a more realistic environment for testing.

    3. The Tests themselves. Of course, the tests themselves also need to be automated and there are a variety of tools to assist in this process. As software gets more complex, this continues to be a challenge, with mobile testing replacing GUI testing as the most challenging type of testing to automate.

    4. Reporting and result analysis. To provide continuous automation from development through testing to delivery, it is important to see and analyze test results automatically.

    5. Tool Integration. Automation into and out of testing needs to be enabled. This means sandboxes and test automation suites need to be API-driven so that they can be started by a previous tool in the DevOps tool chain and can also initiate a tool that follows testing in the tool chain.

    Show Some Respect

    Testing is a crucial part of the DevOps continuum. It needs to be done properly and effectively, but it also needs to be a streamlined process that drives DevOps forward rather than a hurdle that slows everything down.

  • State of DevOps Report: Reaping Results

    State of DevOps Report: Reaping Results

    The newly released 2016 State of DevOps Report concludes that DevOps is “no longer a mere fad or buzzword,” but rather an established set of practices and cultural patterns. Yet, a closer look at this year’s findings reveals progress is far more substantial than any matters of perception.

    The report was conducted and analyzed by the experts of DevOps Research and Assessment (DORA) and sponsored by CA Technologies. Among its findings is proof that high-performing organizations that have embraced agile and DevOps methodologies deeply are outperforming massively those that have not. And the gap is widening.

    The State of DevOps Report also shows leading DevOps practitioners are appreciating benefits that span nearly every area of their business. If I know my colleague Gene Kim, he will assert this point exuberantly on our upcoming State of DevOps Report Webcast.

    It’s noteworthy that high performers are surpassing incredible milestones related to core elements of the applications life cycle. Examples include deploying code 200 times more frequently than low performers, driving 2,555 times faster lead times, 24 times faster recovery times and producing three times lower change failure rates. This is evidence that DevOps is having the desired outcome on applications delivery, software quality and organizational velocity. It also shows organizations truly committed to wholesale transformation of culture and process are actively succeeding.

    At the same time, the State of DevOps Report shows employees working at organizations enjoying this success are more satisfied with their jobs and more closely engaged with their companies. Chalk this up to the halo effect of operating in a fundamentally more sensible, innovative fashion. Cultural change is undoubtedly the greatest hurdle to DevOps advancement. Here’s proof that if you can navigate the process, your workers will be happier and more productive.

    Using Employee Net Promoter Score (eNPS) as a barometer, the report finds that employees in high-performing organizations were 2.2 times more likely to recommend their organization as a great place to work. They also were 1.8 times more likely to recommend their team as a great working environment. Previous studies have found that such an air of positivity can be directly correlated with improved business outcomes, researchers noted.

    Shifting the manner in which you build applications to better adapt to changing customer expectations is a necessity. That’s what began driving this movement years ago. That said, proof it also makes it easier to keep valued software engineering and IT operations employees should not be overlooked.

    In addition to positive conclusions on the impact of continuous delivery and improvement of test data management, the report offers some important metrics related to return on investment. This is nothing short of landmark, as for decades we have struggled to make a hard case for IT investment beyond implied competitive advantage. It actually was impressive that last year’s report highlighted such a “predictive relationship between IT performance and organizational performance.”

    One such new measurement of note is that high-performing teams occupy the least amount of time responding to unplanned work and rework—efforts widely recognized to be results of flawed processes. On a related note, DevOps leaders spend 49 percent of their time on new work‚ surely, in many cases, the next “must-have” feature which impacts competitive standing and, ultimately, the bottom line.

    This report is fantastic. It reaffirms powerfully that so many of the promises made about DevOps over the last few years are neither hype, nor overstated. The gap between the leaders and laggards is growing. Industry landscapes and business models are being redefined.

    This is critical transformational work that every organization must adopt to survive.

    Are you on board? Download the full State of DevOps Report here.