devopsy.kinsta.cloud

Tag: devops

Top 5 Reasons to Back Up Your OpenStack Environment
I am a big fan of lists. If you recall the movie “High Fidelity,” John Cusack’s character Rob and his co-workers—armed with an encyclopedic knowledge of all things musical—compile “top five” lists for every conceivable occasion, openly mock the tastes of people, and, every so often, sell a few records. In the spirit of a lists, here are the top five reasons to back up your OpenStack environment. We thought that it would be helpful to many.

If you’re currently working with OpenStack clouds, or are in the process of embracing it, you need to include backup and recovery for OpenStack on your list of to-dos from the start. You may ask, “Why? I have orchestrated/automated everything, I just need to spin resources up and down.” Cloud environments are fundamentally different from the virtualization we have become used to. Virtualization relies on infrastructure for resiliency. In the cloud, distributed applications are responsible for their own resiliency, and are independent of the underlying infrastructure. Therefore, cloud apps need backup and recovery options, lest you face a complete machine, data or file meltdown.

We’ve compiled the top five reasons to backup your OpenStack environment. Take a read and it will become clear why you must include backup in your OpenStack plans.
1. Compliance — Compliance may seem like an issue for only certain industries—finance and health care come to mind—but nearly every organization has to deal with compliance issues. For some, it’s compliance to external regulations, while for others it’s simply complying with internal policies and best practices. Backup for OpenStack is an essential component for compliance; it ensures the availability of the data at a specific point in time within your OpenStack applications. I was recently involved in a dialogue/string on LinkedIn watching experienced OpenStackers go back and forth debating “pet vs. cattle.” “I am getting tired of it,” one person said. “This is cloud. It’s about scaling up and out … With automation and orchestration there is no need for cattle.” This conversation went on for days. Theory is great. Practice is reality. What people failed to discuss is that compliance or the business units will drive many requirements (such as backup) either today or tomorrow. End of story.
2. DevOps — Backup is often the forgotten tool for DevOps. Containers are great to use, but the ability to test with real data is an issue. The reason to use backup is quite simple: test and development. With a copy of a production environment, you now can test upgrades and new features in your agile development process. Furthermore, if you lose a machine or your data, or you end up with corrupted files while in the middle of testing or development, your life will be much easier if you have an appropriate backup solution in place. Restoring machines, data and files is a better option than re-creating them entirely. Cookbooks and recipes are great as well, but you still need to couple it with the appropriate “ingredients.” It is like playing with a fake kitchen as a child … do you want to make breakfast with plastic pancakes and toast? Nothing beats the real thing. Yes, more resources are required for one over the other, but when something goes wrong—it is unfortunate—people point fingers.
3. Disaster recovery plans — While the terms “backup” and “disaster recovery” often are used interchangeably, they are actually not the same thing. You might have what appears to be a great recovery environment (ideally one that mirrors your production environment for high availability), but without a comprehensive backup solution, your recovery might not be the painless experience you expect it to be. Perhaps the solution for intelligent disaster recovery is to marry backup with a Swift environment so you can recover from any point in time, anywhere in your organization.
4. Save time — Often recovery can be a frantic process, driven by a business need to have the machine, data or files recovered as soon as possible. Or, more likely, sooner than possible. If you are trying to re-create something under that type of environment, there’s a likelihood that mistakes could be made. This becomes increasingly true the more complex and mature your cloud becomes (think about the growing number of workloads and applications). A much easier approach—one that provides you with peace of mind—is to have a comprehensive backup solution ready and available for when you need it. There’s also another reason backup can save you time: When you have to re-create the lost information, you are taking your time away from something else—and that means you are taking a big hit to your productivity. Save yourself and your organization a big headache with backup.
5. Security and forensics — You never know when you are going to be asked to provide data or files related to a security issue or a forensics investigation. The right backup solution not only makes it easier to assist with the activity, but think how good you’ll look by being able to deliver the information the forensics team needs quickly.
Are you currently looking into backup solutions for OpenStack? Now that you know why you need backup for OpenStack, learn more about how to backup OpenStack.
March 10, 2016
Threat Stack Cloud Security and Monitoring Now Integrates With Slack For Real-Time Response to Security Threats
New Integration Provides Security Alerting and Immediate Collaboration for Security and DevOps Teams

BOSTON– March 9, 2016 – Threat Stack, a leader in cloud security management and compliance, today announced its integration with team communication platform Slack. The Slack integration with Threat Stack’s Cloud Security Platform™ alerts channel members to security concerns and enables instant workflows for cloud-based security operations center (SOC) teams. The Threat Stack Slack integration improves the speed at which team members can respond to and communicate about real threats the instant they happen.

“Threat Stack’s integration with Slack alerts our entire DevOps team to security concerns and alerts in real-time,” said John de Freitas, principal software engineer, OnShape.”Threat Stack helps us to collaboratively detect potential security issues, and Slack allows us to communicate and address them immediately.”

“Today’s fast growing businesses leveraging modern infrastructure for scale need to incorporate security into day-to-day workflow tools,” said Pete Cheslock, senior director of operations and support, Threat Stack. “Integrating Threat Stack security alerts into Slack allows for context and conversation around important events, providing valuable insight into activities happening across your infrastructure.”

Threat Stack’s Slack integration automates SOC team’s processes, delivering only the most important security alerts directly into a designated Slack channel. After all alerts are thoroughly analyzed and baselined within Threat Stack, Severity 1 and 2 alerts are delivered to Slack, including:
- Abnormal user behavior (e.g., insider threats)
- Abnormal process behavior (e.g., new process behavior)
- Abnormal network behavior (e.g., connections to new and bad IPs)
- File tracking and copying of files
- Abnormal infrastructure and CloudTrail activity
The Slack integration works alongside Threat Stack’s audit trail capabilities, and improves SOC teams’ workflows by pinning alerts, dismissing alerts and identifying new patterns and rules. Additionally, Slack Plus users can easily archive conversations for audit and compliance purposes. By leveraging the benefits of Slack’s real-time communication, users gain deeper context on Threat Stack security alerts and the ability to collaborate pre- and post-alert to determine the best course of action.

To learn more about Threat Stack’s Slack integration, please visit our blog.

Availability

Existing customers can get started by simply providing their webhook API and alert severity preferences in the Threat Stack dashboard. New customers can get started here: http://get.threatstack.com/threat-stack-free-trial

About Threat Stack

Threat Stack enables growth-driven companies to scale with confidence by identifying and verifying insider threats, external attacks and data loss in real-time. The only fully integrated, cloud-native continuous monitoring solution that gives companies instant visibility and automatically responds to changes in their environment, Threat Stack provides the coverage needed to run secure and compliant, in all environments, without sacrificing speed and efficiency. For more information, or to start a free trial, visit threatstack.com.
March 9, 2016
Embracing DevOps in the IoT Era
To those of us struggling to cope with the challenges of delivering software over the Internet of Things (IoT), DevOps can be the savior.

Delivering software over the Internet is no easy task, and delivering it over the Internet of Things is even more formidable. How do you deliver software to so many “things,” many of which are “loners” unconnected to the rest of the world?

What’s encouraging is that the software management processes and tools that we know and have learned to love still work in the IoT era. In fact, not only do they work, they are essential.

We need teams to work together more smoothly and communicate more quickly to mitigate the higher technological risks. DevOps processes and tools, therefore, are critical in the IoT era because they facilitate smooth, well-oiled collaboration between teams.

A Typical IoT Scenario

Consider a scenario in which you need to develop a “smart” parking system for a “smart” city. The system will involve multiple sensors in the parking lots, a display device in each parking area along with communication equipment, a central server for control and analysis and a smart device in each car.

Drivers can check how many slots are available in nearby parking lots on their automobile devices and navigate to the appropriate parking lot. They also can book slots in advance and start paying from the time they book the slot. When they leave a slot, the parking slot sensor automatically detects that the slot is free and updates a central server. The central server transmits slot availability to the car-based devices, where they become visible to drivers. The central server also generates various kinds of reports and performs various kinds of high-end analysis.

As with any conventional Internet system, there are multiple software components. All of them have their respective delivery (development, testing and deployment) streams. These streams need to work interdependently and collaboratively, and they need centralized configuration management and dashboards.

The Scale and Diversity of IoT

The differences and challenge, however, lie in the sheer scale of deployment, the diversity of deployment environments and the multiple deployment channels. As you can imagine, any large city will have millions of cars, thousands of parking lots and, hence, hundreds of thousands of individual slots. The number of deployment devices easily can run into the millions.

In the interest of preventing monopolies, not all the parking sensors will be from one manufacturer. The same holds for the car-based devices. While certain standards can be enforced, not all manufacturers will adhere to one universal protocol. It will be necessary to allow multiple communication and security protocols on these devices. This multiplicity of protocols can complicate software deployment on the devices.

Other Considerations

What makes the entire deployment process even more complex is the fact that most of the deployment will be done over the air (OTA). Given that OTA deployment is susceptible to radio-frequency interference and other transmission issues, the deployment process must allow for more robustness than conventional wired deployments.

There are even more factors to consider: A city-based system can be extremely dynamic. New cars get registered every day, adding to the traffic. New parking lots may be built every now and then and get integrated into the smart city system. New kinds of chips from new sensor manufacturers could be added, as mentioned earlier, to increase competition. New, more sophisticated car-based devices coming into the market might offer to host the smart parking software. Of course, as in conventional systems, new functionality and patch fixes would be released frequently. Finally, as the system becomes part of city life, its utility as an analytical tool could increase beyond analyzing parking trends to other spheres of activity.

These business and technological factors can exert tremendous evolutionary pressures on the system. A smart system in a smart evolving city must evolve, too. Yet, no change anywhere in the system must be allowed to break the system anywhere else. The chances of this happening are higher in an IoT system because interconnection protocols have not matured enough to become universal and because physical device conditions can never be predicted perfectly. For instance, a single extra field required by the central big data server could place an unsustainable additional burden on the fragile radio-frequency system in the parking lot and bring down the entire data transmission.

How DevOps Can Help

To offset the increase in technological and business risk in the IoT, we need robust processes and tools that mitigate the additional risk by improving communication and collaboration between teams. Tools that have the following features become indispensable:
- A centralized dashboard providing a cross-stream view of the software development;
- The ability to trace linkages between all related software artifacts across streams and lifecycle stages, given the stressful nature of interdependencies between streams; and
- A tool that can detect broken linkages.
The tools also need a well-oiled DevOps management culture that encourages close collaboration and rapid communication between development and operations.

IoT heightens the need for close collaboration between multiple software streams and within streams between development and operations. Adopting a DevOps culture and DevOps enabling tools is the way to offset the risks of software delivery in the Internet of Things.

About the Author / Vidhya V. Kumar

Vidhya is an advisory software engineer at IBM. An evangelist and practitioner of agile methodologies, continuous delivery and documentation, she has about 10 years of experience in the IT industry. She is a subject matter expert in DevOps, application lifecycle management and search methodologies.
March 9, 2016
Taking Stock of DevOps: Where to from Here?

Have you noticed how every technology trend goes through a series of stages on the path to mainstream adoption? First comes doubt and denial, then tacit acceptance and finally acknowledgement that it works fine after all. The DevOps movement is no different.

First came questions about what DevOps actually is and its usefulness in an enterprise context (whatever an enterprise actually means these days), then a trickle of success stories and finally the publication of tangible and quantifiable benefits.

Thankfully, we’ve moved on from the “Is it a bird or is it a plane?” stage. Of course, that doesn’t stop hype, but at least the publication of benefits—such as those recently illustrated in the global study, “Assembling the DevOps jigsaw“—allow us to cut through all the “DevOps solves global warming”-type of nonsense being written.

So with the value jury finally in, the next question we should be asking about DevOps is, Where to from here? Interestingly, the old Wikipedia entry for DevOps provides some guidance, stating that DevOps is:

… a culture, movement or practice that emphasizes the collaboration and communication of both software developers and other information-technology (IT) professionals while automating the process of software delivery and infrastructure changes.

That’s pretty good, because it emphasizes the importance of collaboration across all IT functions (not just Dev and Ops). However, this still doesn’t quite cut it for me. Although lots of cultural and automation heavy lifting has been done to bridge Dev and Ops, more work is needed to understand how aligning other IT functions to DevOps actually benefits the function itself and the business. Also—and perhaps just as important—how aligning other business functions, such as HR and finance, can lead to more success.

DevOps Works Because It’s Good for Business

Business leaders talk in terms such as faster lead times, customer conversions and time-to-value, which (putting cultural discussion aside) is really the essence of DevOps. And because DevOps adoption directly correlates to making a buck, it has a fair chance of garnering attention and investment from the business.

That said then, information security and other professionals would do well to hitch their wagon to DevOps. One of the beauties of the movement is that teams collaborate and provide input much earlier in the development life cycle, with processes then automated to ensure faster release time and quality. By also involving security earlier, businesses could feasibly harden security, balancing all those “rain on your parade” audits and checklists with automated methods that ensure compliant configurations lead to faster deployments.

An interesting but important benefit is how this approach helps align IT security to business outcomes. Rather than proving its worth through a whole raft of technical sounding measures, such as penetration test scores, patched vulnerabilities or security incidents detected, security can report functional value in context of business goals, such as how automated compliance equals faster releases, leading to increased revenue.

Of course, DevOps doesn’t just involve Dev, Ops and security, it also will involve other functions providing valuable input to help increase speed and quality. Think of it like the old “Stone Soup” story but without the trickery—everyone, be they software designers, product managers and enterprise architects, providing advice and expertise earlier in the software life cycle so essential elements of resilience, supportability and scale are baked in right from the get-go.

DevOps Shouldn’t Start and End in IT

The DevOps way suggests that we shouldn’t just restrict ourselves to IT functions—start there, yes, but other facets of the business should also participate. This sounds like common sense, but in reality it’s more critical because the boundaries between business and digital have blurred significantly. Fail to recognize this and we could end up a silo of good intentions: culturally correct but lacking any teeth.

This explains why even the much-maligned HR function has a DevOps role to play. For too long, many HR departments have been fundamentally back-office, dipping their toes in the muddy waters of organizational culture with periodic staff surveys and performance appraisals. But this doesn’t go far enough. Now, HR leaders must step out onto software factory floor and work hand-in-step with other DevOps practitioners to identify all the organizational and psychological barriers that inhibit business growth and the development of talent.

Finance, too, must become aligned to DevOps. This involves moving beyond traditional IT cost-center thinking to developing new fluid funding models needed to stimulate software innovation by agile teams. This means business change agents must join forces with DevOps practitioners to look at better ways to capitalize or expense software development costs or optimally monetize new apps, APIs and information assets. Once again, the earlier this happens in the software life cycle, the better.

From an IT perspective, we’ve come a long way with DevOps in a relatively short amount of time. But this is only the start of the journey. Most businesses haven’t even considered transformation of the whole organization using DevOps principles as a change agent. Those that do most likely will gain first-mover advantage—and that’s a good place to be in an economy increasingly shaped by application software.

March 9, 2016
Murphy’s DevOps: 7 Habits of Rugged DevOps

Attendees of Rugged DevOps Connect at RSA packed Moscone West’s second floor Feb. 29 to immerse themselves in security. Among the presenters of the daylong event was Forrester analyst Amy DeMartine, who provided a tutorial on how security, developers and operations folks can work together better in the new DevOps world.

Through a slide show, DeMartine laid out her Seven Habits of Rugged DevOps, three of which are discussed in this column:

1: Increase Trust and Transparency Between Dev, Sec and Ops

We live in a world where technology’s goal increasingly is to automate everything, with less reliance on humans—at least, that’s what many marketers would have us believe. However, DeMartine emphasized that Security and Risk groups, if they are going to play a key role in DevOps, need to speak to the practice’s true owners—App Dev and Infrastructure and Ops—in a language they can understand. Here, it’s not automation that matters most. It’s communication—among actual human beings—that’s paramount.

She emphasized a real disconnect between these groups, with AppDev being perceived as the department of “Anything Goes,” Infrastructure and Ops thought of as the division of “No,” and Security and Risk seen as the “Persistent Nagging” sector.

Imagine for a minute, a family unit comprised of Mom, Dad and a highly motivated teenager. The teenager is fast, full of energy and always pulling the trigger; Mom is pragmatic, a disciplinarian always having to tug at the teenager’s reins; and Dad is constantly frustrated that no one listens to his determined warnings. The family’s living room is the scene of many “heated” debates, where each side scores its share of wins but there are really no common agreements that satisfy everyone’s needs. When the teenager wins, it’s because Mom simply doesn’t have the energy to resist any further. When Mom wins, the teenager turns on the iTunes, plugs in the headphones, withdraws and possibly even starts searching for a new family. Dad’s victories are often followed by a series of door slams and the silent treatment.

Now imagine if the three sides found a common language? One that not only got each to see the others’ viewpoints but also developed a system where the teenager was set free to operate within defined boundaries, and where he or she even wore enough safety gear to keep risk to a minimum. We’d have a much more harmonious place, one where the teenager continued to grow without risking the family ship.

Interestingly enough, there really isn’t any technology available that addresses this very real human communication challenge. No mater how counter intuitive it may seem, an effective Rugged DevOps environment is highly dependent on human-to-human relations.

3: Discard Detailed Security Road Maps in Favor of Incremental Improvements

The U.S. Office of Personnel Management (OPM), Sony, Hollywood Presbyterian, Anthem—each of these organizations experienced a security breach of massive scale. If these breaches all shared a word in common it would be PANIC—or at least headlines would have us believe this. The OPM breach was the ultimate example, wherein almost as soon as the alarm bell rang the government announced an elaborate plan followed by the big “Sprint.” Although, it might have been wiser just to beef up phishing defenses (smiley face).*

It turns out that a detailed long-term plan may not be the answer to data breaches, ransoms and system shut-downs.

DeMartine said outright that a comprehensive road map for addressing threats should be discarded in favor of a vision for real-time measurement and incremental improvements. Below is the “circle of life in security and DevOps,” as envisioned by DeMartine:

7: Test Preparedness with Security Games

Who doesn’t like competition? Not many. I think security folks and hackers are probably some of the most competitive people around; visit a Black Hat conference and watch as attendees intently capture flags, break out of handcuffs and hack signs.

With that in mind, it makes sense that this is one of the seven habits. There’s little doubt that simulations will do more to prepare people for real-life situations—after all, practice makes perfect.

Communication is a Rugged DevOps Essential Tool

Increasing trust between Dev, Sec and Ops mandates effective and, likely, improved communication. Perhaps one of the biggest takeaways is that, for all the technological bells and whistles the industry throws at combating cybercrime, in the end an age-old skill—communication—is at the foundation of the most-effective security.

*Phishing is assumed the most likely cause of the OPM breach; it is important to disclose that one of my clients, PhishMe, is a phishing defense solutions provider.

March 8, 2016
Avaya Delivers the Next Big Thing for Developing Digital Business Communications and Customer Service Smart Apps
Avaya Breeze Provides a Next-Generation Technology Platform With a Framework, Development Environment, and the Industry’s First eCommerce Delivery Mechanism for Embedding Open, Mobile Digital Communication

ORLANDO, FL – Enterprise Connect 2016 – Booth #1707 — More than two-thirds of IT executives plan to increase spending on mobile, customer-facing and cloud migration applications over the next two years as part of digital transformation initiatives. But first, IT executives must overcome a significant skills gap that will affect their ability to carry out such initiatives at customer speed.

It’s a conundrum Avaya has solved with Avaya Breeze™, an entirely new way to develop business communications applications.

At Enterprise Connect, Avaya will showcase Avaya Breeze, the next generation of the Avaya Engagement Development Platform — the technology platform that profoundly simplifies application development while delivering built-in capabilities for enhanced mobile, customer-facing and hybrid/cloud requirements. Avaya will also unveil the Avaya Snapp Store – the first eCommerce app store for business communications.

Components of the Avaya Breeze technology platform include:
- An open framework that brings the necessary attributes for communication in the digital age: embedded, multi-platform, mobile, fast, low risk, and workflow enabled — a key requirement to automate previously manual processes to improve digital experiences.
- A development platform for rapid creation of new workflow-based applications within a matter of hours or days versus months.
- A delivery mechanism — the Avaya Snapp Store — that allows a single integrated experience via browsers and native smart apps for entirely new customer experiences.
- Open connectors/APIs that enable simple, integration with existing business communications services and access to the billions of devices in the Internet of Things.
The Avaya Snapp Store is a focused, ecommerce-enabled marketplace for Avaya Breeze applications — or Snap-ins — from Avaya and 3^rd party developers. Snap-ins — easily consumable, prebuilt connectors, fit-for-purpose apps and/or developer code — enable companies to quickly build workflows, customer journeys and other unique applications. The Avaya Snapp Store makes it easy to find, access and download Snap-ins by simply using a credit card for purchase. Developers can create Snap-ins and be on-boarded in the store within weeks.

Gary Barnett, SVP and GM, Avaya Engagement Solutions, said:

“Now, Avaya delivers on the promise of open, mobile engagement with a platform that allows companies to easily design and embed applications into workflows via a powerful, simplified, software-defined architecture and infrastructure for communications. This game-changing technology is built for digital business where companies need the flexibility, speed and the freedom to easily create unique value for their customers. Avaya Breeze liberates them from the confines of monolithic, vendor-locked platforms.”

Avaya is issuing a challenge to the industry to creatively address the major challenges facing businesses and consumers today by developing new apps on Avaya Breeze to help resolve them. To date, thousands of developers from global enterprises have participated in Avaya Breeze Bootcamps and webinars, and are using their lab systems and Avaya Collaboratory accounts to design, build and test Avaya Breeze applications. This week, five of the growing list of third party developers will showcase their Avaya Snap-ins in the Avaya booth at Enterprise Connect, including:
- eGain’s Knowledge Snap-In sends a contextual SMS link to customers on IVR so they can easily use web self-service, without losing their place in the phone queue.
- WEBTEXT uses its global network of SMS messaging gateways to seamlessly connect Avaya contact centers to their customers and the carriers.
- Moxtra’s mobile-first business messaging and document sharing service Snap-In enables rich, persistent collaboration across teams, providing continuity as customers increasingly move between devices.
- Verbio’s Voice Authentication Snap-In addresses increasing concerns about security and identity theft by authenticating users in a fluid and unobtrusive way.
- Approved Contact’s Snap-In provides a worker with more control over who can contact them and when, acting as a personal gatekeeper.
Those interested in developing to Avaya Breeze and/or creating Snap-Ins can learn more by going to the Developer portal at:http://bit.ly/20ZwM0T. For a list of Avaya Breeze Bootcamps and hackathons being held globally, visit: https://www.avaya-learning.com/lms/#/training/catalog/edp

QUOTES:
“I sat there, and I’m not an engineer, but I was dragging and dropping, building a whole workflow for a Web calling service, saying, ‘When this happens, play this IVR message.’ I recorded the message myself, put that in there … and in about two minutes we had a Web calling service Snap-In.”

Daniel Bergan, Head of Strategy and Transformation, Westpac

“More than half of the companies are using or planning to use APIs to embed communications capabilities into their apps, while another 25% are looking at using them to build custom apps. Platforms like Avaya Breeze offer organizations the ability to deliver enhanced business value and execute on their digital strategies by integrating communications and collaboration into workflows, business processes and existing applications.”
Irwin Lazar, VP and Service Director, Nemertes Research

Tags: Avaya, customer engagement, applications development, contact center, digital transformation

About Avaya
Avaya is a leading provider of solutions that enable customer and team engagement across multiple channels and devices for better customer experience, increased productivity and enhanced financial performance. Its world-class contact center and unified communications technologies and services are available in a wide variety of flexible on-premises and cloud deployment options that seamlessly integrate with non-Avaya applications. The Avaya Engagement Environment enables third parties to create and customize business applications for competitive advantage. The Avaya fabric-based networking solutions help simplify and accelerate the deployment of business critical applications and services. For more information please visit www.avaya.com.

Certain statements contained in this press release may be forward-looking statements. These statements may be identified by the use of forward-looking terminology such as “anticipate,” “believe,” “continue,” “could,” “estimate,” “expect,” “intend,” “may,” “might,” “plan,” “potential,” “predict,” “should” or “will” or other similar terminology. We have based these forward-looking statements on our current expectations, assumptions, estimates and projections. While we believe these are reasonable, such forward looking statements involve known and unknown risks and uncertainties, many of which are beyond our control. These and other important factors may cause our actual results to differ materially from any future results expressed or implied by these forward-looking statements. For a list and description of such risks and uncertainties, please refer to Avaya’s filings with the SEC that are available at www.sec.gov. Avaya disclaims any intention or obligation to update or revise any forward-looking statements.

All trademarks identified by ®, TM, or SM are registered marks, trademarks, and service marks, respectively, of Avaya Inc. All other trademarks are the property of their respective owners
March 7, 2016
Are databases part of Agile? The new partnership between Redgate and DevOpsGuys points the way

Cambridge UK, 7 March 2016 – DevOpsGuys, the Cardiff-based company that builds, deploys, and manages enterprise-scale web applications for blue-chip companies and the public sector, has become Redgate Software’s first Certified Partner in the UK. The move brings advantages for both businesses, with DevOpsGuys given the support and expertise to enable them to include the database in Agile processes like continuous delivery.

With a growing roster of clients including ASOS, BAE Systems, the Government, and Fitness First, DevOpsGuys is gaining a reputation for delivering practical engineering solutions which revolutionize the way businesses work. Typically called on to improve software delivery processes, speed deployments, and reduce both cost and risk, DevOpsGuys are experts in improving IT performance using DevOps practices.

Redgate, meanwhile, makes the world’s most trusted tools for shipping changes to enterprise databases. The tools are technically challenging to make, but intuitive to use – a philosophy Redgate calls ingeniously simple. As a direct result, the company has more than 650,000 users worldwide and 91% of the Fortune 100 use Redgate software.

DevOpsGuys joins other noted software consultancies like Northwest Cadence in the USA and GDS Business Intelligence in Germany in becoming a Redgate Certified Partner.

Certified Partners are given inside knowledge of Redgate’s products, training in advanced deployments, and expert advice and support so that they can offer a premium service to their own clients. As James Smith, CEO of DevOpsGuys, says: “We’re on the inside track, if you like. We can talk directly to the people creating the software we’re recommending to clients. It’s a big advantage because if we have an issue, we can resolve it with one phone call.”

The relationship works for clients as well. DevOpsGuys were recently shortlisted by private gym chain, Fitness First, to introduce a standardized IT infrastructure to make software delivery faster, reduce errors, and cut costs. As Smith continues: “Our close working relationship with a key vendor like Redgate demonstrated our capability far better than a PowerPoint slide. It was evidence of our commitment to industry-leading standards and helped us win the business.”

Redgate’s Database Lifecycle Management (DLM) products were included in the solution to source control database development and automate database deployments for Fitness First. As a direct result, it is now quick and simple for the gym chain to copy databases into new environments – something that was extremely difficult and time-consuming before.

DevOpsGuys are now organizing a series of training workshops in London UK to teach developers and DBAs best practice for database source control, database continuous integration, and automated database deployment using Redgate tools.

As Smith concludes: “Redgate have a portfolio of world-leading database products that make continuous delivery for the database a reality. The big thing for clients is understanding how they can work alongside tools for application development, and what new Agile processes need to be adopted to make it possible. That’s where we come in.”

As part of Redgate’s ongoing commitment to DLM and continuous delivery for databases, DevOpsGuys will be joined in the future by further Certified Partners in the UK as well as America, Europe, and Australasia.

– ENDS –

Further information from:
Michaela Murray
Regional Partner Manager, Partner Program
Redgate Software
michaela.murray@red-gate.com

About Redgate Software
Redgate Software makes ingeniously simple software used by 650,000 IT professionals who work with SQL Server, .NET, and Oracle. More than 100,000 companies use Redgate products, including 91% of the Fortune 100. Redgate’s philosophy is to design highly usable, reliable tools which elegantly solve the problems that developers and DBAs face every day.

About DevOpsGuys
DevOpsGuys deliver DevOps-as-a-foundation to underpin digital transformation, achieving greater customer enablement and unlocking new revenue streams. Their DevOps Education, Automation, and Transformation solutions make enterprise organizations agile, scalable, and responsive to rapidly changing business requirements.

March 7, 2016
Software Complexity Driving DevOps Automation

The drivers behind increasing software complexity also are the drivers behind expansive DevOps automation. As the saying goes, “Software is eating the world.” DevOps is gobbling up software, too, engulfing it in practices that are necessary to make it thrive under the pressure of the current environment.

That environment and those drivers are of keen interest to many. DevOps authority Andy Vitus, partner at Scale Venture Partners, has identified four drivers in particular that are creating the software complexity pushing DevOps automation.

Multiple Distributed Software Locations

According to Vitus, by moving software from one server to multiserver to multiple data center deployments, the industry has made software more elaborate. Applications now execute in a distributed manner and in parallel using multithreading inside multiple processor cores; among many servers running multicore processors; and in and between geographically dispersed data centers. This makes software more powerful and reliable, though it demands more DevOps automation to produce it.

Simply incorporating the ability for software to run in parallel using multithreading adds intricacies to the development process. To keep both the workload and the number of man hours needed during development manageable, automate as much of the additional coding duties and testing as possible.

“Running applications across servers and data centers requires that you ensure consistency in the data layer,” which will then need new databases to handle the load, says Vitus. Depending on the database, the developer must rewrite the software to be able to use it.

The entanglements don’t end there.

With mobile applications, mobile devices and back-end servers both store data. “You have to be a lot more careful about knowing what version of the data is the true one, unless you’ve got a synchronization layer built in,” says Vitus. Either way, programming annoyances can be introduced.

Getting Lost in Translation

Expanding development from a single programming language to multiple languages, even for the same project, has made software more convoluted. In legacy development shops, programmers typically used one language for everything regardless of whether it was the best language for their creations. These days teams are applying choice languages such as C++, Python and Go to the tasks to which they are best-suited. “This increases the complexity of security and patch management as you use six, seven or eight different languages all with their own vulnerabilities,” says Vitus.

While adopting several languages certainly adds to patch management and security headaches, understanding how each language can and must be compatible with the others for them to work together is an entirely new challenge. “The ways that they handle variables and time stamps changes over time, and you have to ensure that different services can still talk to each other,” says Vitus.

Stacks of Stacks

Moving from a simple three-tier stack to a distributed microservices architecture catches software development in another snag, Vitus says. The database layer has grown to include in-memory and other database types. As development breaks the application layer into microservices, each potentially with its own data store, the two layers combine to create this new stack.

Millions of Endpoints

Finally, moving from deploying servers to deploying servers, mobile and Internet of Things (IoT) takes software down new paths of mostly uncharted territory, says Vitus. “Today you deploy software changes to a back-end server that must talk to a mobile client using iOS or Android or to IoT devices such as dishwashers and light bulbs in smart homes,” he says. “You could be deploying code to millions of devices.” This certainly affects the construction of the code for use on so many different platforms.

Conclusion

These drivers help create a magnified need for DevOps automation. Considering the costs of hiring engineers and technicians to do the same development work manually, the world will be watching companies that are pushing for increased automation to displace those labor costs. “To the extent that you can offload some of that to regression tests, you end up saving, and the cost of building a new software product goes down,” says Vitus.

March 7, 2016
Appvance Raises $5 Million Led by Javelin Venture Partners

Latest Funding Round Drives Continued Growth in Disruptive DevOps-Ready QA Automation

SAN JOSE, CA–(Marketwired – Mar 2, 2016) – Appvance has closed a $5 million round of venture capital funding led by Javelin Venture Partners to continue its mission to reinvent enterprise software and application testing with the world’s first “DevOps-ready” software quality assurance solution. Appvance’s Unified Test Platform (UTP) helps enterprises improve the quality, performance and security of all their applications as much as 10 times faster and for far less costly than traditional, siloed testing tools.

Appvance provides the first unified enterprise software and application testing platform that answers the needs of both DevOps and quality assurance teams by eliminating redundancies of traditionally siloed approaches to software quality assurance. Appvance’s “write it once” test scripting methodology is designed to seamlessly align with the ways modern applications are developed today — DevOps, agile development processes, continuous integration, frequent releases, rapid test development methods and time-challenged delivery environments.

“As more enterprises adopt rapid development methodologies, QA automation quickly becomes the bottleneck. Everyone knows the legacy tools on the market are not up to the task,” said Appvance CEO Kevin Surace. “Our customers are global 5000 companies that require a complete and robust test automation platform that answers the need for velocity with quality. When enterprises move to agile and DevOps, they need Appvance.”

“We led the investment in Appvance because we recognize the need for DevOps-ready test automation in every enterprise,” said Javelin Managing Director Noah Doyle. “As application development moves to DevOps, agile and continuous delivery, the old siloed tools quickly become a critical bottleneck. Appvance is the only technology we have seen that attacks that problem head-on, delivering speed and productivity improvements, while enhancing quality and security.”

Appvance combines best-of-breed testing modules, including functional, performance, load, app penetration, compatibility, database, DDOS, mobile and more, into a single unified platform that allows test teams to write or record use cases once as well as test apps the way users encounter them, beginning-to-end including UX and API-level tests. This repeatable automation yields real-world results that are superior to protocol-level testing alone.

Appvance will use the funding to expand operations including product development, sales and customer support. In addition to Javelin Venture Partners, the latest round also included H. Barton Investments and Three Bridges Ventures. This is the second round of funding for Appvance, bringing the total amount raised to $7 million.

About Appvance Inc.
Appvance provides the only DevOps-ready unified test automation platform. Built from the ground up with agile and cloud services in mind, Appvance offers true Beginning-to-End data-driven unified functional, performance, compatibility, and synthetic APM testing, enabling users to quickly uncover client-side and server-side issues in a fraction of the time of traditional testing solutions. The Appvance platform drives quality and velocity for DevOps-oriented or traditional development shops, showing 5x to 10x productivity improvements over siloed QA tools. Founded in 2012, Appvance is a venture-backed technology company headquartered in San Jose, CA, with offices in Costa Rica and India and funded by Javelin Ventures, Staenberg Ventures, Social Internet Fund, FundersClub, Three Bridges Ventures and HB Asset Management.

Learn more at http://www.appvance.com. Follow Appvance on Twitter and on Facebook.

About Javelin Venture Partners
With $335 million under management, Javelin Venture Partners is an early stage venture capital firm specializing in technology based start-ups that leverage key innovations to create scalable, high-growth companies. Javelin Venture Partners’ investment professionals are proven new-technology entrepreneurs who focus on identifying exceptional businesses and management teams, and helping them achieve great success. The firm operates with the culture of a start-up and with an emphasis on being a true partner to entrepreneurs. Javelin Ventures Partners is located in San Francisco, CA, but invests in start-ups throughout the world.

March 4, 2016
Building a Foundation for Big Room Planning
When people think of agile, the first thing that comes to mind is a software development team. But agile is much more than that now, as every DevOps practitioner knows. Nearly a decade and a half of practice has shown us that high-performing agile software development teams are critical, but not sufficient on their own. When they operate in a silo, software development teams can easily become disconnected from the business and from other teams. To truly achieve the higher business goals, those development teams need alignment, or else they risk delivering the wrong things or the right things but at the wrong time. That is where Big Room Planning comes in.

Big Room Planning is the secret sauce for effective agile planning and execution because it brings together all the people in an organization responsible for delivering software value to market—from development and test to program management and the business—to plan collaboratively. When I say bring them together, I don’t mean that figuratively: The key is to bring them together quite literally, assembling all of the stakeholders together in the same room in real time. That can feel quite shocking because it represents such a significant commitment by the company, but that is the point. Making agile work requires a commitment across every level of a company.

Before the Big Room

So do you just have everyone roll into a large space somewhere in a hotel’s conference area and hit a home run? Clearly, no. Setting up an effective agile delivery group takes time, and is far more complicated than spinning up agile development teams because of all the roles involved and how each team and individual will approach their part of the work. Most importantly, establishing the leadership changes required to truly change the way an organization works must also take place. Bottom line: Establishing an agile mindset throughout the organization is critical to have a foundation for success.

There are three distinct phases of preparation required when standing up an agile delivery group (Agile Release Train, in SAFe parlance), which we call:
- The Ready phase
- The Sync phase
- Rhe Go phase
Each are vitally important, and without success in the earlier phases, your delivery will get bogged down in the latter stages.

Get Ready

The Ready phase is probably the most critical, and it establishes the right leadership, organizational mindset, and right group of people required for agile value delivery. Three key steps include:
- Enterprise value stream mapping
- Agile organization design
- Leadership development
Without these key steps, supported by leadership at every level, you simply cannot instill the cultural and mindset changes required to stick.

Get Synched

In the Sync phase, agile practices are instilled first. Agile practices specific to each role requires training and coaching to set in, and we advocate for a four-to-12-week period to ensure everyone understands their role, the ceremonies they will use to ensure collaboration and what artifacts they will use to plan and execute their part of the overall work.

Once everyone in the delivery group gets it, it’s time to set up a first Big Room Planning event. This typically takes one month of preparation—without which your event is likely to fail.

Preparing for Big Room Planning should focus on the inputs for the event. First among these is the business vision and context—the domain of executives, line of business leaders, etc. This is essentially the “why” behind what the teams will work on. Key initiatives for the delivery group, with clear outcomes defined (often supported by a lightweight business case), must be communicated effectively to inspire the group. It takes time to put this together.

Next, develop a feature backlog that represents what the delivery group will be planning out during Big Room Planning. Doing this well is a more rigorous process than meets the eye. Features are the crucial ingredient because they represent the value being built to both the business and the customer, and they represent the key deliverables teams will produce.

Product managers typically own this step, and if they are not well-prepared, they run the risk of either asking for too much or asking for the wrong things that won’t have the desired impact on business results. At CA, our product managers go through several iterations of backlog preparation involving stakeholders throughout to company to make sure the priorities are clear.

Even with a well-formed and prioritized backlog, effective Big Room Planning requires an understanding of the capacity of the organization to build what’s needed. This requires good estimation and a good understanding of the each team’s velocity. Estimation and a team’s velocity are big parts of what we learn during the Sync phase: Over a few iterations, the amount of work (a.k.a. story points) a team can deliver outcomes and provides an understanding of roughly the right capacity needed for effective planning. Doing this well ensures teams will be asked to plan not only the right features during Big Room Planning, but the right amount of features so that detailed planning can take place with enough time to design stories, resolve dependencies and address risks that emerge.

Then Go

The Go phase actually kicks off with the Big Room Planning event. The event itself occurs over a two-day period, which marks the starting point for agile execution. If formed well, the right people will be in the room to build value fast. With upfront preparation, the group members will understand what they will be building and why it’s important, and will be set up to create a plan that best delivers the value needed.

Planning collaboratively ensures that the plan is well-designed across the group. Most importantly, because everyone has a part in building the plan—with the opportunity to work together across teams and across roles, with the ability to challenge and even veto decisions as they form—everyone ultimately feels a strong sense of ownership and commitment to the final plan. A successful outcome almost always ensues, and the group only gets better from there are they learn to prepare, plan and execute together as a cohesive “team of teams.”

About the Author/Steve Wolfe

Steve Wolfe is Senior Principal, Product Marketing for CA Agile Solutions. He has worked for more than 20 years on software products in both hardware and software companies. His experience spans 10+ years in both software engineering management and product management, including 7+ years on agile teams and delivery groups. Steve’s passions include helping organizations learn how to build the right things fast and reliably by applying agile and DevOps practices at scale. He is a certified SAFe Program Consultant.
March 4, 2016