devopsy.kinsta.cloud

Category: Application Performance Management/Monitoring

  • Build Better CX Across the Entire User Journey with AIOps

    Build Better CX Across the Entire User Journey with AIOps

    Ready or not, digital experiences are now the gateway to customers and the standard-bearer of a company’s brand. Yet, as apps become more distributed, more intelligent and more real-time, they continue to run on infrastructure that resides within on-prem data centers as well as multiple public clouds. This complexity is underscored by gaps across IT teams, leaving businesses, developers and operations teams working in silos without a single source of truth, exposing risks that can inflict not only severe damage to an application’s performance and reliability, but also eventually exposing the entire business. 

    For IT teams, understanding their applications is key. Not only are they the backbone of any organization, but they also hold invaluable data on customers and their decision-making habits. Having complete visibility is critical in today’s multi-cloud and hybrid cloud world.

    When IT teams are able to work quickly and intelligently, they consistently deliver a strong customer experience–avoiding the risk of creating opportunities for customer disengagement and abandonment. Recent research shows that nearly 84% of respondents said they have experienced problems with digital services. As a result, 40% reported switching suppliers due to a poor digital experience and 63% have actively tried to discourage others from using a service or brand if they have a bad digital experience.

    What’s the way forward and how can these existing silos be eradicated? 

    How to Build Better CX

    IT teams are faced with a conundrum–they’ve been asked to manage app complexity while simultaneously navigating operational silos that make collaboration, data exchange and problem resolution incredibly challenging. The way forward lies in a collaborative approach across traditionally siloed teams that leverages artificial intelligence (AI) and machine learning to uncover hidden bottlenecks and resolve issues before they can impact the end-user.

    Transformational CIOs need their teams–across app and infrastructure owners–to speak a common language rooted in what’s important to the application performance, user experience and the business impact. They need infrastructure decisions in service of the application, which will ultimately drive business performance. They also need application teams to be able to go deeper and quickly identify underlying infrastructure that may be contributing to poor application performance. 

    In order for true collaboration to take place, the first step is to increase visibility across the IT organization by providing a common view of correlated data across domains that provides contextualized insights to better collaborate and create a superior digital experience.  

    For application teams, this means gaining insight into the users’ most transited application journeys, helping to clearly identify application bottlenecks and abandonment and to triage efficiently. For the infrastructure teams, improved visibility means having insight into infrastructure constraints impacting app performance so that teams can correlate the user experience to any underlying infrastructure in real-time. Through this increased visibility and context, application and infrastructure teams can clearly identify respective action items and move swiftly to resolve the right issues, at exactly the right time.

    This notion of fill stack visibility and correlated insights that drive action is a mindset commonly referred to as AIOps.

    Enter AIOps

    While it may be true that the emergence of today’s modern application and infrastructure environments has provided the speed and flexibility professionals demand, the numerous services have unleashed a deluge of data on the enterprise IT environment. Automating tasks has helped teams to free up some bandwidth for operations and planning, yet automation alone is no match for today’s increasingly complex environments. What’s needed is a strategy focused on reducing the burden of mounting IT operations responsibilities, and surfacing the insights that matter most so that businesses can take the right action.

    So, what are forward-thinking IT professionals doing to stay ahead of the curve? 

    Many are applying an AIOps approach to the challenge of environment complexities. AIOps leverages advances in machine learning and AI to proactively resolve problems that arise in the application and infrastructure environment. This is so powerful because using AI to identify potential challenges doesn’t just help IT professionals get ahead of problems, it helps companies avoid revenue-impacting outages that jeopardize the customer experience, the business and the brand. What’s more, an AIOps strategy can provide:

    • Intelligent alerting that can be trusted to indicate an emerging issue. By ingesting data, AIOps platforms and technology can play a pivotal role in not just automating existing IT tasks, but identifying and managing new ones based on potential problems detected.
    • Automated root cause analysis and business impact assessment. With the help of AIOps technology, this can be achieved, providing increased agility in the face of potential service disruptions or threats, and without additional drain on resources.
    • Automated remediation for common issues. With an AIOps platform, it’s easy to not only automate remediation for known issues, but unknown issues, too. That’s because it can ingest data and also provide more intelligent insights as a result of it.

    The path forward is clear. Digital businesses are not only the future but they are today’s norm. Any IT leader looking to succeed needs to rethink their overall approach and embrace a future that includes complete visibility of their technology and application stack, and also a strategic approach that keeps their teams operating one step ahead of the curve.

    — Whitney Satin

  • New Relic Extends Reach and Scope of AI Capabilities

    New Relic Extends Reach and Scope of AI Capabilities

    New Relic this week announced it has extended the capabilities within its New Relic AI module to include support for additional data sources and provide access to more advanced analytics.

    Integrations with Splunk, Grafana, Prometheus and Amazon CloudWatch are now provided along with support for a number of incident management platforms, including ServiceNow, OpsGenie and VictorOps. New Relic AI previously provided support for the incident management platform from PagerDuty.

    DevOps teams can also surface more details about anomalies, including attributes that caused spikes, related signals to investigate root cause by looking at what happened around the anomaly and view upstream and downstream dependencies.

    Guy Fighel, general manager and group vice president for New Relic, said these and other capabilities being added to extend the capabilities of a monitoring platform that as a software-as-a-service (SaaS) platform provides a natural focal point applying machine learning algorithms to the massive amounts of data required to inform an AI engine.

    Other new capabilities being added to the platform include the ability to infuse correlations with decision logic to drive custom decisions and greater transparency into why and how correlations are performed.

    New Relic AI has also been enhanced to reduce the number of extraneous alerts that might be generated in addition to providing insights into the rate of total incidents correlated, total correlated issues, rate of noise reduction and the most common reasons why incidents are correlated. New Relic AI also provides access to a configurable set of filters to specify a grace period for each issue priority.

    Fighel said the goal is to make it possible to continuously evaluates telemetry data for anomalies and then share those insights via existing collaboration tools. To accomplish that goal, New Relic AI ingests multiple data types, including alerts, logs, metrics and deployment events.

    New Relic doesn’t see AI replacing the need for IT teams anytime soon. Rather, Fighel said AI will augment existing IT staff in a way that enables them to determine the root cause of any issue faster. Monitoring tools accessed via the cloud make an ideal platform for infusing AI into a service where data already reside, said Fighel. In contrast, other platforms require IT teams to aggregate massive amounts of data to enable an AI model to be trained.

    There’s naturally a high degree of skepticism when it comes to applying AI to IT management, but Fighel said it’s only a matter of time before AI capabilities are taken for granted. In fact, as IT environments continue to become more complex and there is an increased focus on driving down IT costs in the wake of the COVID-19 pandemic, it’s now only a matter of time before AI technologies become more widely adopted.

    In the meantime, DevOps teams should expect many of the rote tasks they need to perform today to become increasingly automated. That might make some members of the IT team uncomfortable, but before long most IT professionals won’t really miss aspects of their jobs that today are little more than pure drudgery.

    — Mike Vizard

  • APM and Application Stability: Where Two Monitoring Roads Merge and Diverge

    APM and Application Stability: Where Two Monitoring Roads Merge and Diverge

    In software development, application performance management (APM) is one of the grown-ups in the room. Not only has APM been around for a long time, but its solutions have evolved over several generations, making it one of the more mature product categories. 

    APM’s longevity makes perfect sense when you consider its fundamental purpose, which is to provide organizations with a way to understand the performance characteristics of their software. Value is delivered by alerting infrastructure teams when applications are performing slowly or poorly, and APM has the vast experience to do this job well. 

    If APM is one of the old-timers in software development, then application stability is the new kid in town. With the rise of mobile apps and iterative development releases, application stability has answered the widespread need to monitor applications in a new way, shifting the focus from servers and networks to the customer experience. 

    The emergence of application stability has caused some consternation for die-hard APM fans. However, these two solutions embody very distinct monitoring focuses, which leads me to believe there’s room for both tools, as well as different teams for both.

    APM: The Engine for Infrastructure and DevOps Teams

    Before the cloud, organizations supplied their own physical hardware and monitored components such as RAM, disk space, CPU and memory. If you ran out of any of these resources, you were screwed. 

    And that was the beauty of APM: It enabled the people running the applications to anticipate when they’d need more resources. 

    Of course, rather than monitor physical machines, today’s infrastructure, SRE and DevOps teams monitor cloud instances. Gone are the days of running out to Best Buy and lugging back new hardware. Instead, a simple request for a new instance is submitted to a cloud provider, and instant access is received. 

    Rather than make APM obsolete, as some feared, the cloud presents two good reasons for continued reliance on this tool.

    1. Apps Can Be Resource Hogs: A cloud instance is simply a slice of someone else’s computer, which means you still need to know when you’re close to running out of resources on this virtual machine. In fact, extra care is needed these days because you’re likely to run out of space more quickly.
    2. Money Still Doesn’t Grow on Trees: The ease of access to infinite cloud resources means that software companies may fall into the habit of throwing money at problems rather than figuring out how to streamline usage and costs through better efficiency. Companies can end up paying a ton of money to run apps if they continuously spin up more cloud instances without thorough consideration of the cost and need.

    And that’s where APM steps in. Its main purpose is to help infrastructure teams figure out capacity planning. With the cloud, questions shift to include:

    • How can I better manage my cloud instances and optimize usage? 
    • How can I make sure I don’t give ludicrous amounts of money to cloud providers? 
    • How can we tweak and optimize the cloud to reduce costs?

    These are the types of things that APM does extremely well. Anytime you need to figure out how to optimize your current resources or when to buy a new server or cloud instance, APM tells you. This information is invaluable to the people running the applications, namely the infrastructure or DevOps team.

    Application Stability: Where the Tires Meet the Road for Engineering Teams

    Now, let’s be honest, APM doesn’t have its strongest showing when the person who runs the app is also the person who builds the app. And that’s exactly the scenario presented by mobile development and iterative coding. 

    Rather than going through long development cycles, software now gets pushed to the web on a daily basis, and mobile apps tend to have weekly or biweekly release cycles. This release speed is not only encouraged but expected in agile software development.

    That means the chasm between building and running apps has shrunk, especially for mobile apps. More often than not, the people building the apps are the people releasing them. There is no gap. And, with mobile, companies no longer need to worry about expensive physical hardware but rather about the end user experience. The customer becomes the focus.

    Unfortunately, APM is perhaps a little too set in its ways to help you do that. But it’s not APM’s fault. These requirements are not what APM is inherently built to do. It’s great at detecting problems and alerting infrastructure teams so they can toss the issue over the fence to the development team. However, its core strength isn’t providing information on how to fix the problems because it wasn’t built with the developer audience in mind. 

    Trying to refactor APM to help with stability and error issues is like tuning your engine when you have flat tires. They are completely separate components of the car, built for different purposes. You can tune the engine all you want, but it isn’t going to move the car unless you focus on why there isn’t air in the tires.

    In today’s iterative world, development teams care a lot more about how apps are running. There’s a demand for fixing actionable items. Developers want to know exactly what’s broken, what to fix right now and what can wait. In short, developers want aggregation and automation of errors. They want to know, “Do we build or fix?” 

    This trade-off between building new features versus fixing bugs is one of the key factors behind the adoption of application stability management tools. Developers need answers to several questions:

    • Where are the errors in the code?
    • How can we get to those bugs and fix them as soon as possible?
    • How can we tie bug fixing into our planning for the week? 

    Whether running sprints or building in an agile manner, development work is planned in advance. Developers want to figure out how much new feature work will be included in a sprint versus how much bug fixing is required. And they need a tool that helps them automate the answer to that question.

    Benefits of Application Stability

    The beauty of application stability is that it brings together the errors captured by APM and enables developers to see at a glance which ones are worth fixing. As a result, five major benefits arise.

    1. Increased Efficiency: Companies eliminate the problem of infrastructure teams tossing issues over the fence to development teams. Valuable time is saved because application stability tools remove the game of telephone between the two teams and deliver bugs directly to the team that will fix them.
    2. Stronger CSAT: The time to fix bugs goes down dramatically when the person who wrote the code fixes the code. With diagnostic information in hand from the application stability tool, software engineers innately understand what the code does, what the bug means and how to fix it. Faster resolution of bugs that impact the end user experience means that customer satisfaction levels (CSAT) are less likely to drop.
    3. Error Prioritization: Application stability tools group bugs by root cause, making it easy for developers to get a sense of severity at a glance. It’s much easier to determine what to fix first when developers can see which errors are most costly, which affect the most customers, and which bug is impacting a key customer.
    4. Tool Synchronization: Taking it one step further, application stability tools are tied into project management suites. Bugs map directly to tickets created in Jira (or whatever tool is used), and tickets update automatically as priority changes.
    5. Stability Scores by Release: Application stability enables product and development teams to see stability scores by release. Since it’s common to have multiple app versions live at the same time, especially with mobile apps (where DevOps isn’t really involved), companies can’t rely on a single stability score. Teams need to see stability by release so that it’s clear exactly where the errors are and what impact they’re having on users.

    What Percentage of Your Development Team Has a Login to Your APM?

    I’m often asked whether I think application stability will replace APM, and my answer is simple: no, I don’t. APM remains an essential part of developing software, and organizations still need to understand when they’re about to run out of resources and when there’s poor performance. 

    Instead, I see these two solutions co-existing as adjacent categories but helping different teams. Application stability delivers prioritized errors to developers for fixing, while APM works well for enabling ops teams to raise red flags on high error rates and reduce cloud spend.

    Some of you may be thinking to yourself, “Well, my APM product does what you’re describing for application stability, so I’m sure my developers are fine using it.” To which I poise the following challenge: What percentage of your dev team has a login to your APM? What percentage logs in on a daily basis? And, if they do use it, do your developers like it?

    The answers to these questions may surprise you. After all, APM wasn’t really built for developers or for keeping end users happy. In contrast, application stability was born at the customer layer and is designed specifically to monitor the front end and ensure strong customer experiences with web and mobile apps. 

    Once you’ve had a chance to hear from your dev team, it wouldn’t surprise me if you discover that they’re pretty excited about the new kid in town.

    — James Smith

  • Uncover the Secrets in Your Apps Through Observability

    Uncover the Secrets in Your Apps Through Observability

    When it comes to your applications, the question to ask yourself is: “How helpful is monitoring if you aren’t proactively capturing the data you need to understand what is causing the errors you find?” The answer: Not very. That is why it is important for us to go beyond monitoring and work on expanding our capabilities in terms of observability.

    When applied to the world of software, observability is how well you can understand what’s going on inside your application based on accessible outputs. Looking at this from outside the realm of errors and application failures, etc., observability might describe how well a developer understands how a certain feature works the way it does.

    This example clearly shows that the metrics and context needed to attain what we can call a reasonable level of observability depends on the requirements of the individual system. We wouldn’t necessarily expect a developer at one company to understand how the features of another company’s application work behind the scenes. Likewise, an e-commerce application and a healthcare system will require different metrics to be observable.

    Bringing Observability to the Team

    Every company that operates software has at least the most basic level of observability thanks to log files. Unfortunately, in most cases we don’t know ahead of time what’s going to break, meaning no data gets logged. Occasionally, we may have a hunch that a certain method will be more likely to fail but even then, the data that’s written to the logs is usually shallow and requires additional investigation and context.

    A key measure of observability is how well you can answer “why this happened” without needing to ask additional questions. Teams that rely heavily on log files to understand and troubleshoot issues generally have low observability, as we all know that the logs often lead to hours (if not days) of follow-up questions. To improve observability, it’s important to focus on proactive solutions.

    Organizations, especially at the enterprise-level, use much more than log files to collect data around application errors and slowdowns. Application Performance Monitoring (APM) tools also play a significant part in most teams’ tooling stacks. Traditional APM tools provide additional context by helping teams identify when and where their application is experiencing performance or availability issues.

    These tools, and more, are commonly used by companies to monitor application behavior and to investigate the root cause of issues. Each tool that provides additional context into the internal function of the application increases our observability. Once your tool stacks provide the full context needed to understand the root cause of any issue, you’ve reached a reasonable level of observability. 

    Creating a Culture that Supports Observability

    Just like with every other buzzword in the industry–CI/CD, DevOps, etc.–achieving a reasonable level of observability means cultivating a culture that values and supports such a goal. There are several layers that need to be addressed and integrated together, but let’s break it down.

    The first step is to create a quality-focused, team-wide engineering mindset toward system hygiene. From beginning to end all members of the team should be trained to build and employ code with quality, first and foremost. The mindset of engineers must go beyond the desire to write high-level code, but also involve the planning process and understanding the purpose behind code changes. It is using foresight to plan for the unpredictable as much as we can.

    We all know that releasing code to production is basically “sending it out into the wild,” and we can all do a better job of making sure we have all the equipment we need to understand its behavior. That includes our mindset, as it forces us to consider our goal much earlier in development, namely by answering the following questions:

    • What are we trying to improve?
    • How can we measure success or failure?
    • What metrics do we need to measure this?

    Once this has been established, radical transparency and open communication follow naturally and further enable improvements in this area. When standards are established and issues are clearly communicated, problem areas in development can more easily be identified and resolved.

    Without the human aspect in place, no tool in the world can give an organization a reasonable level of observability.

    Conclusion

    Observability is about more than just monitoring your system–it’s about understanding it. In order to achieve a higher level of observability, tooling and culture are two major factors that should be addressed. There are many different ways to attain the best level of observability for your organization, so understanding what you need in order to be proactive is crucial.

    — Chen Harel

  • Compuware Shifts Mainframe App Testing Left

    Compuware Shifts Mainframe App Testing Left

    Compuware today announced it is making it easier to shift application performance testing further left on to the shoulders of developers by adding support for a REST application programming interface (API) to its application performance management (APM) platform for mainframe applications, along with a plug-in for Jenkins continuous integration/continuous delivery (CI/CD) environments.

    Sam Knutson, vice president of product management for Compuware, said during the current economic downturn brought on by the COVID-19 pandemic, organizations will find it is now more imperative to shift more responsibility for managing all aspects of application development toward developers. Many organizations simply won’t be able to afford to retain IT specialists such as application testers, said Knutson.

    Instead, most organizations soon will be looking to automate as many aspects of DevOps as they possibly can with an eye toward enabling developers to achieve goals with as little intervention as possible from IT operations teams, he noted.

    In addition, Knutson said the trend of convergence between mainframe and distributed computing teams within IT organizations is about to accelerate. In fact, there may soon be no such thing as “mainframe DevOps,” he noted; rather, the mainframe will be just another mainstream platform on which applications are deployed.

    The economic downturn may limit the number of new mainframes being deployed. However, given that the total cost of computing on the mainframe tends to be lower than distributed systems, the number of workloads running on existing mainframes could increase as organizations deploy more Linux-based applications on the venerable platform.

    The API Compuware is adding to its Strobe APM platform will help accelerate the development and deployment of those applications by making application testing a more integrated element of a DevOps workflow, said Knutson. Automated tests can be run within the code delivery pipeline using Compuware Topaz for Total Test, the Topaz Utilities plugin or Compuware Hiperstation. Development teams can be notified when performance tests are completed via communications tools such as Slack and Microsoft Teams.

    Knutson said Compuware decided to build a plug-in for Jenkins because it is the most widely deployed CI/CD platform in mainframe environments.

    Despite the pending merger with BMC Software, IT organizations can count on the fact that the Compuware portfolio of DevOps tools for mainframe environments will continue to be supported and updated, he said, pointing out that this latest announcement represents the 22nd consecutive quarterly update to the Compuware portfolio of DevOps tools for mainframes.

    It’s too early to say what precise impact the economic downturn may have on DevOps adoption in mainframe environments. However, it’s safe to say that doing more with less is going to be the order of the day for some time to come. As such, the rate at which IT organizations that rely on mainframes to run their mission-critical applications will be embracing best DevOps practices is likely to increase.

    In fact, rather than incurring the costs of replacing those mainframe applications the priority now is much more likely to be modernizing them as much and as soon as possible.

    — Mike Vizard

  • Splunk Updates SignalFx APM Platform

    Splunk Updates SignalFx APM Platform

    Splunk today unfurled its first major update to the SignalFx application performance management (APM) platform since acquiring it last October.

    Karthik Rau, general manager for application performance management (APM) at Splunk, said SignalFx Microservices APM combines for the first time the SignalFx platform with Omnition, a software-as-a-service (SaaS) platform for implementing distributed tracing as an alternative to application sampling that Splunk also acquired last year.

    In addition, the latest iteration of SignalFx adds a Kubernetes Navigator tool to a SignalFx Infrastructure Monitoring module to make it easier to manage Kubernetes clusters alongside the microservices-based applications running on that platform. The module surfaces recommendations to expedite triaging and troubleshooting based on machine learning algorithms that are embedded in the platform. Splunk has also enabled workflow integration across Kubernetes Navigator and Splunk Enterprise and Splunk Cloud to provide IT teams with additional insights and context, noted Rau.

    With the acquisition of SignalFx, Rau said Splunk is at aiming to advance two major DevOps trends. The first is the rise of open source agent software that makes it increasingly feasible to instrument the entire IT environment. Omnition, prior to its acquisition by Splunk, was a founding member of and contributor to the OpenTelemetry project now being managed under the auspices of the Cloud Native Computing Foundation (CNCF).

    The second is the need to eliminate relying on sampling in favor of employing distributed tracing to be able to analyze every event that has occurred within an IT environment.

    At a time when IT environments are getting more complex, Rau said being able to resolve IT issues is critical. Modern applications based on microservices can be especially problematic given all the dependencies involved, he noted. In contrast to legacy APM platforms built to monitor monolithic application environments, SignalFx is built from the ground up to address application environments based on microservices, he said Rau, noting core to that effort is the ability to ingest massive amounts of distributed tracing data.

    Historically, APM platforms were used sparingly to help manage the most mission-critical applications in the enterprise largely because of concerns about cost. Given the complexity of modern applications, however, it’s become apparent that observability is now a core tenet of any approach to implementing best DevOps practices. The issue many DevOps teams will need to address is determining to what degree the existing tools they have for observing their IT environments sufficiently meet the requirements of new classes of applications. In many cases, that decision may be predicated on the rate at which those organizations are embracing microservices-based applications.

    Of course, Splunk is not the only vendor making a case for an APM platform optimized for microservices. Competition between emerging and legacy providers of APM platforms that have added support for containers and Kubernetes clusters is already fierce. The real issue going forward, however, is determining which of the platforms will enable DevOps teams to discover the most relevant issues soonest. After all, when short-handed DevOps teams encounter an issue, every second it takes to remediate that problem counts.

    — Mike Vizard

  • New Relic Gives COVID-19 Relief Agencies Free 90-day Access

    New Relic Gives COVID-19 Relief Agencies Free 90-day Access

    New Relic will provide free access to the entire New Relic One observability platform for 90 days to any organization engaged in COVID-19 pandemic relief efforts that have a specific benefit to the public.

    Erin Dieterich, director of corporate social responsibility at New Relic, said it’s apparent that the IT platforms of both nonprofits and private companies that are lending their services and expertise to mitigate the impact of the COVID-19 pandemic will be taxed in unexpected ways.

    To help IT teams rise to that challenge, New Relic will make it possible to identify both software and infrastructure issues that are having an adverse impact on applications, noted Dieterich. Those issues undoubtedly will be experienced by both non-profit organizations as well as private companies trying to leverage their existing IT environment to make additional digital services available. Examples of organizations beyond those providing humanitarian aid that are being invited to register to use New Relic One via NewRelic.org include public and private schools and other providers of education services.

    New Relic also has a crisis management team in place to make sure the New Relic One service is not disrupted as the company’s own employees work from home across multiple geographies.

    Many of the providers of COVID-19 relief services are likely to find their efforts stymied at some point by IT issues. As IT environments have become more intertwined in the age of the cloud, it’s become difficult to ascertain the root cause of any application performance issue. Platforms such as New Relic One provide access to a cloud service through which IT teams can more easily pinpoint where a specific issue is potentially creating a wave of downstream application issues that would not be obvious to the average IT administrator.

    Beyond the teams of employees New Relic already allocates to New Relic.org on a full-time basis, Dieterich said the company is tapping volunteers from its own base of employees. Many of those employees themselves are now working from home, much like most of the rest of the global workforce.

    It’s too early to say to when the COVID-19 pandemic might subside, so New Relic plans to re-evaluate this initiative three months from now. In the meantime, the company has also pledged to make available $100,000 to match employee contributions to COVID-19 relief efforts.

    In the days and months ahead relief agencies of all sizes are going to be put to the ultimate test. While most of the focus is now on health care, it’s clear the COVID-19 pandemic also represents a major economic disruption. IT expertise will be needed to augment relief efforts spanning everything from tracking coronavirus cases to making sure people who are out of work receive food assistance. IT expertise that enables relief agencies to access public and private funding as quickly as possible is likely to be among some of the most important tasks ahead, regardless of whether anyone realizes today or much less even appreciates it tomorrow.

    — Mike Vizard

  • Day 2 for the Operator Ecosystem

    Day 2 for the Operator Ecosystem

    The original focus for Kubernetes was very much on stateless applications, which don’t rely on coordination between instances or sharing data between client sessions. In practice, that usually means that we can stop and start our stateless applications without data loss or impacting on client connections.

    If all applications were stateless, the world of application deployment and management would be super simple, but unfortunately that’s not all use cases. The second class of applications are stateful, where the application is retaining data or state across its entire lifecycle. Whilst older monolithic applications such as SQL databases fit into this paradigm, there are also many architectures where the individual elements making up a particular service are actually clustered together in some way. They may be sharing state data between them, or they need to be synchronized together.

    One of the fundamental features of Kubernetes is that the scheduler can move pods around between agents, which works fine for stateless applications but not so well for stateful, which tend to like their storage and networking to not change during operation, unless handled in a very specific operational way. In order to try to handle the complexities of stateful applications, Kubernetes 1.5 added StatefulSets, which gave us the concepts of stable network and storage. But this doesn’t solve all of our problems, since Kubernetes still doesn’t know what’s actually going on inside the pods.

    Typically these kinds of applications have a set of lifecycle states which require logical ordering of actions in order to maintain operation. Stateful applications tend to have coordination between their elements, so, in general, if we were to just start and stop instances then we may impact on the correct behavior of the application—we may need to wait for re-balancing of data, or there may be multiple steps involved in an upgrade operation. This also applies to many operations that you are likely to perform such as scaling, and these actions also tend to be unique to the application, so a Cassandra cluster is managed differently from a Kafka cluster. That domain-specific knowledge of how to administer this class of applications isn’t captured in the paradigms that Kubernetes gives us out of the box, so how do we automate and package that knowledge?

    The solution to this problem is the Operator pattern. Operators encapsulate operational tasks in code, so we can orchestrate application lifecycle actions using Kubernetes APIs. Operators encode domain-specific knowledge about the lifecycle actions required for the application—how to scale it, how to upgrade it, how to recover from failure scenarios and so on.

    When we install an Operator into our cluster, we will get a controller, which is the code that manages the lifecycle of the particular thing and where the domain-specific knowledge is encapsulated. We’ll also get a bunch of custom resource definitions, which extend the Kubernetes API to address new resource types, so these add a new type which you can then put data into and instantiate.

    There are now many different ways to build Operators. The first one to emerge was the Operator Framework, which originated at CoreOS, but since then a whole range of different ways to build Operators have appeared, including Kubebuilder, Metacontroller and KUDO. These all take different approaches to building Operators, from SDK’s requiring Go expertise and deep Kubernetes knowledge to the KUDO approach of a polymorphic Operator, which can be configured very simply by using YAML.

    For cluster administrators managing large clusters, this proliferation of development methodologies and management interfaces can be problematic. The class of applications that Operators were developed to manage are almost always part of a larger application stack, with dependencies between them. If we have a lot of Operators written in different ways running on our clusters, how can we ensure they will interoperate with each other, and how do we validate and test them?

    When we depend on other services, we primarily care about two things: how to access and use it, and what it does. The KUDO project is working on the Kubernetes Operator Interface (KOI) to address this, enabling Operators to easily compose with each other based on a well-known set of CRDs. This interface is not just about connection strings and secrets, either; KOI aims to answer the question of “What does this Operator actually do?” By exporting an Operator’s behaviors as a CRD, tooling such as CLIs and GUIs can be written that better abstract the tasks that users need to perform rather than having to understand a library of custom resources.

    Defining behavior is one thing, validating it is another. How do we write standardized tests that confirm an Operator actually does the thing it says it is going to do? In order to try and address this problem, the KUDO project has also developed a test framework, Kuttl, which allows Operator developers to write tests to prove correct behavior. Kuttl has wider use cases outside of the KUDO project, with the ability to test conformance for all kinds of Kubernetes resources, so this is in the process of spinning out into a separate project.

    These kinds of efforts around standardization, definitions and testing will enable us to build ecosystems of Operators that naturally compose with each other, no matter the implementation—allowing users to build application stacks they can be confident will inter-operate consistently, rather than a constellation of unrelated Operators strung together by assuming the right configuration values. Collaboration and cross-project working are key to the future of the Operator ecosystem, and there are now more and more collaborative efforts emerging across the industry with these goals in mind.

    To learn more about containerized infrastructure and cloud native technologies, consider coming to KubeCon + CloudNativeCon EU, in Amsterdam. The CNCF has made the decision to postpone the event (originally set for March 30 to April 2, 2020) to instead be held in July or August 2020.

     

     

    This article was co-authored by Gerred Dillon, principal engineer for cloud native applications at D2iQ. Gerred builds tooling for large scale workloads on top of Kubernetes. He is the creator of the Kubernetes Universal Declarative Operator and assists with the Kubebuilder subproject, SIG API Machinery, and CNCF SIG App Delivery.

    — Matt Jarvis

  • What Developers Should Take Away from the Iowa Caucus App Debacle

    What Developers Should Take Away from the Iowa Caucus App Debacle

    In the wake of the recent Iowa caucus, vote-counting software has fallen under suspicion after a smartphone app built by Shadow, Inc., brought chaos and delays to the first 2020 Democratic caucuses. Stopgap measures, such as Nevada officials canceling the application’s use in its upcoming caucus, are not enough to ensure vote tallies the electorate can be comfortable with. What’s needed is to correctly identify and fix the underlying problem. 

    The flaw does not lie with a lack of end-user sophistication, dataset complexity or inappropriate app security. Remember, government officials around the world are transforming urban areas into connected, responsive smart cities. Students are live-streaming interstellar space flights to Mars and Saturn. Uber drivers navigate past traffic jams, while seniors use apps to make time-sensitive healthcare decisions and adjust their retirement portfolios. People of all ages and experience levels do this and more, on the fly, with handheld mobile devices. 

    The real problem lies in the way leadership teams drive software delivery. The Iowa app failed for a number of reasons: It was released with no product testing after a short, two-month development runway conducted under a cloud of secrecy. It was not built to scale. Worse, there was little to no input, transparency or communication among the application’s most important stakeholders—the Shadow management team, the software developers and the end-users, in this case, precinct captains running the Iowa caucuses and party.

    The IT professionals in charge could have avoided these problems by following three simple principles of successful software development: 

    • Collaborate With All Stakeholders: Applications are no longer stand-alone widgets. They are digital experiences. With even the most sophisticated design, experiences that don’t serve their target audience are failures. A development process that prioritizes collaboration with end users can prevent such failures. Feedback from those with a vested interest in the outcome would have quickly raised red flags for developers. In Iowa, collaborating with intended users would have highlighted a need for accessibility training and connectivity issues, since the app was deployed in buildings with high-speed internet along with remote, off-grid locations. 
    • Build to Scale: Every developer knows to build for performance at an order of magnitude larger than you expect. This includes ensuring performance on the widest possible range of handheld devices and phones. From a developer’s perspective, the phone model will impact application performance due to different hardware specs. It’s imperative for designers to build apps that are native, so that all users, devices and performance profiles will function as intended. A useful software solution should reap success, not failure, when more people use an application than initially expected. 
    • Be Transparent: Valid concerns over security risks and election integrity unfortunately led Shadow’s team to prioritize secrecy over transparency. That didn’t work. Problems are not detected and solved when siloed or when small groups of people work on a solution in secret. Proper vetting and testing falls by the wayside. The risk that the app will not be suitable for its intended users increases. The app may have additional, exploitable security vulnerabilities that can only be found when teams ensure proper openness and transparency during the development process. Proper governance and guardrails that protect core data mitigates the security risk for election-based applications (and software in general). There’s little to be gained and much to risk by closing off input and vetting at any point during the full application development cycle. 

    Developers Move From Stressed to Empowered 

    One simple, effective way to solve or avoid these issues is by adopting an enterprise-grade, low-code software development platform. The “low-code” label refers to visual, model-driven software development, which employs an unambiguous visual language throughout the application development lifecycle, enabling nontechnical stakeholders, end users and professional developers to work together. 

    Such a collaborative platform can surface issues with senior leadership before it’s too late. Feedback from citizen developers—that is, not citizens in the voting sense, but rather, non-traditional developers—can capture leadership’s careful attention, precisely because the feedback is from nontechnical users. The right low-code platform would have enabled the Iowa caucus volunteers and stakeholders to collaborate on every step of the process without slowing it down.

    Another benefit of a robust low-code platform is having more people on deck to meet product goals with tight deadlines. Insights from citizen developers with unique backgrounds can also help when testing applications. With suitable governance controls, low-code functionality speeds up a developer’s ability to deliver software without taking away their ability to dive deeply and extend functionality with coding when needed. 

    Market analysts have evaluated the strengths and merits of different low-code platforms. In multi-experience use cases—such as Iowa’s, particularly because the eyes of the world are watching—it’s important to use a low-code platform that enables applications that are truly device native. This allows the software to take advantage of core device capabilities, typically delivering better performance and supporting the interactivity users are familiar with. Additionally, continuity online and offline would address connectivity issues in areas where signals are weak or nonexistent; the data can be properly synced when a signal is available. Lastly, a robust low-code platform provides tools to enable apps to scale automatically, avoiding the coding work required to allow an app originally built for 1,000 people to service 100,000 or a million. 

    An Urgent Role for Software Developers

    When roughly half of all eligible voters sit out general elections, talented developers should not lose sight of the many ways technology can aid and expand civic participation. Eventually, we may live in a world where election-based apps for registered voters are accessible and secure, regardless of the user’s device, age, location, physical ability or educational background. Building in redundant systems of paper-based vote confirmation and other offline systems will add integrity, inspire greater confidence and drive adoption of these innovations.

    What happened in Iowa is, unfortunately, not an isolated case. These complications are endemic to how most leadership teams drive software delivery. Development teams of all types will continue to run into similar issues until their leadership makes transparency, accessibility and scalability a priority by investing in the appropriate resources. Organizations can leverage the strength and impact of fully robust low-code software development platform to that end. 

    Since the introduction of low-code in 2004, platform capabilities have matured at an accelerated rate, moving to widespread adoption for enterprise use. During the same period, elections have increasingly relied on software-driven electronics, leading to consistent issues. Citizens casting ballots is one of the most sacred mechanisms of our republic. Any software used to tally votes must be bulletproof. Truly open and holistic low-code software development platforms can make this happen by proactively bringing people together to make sure software works for those who need it most.

    — Jon Scolamiero

  • Instana Expands Scope of APM Ambitions

    Instana Expands Scope of APM Ambitions

    Instana has launched a series of additions to its application performance management (APM) platform that reach into the realm of IT infrastructure as well as mobile and Java applications.

    Chris Farrell, technical director and APM strategist for Instana, said the company is adding support for VMware vSphere because more customers are converging their management of applications and IT infrastructure, thanks in part to the rise of DevOps practices. Many IT organizations are also simultaneously embracing emerging platforms such as Kubernetes to run microservices-based applications on top of VMware vSphere, he noted.

    Instana also recently added support for the Container Runtime Interface based on the Open Container Initiative specification, otherwise known as CRI-O, alongside existing support for Docker containers.

    At the same time, usage of Instana, which was created to focus mainly on emerging microservices-based applications, is expanding to include monolithic applications. As a result, Instana has added a free AutoProfile feature for Java applications based on tools it gained by acquiring StackImpact.

    Available in beta, AutoProfile attaches itself to the running process automatically with no restarts or reconfiguration required, to surface how specific pieces of code and associated bottleneck impact overall performance.

    Finally, Instana has also made available in beta an End User Monitoring of Mobile Applications module. That capability is also being made available at no additional charge. Troubleshooting mobile applications should become easier because Instana captures every single request made at the client by both the browser and the application.

    While adoption of APM platforms relative to the size of the IT market remains slight, Instana as a startup has been gaining traction at the expense of incumbent rivals. Instana claims it is now monitoring more than a half a million container and program run-time processes via its software-as-a-service (SaaS) platform, including hosts, containers, Java Virtual Machines, NodeJS runtimes and AWS Lambda functions written in PHP or Ruby. In total, Instana claims to also be gathering 1.5 billion metrics per minute, with more than a million application request traces being captured every second. New customers acquired in 2019 include Vivy, MacMillan Learning, TIpico, ExaVault and Avoris. Overall, Instana reports that its base of customers grew 150% in the last year.

    The Instana APM platform is designed from the ground up to automate application monitoring, including application discovery and mapping, monitoring sensor and agent deployment, and application infrastructure health monitoring. Instana is betting that the rise of microservices will not only require more organizations to rely on an APM platform to manage an increasingly complex application environment in real-time but also force many organizations that have APM platforms to reconsider their options when they discover how limited the visibility into containerized applications those platforms provide. At the same time, by adding support for VMware vSphere and making additional capabilities available for free, Instana is ratcheting up the pressure on rivals in 2020 further.

    Of course, it’s not clear there is anything approaching general dissatisfaction with existing APM platforms, so Instana may have its work cut out. Nevertheless, competition among providers of APM platforms has never been fiercer.

    — Mike Vizard