Tag: automation

  • VMware Extends Network Virtualization Reach

    VMware Extends Network Virtualization Reach

    VMware today announced the general availability of an update to its NSX-T network virtualization software that adds support for NSX Federation, which enables IT teams to apply global policies and isolate domains to contain problems to a single zone. Other capabilities being added via NSX-T 3.0 include support for Level 3 Ethernet virtual private networks (L3 EVPN), multicast routing and improved data plane performance.

    In addition, VMware revealed that next month it will make available an update to VMware vRealize Network Insight that employs machine learning algorithms and statistics to discover application flows across a virtual network.

    VMware is also making generally available intrusion detection and prevention (IDS/IPS) capabilities to a previously announced software-defined firewall, along with support for AWS Direct Connect, VMware SD-WAN application and business policy statistics; enhanced Kubernetes visibility, integrations with the VMware Tanzu cloud service for managing containers; the latest release of VMware Cloud Foundation; and VMware NSX-T 3.0.

    Finally, VMware announced that VMware SD-WAN by VeloCloud software has now been integrated with the Microsoft Azure Zones portal to simplify provisioning on that public cloud.

    Tom Gillis, senior vice president and general manager for the Networking and Security Business Unit at VMware, said as part of the overall effort to reduce costs in the wake of the sudden downturn in the economy as a result of the COVID-19 pandemic, VMware expects many organizations will accelerate the rate at which they are transitioning to network virtualization to replace many of the hardware appliances they currently rely on. For the amount many organizations are paying for software and support for those appliances, they could be transitioning to a much more flexible approach to networking that provides a cloud experience spanning on-premises and public cloud computing platforms, he said.

    Gillis also noted it is now only a matter of time before VMware extends the control plane of its network virtualization software to the physical network underlay on which NSX-T is deployed. That capability will enable IT organizations to further reduce costs by eliminating the need to deploy multiple control planes, he said.

    According to VMware, the number of customers that are consuming some element of its Virtual Cloud Network portfolio now exceeds 15,000, which represents on average a 50% growth rate each fiscal year since May 2018.

    Gillis made it clear that in the months ahead a much larger swath of networking will become automated to drive down costs. Most organizations have adopted some level of network automation. However, Gillis said partial automation is an “oxymoron”—once most organizations start down the automation path the network becomes just as programmable as other IT infrastructure that is now managed as code.

    It may take a while for networks to come fully automated at a time when many network engineers still prefer to use command-line interfaces (CLIs) to manage network infrastructure. However, as networking continues to become more complex in the age of the cloud, it’s not so much a question of whether organizations will automate networking as it is to what degree and using which platform.

    — Mike Vizard

  • Bridging the Network Automation Skills Gap

    Bridging the Network Automation Skills Gap

    With the introduction of network programmability and APIs for everything from management systems to devices themselves, the modern network landscape has evolved to being managed like software. This shift from hardware-focused networks to software-centric functions has had a profound effect on network management techniques and skillsets required to keep pace with the changing ecosystem.

    A recent EMA survey notes that skills gaps associated with network automation are an issue for 96% of enterprises. Even respondents with significant network automation initiatives in place felt their solutions stretched the abilities of their network teams. Network automation can expose skills gaps where network engineers might lack experience with new tools and software development. At the same time, application development teams, who likely would be included in building an in-house network or automation software solution, will also lack networking skills. Hybrid skills with both development and networking expertise are rare and available only at a premium.

    This journey to network automation can be difficult, especially given the required technical skills that are not in abundance within many organizations. Simplifying network automation and empowering a broader set of participation through capabilities to easily create and manage automation workflows presents a key opportunity for organizations to not only mature efforts around network automation, but to also execute against broader business digital transformation objectives.

    Four Keys to Democratizing Network Automation

    The key to democratizing network automation and bridging the skills gap is to provide NetOps teams with the ability to easily design and build network automation without having to re-tool, build custom code or learn specialized software skills. There are four key elements required to effectively democratize network automation in the enterprise.

    Easy Onramp for Non-Developer

    Automation is typically accomplished through writing code in a particular programming language. For a person without any programming skills (or even minimal skills), they must first learn how to code before they can even attempt their first automation task. This is very difficult in terms of time and interest. Additionally, many network engineers see the amount of work it would take to learn to write code, and become disinterested. There has to be a new set of tools and methodology to empower these people to automate their work without the long road of learning to become programmers. It’s important to invite as many people to the automation table as possible including IT, security, cloud and NetOps teams, to streamline business processes.

    Capture Network Tribal Knowledge

    Within the organization, there is already existing embedded tribal knowledge that is incredibly valuable. By harnessing and transferring that knowledge into an automation workflow without a lot of programming, it provides an accelerated path to network automation. The goal is to leverage traditional network automation and management practices (Scripts, CLI) for re-use across the organization.

    Network engineers with years and years of experience have a valuable set of processes and procedures they’ve built up inside their heads, and this wealth of information is a valuable asset. Unfortunately, this information is rarely documented and is normally passed on by activity and word of mouth. This is the type of tribal knowledge that needs to be captured, preferably through automation workflows that can be used in a task, documented in the workflow and modified over time to improve it or change it as the infrastructure changes.

    Integrate DevOps Principles

    Augment network automation with CI/CD pipelines and API services. These are well known solid principles that are already used in other domains outside of networking and pay big dividends when applied to the automation of complex networks. When we look along the horizon of the network automation journey, these same CI/CD practices will be adopted by future networking teams and allow them the same advantages of reliability and velocity within the network.

    Enable Cloud Architect Participation 

    It is important to have networking people that can understand the networking constructs of the cloud, as well as cloud teams that understand how it integrates and operates within the network. Enabling cloud architect participation in network automation will allow for the real-time feedback and control of cloud-based applications and infrastructure critical to modern networks.

    Cloud networking is increasing in complexity and will soon require the skills and experience of network engineers to help solve the problems of cloud networking. Traditionally, cloud and networking teams have been separated because their technology domains have been siloed and there was very little interaction required between the teams. As technologies like SD-WAN have been adopted, the line of responsibility between cloud and network teams has blurred. Cloud and networking teams will need an automation platform that can be used by both to create workflows and automate between both domains. Business technology decisions are forcing these two groups together, and they must have a way to use their own tools, but also have a platform to collaborate automation between them.

    As applications and services are becoming more complex, distributed and require connectivity and policy enforcement across a diversity of domains (such as cloud, SD-WAN, data center, wireless and network applications), the management of these network concepts requires us to re-think how we have traditionally managed networks. As network automation plays an increasingly larger role in enterprise networks, a byproduct of the complexity is a skills gap that threatens to slow or stymie enterprise initiatives.

    By making the onramp to network automation easier for non-developers through capturing tribal knowledge, integrating DevOps principles and enabling cloud architect participation, enterprises better ensure a successful migration to network automation across multiple domains.

    — Rich Martin

  • DataOps and Beyond: How DevOps Methodology Transformed Our Approach to Data Science

    DataOps and Beyond: How DevOps Methodology Transformed Our Approach to Data Science

    The DevOps methodology has become synonymous with forward technical thinking–a workplace culture that reinforces best cultural practice and promotes more, better quality output by synchronizing the functions of development and operations teams. As a testament to its popularity, the term has expanded in reach to refer to a broader set of transformational software-related practices. The list continues to grow: DevTestOps, DevSecOps, GitOps, DataOps. 

    In 2020, organizations are drawing upon thousands—if not tens of thousands—of data sources, which exist in hundreds of different formats and fall under unique sets of restrictions and compliance regulations. Figuring out where all this data comes from, what it means and how to ensure that the right teams can access it when they need to, are common data management challenges. To address these challenges, some solutions were borrowed from effective practices in software development; automating analytics for improved quality, and allowing data scientists to shift away from time-consuming tasks to focus on value-adding projects instead. 

    What happens when software development and deployment methods are applied to processing and integrating data? Does that mean that DataOps is exactly like DevOps, but for data? And what benefits do organizations expect from adopting this approach to data management?

    The xOps Mindset

    At their core, the ops practices are linked by fundamental characteristics that shape their goals and practices. Let’s explore some of these commonalities:

    • xOps ties together workflows from create to run: In an ideal environment, production and distribution don’t function as separate entities, but are synchronized to meet target metrics that can include hundreds, or thousands, of daily deployments. Culture changes have rewritten rules around internal communication and feedback loops in a development environment where the conditions or requirements for success are constantly changing.
    • xOps automates the mundane (non-creative) tasks: Automation not only increases an organization’s agility, but when executed correctly can eliminate communication gaps between teams—for instance, automating traceability and issue tracking within code changes. Within larger, more complex projects, automation can save on time and cost by executing and managing CI/CD—ensuring that software builds and changes reach their designated target environment with little to no human involvement.
    • xOps builds in best practice: Equally as important to the functions they perform, xOps tooling plays a key role in building in best practice from the top down and bottom up. Best practice might not look identical between organizations, but the common goal is delivering value for a range of stakeholders through continuous production, in an environment where it’s encouraged to learn through experimentation and to respond to problems as they occur.

    In short, DataOps loosely applies the DevOps process to data pipelines—using automation and Agile methodology to reduce the amount of time spent fixing issues in pipelines, and to get data science models into production quicker. There are also some obvious differences between DataOps and DevOps. While DevOps refers to the collaborative process between two technical teams, DataOps facilitates cooperation between data analysts, engineers, scientists and any members of an organization who use data. This makes DataOps a much more multifaceted process than its DevOps cousin. 

    xOps for the Big Data Age: Benefits of Running DataOps 

    We know that for many organizations, converting raw data into usable, accessible and relevant (that is, profitable) business intelligence has given rise to a plethora of data management issues. The sheer volume of most enterprise level datasets has simply outgrown many of the inadequate older systems and processes built to manage it, and we continue to produce new data at stunning rates. There is a general consensus among data scientists today that the amount of data in the world doubles every 12 months.  

    • Automation and Continuity: Within an organization, business data moves through a set process—akin to the software lifecycle for the DevOps analogy—where data is ingested in one form and exits in another. Engineers must build data pipelines, test them and change them before they are deployed. By adopting the standards for automation and best practices outlined above, you’ll ideally have a constant stream of data flowing through a pipeline. This unlocks the potential to obtain real-time insights from data, shortening the length of time it takes to turn raw data into valuable business information.
    • Cultural Shift: When completed correctly, DataOps changes who within an organization becomes a data user. A higher level of transparency and an assurance of quality means that data is more openly available to decision makers within non-technical teams. Consider the business value-add for a sales team who wants to expand into new markets and are able to access a wealth of customer data.
    • Machine Learning: We talked about the role of feedback loops in the xOps mindset. When machine learning modelling meets this mindset, you improve the quality of the model being produced because you’re unlocking a higher quality of data through version control, continuous integration and continuous deployment. Improved insights in machine learning offer nearly unlimited potential for extracting value from DataOps.

    — Hannah Leslie

  • IT Automation Tools Are No Longer Enough

    IT Automation Tools Are No Longer Enough

    As Chris Gardner—who conducted the Forrester Wave on Infrastructure Automation Platforms—stated, “Infrastructure automation isn’t just on-premises or in the cloud. It’s at the edge and everywhere in between.” And that’s because, well, it needs to be.

    It shouldn’t come as a surprise to anyone reading this that IT automation is a must-have for organizations today. With infrastructure spread across on-premises data centers, multiple clouds and a multitude of technologies, the complexity of IT long ago outgrew manual management. Automation is the only way to keep pace with constantly changing environments that need enhanced security, greater compliance and be easily adaptable to changing business and market conditions.

    Because of these needs, the market has been relatively quick to adapt and embrace automation technology. According to a recent study by Forrester Research, 56% of global infrastructure technology decision makers have implemented/are implementing or are expanding/upgrading their implementation of automation software. Many of these IT organizations have a trusted tool in place and have been automating scripts and tasks for years.

    Along with outgrowing managing infrastructure by hand, the industry is also quickly outgrowing automation tools. The automation market has now reached a point of maturity where an automation tool alone is not enough. In order for automation to continue to have an impact on an organization and keep pace with the speed IT changes, organizations need a platform that allows them to create a culture of automation.

    Automation as a Trait, Not a State

    Typically, when an organization acquires a new technology, they try to adapt it to their needs and how they work. Automation technology, along with most technology tools, does exactly that—it lets you adapt it to how you want to use it, and performs tasks as desired. But ultimately, successful automation comes down to more than just supporting task execution. Enterprises have realized that they need to support the behavior of automation in order for it to continue to scale.

    As opposed to automation being a state, use automation as a trait—something that is done naturally without thought. The analogy we like to use is one of learning a new language. When you learn conversational Spanish, your mind still thinks in English, then translates what you want to say into Spanish based on what you have learned. Yes, you improve over time, but when you start to dream in another language, that is when it has become second nature. It is no longer something you have to do, you just simply do it.

    When automation becomes second nature, that is when it can make the biggest impact and will help address a continually evolving infrastructure. As a discipline, automation is not technology-specific. As much as we talk about the technology behind it, it actually has little to do with automation. The technology itself is the easy part, the part that is reliant on a tool. Many have reached a point of maturity with using tools and are now working toward IT staff viewing automation akin to testing or documentation—while we may not always do it, we know we should. 

    Having automation become second nature is easier said than done, and something organizations are struggling with, realizing that a tool alone will not support this effort. It doesn’t provide the coordination and collaboration that is desperately needed to unlock the next level of automation capabilities. We need more than a tool to continue to scale automation and spread it to new areas of IT.

    The Next Phase of Automation and What to Look for

    There are multiple personas within an organization that are paramount to successful business-wide automation, and, to be blunt, automation must cater to all of them. Between developers, those trying to simply consume automation or sys-admins executing automation of mundane tasks, they all need something that works for them—but can also work consistently across these personas. Organizations need a common automation language across the entire enterprise and the hybrid cloud that creates a standardized experience for solving problems (and solving them only once). 

    Not only that, but they need a repository or catalog where everyone can find an answer to what they need, along with easily accessed integrations. Part of why automation is growing so rapidly is because of how many technology vendors have embraced the concept and, in turn, are working with automation vendors to integrate their technologies and make them easier to use.

    To continue to spread automation to new areas of a business, organizations need a single repository to more securely search and find necessary modules. Additionally, having a shared repository helps create an automation community within an organization. It brings different personas together to find what they each need, fosters collaboration and ultimately encourages sharing automation specific to their organization. It also provides a place to find integrations that they may not even have been aware they needed.

    When preparing for the next step in their automation journey, organizations should look for automation platforms that provide access to analytics, specifically those that can tell you how your automation is being used and where. As the adage goes, knowledge is power, and the more you know about your automation, the more successful it can be. More importantly though, if you are trying to create it as a behavior, analytics let you track and measure progress. It allows you to better understand what is working, what groups are thriving and what areas need improvement. Using automation analytics enables organizations to create a system for enabling standardized practices. 

    On the whole, a successful automation initiative needs a supporting automation platform to provide coordination and embrace collaboration between different groups. Simplification is also essential for making automation more accessible across these groups, especially in the face of competing needs and varying levels of engagement. Scaling automation successfully applies both to technologies, as well as the users that want to benefit from automation.

    Strategy for 2020

    There is no such thing as a perfect tool, and don’t let anyone try to tell you otherwise. The good news is it’s not about having a perfect solution, it’s about the experience that can be gained from a solution. Every organization is unique and there is no one-size-fits-all option.

    What is needed when developing an automation strategy that takes organizations into the future is a foundation for growing that automation. Automation platforms offer so much more than a tool alone, allowing it to be more easily scaled and being leveraged how the organization needs. It may never solve all problems but will take away a lot of the efforts. You need to find a vendor that is not selling a tool—but selling automation as a whole.

    — Richard Henshall

  • How to Properly Approach Automation

    How to Properly Approach Automation

    Imagine if you backed out of your driveway, tapped the gas and BAM! You are at work. Nothing to worry about along the way, no traffic congestion, no other cars to worry about, etc.

    That is, unfortunately, how many of us approach automation. “Fire and forget” is real, until a problem crops up. I could talk about some complex environments, such as ARA, in a containerized environment with multiple languages, accessing mobility-limited databases and targeting several client platforms, for example.

    But we’ll keep it simple, and I’ll make an admission. Backup was one area where we at Ingrained Tech fell into the fire-and-forget trap. One part of our backup system runs desktops out to a server, the server (and other servers) out to a NAS and the NAS out to the cloud. I don’t think our security peeps will freak out if I mention we use duplicity for this backup and Backblaze for our backup cloud. Backblaze is a dream to use compared to others we’ve looked at, and the pricing is competitive, so it suits our needs well.

    A few weeks ago, we realized that while backups were completing successfully and verification was fine, it was taking nearly the entire week to do our weeklies. That’s bad news. We back up terabytes of data, but this is 2020, and our drive IO/Network can handle it. We started by looking at both of those things, and sure enough, it was drive IO causing our problems.

    Unsurprisingly, reading the disk and creating a collection of encrypted tarballs (a super-simplification of what duplicity does, but gets the point across) on those same disks was causing problems. After investigating, the one build that occurs on that server was suffering from backups stretching out, too. We had seen occasional issues with the build, but nothing jumped out as the source, and it was only one night every month or two. It was on our list. You know, the same prioritized list you have. And this build wasn’t nightly-critical. You get the idea.

    This was a relatively urgent problem, as soon as last week’s backup would not be complete when this week’s tried to start. Not good.

    We took our DevOps mentality to the problem and discovered a simple solution that solves the issues. The backup NAS is RAID 50, so it can handle a lot more abuse than the server that was slowing down backups. So, we took the simple expedient of rsyncing the source server to the NAS, then using duplicity to tar and encrypt before sending it on to the cloud buckets. Internally, we do not believe we need to encrypt backups because if someone is in our network, all of that data is laying around. By putting duplicity and both the tar function and the encryption function onto the backup NAS, we moved it to a far less busy system. Backup times dropped from days to hours instantly, and our unrelated build problems went away.

    We have to rework the automation somewhat to make sure validation is, well, actually validating the data is correct. But we’re well on our way to having a stable, faster system.

    How does this fit with DevOps? We see the same thing happening often in the automation rush of DevOps. Yesterday’s best solution is not necessarily tomorrow’s best solution. “Automate and watch” should be the catch-phrase. Improvement comes from both DevOps culture and paying attention to changes in the tools market.

    As Alan pointed out, someone will eventually win the end-to-end DevOps rush—since I feel the urge to inject my opinion on who stands the best chances, expect a blog on this topic soon. Until then, knowing what your options are and how to best achieve your goals–even on problems that were “solved” last year–is your best path for continued improvement. Yes, it means rework, but just like reworking your code, the point is to streamline things, get closer to your organization’s goals and keep improving after the low-hanging fruits of DevOps have been gathered. The rate of improvement in several areas of DevOps is stunning, so you may find you actually like a new tool better than the one you chose a couple years ago. And remember, knowledge is power.

    — Don Macvittie

  • Moving from NOC to the SRE Model

    Moving from NOC to the SRE Model

    Is Site Reliability Engineer (SRE) another case of “Do what Google does”? When viewed with a discerning lens, the practices and tooling high-performing engineering teams deliver to the market can be very beneficial. The SRE model is one of them and stands to benefit DevOps teams substantially.

    If I could change the name from Site Reliability to Service Reliability I would. Applications are increasingly more service oriented, architectures are based on services and the SRE model is generally more customer centric than previous application support approaches. SRE has become the production support companion for modern application development.

    While the Network Operations Center (NOC) and SRE primary objectives are to focus on application uptime, the responsibility of supporting applications is much greater. Those who support modern applications are under pressure from the business and development to respond fast and accurately. This has been done previously by a NOC only.

    In its most traditional form, the NOC was a 24x7x365 staffed room where all telemetry from various aspects of infrastructure and the application were presented on screens, usually with one screen dedicated to sports and video games. If you staffed the NOC, your job was to keep an eye on the application, spot any alarms and if there is an alarm, to find the right person—usually based on a spreadsheet—to fix it.

    The NOC has also classically been more tied to the infrastructure than the application. They would get alarms for the application, but they’d be unable to dig in and figure out what specifically in the application was causing the issue. The NOC model services waterfall development and monolithic architectures just fine. But now, with rapid release velocity and new application architectures, a new approach is needed. This is where SRE comes in.

    Customer Obsession

    The first big difference between the SRE model and the traditional NOC model is that the SRE role does not start when something breaks, it starts before. The most high-performing SRE teams I’ve seen always work backwards from the customer. They use the customer to decide what metrics to measure and collect, and how they will interpret the metrics.

    Google talks about RED (Request, Errors, Duration) metrics but these are in no way best practice for everyone, nor the only approach. They are the best practice for Google, perhaps, and how their users interact with the application. Things such as saturation, latency, etc., can be even more important. Also, it is not the individual metrics that matter, it is their relationship to each other and, ultimately, to the customer’s experience. The customer obsession bleeds into everything SREs do—from setting up automation to educating the rest of the technical teams.

    To be customer obsessed, SRE teams need to have good visibility into what is going on.

    Observability

    I’m sure you have heard the new popular term “observability.” You might have thought to yourself, “Isn’t that just monitoring?” Observability’s foundation is monitoring, but it’s purpose is to go from the static point-in-time view of applications that traditional monitoring has been used for. It also addresses new challenges that show up as application architectures become increasingly more fragmented with services, and more complex to monitor holistically.

    Observability in some ways is about removing the human observer. In the NOC, you have staff watching aspects of the application and infrastructure to decide when there is an issue. Platforms that are designed to be observable have the detectors to tell you when there is a problem. It also does not create an assumption that those on-call have existing underlying knowledge of how all layers of the application work in advance because with modern applications, this assumption is not possible.

    Observability is both a tooling approach, but also a strategy for building applications. Applications should be built to be observable, which means the application provides sufficient telemetry to support its observability. Monitoring is basically part of your application now.

    Additionally, application degradation (such as latency) is the new downtime, so the ability to measure depth and breadth of application activity is critical. Observability helps identify reduced performance of the application as well, or impending issues in services that could lead to catastrophic events.

    Automation

    There is one big assumption that comes with the SRE model: automation and the interest to automate. The SRE model enables greater context and visibility across the organization, but it has to do that without increasing human effort. Without automation that is not possible.

    Automation includes:

    • Going from insights from observability to incident response.
    • Gathering context from systems to report, to observability tools and incident response.
    • Mechanisms to support those who are on-call with self-service remediation.
    • Automation to understand similar incidents.
    • Automation to alert/page/call people based on on-call schedules and policies.
    • Automation to recommend responders based on their incident response history.

    Anyone Can Be On-Call

    One of the huge benefits of the SRE model is anyone can be on call. The practices and automation of the SRE model allow anyone to be added to a rotation and on-call schedule. Most companies have this as a dedicated team, and in those who are transitioning from the traditional NOC to modern, that is exactly the first change that takes place. They leave the dedicated physical room and are on-call virtually instead.

    Not just people who support the application are on-call, the SRE model allows for developers and quality engineering to be on-call as well. Arguably, you can’t embrace shift-left without embracing SRE.

    Context

    Automation without data does not create a truly observable and actionable environment. Leveraging data across your delivery chain that can support action is critical. For example, this means the ability to leverage tracing to pinpoint production issues down to a service, or embed more context as part of the payload of alerts to bring more clarity to those on-call.

    Data collection is one thing, but not knowing how you are going to leverage the data makes it useless. The SRE model is obsessed with leveraging data and doing controlled experiments to ensure the data collected supports the uptime and experience for the user.

    Stewardship and Strategy

    Finally, SREs spend more time on stewardship and strategy than the traditional NOC. Some SRE groups run DoJos for the organization to help spread the idea of quality and application support across all technical teams. They will collaborate with developers so they better understand aspects of the application the SRE processes can leverage to support it better. SREs also spend a lot of time creating the strategy of application production support for the organization. Choosing key metrics, deciding how automation will be setup and consumed and creating policies on how on-call should function.

    Before you get upset, SRE does not mean the NOC is dead. The modern NOC can be driven by an SRE model, and I’ve seen this in-place in several companies. The NOC is also necessary to support many on-prem applications.

    What happens is, instead of a staffed room, the NOC becomes a group of engineers who are building automation, setting policies and practices, and stewarding quality across all teams. Similar to DevOps, SRE has elements of culture, principles and practice. Organizations who have a team structure where the NOC is responsible for application support, oftentimes do not change this for SRE, they become the SRE.

    The NOC is changing, and has to change as modern applications become more complex, release velocity increases and users become more demanding. The SRE model is an approach to transform the NOC into a modern version of itself or a whole new organization and strategy. The goal is not only to support applications when something breaks, but to make sure customer’s expectations are met, and systems support current and future development efforts, without increasing the human workload.

    — Chris Riley

  • Atlassian Adds No-Code Automation Tool to Jira Cloud

    Atlassian Adds No-Code Automation Tool to Jira Cloud

    Atlassian announced today it has added a no-code tool to enable DevOps teams to make it easier to customize Jira project management software without having to learn how to code.

    Sean Regan, head of growth for software teams at Atlassian, said Automation for Jira will now become a core part of Jira Cloud that will be made available to all 65,000 customers using Jira software. Originally developed by Code Barrell, the tool was acquired by Atlassian last year. Previously, it had been available as an add-on adopted by about 6,500 customers, he said.

    The goal is to enable administrators that track projects to reduce the amount of time they spend on manually entering data. On average, organizations are spending 51 hours a month on administrative tasks involving the management of projects, Regan noted. Organizations should take inventory of those tasks and use Automation for Jira to start automating the tasks that are the most repetitive, he said.

    Automation for Jira, Regan said, is part of a larger ambitious effort to make Jira software accessible to more than 100 million active end users. By employing a visual tool to automate tasks it should become easier for a broader number of organizations to customize processes by defining rules that trigger events. Organizations will not be forced to depend on developers to write code to create those workflows, he noted.

    Automation for Jira

    Automation for Jira is also part of a concerted effort to modernize a venerable Jira project management application that has been widely employed by software development teams for decades. The ultimate goal is to enable software development teams to spend more time building applications versus trying to ascertain the status of any given development project, said Regan.

    The no-code Automation for Jira tool is also designed to integrate with collaboration tools Slack and Microsoft Teams within the context of a set of best DevOps practices. In fact, Regan noted any time there is an issue on a software development project it almost always comes down to a lack of collaboration between all the stakeholders involved.

    There is, of course, a lot more appreciation for project management software among DevOps teams that typically are trying to organize around multiple projects at the same time. A delay on one project might present an opportunity to reallocate resources to accelerate another. That can’t happen, however, if no one is aware of what bottlenecks exist in the first place.

    Not everyone appreciates all the nuances of project management. The less obtrusive project management becomes the more effective it tends to be. Developers are especially notorious for not always updating project management applications, which usually results in project managers having to nag them to share information that other teams are counting on before they can move forward. Hopefully, there may come a day when all project management applications are updated automatically. In the meantime, the less time spent on manual tasks the happier all the members of the software development team are likely to be.

    — Mike Vizard

  • DevOps Chats: Solving Complexity in Continuous Testing, with Sauce Labs

    DevOps Chats: Solving Complexity in Continuous Testing, with Sauce Labs

    SauceCon 2020 by the good folks at Sauce Labs is just about a month and half away (April 27). As part of our lead-up to the show and our coverage including live broadcasting on Digital Anarchist, we caught up with newly minted Chief Product Officer, Matt Wyman.

    Matt discusses how continuous testing, automation and DevOps has led to better testing. With that though, we are more complex and sophisticated than ever in how, what and when we test. Can’t we just keep it simple? Do we want to keep it simple? Have a listen to what Matt has to say, as well as why he is so excited about this coming event.

    If you are interested in testing at all, do check out the great lineup for SauceCon. Hope to see you there.

    [soundcloud url=”https://api.soundcloud.com/tracks/770790922″ params=”color=#ff5500&auto_play=false&hide_related=false&show_comments=true&show_user=true&show_reposts=false&show_teaser=true” width=”100%” height=”166″ iframe=”true” /]

    Transcript

    Alan Shimel: Hey, everyone, it’s Alan Shimel for devopsy.kinsta.cloud, and you’re listening to another DevOps Chat. Today’s DevOps Chat is meant to give you a little bit of a flavor, a preview for the upcoming SauceCon put on by Sauce Labs, which will be at the end of April. So, about a month and a half away, almost two months—well, a little less than two months away. It promises to be another great event from the folks at Sauce, and they have, really, just a packed lineup of speakers from a wide range of enterprises and startups and tech companies, manufacturing companies. I mean, just a whole gamut.

    Anyway, speaking with me today about SauceCon, about maybe some new developments and trends in the testing market is Matt Wyman. Matt is chief product officer at Sauce. And Matt, welcome.

    Matt Wyman: Thank you. Glad to be here.

    Shimel: My pleasure. So, Matt, let’s get this out of the way first. You recently joined Sauce in, like, January, correct?

    Wyman: I did, January 6th. I am a recent addition to Sauce Labs, and very excited to be here. I’ve been in the DevOps community for some time, worked as the head of product for CircleCI, so definitely a space that I know well.

    Shimel: Sure

    Wyman: But I see this massive opportunity and impact around test, and this fragmented space, and hopefully, we’ll get into this and talk about complexity a little bit. But it just really seems like a huge opportunity and a company that I love and a great reputation, so I’m excited to be here.

    Shimel: Very cool. You know what’s interesting? I mean, of course, CircleCI is in and of itself a great company, too. We’ve—you know, I’ve done a couple podcasts with Rob, the CTO over there.

    Wyman: Yep.

    Shimel: And, you know, they recently, they raised a bunch of money, they’re really becoming a player in the CI/CD space. But it’s interesting that you moved from CI and CD to testing here, and you know, when we look at, let’s say, CloudBees, right, and Jenkins, the Jenkins founder, KK, you know—I’m not even try to pronounce his name; let’s just call him KK. But anyway, KK recently left CloudBees and the Jenkins community to start a new company also focused in the testing space.

    So, I think your move here, KK’s move—I think it shows that, as the whole CI/CD, you know, software delivery pipeline type of industry and community matures, people are recognizing that testing is kinda where it’s at right now, right? That’s the new battleground. And maybe it is, as you mentioned, Matt, because you know, the mission has grown so much more complex than, you know, let’s say pre-DevOps, right?

    Wyman: Absolutely.

    Shimel: So, why don’t you—if you don’t mind, give me or give our audience an idea of where you see or how you see testing has become, you know, more complex.

    Wyman: Absolutely. So, speaking to the CI/CD platforms just for a moment, orchestration in CI/CD has become a very complex problem, and that’s reflective of changes in the software landscape and how people build software, which itself is a reaction to where we started.

    So, we had all these monoliths, these, you know, large systems, we’ve all talked about it, they still exist out there in the world. Most every system that says that they do microservices actually has a monolith somewhere, like, micro-monoliths all around.

    When you’re in the monolith world, testing is all about end-to-end testing. You’re trying to put all the pieces together, validate that everything works top to bottom, and that’s really where quality and test have their roots. And as much as possible, it’s all about trying to automate those difficult processes and make it easier and more efficient to move through all your different test cases.

    But as those entities split up, and as we started to recognize that each component of a larger application needed different types of tests, testing itself became more complicated. And furthermore, it became more than just clicking buttons. At one point, testing was about validation, that if you click a button, you go to the correct page. If you click a button, the right business logic executed.

    But these days, it’s a lot more than that. It’s also validating that the CSS is correct, that the experience is performant and is wonderful and delightful. Companies that have bad user interfaces and bad user experiences don’t win.

    And so, you have this testing world that, on the one hand, is trying to move faster, dealing with a more complex software landscape, and on the other hand, is now broadening in the types of tests that are being run, not just functional testing, but also, if you will, delight testing and trying to validate that the user experience, the customer experience is going to be an excellent experience at the end of the day

    Shimel: Yeah.

    Wyman: And so, that’s how I see this space splitting up.

    Shimel: Absolutely. I don’t disagree with you there. You know, Matt, I almost wanna put myself in the shoes of the test professional and the QA person who, you know, maybe six or seven years ago was hearing that DevOps and this move, you know, agile to DevOps and beyond was gonna somehow make them obsolete. And then other people were saying, “Oh, no, it’s not gonna make you obsolete, it’s gonna free you up to do higher level kind of tasks that are more worthy of your talent and skill set.”

    And I think that has come true, certainly. I think what we’ve seen with test automation has freed up testers to do higher level stuff, but I also think it shifted the—not the burden, but the emphasis on people who know how to set up automated testing, right? You’ve gotta know maybe a little bit of coding, a little bit of scripting, you gotta know some of these open source tests.

    Wyman: There’s a bit of all of the above, don’t you think?

    Shimel: Yeah, it is. That’s exactly it.

    Wyman: The—and it’s further complicated by the fact that the number of devices and environments we’re testing on has also fragmented and increased. And you can’t run the same type of test in every environment, so most software applications have some sort of mobile component to them.

    Shimel: Yeah.

    Wyman: And yet, mobile testing is not automated in the same way that you would automate browser testing. And in fact, in some cases with mobile testing, it’s more effective to be manual and to go through it piece by piece, or to use visual testing to go through it.

    And so, you have to pull together all these different techniques. I think there’s often this perception that, with any new technology or any new change, that it’s going to somehow upset the apple cart and suddenly everyone who has a job doesn’t. And it just doesn’t typically work out that way. I think what we’ve seen is just this increasing complexity, and then also the opportunity to use the right type of testing in the right place. Meanwhile, a lot of the people out there doing quality testing continue to do so, because the number of applications has only multiplied.

    You know, the fact this whole digital transformation and all the buzz words that you hear about that—fundamentally, it’s true. Every business is now a software business, and one of my favorite examples recently is, where I live, there’s a highway called 101, a pretty big highway, and there’s a big billboard on the side that has a, it’s from Wells Fargo, and it has a mobile app on it. And the billboard is not advocating or talking about Wells Fargo’s core business, they’re not talking about loans or lending or savings accounts, it’s talking about their mobile app and the experience of their mobile app. And you better believe that they care about testing it, right?

    And so, it’s more than just—again, I covered this earlier, it’s more than just feature function right now. You have—you need more people who need to look across all the different touch points and then utilize the right type of testing in each area. And so, there isn’t one test solution that solves all of it. You have to use different techniques, because ultimately, you’re managing business risk, and you have to do it all the way from the moment a developer checks in code all the way through to production and validate, if you will, a virtual user. Someone has to go validate that it’s actually working as expected when a customer reaches out to interact with the tool.

    Shimel: Yeah, yeah. And, you know, Matt, you hit on a couple—you hit on web testing, mobile testing. I think one of the things, you know, thinking back to when I was running software companies, testing was always something that meant that we were a day late and a dollar short with, you know?

    Wyman: Absolutely.

    Shimel: It seemed like we never had enough budget to do all the testing we thought we should do, and we never had enough time to finish the testing at least we were going to do. But when I look at the kinds of testing and the amount of testing that goes in today, and all of it pre-deployment and everything—yeah, it’s grown more complex, but I think just beyond pure complexity, I mean, would you say we’re testing more now than we did before.

    Wyman: Well, I think part of the answer there is to dig in on what does it mean to test. So, these days, it’s about risk management. And so, if we’re going to have developers able to check in code and 10 minutes later update production, then we’ll need mechanisms to ensure the production is safe. And typically, that’s done with feature flagging, it’s done with canaries. There’s all sorts of ways to ensure that each change doesn’t blow out production.

    But along that path, it’s also about automating as many of the different possible negative outcomes as you can. And that is what we would typically call testing. So, there’s visual testing, there’s browser testing, there’s unit testing, there’s end to end testing, integration testing. All these are necessary, and you’re trying to compress them all into that 10 minute window, which—you know, most organizations can’t hit that kind of number, but that’s the gold mark if you can hit that 10 minutes from change to production.

    And so, I believe that it’s a matter of thinking about risk and saying it’s not about quote-unquote test coverage with a go/no go meeting where you look at the test coverage—and frankly, there’s so much peer pressure to go that typically organizations do. It’s more about saying, “What is the possible negative outcome, and how do I ensure that I have appropriate coverage for each of those negative possibilities?” And in some cases, you’re going to build tests to simply block and fail that particular change, and in other cases, you’re going to provide monitoring and observability to ensure that, if something negative happens, you can pull it back quickly.

    And if I go very meta for a moment and go well above even what Sauce Labs is doing as a platform, I would suggest that all of that is a part of the overall test or risk management perspective. And ultimately, I think our goal is to then create visibility across the whole thing, so you can manage your risk, manage your test all from one place.

    Shimel: Got it. Makes sense. Now, Scott—Matt, excuse me—let’s talk a little bit about SauceCon. How is all of this manifesting itself, you think, at SauceCon?

    Wyman: Well, one of the fun things for me is, this is gonna be my first SauceCon. So, I haven’t had the opportunity to see—

    Shimel: Oh, you never went? Okay.

    Wyman: I’ve never been, so, this is gonna be my first one. I mean, I’ve seen the lineup, it looks fantastic. I’m hoping to see not only a whole series of really good conversations within our existing community, but also, there are quite a few people that are coming who are Selenium, who are Appium users, developers and whatnot, to share in some of their experiences.

    I know, as a product person, one of the conversations I’m very eager to have is in how we help people shift left. And so, it’s more than just running Selenium tests, it’s about the headless tests, it’s about getting earlier upstream so that we can provide a little bit more of a developer oriented experience. And so, I’m very excited to go have those conversations, and I think the lineup looks good to have it.

    Shimel: I agree as well. So, I’ll tell you, my experience is, you know, if you’re looking for conferences around testing and how—like, what’s pushing the frontiers there, right, and also pulling in the open source testing community, SauceCon is one of the best. And I’ll tell you what I like about what Sauce Labs has done there is, you will see other testing companies represented, mentioned, participating, right? I remember, you know, CA who had bought BlazeMeter, for instance, was involved in SauceCon. I don’t know if BlazeMeter will be there this year or not, but they were there. I know the Tricentis folks also like to participate.

    And part of the reason is because testing is such a big world with so many different facets today, you know, everyone kinda does—you know, they’re not necessarily head on competitors. A lot of this is sort of complementary. And so, it’s really nice to see the community come together. You see it a lot—and maybe this is something that is specific to DevOps in general, I don’t know, but you see it a lot at these DevOps events where, yeah, it’s Sauce Labs throwing the party, but the whole testing community partakes. And that, I think, to me is one of the things that makes SauceCon really special.

    The other thing is, is just the speakers. I mean, you know, like in any vendor/user type conference, you’re gonna get the CEO, the CTO, and I’m sure Matt, you’ll do some presentation. But when you look at the speaker lineup here, you know, you have everything from, like, Google kind of engineers to startups to large enterprises, you’re really getting a good 360 degree view.

    Wyman: What excites me is that the way in which we think about this event, we don’t see it as a sales event. We’re not sending salespeople there.

    Shimel: Right.

    Wyman: A number of my product folks will go, because we’re interested in having conversations. The test market overall is fragmented, but it’s fragmented for a good reason, which is, there are a lot of different use cases, a lot of different problems that people are trying to solve, and quite a few of those folks are going to be there, and so, it’s a good chance to have a conversation if you wanna do, if you wanna know more about visual testing, if you wanna know more about how to use headless effectively or deal with the grid.

    So, there’s this opportunity to share that information and share that knowledge, and I think that’s really what we’re aiming for is an environment that’s a practitioner’s environment. It’s [Cross talk].

    Shimel: Yeah, definitely, in years past—in years past, you know, SauceCon, that’s exactly what it’s been, and I think Sauce Labs has done a great job fostering that, right? It’s good stuff, all around.

    We don’t have a lot of time left, but you know, you just joined in January, you’re fairly new, your first SauceCon, you’re getting a handle around product. But do you feel up to giving us a little projection, maybe, of what we’ll see coming out from Sauce Labs over the next, you know, six months?

    Wyman: Well, I don’t wanna give away too much, but we will have something that I expect to be quite exciting, a new beta labs experience that I think people will be able to go get their hands on and play with, something that moves, let’s call it shift left, a bit.

    And we’ll continue to talk a bit about our analytics and in particular, there’s a new report that we are going to be showing. I think some folks may be aware of it already, but it’s relatively new, it’s called Failure Analytics, where we’re able to aggregate all of the different log outputs and provide intelligence and cohorting of different common errors so that, instead of having to hunt through hundreds, potentially, of failures, we will highlight the common problems, which gives developers an easier time of going and fixing things. Also, it makes it a lot easier to debug across large automated test suites.

    So, we’ve got quite a bit that we’ll be showing from a product standpoint, and like I said, there is gonna be a pretty exciting unveil around a beta project that we’re moving forward with.

    Shimel: I think that’s enough of a tease right there. Hey, Matt, you may not know this, but I’ll mention it for our audience—anyone interested in going to SauceCon, it’s actually SauceCon, S-A-U-C-E-C-O-N dot com, and you can go on there and you can still register to attend. I should also mention that our MediaOps, devopsy.kinsta.cloud team will be there under our Digital Anarchist platform. We will be broadcasting live interviews from SauceCon.

    So, if anyone listening is going to be in Austin for the event—hey, come find the Digital Anarchist broadcast booth or me, and we’d love to hear what you have to say and maybe interview you. You never know. So, yeah, please do that, but check out SauceCon.com for more information.

    Matt, before we wrap up, anything else you wanna add?

    Wyman: I think this is great. I appreciate the opportunity to have the conversation.

    Shimel: Well, now that you’re part of Sauce, you know, we’d like—we do these DevOps Chats pretty regularly, so maybe we can have, maybe we’ll do another one even before SauceCon itself.

    I’d like to—you know, I didn’t wanna put you on the spot today, [Laughter] but maybe in the future, I’d like to hear, what are your top three sessions at SauceCon that you’re looking forward to. You don’t have to answer now, though, but I’m gonna give you a chance to do a little digging, but I’m gonna invite you back on in about two weeks and let’s talk about it.

    Wyman: That sounds great. I think it’d be a good idea to, I assume that we’re at the end, here?

    Shimel: Yeah, we’re wrapping up, and you know what, for our next one, Matt, I’m gonna pick three, too. So, folks, there you have it—stay tuned for our next chat with Matt where, between us, we’re gonna highlight his three and my three—

    Wyman: That sounds like fun.

    Shimel: Favorite talks for SauceCon that we’re looking forward to. Sound good?

    Wyman: Alright, sounds great. I look forward to it.

    Shimel: Alright! Hey, Matt, welcome aboard to Sauce Labs, I think—and you already know it, but you joined a great outfit, a great bunch of people there, and looking forward to seeing you in person at SauceCon.

    Wyman: And likewise—thank you.

    Shimel: Okay, and we’re looking forward to seeing you, our listeners, there at SauceCon, but if you can’t make it, do log onto digitalanarchist.live and you can follow along with us from there.

    Until then, this is Alan Shimel for devopsy.kinsta.cloud, and you’ve just listened to another DevOps Chats. Have a great day, everyone.

    — Alan Shimel

  • Commercial Objectives in the Age of Automation

    Commercial Objectives in the Age of Automation

    When I was 17 years old, back in 1971, I sold orange juice near a busy street corner in New York City. My job was to stand out in front of a fruit stand and dispense quarts of OJ from a machine. It was pretty simple: keep the hopper on the top of the machine filled with oranges and keep the supply of quart jars steady. Then, when a customer came by to make a purchase, I filled a quart jar with juice, took the customer’s money and rang up the sale in the cash register.

    That was my job, rain or shine, in warm weather or cold: keep the machine operational, give the customer the goods and collect the money. Other people had this job, too. Selling fresh-squeezed orange juice to the masses by way of a rather simple piece of automation technology kept us busy.

    But, here’s the thing. If my employer had to choose between me or the machine, he’d have chosen the machine every time. The machine was a gold mine. It made more orange juice in a minute than 10 human squeezers could have done in 10 times the amount of time. In fact, if my employer used humans, he would have lost money. The machine was key to his commercial success selling orange juice.

    Now, hold this thought while I move forward to recent times.

    In May of 2019, the rideshare service Uber went public. In order to issue shares on a public exchange, the company, as prescribed by law, needed to publish a prospectus describing its business model as well as how it intends to use the money it raised through the IPO.

    Every company that’s listed on a public stock exchange publishes a prospectus. Facebook has one, and so does Microsoft. Even World Wrestling Entertainment, the folks that produce action-packed events such as the WWE Super ShowDown and WrestleMania, has one. The prospectus is the way the SEC creates transparency into the finances and commercial strategies of a  company. If you take the time to read one, a prospectus will tell you a lot.

    So I did. I read the Uber prospectus and I found something very interesting on Page 10: “We are investing in technology to power the next generation of transportation. Our Advanced Technologies Group (‘ATG’) focuses on developing autonomous vehicle technologies, which we believe have the long-term potential to provide safer and more efficient rides and deliveries to consumers, as well as lower prices,” stated Uber.

    In other words, Uber is actively pursuing driverless technology as a key commercial objective. Why? Well, to answer this question let’s go back to my days in New York City playing trusty sidekick to the orange juice machine.

    Back then, in order for my employer to make money selling fresh-squeezed orange juice, he needed both me and the machine working in tandem to fulfill the commercial objective to turn some oranges and a glass jar into money. In terms of his commercial objective, I was the weak link in the chain. I got sick. I had bouts of adolescent unreliability. I moved on to greener pastures when better opportunities appeared. If he could have replaced me with a vending machine that sold fresh orange juice he would have. If I were in his shoes, I’d do the same thing. But at that time, orange juice vending technology was not as advanced as it is today. I was lucky, I guess.

    But, that was then and this is now. So let’s go back to Uber.

    Remember, the commercial objective of rideshare is to turn a moving vehicle into money. Right now this involves a cellphone, a human and a car. The cellphone provides the driver with passenger pickup information and routing instructions to get to a destination. The car provides the transportation. The human operates the car in response to and with the assistance of information coming from the cellphone.

    Right now humans are really good at operating motor vehicles and interacting with the cellphone and passengers very much in the same way I was really good at keeping the orange juice machine full of oranges and dispensing the product to customers. But, just as I was the weak link with the orange juice transaction, so is the human in a rideshare. The cost of a human can vary and things can get sticky in terms of legal matters that go with human employment. Yet, the risk is offset by profit the human produces, for now anyway. But, that can and will change. Take the human out of the equation and the profits go up and the risk goes down, provided the underlying automation technology is advanced enough to meet the demands of the situation.

    If you have any doubt that driverless technology will advance to the point where humans can be replaced, think back to how crappy voice recognition was in 1989. It was really, really bad. Now, voice recognition is really, really good, even in a variety of languages. Getting to that level of technical maturity only took 20 years. Now, imagine how good a driverless vehicle will be 10 years from today. I’ll wager it will be really, really good.

    Yes, some people will point to the current fatalities created by driverless automation to assert that human displacement won’t happen. But, if you have any doubt that it will, keep in mind that the were a lot of crashes early on when the Wright brothers took to the skies in 1903. Yet, by 1919 KLM was flying commercially. That’s a pretty dramatic accomplishment in terms of safety improvement for a technology.

    So the long and the short of it is, just as the owner of the fruit stand would have gladly chosen an orange juice vending machine over me, so too does Uber want to take the human driver out of the car. For all intents and purposes, a rideshare vending machine will be the preferred way to meet the commercial objective at hand.

    So, where does that leave humans?

    The conventional wisdom is that as human labor continues to get replaced by machine automation, there will be new, unimagined jobs for those displaced workers. I think otherwise.

    Consider this: around the 1880’s there were almost 200,000 horses in the City of New York. Now, if you can find 400, you’re lucky. Why? Because that much horse labor isn’t needed anymore. Some have gone onto other jobs, such as being a thoroughbred competitor at Aqueduct Racetrack or a tourist amusement pulling a carriage through Central Park, but as far as being the engine the moves street-cars, carriages and mounted pedestrians, that time has long passed. Horse labor no longer meets the commercial objectives of transportation.

    So too will it be with humans who earn a living driving a motor vehicle. They will be displaced. Only this time there is a very good chance that there will not be the number of new, unimagined jobs created that will meet the needs of the broad segment of the population being displaced. Yes, there will be new specialized work, but not at the scale necessary to absorb the number of those out of work. After all, once the automobile came along, the 200,000 horses left behind in New York City did not go on to become thoroughbred racers.

    The point of the analogy is this: the more specialized the work becomes, the more difficult it is to quickly acquire the skills necessary to do the work. For example, some displaced drivers might be able to become data scientists quickly, but a significant majority will not. To assume otherwise is folly.

    Addressing the issue of worker displacement due to advanced automation is a serious problem, one that deserves significant attention. Hopefully, we’ll figure out some solutions that have long term viability. Otherwise, we’re in for some big trouble because no matter what, businesses will continue to advance and embrace automation to meet their commercial objectives. As the saying goes, “an ounce of prevention is worth a pound of cure.”

    — Bob Reselman