devopsy.kinsta.cloud

Author: contributor

  • How to Ensure DevOps Success in a Distributed Network Environment

    How to Ensure DevOps Success in a Distributed Network Environment

    Data-centric applications are not typical, and the environment where they’re deployed are also not typical. Most often, they’re deployed into large, distributed network of machines, which compels the question of whether DevOps practices and tools can be applied to distributed applications.

    To be successful, DevOps practices for data-centric applications must work smoothly even when production environment is a distributed network. For that to happen, developers and testers must define best practices for DevOps as well as continuous deployment into these distributed network environments.

    Can DevOps Work in Distributed Environments?

    Let’s say you’ve adopted a distributed network environment for your data-centric application production environment. Unless you’re able to successfully and rapidly develop your application for such an environment, it’s a wasted effort. Although DevOps is the solution, how many DevOps tools allow you to develop applications in distributed network environments?

    Here are three critical steps to ensure DevOps success in a distributed network environment:

    1. Containerize applications
    2. Use DevOps tools to enable a continuous DevOps life cycle
    3. Use sandboxes throughout the DevOps life cycle

    Why are they important? The above three steps help you address the what, how and where aspects of your data-centric DevOps problem:

    1. The What (Containers) —A distributed network environment, most likely, is heterogenous and consists of different types of systems and applications. Putting your application within containers will make them look uniform and allow you to easily move them from non-production to production environments, as well as from on-premises systems to cloud.
    2. The How (DevOps Tools) — To rapidly develop your application you’ll need to quickly iterate through the program-test-deploy cycle. DevOps tools help automate these steps.
    3. The Where (Sandboxes) — Sandboxes help you decide where you develop your application so that its infrastructure and environment looks the same whether you access it from development lab, or testing lab, or production data center or anywhere else.

    Of these, two steps are common to both data-centric and non-data-centric environments. Containerizing applications is definitely important to data-centric applications whose requirements don’t seem to affect DevOps tools much. Nevertheless, the DevOps practices still apply fully.

    However, the data-centric environment is quite different from a typical application environment. This makes sandboxing for distributed network environment all the more essential for data-centric applications.

    Playing in the Sandbox

    Sandboxes (also called uber containers) are basically self-contained infrastructure environments that can be not only configured to look identical to your final target deployment but also created and run from anywhere.

    Developers, for example, can create a sandbox that looks exactly like their production environment—hardware, network, OS versions, software and even cloud APIs. Sandboxes can be spun up so developers can do their development and then torn down when they are done.

    Similarly, testers can create a sandbox that looks like their internal IT environment to run a bunch of tests and then re-configure it on the fly to look like their external cloud environment so they can run some more tests. This will enable them to test all possible environments that the application could run in, without actually disrupting the production infrastructure.

    So, what, technically, is a sandbox?

    A physical sandbox is a protected space where you have complete control and others are allowed only by your invitation. You can build whatever you want with the sand and even bring your own toys into it. If you don’t like it, you can always start over.

    Similarly, a technological sandbox provides a controlled environment where you can build and test what you want without disrupting what’s outside the environment. You can even install your own software (bring your own toys) to create the desired environment for your application.

    In fact, a number of vendors are now offering sandbox solutions (also called “environment as a service”) that provide a simple interface for creating any target infrastructure environment and configuring it with any control you want. You can bring applications, tests, tools and automated processes to your sandbox. User access to your sandbox is highly controlled so no one can mess up the infrastructure that you are currently using in your sandbox.

    You can even reserve and schedule sandboxes so that whole teams of developers and testers can share the infrastructure for hours, days and even weeks at a time. These sandboxes can be triggered even from the outside, right from your DevOps tools.

    If you’re developing a data-centric application such as an internet of things (IoT) application, it needs to be deployable on distributed network infrastructure. Sandboxes provide a great way to mimic these complex, large-scale environments and allow developers to build applications that can run in this type of environment.

    Wrapping Up

    Ideally, it is possible to combine containers, DevOps tools and sandboxes to enable continuous deployment in a distributed network environment. The key is to package your application in containers, use DevOps tools to automate the process of moving through the various stages of your development cycle and create sandboxes to mimic the target product environment required to run those applications.

    About the Author / Sreeram Sreenivasan

    For more than eight years, Sreeram Sreenivasan has worked with various Fortune 500 companies in areas of business intelligence and sales and marketing strategy. He’s the Founder of Ubiq BI, a cloud-based BI platform for SMBs and enterprises. He’s also the editor of Fedingo blog, which covers a wide range of business growth topics.

  • Dissecting the Role of QA Engineers and Developers in Functional Testing

    Dissecting the Role of QA Engineers and Developers in Functional Testing

    Until a few years ago, quality assurance was generally considered low-level R&D. As a result, quality assurance (QA) teams were characterized by a low budget, lack of attention and, more often than not, poor attitudes. Moreover, QA engineers were considered the enemies of developers and the product.

    However, today, this is no longer the case, and QA is part of the entire software life cycle. Today, organizations understand how a product’s quality affects the brand’s reputation and customer retention. In the Agile ecosystem, QA engineers are no longer solely focused on testing; they also fill an important role in the planning and delivery domains. The shift left approach—where testing is performed earlier in the life cycle—requires QA engineers to have higher technical abilities and involvement in the whole CI/CD process. Nevertheless, QA managers, who usually encourage assimilation in the scrum team, as well as rapid feedback for user stories and automation, must not forget the main objective of quality engineers: to ensure a high-quality product and a seamless user experience for customers.

    High quality demands testing and verifications. There are different types of testing that can be conducted to meet quality goals. In one of its blog posts, Testing Excellence describes almost 60 types of testing that can be performed on a product. We’re going to look at one that is quite clearly one of the most important types of testing: functional testing.

    Different than other forms of testing, functional testing is considered one of the most sophisticated test type, and the most comprehensive one.

    Same Team, Different Responsibilities

    One important fact every QA engineer must remember is that developers develop and QA engineers test. Even though QA and developers are part of the same scrum team, their work, methodologies and state of mind are completely different. In cases in which the significant contribution of QA isn’t visible to the whole team, testing might be considered an easy and clear task. Quite the contrary; testing an application is much more complicated and entangled than developing it. When planning tests and executing them, QA engineers must take into account several aspects developers likely never consider.

    Understanding How the User Thinks

    The primary distinction between dev and QA is state of mind. While developers write pieces of code that later become features in the application, QA is expected to understand how real users think, engage customers to learn business scenarios, and confirm that the application satisfies customer needs.

    Let’s look at eBay, for example. Every veteran R&D member will agree that eBay isn’t just a simple shopping application, but a comprehensive system that includes a whole set of capabilities on both web and mobile that requires attention and deeper understanding to determine whether they really function correctly. In such a rich and mature online platform, we can identify several types of users and many cases in which the application may be utilized. A seller performs different steps than a buyer and requires different functionality, while a support agent needs an entirely different version of the application. When planning tests, all these personas must be taken into consideration with a particular test plan for each. In other words, testing functionality is not just simulating user operations.

    In addition, eBay is not a standalone application—its web application lives inside the browser and subsequently depends on that browser’s rules and behaviors. This is true for eBay’s mobile apps, as well, which must meet the OS constraints to function correctly, whether it’s navigating to the seller’s store or making a purchase. This makes compatibility testing an integral part of functional testing. Most developers don’t think about the project availability matrix when they code, so QA is required to contemplate all the ways the customer will engage with the application and verify functionality for each.

    Viewing the Application as a Whole

    Dev and QA differ in their point of view—an obvious but important distinction. While developers focus on developing user stories, QA engineers test the user story, the feature it is part of and the application behavior with the new code. Integration testing is a crucial part of the application verification effort and requires a broader view of the application and how the new functionality is part of it. End-to-end testing is the fulfillment of the above two aspects, validating that real user scenarios in the context of multiple regions in the application behave as expected. End-to-end tests increase test coverage and reduce the risk of making the new code part of the application.

    Paying Attention to User Experience

    As noted, testing the application functionality is merely one step in functional testing. Testing the operations available in the application encompasses another type of testing—the user experience. If a new feature is developed, but users do not have easy access to it or cannot understand how to use it, it is as if the feature doesn’t exist. QA engineers must incorporate user experience as a main metric of features so users will not have room for error, which can lead to misuse and frustration.

    For instance, eBay’s “all categories” page previously displayed all the categories by default, even though some of the categories had no items. While this was the correct behavior from a functionality standpoint, it caused user confusion and mistrust. Consequently, the “all categories” view was changed to show only categories with items.

    Looking at the narrow current task, developers might implement features as they are told without questioning or contemplating the specifications. In the same way, testers who test features without realizing how customers perceive them are missing an important benefit of the test.

    The above three aspects—thinking like customers, testing the application as a whole and paying attention to user experience—revolve around the way developers and QA engineers relate to new features. While developers tend to follow the specification guidelines, QA engineers must “think outside the box” when it comes to user consumption of the feature.

    There are two other ways in which QA work is more complicated and yet invaluable—test maintenance and test automation.

    Maintaining High Quality Throughout an Efficient Release

    In general, developers split their time between developing new features and fixing defects. QA work is much more diverse. A substantial portion of the release is spent on testing functionality that already has been released and used. While the main effort of designing and writing test plans for this functionality was invested in past releases, every new feature developed requires a test plan and a maintenance effort on existing tests. One of the main goals for QA managers is reducing this effort to a minimum. Teams that succeed in creating clear and reusable tests simplify the maintenance struggle and optimize the test registration time.

    Eliminating Risk Through Automation

    However, for QA, the most cost-effective solution is test automation. At release end—the time when QA is at its most stressed and every commit might introduce a new risk—automation testing can eliminate risk and supplies early feedback on every change. Agile teams strive for the highest automation coverage percentage so the development team can have confidence in committing changes late in the release. That said, developers often aren’t interested in investing their time in automation. They support the QA automation effort, but they don’t want to “dirty their hands” by doing testing. Whether it’s UI automation—during which achieving element uniqueness is essential yet tricky and requires developers’ intervention—or API testing for APIs without proper documentation, QA faces intricate challenges that require sophisticated solutions, which developers are, in most teams, not part of. While the dev team focuses on the status of the new feature, QA attends to the application as a whole with extra attention to identify regressions created by a change.

    Join Forces for Higher Rate of Success

    Testing an application requires a completely different mindset than developing it. One of the main challenges in the Agile methodology is to create developer awareness of quality, involving other stakeholders in the quality assurance activities and making the QA process visible to everyone. QA managers must understand how day-to-day QA work is different than the work of other team members so they may truly represent the complexity, efforts and eventual success. R&D groups that join forces and understand that QA extends far beyond the actual tasks of the QA team have a much higher chance of improvement and set high standards for their product’s quality. Implementing the appropriate methodologies and utilizing the right tools lead to an increase in customer satisfaction and retention rate.

    About the Author / Ronit Eliav

    Ronit Eliav is the Director of Product Marketing at Panaya. With a deep interest in digital transformation and the latest IT trends, she enjoys creating thought leadership around such topics as agile and continuous delivery, DevOps, quality assurance and IT modernization projects. Connect with her on LinkedIn.

  • DevOps Primer: Using Vagrant with AWS

    DevOps Primer: Using Vagrant with AWS

    One of the most common problems in modern software development is the phrase, “It works on my machine,” when a particular piece of code runs on developer’s machine but produces error on other team member’s machine. Thankfully, now there is a plugin that can help determine why something works only in particular environments, turning the phrase into more an observation than an excuse.

    Vagrant to the Rescue

    Vagrant is a tool for building and maintaining portable software development environments. It isolates your project’s dependencies and configuration from your projects without disturbing the tools your application is consuming. You could easily reproduce similar environments on other machines by using the same configuration as your machine.

    Basic Concepts in Vagrant

    Before going further, it is important to understand the following basic concepts that are essential to the working of Vagrant.

    Provisioners

    Provisioners provide automation for installing different software and configurations. It is useful in cases when you don’t want to install software manually to your machine.

    Providers

    Providers provide basic services that are required to run your machine. Although Vagrant provides support for VirtualBox, Hyper-V and Docker, other providers can also be used through appropriate plugin.

    Boxes

    Boxes are Vagrant environment packages that can be copied to any other machine to replicate a similar environment. Vagrant provides a repository of these boxes that can be downloaded, and you can contribute to the list by adding your own customized box.

    Install the Plugin

    The first step in the process is to make sure that you have Vagrant installed on your machine. As I mentioned earlier, you could use providers by installing the respective plugins. For the purpose of this tutorial, I will download the vagrant-aws plugin through the following command:

    vagrant plugin install vagrant-aws

    Next, verify the plugin installation through the command:

    vagrant plugin list

    The vagrant-aws plugin should be present in the plugins list

    Set Up the Vagrant Box

    After installing plugin, the next step is to install a Vagrant box. The problem is that there is no box for AWS provider. To make things work, I recommend you use the dummy box provided by Mitchell Hashimoto.

    Run the following command to add the dummy box:

    vagrant box add aws https://github.com/mitchellh/vagrant-aws/raw/master/dummy.box

    Although I have named the box aws, you can give it any name that works for you. Once the process finishes, I am ready to create AWS instances.

    Create the Instance

    Run the vagrant init command to create a vagrant file:

    vagrant init

    Next, edit the vagrant file as follows:

    # -*- mode: ruby -*-
    # vi: set ft=ruby :

    # Require the AWS provider plugin
    require ‘vagrant-aws’

    # Creating and configuring the AWS instance
    Vagrant.configure(‘2’) do |config|

    # Use dummy AWS box
    config.vm.box = ‘aws’

    # Specify configuration of AWS provider
    config.vm.provider ‘aws’ do |aws, override|
    # Read AWS authentication information from environment variables
    aws.access_key_id = ‘ABCR2NDJKZJIAJ5QVXGJK’
    aws.secret_access_key = ‘WAuZE39lKHXAJnCfbZf2y6DzRfeCsPUU/yZMRDWo’

    # Specify SSH keypair to use
    aws.keypair_name = ‘vagrant’

    # Specify region, AMI ID, Instance and security group
    aws.region = ‘ap-southeast-2’
    aws.ami = ‘ami-14b55f76’
    aws.instance_type = ‘t2.micro’
    aws.security_groups = [‘default’]

    # Specify username and private key path
    override.ssh.username = ‘ubuntu’
    override.ssh.private_key_path = ‘~/vagrant/vagrant’
    end
    end

    Vagrantfile Explained

    The following list explains the important variables and aspects of the above file:

    • config.vm.box : Specify the box. Using dummy aws box for AWS deployment
    • aws.access_key_id : Access key ID of your Amazon account
    • aws.secret_access_key : The secret access key for your Amazon account
    • aws.keypair_name : Your SSH keypair in AWS
    • aws.region : The AWS region in which you want to create your instance
    • aws.ami : The AMI ID you want to use. AMI specifies the information needed to launch a virtual machine within EC2
    • aws.instance_type : The AWS instance you want to create
    • aws.security_groups : Specify the names of security groups that will be applied to your instance
    • override.ssh.username : The username that will be used to access the instance
    • override.ssh.private_key_path : The path of your SSH private key

    Launch the Instance

    After configuring the Vagrantfile, I will simply run the vagrant up command. Vagrant will launch an AWS instance through the AWS AMI provided in the configuration using the credentials provided in the Vagrantfile.


    You can view the newly created instance in the AWS console panel.

    You can now SSH into your AWS instance or perform other Vagrant operations.

    Final Words

    As you can see, using Vagrant to launch a AWS instance is simply a matter of installing the plugin and then launching the instances through easy steps. If you need help with the process, do leave a comment below.

    About the Author / Ali Azmi

    Ali Azmi is Associate DevOps Engineer at Cloudways – A Managed PHP Cloud Hosting Platform. He is skilled in developing PHP applications particularly in Laravel. He is passionate about contributing to open source projects.

  • All Day DevOps, Viewed from the Outside

    All Day DevOps, Viewed from the Outside

    This year was my first All Day DevOps event. I loved it, as much as I was able to attend. I was especially interested in how DevOps worked with government, as I work in state government. We don’t use DevOps. My guess is that if you work in state or local government, your group also may not use DevOps. This may also be true of some federal agencies.

    I’ve not been fortunate enough to work in an organization that used DevOps. So, when I learned of the All Day DevOps event, I had to join.

    I’m a DevOps outsider looking in. Where I work the waterfall project management paradigm is followed, mainly because waterfall includes the word, “requirements.” I’ve been told that scrum and, more generally, agile project management includes the concept of requirements, but they’re just not called that.

    Since we use waterfall, our progress in delivering software solutions is lengthy. I appreciate the need to get a very good understanding of what the users want, but it can be difficult to meet so many needs in a timely manner. Consequently, many users will strike out on their own to come up with a software solution. In our state department, that means using Microsoft Access. Sometimes a division will get someone to write an Access app to quickly satisfy their needs, which they start to use. This works for a while until the demands on the app become too great and they come to IT begging for help.

    I really should mention that not all of this is caused by IT being slower to respond than we would if we were using DevOps. A large part of this is a consequence of not having enough money to purchase a commercial, off-the-shelf software solution, if such exists. Fiscal limitations coupled with a long queue of projects to work on and a project management process that tends to be slower makes for aggravation on both sides.

    Another thing I’ve noticed about my department is that both IT and development don’t work together as well as they could. I wouldn’t characterize it as adversarial—more like just not entirely trusting of each other. This IT/Dev department has more than 200 people throughout the state, so I find it interesting to see how it plays out. Before this job, I worked in a very small organization with just two IT people—and I was one of them. It was easy to coordinate and there was no divide between IT and development. In my current position, however, everyone has their assigned tasks: IT, development, business analyst or security. There is very little overlap. I very much would like to see more.

    When I learned about the All Day DevOps event, I was thrilled with the prospect of being able to learn more about DevOps. Where I work, no one ever travels to any conference, so having All Day DevOps online was a huge bonus. Also, it was free to attend, which was essential. I caught a few of the sessions throughout the day. This may sound trite, but I was awestruck with the idea that All Day DevOps was going on worldwide! This demonstrates just how widespread the DevOps movement is. When I start promoting All Day DevOps to my colleagues, I will stress this fact.

    I understand that All Day DevOps will be done again in 2018. I look forward to that because this year I learned of the event only the day before, which was hardly enough time to really prepare. If you’re like me, working in a government agency—or any organization, really—and you desire to do a better job of providing your users with software solutions they’ll enjoy and in a more timely manner, as well as work better with your colleagues, I recommend that you join in at the next All Day DevOps event. I’ll be there, so I hope to see you there as well.

    About the Author / Rod Falanga

    I’m a longtime software engineer working primarily in the Microsoft stack. Writing applications for both the desktop and web, with some experience in writing mobile apps. I’m also a longtime fan of the BBC’s Sci-fi show, “Doctor Who.” Follow me on Twitter @Doctor_Who.

  • The Value of Commercial Open Source

    The Value of Commercial Open Source

    Adhering to the open source definition enables a large, passionate community to collaborate and share their work, insights and innovations on a given OSS project. Companies working in commercial open source add to that value by turning what may look to enterprises like “raw material” into whole product.

    These combined efforts serve to improve products, while continuing to protect customers from the stranglehold of proprietary vendors. Beyond just open source, adherence to open specifications (such as CMIS in the content services space) and implementing open RESTful APIs provides a treasure trove to developers that they can quickly and efficiently build upon to add new innovative functionality into the solutions they craft to meet specific business needs.

    When vendors employ open thinking at all these levels (open source, open standards, open APIs), there are commercial benefits across the board. The enterprise customer has a hedge against lock-in, can benefit from the innovation across the community, and, perhaps most importantly, can quickly and nimbly respond to changing market conditions while relying on the robust software quality commercial open source provides.

    James Dixon, Pentaho Founder and CTO, has described the approach of commercial open source as being akin to a Bee Farm.  Bees can, of course, create honey on their own in the wild, but most of us buy honey that comes from a farm. The beekeeper’s job is to create conditions that attract the bees in the first place, and then (bravely!) collect the resulting honey before refining, packaging and distributing in a way that appeals to consumers.  This system of open collaboration adds value throughout the supply chain, from the bee to the beekeeper to the customer at the breakfast table.

    Likewise, in commercial open source, the vendor takes on the role of beekeeper, creating conditions in a community that attract and retain contributors to help create a better product for all in a win-win-win scenario:

    • The community gains open source software they can use for their own purposes. This software has more functionality and more resources than a ‘pure’ open source project could provide. In this way the community profits directly from the company and its customers.
    • The customers gain higher quality software at a better price. The customers profit from the open source community’s ability to produce high-quality software.
    • The company gains by growing and increasing its valuation as a result of keeping both sets of consumers content.

    I can’t think of a more perfect metaphor for the role of commercial open source. In fact, as a nod to James’s insight, years ago the Alfresco user community named their organization the “Order of the Bee.” What a complimentary match for our company, which, after all, is named after an open air, outdoors experience!

    The open source mindset provides areas of opportunities along the entire supply chain, from creation of software to products and services on which the software runs. Just as bees are integral to honey, open source is integral to today’s digital business environment.

    About the Author / Chris Wiborg

    Chris Wiborg is Vice President of Product Marketing at Alfresco Software. In his role, Chris is responsible for setting and executing the go-to-market strategy for Alfresco’s Digital Business Platform. Connect with him on Twitter and Linkedin.

     

  • The 5th Industrial Revolution: When It Will Happen and How

    The 5th Industrial Revolution: When It Will Happen and How

    Industrial revolutions have always dominated and changed the world in a big way. The first one happened way back in 18th century, and the second industrial revolution occurred almost two centuries later, in the 20th century. The third one happened only a half-century later, while the fourth one was observed within three decades. By the speed these transformations are occurring, a fifth industrial revolution is already around the corner.

    The next technology revolution will be faster and more scalable, and will be adopted by a lot more people as compared to the previous ones. Everyone on the planet will undergo a “personal” revolution by the kind of technology at their disposal. 3D-printing, wearable technology, robots. driverless cars … everything will be readily available and will make lives simpler and faster. With every industrial revolution brought a substantial increase in the GDP, and lifestyles improved manifold. The next revolutionary technology, however, does not aim to simply improve the lifestyle or help people make more money; rather, it focuses on the higher form of intelligence. Now humankind is ready to take the big plunge and step into space. With ideas such as SpaceX and affordable space travel, a future that we cannot imagine today might be possible tomorrow.

    The definition of industrial revolution includes the use of sophisticated machinery to make the work of humans easier and faster. Today, that includes robotics, machine learning, artificial intelligence and a lot more things that nobody could think would become a part of industrial revolution someday.

    In future, we can only expect technology to become more superior and sophisticated in every sense: augmented reality, big data, virtual reality, artificial intelligence and the most disruptive one—cryptocurrency—are a few to name. Cryptocurrency is something so revolutionary that it is making news every day. Bitcoin’s price is touching the sky and investors of cryptocurrency believe that the prices are sure to touch the moon in coming years. With the number of people investing in cryptocurrency and people holding on to their alt-coins, one thing is sure: A fifth industrial revolution has “already” arrived.

    Industry not only runs on machinery or ideas, but also on money. Today, people are spending their hard cash and fiat currency to buy cryptocoins, including Bitcoin, Ethereum, Litecoin, Ripple, Monero, Dash, Golem IOTA and even tokens (ICOs). A popular crypto-exchange claims it adds more than 30,000 new user accounts every day—a number not to be ignored!

    It is true, cryptocurrency currently is not regulated or controlled by any government, but it’s possible governments could impose taxes on the income generated from it in future. There is still much to be worked out in making cryptocurrency a validated form of currency. But even high-end investors such as Warren Buffet claim cryptocurrency is here to stay, and it is indeed something that will bring a bigger revolution than expected.

    The Fifth Industrial Revolution is poised at the cusp of a future in which things considered unimaginable today become the norm, and concepts such as universal basic income (UBI) help ease the sting of automation and mass unemployment. Mankind is ready to take a step forward.

    The world currently is in a disruptive stage, as the fifth industrial revolution unfolds to impact our lives—for better or for worse. Now we wait and observe what the future has in store for us.

    About the Author / Emma Rundle

    Emma is a professional content writer currently providing her freelance services to Edubirdie. Emma’s favorite topics to cover include business, software, high tech, and web development. She has a Master’s degree in Economics from The University of Texas at Austin. Follow Emma on Twitter.

  • Why One Second Matters for Today’s Application-Centric Businesses

    Why One Second Matters for Today’s Application-Centric Businesses

    A lot can happen in a second, especially if your business is digital. Google receives 68,000 search requests. Amazon averages $2,361 in sales. In this application-centric world, those are just examples of what application outages can cost the business. Imagine if you didn’t even know there was a problem for just one minute. Sixty seconds of downtime would result in almost 3 million unfulfilled Google search requests and it would cost Amazon about $141,660 in missed sales.

    In an economy where consumers will abandon an application in six seconds if the experience isn’t satisfying, shopping carts are routinely deserted for poor performance and brand loyalty depends on immediate gratification, one minute of poor application performance can be disastrous for today’s digitally transformed organizations. Businesses must be able to see how their application (which is essentially their business) performs in real time, by the second.

    The Need for Speed in Today’s Modern Applications

    Those who code fastest will be the winners in a digitally transformed world. To increase velocity, developers are embracing more modern development methodologies such as Agile and using containers and microservices for their flexibility, scalability and speed. This is having a tremendous effect on the technology makeup of today’s applications and services.

    Operations must respond to this development speed revolution, especially when applications are deployed in a containerized environment. Consider this: Within 15 seconds of starting a script, an array of newly created containers can alter (or significantly impact) performance and/or quality of an organization’s applications—and its business. If those applications aren’t monitored within the same realm of speed at which the application is morphing, IT Ops won’t know about problems until unhappy customers start calling—something every business wants to avoid.

    Traditional application management products architected for monolithic applications struggle with visibility into modern applications. They also struggle to match the speed of change within the modern dynamic applications that digital businesses are rolling out today. In essence, using a traditional tool to monitor modern applications removes the benefits of a high-velocity development process through the increased risk of insufficient monitoring. High-resolution, time-based metrics (i.e., one-second granularity) are critical to modern application performance management.

    This need for one-second visibility actually goes beyond monitoring. Operations teams require feedback whenever a new application component is deployed, whether it’s a long-term server, a short-term container or a change of host. With application changes occurring with increased frequency and regularity, feedback is necessary in seconds, not minutes.

    One Second Means Business Success or Failure

    For monitoring tools to catch up with development progress and innovation, one-second visibility, or granularity, is essential.

    In today’s modern, dynamic application world, where the application is the business and possibly the only direct engagement with customers, one second means everything. It can mean the difference between business success or failure.

    The technology that allows developers to deploy applications so quickly is a great advantage, but that same attribute—speed—creates a huge hazard if these more complex applications can’t be adequately monitored and managed. The only way to ensure your IT Ops team—and your business—are protected against application outages is to monitor (and manage) your applications on a second-to-second basis.

    About the Author / Mirko Novakovic

    Mirko Novakovic is CEO and co-founder of Instana, where he brings deep technological experience with a background that includes performance management software, agile development and DevOps. Prior to Instana, Novakovic founded codecentric AG, a leading software consulting firm focused on performance, agile software development and software architecture. He received a Bachelor of Applied Science in Information Technology at Stuttgart University and an SMB Management at the University of St. Gallen. Connect with him on LinkedIn and follow him on Twitter.

  • Outsourcing DevOps? Here’s What to Look For

    Outsourcing DevOps? Here’s What to Look For

    DevOps synthesizes methods, processes and tools with the goal of improving your company’s velocity at which you deploy applications, which serves your customers better. Teams using DevOps best practices and tools to create production software are much faster than organizations using traditional infrastructure management and software development methods. In 2016, RightScale’s “State of the Cloud Report” estimated that 70 percent of SMBs were adopting DevOps methods. Every indication is that percentage has increased.

    For companies that already understand the value of software development outsourcing, partnering with a capable outsourcing vendor for DevOps is a natural next step. For companies who want to embrace the benefits of DevOps but haven’t yet, aligning with a qualified DevOps outsourcing company is really worth considering.

    Consideration No. 1: Pick the Right Project

    If DevOps is new to your company, or the DevOps partner is new to your company—or both—it’s very important to pick the right project to begin work together. Also, it’s possible that the project you target will influence the selection of your DevOps outsourcing partner.

    Here are some questions you may want to use in selecting the right project:

    This question…. is important because…
    Which software, if successful, will show the clearest benefit (i.e.: ROI) to the company? Software with clear business benefit will generally get better buy-in from the user community, and higher quality participation.
    Which software  has the clearest goals and scope of work? It’s always easier to achieve the goal, when the goal is clear.
    Do any projects require the use of new, unproven technology? Unfamiliar technology can be a dangerous variable in your work and risk estimates.
    How many other systems will the newly completed software need to integrate with? Integration testing is time-consuming and requires a high levels of coordination.
    Which projects are expected to have the longest duration? Unforeseen variables naturally occur in long running projects — personnel changes, other business distractions, loss of momentum, etc.
    Which projects are expected to require the largest number of participants? More people involved equals more complexity.
    What employees (IT and business stakeholders) will be part of the projects? DevOps requires good collaboration and speed. IT and business area participants must be able to fulfill their roles accordingly.

    Consideration No. 2: Vendor Communication

    In selecting the right outsourcing DevOps partner, the ability to communicate well is one of the most important considerations. A partner who communicates poorly can derail a relationship that has all the right methods and tools in place for success. design iterations and project sprints simply cannot happen if your outsourcing partner lacks the proper communication skills. Conversely, an outsourcing vendor who is truly acting like a partner in the relationship, communicating well and often, can help you overcome any number of unforeseen issues along the way.

    Evaluate how well prospective vendors respond to your due diligence questions. Their responses could tell you a lot about how they’ll interact with you during the project. Are they clear? Do they interact in professional ways, or does it seem a bit random and disorganized? Are they prompt  and timely in their interactions, or are there “black holes of silence”?

    If you see evidence of poor communication during the due diligence process, you’ll almost certainly have problems when you’re actually engaged in working together. As you check references, try to determine if other customers experienced problems in communication and interaction—those can pose as red flags when it comes to selecting your vendor.

    Consideration No. 3: Vendor Location

    Global software development outsourcing is a proven success for many companies. However, you must be attuned to the vendor’s geographic location compared to yours. Would time zone differences be an issue? This may affect the geographic location from which you’ll select your outsourced DevOps team. In a recent survey, one-third of U.S. companies that outsourced to India considered the 10-hour (or more) time difference to be a big challenge. DevOps activities cannot be artificially hampered because of time zone issues. The best DevOps outsourcing companies have a business model that allows U.S. time zone companies to interact easily with the vendor’s “A team” supporting your project. Be wary of companies that assume that all Skype and conference calls will be done off-hours to your normal business day—or plan to have secondary members of their team available during your normal work hours.

    Consideration No. 4: Vendor Technical Skills

    As you examine a prospective outsourcing DevOps partners technical capabilities, consider these questions:

    • Do they have the relevant skills and tools experience I need?
    • Is this a core competency of the company, or the expertise of a small select few inside the company?
    • How does this company go about attracting new talent with these same skills?
    • What certifications do they hold?

    Automation of good process makes it possible to eliminate bottlenecks in the software development cycle, so you can truly “sprint through your Sprints.” Automation tools must be used with consistency by you and your outsourcing DevOps partner. Perform an inventory of the available tools:

    • Will you be able to seamlessly (and automatically) promote code?
    • Can you perform test-driven design?
    • Can you perform test-driven development?
    • Can you easily associate features and fixes with promoted code?
    • How will you perform regression testing?

    DevOps teams will have programming language expertise that includes Python, Ruby, PHP and Java. Remember: DevOps means infrastructure as well as applications, so a true DevOps outsourcing company will have employees with expertise in infrastructure-oriented software and tools such as Windows PowerShell, Docker, Puppet, Ansible and SaltStack. You may also want to look for expertise and certifications for networks, databases, and operating systems.

    DevOps outsourcing companies should be experienced with the continuous integration (CI) method—the CI tools which support the associated processes. CI tools help merge source code updates from all developers on a specific software build, notifying the team of any failures in the process. Popular CI Tools include CruiseControl, Jenkins, Travis CI, TeamCity and GitLab.

    The best partners employ a programming staff that have achieved certifications that are important for your DevOps project needs. In addition to certifications around the tools and language mentioned earlier (such as Puppet Certification, for example), you will want to look for certifications in:

    Consideration No. 5: Vendor Commitment to Training

    As you evaluate a prospective DevOps outsourcing company, ask yourself: Is continuous training a part of their business model? A good partner invests in their programming staff’s training on a continual basis. We like to see evidence that their programming staff regularly renews their certifications—and the outsourcing company should be actively advocating this.

    Consideration No. 6: Vendor Experience and Size

    To succeed with DevOps outsourcing, you need a partner who has relevant experience and is a size that complements your company size.

    Experience. The ideal DevOps outsourcing team will have experience in your business vertical (example: discrete manufacturing, banking, etc.). It also should have expertise in the system functional area of your target project (e.g. finance, e-business order processing, warehouse management, etc.). Of course, the demonstrable experiences should include work using Agile and DevOps techniques.

    Size. The right partner should be neither too large nor too small. The outsourcing company needs a pool of programmers large enough to keep with the intended work pace of your project. Conversely, we caution IT managers to be wary of extremely large outsourcing companies. Your project and company must be “big enough to matter” to the partner you select. If you are seen as too small in terms of the revenue opportunity, the outsourcing company will defer attention and their top talent to larger customers who are more able to influence decision-making.

    About the Author / Steve Mezak

    Steve Mezak is founder and CEO of Accelerance, a leader in global software development outsourcing, as well as the author of “Software Without Borders,” co-author of “Outsource or Else: How a VP of Software Saved His Company” and a CIO columnist.

  • Are Your Web Applications Prepared for the Holidays?

    Are Your Web Applications Prepared for the Holidays?

    Three best practices to secure your website for the coming retail boom 

    The holidays are upon us, which means retailers are racing to launch new promotions, sales and other temporary web pages in time for what is anticipated to be a record-breaking retail season. Amidst their haste to prepare, some businesses forget—or don’t realize—that there are often a number of critical vulnerabilities in their web applications and servers that go completely unnoticed or unaddressed. In fact, recent research has shown that retail has one of the worst records when it comes to applications failing security checks. This is because web applications are often created quickly, without security in mind. Or even worse, they are created, launched and then forgotten. And if there is one thing we know about applications—they age like milk, not wine.

    Our research shows that the average web application contains 11 vulnerabilities, with an average of seven critical vulnerabilities. And every one of those vulnerabilities is a chance for a criminal to breach your company. The last thing a retailer needs right before the holidays is to become yet another victim of cyberattack and negative headline.

    Security for Web Applications

    To sail smoothly through the holidays, here are three basic hygiene principles that can be used to ensure your business’ web apps are thoroughly safeguarded:

    Test Early, Scan Often

    The importance of scanning website applications regularly is critical to ensuring web applications aren’t launched with known vulnerabilities. According to CA Veracode’s State of Software Security Report, 60 percent of web applications are scanned less than four times a year, 36 percent of organizations don’t run any kind of static analysis security testing (SAST) and 48 percent of organizations aren’t running any kind of dynamic analysis security testing (DAST). Part of the problem is that so many web servers have vulnerabilities that have not been patched, with 25 percent of those scanned possessing a high or very high severity vulnerability—meaning they could be easily exploited by attackers to compromise websites and potentially steal or compromise consumer data.

    Best practice for IT departments is to make sure their web servers are not sending out information that could be valuable to an attacker, such as server version information, for example.

    Discovery scans of websites show that organizations have 30 percent to 40 percent more websites than they thought they had. This could include marketing pop-up sites that are left online and forgotten about. These sites often are left online with a redirect instead of being taken down—this is a “messy” practice that can create entry portals for hackers later on.

    Shockingly, applications are only scanned twice a year on average. But scanning more frequently during development allows developers to fix on average 48 percent more vulnerabilities versus conducting scans that only give applications an up-or-down on security policy.

    Prioritize Remediation Based on Risk

    Testing and scanning for vulnerabilities is only half the battle—businesses need to fix the flaws they find. Out of 400,000 application scans that took place over the course of a year, only 18 percent of flaws were closed in less than 30 days, while 49 percent of flaws fixed took more than 90 days to close. Because critical vulnerabilities put your organization at the most risk, companies should fix the most severe vulnerabilities first. Many organizations are wisely doing this already—data shows organizations fix high severity vulnerabilities at twice the overall fix rate.

    To prioritize risk, organizations must account for the severity of the flaw in addition to the business value of the application at risk. In addition, not all high-severity flaws are weighted equally—some organizations may choose to prioritize more high- and medium-level vulnerabilities that have more value, or are in more sensitive applications, over very high severity vulnerabilities in less sensitive applications.

    Empower Developers with Resources to Make Security Part of Their Process

    It’s important that cybersecurity professionals nurture their relationships with the people who are closest to the development process. But this is often deprioritized. According to findings from a survey conducted by CA Veracode and ESG, only 18 percent of development team leaders said security was the most important metric for measuring their team’s performance. And security education and ongoing training is equally neglected, with 68 percent of surveyed developers and IT pros saying their organizations aren’t supplying them with adequate training. This endemic goes all the way back to college—76 percent of respondents reported that they weren’t required to complete any security courses while in school.

    However, developers do care about security, and these stats should serve as a reminder to maintain vigilance in helping developers get the tools and reinforcement they need to fix vulnerabilities efficiently.  In fact, there is a 19 percent improvement in vulnerability fix rates when employers provide developers with on-demand training courses.

    As more cybersecurity threats continue to emerge, having a “clean” app landscape has unmatched long-term benefits and can help ensure customers continue to have trust in your brands.

    About the Author / Joe Pelletier

    Joe Pelletier is the Director of Product Management for Veracode’s Web Application Security and Runtime Protection product lines. He has worked in application security for over six years, originally helping large enterprise clients implement secure development practices and programs. Joe is a hands-on learner and passionate about building great products and teams. Prior to Veracode, Joe worked in the financial services industry and helped develop portfolio management and investment research platforms. He received his degree in Finance from Bryant University. Follow Joe on Twitter.

  • Accommodating Different Processes in Enterprise Software Delivery

    Accommodating Different Processes in Enterprise Software Delivery

    When an organization takes on a new initiative, it typically develops a procedure to optimize execution and limit blowback from the transition. Whether it’s the introduction of new processes, personnel, structures or technologies, there are a number of established ways—often gleaned from experience—to support the individual, the team and the wider organization.

    That said, while this procedure may work for one department or team in a certain discipline—say, when marketing invests in a new marketing automation tool—what if the initiative impacts multiple teams, processes, structures and technologies, as it does with enterprise software delivery? A standardized procedure won’t work; there are just too many variables to consider.

    And as organizations continue to provide digital services and products for their discerning customers, the number of variables will only increase as enterprises look to ramp up their software delivery to gain a competitive edge in a digital world. How do you manage all this change?

    Moreover, what if this change disrupts some of your best teams, many of whom who are fiercely protective of their own unique processes? Much time and thought has been committed to hone a process that is right for them. Who are you to tell them to pull up the floorboards and start again? Sure, the wider organization may want everyone operating from within one end-to-end system, but that’s just not how software delivery works. Nor, for that matter, is it how practitioners think.

    You Can’t Please Everyone — or Can You?

    Very rarely do practitioners look beyond their core function and specialism, unless it truly impacts their job. For instance, developers want clear requirements to write accurate code that is tested, validated and out the door. They have to write and maintain reams of code, meaning they have little time to think about the rest of the value stream. Typically, if you’re not a business analyst, tester or in ops, then you’re unlikely to be on their radar. They certainly won’t welcome any interruption or change to the way they operate from someone “outside” their world.

    This dilemma is exactly why organizations need to think long and hard about how they deal with these differences within software delivery value stream. Not only can practitioners be hostile and resistant to change, but it’s extremely complicated to deconstruct or adjust these processes. They’re highly detailed in practice (although rarely documented due to the frequency with which they’re modified!), covering:

    • Work items to utilize/prioritize
    • How backlog items vs. issues are represented on their backlogs
    • How items flow through day-to-day processes
    • Whether they use Scrum and/or Kanban
    • The required information that developers need to submit to management level
    • The person responsible for submitting certain elements of the management report

    When Standardization Isn’t Enough — How to Accommodate the Cowboys

    While standardization is possible (and preferred) across organizations, e.g., ITSM for managing multiple systems for multiple functions from one centralized point of control, unifying teams across the software value stream isn’t so simple. There always will be one or two rogue teams that will reject any new process because they know better and only want to do things their tried-and-tested way. We call these teams “cowboy teams.”

    Cowboy teams, while problematic, are a force for good as they can be leaders in experimentation and innovation: Consider Alan Turing and his “Enigma” team. Nor are these teams stubborn sticks in the mud. Often it just boils down to the fact that introducing a new process comes with a lot of baggage that people are naturally going to want to avoid, including:

    • Financial cost (new tools, staff and accompanying training)
    • Time cost (training etc.)
    • Reduced productivity during implementation period
    • No guarantee of success
    • Potential of negative impact on function
    • Detrimental influence on employee satisfaction
    • Unforeseen complications and conflicts such as mismatch with tools used by the team

    Last but not least, haphazardly introducing a new process can undermine your software delivery value stream. We know that large-scale software development and delivery requires all teams, tools and disciplines within the value stream to be connected for end-to-end visibility, traceability and governance over the whole process.

    And in an ideal world, the process would be underpinned by a single cohesive system. But in reality, this is not the case. Teams work in silos because their purpose-built tools aren’t connected to other stages in the value stream since these tools are unable to automatically flow information between systems. Not only does this state foster siloed thinking, but there always will be one or more teams that will resist any wholesale change to their way of working, even if they’re told it will help the organization meet its business objectives.

    Fortunately, there’s a way to unify and connect your value stream while simultaneously accommodating these cowboy teams, and that’s a modular tool chain.

    Modularity — The Backbone of Autonomous Teams Functioning Within the Bigger Picture

    The software delivery process isn’t a conventional manufacturing process. It’s more like a network of thousands of people with different functions, tools and processes that work on different components of the same project at the same time. And these components simply must communicate in real time to share collaborative data. Supporting such a system is complex, because all the best-of-breed tools for planning, building and delivering software do not naturally integrate—there’s no interconnection, the lifeblood of any network.

    However, you can connect these tools via model-based integration through a modular value stream; i.e., not point-to-point integration, but an adaptable, integrated network that communicates through a model in the center of this complex universe. Not only does this account for all different tools, teams, disciplines and processes, but this paradigm enables organizations to plug new elements in and out without disrupting the all-important flow of information across the value stream.

    This means any information that is shared throughout the value stream is done so in a normalized format—a common language, if you will—that allows teams to operate in their preferred tool and methodology. For example, if your management wants to know the number of tickets/defects submitted per program during each release, they don’t want to know there were 10 “high priority” ones from one team and 15 “important” from the other team. If “high” and “important” mean the same thing, priorities should be normalized and reported back to the management in a standardized fashion.

    Thanks to the automated flow of information into a language everyone understands, the whole value stream, even the cowboys, are on the same page without the need for laborious time-consuming manual forms of communication, such as email threads, status meetings, phone calls, spreadsheets and duplicate data entry. Not only does this improve the working conditions for practitioners, enhancing employee engagement, but it also can save up to $10 million a year in productivity-related savings.

    So, the choices for organizations are either to:

    1. Force all teams to use the same system, creating a litany of individual, team and organizational problems due to disruption, or
    2. Use a modular value stream method that maps each team to the standardized model, while at the same time allowing teams to continue working in their preferred system using their carefully devised processes.

    Change is constant, inevitable and vital for progression and innovation. At the same time, change can be a threat to those important parts of your business model that are working and delivering business value. With value stream integration, you can have the best of both worlds: Your pioneering cowboys can continue to work in the ways that make them happy and productive, while the rest of the stream can continue to collaborate, evolve and adjust to the fast-paced digital landscape.

    About the Author / Mara Puisite

    Mara Puisite is a Pre-Sales Engineer at Tasktop, bringing with her years of industry and technical experience. Prior to her current role, Mara worked as a Product Manager running Tasktop’s connector program and managing the development and maintenance of 50+ integration systems. Today, she helps companies solve various bottlenecks in their software development and delivery process through the power of value stream integration. Connect with her on LinkedIn.