devopsy.kinsta.cloud

Tag: IT operations

  • BMC Pushes Automation to the DevOps Left

    BMC Pushes Automation to the DevOps Left

    Much of the inherent conflict that exists between developers and IT operations teams often comes down to how IT automation processes are implemented. IT operations teams generally have their own preferred tools for automating operations while developers have another. To resolve that issue, BMC Software unveiled Control-M Workbench, a set of development tools that extends an application programming interface (API) to allow developers to embed instructions for automating infrastructure using BMC Control-M automation platform.

    Gur Steif, president for digital automation at BMC Software, says Control-M Workbench moves the responsibility for automating the IT infrastructure resources that their application consumes, including the ability to code, debug and test workflows. The IT operations team can then more easily deploy that application in a production environment, he says.

    In effect, BMC Software is enabling IT organizations to put the control of how jobs are executed in a production environment in the hands of developers by moving that function further to the left of the DevOps life cycle. Control-M Workbench represents the first time BMC is venturing beyond its traditional IT operations base to create a tool that will primarily be employed by developers.

    Steif says the goal is to enable IT operations teams to manage much higher volumes of application rollouts. In return for spending a few minutes on installing Control-M Workbench, IT organizations can deliver application 20 percent faster, while running jobs using 50 percent fewer full-time employees. In addition, Stief says production incidents can be reduced by up to 25 percent and batch processing failure rate can drop by as much as 80 percent.

    Control-M Workbench is clearly part of a trend to give developers more control over and responsibility for IT operations. A recent survey of 650 IT decision makers conducted by BMC finds 94 percent of IT decision makers expect automation to spread into all other areas of business by 2020.

    In addition, the survey notes that 73 percent of IT decision makers believe businesses that do not embrace IT automation to achieve the larger digital business strategy within the next five years will cease to exist in 10 years. The top three areas of investment priority in the next 24 months to achieve those goals are containerization, workload automation/scheduling and DevOps. Almost 9 in 10 (89 percent) respondents concur that IT automation needs to achieve their desired digital business objectives.

    However, there are considerable obstacles that need to be overcome, including lack of budget (67 percent), skills (44 percent) and time (51 perent). In fact, 42 percent of the respondents concede that when it comes to digital business initiatives there are conflicting objectives between business units and CIOs that can get in the way of crafting a comprehensive IT strategy.

    DevOps, of course, is more about people and processes than it is technology. Then again, DevOps isn’t going to be willed into existence without providing the tools needed to change the processes. Given the chicken-and-egg relationship between processes and tools, it becomes incumbent on the IT leadership to serve as the catalyst for bringing it all together.

    — Mike Vizard

  • Node.js Becoming More DevOps-Friendly

    Node.js Becoming More DevOps-Friendly

    Over the last several years use of Node.js has exploded across the enterprise, as developers moved to embrace a variant of Javascript that made it easier to build both client and server-side applications. However, every time it is upgraded, all the dependencies between it and application modules written in C or C++ breaks.

    To solve that problem, the Node.js Foundation is making available on an experimental basis a Node.js API (N-API), developed collaboratively by Google, IBM, Intel, Microsoft, nearFrom, NodeSource and other contributors. The API will be in Node.js 8, and promises to eliminate the need to update all those dependencies. Pending additional testing, it is expected to be given Long Term Support (LTS) status later this year.

    At the same time, The Linux Foundation is adding new features to experimental tracing and async tracking features. A diagnostics API will make it easier to monitor the operation of the Node.js event loop across the complete life cycle of a service request. Finally, an inspector core module, which allows developers to leverage the debug protocol used by the Google Chrome inspector to inspect currently running JavaScript code, is also being added.

    Each of these new capabilities are nice to have on their own. But collectively, they signal the beginning of a maturation process in the Node.js community. Increased use of Javascript in general—and Node.js especially—have arguably caused many enterprise IT organizations re-evaluate their DevOps processes. Developers using Node.js have been able to increase the number of applications they could develop considerably. Since then, the number of languages being employed within the enterprise has exploded.

    Mark Hinkle, executive director of the Node.js Foundation, says moving forward there will be more focus on reducing the friction surrounding upgrades of Node.js applications as part of an effort to further expand the ecosystem. Many organizations commonly end up supporting multiple versions running across a variety of applications. Hinkle says N-API is a step in helping to reduce the maintenance costs associated with supporting those applications. In an ideal world, the foundation would be gathering additional input from DevOps experts pursuant to achieving that goal. In most IT organizations, the care and feeding of Node.js applications is still left in the hands of IT operations teams after the apps are deployed in production.

    In the meantime, Hinkle says its performance continues to improve. Naturally, there’s a corresponding relationship between better performance and the number of use cases for which it will be considered. Of course, that doesn’t mean Java and other legacy programming languages won’t be used to develop new applications. But it does means that in terms of the number of programming languages employed across the enterprise, it’s now a polyglot universe.

    — Mike Vizard

  • Dev & Ops: These Are Reconcilable Differences

    Dev & Ops: These Are Reconcilable Differences

    The new world of IT requires a different approach from what worked in the past. As usual, the technology is the easy part, but without people and processes being aligned, it won’t deliver value. When evaluating how data science and machine learning can help manage highly dynamic IT environments, old reflexes may be actively harmful.

    By their nature and due to their experiences, Ops people tend to be a pretty (small-C) conservative bunch. Rule No. 1 of Ops is “If it ain’t broke, DON’T TOUCH IT!” and if we’re honest with ourselves, most of the rest of the rulebook is just variations and commentaries on that theme.

    One of the ways in which Ops people try to control their world is through automation. DevOps mostly looks to the moment of release and deployment, as that is where the handover to Ops typically occurs—and this is a big focus of the drive to automate. However, there is another part of Ops where automation is key, something that Dev is not always nearly as involved in; namely, day-to-day operations. Which alerts should even be sent, whom they should be routed to, what are the valid responses and so on—all these have been automated over the years, to a greater or lesser extent.

    Ops people have laboriously documented their architecture and spent a long time in meetings planning which information is relevant to share and who should respond to alarms. Much of this is implemented in various pieces of software, whether commercial, open-source, home-grown or that special grey area, where something that started out as a standard component has been so customized that it is effectively bespoke. Rules, filters and thresholds determine what action to take in which case.

    These approaches have been in place for years or even decades, but now they are starting to fail. Simply put, IT’s increased complexity and the ever-accelerating rate of change are outpacing administrators’ ability to keep up and reconfigure their management systems.

    The Coming ‘New Normal’

    New approaches are emerging to deal with the new normal, but as ever, the technology is the easy part. For new technology to be a success, people and processes need to be in sync.

    Right now, the emerging approach is to use data science and machine learning to process events, instead of the old deterministic rulesets and databases. The results speak for themselves, especially at scale and in highly dynamic environments. People building container-based or SDN architectures no longer assume that there will be a database of configurations that will always be up to date; quite the opposite.

    The new way is to throw out all the filters and rules, feed all the alerts into a single place, and then use data science and machine learning techniques to sift them and identify relationships with them. The result will be a shift in focus from individual alerts to the business problems those alerts are the symptoms of.

    Algorithms are great at these sorts of repetitive, high-volume tasks. They can look at massive volumes of events and figure out which are even relevant and worth taking a second look at, and then identify how those events relate to each other and what they really mean. This is where the humans come in, with their strengths in low-volume and unpredictable situations. Because they are not constantly drowning in irrelevant noise, they can work together effectively to understand the actual problem and get it fixed quickly.

    Where’s the Catch?

    The difficulty is that for many Ops people, there is a big cultural change required to adopt this model. The old deterministic systems may have required laborious maintenance, but at least it was possible to model them and understand why a specific result was achieved. New algorithmic techniques take a radically different approach, and while the results are impressive, they come from a black box. This does not inspire confidence for people who are very comfortable with the old approaches.

    Often, the response of Ops people coming from legacy tools is to get stuck into the minutiae of what is going on inside the black box and to look for traditional failure modes. The problem is that these approaches are no longer valid in the new world, as I discussed in my last post about getting to SRE.

    For instance, while it is indeed important to make sure that no issues are missed due to over-aggressive filtering, this does not mean that we need to see every single alert. As long as we know about the actual business problem, we don’t actually care about the single alerts, except insofar as they help us debug the underlying issue and resolve it.

    The other direction is even more insidious, where people spend a lot of time chasing down “extraneous” events that they think they should not be seeing. The risk is, of course, that the Ops team ends right back up in the same place that they were trying to escape, where they are only able to identify expected problems, but are getting blindsided on a regular basis by the “unknown unknowns,” the conditions that simply should not happen.

    Ultimately, Ops needs to let go of reflexes that were good in the old world, and focus on the goal: ensuring the uptime and stability of business-supporting systems. The how is less relevant than the what and the why; the algorithmic black box might as well be full of magic leprechauns, as long as they are telling Ops what they need to know, when they need to know it. Call it the “Chinese Room” theory of Ops: For as long as the results are useful to Ops, it does not matter what is inside the room.

    The benefit for Ops is precisely that they no longer need to focus on the minutiae of individual alerts, but can concentrate on solving actual business problems. That is how IT can make itself a value generator and avoid being viewed as another undifferentiated cost center.

    Pay no attention to the algorithm behind the curtain.

    — Dominic Wellington

  • IBM: DevOps, AI to Drive Digital Business Transformation

    IBM: DevOps, AI to Drive Digital Business Transformation

    Conventional wisdom holds that one of the biggest challenges organizations face today is a chronic shortage of application developers. But as artificial intelligence (AI) advances, the process of writing code will become more automated. But rather than there being not enough developers to write all the code necessary, the shortage will be in software engineers who can develop innovative systems.

    Bob Lord, chief digital officer for the Digital Business Group at IBM, says a glimpse of the future of application development is already being provided today. Instead of writing low-level code, most developers today simply combine modules to create new applications. Anytime new functionality is required, another module gets dropped into the application. The number of developers writing the low-level code needed to create those reusable modules is relatively few, says Lord.

    Over time, however, AI models will learn how to write that code. People will add value by providing the engineering expertise needed to combine modules to create an innovative application, Lord says. Naturally, most of the processes employed to deploy that software also will be automated. But IT operations teams will be needed to continuously train the AI systems being used to deploy that software. This is in much the same way that we need human pilots to fly a plane whenever something new or different occurs, despite the existence of autopilot technology.

    In general, Lord says, IT organizations would be well-advised to focus on three things:

    • They need to decide what architecture strategy is going to be employed to accelerate DevOps integration.
    • They need to develop a data strategy that drives digital business transformation.
    • They need to layer a cognitive computing strategy that employs advanced algorithms to maximize the business value of the data they’ve accumulated.

    While some organizations approach these issues in isolation, Lord says the reality is they’re all closely connected. Organizations are investing in DevOps not just to reduce costs—DevOps is about attaining a level of IT agility capable of driving digital business transformations. In fact, Lord believes the way IT organizations are measured will change: Rather than being rated on traditional IT metrics, they will be measured on how effective they were in attaining business goals—especially when to comes to velocity at which applications are rolled out and updated.

    In the meantime, Lord says, developers are starting to exercise more influence over the technologies organizations are employing to achieve those goals. Because of that issue, IBM is making an effort to get closer to the developer community. But as application development advances, many of those developers will be software engineers rather than people who write code, while IT operations teams will become teachers who train intelligent systems how to respond to the needs of deployed code.

    — Mike Vizard

  • The Time Is Now for an IT Operations Revolution

    The Time Is Now for an IT Operations Revolution

    There’s a level of frustration starting to build inside IT operations teams that’s about to boil over. Lucas Carlson, vice president of strategy for Automic, a unit of CA Technologies that provides an IT automation platform, says developers are bullying IT operations teams by programmatically invoking application programming interfaces (APIs) exposed by public cloud service providers. As the number of application workloads running in those clouds increases, IT operations professionals are losing control.

    To ensure their continued relevance, IT operations teams need to leverage automation to inject levels of agility into local data center environments, he says. That would make it much less likely developers would feel the need to programmatically invoke IT infrastructure resources.

    Carlson says achieving that level of agility will require IT operations teams to rely more on machine- and deep-learning algorithms to automate low-level tasks. Instead of thinking in terms of managing silos of compute, storage and networking resources, Carlson contends IT operations professionals need to reinvent themselves.

    The artificial intelligence (AI) models based on advanced algorithms must be trained continuously. IT operation professionals could become the trainers of those AI models. In fact, Carlson says IT operations teams are approaching a critical moment in history: They can either wait for AI models to eventually replace them or they can leverage them to take back control of IT infrastructure.

    However, developers tend to make decisions based on what they prefer versus what’s best for the organization. Before too long, multiple duplicate operations management frameworks are in place. Rather than incur all those management headaches and associated technical debt, Carlson says organizations need a single framework that can more adroitly accommodate the multiple roles within the DevOps team. It’s already long past the time when IT teams should have modernized their operations, he says.

    The relationship between developers and IT operations teams has always been contentious. The more belligerent members of the developer community are even making a case for “NoOps.” In that context, all the IT dollars spent on operations are moved into developing applications because the management of IT infrastructure is completely automated. Given the amount of legacy infrastructure that isn’t likely changing anytime soon, achieving that level of automation inside the enterprise won’t happen for a while. But there’s no doubt that IT operations needs to get more agile. Because of that issue, investment in software-defined data center (SDDC) technologies is growing rapidly.

    Instead of resisting that trend, Carlson says teams need to demand that internal IT operations be brought into the 21st century. It’s true that SDDCs infused with AI models will automate most of the lower-level tasks associated with DevOps. But those members of that IT operations teams who become the masters of building and training those AI models will be among the most highly sought-after individuals in IT.

    — Mike Vizard

  • VMware CEO Stakes Out DevOps Position

    VMware CEO Stakes Out DevOps Position

    At the Dell EMC World 2017 conference this week, VMware CEO Pat Gelsinger waded into an increasingly heated DevOps debate by suggesting that most developers are too “lazy” to be really interested in IT operations.

    At a time when factions within the DevOps community are making the case for developers to be responsible for DevOps on an end-to-end basis, Gelsinger contends that most developers want to get out of being involved with IT operations as quickly as possible so they can spend more time developing applications.

    The VMware approach to DevOps is closely aligned with Pivotal, a sister company operating under the Dell Technologies umbrella that curates an instance of the platform-as-a-service (PaaS) environment developed by the Cloud Foundry Foundation.

    Gelsinger notes that the two primary reasons developers have shifted workloads to public clouds is perceived costs and the fact that invoking infrastructure as a service (IaaS) via an application programming interface (API) is simpler. To combat both those issues, Dell EMC has been rolling out preintegrated converged and hyperconverged infrastructure that, for certain classes of workloads, is less expensive to own over multiple years. Those systems are optimized to run either VMware or Microsoft virtualization software within a software-defined data center that exposes IT infrastructure resources via APIs. In effect, Dell EMC is applying a cloud operating model on top of IT infrastructure deployed inside the data center to close what Gelsinger describes as an “easy gap” between public clouds and internal IT operations. As those systems are more widely deployed, Dell EMC and VMware jointly contend that IT organizations will be in a better position to inject more agility into their DevOps processes.

    Many IT operations professionals have a vested interest in the outcome of those efforts because developers have been doing an end run around internal IT operations teams by deploying applications directly on to a public cloud. The challenge VMware recognizes, says Gelsinger, is that the entire DevOps space currently is chaotic. Each IT organization not only has a different view concerning to what level of DevOps integration it wants to achieve, but none of them are at the same point in making that DevOps journey. In fact, there’s a raging debate over the merits of PaaS environments versus lighter-weight container-as-a-service (CaaS) environments.

    Dell EMC, in collaboration with VMware and Pivotal, has invested heavily in a Cloud Foundry platform that it makes available as a Pivotal Cloud Foundry (PCF) offering is increasingly automated, from an IT operations perspective. The latest version includes a rolling update capability that requires no human intervention. Pivotal claims one financial services customer has deployed 10,000 application containers on an instance of PCF that is managed by only four IT operations people. Couple that level of automation with the automation that VMware and Dell EMC are driving into the underlying IT infrastructure, and it shows that DevOps will be profoundly different than today. Less clear is who inside the IT organization will be exactly managing what.

    — Mike Vizard

  • Site Reliability Engineering: How to Make the Operations Side of DevOps Actually Work

    Site Reliability Engineering: How to Make the Operations Side of DevOps Actually Work

    The DevOps movement often has been accused of focusing too much on the first half (Development) and not enough on the second half (Operations). Certainly there has been more attention paid to deployment of payloads than to operating running systems, leading to the dismissal of the handover between Dev and Ops as “throwing it over the wall.”.

    Lately, we have seen the emergence of a new focus on the stability and reliability of the systems that are the targets of those deployments, with the creation of the new practice of site reliability engineering (SRE). This has been a welcome addition to the IT toolbox, but it can still seem to put all the onus on Ops teams to catch whatever comes over the wall.

    The Problem with Site Reliability Engineering = IT Infrastructure

    In SRE, the IT infrastructure is expected to be highly automatic and self-healing in the face of any events. Here is the problem: That approach works well for foreseeable events, but less well for the unforeseen ones. Because of that factor, it works well in environments that run few types of individual workload types, but do so at very large scale. If you’re thinking that sounds like Google and Facebook, you’d be right.

    What this amounts to is massive engineering of the infrastructure to withstand known or foreseeable problems. However, typical enterprise IT environments are not like that. A large bank might have thousands of applications, each of which must accommodate changes on a pace that is dictated from outside the IT environment. Applying assumptions from one environment to the other is asking for trouble.

    To illustrate this, let’s look at an example from outside IT. Recently was the anniversary of the sinking of the Titanic, on April 15, 1912. The RMS Titanic itself embodies the principles of SRE, engineered to prevent or survive all manner of emergencies. The ship was equipped with state-of-the-art everything to transport its passengers in comfort and safety across the Atlantic.

    As we all know, that plan did not quite work out. A combination of unexpected changes in the environment (more icebergs than normal), business imperatives to maintain speed and mishandled warnings about the ice from other ships led the Titanic to disaster.

    While the consequences of an IT failure are rarely quite as dramatic as the sinking of an ocean liner, many of the same factors apply. IT administrators may believe that in the worst case their backups and disaster recovery plans will be sufficient to handle any problems, but these plans are designed around known and foreseeable problems. Unexpected circumstances can easily lead to cascading failures, which is why it is critical to be ready for the unexpected when it—inevitably— occurs.

    The Problem with Traditional IT Ops = Static Models

    The key flaw in IT Ops is reliance on static models of the world. These models come in many shapes – the CMDB is the “model” that many think of first, but static rulesets are also a model. The most dangerous models, though, are the ones that are invisible: namely, the filters that are put in place to determine which alerts and events are even worth considering.

    This is the flaw that ultimately sank the Titanic: The crew were unable to correctly priorities events and react to them in time to avoid failure. It is also the flaw that causes countless much more minor issues every day in data centers everywhere: the filesystem that filled up with logs, taking down the database that the critical business application relied on—and the filter that had not forwarded that alert because it usually was harmless. Or the loss of one leg of the redundant network link, which was ignored because the other leg was still up, so there was still a link—until that one failed too, and an entire site went dark.

    The key factor is that the filters were not wrong to suppress those alerts. By definition, informational or warning alerts are not the same as major or critical ones, and most of the time they can be safely ignored, to be dealt with later.

    Every now and then, though, a pattern of those alerts, if understood correctly, can identify a future problem in the making. These developing issues could be nipped in the bud, if only Ops teams had enough hours in the day to look at them and review them. But, of course, they don’t—every Ops team I have ever met is drowning in issues, and behind those there is a long and lengthening to-do list.

    What Can DevOps Do to Make Operations Better

    New approaches are emerging to make the principles behind SRE more widely accessible and applicable. In particular, more dynamic noise reduction and correlation is now possible, to sift those important alerts from the constant background noise and put them together into a picture of what is really happening. The key factor is to be able to do this in real-time and without a human having to plan out laboriously what are all the possible scenarios that they might need to know about in the future.

    Gartner has called this new approach Algorithmic IT Operations, or AIOps. The idea is to bring together all possible sources of events, whether those are alerts from the compute or network infrastructure, transaction slowdowns reported by an APM tool, automated deployments being run from a CI/CD toolchain, or anything else the might conceivably be relevant. All of this information then can be sifted by algorithms to understand what is actually important to Ops and brought to the attention of the right specialists who can work on the issues and get them solved fast. Part of that process is also the integration with systems of record (which generally means IT service management), and with automation and orchestration tools that can accelerate remediation activities.

    This is how we can get the Ops side of DevOps to where they need to be to be able to accommodate the ever-accelerating pace of change—whether from Dev teams wanting to run ever more frequent deployments, or from business users needing help with their own goals—or from the next unexpected issue to come down the line.

    — Dominic Wellington

  • Is Cloud Adoption on Your Company’s Horizon?

    Is Cloud Adoption on Your Company’s Horizon?

    Under pressure to increase the speed of innovation in the digital space and outpace competitors, companies large and small are turning to the cloud. Moving to the cloud provides flexibility of infrastructure, transparency of infrastructure costs and many other benefits.

    However, making the transition to the cloud is far more intricate for regulated industries—especially large financial organizations—where security and compliance concerns often trump innovation efforts. According to Cloud Security Alliance, the financial industry is still in the early stages of cloud adoption. In fact, 61 percent of financial leaders say their cloud strategy is in the formative stages. Those financial companies that can shift to the cloud properly will see long-term gains, from both a performance and economic standpoint.

    In 2015, while working at a large international bank, I assisted on a project to help transform how the bank approached digital for retail banking and wealth management. The bank was still approaching most projects as large, monolithic endeavors, where six-month delivery cycles were standard. Infrastructure was owned by IT Operations, and provisioning lacked automation. As such, almost every project began with designing environmental needs from scratch—adding time to both creation and delivery. It was quickly evident that cloud was the bank’s best option, allowing for increased transparency, greater scalability, infrastructure on demand and improved organizational efficiency.

    Shifting to the Cloud

    After working on this project, I learned that to effectively move to the cloud, organizations must understand how to maximize benefits and minimize risks. Here’s how:

    Apply a two-pronged approach

    We realized right away that we needed a system where we could meet our project objectives, while simultaneously exploring the cloud options. To avoid jumping in too quickly and running into non-technical challenges, we adopted a two-pronged approach: we’d build the platform internally using Cloud Foundry PaaS, while exploring the use of external cloud in parallel—without impacting the delivery of the internal platform. To avoid re-architecture and rebuild later on, we had a guiding principle: Whatever is built internally has to be available in the external cloud as well.

    Navigate legal and compliance hurdles

    Regulators are still on the fence when it comes to certain industries adopting the cloud, with regulations still lacking specific policies. For example, in the financial space, lack of close regulation leaves many institutions on their own to sort out contracts with cloud providers based on their individual risk appetite. When regulations are published, they are very high-level and generally state that managing the risk and responsibility for integrity of data is with banks, not with cloud providers. Instead of creating an equal playing field, this tilts the scale toward smaller fintech partners with larger risk appetite±and who more regularly fly under the regulator’s radar.

    Expect roadblocks

    In so many organizations, IT operates in silos. For example, all infrastructure is owned and operated by the IT Operations group, which then recharges that infrastructure back to the businesses based on complex metrics. For cloud to succeed, we need to answer the question of ownership. But that’s not all: Many folks may not believe that organizational issues are a serious problem, and thus, will lack a commitment to be involved. To ease this problem, strong sponsorship from senior leadership is essential.

    Prepare for technical issues

    When implementing a technology solution, things don’t always go smoothly from the start. For example, there might be approved ways to connect with third-party providers that were created before cloud providers came into play. While this kind of issue is easy to solve, it requires a change in internal procedures that must be accounted for.

    Focus on development and testing first, then on production

    While working toward final approval and negotiating the agreement, which can take significant amount of time, conducting a trial run is an effective way to work out any potential problems before full implementation. Signing an agreement to use cloud for development and testing only is less of a hurdle, as no customer data will be transmitted or stored. It’s also important to train anyone who might be involved throughout the process—no matter how big or small their role.

    Conduct a formal project launch and set clear goals

    To drive continuous improvements, it’s essential to establish clear objectives and goals. This provides metrics for benchmarking success and ROI, and encourages the brainstorming of new ideas on a case-by-case basis. Prior to the formal launch, don’t forget to identify key stakeholders and advocates—they will stand behind the project and provide valuable insight into the potential outcomes of decisions.

    Create a transparent culture

    Full transparency is key, even if it means dealing with resistance. Resistance, especially early on, often is unavoidable. However, it is better to deal with resistance, gain support and handle any issues early in the project. Being transparent gains you more support. Or, if the opposition is insurmountable, you can stop the project before wasting too much time or effort. Most important, you want to avoid criticism suggesting that the project is putting the company at risk. By looping in the right people from the start, you’ll have advocates in your corner who will raise red flags and anticipate problems on the horizon.

    Remember that people will want to be involved

    While cloud may still be an unfamiliar concept for many, almost always someone will come out and say, “Actually, I have experience, and already thought about how to do this. How can I get involved?” Bring those people on board, leverage additional insights and increase commitment to the project. This is an exciting change—people want to be on the team that introduces it!

    Large, regulated companies historically have been slow to implement the cloud, due largely to perceived compliance concerns and security risks. However, in an environment marked with rapid innovation, companies are quickly realizing that to stay ahead, adopting a cloud-first business model is a must.

    About the Author / Alexander Kalinovsky

    Alexander Kalinovsky is Director of Engineering at Wipro Digital. He is a senior IT leader with extensive experience managing successful application development and operational teams, along with establishing global development practices and partnering with global organizations. Alex has spent over 10 years working in Financial Services in development and infrastructure, specializing in payment systems and FX solutions. Alex brings his strong FS background and enthusiasm for Agile development to his role at Wipro Digital, driving the digital transformation agenda for many of the world’s leading brands.

  • How IT Ops Teams Prepare to Prevent Web Downtime

    How IT Ops Teams Prepare to Prevent Web Downtime

    IT operations teams can anticipate most periods of peak web traffic. The key to preventing outages and issues is to plan ahead. Here at BigPanda, we’ve prepared a checklist of the key factors IT ops teams need to consider to ensure their IT infrastructure is ready.

    Here’s is a recommended checklist for IT and ops teams:

    • Review monitoring metrics and work with your developers to test applications for stability. Some companies may need additional support to accommodate peak seasons and events.
    • Perform regular security tests and ensure necessary measures are taken to protect your systems. Exposure to hackers and the potential for unanticipated load are real threats.
    • Prepare for alert storms with an effective correlation platform. For IT ops teams, spikes in workload can cause what is known as alert storms. Reduce risk by utilizing an alert correlation platform that identifies patterns in unstructured alert data to separate signal from noise. This allows you to more effectively identify, triage and take action on issues before they have a chance to affect your customers.

    Companies also run a higher risk of downtime during peak traffic times. Seventy-five percent of outages are due to unplanned configuration changes to a system—when IT ops teams find something they think might cause a problem and try to fix it immediately, unintentionally creating a much bigger issue for the web or mobile site.

    To avoid unexpected downtime, we recommend companies take the following steps to ensure the availability and reliability of their services:

    1. Identify what is mission-critical.

    To avoid unexpected downtime, we recommend that IT ops teams tier their services and identify the systems that are mission-critical to the business. Top-tier applications should include those that are linked directly to the success or failure of the business, such as point-of-sale, ticketing or billing.

    2. Develop an ironclad failover plan for top-tier systems.

    Offering a high level of availability is not something that happens by chance. It must be planned carefully for every aspect of your systems architecture. Top-tier systems should be bolstered by an ironclad failover plan—one that plans carefully for load capacity to handle unexpected spikes.

    3. Invest in a best-of-breed monitoring stack.

    You can’t protect against what you don’t see coming. In the age of continuous integration and continuous delivery, the only way to ensure that you have an accurate pulse on the health of your IT systems is to implement the best monitoring tool for each layer of your stack (such as systems monitoring, application monitoring, web and user monitoring, logging and error tracking). The industry rapidly is replacing monolithic monitoring architectures with this “best-of-breed” approach to better service increasingly complex and dynamic IT systems.

    4. Implement alert correlation to distinguish signal from noise.

    More tools—monitoring more moving parts—lead to more noise. It’s a simple fact. To efficiently identify, triage and remedy potential issues before they have the chance to do real damage, IT teams require a way to properly separate the signal—the “real problem”—from the many sources of noise. By implementing an alert correlation solution, IT teams are able to see how alerts from their various monitoring tools are related, allowing them to quickly filter non-critical issues and focus on what matters most.

    — Assaf Resnick

  • Why PR, Legal and HR Matter for Continuous Delivery

    Why PR, Legal and HR Matter for Continuous Delivery

    By most definitions, DevOps involves making developers and IT Ops teams work better together. But integrating other parts of an organization, such as legal and public relations, into DevOps is also important. Here’s why.

    DevOps has become popular because it helps to speed the delivery of software. The goal is to reach continuous delivery, which means code is changed, tested, staged and delivered to users on a (nearly) continuous basis.

    If you think only from a technical perspective, then getting to continuous delivery of software involves only technical people. Developers, IT Ops admins and software testers are all you need.

    DevOps in the Big Picture

    Yet, to deliver software continuously on a reliable basis, you need to think beyond just technical processes and personnel. Effective DevOps workflows have to involve all of the other parts of the organization that play a role in creating software, delivering it to users and maintaining it once it is in production.

    For example, PR teams need to be plugged into the software delivery chain so they know when new features are coming down the pipeline and can prepare to promote them. Legal professionals should play a role as well, since they’ll know when code changes require tweaks to licensing, compliance procedures and so on.

    The list can go on. In most organizations, human resources has a role to play in DevOps, since personnel changes can affect the continuous delivery chain. Supply chain managers should be involved, too, since they have a hand in provisioning the infrastructure on which DevOps teams rely.

    To be sure, these various non-technical teams don’t need to be as plugged into the DevOps workflow as deeply developers and admins do. Code can be written and tested without their perpetual involvement. Still, at a minimum, all parts of the organization should at least be aware of the state of the delivery chain. Otherwise, visibility and communication break down.

    Taking this big-picture approach to DevOps is important because ultimately, despite the relatively narrow purview implied by the term DevOps itself, the value of DevOps lies in adding efficiency and promoting better communication across the entire organization in ways that optimize software delivery.

    So, if you want to make the most of DevOps, start thinking beyond just Dev and Ops.

    — Chris Tozzi