staging-devopsy.kinsta.cloud

Category: DevOps Toolbox

  • DataDog Announces APM. Why You Should Care

    DataDog Announces APM. Why You Should Care

    In case you missed it, DataDog announced it has added application performance monitoring to infrastructure and business goal monitoring.

    1Part of my background includes a variety of clustered systems. First VMware, then OpenStack, Hadoop and its derivatives for a while, and these days the Mesos family. One of the many things I have learned along that journey is the inter-related nature of infrastructure and application. While we all know about that relationship, it goes further, I think, than most people recognize. A single degraded hard disk or loose network connection, which pushes work back out to the rest of the cluster, can drag an entire cluster to its knees.Since my time at F5 Networks taught me a metric ton about the nature of load balancing, I can say confidently that the same could happen to your load-balanced application.

    The biggest frustration for me in most multi-system configurations is the inability to track enough places to quickly diagnose the problem, because your application could be brought to its knees just as easily by a memory leak. But the logs are spread across multiple logs on multiple machines, between the hardware, OS, and software, and you generally have to go looking for more information. Even if you have some of the best tools in the business, you are still looking in multiple places to find information about one problem and having to do things like sort by time to correlate events between the systems.

    To be certain, other vendors are offering hardware/OS diagnostics with their APM. But DataDog’s approach, adding APM from the infrastructure side (rather than the more common reverse scenario), will offer different insights. So I’m interested in seeing how DataDog’s offering pans out.

    I obviously haven’t had the chance to play with DataDog’s new functionality, but it is a space that very much interests me and one we as an industry do need more work in. So just the fact that DataDog is integrating these three monitoring layers is important. From here, it has a platform for adding things (security monitoring? Inclusive root cause analysis?) or increasing the quality and quantity of across-the-application, metal-to-user information available to Ops and for alerting. In fact, it disappoints me that actual infrastructure isn’t a core part of the APM Conceptual Framework, because the hardware under the VM that is hosting the app server for your app really does matter when performance degrades.

    At a minimum, APM can help you get from problem to solution somewhat faster. If done well, it can alert you to the problem and show you where it is, helping you get from problem to solution even more quickly.

    — Don Macvittie

  • Automation, ChatBots Can Improve DevOps

    Automation, ChatBots Can Improve DevOps

    At its heart, the goal of DevOps is to foster better communication between the development team and operations team at an organization. When these two teams are systematically connected, they can easily stay in sync on most issues and there is strong coordination in building and delivering the product to customers.

    Automation and ChatBots can play a big role in the connecting development and operations. They open the door for companies to go beyond simply being alerted when something happens in a chat application, allowing an employee to take action after receiving the alert either in an automated manner or by providing guidance to the employee on which actions to take.

    Automation: Creating Smart Alerts That Don’t Require Follow-Up

    Monitoring applications, systems, virtual machines and networks are a key part of any operations team. There are a number of tools that are used for this purpose, including CloudWatch, Splunk, Rollbar, Pingdom and Newrelic. These tools typically alert the operations teams when there are issues. Engineering teams, on the other hand, use tools such as JIRA and Github to track tickets and manage their agile development process. Alerts from the tools used by operations are helpful, but they still require some manual follow-up. For example, imagine a critical alert is reported by one of the tools because of a product issue. Follow up on this alert would require:

    • Creating a ticket in JIRA/Github with all the relevant information to help diagnose the issue.
    • Escalating that ticket so that it gets looked into right away.
    • Keeping the required people in sync as the status of the issue changes.

    This entire process can be automated. When automated, the workflow operates like this:

    • When the monitoring tool senses there’s something abnormal, like error rates above certain thresholds or a critical failure, alerts are sent and a ticket is created in JIRA or Github automatically with all the relevant information about the issue.
    • Taking this a step further, based on the type of issue, it can be automatically assigned to the right person and even post a message on the appropriate Slack channel.
    • As engineering works through the issue, everyone is automatically informed in Slack when the ticket is updated.

    The key to getting this scenario automated is to leverage an integration and automation platform that is powerful enough to handle complex workflows, yet easy to use so that these automations can be built in minutes. Users don’t want to work for your automations, they want their automations to work for them. With that in mind, the platform should also be flexible so changes can be made to the workflows without any engineering effort (i.e., an automation platform where integrations and automations can be built and changed without any coding).

    ChatOps: Monitor and Orchestrate via Chat Platforms

    With all the apps being used by DevOps, it is difficult for any team to stay on top of monitoring and managing issues while also taking actions across all these tools. Studies show that app hopping is not efficient and results in constant context switching, which negatively impacts productivity.

    ChatOps allows users to stay on top of everything including orchestrating workflows right from chat platforms such as Slack. To make ChatOps work, users need a bot that works in tandem with an integration and automation platform. The bot works with all business apps (even the tough ones with custom objects such as Github and Salesforce), is customized to meet the specific needs of the business and can extend to address all operational needs.

    Here are three ways users can leverage bots for better DevOps:

    Smart, actionable alerts: Rather than have a firehose of alerts coming in, users can define various thresholds, monitor velocity of alerts and, based on these settings, post an alert to the relevant channel or person on Slack. Bots can also prompt the person to take action based on the notification.

    Stop services, virtual machines: Bots can connect with any app, or service that has a HTTP/REST API. Not only can they monitor various apps and environments, they also can start and stop them.

    Workflow orchestration: Various workflows such as managing incidents, escalations and deploying code are all triggered and managed through Slack.

    Automating DevOps has significant benefits in overall increased engineering and operations productivity. The key to automation success is to select an integration and automation platform that is secure, resilient, can handle complex workflows, can be easily customized to meet the specific needs of the business and can be managed through Slack. It should be easy to use so automations can be built fast and changed easily as workflows change. Automation and ChatOps will streamline business workflow, keep the important players from both development and operations informed and increase productivity for everyone involved.

    About the Author / Gautham Viswanathan

    Gautham Viswanathan is the founder/head of products at Workato, www.workato.com. He also leads the team in creating Workbot For Slack, a bot designed to be customizable and allow you to do work in your apps right from Slack. Gautham has a deep background in integration platforms and was previously the head of products and engineering at TIBCO. Connect with him on LinkedIn.

     

  • Relevant Continuous Testing: The Primary Key to DevOps

    Relevant Continuous Testing: The Primary Key to DevOps

    My recent blog, “7 Pillars of DevOps,” identified seven essential best practices areas that make up successful DevOps and explained that the pillars are not silos, but rather foundations that need to be kept in balance. One of the pillars is continuous testing (CT).

    For well-balanced DevOps, CT performs tests that are fast enough to just fit within the time budget, yet thorough enough to cover the quality needed for deployment to production. Despite the need for balance, CT can be considered the true backbone of DevOps because testing is the one pillar that proves the validity of changes needed to operate and validate the correct operation of the other pillars from end to end across the pipeline.

    Compared to older testing strategies in which large software changes were tested as a complete product after “release to QA,” DevOps CT strategically tests changes incrementally over a series of DevOps stages. CT begins the moment a change is made in development and continues through all DevOps pipeline stages. Release readiness is judged on analysis of test results accumulated prior to deployment. With Blue-Green, A/B and Canary test strategies, some tests may continue into the live environment after deployment, and the results may influence future CT activities.

    Like continuous integration (CI), frequent, small, incremental testing has many merits. Quick feedback on problems enables a release consisting of many individual changes to be tested incrementally with confidence. The root cause of problems can be isolated much faster when the changes are tested incrementally. The problem is determining which tests are most relevant to run at each stage of a DevOps pipeline with content, with the risk of changes varying widely from one change to the next.

    Given that testing is a stochastic sampling process, there is no such thing as 100 percent testing in any absolute sense. Left unchecked, the content of tests will grow exponentially beyond the content of the product that is being tested. No number of test resources, even if elastic on-demand cloud infrastructures are used, will keep up with the growing demands to satisfy test requirements. The key is to create and choose tests that are most relevant to the changes that are being processed in the pipeline rather than attempting to run all tests with no regard to actual matter what the changes you wish to inspect. A strategy that chooses the most relevant tests at each stage in the pipeline is optimal.

    Several strategies for creating and selecting relevant tests are described below. These relevant test strategies may be used standalone for specific DevOps stages or a plurality of these relevant test strategies may be used end to end across the pipeline.

    1. Choose tests that focus on source code deficiencies. Metrics based on static analysis scans can determine which areas of source code have the highest number of defects. Test creation and selection algorithms can provide higher weight to tests written for those areas. This seems like a good idea; however, there are several limitations. Scan tools are limited to specific languages, may miss critical defects and do not have intelligence regarding the systemwide relevance of a specific defect.
    2. Create and choose tests for areas of the code with low test coverage. This also sounds like a good idea, but it is not. The most obvious reason is that tests probably are not available to select or the coverage would have been higher in the first place. Also, code coverage algorithms, especially at the system level, are limited to simple metrics such statement coverage, which is not a good indicator of system-level performance.
    3. Create and choose tests that match the artifacts of build changes including build dependencies. In this approach, tests are mapped to build changes and tests are selected that match the changes. This sounds logical, but unfortunately, a static mapping between test and build artifacts may not reflect system impacts of changes, as critical failures may occur due to interactions with modules outside the build dependency chain.
    4. Create and choose tests per risk analysis. This approach keeps a running record of code changes correlated to test results. Tests that tend to fail the most when a code module is changed are selected. This approach has several advantages over the other approaches. Test selection is not limited to implementation language or build dependency maps. Empirical experience correlates to risk better than code structures in the stochastic context of testing. The same algorithms can be applied to every stage in the pipeline. And the pipeline metrics can be adjusted dynamically for each pipeline stage run.

    The above CT practices indicate that relevant testing strategies reduces the time for CT execution and reduces the infrastructure cost for CT, without sacrificing quality delivered to production.

    Summary

    What do you think? Do you agree with the above relevant continuous testing practices? Are there others you recommend?

    While DevOps implemented with all seven pillars provides a strong foundation for long-term enterprise business improvements, it is important to understand DevOps is not an island. Enterprises implementing DevOps should be aware that DevOps interoperates with other IT systems and practices. Enterprises are well-advised to put in place governance policies that encourage the selection of tool-agnostic IT partners with solutions that best suit the needs of each unique enterprise and can integrate and evolve DevOps together with all their IT systems.

    — Marc Hornbeek

  • Automation: Achieving Faster Rollouts with Better Accuracy

    Automation: Achieving Faster Rollouts with Better Accuracy

    A changing landscape requires new processes

    At the recent Symposium/ITxpo, Gartner shared a list of technologies and trends that will be important for organizations to embrace and prepare for in 2017. These trends, which are listed in the report, “Top Strategic Predictions for 2017 and Beyond: Surviving the Storm Winds of Digital Disruption,” reinforce the breadth of technology that IT must support, roll out and engage with. This includes everything from the 100 million consumers who will shop using augmented reality to dealing with the roughly 21 billion endpoints expected to be in use in 2020.

    The report also demonstrates how fast technology changes directions. For example, Gartner predicts that in 2019, 20 percent of brands are expected to abandon their mobile apps. “Many brands are finding that the level of adoption, customer engagement and return on investment (ROI) delivered by their mobile applications are significantly less than the expectations that underpinned their app investment,” the report notes. However, this doesn’t mean less work. IT departments continuously have shift gears to support new processes, news apps and new technologies, such as the Internet of Things (IoT) and the massive amount of data that it produces.

    The dynamic needs of today’s businesses are driving organizations to increasingly adopt new technologies and applications that oftentimes don’t play nice with the existing set of infrastructure and legacy systems in place. So, while it’s clear that the technology landscape is changing, what isn’t so obvious is how IT and business decision makers should be adapting to an industry that is in constant motion.

    In-Steps DevOps

    To keep up, IT must implement agile methodologies that can adapt quickly to market changes. The DevOps mentality is making its way into many organizations and involves the development team creating, building and evolving products to ensure the organization is up to date, while the operations team confirms everything is running smoothly prior to a launch going live. This level of checks and balances isn’t just a nice to have, it’s a necessity—one mistake and the entire system can be brought down. Fostering a greater level of collaboration between development and operations makes it possible to efficiently and effectively build, test and correct new features and new products.

    While the shift to a more collaborative environment between the Dev and Ops teams can take time, using modern IT automation solutions can make this transition easier. Such solutions automate many of the routine—and even not so routine—elements of the application release process within DevOps. Many of the actions necessary to move from code to production—not to mention maintenance, testing and cleanup tasks—can be taken off the backs of developers and operations, saving them time so they can focus on higher-level projects and reduce manual errors.

    Finding the Balance Between Speed and Accuracy

    In 2012, Facebook announced it was increasing the speed at which it released code to twice a day, every day. As Chuck Rossi, director of Release Engineering at Facebook said, his team follows the advice “ship early and ship often.” Facebook continues to follow this model, and while the company certainly didn’t invent it, the model has caught on and is spreading among companies developing virtually every type of technology. The catch? It’s an incredibly time-intensive process and not every company has the resources necessary for a dedicated release team. Plus, a true shift to DevOps doesn’t happen overnight, especially since there is a ramp-up time for folks to get on board. For example, Phil Dibowitz, systems engineer at Facebook, told TechTarget that it “led its Chef team through a three-year process to rethink configuration management to scale on par with the web-scale company’s data centers.”  This took three years, he said, “not because of the technological change, but because of the structural change.”

    A slow transition to a new technology or new way of operating is a common occurrence because historically the production systems are cordoned off from development groups. While the Ops team has to ensure the rollout will meet certain standards, the Dev team wants to speed the process to begin the final rollout process as soon as possible. A happy medium exists, but if it isn’t found, things can go very wrong. Unfortunately, 2015 gave us two major examples of what can go wrong if products can’t speak to each other and rollouts are completed too early: Remember the New York Stock Exchange and United debacles?

    Breaking Constraints Through Automation

    This is where modern workload automation comes into play. Automation and solid change management allows IT to flexibly add on new technologies with automated processes for building, testing, upgrading and configuring IT—all while reducing the slack time between various steps. For instance, a workload automation solution should be able to trigger a build, deploy the build to the test environment, run the test suite and, assuming testing meets acceptable criteria, promote the build to production. If something does go wrong, necessary remediation can occur, and through monitoring and alerting capabilities, the required parties can be notified proactively.

    Additionally, automation solutions with pre-built integrations make it easier for disparate applications to communicate, creating an end-to-end approach to workflow creation and maintenance. As a result, IT organizations can minimize the risk of business disruptions and achieve a more fluid technology delivery to the business.

    Although it’s not a silver bullet that will solve all DevOps transition issues, automation does reduce manual intervention, which leads to fewer delays and errors and improves speed at which tasks are completed. However, beyond the technological aspects, there must be a clear understanding by both sides (the Dev and Ops group) on what their counterparts need—and this requires a high level of trust and coordination.

    While the specifics around the DevOps methodology certainly will change, automation will remain a critical piece of the process. With IT automaton, DevOps teams are able to refocus on critical IT business and operational processes, thereby reducing delays, decreasing errors and improving the speed at which tasks are completed. Ultimately, automation makes it possible to increase the speed of product releases and enable companies to stay ahead in the age of unpredictable customer preferences and ever-changing technological developments.

    About the Author / Mehul Amin

    Mehul Amin, a 21-year veteran of Advanced Systems Concepts Inc. (ASCI), previously held roles as product engineer and technical support manager and played an integral part in building the company’s workload automation solution, ActiveBatch. In his current role as director of Engineering, Mehul drives high-profile initiatives and leads both the Product Engineering and Release Engineering teams. Mehul received a master’s in computer science from the Stevens Institute of Technology.

  • An Operational Approach to Benchmarking Microservices

    An Operational Approach to Benchmarking Microservices

    Benchmarking microservices often falls behind on the engineering team’s to-do list. However, those that aren’t are missing out on a key component. The fundamental goal of benchmarking is to better understand the software, and test out the effects of various optimization techniques for microservices. In this post, I’ll describe an effective approach to benchmarking microservices.

    First, create a spreadsheet for tracking your benchmarking. One convenient way to document a series of benchmarks is in a Google Spreadsheet. It allows collaboration and provides the necessary features to analyze and sum up your results. Structure your spreadsheet as follows:

    • Title page
      • Goals
      • Methodology
      • List of planned and completed experiments (evolving as you learn more)
      • Insights
    • Additional pages
      • Detailed benchmark results for various experiments

    Then, before you engage in benchmarking, clearly state (and document) your goal. Examples of goals are:

    • “I am trying to understand how input X affects metric Y”
    • “I am running experiments A, B and C to increase/decrease metric X”

    Next, pick one key metric, stating clearly which one metric you are concerned about and how the metric affects users of the system. If you choose to capture additional metrics for your test runs, ensure that the key metrics stands out.

    Now, you’re going to have to think like a scientist and perform a series of experiments to better understand which inputs affect your key metric and how. Consider and document the variables you devise and create a standard control set to compare against. Design your series of experiments in a fashion that leads to the understanding in the least amount of time and effort. You’ll then need to define a methodology for running your benchmarks. It is critical your benchmarks be:

    • Fairly fast (several minutes, ideally)
    • Reproducible in the exact same manner, even months later
    • Documented well enough so another person can repeat them and get identical results

    Document your methodology in detail. Also document how to re-create your environment. Include all details another person needs to know:

    • Versions used
    • Feature flags and other configuration
    • Instance types and any other environmental details

    In most cases, to accomplish repeatable, rapid-fire experiments, you need a synthetic load generation tool. Find out whether one already exists. If not, you may need to write one. Understand that load generation tools are at best an approximation of what is going on in production. The better the approximation, the more relevant the results you’re going to obtain. If you find yourself drawing insights from benchmarks that do not translate into production, revisit your load generation tool.

    It is then important to validate your benchmarking methodology, and repeat a baseline benchmark at least 10 times and calculate the standard deviation over the results. You can use the following spreadsheet formula:

    =STDEV(<range>)/AVERAGE(<range>)

    Format this number as a percentage, and you’ll see how big the relative variance in your result set is. Ideally, you want this value to be less than 10 percent. If your benchmarks have larger variance, revisit your methodology. You may need to tweak factors like:

    • Increase the duration of the tests.
    • Eliminate variance from the environments.
      • Ensure all benchmarks start in the same state (i.e. cold caches, freshly launched JVMs, etc).
      • Consider the effects of Hotspot/JITs.
    • Simplify/stub components and dependencies on other microservices that add variance but aren’t key to your benchmark.
      • Don’t be shy to make hacky code changes and push binaries you’d never ship to production.

    Important: Determine the number of results you need to get the standard deviation below a good threshold. Run each of your actual benchmarks at least that many times. Otherwise, your results may be too random.

    Now that you have developed a sound methodology, it’s time to gather data. Some tips include:

    • Only vary one input/knob/configuration setting at a time.
    • For every run of the benchmark, capture start and end time. This will help you correlate it to logs and metrics later.
    • If you’re unsure whether the input will actually affect your metric, try extreme values to confirm it’s worth running a series.
    • Script the execution of the benchmarks and collection of metrics.
    • Interleave your benchmarks to make sure what you’re observing aren’t slow changes in your test environment. Instead of running AAAABBBBCCCC, run ABCABCABCABC.

    Now, you’ll need to create enough loads to be able to measure a difference. There are two different strategies for generating load:

    1. Redline it! In most cases, you want to ensure you’re creating enough load to saturate your component. If you do not manage to accomplish that, how would you see that you increased its throughput? If your component falls apart at redline (i.e. OOMs, throughput drops, or otherwise spirals out of control), understand why, and fix the problem.
    2. Measure machine resources. In cases where you cannot redline the component, or you have reason to believe it behaves substantially different in less-than-100-percent-load situations, you may need to resort to OS metrics such as CPU utilization and IOPS to determine whether you’ve made a change. Make sure your load is large enough for changes to be visible. If your load causes 3 percent CPU utilization, a 50 percent improvement in performance will be lost in the noise. Try different amounts of load and find a sweet spot, where your OS metric measurement is sensitive enough.

    As you execute your benchmarks and develop a better understanding of the system, you are likely to discover new factors that may impact your key metric. Add new experiments to your list and prioritize them over the previous ones if needed.

    In some instances, the code may not have configuration or control knobs for the inputs you want to vary. Find the fastest way to change the input, even if it means hacking the code, commenting out sections or otherwise manipulating the code in ways that wouldn’t be “kosher” for merges into master. Remember: The goal here is to get answers as quickly as possible, not to write production-quality code—that comes later, once we have our answers.

    Once you’ve completed a series of benchmarks, take a step back and think about what the data is telling you about the system you’re benchmarking. Document your insights and how the data backs them up. It may be helpful to:

    • Calculate the average for each series of benchmarks you ran and to use that to calculate the difference (in percent) between series — i.e. “when I doubled the number of threads, QPS increased by 23 percent on average.”
    • Graph your results — is the relationship between your input and the performance metric linear? Logarithmic? Bell curve?

    Finally, you’ll need to present your insights. Here are some final tips for exhibiting to management and/or other engineering teams:

    • Apply the Pyramid Principle. Engineers often make the mistake of explaining methodology, results and concluding with the insights. It is preferable to reverse the order and start with the insight. Then, if needed/requested, explain methodology and how the data supports your insight.
    • Omit nitty-gritty details of any experiments that didn’t lead to interesting insights.
    • Avoid jargon, and if you cannot, explain it. Don’t assume your audience knows the jargon.
    • Make sure your graphs have meaningful, human-readable units.
    • Make sure your graphs can be read when projected onto a screen or TV.

    — Stefan Zier

  • Top Reasons to Use Node.js

    Top Reasons to Use Node.js

    When considering the architecture of a new web app, it might be a good idea to include Node.js in the discussion as a key part of that architecture. Node.js could provide you with additional speed, can be used on numerous platforms and has an active community from which to get modules and other assistance.

    What is Node.js?

    Node.js is a server-side platform developed by Ryan Dahl in 2009. It was built on Chrome’s V8 JavaScript engine and designed with a non-blocking, event-driven I/O. It is also cross-platform, able to be run on Windows, Linux and OS X. Its non-blocking I/O is due to its use of asynchronous functionality, which keeps the server from waiting on data to be returned before being able to move on to other tasks.

    Why Use It?

    Given the architecture of Node.js, a number of advantages are provided both to developers and the resulting apps they develop. A few of these advantages include speed, programming language consistency, real-time apps developed easily and a large number of modules/packages for developers to use while creating new apps.

    Speed

    Node.js offers speed advantages in many cases. First, it uses the Google V8 engine, which is optimized for JavaScript speed. Also, its use of non-blocking asynchronous behavior can ease the time it takes for users to see actions as complete, since things can be going on in the background while the user moves on to other tasks.

    One Language

    JavaScript is listed as the most popular programming language. Source: Thenewstack

    Using Node.js, front-end and back-end code can both be in JavaScript, so your developers don’t have to transition between languages as they move through the stack. Some architectures, such as the MEAN stack (MongoDB, Express.js, Angular.js, Node.js), are designed around this principle. In this case, the stack uses JavaScript for Express, Angular and Node. MongoDB uses BSON for database queries, which uses the same syntax as JSON (JavaScript Object Notation).

    Seeing full-stack developer as the largest occupation and JavaScript as the top language among both back-end and front-end aligns with what we’ve been seeing in overall JavaScript adoption.

    Source: Mikeal Rogers, Node,js Foundation Community Manager 

    For developers, this can help both with moving across the stack during development as well as help communication among developers, as they will be referencing the same language (JavaScript) while discussing programming decisions.

    Real-Time Apps

    Node.js is a great platform for creating real-time apps. With a module such as Sockiet.io, you can create real-time chats, games and more. Along with its non-blocking asynchronous architecture, real-time apps can be developed with plenty of speed and responsiveness.

    Modules

    The Node Package Manager (NPM) makes it easy to install packages that others have developed to perform any number of tasks. This helps to encourage code-sharing among developers and to reduce the amount of custom development that has to be done when one or more packages can take care of that coding for you.

    Notable Examples

    Some notable examples of Node.js use are Paypal and Uber, showing that it can, indeed, be useful for large projects.

    Paypal

    Node.js and an all Javascript development stack helped PayPal bring efficiencies in engineering and helped rethink and reboot product, design and operational thinking.

    Source: Sameera Rao, Paypal Sr. Business Products Engineering Manager 

    Back in 2012, Paypal had a single app running all things, including UI, API and more. This included a lot of duplicated code that was copied and pasted from one app to another to make apps for different locations.

    Using Node.js, the company was able to modularize and clean up its code and processes, which in turn sped the development of apps it needed at any given time.

    According to Paypal’s engineering team, they were able to build the Node.js app with 33 percent fewer lines of code and 40 percent fewer files, and were able to build it twice as fast and with fewer people than before. Certainly, Node.js proved to be advantageous to their development.

    Uber

    Uber used Node.js from the beginning, and its distributed system was a perfect fit, since a lot of network requests are made. The non-blocking asynchronous I/O used by Node.js helped to ensure those requests could be made and handled quickly to provide the best service possible.

    Conclusion

    The benefits of Node.js have been proven. It helps speed development, can be used on numerous platforms and has an active community from which to get modules and other assistance. Include Node.js in your future conversations about website architecture.

    — Brian Wheeler

  • Are You Paying a ‘Wait-Time Tax’ on Your Global DevOps?

    Are You Paying a ‘Wait-Time Tax’ on Your Global DevOps?

    Business increasingly is global, so DevOps has become global as well. In fact, for many enterprises, DevOps entails collaboration between development, test/QA and ops teams across multiple continents.

    This is in part due to the economics of IT labor and in part because applications for global enterprises have to be deployed globally.

    Unfortunately, enterprises executing DevOps globally must confront the physical realities of global code distribution. And those physical realities impose a “wait-time tax” that fatally undermines Agile processes and culture.

    But they don’t have to. There’s a tax-free way to share large volumes of code across globally dispersed DevOps teams.

    The Wait of the World

    Every time you ship a massive build worldwide, you have to wait. Assume, for example, that you’re sending a 10GB build to five different locations over a 10Mbps MPLS connection. If a couple of your remote locations have 5Mbps connections, it will take them five hours to get each build. But if you have three locations with only 2Mbps connections (as is likely the case in Asia), they will have to wait 12.5 hours.

    That wasn’t a problem when you iterated your builds with limited frequency. But as you try to become more aggressive about highly iterative Agile development and testing, this “time tax” becomes punishing.

    For one thing, you lose productivity as your overseas developers and test teams wait idly for new artifacts. And these chronic wait times fundamentally undermine the Agile culture you’re trying so hard to build across your organization.

    In fact, if your current model for distributing code globally remains as-is, you’ll never achieve the speed and iterative frequency your business needs. And you’ll certainly never come anywhere close to continuous delivery.

    Faster Cycles from Dublin to Dubai

    Fortunately, you can eliminate DevOps wait times, regardless of how globally dispersed your teams are and how thin their connections to your enterprise network may be.

    The solution entails a hub-and-spoke model that:

    • Lets you maintain a “gold copy” of your current codebase(s) in the cloud;
    • Provides all your remote locations with their own local codebase copies that get continuously and automatically updated with any incremental changes as they occur; and
    • Leverages each location’s high-throughput internet connection.

    The combination of small, incremental code updates and high internet bandwidth dramatically changes the rules of the global DevOps game, allowing even the most geographically dispersed teams to work with even the largest codebases extremely iteratively and without delay.

    It’s difficult enough to sync dev and test teams on different continents. And the pressures on your organization to respond immediately to ever-changing market and regulatory demands will only intensify. So now’s the time to consider abandoning your obsolete approach to global code distribution and adopt a model that better enables you to be fast, super-iterative and global.

    — Barry Phillips

  • 5 Reasons Why Companies Should Analyze Their Logs

    5 Reasons Why Companies Should Analyze Their Logs

    At first thought it might seem as though analyzing logs is something that only affects the IT portion of your business. However, nothing could be further from the truth. In reality, log analysis affects every aspect of your business. This includes finance, legal, human resources, sales and marketing, security and operations. In fact, with log analysis, you’ll discover issues either before or as they happen and avoid both lost time and unnecessary delays.

    There are many benefits to properly analyzing your logs. Your organization can increase revenue, reduce expenses, better manage employees, respond to incidents and even keep yourself out of legal hot water. Read on to learn about the five major business areas impacted by log analysis and why every business needs to analyze its log—and the sooner the better.

    Business Operations

    Probably the most obvious use of log analysis is in supporting business operations. These functions include the following:

    • Detecting critical system errors
    • Identifying key trends
    • Improving operational efficiency
    • Supporting service level agreements (SLA)
    • System troubleshooting

    Early indication of problems can pinpoint money-wasting processes. It also can mitigate risk in support of business continuity. This will help avoid service disruptions that can lead to unhappy customers and lost sales.

    Compliance and Legal

    Every organization has internal policies: security policies, employee policies, legal policies, etc. In fact, most organizations have regulations (such as HIPAA and Sarbanes-Oxley) they must adhere to. Often these regulations are imposed by the government. The only feasible way to ensure policies are followed and regulations are met is through log analysis.

    Log analysis simplifies compliance. It also supports audit requirements, litigation needs, subpoena requests and forensic investigations. In short, log analysis is the only way to ensure an organization stays out of legal trouble.

    Proper Resource Sizing

    One of the worst things any company can do is have the wrong amount of resources to support its business operations. From network bandwidth to storage capacity to CPU cycles, businesses have to get these quantities just right. Not enough resources in any area can lead to poor performance, frustrated customers and, eventually, lost sales.

    Of course, the easy thing to do is just overspec these resources. However, doing that leads to increased expenses, which adversely impact the bottom line. Using logs to determine proper resource sizing is the only way to ensure you have maximized your profits.

    The use of logs can also be used to verify third-party billing. For instance, your company can use your logs to make sure the amount of bandwidth you were charged for by your service provider is actually the amount you used. This, too, can benefit the bottom line.

    Sales and Marketing

    It may not seem as though log analysis can be used to directly impact sales and marketing, but it certainly can. For starters, log analysis can be used to quantify the effectiveness of a sales campaign. Information such as referring sites, pages accessed and conversion rates all can be used to tweak different aspects of the sales effort.

    Log analysis also can be used to optimize website performance in the support of a sales funnel. Information such as customer navigation, traffic loads and conversion errors can be used to improve the sales process. In fact, analyzing logs can be used as a revenue driver in any organization.

    Security

    One of the most important areas in any business today is security. Logs can be used to both proactively protect an organization, as well as forensically investigate security breaches.

    Proactively, logs can be used to accomplish the following:

    • Optimize blocking and filtering of incoming traffic
    • Maximize email virus protection
    • Monitor failed authentication attempts
    • Verify configurations in firewalls

    After the fact, logs can be used to do the following:

    • Assess security policy compliance
    • Initiate incident response
    • Investigate security breaches

    You cannot understand security risks or respond to security incidents without the ability to analyze your logs.

    In short, whether you were aware to it or not, log analysis impacts every department in your organization. It directly and indirectly impacts every company’s bottom line by increasing revenue, decreasing expenses and delighting customers.

    You now know that log analysis is not just a “back office” IT function. Every department in your company needs to use the intelligence contained in your logs to do their jobs better. It is why every business needs to analyze their logs, and now is the time to start.

    About the Author / Ariel Assaraf

    arielassarafAriel Assaraf is a co-founder and CPO at Coralogix. Previously Ariel was a GL at Verint and a Product manager at an elite Israeli intelligence unit.  He is into Software design, UX, growth hacking and basketball. Ariel holds a BEc in Economics and Math from the Open university of Israel. Connect with him on LinkedIn and Twitter

  • Mainframe Apps and the Long View of DevOps Strategy

    Mainframe Apps and the Long View of DevOps Strategy

    IT is constantly under intense short-term pressures. Line of business (LOB) executives demand a competitive advantage in digital customer engagement now. Marketing leaders demand better customer analytics now. Legal demands better audit reporting now.

    In fact, much of the investment that companies are making in Agile, DevOps and continuous delivery is due to the urgent, short-term demands of the business.

    But short-term actions alone are insufficient for business success. IT leaders must also strategically navigate the vagaries of the digital economy over the long term—or, as Wayne Gretzky’s father taught him, to “skate to where the puck is going to be.” Otherwise, today’s small wins inevitably will lead to tomorrow’s egregious failures and inefficiencies.

    And integration of your mainframe apps and data into your enterprise DevOps tool chain is central to that long-term digital strategy.

    Here’s why.

    The Mainframe: Big, Nimble Iron

    A DevOps tool chain is only as fast as its slowest link. For most large enterprises, that slow link is the mainframe.

    Slow, waterfall-bound and underautomated mainframe dev/test processes are non-trivial—because mainframe applications and data are non-trivial. They typically are an organization’s most important apps and data. So if you can’t modify your mainframe application logic quickly or leverage your mainframe data in new ways easily, you’re uncompetitive toast in today’s fast-moving markets.

    Also, mainframe applications and data typically serve as the back-end systems of record for front-end mobile and web-based systems of engagement. Your ability to innovate and remain competitive when it comes to digital engagement and digital perceived value is, therefore, almost universally contingent on lessons learned from frequent and timely mainframe code drops.

    In other words, everything IT is under pressure to deliver—new mobile apps, better analytics, fulfillment of increasingly stringent compliance mandates, etc.—depends on bringing Agile, DevOps and (ultimately) continuous delivery to the mainframe.

    Just about everyone realizes this. Sure, there are some holdouts who still advocate something they call “bimodal IT”—which prescribes allowing the mainframe to languish in obsolete waterfall and dev/test practices while the rest of the enterprise moves forward. But bimodal lT has proven to be a mistake. An Oct. 31, 2016, Forrester Research report titled, “Predictions 2017: CIOs Push For Speed Amid Volatility,” shines a light on the fatal realities of bimodal IT:

    “In early 2016, many CIOs fell for the false promise of a bimodal strategy. They only pushed part of their team to adopt an accelerated pace — and left others unchanged. But those CIOs are already experiencing the shortcomings of operating at two speeds. Business peer frustration, polarizing and deteriorating cultures, and unsustainable operational complexities will continue, ultimately spurring most of these CIOs to course correct in 2017.”

    Given the explosion of mainframe-related innovation that has taken place in the past couple of years, enterprise IT leaders and industry analysts agree that “mainstreaming” it into enterprise DevOps is the right and necessary strategy (see as examples here and here).

    Some Good Things Take Time

    While instant gratification may be the order of the day—and gain without pain may be an all-too-frequent vendor promise—the reality is that great IT achievements all require effort, investment and time.

    Inclusion of the mainframe into your cross-platform DevOps tool chain is no exception. No CIO can achieve mainframe agility and cross-platform DevOps orchestration by simply waving a magic wand. But there is a clear, practical path to these goals for those with the requisite foresight and leadership.

    That path includes:

    • Modernizing the developer workspace. Most mainframe development is still performed in “green screen” TSO/ISPF environments that require specialized knowledge and limit staff productivity. A modernized, graphical workspace as part of a preferred DevOps tool chain will allow staff at all experience levels to perform dev/test tasks on both mainframe and non-mainframe applications.
    • Graphical visibility into existing code and data structures. Mainframe applications typically are large, complex and poorly documented. These attributes are a major impediment to mainframe transformation. The right tools enable new participants in mainframe DevOps to quickly and easily “read” existing application logic, program interdependencies and data relationships.
    • QA “shift left.” Early detection and correction of quality issues is a central principle of modern programming—and it’s particularly important on the mainframe, where there’s an especially low tolerance for error.
    • Initial Agile training and adoption. Once you put the right development environment in place, you can start shifting your process from a traditional waterfall model with large sets of requirements and long project timelines to a more incremental model that allows teams to quickly collaborate on user “stories” and “epics.”
    • Use operational data throughout the dev/test life cycle. By using operational data in the dev/test life cycle, your DevOps team can ensure that applications perform optimally in production. They also can significantly reduce your MIPS/MSU-related costs by avoiding excessive CPU consumption caused by inefficient code.
    • Agile-enable source code management (SCM) functions. Traditional mainframe SCM environments are inherently designed for waterfall development and thus are incapable of supporting Agile requirements such as parallel development on user stories. The shift to Agile-enabled SCM is, therefore, absolutely essential for mainframe transformation.
    • Automated release management. To keep pace with today’s fast-moving markets, you must be able to quickly get new code into production. That means automating and coordinating deployment of all related development artifacts across all targeted environments.
    • Cross-platform DevOps. Ultimately, you need to fully de-silo your enterprise environment so the mainframe becomes “just another platform”—albeit an especially scalable, reliable, high-performing, cost-efficient and secure one—that can be modified quickly as needed to meet the relentlessly evolving needs of the business.

    ‘What’s My Motivation?’

    With as much as IT departments have on their plates, it’s easy to continue putting off mainframe DevOps integration. But, ultimately, there are only two alternatives to doing so:

    • Re-platform your mainframe applications. This alternative has proven to be a costly and extremely risky undertaking that delivers zero benefits while it consumes resources and potentially disrupts IT operations, or
    • Continue doing nothing. This alternative puts your company at further competitive disadvantage and hastens the day when you’ll experience total mainframe paralysis due to the loss by attrition of all your veteran mainframe developers, QA specialists and operations staff.

    Viewed in this context, genuine investment in the mainframe—whether you call it modernization, mainstreaming or “Millennializing”—is the only reasonable course of action. Such investment starts improving your digital competitiveness immediately, while paving the way for a future where you can make the most of all your resources and confidently transfer platform responsibilities to your next generation of IT professionals. Including the mainframe in your broader DevOps efforts (while extremely valuable) does require commitment, and there are resources available to help. Just be wary of those who may talk a good game, but whose actions don’t really convey a strong commitment to users’ best interests. Fortunately, there are truly dedicated experts who can help every step of the way, and have direct experience modernizing on platform within their own organizations.

    It’s the smart, viable long-term DevOps strategy every CIO of a mainframe-enabled enterprise needs to adopt ASAP.

    About the Author / Christopher O’Malley

    chris-omalley2Christopher O’Malley is CEO of Compuware. He has nearly 30 years of IT experience with past positions including CEO of VelociData, CEO of Nimsoft, EVP of CA’s Cloud Products & Solutions and EVP/GM of CA’s Mainframe business unit, where he led the successful transformation of that division. Connect with him on LinkedIn and Twitter.

  • From the Trenches: Zesty.io’s Google Cloud Migration

    From the Trenches: Zesty.io’s Google Cloud Migration

    Zesty.io recently migrated its sites to the Google Cloud Platform from Rackspace—a process the company believes will make it more agile while streamlining its operations. Zesty.io community manager Phil Ballew recently spoke with Chris Hiestand, Zesty.io’s DevOps leader, to discuss some of the reasons for the migration and get a feel for just what the new cloud system brings to the company.

    Ballew: So what exactly is Google Cloud, and how does that compare to Rackspace?

    Hiestand: Google Cloud Platform is similar to AWS, Rackspace or Azure; they manage infrastructure and services to host your applications and data on. With Zesty.io being SaaS, there are servers running the user’s website that we will manage, and these names are the companies that provide the infrastructure.

    Ballew: So what about Google Cloud made you choose that over Rackspace?

    Hiestand: The difference is that Rackspace has been around for a long time and has produced great business tools, but Google’s tools, which they have been using internally for a while and are now making publicly available, will fit the needs for Zesty.io as we scale out at a rapid pace. Some tech that Google created about 10 years ago is considered cutting-edge today.

    Ballew: What was the reason and initial appeal for moving from Rackspace to Google Cloud?

    Hiestand: Google’s infrastructure is a well-designed fit for containers using the Kubernetes project. Their architecture is designed to minimize operations work, saving labor. Using GCP, we can focus more on writing good software and less on the drudgery of making that software run. Google’s network is remarkable in every respect: good security, bandwidth within the data center, between data centers and out to the greater internet. And their compute nodes are set up in such a way that when they do maintenance, they can move our systems around and we don’t even know it. We stay running and focused while they maintain the hardware.

    Ballew: Kubernetes? What is that exactly?

    Hiestand: Kubernetes is a container orchestration tool based on Google technology that we use on GCP to help us automate and scale the deployment of our software and websites for the users. It helps us think about our applications first and operations a distant second. It also empowers Zesty.io engineers to own what’s running in ops.

    Ballew: What other technologies are you using?

    Hiestand: Kubernetes is built on container technology, so we also use Docker extensively in development.

    Ballew: What were some of the major obstacles that you ran into when migrating to Google Cloud?

    Hiestand: The technical parts are pretty straightforward. The hardest part is probably coordinating with customers. We are mitigating this by keeping Rackspace and Google Cloud in production at the same time, giving customers time to update their DNS records.

    DNS instructions can be found at: https://developer.zesty.io/docs/satellite-sites/launching-a-satellite-site

    Ballew: What are some of the benefits Zesty.io users will see from this switch?

    Hiestand: The most obvious benefit will be the faster page load speeds of Zesty.io-developed websites, including slightly faster application load times for Zesty.io developers. In the not-too-distant future, international load times will be very good, particularly for our enterprise customers. In addition, we are pushing a lot of new features to Zesty.io that will be on the Google Cloud version soon for people to try out. The rollout to GCP also improves our software engineer development velocity so we can get improvements delivered to our customers faster.

    Ballew: Even though Zesty.io users have not all been moved to Google Cloud, is there the option to move now if somebody wanted to, and if so, how can they do that?

    Hiestand: Sure! I would love to help out with that. They can send me an email at support@zesty.io. After we migrate their site, they can update their DNS to point to the new CNAME when they are ready, and customers won’t be able to update their Rackspace website anymore. They will also want to update their bookmarks because the administration URLs have changed, but for the time being, they will get automatically redirected to the new ones. We can help them with any questions they have. Eventually, we will be updating all websites for all users. If you do not update your CNAME, it will take a little extra time for your site to load because of additional network routing from Rackspace to GCP.

    About the Author / Phil Ballew

     

    philballewPhil Ballew is the Zesty.io community manager, working with developers and building the Zesty.io community through many unique outlets. Connect with him on LinkedIn.