staging-devopsy.kinsta.cloud

Category: DevOps Toolbox

  • Observe Seeks to Put More IT Metrics in Context

    Observe Seeks to Put More IT Metrics in Context

    Observe, Inc. announced today it has updated it observability platform to add support for metrics based on time series data. In addition, the company is revamping how the platform generates alerts as part of an effort to surface more actionable intelligence.

    Jeremy Burton, Observe CEO, said rival observability platforms require IT teams to sift through hundreds of metrics that are generated using elaborate tagging schemes that ultimately drive up the cost of storage. The Observe platform curates metrics by associating them with, for example, a customer, to provide more relevant context, Burton noted.

    That approach eliminates the need to present IT teams with overwhelming lists of metrics in addition to reducing storage costs by removing the need for a complex tagging scheme, added Burton.

    The latest update leverages that approach to metrics to only generate alerts based on curated metrics attached to customers, pods, shopping carts or containers. Rather than simply being alerted to a drop in response times, for example, the IT team can also easily see which customers or pods might be affected. That shift will reduce the volume of alerts that are already overflowing in email inboxes and across other communications platforms.

    Fresh from raising an additional $7 million, Observe today also revealed it has added 20 paying customers since launching the platform on top of the Snowflake cloud service residing on the Amazon Web Services (AWS) public cloud. Rather than reinventing the same core infrastructure, Observe is leveraging a data analytics engine that is already widely employed in IT environments.

    For now, Observe will continue to primarily focus on metrics as part of an effort to deliver insights in a form IT operations teams are prepared to consume today, said Burton. Over time, however, Observe will add support for distributed traces via tools such as OpenTelemetry and Jaeger as it adds additional application performance management (APM) capabilities, added Burton. Rather than telling IT operations teams they are managing IT in the wrong way, the goal is to meet IT operations teams where they are today, noted Burton.

    That strategy also enables the Observe platform to be employed to manage both monolithic and microservices-based applications running on Kubernetes clusters, noted Burton. The immediate goal is to provide IT teams with an alternative to legacy monitoring tools that provide more context at total lower cost by allowing IT organizations to rationalize tools that don’t tend to be especially well integrated, added Burton.

    In the longer term, Observe will also employ machine learning algorithms to collect data more efficiently. However, Burton said the company remains skeptical of visions of an IT future that depend on machine learning algorithms to continuously learn IT environments that are not only unique, but subject to frequent changes.

    Competition among observability platform providers is already fierce. Each IT team will need to decide what type of platform makes the most sense for them based on costs and their preference for specific capabilities one vendor might have that another doesn’t provide. One way or another, however, the way IT environments are managed will soon be changing for the better.

  • Grafana Labs Advances Open Source Visualization and Observability

    Grafana Labs Advances Open Source Visualization and Observability

    During the online GrafanaCONline conference today, Grafana Labs announced that version 8.0 of its open source visualization software widely employed by DevOps teams is now generally available. In addition, version 1.0 of Grafana Tempo, an open source back end platform for collecting distributed traces that are needed to drive observability across an application environment, is also generally available.

    At the same time, Grafana Labs revealed that Grafana Tempo is now available as a service on Grafana Cloud.

    Version 8.0 of Grafana adds support for additional types of visualizations such as streaming panels, state timeline, status history, bar chart and histograms in addition to a revamped unified alerting system that enables DevOps teams to view and edit alerts generated by Grafana and open source Prometheus monitoring platform via a common user interface. The notification system adopted to achieve that goal is based on a Prometheus alert manager that provides capabilities such as grouping, deduping and silencing of notifications alongside advanced message templates.

    The latest release of Grafana also improves startup and graph rendering performance, thanks to a major reduction in initial download size and graph rendering time.

    The enterprise edition of Grafana has also been updated to provide support for fine-grained access controls, improves caching of back end data sources and improved reporting capabilities such as live dashboard links that can be embedded in email.

    Overall, Grafana Labs claims there are now more than 750,000 active installations of Grafana that organizations are employing to create visualizations that correlate data collected from multiple back end sources.

    In addition to contributing to Grafana and Grafana Tempo, the company is running a cloud service that makes multiple instances of Prometheus running on different clusters accessible from a central console.

    Torkel Ödegaard, creator of the Grafana project and chief Grafana officer for Grafana Labs, said Grafana Tempo promises to further advance observability thanks mainly to its ability to employ object storage to capture complete distributed traces. Rather than only sampling traces, it’s now feasible to trace every request. Grafana Tempo is also compatible with any open source tracing protocol, such as Jaeger, Zipkin and OpenTelemetry, and can be integrated with metrics, logs and dashboards via a managed Grafana Cloud service.

    It’s not quite clear how quickly organizations are embracing distributed traces to improve application observability or, for that matter, to what degree traces might eliminate the need for certain types of metrics or log analytics. The one thing that is certain is DevOps teams require more context than ever to proactively manage complex IT environments. Distributed traces make it simpler to track interactions between application services. The challenge is they can require IT teams to store a lot more data.

    In time, of course, distributed tracing will become more commonly employed as developers more routinely instrument applications based on microservices that tend to have lots of dependencies that are difficult to discover in the absence of some type of distributed tracing capability. Of course, distributed tracing has been around, in some form or another, in application performance management (APM) platforms for some time. The difference now is that, as open source software, it’s becoming more affordable to implement.

  • Digital Customer Experiences: The Future is Modular

    Digital Customer Experiences: The Future is Modular

    With the proliferation of microservices and APIs, will UIs go modular too? Some technologists note a rising trend around smaller, intent-based customer experiences that more directly mirror API endpoints.

    I recently met with Adam Evans, co-founder and CTO of Airkit, to better understand what’s broken with today’s digital customer journeys and how they need to evolve. He predicted that single-purpose experiences will become more pervasive in the future. In the process, we’ll likely encounter fewer native apps and fewer downloads. To enable all this, he’s putting faith in low-code to bring easier integration and automation patterns to more developers.

    The State of Digital Experiences

    Digital customer experiences are becoming increasingly connected and web-based, and at times, disconnected from the core service. In headless environments, end users are engaging with companies through more and more abstraction layers, such as chat, SMS, voice or email notifications. These interactions are increasingly modular and event-driven, noted Evans.

    Increasingly, user encounters are the result of trigger-based patterns activated when user action is required. Not only is the communication style changing, but new devices and platforms have emerged, further making a case for a decoupled development approach. B2C apps become more modular in this transition, presenting experiences built around specific tasks and closely reflecting the specialized microservices or APIs that drive them. Consider the rise of the single page application (SPA) style or AWS Lambda as evidence.

    As more automation and subscription models enable a “set and forget” attitude to commercial software, Evans predicted we’ll likely see more intent- and event-driven workflows emerge. He said these reimagined UIs would shroud platform complexity and, instead, focus on single, specialized actions, like submitting an insurance claim, checking the status of a package or updating your coffee subscription.

    A Broken Customer Journey

    So why would end user digital experiences evolve into more intent-driven applications? Well, complex digital platforms can get feature-bloated very quickly. Bulky applications with many menus are difficult to navigate, thus impacting user experience.

    As Evans describes, generic interfaces often display tons of information irrelevant to the task at hand. “Don’t make me go through generic interfaces to help me do something specific,” he said.

    Clunky interfaces are at odds with small digital tasks that involve an attention span of 20 seconds or less. Evans describes these as “micro touchpoints in our daily lives where you don’t need traditional, large applications.” These actions could be, for instance, looking up COVID-19 infection rates, checking your credit card balance or updating a streaming subscription, he said.

    Organizations have other imperatives to improve user experience, too. For example, if a platform isn’t self-service, it can increase support calls, which can cost a company significant resources. Plus, if the service isn’t event-driven, users must routinely check in of their own accord, which could waste time and encourage tech anxiety.

    Single Page Applications

    In the age of modular microservices, the days of bulky apps and “manual polling” may be limited. To Evans, the solution lies in expressing the “minimum way to represent the transaction of that interface.”

    “How do we keep moving smaller divisions from the back end to the way interfaces are built?” Evans asked. Similar to the way microservices architecture separates domains, Evans noticed UIs segmenting attention along API endpoints. He envisioned more single-purpose experiences being constructed that extend APIs and microservices with a user interface.

    Technically, this may result in more single page applications being developed. Niche UI layers that map APIs would likely carry a data model, Evans described, so that micro apps are delivered with data for entering fields into API calls. As they are web-based, asynchronous single-purpose experiences could also transcend the barriers of app stores and third-party marketplaces.

    Potential Benefits of Modularity

    More intent-based workflows mean less overhead for the user, bringing quicker, more convenient access to the problems they want solved. Sure, users still register with a core service, such as their bank, coffee subscription service or insurance agency for centralized account management. But, users frequent account centers less often, as the periphery of interactions around them continues to grow.

    “The future of apps will look more like individual, intent-based micro apps,” Evans reiterated. These would reflect a metronome of touchpoints Evans called “little moments of delight.”

    Pinging users only when action is required could reduce check-ins, thus reducing digital anxiety. Aside from the user benefits, deployment and maintenance for small applications may be easier to support, said Evans. Lastly, more isolated intentional customer experiences increase engagement, response rates and sales, he added.

    Using Low-Code For Customer Experiences

    Connected digital experiences are relying more and more on APIs. Yet, API integration can be difficult, even for experienced programmers. So, how do we make it easier for people to build interfaces to hit these APIs? Building user-facing layers on top of APIs will require great developer experience, says Evans.

    Lately, low-code has been dominating these discussions. With greater emphasis on visual-driven development, low-code is empowering non-technical employees. To Evans, low-code capabilities will be essential to influence how future customer journeys are constructed.

    Evans noted how low-code “changes the whole game around how apps are built.” For example, branded experiences often require reusable code and common libraries, all of which low-code platforms excel at. In addition, when working with APIs, a “layer over REST design is essential to maintain state and enable long-term processing,” he said.

    Will The New Digital Journey Go Micro?

    Complex interfaces seem to work for conglomerate giants like Amazon. But other scenarios may benefit from more single-purpose workflows. As platforms become more extensive, the user interactions need to become leaner to avoid added stress. As a result, Evans predicts that micro, trigger-based B2C touchpoints will become more common in the coming years. In this paradigm, better UI extensions of common APIs could help bring people into the equation.

    “We’ll see a lot of cool stuff in the next decade,” he said. “Future apps won’t look like what past ones looked like.” As IT moves to support new, multiple channels, such as chat, voice, web and VR/AR, our perception of what an application is also will inevitably alter.

    In tomorrow’s “great unbundling of apps,” as Evans called it, “if you don’t use it every day, there’s a pretty good chance it doesn’t need to be there.”

    There are many schools of thought on the best methods to retain quality user experiences. Do you think modularity is the answer? What do you think tomorrow’s digital experiences will look like? Feel free to let us know in the comments below.

  • Cribl Automates Observability Efforts

    Cribl Automates Observability Efforts

    Cribl today announced it has updated the Cribl LogStream observability tool in addition to generally making available a software-as-a-service (SaaS) offering dubbed LogStream Cloud.

    Nick Heudecker, senior director for market strategy and competitive intelligence at Cribl, said Cribl LogStream provides the means to aggregate log data collected from multiple platforms and applications in a format any observability or monitoring tool can access.

    The challenge with observability platforms today is they leave it up to IT organization to copy and paste data into the platform. LogStream automates that process via a log router that collects and optimizes data streams from existing installed agent software and then shapes and routes that data on to analytics platform.

    Version 3.0 adds LogStream Packs, a framework for accelerating deployments of the log router. Alternatively, DevOps teams can employ LogStream Cloud to build and share LogStream configuration models.

    Heudecker said the goal is to reduce the cost of achieving observability by reducing the time and effort required to set up and manage data pipelines. No customization effort on the part of a DevOps team is required to collect and send data from hundreds of sources to any number of destinations, noted Heudecker.

    While observability is a core DevOps tenet, achieving it has been a major challenge. In addition to deploying and managing agent software to instrument IT environments, there’s a significant amount of time and data engineering effort needed to set up the pipelines employed to transfer data to a platform where it can be analyzed. Cribl is making a case for automating those data engineering tasks using a tier of software that abstracts data into a format that can be consumed by multiple observability and monitoring platforms.

    It’s not clear yet to what degree IT organizations perceive observability to be an evolution of monitoring, or simply the next logical evolution of monitoring. One way or another, IT teams need a lot more context than they have historically been able to attain using legacy monitoring tools. Each platform employed within an enterprise typically comes with its own monitoring tools that are used by the IT teams tasked with managing it. Whenever there is an issue, however, IT teams will spend hours correlating data from multiple tools to ascertain the root cause of a problem.

    Observability platforms promise to reduce that time and effort by applying analytics to data collected from multiple platforms. The challenge now is finding a way to efficiently collect all that data.

    It may be a while before IT organizations start to abandon all the monitoring tools they have in place in favor of observability platforms. However, as IT environments continue to become more complex (thanks, in part, to the rise of cloud-native computing platform based on microservices) the need for those platforms becomes more acute. The issue is enabling DevOps teams to achieve that goal without having to wait for an overworked data engineer to find the time to build a pipeline.

  • Learning ‘The First Way’ of DevOps – Continuous Flow

    Learning ‘The First Way’ of DevOps – Continuous Flow

    Many organizations are struggling to realize well-engineered DevOps, even ‘the first way’ of DevOps – continuous flow.

    DevOps is an evolving body of knowledge. There is no one-stop shop that covers all roles and the complete range of skills required for DevOps. A DevOps-competent workforce requires an ongoing commitment to DevOps skills development and mastery. Enterprises must approach DevOps training strategically to leverage training resources to their best advantage.

    Learning Continuous Flow

    The first way of DevOps, continuous flow, is the foundation for DevOps.

    Why Is Learning Continuous Flow Important to Engineering DevOps?

    A knowledgeable, skilled workforce is needed to meet strategic objectives. Without a solid understanding of DevOps concepts and terminology, communication between people and teams is inefficient and a source of bottlenecks and misunderstandings. Developing hands-on skills for the tools and workflows is needed to understand and implement DevOps pipelines. There is an industry-wide shortage of skilled DevOps candidates. New skills foster innovation. Knowledge workers reduce production costs and reduce mistakes. Having skilled coworkers makes for a satisfying working environment. Employee retention is better. Competitive advantages are derived from knowledge.

    How Is Learning Continuous Flow Accomplished?

    The following are recommended engineering practices for learning continuous flow.

    People are encouraged to be continuous learners with an ongoing commitment to DevOps skills development. DevOps training is approached strategically to ensure DevOps training is well aligned to business goals. DevOps skills gap assessments are conducted and used to define and refine the training strategy. Leaders and cross-functional teams are encouraged to take DevOps fundamentals training. Leaders define a training strategy that best fits the needs and priorities of the organization to meet critical skills gaps.

    The training strategy considers which skills and roles can be covered by inexpensive self-study resources. Determine which skills and roles warrant more costly training. DevOps training has a distinct budget. Compliance to DevOps training programs are tracked. DevOps leadership training is offered to management and staff that have a role relevant to DevOps. DevOps tools training includes the recommended engineering practices for using each DevOps tool in the Service Catalog. Staff are encouraged and supported to take DevOps certifications that are relevant to their assigned roles.

    A DevOps training program is defined and includes a recommended curriculum for each role including leaders, developers, QA, Ops, and infrastructure and security staff that are operating in a DevOps environment. Recommended DevOps training resources are cataloged, and the catalog is visible for all stakeholders. Merit and recognition programs encourage employees to master DevOps skills.

    All staff is allocated time for DevOps training. DevOps mentoring programs supplement formal training. Job swapping and immersive training is encouraged and planned. People are encouraged to attend external conferences and meetups and share what they learn with other team members.

    What Is Needed to Implement Learning for Continuous Flow?

    The following are recommended engineering practices for implementing a learning program for continuous flow.
    Assign roles and responsibilities for DevOps training leadership (e.g., DevOps Sensei, Training PM, evangelist). Conduct a DevOps skills gap assessment. Define a training strategy that best addresses the gaps and fits the needs and priorities of the organization. Define a training budget that includes expenses and time allocations per role and skill.

    Determine which skills and roles can be covered by inexpensive self-study resources. Determine which skills and roles warrant more costly commercial training. Identify training goals for each role. Ensure job recruiting profiles match skill requirements for DevOps skills that are most relevant to the organization strategic goals. Put in place the means to make training resources visible and available. Set training goals for teams and individuals. Put in place incentives and recognition programs for completion of training.

    Some of the best sources of DevOps training resources are listed below:

    1. The DevOps Institute
    2. Partners of The DevOps Institute, such as Learning Tree International and Xellentro
    3. Udemy
    4. Recorded talks and publications available through IT Revolution
    5. Books such as my own Engineering DevOps, by Marc Hornbeek.

    What this Means

    Organizations need a trained workforce to succeed with DevOps—even ‘The First Way’ of DevOps—continuous flow. Organizations need to approach DevOps training strategically to leverage DevOps training resources to their best advantage. To learn more about my blueprint for learning all things DevOps, refer to my book Engineering DevOps.

  • How IT Can Use AI To Prepare For Uncertainty

    How IT Can Use AI To Prepare For Uncertainty

    The past year has been unpredictable for businesses – from migrating to remote work to planning for a return to offices to keeping pace with shifting government guidelines. With so much in flux, it was and is a good reminder that organizations must be prepared for the unexpected and have contingency plans in place.

    From an IT standpoint, this means ensuring that employees are well equipped to work efficiently and safely, no matter what work may look like in the year ahead. Fortunately, artificial intelligence (AI) technologies are evolving quickly, enabling enterprises to better manage an ever-changing hybrid workforce.

    The following are three AI-enabled strategies that organizations should implement to help prepare for times of uncertainty:

    Invest in Self-Driving Networks

    When companies quickly and unexpectedly moved their employees to remote work last year, networks experienced increased pressure on multiple fronts: usage, quality and issue remediation. These factors compounded on top of the fact that networks have continued to become more complex in the past few years as workloads become more distributed across public and private clouds. Even under the best circumstances, building and maintaining a traditional network requires a team of dedicated experts and can be time consuming. Due to their complexity and the increasing amount of data, networks are becoming more difficult to manage via command-line interface (CLI) and are required to adapt to changing workloads and employee connectivity – this is where AI comes into play.

    A self-driving network eases complexity by using AI and automation to run the network’s end-to-end user experience with minimal human intervention. This includes monitoring for issues such as bad cables and capacity hotspots within the network and solving them before they impact the end user. By ensuring networks are running smoothly on the foundational level, self-driving networks allow IT teams to spend their valuable time tackling more complex problems and driving innovation.

    Empower IT With AI Assistants

    Another way to free up the IT team’s time is to make a new hire – not a traditional employee, but rather an AI assistant. More specifically, an AI assistant that can answer questions and manage networks on par with a network domain expert – one that learns and improves as you work with it. As AI truly delivers on completing functions on par with humans, this is where AI and machine learning are disrupting industries.

    Today’s AI assistants, through conversational interfaces, are delivering more than simple “yes” and “no” answers to IT questions – they are able to answer complex open-ended questions such as, “Why is Bob having a poor Zoom experience?” They’re even learning to solve more complex problems, helping IT teams minimize the number of support tickets issued by frustrated remote workers. As businesses recognize the value AI assistants bring to their team, they now see them as members of the IT team that help them simplify the ever-growing complexity of IT networks.

    Educate Employees on the Benefits of AI

    In 2021, we expect the adoption of AI in networking to accelerate. Ensuring the right AI technologies are property executed starts with trust. Therefore, getting teams to perceive AI assistants as more of a teammate and less as a job-threatening technology is an important step toward successful AI implementation. The end-user experience is more important than ever, and AI is becoming more crucial for enterprises to manage this experience.

    To many employees, the concept of AI can be scary. A common misunderstanding is that AI will take over humans’ jobs. However, people are starting to understand the importance of AI by seeing it solve real problems. As companies implement AI technologies into their solutions, they should first prioritize open conversations about the business benefits of AI. By ensuring everyone is on the same page, teams can work toward building a better process together. After all, the goal is for AI to ultimately make their jobs easier.

    The last year has been difficult to navigate, but it serves as a reminder of the importance of planning for the unexpected – this is necessary to continue running a business efficiently and supporting employees remotely. Though there are sure to be more uncertain times ahead, we have the tools to prepare the best we can today.

    By taking steps toward building a self-driving network, investing in AI assistants and educating employees on AI, organizations can have peace of mind that they’re on the path to building themselves, their employees and their stakeholders a stable future that’s prepared for whatever uncertainties come their way.

  • Turbocharge Enterprise Apps With Contextual Analytics

    Turbocharge Enterprise Apps With Contextual Analytics

    Software product managers and developers typically treat analytics as a standalone capability—something to be integrated into their application’s dashboard or reporting module. As a product feature, analytics is undoubtedly a valuable tool. But offering it merely as a tacked-on function is an approach that lags behind where your users are today.

    When data analytics is limited to dashboards, users must switch away from their transactional environment whenever they need to interrogate data or derive insight. This disrupts workflows and interrupts trains of thought, creating friction for the user. Moreover, a standalone analytics capability doesn’t provide context or guided analysis. Users must look for anomalies or trends manually. As a result they’re less likely to dive into analytics to support good business decision making.

    Contextual analytics, on the other hand, gives users a powerful tool right at the point of their daily work. Contextual analytics is defined as any analytics solution that is integrated directly into an application’s core workflows. This approach delivers the benefits of analytics in the situational framework where decisions must be made.

    Embedding analytics in this fashion creates significant value for the user. Charts, tables and metrics sit side-by-side on the screen, alongside the application’s central functions. With one click, the user gains instant, guided and dynamic insight.

    Such an improvement is helpful for all kinds of business activity. Retail store managers can instantly access demand forecasts while creating weekly work schedules. Inventory managers can view trends and analyze stock without leaving their ordering screen. Supply chain, finance, logistics, sales and marketing, manufacturing—any process involving routine data processing can profit from contextual analytics.

    A Rich Workflow Asset

    When embedded into transactional workflows, contextual analytics can deliver two forms of understanding. The first comes from predefined visualizations, ranging from simple KPI numbers to line and bar charts and even contextual dashboards. These visualizations are presented based on user action; a customer’s purchase history, for example, can pop up in chart format while viewing the account record, enabling the user to make decisions about sales incentives or priorities for service.

    Second are dynamic analyses and alerts. These indicate that either thresholds have been crossed or anomalies in a record have been discovered, prompting the user to explore and take further action. Pop-up alerts can be invaluable in sales, production, finance or many other disciplines.

    For both predefined and dynamic contextual analytics, outcomes can be based on simple aggregations of transactional data or as the result of sophisticated data science modeling (e.g., propensity to purchase). Specific outcomes can be set by either the product manager or the user to maximize utility.

    Contextual analysis is ideal for supporting or triggering actions according to any business need. The capability enhances transactional workflows by providing metrics pertaining to a particular transaction; it will also trigger a new workflow via an alert or suggestion for action, based on the output of a data science model.

    contextual analytics

    Of course, none of this means that dashboard-based analytics aren’t still important. Users will always need to conduct broad data analysis. Dashboards and/or report analytics allow users to monitor overall business performance, drilling down when necessary into the details behind the numbers.

    With the secondary addition of contextual analytics, however, users can be continually guided in their decision making as they work. They receive a constant flow of deeper insight, supporting management tasks intuitively at a granular level.

    Deployment Framework for Developers

    Embedding transactional analytics into enterprise applications can be directed according to a maturity model. There are five possible stages of product development:

    • Stage One: No Capability. The main engineering focus is on bringing a new application to market. Minimal Viable Product (MVP) attributes lead development, and reporting capabilities are rarely included.
    • Stage Two: Data Exports. Analytics are provided based on customer feedback, but only through a CSV download or API access that allows the end user to analyze data in their preferred tool. The burden of building analyses rests with the customer.
    • Stage Three: Basic Reporting. A limited set of reports are supported by analytics, and in-house developers are tasked with creating the capability, often to the detriment of new features for the core product.
    • Stage Four: Standalone Dashboard and Reporting Module. This is often the end journey for most enterprise applications. Self-service reporting and analysis are available via out-of-the-box dashboards and reports.
    • Stage Five: Contextual Analytics. Sophisticated, automated analysis is available as part of the application’s core workflows, as well as at the dashboard. Users are guided to optimal decision-making at both the transactional and reporting level.

    These stages are not mutually exclusive. Especially for stages four and five they can be additive, so that end users will have a variety of mechanisms to access the data they need, at the time they need it.

    contextual analytics

    Accelerating Implementation

    Elevating the end user analytics experience is easier to achieve than it once was, thanks to BI vendors that specialize in embedded and contextual analytics built on an open platform. The best vendors are able to adapt quickly and easily to product development roadmaps, aligning features to meet specific needs and following up with administrative tools and automation processed to support the lowest possible cost of ownership.

    Working with an analytics vendor means development teams will have maximum support from prototype and design to integration, deployment and subsequent iteration. Options for Windows and Linux, on-premises or cloud will ensure the versatility, security and scalability required for highly marketable offerings.

    How Customers View Analytics

    As a product feature, analytics can often be dismissed as an afterthought—but your users don’t see it that way. BI analytics is increasingly seen as critical to business governance. Users want to glean as much insight as possible from the data they’re collecting—and on multiple levels. This means your users want to get more from your product, even in ways they haven’t yet imagined. Contextual analytics can provide that enhanced appeal for your application, putting your product out in front at a time when enterprise applications are more essential—and more competitive—than ever before.

  • Atlassian Delivers on Forge App Dev Platform Promise

    Atlassian Delivers on Forge App Dev Platform Promise

    Atlassian this week made available a Forge platform for building applications that complements its existing portfolio.

    Mike Tria, head of platform engineering for Atlassian, said Forge is intended to provide an application development environment to both IT organizations and third-party partners. It provides developers with access to an integrated Atlassian DevOps toolchain to accelerate testing, deployment, debugging and to capture log data, added Tria. Forge also presents developers with a command line interface through which they can be onboarded to the Atlassian cloud where Forge runs to access documentation and application samples. It uses OAuth 2.0 to ensure applications deployed on the Atlassian cloud only access data they have permission to access.

    The overall goal is to provide developers with a more modern application development environment as an alternative to the application development platform the company previously made available.

    Once an application is built, developers can then publish their applications on the Atlassian Marketplace as free or commercial offerings. There are already more than 3,500 Forge apps that were created during a beta process that began late last year. Forge will soon be extended to the rest of the Atlassian portfolio, noted Tria.

    Forge is intended to complement an Open DevOps initiative launched earlier this month that tightens integration between the Jira project tracking and management tools provided by Atlassian and a wide range of other tools commonly employed by DevOps teams. The goal is to not only make it easier to correlate issues that are listed in Jira with artifacts found in various software platforms, but also to collect data from DevOps tools to automatically update Jira.

    That data will then be employed to inform key performance indicators (KPIs), based on graphs that Atlassian provides within Jira, to keep track of value streams. Rather than having to acquire a separate value stream management (VSM) platform to track software development progress, the insights needed to understand the impact of, for example, a delay to one project becomes a dividend of using Jira.

    Like most providers of software-as-a-service (SaaS) applications, Atlassian has been making available a platform for building applications on top of the same platform it employs to build its own applications. Atlassian claims there are more than 1,200 partners building applications in addition to internal IT that teams that have built custom extensions to its applications. Atlassian has already shown a proclivity for acquiring independent software vendors (ISVs) that build applications on its platform. As part of the overall Forge initiative, Tria said Atlassian will be working more closely to identify the white space that won’t be addressed by the Atlassian product roadmap at some future date.

    In the meantime, independent software vendors and internal IT teams will need to determine to what degree they will prefer to stand up their own application development environment versus opting to be dependent on Atlassian. In theory at least, applications built on Forge should be more tightly integrated with the rest of the Atlassian portfolio. The only potential downside is, of course, any potential conflict that might emerge with a provider of an application development platform that also happens to sell application software.

  • Serverless Computing Brings New Security Risks

    Serverless Computing Brings New Security Risks

    Attracted by lower costs and less operational overhead, serverless computing is an unmistakable undercurrent in the world of DevOps. Developers are drawn to the innovation because it requires no architecture to manage while offering continuous scaling for anything from a few requests per day to hundreds of thousands of requests per second.

    More than 50% of the developers using serverless functions today started using the computing model in the last three years. By some estimates, serverless computing is the fastest-growing segment in the cloud services market.

    While businesses are drawn by the opportunity to extend and integrate cloud applications at greater scale, there’s a dark underbelly to this DevOps phenomenon: security. In fact, organizations cite security concerns as the leading reason why they haven’t yet adopted serverless computing. For good reason!

    Serverless functions are introducing a new breed of threats – misconfigurations, code-level risks, injections and weaknesses – many of which are the underlying risk factors for a software supply chain attack. With adoption of this technology accelerating, organizations need security that delivers more than just visibility into these dynamic environments. They also need the ability to detect and block code-level vulnerabilities and misconfigurations that occur during development and through to production. Most importantly, this needs to happen seamlessly and with little to no impact on DevOps.

    Dynamic Environments Create Complex Security Risks

    The nature of applications has evolved, creating a new paradigm of security risk. In serverless environments, code sprawl makes it harder to identify vulnerabilities and patch them before they become business-level risks.

    In a monolithic application environment, an identified vulnerability could be efficiently patched by the developer through upgrading a single package, pushing a deployment and then testing and deploying the app.

    In a serverless computing model, patching and resolving vulnerabilities becomes a lot more complicated, given that there may be several hundred (or more) environments across different providers and regions. So, instead of having to patch a single application, developers will need to patch, deploy and test hundreds of individual functions that rely on that library.

    With 39% of developers saying they’re now fully responsible for security, it means they’ll carry the burden of having to patch an identified vulnerability – often taking them away from development work.

    With Serverless, You Need to Rethink Your Approach to Security

    Given the distributed nature of serverless functions – essentially, the reason for its flexibility and scalability – many existing security tools will provide little to no visibility, nor the control capabilities, for these computing environments. Many of the security attacks that will occur in serverless functions will be a result of misconfigurations and mistakes that happen outside the purview of the security team and due to legacy solutions which don’t translate to serverless architectures. Further, because abstracted workloads create blind spots, attackers will have more room to maneuver undetected.

    Serverless functions will even render some traditional DevSecOps tools less useful. Scanning tools must monitor hundreds of individual repositories instead of a single monolithic repository, while application performance monitoring (APM) tools lack security proficiency and cannot protect from the OWASP Serverless Top 10 risks.

    The challenge for security teams will be implementing solutions in a way that does not modify workloads or require changing business logic — both of which slow development. When applying security to serverless functions, it’ll be critical that the solution can do the following:

    • Go beyond monitoring and actually detect and block vulnerabilities without elaborate or manual steps involved. The scale of serverless functions will make it nearly impossible for security analysts to manage and keep up with every alert they receive. Instead, they need a tool that delivers actual security and can help them block malicious activity without stopping development altogether.
    • Enable a positive security model that provides protection against malicious changes, like zero-day exploits, within the function. This approach gives security teams more control by automatically detecting and blocking anything that isn’t explicitly allowed in a given function.
    • Provide forensic detail from log-level information so security analysts can fully understand the context of every attack with virtually no impact on latency. Further, with the risk of supply chain attacks soaring, security teams need the ability to identify and map third-party dependencies used during runtime.

    For many organizations, serverless architecture is a very different and unique computing environment – unlike anything they’ve experienced or had to protect before now. That reality means that organizations need a fresh approach to securing these environments and will need to look beyond the traditional tools they have in their tech stack today.

    Above all, developers and security teams will need to work together to ensure security is built-in from the start. Otherwise, serverless functions will quickly become a playground for cybercriminals.

  • Digital.ai Deepens Value Stream Management Integration

    Digital.ai Deepens Value Stream Management Integration

    Digital.ai announced today it has expanded usage of machine learning algorithms within its namesake value stream management (VSM) platform to include modules to optimize flow and improve application quality in addition to enhancing its risk prediction and process optimization modules.

    In addition, Digital.ai has expanded the number of pre-built integrations it now provides for hundreds of DevOps tools and platforms.

    Derek Holt, general manager of agile and DevOps for Digital.ai, said the goal is to expand the bi-directional flow of data between the core Digital.ai platform and modules and tools provided by the company and its third-party DevOps partners.

    Digital.ai was formed from the merger of XebiaLabs and CollabNet VersionOne. The combined company has rolled up Numerify, a provider of analytics tools infused with artificial intelligence (AI), Experitest, a set of testing tools and Arxan, a provider of an application security platform. With the latest release, these capabilities have been integrated into the core Digital.ai platform in a way that goes well beyond merely providing access via a common user interface, said Holt.

    The goal is to provide organizations with a VSM platform through which better decisions can be made to optimize software development and delivery by first collecting data from all the DevOps tools employed and then using machine learning algorithms to surface optimization recommendations, noted Holt. As application development environments become more complex to manage, it’s already apparent that most IT teams will require AI capabilities embedded in a VSM platform to manage interdependent projects, noted Holt.

    Armed with those recommendations, it becomes simpler to reallocate resources in the event a critical project is going to be completed later than planned or shift resources to make sure that project is completed on time. A VSM platform also enables IT organizations to assess the impact those decisions will have on the rest of the business at a time when organizations have never been more financially dependent on the timely delivery of software. The late delivery of a single application module can wind up having a profound impact on revenue projections for organizations that increasingly rely on digital processes to engage customers.

    A recent survey conducted by Digital.ai found that many digital transformation initiatives are struggling, to some degree. Nearly half of respondents (49%) said they are not seeing the results they expected from their digital transformation efforts, and 54% admitted they were worried about their ability to compete. Over 90% need to see a better return on their digital transformation investments.

    Digital.ai claims it currently has more than 1,200 customers, including Allianz, Commerzbank, eBay, Janus Henderson and Levi’s that are using elements of the Digital.ai platform to better manage software development projects. Many of the users of those tools now include business executives and other application stakeholders that are employing a VSM platform to track the progress of application development projects. Digital.ai Analytics Lenses that are domain-specific make it simpler for different classes of end users to access pre-built dashboards and metrics, noted Holt.

    The market research firm Gartner has predicted that 70% of organizations will employ a value stream management platform by 2023 to improve flows across their DevOps pipelines. However, as DevOps platforms and project management applications continue to evolve, many are also adding many of the analytics capabilities found in a VSM platform. Each IT organization will need to decide which approach makes the most sense for them, but Digital.ai is clearly betting that as application development becomes more challenging, the need for an integrated VSM platform will become much more apparent.