Tag: IT infrastructure

  • Red Hat Tightens CloudForms Integration with Ansible

    Red Hat Tightens CloudForms Integration with Ansible

    Red Hat has tightened integration between CloudForms, its tool for managing IT infrastructure on-premises and in the cloud, and the its Ansible framework for automating IT operations.

    Pete Cruz, product marketing manager for management for Red Hat, said version 4.7 of Red Hat CloudForms and Ansible together promise to make it easier to manage multiple IT environments running on-premises and in the cloud using a common set of tools. Most IT organizations today are trying to manage at least one public cloud alongside their existing IT environment. Rather than having to master a separate framework for each IT platform, IT organizations can employ multiple Red Hat tools and frameworks to unify the management of multiple clouds and their internal IT operations, said Cruz.

    Version 4.7 of Red Hat CloudForms now makes it possible to execute Red Hat Ansible Tower workflows directly from CloudForms deployed on-premises. Those workflows can already be extended to include multiple clouds.

    With this release of Red Hat CloudForms, Red Hat is continuing its effort to extend its reach into the management of networks and servers. CloudForms is now integrated with Lenovo Clarity, a set of systems management tools, and Nuage Networks’ Virtualized Services Platform (VSP). Integration with networking platforms is becoming increasingly pivotal because internal IT organizations are now being asked to be as agile as a cloud service provider, said Cruz, noting it’s not especially useful if an IT organization can spin up a virtual machine in a matter of minutes but must wait weeks as network services are provisioned manually.

    Red Hat is trying to lay a foundation on top of which best DevOps practices can be extended across multiple IT environments. With each additional cloud service an organization adds, the less agile the internal IT organization becomes, unless it finds a way to centrally manage all the platforms being employed using a common set of tools, noted Cruz, and the only way to effectively manage IT at that level is to rely on automation frameworks.

    Unfortunately, the number of organizations that are haphazardly embracing multiple clouds seems to outnumber greatly the number of organizations defining a strategy for unifying the management of hybrid clouds. But as the operational costs of managing multiple clouds becomes more apparent, the pressure to unify the management of multiple public clouds and on-premises IT environments inevitably will rise.

    In the meantime, savvy IT leaders are trying to ensure their organizations don’t become overly dependent on any one cloud service provider. The deeper an IT organization dives into the management frameworks provided by cloud service providers, the more difficult it potentially becomes to move an application workload, should the need arise. It does not follow that because a workload was built on one platform it never will move off that platform.

    Naturally, Red Hat, which is scheduled to be acquired by IBM, is not the only vendor with an eye on the rising need to unify the management of hybrid clouds. But the one thing that is certain is that even before the deal closes, Red Hat is aligning its portfolio to specifically address that opportunity.

    — Mike Vizard

  • AWS Finally Embraces On-Premises IT

    AWS Finally Embraces On-Premises IT

    Amazon Web Services (AWS) announced this week it will make available instances of its IT infrastructure available in on-premises IT environments, which it will then manage on behalf of customers. The announcement was made at its AWS re:Invent 2018 conference.

    AWS CEO Andy Jassy said AWS Outposts platforms, scheduled to be available in 2019, will come in two flavors: one will run the same stack of software AWS uses to manage its public cloud, while the other will be based on the software stack VMware currently makes available on the AWS cloud.

    VMware announced it will make available a managed service of its own for AWS Outposts based on its entire platform stack, in addition to making its management and networking software in the form of VMware Cloud Foundation available on instance of AWS EC2. That move represents a significant expansion of the VMware approach to hybrid cloud computing because AWS EC2 is based on the open source Kernel-based virtual machine (KVM) rather than the VMware hypervisor.

    Regardless of path chosen, each Outposts platform will function as an extension of the Amazon Virtual Private Cloud (VPC) service, with connectivity being provided via the closest AWS Region located to that on-premises platform. Both Amazon VPC and AWS Outposts will be tied into the AWS Control Tower service to create a common management plane.

    After years of making the case for moving all workloads into the public cloud, Jassy admitted this week that there are instances when performance and compliance concerns will result in some workloads never moving to the public cloud. In response to demand from customers who want to be able to deploy and manage the same infrastructure on-premises as they have in the cloud, Jassy said AWS is now committing to making racks of systems available via an AWS managed service.

    The challenge DevOps teams will now face is determining the degree to which they will want to integrate their DevOps processes with managed services provided by AWS, VMware or any number of third-party service providers. In some cases, DevOps teams may simply decide that additional layer of management adds to much complexity. In other cases, the decision might lean more toward allocating more resources to application development, as IT operations spanning hybrid clouds become more of an automated service provided by an external vendor.

    Heading into 2019, it appears the specious debate over public clouds versus on-premises IT environments is coming to an end. Not only will there be workloads running in both environments for the foreseeable future, but a recent study conducted by International Data Corp. (IDC) notes that 80 percent of IT organizations surveyed have repatriated workloads back into on-premises IT environments from public clouds. To make matters even more complex, a whole new generation of so-called cloud-native applications based on microservices enabled by containers running on Kubernetes clusters is adding even more complexity to IT environments.

    The goal, of course, is to make modern businesses more agile. The irony is that achieving that goal appears to requires paradoxically making IT environments more complex than ever.

    — Mike Vizard

  • Rackspace Aims to Push VMware Everywhere

    Rackspace Aims to Push VMware Everywhere

    Rackspace is expanding its efforts to provide managed services for private clouds based on VMware that can now be deployed anywhere.

    Peter FitzGibbon, vice president and general manager of VMware at Rackspace, said Rackspace Private Cloud Everywhere, powered by VMware, is making an effort to provide infrastructure services that enable IT organizations to devote more resources to building applications. As part of the effort, Rackspace is making the managed services it provides a natural extension of an organization’s DevOps processes.

    Previously, Rackspace provided support for VMware in data centers it owns. Now Rackspace will manage instances of VMware deployed anywhere, including public clouds such as Amazon Web Services (AWS), FitzGibbon said.

    FitzGibbon noted Rackspace already has more than 70,000 VMware virtual machines under management—a number the company expects to expand significantly as more instances of VMware are deployed on the cloud in addition to on-premises IT environments.

    Longer term, FitzGibbon said IT organizations should also expect to see Rackspace extend the reach of the managed services it provides for VMware to include storage and network virtualization, as well as Pivotal Container Service, an instance of a container platform developed jointly by Pivotal and its sister company VMware.

    FitzGibbon said most organizations are on a multiyear journey when it comes to making the transition to the cloud. Most are still analyzing which classes of workloads make the most sense to deploy on a public cloud. Also slowing that transition are new data sovereignty requirements that force organizations to rethink where data is hosted around the world, he said.

    As they make that transition, many of those organizations are concluding they don’t want to manage the underlying infrastructure that is now distributed across multiple data centers. Instead, they want to reallocate their own limited resources to developing software faster, FitzGibbon said.

    FitzGibbon also noted that taking advantage of advanced cloud capabilities such as cloud bursting or moving workloads back and forth between environments requires a level of expertise many organizations don’t have in place today.

    As more organizations realize they need to become software companies to remain competitive, many are rethinking how IT infrastructure is managed within the context of a integrated DevOps processes. As part of that transition, many are starting to evaluate how much of the management of IT infrastructure they can outsource within the context of those DevOps processes. Rackspace is essentially making the case for retraining the existing IT staff focused on IT infrastructure to focus more on managing applications rather than physical and virtual infrastructure.

    Naturally, that level of cultural IT transformation inside any organization will take time to achieve. Not every organization is comfortable giving up control over its IT infrastructure. Others will prefer to collaboratively manage IT infrastructure with a service provider. Just as significantly, not every member of the IT staff managing infrastructure wants to be retrained.

    Nevertheless, as the sheer volume of IT infrastructure that needs to be managed becomes more distributed, it’s unlikely most IT organizations will be able to manage all those systems on their own.

    — Mike Vizard

  • DevOps and Cloud: A Symbiotic Relationship Aimed at Business Success

    DevOps and Cloud: A Symbiotic Relationship Aimed at Business Success

    DevOps and cloud computing are not mutually exclusive, though their relationship has often been uncertain and confusing from a layman’s perspective. While cloud computing relates to technology and services, DevOps is more about processes and process improvement. However, both DevOps and cloud computing are vital in every organization’s journey toward an effective digital transformation.

    Cloud-centric DevOps Automation

    Cloud computing’s centralized nature enables a standard and centralized platform for DevOps automation. Using a cloud platform resolves issues in centralized software deployment caused by the distributed nature of enterprise systems.

    DevOps objectives including continuous integration (CI) and continuous delivery (CD) are supported by most of the private and public cloud service providers. This ensures centralized governance and control, in addition to reducing the costs associated with DevOps automation on-premises. DevOps utilizes orchestration systems that can proactively monitor the cloud data sets and application workloads. End-to-end automation is a prerequisite for deriving the full advantage from the cloud.

    By expanding the concept of continuous improvement to cloud-based platforms, DevOps ensures lesser system vulnerabilities and greater security.

    DevOps Best Practices for Effective Cloud-Based Computing

    DevOps provides several core capabilities that assist organizations in effectively handling cloud challenges. These include:

    • Infrastructure as Code (IAC): IAC comprises the provisioning of servers and installation of application code, the core components of the system architecture.
    • Automated Application Deployments: DevOps practices facilitate the creation of a fully automated application deployment pipeline that is of great importance in the development life cycle.
    • Application Lifecycle Management (ALM): DevOps principles such as continuous integration and delivery help in effective ALM in the cloud.
    • Continuous Quality Assurance (QA) and Testing: DevOps capabilities address the challenges for QA and testing in the cloud by provisioning multiple test environments using cloud-based resources that result in enhanced quality and productivity.
    • Knowledge-Sharing with the Cloud Provider: DevOps promotes the concept of knowledge sharing between organizations and SMEs of the cloud service providers throughout the application life cycle using online communities that are focused on fostering communication and collaboration, thereby ensuring that most risks are mitigated effectively.

    The Significance of Cloud Computing vis-á-vis DevOps

    Cloud computing complements DevOps in several ways. The application-specific infrastructure in the cloud enables developers to own more components easily and enhance their productivity and efficiency. It allows developers to create the development environments quickly without the need for IT operations to provision resources and infrastructure.

    Cloud computing ensures flexible IT infrastructure in addition to enabling greater business agility. It propels IT transformation by helping organizations in streamlining and embedding DevOps processes.

    DevOps tools and services eliminate human error and help in establishing repeatability by automating and streamlining the process of building and managing code.

    IT Transformation Enabled by DevOps with Cloud Technology

    Cloud computing coupled with DevOps ensures that scalability becomes an integral part of application development, thereby contributing to reduced infrastructure costs and increased global reach.

    Cloud-based operations increase the availability and failover ability of applications in addition to eliminating downtime, which leads to improved business reliability and rise in customer satisfaction.

    DevOps automation and IAC help in reducing the complexity of the cloud and improving system maintenance. Additionally, the automated repeatable processes increase security controls. Process streamlining and faster access to the development environments ensure improved product time to market.

    In Conclusion

    By realizing the importance and prioritizing the usage of DevOps in the cloud, organizations can derive a huge number of potential benefits including enhanced agility and reduced operational costs.

    — Veritis

  • Why an Enterprise 5-Year Cloud Plan Must Focus on Serverless

    Why an Enterprise 5-Year Cloud Plan Must Focus on Serverless

    While most of us have looked at the beginning of the new year as the time to set our personal resolutions for the next 12 months, enterprises have already started to execute their plans for the year ahead. But, that’s part of a problem. Too often major organizations move from year to year on a schedule of 12-month technology plans, never really planning or setting a path for ambitious change that will be realized in years two through five. Thinking in terms of 12-month plans, rather than a desired end state in three or five years, creates a missing-the-forest-for-the-trees effect, where enterprises can end up chasing the technology trend du jour and miss taking advantage of major disruptions to their industry.

    We saw this with the cloud: Many enterprises, still focused on improving virtualization, were surprised by how quickly their developers took to the cloud to develop new applications. These same organizations have factored the cloud into their long-term planning now, but only after many others have reaped the advantages and proven it to be a great way to deliver rapid innovation. And, so far, enterprises look to be on the verge of making a similar mistake with serverless computing.

    Serverless: The Ultimate Abstraction Layer

    Many developers are increasingly looking to serverless computing as a faster way of developing and deploying business IT workloads. It’s not difficult to see why: Developers focus on their application and run it with third-party management; their code is only executed when prompted by predetermined triggers; it scales automatically as needed; and the business is only charged for the time that that code is actually running (as opposed to a flat rate, regardless of whether the code is running). This seems like the kind of intuitive no-brainer that enterprises should be setting a path to now.

    Serverless computing is the natural outcome of the past decade of IT development, where we’ve seen different kinds of layers of abstraction being applied to hardware to create innovative new forms of growth, and do so at scale. Those layers run the gamut of:

    • Virtualization, used to consolidate multiple virtual machines across a single hardware platform;
    • The cloud, used to virtualize compute, networking and storage; and
    • Containers, used to isolate application technology components that can be deployed and operated at scale across multiple substrates.

    Following that evolution, we now have serverless computing, which takes code and functions, and executes in an environment that takes care of all the underlying infrastructure, everything from application services through operating systems, hypervisors and hardware. In other words, the ultimate abstraction layer.

    Embracing Serverless Means Rethinking IT

    Previous abstraction layers, such as the cloud and containerization, broke out as disruptive technologies and caught a lot of enterprises flat-footed—they hadn’t been planned for well enough in advance. Organizations needed to adjust to incorporate them into their IT workloads and business models after the fact to try and give their developers what they wanted and avoid falling behind. Consider the disadvantage that places them at when compared to cloud-first—and, increasingly, cloud-only—organizations.

    Serverless promises to be even more disruptive, in no small part because it isn’t just a new layer to add on top of your hardware, as containers and the cloud were. Incorporating serverless computing into your IT environment requires a complete rethink of how your IT workloads are structured, because the serverless approach works by forcing organizations to focus on business technology as application code and not be distracted by the commodity services needed around it.

    All the more reason why enterprises need to get serious now about making a long-term plan for IT that revolves around serverless computing and outsourcing IT infrastructure. Preparing for a world where the default for new applications is to be developed to run against serverless platforms will take several years. And, in fact, delaying too long will only open you to some of the challenges presented by serverless adoption: application portability, service predictability and overall failure liability.

    Enterprises are understandably wary about outsourcing too much of their IT infrastructure, but the fact is, this is the direction the world is moving in. And besides, serverless isn’t solely a service offered by external cloud providers. There are many serverless platforms, such as Galactic Fog, that can be run atop of fully managed Kubernetes or OpenStack on-premises infrastructure and deliver the same benefits. Companies will only continue to outsource more and more of their IT infrastructure one way or another through 2018, putting us on track for entirely serverless businesses in just five years’ time.

    While everyone is thinking about the year ahead, enterprises need to think about the next five years, whether their IT infrastructure as-is is making a difference to their business and how they can—and need to—restructure accordingly to best leverage serverless computing to their benefit.

    — Mark Baker

  • Top 3 Challenges of Adopting Microservices as Part of Your Cloud Migration

    Top 3 Challenges of Adopting Microservices as Part of Your Cloud Migration

    Many organizations embark on cloud migrations to achieve scalability, cost-efficiency and higher application performance. IDC estimates 60 percent of worldwide enterprises are migrating existing applications to the cloud. With the promise of greater flexibility, a reduction in overhead and the potential for significant cost savings, it’s a logical decision. But instead of performing a “lift and shift”—simply moving an existing application to a cloud platform—many businesses use the migration period as an opportunity to modernize the architecture of their applications.

    What’s more, in a survey by NGINX, over 70 percent of organizations say they’re adopting or exploring microservices for their new architectures—and with good reason. A complex name for what is relatively a simple concept, microservices refers to a concept whereby individual parts of an application are constructed as discrete, modular building blocks. Breaking a monolithic application into manageable microservices allows development teams to rapidly respond to an ever-evolving set of business requirements, choose the right technology stack for each task, and readily provide support for a variety of delivery platforms, including web, mobile, and native apps.

    But with the great benefits that microservices bring, there are also some challenges that enterprises face as they look to adopt new concepts to maintain their competitive edge. In fact, adopting microservices as part of your cloud migration isn’t always easy. Below are three common challenges we’ve seen enterprises face, and solutions to help mitigate these risks.

    Challenge 1: Identifying What Needs to be Migrated to Microservices

    Before you can begin breaking your application out into individual microservices, you first need to understand its full scope and architecture. This can prove challenging, as many times the overarching view of the application is based on “tribal knowledge” or cobbled together from a collection of disparate tools. Sometimes a more holistic view may be available, but is based on outdated information that does not reflect the current architecture of the application.


    Related Content:

    DevOps in the Cloud: Security’s Groundhog Day

    The Challenges of Digital Experience Monitoring


    You need to find a solution that will help you discover and map every component, dependency and third party call of your application. This solution should help you understand the relationship of these pieces and how each impacts your application’s behavior and user experience. Armed with this information, you’ll have a clear picture of what needs to be migrated and will be able to make more-informed decisions regarding the architecture of your microservices.

    Challenge 2: Ensuring Your Microservices Meet or Beat Pre-Migration Performance

    To ensure your application runs smoothly post-migration, and that user experience was not negatively impacted, you need a way to compare performance metrics from pre- and post-migration. This can be extremely difficult, as the architecture of these two environments (with the changes to hardware and the move to a distributed architecture) can look drastically different. To make things even more difficult, the monitoring tools supplied by individual hosting providers give insight into only a small portion of the entire architecture and have no way of creating a more holistic set of data.

    To combat these issues and establish a consistent baseline by which to measure your performance and user experience, you will need to capture key user interactions (often referred to as business transactions), prior to beginning your migration. The business transactions are likely to remain the same through migration whereas other metrics may change as you take different code paths and deploy on different infrastructures. Armed with baseline data about your business transactions, you can easily compare the performance of your pre- and post-migration environments and ensure that there is no impact to your user experience or overall performance.

    Challenge 3: Monitoring Your New Microservices Environment

    With large, monolithic applications running a single codebase on a few pieces of hardware, two or three tools could once provide complete, straightforward monitoring of application and infrastructure performance. However, with the introduction of microservices and the potential for each service to implement its own solution for technology stack, database and hosting provider, a single service may now require a greater number of monitoring tools than the entire application once did. And microservice monitoring brings specific challenges: They are often short-lived, which means monitoring over a longer period of time can be more complicated, and there may be more pathways through which the service is reached, potentially exposing issues such as thread contention.

    Finally, while development teams previously didn’t require a monitoring solution that took infrastructure into account, the move to DevOps and the reliance on cloud-native technologies means this factor can no longer be ignored.

    Changes in consumer behavior and expectations have been the catalysts for large tech trends including cloud computing and mobile device adoption. While the change of pace can be dizzying for many, as the need for speed in application development is greater than ever before, cloud migration is possible. The goal for any business looking to successfully adopt microservices as a part of its cloud migration is to find a unified monitoring platform that supports all of your environments, regardless of language or technology stack. This solution must collate metrics from across your application and infrastructure into a single source of truth and allow for correlation of those metrics to user experience.

    — Matt Chotin

  • Red Hat Survey Sees Broad Adoption of Microservices

    Red Hat Survey Sees Broad Adoption of Microservices

    A new survey from Red Hat shows the extent to which IT organizations are moving to modernize their IT environments: More than two-thirds of respondents (69 percent) reported they are using microservices for both new applications and re-architecting existing ones.

    The survey, which includes responses from 168 IT professionals employing either Red Hat JBoss middleware or Red Hat OpenShift platform-as-a-service (PaaS) software, also confirms that IT organizations are employing a mix of legacy and emerging programming models to build and deploy microservices, says Rich Sharples, director of product management on the middleware team at Red Hat.


    Related content: DevOps Chat: Microservices & Containers – Mastering the Replatforming of the IT Infrastructure


    For example, Sharples notes, many of the microservices being deployed inside the same organization are being built with both traditional Java programming tools as well as so-called new stacks of software based on containers such as Docker. In fact, a full 87 percent of the respondents are either using or considering multiple technologies to build and deploy microservices, and nearly half the respondents (45 percent) said their organization is committed to “using the right tool for the right task” versus forcing the organization to employ a single technology, runtime or framework.

    The top five benefits attributed to microservices are continuous integration/continuous deployment (CI/CD), agility, improved scalability, faster time-to-market, higher developer productivity and easier debugging and maintenance. One-third of respondents (33 percent) said they have achieved two of goals by implementing microservices in the last two to six months.

    However, making the shift is by no means easy. The top four challenges associated with making the transition cited by respondents are developing/implementing in-house microservices tooling, reorganizing their organizations, working with vendor subject matter experts/using a vendor as a trusted advisor and purchasing or using a platform/solution.

    Microservices clearly are not for the faint of IT heart. Developing and managing a handful is relatively trivial. But managing them at scale can prove daunting to even the most skilled IT organization. Sharples says the most important decision an IT organization can make is determining what application workloads to deploy as a microservice. In many cases, IT organizations will be better off rewriting an existing application that they know how to run than trying to create an application from scratch employing microservices—not only to gain experience, but also to be able to compare the results achieved against what was previously delivered as a monolithic application, he says.

    In many ways microservices are the next logical extension of concepts that were pioneered with the advent of service-oriented architectures (SOA) more than two decades ago. The difference now is that microservices tend to be more granular and are often maintained by the developer rather than a centralized IT operations team. Regardless of what level of appreciation an IT organization may have for the history of computer science, the one thing that is clear is microservices are being more broadly adopted than advocates of SOA ever hoped to imagine.

    — Mike Vizard

  • Is Your Company’s IT a Disaster Waiting to Happen?

    Is Your Company’s IT a Disaster Waiting to Happen?

    Recent IT disasters suggest gaps in hardware testing, backup system testing and inadequate disaster recovery plans.

    Although the summer often is the most profitable season for most airlines, this past summer wasn’t great for several of the largest carriers. In July, Southwest Airlines suffered a 12-hour IT outage, triggered by a router malfunction that quickly took down many of its core operating systems like a house of cards. Worse, backup systems failed to deploy. Flight delays and cancellations continued for a few days.

    A similar disaster unfolded at Delta in August, when a power control module at the airline’s central data center malfunctioned, creating a surge to the transformer and loss of power. Delta’s systems didn’t switch over to backups as planned, causing scheduling mayhem as agents couldn’t access key systems. For both companies, the outages resulted in tens of millions of dollars in lost revenues.

    Sure, both of these outages affected businesses running more traditional IT infrastructure, but even if your company is running in the cloud, your business isn’t immune from a damaging outage. In September, Microsoft Azure experienced two outages lasting several hours each, one in Europe and the other affecting U.S. customers across several key services, including SQL Database, Virtual Machines, Service Bus and Visual Studio team services.

    As software developers and testers, we often focus narrowly on the application and the server it is running on—but there’s a lot more to consider. Hardware and components, backup systems and third-party providers all come into play when testing applications for stability and reliability. Of course, there’s no way to prevent all bad things from happening but there are some steps you can take to cover the bases more thoroughly.

    Look Beyond the Software

    If there were three main lessons learned from these recent IT disasters, they would be:

    1. Assess risk of the whole environment. The quality of your software is only as good as the components it runs on—the hardware, network, power, storage, and other third-party applications are often required. Understand the full picture and all of the dependencies. Categorize applications based upon business criticality and failure rate to focus attention on the pieces that really matter.
    1. Backup systems and processes are not “set and forget.” Spend more time documenting them, testing them and training staff. Make sure that the processes are up to date as IT adds new components and vendors to the system or if the company goes through a merger or acquisition.
    1. Invest according to your risk profile. If your company can’t operate for more than a few minutes without access to certain systems, plan on budgeting for warm or hot failover systems which enable near 100 percent uptime with always-on, parallel systems continually synchronized and ready to go. It’s too expensive to enable this failover capability for your entire environment—you will need to be picky. Some IT assets, such as an airline’s scheduling and reservation systems, deserve top priority and resources, while other assets such as the HR system, can do with less. IT directors also need to frequently investigate the need for upgrading old, unstable infrastructure technologies. Most companies also don’t spend enough time monitoring and testing backup and recovery systems.

    To minimize the risk of a major IT outage bringing down your business and alienating customers, the recipe is as follows: Analyze the points of failure, determine what is reparable and what is not easily fixed (for example, installing software usually can be done much more quickly than building a new server environment) and, finally, install and test failover systems and processes that can maintain basic operations with minimal customer disruption.

    Delta & Southwest: A Quick Analysis

    In both cases, Delta and Southwest had backup systems that did not deploy properly—or, at least, in a timely fashion. The first point of action would include conducting thorough, regular testing of those backup systems and locations and upgrading capabilities if necessary. Second, since no disaster recovery system is foolproof, create manual workarounds for critical system outages. That would have helped tremendously so that customers weren’t completely stranded. Third, create a fully redundant second data center that switches over automatically when the primary data center goes down. Naturally, this is the most expensive option, but depending upon the outcome of the risk analysis, it may be worth the money.

    With Southwest, a router failure caused a cascading effect that brought down the network altogether. It’s not clear if a secondary network was available for failover, although it appears the answer is no. Again, better, more frequent monitoring could have isolated the router problem and alerted IT to fix or replace the hardware before disaster struck.

    Any company with technology from many different vendors should work closely with vendors and partners whenever possible to mitigate possible risks. Vendors often are able to provide insight into how they test their own systems and can even share test cases to assist in validating the end-to-end system. Keep in mind that aging technology is not the only problem—sometimes new technology brings untenable risks. A recent example is the Samsung Galaxy Note 7 and its overheating battery problem and recall. As well, it’s smart to understand how the local utility handles its outages and what if any help it provides to customers in the event of service disruption.

    Planning Ahead

    Large companies with complex IT infrastructures should take a holistic view of critical system availability, considering all of the possible ripple effects from a single point of failure. Today’s systems and networks are increasingly interconnected and interdependent. For both airlines, the effect on customers and employees lasted far beyond the actual outage, as managers struggled to get agents and planes reorganized and rescheduled. Take that risk into any spending calculations for the disaster recovery plan. Companies that have gone through mergers and acquisitions have additional complexities from IT integrations—or lack thereof. Failover strategies should ideally be incorporated upfront as part of any acquisition plans.

    Comprehensive testing strategies are paramount, although sometimes overlooked, in preventing outages. Request information from core vendors, such as the networking equipment provider, on testing processes and ask to see their test cases. Though the vendor should be responsible for ensuring thorough testing of their own products, the customer is always the one to suffer the costs of a downed system. Development and testing teams should get clear on how external systems and providers handle down time and equipment failure. Strive to align the company’s disaster recovery processes with those of partners.

    Finally, for companies running mission-critical systems in the cloud, there are ways to mitigate the effects of an outage. Multi-cloud management tools such as CliQr (now owned by Cisco) allow IT to quickly redeploy workloads from one cloud service to another whenever needed. Containers are also helping in this regard due to the inherent portability benefits of the technology. Companies are using containers to move applications and workloads from region to region within one cloud provider; from cloud to cloud, such as from AWS to Azure; and even from the cloud to an on-premise data center.

    There are many causes of IT outages today, and as IT environments become more multifaceted, supporting more technologies, data and applications all the time, those risks grow. We don’t have an answer to the problem, but there is one strategy: leave no stone unturned. Involving testers and developers in outage prevention and disaster recovery planning is a wise move, indeed.

    About the Author / Kevin Dunne

    Kevin Dunne picKevin Dunne is vice president of strategy and business development at QASymphony. Prior to joining QASymphony, Dunne was a business technology analyst at Deloitte. He can be found online at Twitter and LinkedIn.

  • Clone your entire IT infrastructure in the cloud at the push of a button

    Clone your entire IT infrastructure in the cloud at the push of a button

    Rapid development and deployment is a hallmark of DevOps. The faster pace doesn’t change the need for testing applications before they’re pushed to production, or QA testing the code and infrastructure, though. The tricky part for many organizations is that different groups need access to the same environment, and creating duplicate environments can be tedious.

    There are plenty of tools out there that enable an IT admin to quickly create and provision virtual servers. The virtual servers can even be created from base images that include all of the necessary applications and configuration to match the servers in production. That part is fairly simple.

    Where it starts to become challenging is the rest of the infrastructure. The virtual servers might be identical to the production servers, but unless the switches, routers, connections to other servers and applications, IP addresses, and every other aspect of the production infrastructure match identically, the testing or development done in the secondary environment might not be completely valid.

    In 2011, the core team that introduced the KVM hypervisor—now the standard virtualization technology in Linux—founded Ravello Systems to address and solve this challenge. The Ravello Systems team understood that it’s possible to migrate virtual servers to a new environment, but that doing so introduces other issues, and the resulting environment is not an exact duplicate of the original. They set out to find a way for an entire infrastructure to keep up with the pace of agile development.

    Ravello provides organizations with a way to implement repeatable deployments—complete clones—of complex multi-tier production environments at the push of a button. It’s a concept they call nested virtualization. Ravello saves a blueprint of the environment, and enables IT admins to spin up instances of the complete IT infrastructure, including networking and storage configurations, with a single click or API call.

    One organization that has adopted Ravello for managing rapid development is Deutsche Telekom. Deutsche Telekom (DT)—the fourth largest wireless service provider in the world—maintains a cloud telephony service that is a complex multi-tier application with multiple virtual machines, and network appliances from F5 Networks, Brocade, and Palo Alto Networks. DT uses Chef and Jenkins to automate many aspects of continuous integration and continuous development, but it needed a solution to keep up with capacity needs without the expense and effort involved in expanding the physical datacenter environment.

    “Creating a copy of our production-like environment in Ravello was easy. We simply uploaded our base image, and virtual appliance form factors of our physical appliances, and then used the Chef bootstrapping support that Ravello offers to bootstrap into our existing Chef infrastructure,” said Ram Akuka, director of DevOps at Deutsche Telekom HBS in a statement. “What we are building is a truly large scale system with millions of concurrent users and transactions, so by continuously developing with Ravello we can easily scale to meet our customer’s critical business communication needs twenty-four by seven.”

    The first wave of virtualization made server platforms hardware agnostic. A virtual machine of any server operating system could be deployed and run from virtually any x86 hardware through virtualization. Ravello takes that a step farther by taking the entire virtualized environment, and making it cloud agnostic. The Ravello virtualized infrastructure can be deployed on AWS, Azure, or any other cloud platform.

    Ravello also keeps the pricing and invoicing for the service simple. Ravello charges customers on a per application basis rather than per VM. The Ravello pricing also includes the underlying cloud platform. You get one bill from Ravello, and you don’t need to pay the cloud provider separately.

    If you’re struggling to scale the scope and capacity of your infrastructure to keep up with demand, or you’re having challenges with development or testing in environments that aren’t exact clones of the production environment, you should take a closer look at Ravello and see if it will help you resolve those issues.

  • Simplify and expedite server management

    Simplify and expedite server management

    Deploying, managing, and maintaining servers can be tedious. Deploying, managing, and maintaining thousands, or tens of thousands of server instances is overwhelming—bordering on impossible—without the right tools. Thankfully, the right tools exist.

    The Pain of Doing Things the Hard Way

    I know I am dating myself, but when I was an IT admin for a dot.com startup, I had to deploy servers the old-fashioned way. UPS would show up with a box from Dell. I’d unpack it, and mount it on the rack in the datacenter. Then, I’d begin the process of configuring the operating system, and installing the application software. Each server was essentially a full-day project, and we seemed to constantly be adding new servers, so my full-time role was basically “racking and stacking” for a while.

    Adam Jacob was experiencing similar obstacles when he developed Chef. Working as an IT infrastructure consultant, Jacob was frustrated by the configuration tools that were available, and the lack of a simple, repeatable process. Rather than starting from scratch and reinventing the wheel for each client, he developed Chef to enable IT admins to create modular, reusable “recipes” that automate the process.

    Server management doesn’t end with deployment and initial configuration, though. You also have to maintain the servers, and resolve issues that might occur. When an issue arises, it could mean hours of troubleshooting to identify the root cause, and another few hours to work out and implement a resolution.

    I used to get into philosophical debates with management and other IT personnel because it was my opinion that we should just skip the troubleshooting and rebuild the server from scratch. My theory was that it might be nice to know what caused the problem, but from an operational perspective I knew I could rebuild the server and restore normal operations in a couple hours. Troubleshooting, on the other hand, was an unknown—both in terms of whether or not it would even be successful, as well as how long it would take.

    The Beauty of Doing Things the Easy Way

    Tools that automate configuration and deployment of server instances automatically solve both of these problems. They expedite deployment and configuration, and simplify management and maintenance—freeing IT admins and IT personnel to focus on more important, less mundane tasks.

    Tools like Chef help IT manage complexity. It is great from a DevOps, automation perspective to have a tool that enables you to quickly deploy and configure servers, but the real value comes from the ability to maintain a stable, dependable network with minimal effort.

    Chef nodes “phone home” periodically to ensure the configuration matches the recipe it has been assigned from the Chef server. Any deviations are automatically overwritten—so any changes that may have been made locally on the node are erased, and the server remains configured as it should be.

    In order to implement lasting configuration updates, the changes have to be made to the recipe at the Chef server level. The bonus is that once the recipe is updated, all Chef nodes working from that recipe will be automatically updated.

    When an issue occurs on a server instance, it should ostensibly be corrected automatically when the node communicates with the Chef server and overwrites the configuration. However, even if that doesn’t happen for some reason, the use of DevOps tools like Chef still makes the task of troubleshooting and/or resolving server issues much more efficient.

    With the push of a button, you can just deploy a new server—properly configured and ready to go. You could choose to kill the server experiencing issues and just replace it with the new one, or you could launch a new server to take over the roles and responsibilities of the affected server while you take the time to troubleshoot if you really need to understand what the root cause of the problem was.

    Embrace simplicity

    Apparently, I was an IT admin at the wrong time, and I got out of that career path right when things started to get interesting. Necessity being the mother of invention and all that, Adam Jacob created a platform with Chef that reduces the complexity and tedium of deploying and managing servers.

    Chef isn’t alone. Tools like this form the foundation of DevOps because a culture that combines development and operations, and iterates new releases on a rapid scale needs to have this sort of automated IT infrastructure to keep up.