Category: DevOps Practice

  • Incidence Avoidance in Action

    Incidence Avoidance in Action

    Today, CIOs are faced with the challenge of making enterprise technologies perform on par with offerings from consumer-facing technology leaders, such as Facebook or Netflix, meaning technology or services being seamlessly available with no performance lag. Of course, these expectations are not always aligned with the realities of managing complex hybrid enterprise systems that were not necessarily designed to deliver this type of performance.

    On the other hand, IT operations supporting new-age “digital” business services are dealing with on-demand resources that are supported by software-defined data centers extending into the public cloud by using serverless computing platforms. This is resulting in a “new generation hybrid enterprise” that must deliver the functionality of, and operate as, real-time infrastructure.

    Lexmark, a U.S.-headquartered global company that manufactures laser printers and imaging products, wanted to achieve zero latency operational performance and enhance its business processes to achieve incidence or error avoidance.

    This article details Lexmark’s IT objective and the solution implemented by Wipro Ltd., a global information technology, consulting and business process services company.

    Problem: Lexmark required a technology solution that would provide visibility into its core business process—managed print services. The solution would also need to factor in other supporting systems and functional processes. The objective was to achieve operational excellence by minimizing errors and risks.

    Solution: To address this critical IT operations problem, Wipro was able to incorporate unique design principles to create an operationally simple, scalable and focused solution that brings IT and business process owners to a common understanding regarding achieving incident avoidance.

    Wipro built a new way of visualizing operations management, based on the fundamentals laid out by IT operational analytics (or AI operations, as it is called now).

    Working only with the tools and data that Lexmark already owned, Wipro and Lexmark created a system that measured the heartbeat of Lexmark’s managed print services business. That heartbeat was synchronized to the printer data collection systems, with the thresholds determined entirely by machine learning techniques. Every underlying system was arranged in a “server room.”  Only out-of-variance conditions are displayed in the main visualization panel, with the root cause just a single click away. This paper provides insights into the challenges faced by IT enterprises to deliver an on-demand solution to clients, similar to the ones offered by digitally evolved B2C companies.

    Digital enterprises that use hybrid environments must respond in real-time and need to achieve incident avoidance, rather than incident management.

    If we look behind the scenes at operation command centers today, we see operations that struggle to keep up the pace. Very few operations have been built from the ground up. In the enterprise world, Severity 1 (incidents that are categorized as high impact by business users) incident resolution times, still run for a couple of hours if IT support is not in a position to find the root cause of the problem. The culprit is often the lack of a proper configuration management database (CMDB), insufficient logging or lack of application discovery and dependency mapping. Every IT professional can recognize these failings, yet projects to correct these flaws never seem to get the necessary capital appropriation. Clearly, a new approach is needed to fix this.

    Identify the Business Process

    The process should start by identifying the key driving force or the heartbeat of the core business operation. Depending on the industry, this heartbeat might be customer orders, service requests or vendor purchase orders. All other systems are connected to this heartbeat. To select the right attribute to monitor as the heartbeat, start with business analysts who have a good feel for the day-to-day struggles of the operation. These analysts often have a series of scripted reports they run to track system health. More advanced analysts might even have automated these with alerts. By leveraging this information and using data discovery techniques, we found that the values can be configured as business KPIs.

    In the case of Lexmark, Wipro streamed the KPI values in real time and used machine and wire data to broadcast the underlying monitoring components by using an existing streaming analytics platform that is supported by AI and machine learning techniques. We found that the amount of data needed to assess process health is time sensitive, and normally less than 24 hours of data is displayed during that time.

    The platform visualization shown above, tracks the creation of sales orders for a business unit. The green line represents the flow of orders through the system. Any anomaly in an underlying system is reflected directly on this flow. This is achieved by streaming analytics and AI techniques that use the business KPIs.

    Apply the Architecture Overlay

    The next step is to subordinate the supporting infrastructure to the business process heartbeat. This feat is accomplished without complex business rules and sophisticated orchestration engines. We call this the “server room” and it is a view of the entire infrastructure on one web page, leveraging a lattice chart format that allows for easy comparison. Each of these underlying components will have a direct impact on the business process.

    Applying the same streaming analytics and AI/ML techniques that identified the anomaly in business process, we identify what is causing that anomaly and can quickly see the problem areas.

    Color coding helps the technician quickly understand the severity of the event. Blue indicates the system performance has not yet violated the set threshold, but an underlying infrastructure issue exists and needs to be proactively addressed. Amber indicates the system has violated the warning threshold. Red indicates the system has violated the critical threshold, a condition that by design we will never allow to happen.

    The user can scroll over any given point and a callout box will display the actual level, as well as a brief note on what has gone wrong and the timestamp.

    Analysts can now instantly focus their efforts on the specific systems that are in an error state, even if an event has not yet created an incident.

    Machine Learning to Define the Thresholds for an Anomaly

    What is normal behavior? This is often the most difficult question to answer because common monitoring and management processes rely on a single data value that was set during implementation. But thresholds must be extremely flexible to capture the ever-changing nature of the business process. Batch jobs that run at midnight, end-of-month closing activities, shift changes and a host of other potential variables must be considered when determining the right thresholds.

    For any component supporting the business process, we need to understand what is normal for right now. To determine that at Lexmark, we applied machine learning to dynamically set the thresholds for each sub-system at the month, day and hour level based on the healthy business KPIs we established.

    Incident Avoidance, Not Incident Management

    To fully understand the potential of this approach, it is necessary to change the way system analysts interact with the system. IT professionals who have been doing system support for several years, may be conditioned to react to the work in their queue. A well-honed incident management process is the enemy of proactive action that can prevent emergencies.

    By aligning the underlying system activity and thresholds with the business process, the IT professional can truly understand the whole environment, not just their individual technical component. The most effective analysts will extend their knowledge into other business areas. At Lexmark, we discovered that we were able to solve “intractable” performance issues by simply adding hardware or capacity.

    Integrated IT operations is not a goal, it is the means by which digital enterprises can be managed in real time. The path to real time management is through service capacity guarantees, performance and availability management and using anomaly detection in the context of the business process to identify issues well before an incident occurs. We advise starting small and building an anomaly detection system for the heartbeat of the process that enables you to see both the forests and the trees.

     

    This article was co-authored by Murthy Malapaka, general manager, Transformation Services Cloud and Infrastructure Services at Wipro Ltd. He helps enterprises digitally rearchitect their operations to run on hybrid IT environments to achieve incident avoidance instead of incident management. He has assumed various technology leadership roles across application and infrastructure architecture domains, specializing in availability and reliability. Murthy has been providing consulting services to CIOs and CTOs in their journey from client server to on demand infrastructure services.

    — Brad Clay

  • SoulCycle Flexes Its Muscles with DevOps and CI/CD

    SoulCycle Flexes Its Muscles with DevOps and CI/CD

    When SoulCycle wanted to improve application development and deployment, including improving services for customers across its 80-plus indoor cycling centers in the United States and Canada, the company turned to Mark Sost, a veteran developer and engineer who worked at several media companies, including Hearst.

    Over the last two-plus years, Sost, who now holds the title of senior director of engineering at SoulCycle, has built-up the company’s engineering and DevOps teams, increasing the headcount from eight or nine developers to about 40 employees now.

    The first major project was revamping a legacy, LAMP-based stack used to support applications to focus more on a modern platform that could take advantage of DevOps methodologies, as well as continuous integration and continuous delivery practices (CI/CD).

    Sost and his team dubbed this new platform Podium. However, Podium is more than a development platform, Sost explained.

    “Podium became the ethos and the methodology, as well as the architecture and application stack for re-platforming Soul’s technology stack in total,” Sost said in a telephone interview. “We moved from that monolithic to more of a service-oriented architecture. As such, we started to break out functionality on multiple applications.”

    The re-engineering also meant investing in new infrastructure, as well as other cloud-based technologies. This includes a multi-cloud approach.

    While most of the legacy applications have now been moved to Amazon Web Services, SoulCycle also uses Google Cloud Platform for Podium and all new developments. Sost also takes advantage of Kubernetes and Docker for container orchestrations, as well as investments in other managed services.

    Other tools in the DevOps arsenal include Jenkins to run unit tests; DataDog and StackDriver for monitoring and analytics for workflows; combing Travis CI, Cloud Builder and GCR for CI; and technology from startup Harness, which provides CD-as-a-service. Sost called Harness the “last-mile” tool needed for application deployment.

    “For Harness, that’s CD for us,” Sost said. “That’s continuous delivery to our various Podium environments. We’re leveraging it for delivery to all our Podium environments. Everywhere from UAC (user account control) during the code review cycle to QA after merge, to production, load test and everywhere in-between.”

    This revamped approach to application development now means that the SoulCycle engineering team has created approximately 30 different apps over the last 24 months, this includes internal apps used within the company environment, and ultimately to customers using the facilities and equipment.

    Additionally, Podium helps create a more unified architecture to help ensure that the entire team—whether it’s DevOps, QA or the production team—can paint a 360-degree view of the problem that needs to be solved and what the implications are for the business once the solution is put into place.

    This is what Sost and his team call “Podium principles.”

    “When we say that we’re building things with Podium principles in mind, we’re talking about the fact that everything is version-controlled,” Sost said. “We have full test coverage. We have everything in terms of Kubernetes manifests to infrastructure automation written down and version control checks it as part of source code. That applications are conforming to more of that 12-factor methodology and that we’re really focused really heavily on developer empowerment.

    “I think for us, that really is a shift that Podium has introduced; a move from writing the code as an application developer and then throwing it over a wall to an operations person—a QA person—to test it and deliver it somewhere,” Sost added. “Instead, we provide a developer the tools and the patterns of principles to go about controlling more of their application development life cycle all the way through to delivery.”

    The results have helped improve the overall SoulCycle experience for customers, which includes:

    • Reducing deployment time by approximately 80 percent.
    • Instead of one hour, deployments now take one developer 10 to 15 minutes.
    • QA verification has been reduced by approximately 80 percent.
    • It now takes three QA engineers one hour to verify, compared to three to six hours previously.

    At the same time, Sost believes that the Podium approach gives developers more control over their projects and lets them focus on writing good code that creates apps people want to use.

    “It’s more, ‘Now, I know what’s involved with getting my application to people,’” Sost said. “Because at the end of the day, engineers are just concerned with writing things that people want to use. … This is how we’re going to give you more control of the code and applications that you’re writing, so that you can see meaningful results quicker, without having to wait for someone.”

    What’s next for Sost and his team at SoulCycle? The answer: Machine learning and a bit of automation to the DevOps process.

    Here, SoulCycle is using Harness tools to log more data and infrastructure monitoring into the platform, which allows the algorithm to learn more about the various development projects. This can make the code better and eliminate errors that come with constant development and deployment.

    “We’re letting it get smarter over time around how it can detect anomalies and understand whether our code was successful because there are going to be times where things slip through unit testing or slip through integration tests and there are even going to be times where they slip through load tests, where things like 99 percent are just not going to cut it,” Sost said.

    — Scott Ferguson

  • How Mainframes Live On

    How Mainframes Live On

    TL/DR: Highly controlled change is sometimes the best answer.

    For much of my career, I’ve worked in mainframe shops. I have never worked on a mainframe team, but I have worked closely with them. I’m in Northeast Wisconsin, and at one point we had the highest per-capita number of mainframes in the world, so pretty much anyone from this area can say the same. They were the “stable core” of the system for which I was the “new shiny”—and at times, that was painful.

    If you’re an established enterprise, even after years of trying to eliminate the mainframe, you probably still have one. They don’t go away so easily because, despite frustrations with rate of change, they do host core systems in established organizations and are reliable. I have seen similar in client server systems that are core to the business.

    We are reaching a point where there are some great products out there to help modernize the mainframe and/or split up client/server applications. Some of them have been around a while (Linux) and are coming into wider adoption, some of them are building on that bit of more familiar interface and many are simply making the UI more familiar to developers like me that only ever developed in a mainframe terminal for college, if at all.

    One of the main reasons why mainframes and future iteration’s applications are “sticky” is because they, and the systems they host, are generally reliable. No matter what you think of the timeline for updates, the data coming out of the mainframe and more controlled distributed applications is considered accurate in most organizations, over most other sources.

    To be clear, there are groups like this from each successive wave of computing. The client/server app that replaced your mainframe customer information system has learned over time that a fault in their system impacts the core of the business, for example.

    The goal is to increase the rate of change, without undermining the reliability. You hear a lot about throw-away instances and “fail fast,” but dropping your billing system isn’t really an option, so these need to be tempered with the knowledge of what failure implies in core systems.

    Make the change, do the modernization, but listen to lessons learned on core systems. Take into account that your informational website being down is a serious problem for marketing, but the billing system being down is a disaster for the company. There is a degree of difference, and the approach should be less about continuous deployment and more about stable deployment. Yes, it can be a scale, and you can start the motion from one to the other slowly to make sure you’re covering your bases.

    In short, assess the risk levels of these systems before deciding how to proceed. This is pretty much common-sense advice—but better to read it and not need it, than to find out when corporate revenues are impacted.

    I worked at one shop where a certain core application was using technology that was a couple of generations old and no longer supported. The pool of available developers was shrinking, but it was an important application. This type of thing is where modernization is critical; having someone say, “We don’t touch that,” is no longer acceptable. That story ends in disaster when the system fails, and no one knows how to troubleshoot—let alone fix—it.

    As with so many things, the balancing act is up to you; determine your organization’s level of risk acceptance, then determine the impacts of this application being unavailable and proceed from there.

    Each step of mainframe development is a little different from what developers coming out of college expect, but there are new tools and mechanisms available of which these developers can take advantage.

    — Don Macvittie

  • Helping the Little Guy: The Power of Open Source Software for Startups

    Helping the Little Guy: The Power of Open Source Software for Startups

    It’s no secret that open source software holds many benefits for businesses looking to reap the rewards of these innovative, collaborative and incidentally free efforts of developers around the world. Even major companies such as Salesforce have opened up their software for developers to test, debug and improve. Other huge players that run on open source software include Netflix and Twitter. In fact, 78 percent of companies run on open source. So, what if I told you these benefits improve exponentially for startups using OSS to launch and scale their business?

    Open source software has leveled the playing field so that even small startups can leverage advanced technologies, without needing the big budget to go with it. Here are the top ways that startups seriously benefit from running on open source software solutions.

    Power and Control

    Startups are always are running under strict budgetary restrictions as they’re just starting out. This means executing their business model in the most economical way, and open source software undeniably allows this by relieving businesses of the need to pay the expensive initial fees of proprietary software. In fact, Linux found that its users save up to 55 percent over commercial solutions, and Barclays bank reduced its software development costs by 90 percent using Linux.

    While it’s likely that down the line they may have to spend money on support, training or bespoke development needs, these choices can be made as per their business plan and actual business traction, and deployed as and when needed.

    Power in the form of expanded capabilities that comes from open source software is also in large part due to the community of talented programmers who build and craft the solution, allowing for quicker troubleshooting and accelerated development. Many hands can deliver powerful results.

    Innovation, Productivity and Agility

    Startups need to be able to experiment freely to understand what works for their business and what doesn’t. If this need to try different options is shackled down by high costs or contractual commitment, they won’t be trying out the necessary paths or making the necessary mistakes to understand which is the best route to take—not to mention the benefit of being able to take advantage of new tools as soon as they become available, especially before other big players that have developed their own proprietary software.

    Open source software allows for this kind of agility, which breeds innovation. Without the requirement to follow the dictates of a particular vendor, startups can explore all the avenues that they need to, until they know the right way for them.

    For example, startups working within AI will need to identify the algorithm that works best for their particular business needs. To identify these algorithms from the library, data scientists have to perform many trial-and-error iterations. This is usually followed by a detailed data analysis and discovery phase. Only after going through these iterative cycles will the data scientist have a full understanding of which algorithm to use, how best to slice and dice the data and how best to get the expected business results.

    If it wasn’t for open source software, going through these cycles would be prohibitively expensive. This is how top companies were expected to create AI algorithms in the past—with huge expenses on manpower and resources. Now, these open source technologies are mature enough to apply predictably, making AI startups easier and cheaper to build.

    Open source software helps startups take huge strides in their productivity levels, too. A study conducted by Frank Nagle, assistant professor of strategy at the Marshall School of Business at the University of Southern California, measured the impact of free open source software on productivity, especially since a growing number of businesses are increasingly using open source software as a key input.

    The study found productivity either always increased or stayed neutral, as a result of open source software—the impact was never negative. For every 1 percent increase in the use of free open source software, profits can go up by $100,000. This is a “huge amount for small firms,” said Nagle.

    Security and Reliability

    Due to its public nature, the software’s source code is likely more reliable than anything built by independent groups of developers. And although open source software is not automatically more secure than proprietary programs, unlike closed solutions, open source software is transparent and available for inspection. So, by opening up the software and allowing anyone to fix broken code that might put it at a risk, companies can utilize the proactivity of the community to enhance the security of their programs.

    Startups that are just starting out may be intimidated by the amount of open source software options that are out there, but this shouldn’t put them off—there’s a huge amount to gain by opting for open source technologies. Between saving on costs and resources, increased capacity for innovation and agility, and having the security of your systems granted by the open source software community and their dedication to great code, the options are countless for forward-thinking startups.

    — DJ Das

  • Building Amazing Apps, Part 2: Optimizing the Back End

    Building Amazing Apps, Part 2: Optimizing the Back End

    This is part two of a series of three articles on building and delivering amazing apps at the edge. To read part one, click here.

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

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

    We’ll break these steps down into three key areas:

    • Front end: Covers the parts of the app that end users interact with.
    • Back end: Looks at the required origin infrastructure to support the app, including databases, application, web servers and more.
    • Middle-mile: Explores the internet, where all the information needs to traverse back and forth between the front end and back end.

    In this article, we are going to explore five things you can do on the back end.

    Distributed Architecture

    In a nutshell, distributed architecture means having origin (back end) infrastructure that is geographically dispersed to maximize availability and performance.

    There are three main types of back end configurations:

    • On-premises: This is where the hardware and software are owned and managed by your organization. This type of back-end architecture is often more expensive and resource-intensive to maintain but offers a higher degree of security and flexibility because you have full control of the hardware and software.
    • Cloud-hosted: This is where the hardware and software are hosted on a third-party cloud provider. This type of architecture runs on dedicated or multi-tenant servers, and is usually more cost-effective to create and manage because some of the cloud providers include efficient infrastructure configuration/orchestration tools.
    • Hybrid: This is where your architecture is a mix of on-premises and cloud-hosted. This is the most flexible and common solution, since most companies that traditionally have relied upon all on-premises architecture are slowly migrating some of their back end to the cloud. For this type of solution, it’s best to use open source, multi-cloud tool solutions.

    The goal for your configuration should be having a back-end system that is geographically dispersed enough (with most locations close to your users) to ensure low network latency, while at the same time avoiding a single-point-of-failure to ensure the service runs, despite any localized outage.

    Regardless of your configuration, the general idea of distributed architecture remains the same: Using data centers where the load is distributed via a global load balancer, and where critical information is replicated across the data centers via fast, fiber-optic private links.

    Here are some concepts you can research that will help you to choose the most optimal, distributed architecture for your needs: virtual machines, containers, microservices, data replication, stateless apps, serverless, distributed processing, etc. devopsy.kinsta.cloud is an excellent resource to learn more about them.

    Generally speaking, you can simplify your origin infrastructure and maximize end-user performance by putting a content delivery network (CDN) between your end users and your back end. A CDN is a super-distributed network of reverse proxies that allows you to put your content very close to end users, minimizing network latency to achieve rapid app interactions, especially when the CDN caches your content on its edge servers.

    Auto-Scaling

    You can optimize costs and performance by choosing an architecture that auto-scales (up and down) depending on current traffic demands. To implement this effectively, you need to monitor global traffic and set triggers that launch infrastructure on-demand so it is ready when needed. Most of the largest cloud services companies support auto-scaling services, and some of them even allow you to tune your settings to favor either costs or performance. One of the easiest ways to implement effective auto-scaling is with CDNs, which can automatically scale traffic with minimal effort just by configuring a set of rules that define what content should be handled completely by the CDN (either dynamically generated at the edge or cached) and what content should be pulled from your origin infrastructure.

    Continuous Monitoring

    Continuous monitoring helps maintain the quality of service. There are many open source tools for continuous monitoring that fall mostly into the following four categories:

    • Infrastructure monitoring: This allows you to keep track of compute resources, storage, network usage, etc.
    • Cloud providers: Most of the largest cloud providers have integrated tools for monitoring your back end in each respective cloud platform.
    • Application performance monitoring (APM): To monitor your application’s framework.
    • Aggregators: Tools that allow you to aggregate and analyze data across several monitoring tools.

    In addition, it’s a good idea to complement server-side monitoring with real user monitoring (RUM) tools to identify whether a specific code deployment impacts performance.

    Performance

    A faster back end makes for a faster front end, and, as we know from part one of this series, performance is a major contributor to user experience. In addition to focusing on improving metrics including latency, throughput and errors (all of which are directly correlated with back-end performance), it’s critical to have a “culture of performance” in your company. José Pérez provides an overview of that concept in his article, “Fostering a Web Performance Culture.” This is a perfect example of how you could implement a culture of performance in your organization, by having performance tools integrated into your IDEs—this can provide instant feedback to developers on how new code performs against a defined performance baseline so that any code that might degrade performance is identified before it is deployed.

    For content that is not personalized, such as a product catalog, news or media assets, you can easily improve performance by putting a CDN in front of your back end (and caching that content on the CDN’s edge servers). Those edge servers are distributed around the world, located much closer to end users than your back-end infrastructure, to minimize network latency and maximize throughput.

    DevOps Automation

    Finally, a big part of setting up monitoring that works (and in responding to failures quickly) is DevOps automation. Building automated DevOps tooling allows you to react to changing conditions automatically, in real time.

    For example, you can use DevOps automation to alert your team via a chat system such as Slack when a deployment impacts the service, with an option to roll back easily the deployment within the chat app. Another great example of DevOps automation is Pinterest’s implementation of a “performance detective” that runs a binary search (similar to git bisect) to determine the offending commit that is degrading app performance after a release. If you combine these two automations, you could detect a performance degradation caused by a release; let the DevOps team know that it has been rolled back and track the offending code in the version control repository. That’s just one specific example among the many ways that DevOps automation can further optimize your back end.

    Coming up next in this three-part series: Everything you need to know about optimizing the middle-mile.

    — Javier Garza

  • VMware Brings NSX Network Virtualization into DevOps Realm

    VMware Brings NSX Network Virtualization into DevOps Realm

    At the Mobile World Congress (MWC) 2019 conference, VMware moved to bring network virtualization into the realm of DevOps by adding support for a declarative programming model and JSON data formats to version 2.4 of NSX-T.

    In addition, VMware is making it possible to use the open source Ansible automation framework to deploy NSX-T.

    Finally, VMware is adding support for IPv6 as well as the ability to now extend microsegmentation all the way to Layer 7 of the application stack.

    Jonathan Morin, product marketing manager for NSX at VMware, said this release of NSX-T not only will become the dominant version of NSX for VMware in the enterprise, it also represents a concerted effort to make network virtualization directly accessible to both developers and IT operations teams alike. JSON support is critical from that perspective because it makes it easier to programmatically replicate the networking requirements and security controls attached to any class of applications.

    Longer-term, JSON support will also make it easier for a wide variety of management tools to consume metrics generated by NSX-T.

    IT organizations must determine to what degree they want to fold network operations into DevOps. Some organizations will simply prefer to provide developers with access to self-service virtual networks, while others will move to expose the declarative application programming interfaces (APIs) in NSX-T 2.4 directly to developers, said Morin.

    VMware expects that, going forward, a hybrid method for deploying and managing NSX will emerge. Developers will want to programmatically invoke network resources as they build and deploy applications. But network administrators will need to be able to access tools to manage those virtual networks over time. To facilitate that process, the latest version of NSX-T has been updated to add support for an HTML5-based user interface. The goal is to not just distribute NSX-T, but also make it accessible to everyone, said Morin.

    Rather than requiring organizations to upgrade switches and routers to enable programmability, VMware has been making a case for employing network virtualization to create a programmable overlay. That approach serves to make the underlying physical network agile enough to be employed with a DevOps framework without requiring organizations to upgrade the entire physical network.

    In many ways, networking represents the last major frontier to which DevOps processes need to expand. It’s possible for developers to spin up a virtual machine in the cloud or in an on-premises environment in seconds. But it can still take weeks to manually provision the networking resources in an on-premises environment that a virtual machine requires. VMware has been advocating for the deployment of instances of NSX in both on-premises IT environments and in public clouds to provide a consistent network overlay that can be programmatically invoked and automated.

    It remains to be seen to what degree network operations will be pulled into DevOps processes going forward. But the one thing that is clear is that IT organizations have the option to decide to what level they might want to achieve that goal.

    — Mike Vizard

  • How SRE Creates a Blameless Culture

    How SRE Creates a Blameless Culture

    People in tech love to praise failure as essential to innovation. But at far too many organizations, when failure happens, it is punished. When an IT system goes down, an individual or a team is immediately ID’d, blamed and shamed. This is counterproductive. Blame damages companies by creating a play-it-safe atmosphere and stifling innovation; even worse, when mistakes are made, they are often hidden.

    Fortunately, more and more organizations are recognizing the damage that blame can do and embracing a blameless culture. This is a big shift, yes, but companies can make the move to blameless—and make it stick—if they bring site reliability engineering (SRE) best practices to their technology teams.

    Why Blame is Bad

    I’ve worked at several fast-growth companies that suffered under a culture of blame. At one, we were scaling quite rapidly. Change was constantly being introduced to the infrastructure, which meant that it broke all the time.

    Because we had customers running their core business on our systems, our reliability requirements were very high—so high that for a while we stopped feature development altogether, in fear that new features would bring our systems down.

    This was difficult enough, but the culture of blame made it worse. There was no psychological safety net and fingers were pointed constantly. There was an us-versus-them mentality—engineers versus non-engineers, developers versus operations, developers versus developers. Developers dedicated way too much mindshare to protecting themselves and their domain.

    In a blame-rich environment, developers who should be delivering concrete results spend too much of their time in meetings trying to justify their work. There is a culture of retribution for mistakes. This leaves little room to learn and grow from failure because developers get harassed by management when they do make mistakes, or they get fired.

    Your best people—those empowered to make decisions—see their responsibility undermined and go elsewhere. Creativity and innovation slow to a crawl. Meanwhile, competitors run ahead.

    Why Blameless is Better

    In a blameless culture, everyone feels safe and no one is afraid to make mistakes. It’s a psychologically secure environment, where true DevOps can happen. Developers feel confident enough to express their ideas and take chances. Development folks and operations folks collaborate well, and everyone is aligned on the problem.

    The work environment is positive and workers are assumed to be doing their best. When mistakes happen, people aren’t blamed. Instead, any error is viewed as a manifestation of an underlying vulnerability in the systems. Attention is focused on fixing those vulnerabilities and, as a result, systems are constantly improving.

    How to Get to Blameless

    Let’s say you just had an outage and your database crashed. Don’t start by placing blame on a team or individual. Rather, start by conducting a postmortem. Ask questions and find the answers: Why did the database crash? Because Alex pressed the wrong button. Well, why? Because we didn’t have a system in place to enable automatic checking or a review process. So why did we not have that?

    Now you’re getting to blameless and you’re reaping the benefits. You’re having a productive conversation and you’re focused on fixing your systems, not affixing blame. It’s not about Alex pressing the wrong button; it’s about how your organization is not set up to ensure success. It’s about this vital opportunity to learn from a mistake and get better. Don’t fire Alex. Put a solution in place so the problem doesn’t happen again.

    How SRE Can Help

    To get to a truly blameless environment, you need to implement SRE best practices. Why? Because SRE creates ultra-scalable and highly reliable software systems, by building in automation and tooling—moving the human element out of the picture and focusing on the systems.

    One of the founding principles of the SRE movement is blamelessness. By implementing an SRE team and establishing SRE practices, your organization can move from the traditional operational model of break-fix to an environment that applies a development approach to IT operations, with the goal of improving reliability via automation, continuous integration and delivery.

    For this to happen, you will need a SRE champion to quarterback your SRE effort. You will also need organizational buy-in to blamelessness. It has to be practiced top-down and have the full support of all leaders in the organization.

    Tooling is critical, too. Look for tools and dashboards that can quickly do postmortems and find action items that need attention, that can identify the most commonly impacted services, products and customers, and the contributing factors that most often lead to incidents. The right tools will help you resolve incidents faster, by providing a clear overview of metrics related to incident identification and the actions that need to be taken.

    You want to move fast and be innovative. But can you do it reliably? With a blameless culture, you can. You’ll have a safe environment that attracts and retains the best talent. You’ll move quicker, because you’ll be focused on fixing systems that break and finding out why—not the blame game. By delivering a higher degree of reliability, you’ll build greater trust with your customers.

    You’ve heard the saying: Failure is not an option. In a blameless environment, failure is always an option—because it means that systems are always improving and innovation is always happening.

    — Ashar Rizqi

  • SauceCon Speaker Profile: Richard Bradshaw

    SauceCon Speaker Profile: Richard Bradshaw

    This is the sixth in a series of articles highlighting speakers at SauceCon 2019. SauceCon brings together the global community of Sauce Labs users and continuous testing experts, to learn from each other and level up their automated testing and continuous delivery skills. This year’s event will be held April 23-25 in Austin, Texas.

    Richard Bradshaw is known for running the Ministry of Testing, speaking at events all over the world and for being the “Friendly Tester”—a nickname given to him by a developer.

    However, one thing toward which Richard isn’t 100 percent friendly is the Test Automation Pyramid. He says it can and should bring about conversations, but thinks it lacks too much to function as a solid automation strategy, which is how many people use it. At SauceCon 2019, Richard will present some other options in his talk, “Pyramids Are Ancient – Let’s Talk Automation Strategy.”

    Richard hopes that people will take away the fact that to truly be successful with automation, you need to fit automation into your overall testing strategy. During his talk, he will review the steps that he takes when conducting an automation audit, steps attendees will then be able to immediately take back to work and begin applying. “I also hope that observing me critique existing models will motivate them to do the same to some of the models used in their current workplace, and identify ways to improve their approach,” he said.

    Richard is well-qualified to help testers improve in this area. As the BossBoss (aka CEO) of the Ministry of Testing, his primary role is to ensure they stick to their mission of “co-creating better testers.” Richard and his team offer numerous ways to learn and share testing knowledge. They run the TestBash conference, manage an online learning platform called The Dojo and host meetups all around the world.

    When he is not working or thinking about work (a rarity!), Richard loves cooking up a storm, hiking and traveling.

    You can hear from Richard and more than 30 other expert speakers at SauceCon 2019, the third-annual Sauce Labs user conference. To see a full list of presentations or to register, visit the SauceCon website.

    — Rebecca Cramer

  • What AI Could Mean for Developers

    What AI Could Mean for Developers

    Artificial intelligence has been dominating the tech news headlines for a few years now, as the innovations in the sector keep rolling out at increased rates. The technology is, for lack of a better term, awesome, and when used correctly, it can have tremendous effects. We have already begun to see artificial intelligence in the consumer sphere take off at lightning speed.

    Artificial Intelligence is in More Things Than You Think

    Smart assistants, such as Google Home, Amazon Alexa and Apple’s Siri, have all dominated their share of the market with intuitive daily assistants that can keep track of your schedule and tell you the weather. They can even tell jokes—which may or may not leave you in a state of disrepair.

    Looking to the future, we also have autonomous vehicles, which will change our lives undoubtedly by potentially limiting traffic collisions and deaths. That is the true endeavor of technology: to change our lives in such a way that they are never quite the same.

    Artificial Intelligence Development is Open to All

    Development of AI programs is being accelerated due to the availability of AI libraries. With these powerful libraries, development teams are able to build custom code on a complex pre-built infrastructure. Google, IBM and Microsoft all have their own AI APIs that programmers can use to create better products.

    Using paid APIs, developers can use advanced programs developed by tech giants in their own applications. Google Cloud AI provides a suite of machine learning services. You can venture into other APIs also powered by AI. For example, you can use Google’s Cloud Speech API, which uses AI to dynamically convert audio to text in an existing application.

    TensorFlow is freely available to help programmers, developers and engineers use machine learning algorithms to better manage and classify data. All of these APIs empower development teams to dig deeper into deep learning.

    What Advancements Mean for Developers

    The goal of the openness of AI development is to create a new normal brought to life by the endless innovations of the tech industry.

    Without hesitation, we can call AI the next great invention. It has an ability to completely reshape the face of our world in such a way, that this current life will become one of distant fondness and inelegant trite labor. Indeed, the developers of AI will be contributing to the total revolution of life as we know it and the consequences thereafter.

    This is why it is so important to get it right. Using a guideline to build the future will ensure that it can handle the weight of use, without failing itself into obscurity.

    Innovation Means Opportunity

    Ultimately, AI is at its best when it fixes a common problem and is developed with best practices. Because the technology is so new, developers must work around the clock to create applications and get them to market so that their impacts, if any, can be registered and used for analytics. Developing AI is much bigger than a simple web application or smartphone app.

    The pure potential of the tech alone is enough to incite the most lethargic to action, but development will be in vain if not for best practices. Once developers around the world start to follow a development guide, it will increase the fluidity of innovation and knock down any barriers in its way.

    This ensures that developers can share ideas and technology easily, without being in the dark when it comes to the shared development process. Artificial intelligence is an ongoing innovation that may never cease to improve on itself.

    Conclusion

    In this article, we examined the best development practices in AI so that you and your team can create AI applications with the future in mind.

    In fact, the pursuit of humanoid AI, upon its completion, will most likely give us its own revolution in the tech industry as it slowly becomes pervasive in all industries. There is a beauty in contributing to grand goals. You and your team should not be limited or sidelined by a lack of knowledge about best practices when developing AI applications.

    There’s a wealth of resources for developing AI programs through the use of existing AI libraries. There’s plenty of help from the AI community, who are all pursuing a greater utopia with AI—and your team should not be left in the dust.

    — Anthony Coggine

  • Top Trends in DevOps for 2019

    Top Trends in DevOps for 2019

    DevOps is poised for healthy growth over the next several years, with analysts large and small weighing in with forecasts. For instance, IDC predicts the worldwide DevOps software market will reach $8 billion by 2022, up from $3.9 billion in 2017. Similarly, Grand View Research estimates the global DevOps market will hit $12.85 billion by 2025, registering a CAGR of 18.6 percent.

    Below are some of the most influential trends driving growth in 2019.

    DevOps Instrumentation in AI and Machine Learning will Increase Productivity Gains

    Web-based forms are the nemesis of process automation. Everyone dreads manual forms, but that’s what organizations use when they want to capture data from customers, employees or partners.

    AI and machine learning technologies are mature enough to reliably process voice, video, text and images. That means data-enriched forms could be filled out simply by making a phone call, taking a video, taking a picture or some other natural activity. The analog inputs from the external world are captured digitally and automatically.

    Of course, the error rates in such conversions would depend on how well the AI models have been trained and how well we use the real-world input to enhance the model. DevOps-level instrumentation needs to be introduced in the pipeline. That way, either the customer or the person in-loop will be able to take these errors as inputs for enhancing the accuracy of the models.

    Key Management is Key for DevOps

    In 2019 and beyond, data usage will be closely monitored as GDPR becomes a reality and similar privacy laws are passed across the globe. This is when data tagging becomes critical. Therefore, tools related to data tagging and master data management will become crucial for tracking the origin of data usage.

    Sensitive data will need to be encrypted in rest and in motion. Along with data encryption comes the important responsibility of managing encryption keys. Not only should the keys be stored securely, they also may need to be rotated. Key management services that offer such functionality will become commonplace in the DevOps world.

    Container Adoption Increases with Data Locality Demands

    Data locality is driven by countries that mandate data must reside within their geographical boundaries. Enterprises using SaaS or PaaS will use country-specific public clouds or even private clouds. As a result, critical data and applications will have to be deployed across geographies. Deployments will become more complex due to geographical expansion as well as agile development methodologies.

    In response, container-based development, release and deployment models will become commonplace within the enterprise. While containers offer many advantages by creating siloed workloads, they also increase the demand for sophisticated monitoring tools and technologies that help consolidate the view of these applications.

    The Compiler is the New King of the Data Center

    The demise of Moore’s Law is not helping the CPU keep up with increasing workloads in the data center. To bridge the performance gap, modern hardware such as GPUs, FPGAs and ASICs will infiltrate the data center.

    Developers will start using higher-level languages such as OpenCL and CUDA, and the compilers will generate code to run on the various hardware, depending on deployment-level input including workload, hardware configuration and data size. DevOps practices will have to start befriending compilers so that code can be generated just in time, very close to the point of deployment.

    Technological advancements, security requirements and legislative changes will impact the professionals within this sector, which is growing at a rapid pace that could see it double within five years. As developers prepare to manage a higher volume of sophisticated data, an increasing amount of DevOps solutions will enter the market to further automate processes, accelerate deployments and address the above trends.

    — Shailesh Kumar Davey