devopsy.kinsta.cloud

Category: Doin’ DevOps

3 Steps to Building Data Science Models

Have you ever considered supplementing your development skills with some data science? Expand your range and follow this quick tutorial on how to build your own predictive models using open datasets, Jupyter notebooks and Sequential models.

Pick Your Data Game

Your first step in learning data science is to find a dataset that fits your interests. A robust platform where you can find inspiration is Kaggle, a web-based data science environment for machine learning enthusiasts. It offers, not only open datasets, but also competitions and even free micro-courses.

Maybe you want to change the world and help with scientific research. Maybe you’d like to jump in to win $65,000 in a sponsored challenge. Or maybe you’d like to start with some machine learning techniques. There is plenty of data to search through and there always are a couple of open contests to enter.

For this tutorial we are going to use a dataset from a competition called “Histopathologic Cancer Detection.” It is very important to understand not only the data we are going to work with, but also the main purpose of this challenge. Looking at our example, we read the following: Identify metastatic tissue in histopathologic scans of lymph node sections.

In layman’s terms, the goal is to determine/recognize/discover if there is a sign of tumor tissue in a given image based on a dataset of lymph node scans. This is enough information to know that our model will have to answer this question in a binary manner: if there is a metastatic tissue in a given image, the answer is yes; if there is not, the answer is no.

Choose a Game Plan

There are two main types of machine learning, supervised and unsupervised.

In our case, we have a training set and a ground truth–train labels. In other words, we have prior knowledge of what the output values for our training images should be. Therefore, if we have a ground truth, then we know we are dealing with supervised machine learning.

The goal here is to learn a function based on example input-output pairs. Having this function, the task is to map a new given input to a predicted output. Sound reasonable? Let’s jump into the competition sources and see if we have what we need.

Train set: This set contains the data you will train your model on. It’s the set of plain images for which we already know the correct answer.

Train labels: As you may have already guessed, this file contains the correct answers to each image in a train set.

Test set: Set of images for which we do not know the answer.

Our goal is to create a new file (similar to train labels) containing predicted answers for images from the test set.

Game On!

For this opportunity, I decided to explore Google Colaboratory. It is a free Jupyter notebook environment with Python 3 that requires no setup and runs entirely in the cloud. If you haven’t used Jupyter before, now is a great chance to get started. With Jupyter notebooks, you can write and execute code, save and share it, and even access powerful computing resources, all from your browser.

We start our game by importing the files we need to Google Colaboratory. Here’s how: Remember to copy the imports as we will need them later.

We will use the Kaggle official API (you can read more about the setup and obtaining needed keys here) to easily retrieve large datasets directly to a server environment.

Now when you execute ls /content/, you should see:

We are going to read dataset into the pandas data frame.

The output should be as shown below:

Having all data in place we are ready to construct our first model.

The Sequential model is a linear stack of layers. The model needs to know what input shape it should expect. For this reason, the first layer (and only first) needs to receive information about its input shape. You can read more about the construction of Keras Sequential model here.

We need to declare some helper functions to transform the data to fit our needs (map train set with train labels).

Execute the code below and put on your favorite TV show … this will take some time to compile! Remember to change hardware accelerator to GPU. It’s free and can speed up model building time up to five times. Go to Runtime, then change runtime type and change None to GPU.

Data Science Endgame

Before we generate predictions, we should probably preserve our model (better be safe than sorry).

The last step is to get the answers for the images in our test set. When all is computed we can see predictions for the first couple of images.

To save final results and download them run this:

It’s time to upload the files to Kaggle and wait to see our final percentage score.

Stepping Up Your Data Science Game

There’s nothing better than a little healthy competition. Since we are taking part in a real contest, we have to consider that there will be some winners and some losers. There’s no doubt that we want to be in the first group, but the model that we have trained so far does not guarantee this. We should improve the predictive power as much as possible (although watch out for overfitting).

There are many techniques to do that, including adding more data, algorithm tuning or ensemble methods. It’s easy to list them, but not so easy to pick the ones that actually will improve our score.

There are endless possibilities to increase the predictive power of this or any model. Pick a new dataset and try for yourself to expand your data science skills.

— Magdalena Baracz

May 9, 2019
‘DevOoops’ Moves: Deploying Code Out of Step
‘Everything as code’ can create opportunities for misadventure for DevOps teams

DevOps’ ultimate aim is to create efficiencies in the software delivery process. But it doesn’t always work out that way. Sometimes DevOps initiatives lead to mistakes—something we lovingly call “DevOoops.” CloudBees recently polled some colleagues and came up with five examples of a DevOoops in action. Following is a discussion submitted by Director of Engineering Laura Frank Tacho about deploying code out of step.

Scenario:

Running in parallel during CI/CD can speed up your automated testing and shorten your feedback cycles. Just make sure deployment is not executing as a parallel step. That misconfiguration will cause your code to deploy at the same time the tests are running, regardless of their exit codes, pretty much defeating the purpose of automated testing before a deploy.

This scenario touches on a theme we’ve seen throughout most of the “DevOoops” stories our colleagues have come up with. The theme is how the emerging concept of “everything as code” can create opportunities for DevOps teams to slip on proverbial banana peels.

In this case, we’re talking about sequencing problems in a process we can call pipeline as code.

To be successful, teams need to extend a quality-first approach in automated testing throughout their continuous delivery life cycle—from code to commit to test, as well as through the various tiers of the development life cycle. And with a quality-first approach, you need to apply testing and quality management to your environment configurations and infrastructure as code.

Laura’s example highlights how teams need to treat their CD pipelines as applications themselves. They need to check for and eliminate bugs and errors in CD pipeline code to ensure that code is operating as expected. Failure to properly manage the creation and evolution of complex CD delivery pipelines will result in significant cost or risk.

So, if you don’t have proper test coverage on application code, you could end up releasing an application that hasn’t been tested at all. If the app doesn’t pass through a security gate, as it’s supposed to, you could release unintended preproduction data.

While there are always risks with untested code, we have to give unique consideration to untested or unmanaged CD pipelines. We need to consider the risks of what missed gates could mean for our developers, our organization and our customers.

Teams should do the following as they release their CD pipelines:
- Build: Start from the left-hand side of process and work through the defining and coding of CD pipeline left to right in the direction your apps and development artifacts flow: from dev to test to deployment. While we may not be able to define an ideal automation solution completely on the first pass, going left to right encourages teams to focus on what the life cycle of an artifact looks like.
- Manage: Define your CD pipeline using an everything-as-code or pipeline-as-code approach. For this to add value, you must manage development of your CD pipeline as you would your application code and apply software best practices. Check your CD pipeline code into a source code repository and leverage language-specific technologies that can check your syntax. (If you’re using Groovy-based code or Jenkins-based code, there are versions of Lint that can perform these functions.)
- Create staging environments: You should establish staging environments or test pipelines to validate your CD process. These pipelines should go through all checks and gates against your real tools, using reference code that is representative of the applications your pipeline would be servicing but stops short of production into environments.
This will give you an opportunity to iterate changes against your application code, do some initial scans and checks to collaborate to define your CD pipeline in code-managing SCM. Execute initial validation on scans as pipeline as code and then validate expected operations in a staging environment before you deploy it as the basis of the pipeline for your production of business-critical applications.

Key Takeaways
- This story highlights how crucial it is to ensure that your application code and environments pass through certain gates and checks before being deployed out to the customer.
- You need to construct your CD pipelines so your parallel testing is managed as a gate to production, ensuring that properly tested and validated changes are not automatically deployed.
- Deployment happens at the end of all the processes within a pipeline, and all required tests, validations, checks and approvals have been done before any change is deployed to the customer.
To read our previous “DevOoops Moves” post, click here.

— Brian Dawson
May 7, 2019
How DevOps Can Help Speed Go to Market
With continuous evolution of IT systems, speed and flexibility have become of paramount importance for businesses. This requirement has caused a massive shift in the IT delivery system. Now, building and releasing a better product in the market is not enough for businesses to stay ahead of the competition. Organizations need an agile approach to understand and adapt to information, trends and new developments, and to meet the demands of time-to-market features.

DevOps is one such cultural shift in the IT field that shows how software development and IT operations can work together to reduce time to market. It has attained such a great profile in the market that people have started measuring the outcomes for businesses that adopt it.

If you’re just beginning with DevOps, here are some tips that will help you understand how you can accelerate time to market for your product and services.

How Can DevOps Accelerate Time to Market?

There are many ways in which DevOps helps organizations accelerate time to market for their product. Some of the most effective ways are:

Faster Delivery of Features and Modifications

When development teams build software, they connect with IT operations to send the software for testing. If the product is completely new, operations need to create a testing environment. If the software is an updated version of the current product and there is already a testing environment for it, operations still need to configure and add interfaces and side applications. So, a developer can only deploy code to the software when the operations team tests the product, which is a very time-consuming process.

However, DevOps eliminates such time-consuming tasks from the software development process. For example, with automated testing of web apps developers get quick feedback and automated integration allows them to make changes in the code base more quickly. Therefore, organizations can release small or incremental updates of the software while delivering new features to market faster.

Enhance Efficiency

DevOps encourages development teams to give more time to value-creating work. When businesses use automated testing and integration, developers don’t have to waste their time waiting for machine configuration or code integration. Both tasks can be achieved by clicking a button on the self-service portal.

For example, many European banks have implemented DevOps in their software process, which resulted in 25% efficiency improvements in providing updates for their online banking applications. It also reduces the workload for the IT operations team so that they can work on more challenging tasks to add more value to the company.

Improved Quality Code and Quick Recovery from Failures

When software is released to the market, developers often start working on their next project. So, they usually don’t have any motive to predict or prevent future problems related to software; it’s all up to the operations team. But DevOps keeps developers involved during the entire life cycle of a software product for updating any feature or application, which results in improved quality code. Also, it requires only a few fixes as developers can track and eliminate potential problems while writing code.

As developers work with smaller chunks of code, when a failure occurs in any product, bugs can be tracked easily to their resources. Also, human errors are reduced thanks to the automation that DevOps provides to the software life cycle, while allowing companies to deliver fixes faster.

Best Practices for Using DevOps

Just like agile approaches, DevOps doesn’t have any pre-planned implementation model. But, most companies that use DevOps follow these best practices:

Set a Business Standard

The improvements in an organization can never be measured without having a business standard. If you want to reduce time to market for your software development process, then have a look at the current development process and find out which areas need improvement. For example, you can review the steps involved in making a project live and identify any defects, inefficiencies and constraints in the project.

After reviewing these processes, you can set a business standard that shows the current software development process and the improvements that are required to reduce the time to market. With DevOps, you can set a business standard more quickly and improve your software deployment process.

Optimize and Eliminate Unnecessary Inputs

While reviewing your software deployment process, you might encounter some inputs that don’t add value to the process and reduce its speed. Eliminating such inputs from the development process is crucial, but make sure there is open communication between you and your team so efforts are not wasted.

What you can do is set up the right team structure and use tools that provide transparent and fast communication between the teams. For example, you can structure a team that includes marketing managers, right analysts and, most importantly, DevOps resources.

Allow Continuous Deployment in Software Process

Continuous deployment is one of the essential key factors of DevOps that helps in reducing time to market. It is the continuous delivery pipeline that doesn’t involve any manual intervention in-between. In continuous deployment, automation stimulates and simplifies communication and validates the software process to ensure timely releases.

However, not every company implements continuous deployment in its software development process. Usually, the organizations that need to move faster to provide new features, applications or security channels for their product use continuous deployment. For example, media companies and online retailers use continuous deployment in their software development process.

Improve the Quality of Automated Tests

One straightway to reduce time to market with DevOps is improving the quality of automated tests. In any organization, testers test the application for its functionality and other factors. But this testing process can be enhanced by engaging with clients and a targeted audience in the development process. Taking input on the overall functionality and user interface will not only improve the testing process, but also help you find bugs and defects earlier.

It is proven that if bugs are not tracked and eliminated in the early stages, it can greatly impact the time to market for your software product. For example, if you want to test your web application browser compatibility, then consider cross-browser compatibility testing. With end-to-end automated testing, the overall testing process can be improved, which will result in reducing time to market. Some other benefits of automated testing that can improve your DevOps are:
- Track and eliminate bugs and errors in the early stages to improve the system’s capacity.
- Improve the security of your software product.
- Enhance custom engagement and satisfaction with a high QoE score.
- Less cost of ownership.
- Meet the industry standards and compliance regulations in a better way.
An improved automation strategy helps move your product to market faster and allows your resources to do more high-value tasks. Also, the development teams will be more encouraged and confident to add new features to the application, as it will be tested more thoroughly.

Conclusion

Today’s businesses heavily rely on applications to collaborate, communicate, complete sales and operate more proficiently. Therefore, they strive to bring these applications to market more quickly so they don’t miss any opportunities and easily adjust to the market standards. To achieve these objectives, organizations must adopt the right DevOps practices in their software development processes to reduce time to market.

— Junaid Ahmed
May 1, 2019
Embedding Accessibility into the DevOps Process

Calls for accessibility and inclusion are a defining characteristic of current times. Persons with disabilities (PwD), including vision, hearing, cognitive and physical impairments and others, are demanding equal access to virtually all public services and forums they interact with, from transportation to banking and self-service terminals in airports—and increasingly, digital (web and mobile) services.

Ensuring accessibility can help enhance brands and is good business practice. The process can seem daunting but integrating accessibility into DevOps doesn’t have to be overwhelming. There are several simple steps for getting started.

Understanding Your Organization’s Unique Accessibility Motivators

Knowing what accessibility elements you need to test for depends on numerous factors, including your industry and where you are located. For example, U.S. government organizations are subject to Section 508, while telecommunications providers must comply with the Communications and Video Accessibility Act (CVAA). Different scenarios require a nuanced approach to accessibility testing.

The risks of digital inaccessibility are growing far beyond government websites, with the number of Americans with Disabilities Act (ADA)-based web accessibility lawsuits increasing 181% between 2017 and 2018. Since the beginning of this year alone, several well-known brands including Domino’s Pizza and Beyoncé have been sued for web accessibility breaches, bringing the issue to the forefront.

E-commerce sites are often more concerned with lost revenue opportunities, as the average blind person is known to abandon several companies per month due to web inaccessibility. For transaction-oriented sites, inaccessibility translates directly to lost business. Whatever the motivators, building empathy can be a great way to give this mission meaning for developers. Organizations can do this by staging and having developers participate in “empathy events” where simulations are offered and developers can experience first-hand what it’s like to interact with a given website using the same assistive technologies that people with disabilities rely on regularly.

Set Achievable Interim Milestones

Agile DevOps teams emphasize catching defects as early as possible in the software life cycle to ensure efficient, high-quality rollouts. Unfortunately, accessibility testing is often relegated to the end of the process or performed as user-acceptance or usability testing. This type of testing is often manual and can be resource-intensive and expensive.

Organizations only became aware of issues upon hearing from end users encountering problems—or, worse, taking legal action to gain equal access to web-based content and services.

Getting from a manual process to a fully automated and integrated process takes time. We recommend setting achievable, interim milestones that start small and build on early success. Organizations may not know what to tackle first, but some commonly shared examples of achievable first milestones are accompanying all digital videos with subtitles and/or sign language translation (for the hearing impaired) and ensuring that all new UIs are clear of any issues identified by automated tools. Experts and trainers can offer valuable advice on addressing the basics and then building on the success.

Implement Tools

Today’s developers have easier access to more comprehensive accessibility testing tools than ever before. Currently there are tools available for all the major platforms (web, Windows, Android and iOS) and many of these have been open-sourced, making them richer every day. Interactive testing functionality can enable development teams to thoroughly assess the accessibility of products early on in the cycle, while libraries allow these tests to be run regularly as part of the development test automation. A good tool will provide developers with simple remediation guidance and allow them to embark on a learning journey to increase their knowledge and expertise.

Measure, Improve and Automate

Ongoing measurement is the key to understanding whether your accessibility transformation is taking hold. Leading metrics will focus on the change in development practices. These changes will give early indication of end user outcomes. An example of a leading metric is “percentage of new UI code that is clean from an automated testing perspective.”

End user outcomes, while lagging, are important to ensure that the activity is leading to real change. An example of an outcome might be the number and the change in the accessibility-related call center inquiries. A reduction would indicate that fewer accessibility issues are making their way into production. Metrics are strongest when they are presented in a manner that directly correlates to business outcomes (such as customer satisfaction), as these tend to resonate the most with business executives, which helps build the broadest internal support base.

Once you’ve had some early successes, it’s time to expand, and you can keep tackling issues incrementally. Organizations should also focus on continually shifting accessibility testing “further left” earlier in the development cycle to enhance quality while maintaining velocity. The sooner you detect and fix accessibility issues, the less likely these are to become more deeply baked into the software, making them more difficult and time-consuming to undo.

Organizations also should consider replacing interactive and manual accessibility tests with fully automated tests. While manual testing cannot be completely eliminated, automated unit testing and integration testing enable developers to test for accessibility as they code (not after the fact), while automated regression testing ensures live web content and applications stay accessible after changes are made. Automated regression testing is critical for organizations wishing to ship software often while maintaining quality—in some industries such as financial services, a disproportionate number of websites have experienced some level of accessibility regression.

Conclusion

DevOps teams are focused extensively on maintaining exceptionally high levels of software quality combined with velocity. We’ve become obsessed with minimizing the number of bugs that make it into production but may be overlooking one of the key attributes of high-quality software—accessibility.

In most cases, functional testing does not cover accessibility testing. While functional testing determines whether a system is working as expected (i.e., certain inputs generate certain outputs), accessibility focuses on ensuring usability for PwDs as a non-functional attribute. With estimates that the current number of PwDs in the U.S. nearly equals the total populations of California and New York combined, accessibility testing needs to be prioritized in the same way as functional testing. Otherwise, you are shutting these people out.

In summary, organizations that demonstrate a commitment to accessibility through their digital products and services will have a natural advantage in an increasingly competitive market space. Getting started can be relatively simple, and you should focus on motivating development teams to achieve and overachieve, emphasizing continual improvement rather than perfection from the get-go.

— Dylan Barrell

April 30, 2019
‘DevOoops’ Moves: Unforeseen Lock-Outs
DevOps’ ultimate aim is to create efficiencies in the software delivery process. But it doesn’t always work out that way. Sometimes DevOps initiatives lead to mistakes—something we lovingly call “DevOoops.” CloudBees recently polled some colleagues and came up with five examples of a DevOoops in action. Following is a discussion submitted by Carlos Sanchez, principal software engineer, about unforeseen lock-outs.

Scenario:

When you’re automating deployments using configuration as code, make sure you have the right protections in place (i.e., validation of configuration). Otherwise, it’s easy to lock yourself out, forcing yourself to manually log in to each machine to fix it when a bad change is pushed and deployed to all the machines.

Having a strong technology solution that securely and centrally stores credentials for the names of people who access those machines is critical to maintaining a successful DevOps program. It’s a no-brainer. When you have to service accounts, you’re much more likely to be able to leverage a fast-acting script to log in and reconcile logouts if credentials are centrally stored than if you had eight individually managed service account-based credentials.

How do you reconcile lock-outs? How do you avoid the kind of DevOoops situation that can derail all of the good progress you’re making? The process you adopt will depend on what your software development and deployment life cycles look like. Here are several potential approaches:
- You can use multiple staging and preproduction environments that share common configurations with the production environment. This sets up a process where, before you try to deploy an app or a new configuration to your production environment, you know you have successfully deployed it to environments that are as close as possible to production, multiple times.
- You can have post-deployment validation scripts run after every deployment and have them validate things such as, Can account X log into environment Y? The scripts should include common or leading indicators of success or failure of a deployment. Once artifacts have been deployed and the system starts, every deployment will immediately run these scripts as part of the deployment process. So, every part of the deployment is automatically validated as success or failure.
When taking an approach such as rolling deployments, you also need to ensure that broken configurations are identified before they’re propagated across multiple servers or server clusters. This means you need to validate your deployment and your configuration changes before you go to production, validate deployment and configuration changes on first deployment and then validate, validate, validate at each subsequent step.

By doing all of this, you avoid surprises. You extend a quality-first, continuous validation approach beyond just your application code and apply that to your environment. Avoiding unnecessary lock-outs will help you mitigate risk, eliminate wasted time and avoid bad customer experiences.

Takeaways
- As you bake quality into the processes and shift automation left, you need to make sure you validate all changes early and often.
- Organizations need to implement proper processes, not only for application code changes but also for infrastructure as code changes that manage environments.
- In automating in pursuit of DevOps, it’s necessary to have a strategy for credentials and secrets management of permissions for your DevOps and production systems.
— Brian Dawson
April 30, 2019
Guess Who’s Coming to JFrog swampUP?

The annual DevOps gathering and JFrog user conference, swampUP 2019, is going to be here before we know it. It’s happening June 17-19 in San Francisco, providing easy access for everyone (it’s just 30 minutes away from SFO airport).

What’s swampUP? For the thriving DevOps community, swampUP is the must-attend event where developers, engineers and business leaders from top companies and industries network and share best practices for software delivery success.

While conference promotions can certainly be full of fluffy cheerleading at times, one thing I’m especially excited about is this year’s swampUP guest keynote speaker, Dr. Nicole Forsgren.

Dr. Forsgren, described as “snarky” by Forbes—a label she readily owns, if you ask—is the co-founder of DevOps Research and Assessment (DORA), which was recently acquired by Google Cloud. DORA quantified customers’ unique needs and DevOps processes to deliver custom paths to DevOps growth.

Coming to swampUP as herself—not that she could come any other way, but not as a representative of Google—to talk about her unique research and the overall landscape. She’s planning on covering many of today’s hot topics, including DevSecOps, cloud and hybrid, tooling trends and DevOps culture in a special keynote aptly titled, “DevOps: It Only Works When You Do it Right.”

If you don’t know Forsgren or haven’t seen her speak, her style and unique perspective perfectly blend data and statistics with understanding of realities that companies face. A bit about her specifically: Forsgren is co-founder, CEO and chief scientist at DORA. She is best known for her work measuring the technology process and as the lead investigator on the largest DevOps studies to date. She has been a professor, sysadmin and performance engineer. Her work has been published in several peer-reviewed journals. Nicole earned her PhD in management information systems from the University of Arizona, and is a research affiliate at Clemson University and Florida International University.

Once attendees get knowledge laid on them from Forsgren, there are some intriguing sessions available in the recently released full swampUP agenda around Cloud Native DevOps, Enterprise DevOps, DevSecOps and even some really cool-looking stuff around IoT. While this may be a JFrog user conference, there are some heavy hitters involved that make this a holistic DevOps gathering, including Andy Glover of Netflix, Aaron Schlesinger of Microsoft, Jayne Groll of the DevOps Institute, Carl Quinn of Zoox, Seth Vargo of Google, Jessica Deen of Azure and John Willis of Botchagalupe, among many other powerhouse speakers.

Of course, you’ll also see the expected lineup of JFrog experts, staff and visionaries swampUP attendees have come to know, including JFrog co-founder and CEO Shlomi Ben Haim, co-founder and CTO Yoav Landman, co-founder and chief data scientist Fred Simon, CPO Dror Bereznitsky, VP of business development Kit Merker and many more. There will be a few special additions this year, including former CEO of recently acquired Shippable Avi Cavale and JFrog VP of technology Ido Green.

From hands-on training to inspiring keynotes and practical technical breakout sessions, swampUp is seen by alums as a premier opportunity to learn about DevOps, DevSecOps and cloud-native delivery. There’s also a full day of training and certifications for practitioners of all levels to take advantage of!

Click here to register and join JFrog and the DevOps community at swampUP 2019.

— Jens Eckels

April 26, 2019
XebiaLabs Injects Predictive Analytics Into DevOps Platform

XebiaLabs is moving to take the guesswork out of DevOps following the launch of a set of tools that leverage machine learning algorithms to predict when and how the release of an application is most likely to go awry.

The Risk Prediction Module being added to the XebiaLabs DevOps platform comes on the heels of XebiaLabs’ move to make its XL JetPack software for automating application deployments available on the Amazon Web Services (AWS) Marketplace. XL JetPack is an automation framework based on YAML files and a declarative programming framework that enable DevOps teams to push applications into production on a cloud platform in as little as 15 minutes.

XebiaLabs CEO Derek Langone said that while DevOps advancements have been made in terms of achieving continuous integration, the goal of achieving continuous delivery has proven to be more elusive. As automation frameworks such as XL JetPack become more accessible, however, IT operations teams will be better able to keep pace with the rate at which organizations want to be to deploy and update applications, he said.

It’s becoming increasingly apparent that a combination of automation frameworks and machine learning algorithms will enable DevOps teams to make a significant leap forward in terms of application release lifecycle management. Because of all the nuances of the different platforms that IT organizations are trying to leverage, it’s become a major challenge to roll out an application manually. As the number of applications that need to be released at roughly the same time increases, managing the release cycle process is moving beyond the capabilities of an IT team made up of mere mortals.

The Risk Prediction Model from XebiaLabs promises to increase the odds of success by applying predictive analytics infused with machine learning and other proprietary XebiaLabs algorithms to identify DevOps bottlenecks before they are encountered. Capabilities provided by that module include alerts that warn the team when a release is likely to be delayed or to fail before the release pipeline starts running; a Risk Forecast view that summarizes predicted delays and failures for every task in the release process; an overview of statistics for similar releases to provide historical context; and forensics tools that uncover flaky automated tests, problematic build setups, long-running deployments and time-consuming manual tasks. That Risk Prediction Module is meant to complement the risk scoring capability that XebiaLabs already includes in its platform.

Arguably, the biggest barrier to DevOps adoption today continues to be the level of expertise required to succeed. But as the combination of predictive analytics infused with machine learning algorithms and algorithms that can discern instantly how changes to the IT environment will impact applications become more common, the level of expertise required to master DevOps processes should decline. As that transition occurs, the number of organizations embracing DevOps more broadly should increase.

In the meantime, DevOps teams would be well-advised to consider to what degree they might next want to rely on predictive analytics to prescriptively automate processes with eye toward eliminating the need for as much human intervention as possible.

— Mike Vizard

April 17, 2019
Building Amazing Apps, Part 3: Optimizing the Network
This is part three of a series of three articles on building and delivering amazing apps at the edge. Read part one here, and part two here.

Introduction

There are millions of apps available today, and it’s incredibly easy for any user to download and install any of them with just a few taps on a screen or click of a mouse. If you want to build and deliver an app that will amaze users, you need to be able to differentiate from the rest of the pack.

Over the past 14 years, I’ve been working closely with the top companies delivering the most popular apps, helping them optimize their apps for speed and scale so users get a great experience. In this three-part series, we’ll explore the fundamental steps you must take to build and deliver your own amazing app at scale that will keep users coming back for more.

We’ll break these steps down into three key areas:
- Front end: Covers the parts of the app that end users interact with.
- Back end: Looks at the required origin infrastructure to support the app, including databases, application, web servers and more.
- Network: The glue that connects the front end and the back end.
In the final article of this series, we’re going to explore four things you can do on the network to optimize your app and make it more amazing:
- Distributed DNS
- Protocol optimization
- Latency optimization
- Edge computing
Distributed DNS

The Domain Name System (DNS) is a critical part of making sure your clients can access your applications (in fact, it’s a very popular attack vector by hackers today because if your DNS is down, nobody can access your PPP). Distributing your DNS across many servers can help ensure that your DNS (and thus, your app) is fast and highly available, so you should use a DNS vendor that has a large DNS server network in a wide range of locations.

Validating whether you have a properly distributed DNS infrastructure is rather easy. Just follow these steps:
- Identify how many name servers your domain uses and their IP addresses. Ideally, you want a number between three and 12—the more the better. You can use command-line tools such as dig and nslookup to identify the name servers of a given domain.
- Use an IP geolocation system to find out the physical location of the name servers. At this point, you can get a rough idea if those servers are close enough to your end users. Hint: Some CDNs offer diagnostic tools that can be scripted via APIs to automate IP geolocation.
- If you want to be more thorough, you may want to run connectivity tests between the main locations of the users and the name server IP addresses to make sure the network latency—i.e., how long it takes for information to go back and forth between the client and the server—stays under 100 ms (the lower the better). Some internet providers and CDNs provide looking glass technology, which enables you to run connectivity tests that originate from servers around the world.
Protocol Optimization

Once your clients know where to connect, how they connect and the protocol used is something that shouldn’t be neglected. HTTP/2 is the modern, superior network protocol, as it uses a more efficient binary format, header compression, single network connection, stream multiplexing and server-push. Actually, I was very involved in the early years of HTTP/2 (the standard was approved in February 2015) and have since helped some of the largest websites on the internet implement HTTP/2 and still spend a considerable amount of my time testing the new protocol in all sorts of environments. I’ve shared my findings in talks at conferences including Velocity and in the “Learning HTTP/2” O’Reilly book, which I co-authored. In a nutshell, most sites can improve page load performance between 5% and 15% by just switching the protocol from HTTP/1.1 to HTTP/2, which is as simple as flipping a switch if your website uses HTTPS.

To illustrate that improvement, I created a demo site that tests the download speed of many small images over HTTP/1.1 and over HTTP/2 and displays the differences.

Figure A

As you can see in Figure A, the content loaded eight times faster over HTTP/2 than over HTTP/1.1 on my mobile phone over an LTE connection. That’s a huge improvement considering how simple it is to implement HTTP/2.

According to the HTTP Archive, as of June 2018, 20% of hosts support HTTP/2, but those hosts are responsible for 40% of all requests—meaning HTTP/2 powers some of the web’s most popular sites.

However, as explained in the HTTP/2 Performance chapter of the Learning HTTP/2 book by O’Reilly, there are a lot of factors that can impact the benefits of HTTP/2. Some of them you can control, while others—such as network packet loss—are much more difficult to tackle and can impact HTTP/2 performance because HTTP/2 runs over a single TCP connection.

Note: TCP stands for Transport Control Protocol and some parts of its implementation (e.g., slow to start and cumbersome network congestion algorithm) can impact HTTP/2 performance because all the communication with the server goes through a single TCP connection.

The future of the web is HTTP/3, which uses HTTP/2 over QUIC (a newer and more efficient transport layer protocol). However, as of April 2019, HTTP/3 is still in draft state and hasn’t been approved as a standard.

Ideally, your servers should monitor the network connection and use different network protocols depending on the current conditions. Certain content delivery networks (CDNs) offer this functionality. For example, to maximize throughput, a top CDN provider uses custom software on its edge servers to dynamically use different network protocols, TCP settings and congestion control algorithms, depending on the specific conditions of each individual connection the server makes with an end user. In short, using the optimal protocol makes your app faster and more amazing.

Latency Optimization

Latency is a physical limitation of nature that impacts the throughput on computer networks. You probably know that whenever you are outdoors and there is a storm with lightning, you can count the number of seconds until you hear the thunder to identify how close the storm is (and if you count less than a second, you better get inside!). In computer terms, latency is measured as the time it takes to send a network packet back and forth between two systems. This concept is known as round-trip time (RTT) and is typically measured in milliseconds. You can use network tools such as ping or mtr to easily measure the RTT between two systems.

Latency has a huge impact on performance because the further away you are from the server you want to connect, the slower the communication will be. As a rule of thumb, you want to ensure your latency is well under 100 ms. The easiest way to achieve that is by leveraging the local device cache to avoid extra network connections to the server and using a CDN to put your server closer to the end user.

Here is a graph (see Figure B) showing that latency plays a larger role on page load time than bandwidth. As you can see, doubling the bandwidth from 5Mbps to 10Mbps results in just 5% improvement in page load times, and any bandwidth increase over 10Mbps doesn’t make a big difference. Reducing the latency, however, drastically improves the page load times. That makes your app more amazing for your end users.

Figure B

Edge Computing

If you are a developer or a DevOps engineer (or just love tech) chances are you are within the TOP 1% of world population in terms of mobile computing power. But things you take for granted, such as resizing images on a mobile phone, are going to take much longer for many millions of internet users who have less powerful mobile devices.

So, what can we do if running logic at the origin causes delays because of the network latency and running logic on the client side may be too slow on less powerful devices? The solution is edge computing, which consists of moving the origin logic to a server close enough to the end users that latency does not impact performance. CDNs are in the best position to offer this proximity because of their natural distributed architecture; a CDN can set cookies, rewrite HTML and resize and deliver optimized images for the screen size of your users so those images don’t take a long time to display on low-end mobile devices with limited CPUs.

Edge computing is the next step beyond cloud computing. You should try to use a CDN company that offers you the ability of running business logic as close as possible to where your users are, to ensure that your app is fast and can scale without impacting your infrastructure.

Summary

In this series of articles, we reviewed some basic things you should consider if you want to build and deliver amazing apps at scale. This is not a comprehensive list of all the things you can do but provides you with some of the most impactful areas for app improvement.

— Javier Garza
April 17, 2019
Monitoring the DevOps Toolchain
DevOps has grown in popularity among many companies seeking greater agility and higher-quality code. When using different tools for automation, these organizations need monitoring and tracking of these tools and metrics from different portals on a common dashboard. Toolchain monitoring helps to bring all reports into a common portal.

Enabling monitoring tools from a centralized platform can save a lot of effort and time. These tools have many in-build capabilities that bring value to the business, such as predictive alarming, graphical representation of data and integration with other tools including email, ticketing system and auto remediation. These added features become game-changers in today’s competitive SLA-driven and standard environments.

Monitoring can be categorized in three ways:
- Infrastructure monitoring: Monitoring the environment, machine and resources used to create a platform for an application.
- Application monitoring: Monitoring the application’s performance, resource consumption, processing time and responsiveness.
- DevOps monitoring: Monitoring the pipeline and toolchain from continuous exploration through release management. DevOps monitoring tools have the capability to monitor job health, job status, performance and quality.
Why DevOps Monitoring is Essential

In DevOps, we use many tools to create a toolchain and pipelines. In some big teams with a long release train, monitoring a project’s status from requirements-gathering to deployment can be difficult, as you have to track a number of different tools. And even then, you might not get the status in a desired format. DevOps monitoring tools bring everything to one single dashboard, where you can see the status and other metrics, including useful information about the project quality and progress.

DevOps Monitoring: Not the Same as Tools Monitoring

Tools monitoring is specific to the health and performance of tools; DevOps monitoring focuses on things such as the status of sprint, code quality, code branch status, test results and deployment status. All of which are required by project management for continuous improvement in productivity and quality.

What to Monitor?

There are a number of things we want to monitor in DevOps orchestration, and all these metrics provide a perspective of the current status of the project or product development and productivity:
- Performance: Performance of the application.
- Development (sprint or Kanban progress) and defects status from the application lifecycle management (ALM) tool.
- Code repository monitoring for a project specific branch.
- Build job or pipeline monitoring from the continuous integration (CI) tool.
- Code analysis and security test results and reports.
- Deployment and upgrade status in different environments.
- DevOps maturity using the tools’ usage and quality data.
- Artifacts (versioned artifacts).
These are the basic and mandatory areas any project would monitor on a single dashboard.

Monitoring Use Case

In agile projects, CI/CD tools are implemented following the best practices of DevOps. An ALM tool is implemented to manage the backlog and development sprints. On this project a CI tool is used to build code and all the code is getting committed in a code repo, using a code review and analysis tool. A binary repository has been implemented to store all the binary of every version. An automated deployment tool is being used to deploy the application in QA, staging and production environment.

Now the struggle comes when monitoring each tool, the status of the build and the progress on different portals (CI tool, code repo, analysis tool, deployment tool, etc.).

Using centralized monitoring tools can help project management to monitor the metrics mentioned below. These metrics give the overall picture of build, quality and deployment status on one dashboard.

Available Tools for DevOps Monitoring

Below are few available products that provide similar solutions:
- Hygieia: Freeware tool that supports all DevOps tools, but metrics are very limited.
- KlipFolio: Has lots of tool support, but it’s not free.
- DevOps Insights: An IBM tool that supports IBM cloud platform only.
- DataDog: Has a wide range of tool support, but it’s not free.
- Prometheus: Freeware tool that monitors lots of tool-using exporters.
Build vs. Buy

Deciding which tool to use is always a tough task—you need to compare all the available tools and their offerings from different perspectives. Below are a few factors that play an important role when deciding on available options or to build your own solution:
- Range of supported tools (plugins or data collectors).
- Freeware or paid.
- Support to customize data collection.
- Rich UI for data representation and customization of fields and views.
- Range of metrics supported.
- Ease of installation and configuration.
- Licensing and distribution policy.
Solution Approach for Building Your DevOps Monitoring

If you have decided to build or extend any existing tool, below are some considerations:
- Identify the tools you have to monitor: List the DevOps tools you have to monitor; the list should cover all the areas of DevOps (build, repo, code quality, deployment, monitoring, etc.) to get the complete picture.
- Identify the metrics: Once you have the list of tools, identify the important metrics from each tool. Your metrics should be capable of providing KPIs of DevOps areas.
- Identify API or command-line interface to fetch the metric data: You need a good understanding of tools and their implementation to identify the best way to fetch the data. It could be predefined APIs, REST APIs or any command line interface. Make sure you are getting all the desired data.
- Correlate the metrics with the business value or define the DevOps KPI: Your metrics should represent the KPIs and business value of all the tools involved in achieving DevOps. The dashboard should cover all the aspects and represent the current status and gaps.
- Determine how to store and process those metrics: You need to define the schema to store the data in defined database; your schema should be generic enough to cater any data from different tools. To process the data, you need a middleware component between database and UI to process in a presentable format.
- Build a scoreboard based on metrics: Use a rich GUI to display the scoreboard in different formats such as table, graphs and charts.
- Support high availability: The tool should be designed to support high availability to avoid downtime and loss of data points.
How Monitoring Tools Collect Data

Most of the tools we use for implementing DevOps and CI/CD are web-based tools such as Jenkins, Sonar, Git, SVN, UDeploy, Gerrit, Jira, Confluence or others. These tools provide REST APIs, from which we get the data in a described format—either in json or xml. Some tools support predefined APIs or CLIs to connect and fetch the data. Once you identify the communication mechanism with the end system, the next step will be writing robust code that can fetch the desired metrics data and handle all the cases to parse the data and put it in a relational or non-relational database.

Once you have the data in the database, you need a GUI to display those in tabular and graphical formats and a middleware component that can fetch the data from the database and provide it to GUI in the desired format.

Getting the data from the system you want to monitor is the real challenge in this whole exercise, as everything else depends on it. Below are a few challenges you might face while developing a toolchain monitoring system:
- Identify the API or any other mechanism to fetch the data.
- Identify the metrics to monitor.
- Identify how you want the data to be presented on the GUI—whether a trend chart, pie chart or just tabular presentation.
- Determine the authentication mechanism for the monitoring system, as each supports a different kind. Sometimes it needs a predefined token while other times a token needs to be generated at runtime.
Simple Architecture of DevOps Pipeline Monitoring

Below is the simple generic architecture, on which most of the monitoring tools work. In the picture below, the different DevOps tools are on the left side; these tools are the end system from where we want to bring the data. Only a few tools have been shown as an example.

A data collector brings the data from each end system and communicates with the end system using a REST API or any API exposed by that tool or a CLI, depending on the case. Using the defined communication mechanism, it will bring the data and pass it to the parser to fetch the required data and put it in the database in the desired format.

While developing data collection, you need to have good a understanding of the tool you are going to monitor as well as available APIs including REST, CLI, SMIs or any pre-defined API built within the tool.

The data parsing layer will fetch the desired metric value from the raw data collected by the data collector. Raw data could be in any format, including key value pair, json, xml or csv. The parsing methodology will differ in each case depending on the type of data. You can use any generic API for the parsing available.

You must identify a good API to parse the data available in a different format and complexity.

The database will hold the metrics data of each interval for each tool and user credentials.

The GUI will request the data from the parsing component. It will represent it in tabular or graphical user-friendly format.

Other features: Once we have data, we can have the trend chart to make some critical decisions, we can generate alarm on breaching any defined thresholds and integrate it with email or SMS to take immediate action.

Monitoring Tool High Availability

If we are relying on our monitoring tool to get reports of all the tools used in DevOps, we cannot afford downtime. We may lose data points and trends if the monitoring tool goes down, and management may not get the actual status of an entire project without having to gather the data manually.

To avoid such situation, high availability (HA) should be implemented on the monitoring tool. In case of a HA setup, we will keep gathering the data in case the monitoring node goes down.

To implement the HA, there are two aspects we need to consider: the HA of GUI and middleware (business logic component) and the HA of database.

HA in the GUI and middleware could be achieved using an Apache or Nginix cluster. In the case of containerized environments, we can use any orchestration platform’s default feature to achieve high availability, such as Kubernetes. Similarly, in the database we can implement a clustered database feature provided by the most of available databases.

Conclusion

DevOps toolchain monitoring is very useful. It provides a good snapshot of the health of a project to management and is able to identify any blocker issues that might impact the release so they can be corrected. Monitoring can help identify pain points to focus on in defining the road map. Organizations following DevOps practices and using DevOps tools should have a tool to monitor the DevOps pipeline.

— Prateek Kumar Asthana
April 15, 2019
5 DevOps Trends Worth Knowing in 2019
DevOps today is more than the buzzword it was 10 years ago. Back then, the idea of combining development with production in your IT infrastructure was not common; the logistics were nonexistent and most of the time businesses decided it was far too much effort.

However, if the last nine years has taught us anything, it’s that DevOps is worth every penny businesses invest. It helps companies streamline production, keep customers happy and provide agile services to attract new audiences.

But as with anything in the IT field, there is a paradigm of change. This article discusses some of the top DevOps trends happening now and how to implement them in your own system.

Automation Will Be a Bigger Focus

Automation has always been the way for businesses. Whether it’s speeding up the pipeline with machines, providing better response times for angry customers with chatbots or better inventory management with tracking and logging system, automation is behind it all.

DevOps is no exception.

But as with everything, there can be too much automation. The best thing to do is break down processes and find simple, redundant tasks that can save time if automated and apply the changes.

The most important aspect of automating DevOps is to understand the six pillars in the DevOps cycle, which are:
- Continuous business planning
- Collaborative development
- Continuous testing
- Continuous release and deployment
- Continuous monitoring
- Collaborative customer feedback and optimization
DevOps Assembly Lines: The Next Big Thing

To track the development of your application, we have pipelines. These visually represent the product from its initial stage right through until final development and release.

However, continuous integration (CI) is no longer the priority focus when it comes to effective monitoring and implementation. Continuous delivery and automation are a major part that businesses have already started delving into in 2019.

This is where DevOps assembly lines enter the picture.

Assembly lines are focused on bridging the gap between manual and automated tasks, ensuring there is no redundancy while providing several tools for teams to implement, to ensure apps are hitting the production lines as reasonably quickly as possible.

Microservices Architecture Adoption Taking Off

Microservices architecture may as well be that new kid in school trying to fit in. These smaller services compound into agile, implementable tools that DevOps teams can use to scale and test software over the course of weeks—not years.

As you can imagine, this can help some businesses streamline their development and production lines, setting them way ahead of their original production estimates—which is never a bad thing.

Implementing microservices into your DevOps team can also help companies focus on the runtime and efficient delivery of new development sources, without the hassle of creating dependency errors when something decides to bug out for no apparent reason.

Security Needs to Step Up

Cybercrime is on the rise—we all know that’s old news. But as a business, cybercrime can either make or break your sales and weigh down your DevOps team.

That’s why more companies are hopping onto enterprise security options. Although there are third-party programmers for almost every situation you need, none of them have the same security levels as the tools from the enterprise version provides. Safeguarding both your company and your clientele.

Riding the Artificial Intelligence Wave

Finally, we have artificial intelligence (AI) and machine learning (ML). When you think about it, these two elements are literally the sum of everything we want in the DevOps community—the ability to crunch out hours upon hours of menial labor and saving your teams hours to focus on higher-priority tasks.

The combination of AI, used to predict algorithmic influencers, and ML’s ability to adapt to new situations will be key for DevOps teams to get to the next level in 2019.

— Gil Artmoore
April 11, 2019