staging-devopsy.kinsta.cloud

Category: DevOps Toolbox

  • Dynatrace Extends Reach of Observability Platform

    Dynatrace Extends Reach of Observability Platform

    Dynatrace this week updated its observability and software intelligence platform as part of an effort to expand its reach across modern enterprise IT environments.

    Announced at the online Dynatrace Perform 2021 conference, the company’s namesake platform can now capture logs from Kubernetes and Red Hat OpenShift as well as Amazon Web Services, Google Cloud Platform and Microsoft Azure cloud platforms.

    In addition, Dynatrace is adding support for open source log data frameworks such as Fluentd and Logstash. Those logs can now be centrally viewed via a Dynatrace Log Viewer that enables IT teams to search, analyze and segment both real-time and historical log data.

    Dynatrace also added a Cloud Automation Module based on Keptn, an open source tool for automating configuration of observability tools, orchestrating code tests and quality checks. Keptn was created by Dynatrace and is being advanced under the auspices of the Cloud Native Computing Foundation (CNCF).

    The company also launched a Software Intelligence Hub to make it easier to access more than 500 pre-configured integrations, as well as access tools for creating integrations without having to write code.

    Dynatrace also announced it has extended a previously launched Application Security Module to now include support for Node.js applications. In addition, the module includes the ability to enforce security policies against applications instrumented with its agent software, and offers extended capabilities to enable the detection of Kubernetes cluster vulnerabilities, as well.

    Finally, Dynatrace has added a Session Replay capability to its Digital Experience Module to enable IT teams to capture a mobile application experience.

    Steve Tack, senior vice president of product management at Dynatrace, said the company is moving quickly to add support for platforms and technologies widely employed within cloud-native applications to provide IT teams with a single platform through which they can manage monolithic and microservices-based applications.

    With the rise of microservices, IT environments are becoming too complex to manage without some type of observability platform. Historically, cost concerns limited IT teams to employing application performance management (APM) platforms, such as Dynatrace, only for their most mission-critical, monolithic applications. It’s now become apparent that observability platforms capable of correlating log and telemetry data captured from applications and infrastructure are required to effectively manage a modern IT environment.

    As part of that effort, Dynatrace is now collecting data from additional sources alongside the agent software it provides. That data is then fed into an observability platform, that Dynatrace has augmented with a Davis AI engine, to identify anomalies and other potential issues by employing machine learning algorithms.

    It’s not clear to what degree IT teams completely trust the recommendations surfaced by any AI engine. However, as platforms such as Dynatrace collect more data from an IT environment, the more accurate AI models tend to become. In fact,  IT teams that don’t have access to AI capabilities might soon be at a distinct disadvantage, compared to other IT teams that do.

    In the meantime, the battle for observability supremacy continues to intensify, as incumbent providers of APM platforms such as Dynatrace look to forestall a host of startup rivals, all promising greater visibility into IT environments at a lower cost. The challenge now is determining what level of visibility is achieved, and at what total cost.

  • New Relic Adds Visualization Tool to Observability Platform

    New Relic Adds Visualization Tool to Observability Platform

    New Relic announced today it has added a visualization tool, dubbed New Relic Explorer, to make it simpler for IT professionals to discover the root cause of issues that adversely affect application performance.

    Buddy Brewer, global vice president and field CTO for the Americas, New Relic, said the goal is to make it simpler for IT professionals to navigate and, ultimately, act on, all the metrics collected by the New Relic One observability platform.

    New Relic Explorer includes a New Relic Lookout capability that enables IT teams to drill down into telemetry data gathered from New Relic One, as well as other third-party sources, and a New Relic Navigator capability for determining the health of relationships between services, said Brewer. These capabilities make it possible to more easily identify correlations, abnormal history and traces that would be, for example, indicative of blind spots or unknown relationships between IT services, Brewer said.

    Just as importantly, IT professionals can more easily discover recent changes to an IT environment, which are most likely the cause of any new issue that is adversely affecting the IT environment, Brewer added.

    New Relic Explorer requires no configuration, and will be included as part of the existing New Relic Full-Stack Observability offering to give IT teams a single unified view of their IT environments, said Brewer.

    As IT environments become more complex, the amount of time spent looking for the root cause of an issue that might only take a few minutes to fix has substantially increased. As a result, organizations are allocating a significant amount of time to convene “war rooms” to identify the source of problems; those problems can now be more readily identified using New Relic Explorer.

    In general, Brewer said, New Relic remains committed to opening up the platform to external telemetry sources, including data collected using open source tools, such as Prometheus and OpenTelemetry agent software, both advanced under the auspices of the Cloud Native Computing Foundation (CNCF).

    New Relic, like providers of similar tools, has recently begun repositioning itself as a provider of an observability platform, rather than of application performance management (APM) tools, that provides insights into both applications and the infrastructure on which they depend. That approach promises to provide IT teams with more context any time an issue arises. As part of that shift, New Relic is making it clear that while it views its agent source as a richer source of telemetry data, its platform can consume relevant data wherever it can be found. New Relic will also remind customers that its agent software, and the other data collection tools it provides, are simpler to install and update.

    The tradeoff, of course, is cost. While open source software itself is free, the total cost of implementing and managing that open source software can be substantial. Regardless of approach, however, the days when IT teams only applied application monitoring tools to their most mission-critical applications because of cost concerns are coming to an end. It has become impossible to manage a modern IT environment made up of both monolithic and microservices-based applications without such capabilities.

  • Sauce Labs Acquires AutonomIQ to Advance App Testing

    Sauce Labs Acquires AutonomIQ to Advance App Testing

    Sauce Labs is acquiring AutonomIQ, a provider of a scriptless test automation platform based on machine learning (ML) algorithms.

    Matt Wyman, chief product officer for Sauce Labs, said the acquisition of AutonomIQ will play a critical role in enabling Sauce Labs to push testing further left toward developers and, ultimately, “citizen testers” that are becoming part of the DevOps testing tool chain.

    The acquisition of AutonomIQ comes on the heels of the company announcing its intent to acquire API Fortress, an application programming interface (API) testing platform provider. Terms of neither acquisition were disclosed.

    Wyman said the rise of DevOps coupled with an increase in the volume of applications being developed using low-code tools are the primary drivers of a need to shift testing further left. As more citizen developers are building applications, they require access to a testing platform that doesn’t require them to know how to write scripts to test applications, said Wyman.

    The AutonomIQ platform employs machine learning to understand, for example, natural language descriptions of test cases or captured mouse clicks. It then generates synthetic data and test cases that can self-heal when an application changes, said Wyman.

    That approach to testing is more feasible in software-as-a-service (SaaS) environments, where a custom application based on a platform such as Salesforce, ServiceNow, Workday, Oracle or SAP doesn’t tend to change as radically as an application being built from the ground up, Wyman said. Those classes of applications will still require either developers or a dedicated team of testers to build tests using scripts, said Wyman.

    In fact, Wyman said testing those applications is becoming more challenging in the age of microservices. The API Fortress acquisition addresses that issue, because microservices are dependent on APIs to communicate with other microservices, said Wyman. In general, Wyman said Sauce Labs is now moving beyond being focusing only on functional testing of user interfaces.

    It remains to be seen how quickly testing will move to the left. Developers are being held more accountable for the quality of their applications, so testing integration within the application development process has increased. This has led to application testing becoming more tightly integrated with continuous integration/continuous delivery (CI/CD) platforms. Less clear is to what degree those efforts might have reduced the burdens of a dedicated application testing team that typically evaluates applications after they have been constructed.

    Exactly where and how citizen testers are being incorporated into those processes is also unclear. In theory, citizen testers can bring more business process expertise to the testing process. Getting individuals with that level of expertise to make time to participate in application testing while an application is being built can be a challenge.

    Regardless of approach, however, it is already apparent that machine learning algorithms, along with other forms of artificial intelligence (AI), will play a much larger role in application testing in the coming months and years.

  • Lightstep Delivers Next Generation Observability Platform

    Lightstep Delivers Next Generation Observability Platform

    Lightstep this week announced general availability of a Change Intelligence observability platform based on a time-series database that is capable of processing a trillion events each day.

    Ben Sigelman, Lightstep’s CEO, said as IT environments become more complex, thanks to the rise of microservices and cloud-native computing platforms, existing monitoring and observability tools will not be able to keep pace with the rate of change in what have become highly dynamic IT environments.

    While AIOps promises to address that complexity by employing machine learning algorithms to analyze IT environments and surface recommendations, Sigelman said there will always be the need for observability platforms that enable IT teams to discover the root cause of an issue in a way that surfaces the insights needed to fix the problem in real-time.

    The Lightstep database was built by the same team that created Monarch, the globally-distributed in-memory time series database system that Google employs to monitor its applications and systems. Lightstep’s database makes it possible to collect metrics, in the form of distributed traces, at a level of scale that allows IT teams to analyze events across a distributed IT environment made up of both monolithic and microservices-based applications, said Sigelman.

    Lightstep is the latest entrant in an already crowded field of observability platforms, all seeking to consolidate the wide range of monitoring tools IT teams have used for decades.

    The challenge IT teams face is that each of those monitoring tools is focused on a narrow range of platforms. IT teams often lack context when an issue arises, and wind up trying to correlate reports from multiple monitoring tools in the hopes of discovering the root cause of an issue. Observability platform providers are making the case for a single platform that correlates application and infrastructure events in a way that makes it easier for IT to fix issues faster.

    Observability, of course, has been a core tenet of DevOps for years. The tools for achieving that goal, however, have been cumbersome to implement and maintain using legacy application performance management (APM) platforms. Most of those platform providers, have rolled out what are positioned as next-generation observability platforms. Now, IT organizations will need to decide if they want to maintain investments in existing platforms versus moving to one of the raft of upstarts looking to dethrone APM incumbents.

    The startups are counting on a massive expansion in demand for observability platforms. IT organizations have tended to limit their usage of APM platforms to mission-critical applications due to cost and the challenges associated with maintaining the agent software needed to collect metrics from each application. Modern observability platforms have automated much of the metrics collection process, while open source software promises to make metrics collection more affordable..

    The challenge, of course, is that many organizations are already struggling to manage complex IT environments, and can’t necessarily wait for that open source software to mature.

  • Hybrid Low-Code: The Next Step in App Development

    Hybrid Low-Code: The Next Step in App Development

    The promise of low-code development has long been the ability to develop business-critical applications by humans with little programming experience. In fact, over the past year or two, the lines between low-code and no-code have become increasingly blurred. Low-code platforms have incorporated more and more functional no-code features to increase the efficiency of the developer even further. Some of these platforms have become so intuitive to use, the idea that anyone can create an app has evolved into the idea of citizen developers. But is low-code really the be-all and end-all when it comes to app development? Seems the answer to that is, “It depends.”

    It has become glaringly obvious that exclusively no-code platforms can’t create complex applications. But then again, these platforms were never really designed with that kind of functionality in mind. No-code can be a highly valuable, rapid prototyping tool as well as a decent tool for very small, very specific apps. These apps would be best suited for intradepartmental use or to extend the functionality of very specific SaaS tools. No-code is not going to power your business-critical applications, and a not-quite-a-developer is not going to lighten your IT load.

    But what about low-code? Can low-code be the bridge between citizen developers and the ever-growing list of backlogged apps? Maybe. Using citizen developers comes with a whole heap of issues that need to be addressed. While this topic can be the subject of an entire blog in its own right, I can quickly highlight the major issues to consider. How much of a citizen developer’s time should be dedicated to app development? Is using citizen developers going to create backlog issues in their primary departments? Who is going to train and support citizen developers? How is IT ensuring that citizen developer-created apps are secure, scalable and extendable? As great as citizen developers sound, they still are not a definitive solution.

    A realization has dawned in the low-code industry. Low-code can’t be and do everything, but it can be a useful development tool to speed up application development. However, most low-code platforms are in their own development silos, separated from other development tools with their own IDEs. Instead, one idea is to create a quick and easy-to-use user interface, drag and drop some app functionality, and then finish complex apps in a language the low-code platform can integrate with, such as Java, or via a Visual Studio plug-in. Even the biggest and best low-code vendors admit that just using low-code isn’t going to power your business.

    Low-code can’t be everything, but it can be a major part of everything. It just needs to look different from how most low-code platforms are designed. Using a hybrid low-code approach will allow organizations to truly use low-code from start to finish in the app development process. Rather than looking at low-code as a separate tool in the development process, a hybrid low-code approach brings low-code inside an IDE where traditional coding methods are still used.

    Is hybrid low-code the future of app development? I would say hybrid low-code is a next step in the evolution of app development. Low-code development tools shouldn’t be isolated in their own IDEs. It can be frustrating to leave a low-code IDE to finish the app in another IDE, and then have to connect the different elements into one cohesive app. As you can see, efficiency is reduced every time a developer leaves one IDE for another. Hybrid low-code views low-code as a tool inside a bigger development toolbox. It is there when convenient, but a developer isn’t forced to use just low-code. They can import already created assets from other languages, hand-code complex solutions, drag-and-drop when it makes sense, and create all the necessary components of a progressive web app with a click of a button.

    While there might be a profound realization that “traditional” low-code can’t do everything it originally promised, hybrid low-code could, instead, fulfill that promise.

  • AppDynamics Partners With Cisco to Secure Application Runtimes

    AppDynamics Partners With Cisco to Secure Application Runtimes

    AppDynamics today announced its agent software, which it provides as part of its observability platform, now has the ability to enforce application security policies.

    Developed in collaboration with the security business unit of parent company Cisco, the Cisco Secure Application offering, available from AppDynamics, can detect attacks, identify deviations in application behavior and block attacks automatically.

    Gregg Ostrowski, a regional CTO for AppDynamics, said the goal is to make it simpler for IT teams that employ AppDynamics for monitoring and observing their IT environments to also embrace DevSecOps best practices. In effect, IT teams can now piggyback security for application runtimes on their existing investment in AppDynamics, Ostrowski said.

    The AppDynamics approach provides the added benefit of easy integration with the Cisco security tools to improve collaboration between DevOps and cybersecurity teams, Ostrowski said. Security details correlated with the application topology make it easier to share context in a way that identifies the actual business relevance of any security event, he added.

    As organizations accelerate digital business transformation initiatives, Ostrowski said the need to embrace DevSecOps best practices is becoming more urgent. The level of risk attached to these types of projects is significantly higher than with previous generations of applications, Ostrowski said.

    While most organizations appreciate the need for greater application security, there’s a debate about how best to achieve that goal. There’s general agreement that developers need to be more involved. However, shifting responsibility for application security to the proverbial left often comes at the expense of developer productivity. AppDynamics is making a case for enabling IT teams, that may already rely on its application performance management (APM) platform, to enforce policies defined by the cybersecurity team.

    Of course, there’s still a need to provide developers with the tools required to write more secure code in the first place. The debate is over how involved in the cybersecurity management process developers need to be after applications are deployed in a production environment.

    Arguably, the goal should be to enable both teams to accomplish their respective tasks in a way that doesn’t require a constant stream of meetings and updates. In the event a vulnerability is discovered, it’s critical for security teams to determine the threat level that vulnerability represents. Otherwise, remediation of that vulnerability will be just one more item in a long list of patches that developers are already working on.

    Regardless of approach, there are now myriad ways to improve overall application security. In effect, the same defense-in-depth approach that IT organizations have relied on to secure network perimeters can now be applied to application security as applications are both constructed and deployed. The most significant challenge is not so much finding the tools required to improve application security, as defining the processes through which best practices can be consistently applied.

  • HashiCorp Expands Managed Services Offerings

    HashiCorp Expands Managed Services Offerings

    HashiCorp today announced the general availability of its Consul service mesh as a managed service on the HashiCorp Cloud Platform (HCP) along with a beta release of a managed instance of HCP Vault, a secrets management platform, on HCP.

    HCP is currently hosted on the Amazon Web Services (AWS) platform, on which the company is making available its complete portfolio as a managed service. In the longer term, HashiCorp plans to make its managed services available on all the major cloud platforms.

    Chris Kent, director of product marketing for HashiCorp, said despite the growing number of open source service mesh alternatives, many organizations would prefer to employ a service mesh provided by a single vendor that they didn’t have to provision and maintain. HashiCorp’s Consul service mesh provides a lightweight alternative that enables service-to-service networking and security via connection authorization and encryption and spans both Kubernetes clusters and virtual machine platforms using the mutual Transport Layer Security (mTLS) protocol.

    Applications can then employ sidecar proxies in a service mesh configuration to establish TLS connections for inbound and outbound connections without ever having to directly interface with Consul itself.

    HashiCorp is making the case for Consul at a time when internecine warfare is raging between proponents of open source service mesh platforms such as Istio, Linkerd and Kuma. The Consul service mesh provides an alternative that is simpler for developers to incorporate across both microservices-based applications running on a Kubernetes cluster and legacy monolithic applications running on virtual machines, Kent said. In contrast, Istio and Linkerd are designed solely for use in Kubernetes environments.

    It’s still the early days of service mesh adoption. In addition to simplifying application traffic routing between services, one of the other benefits of service mesh is that it provides a layer of abstraction above lower-level network application programming interfaces (APIs) and protocols that is more accessible to developers. As developers become more familiar with service meshes, the ability to programmatically include network and security operations within a DevOps workflow will grow. HashiCorp is collectively positioning Consul and Vault as foundational components for creating a zero-trust architecture.

    In the meantime, each IT organization will need to determine which type of service mesh makes the most sense for their environment. In many cases, organizations may find themselves employing multiple service meshes to address different use cases. Regardless of which they choose, service meshes will soon become a permanent fixture in the proverbial solar system around which IT services revolve.

    HashiCorp claims that more than 2,000 organizations signed up to participate in the HCP Consul and HCP Vault beta programs. That level of interest suggests interest is growing in consuming IT as a service rather than as a platform that requires deployment by an internal IT team. It remains to be seen the degree to which organizations will prefer to consume those services directly from a vendor, versus a cloud service provider or third-party IT services provider.

  • Atlassian’s Shift to the Cloud Gets Underway

    Atlassian’s Shift to the Cloud Gets Underway

    Atlassian today announced the general availability of Cloud Enterprise, a cloud-based service through which organizations can mix and match the company’s various offerings under a single subscription.

    The company has signaled its intention to shift toward cloud services for months; now, the initial Cloud Enterprise subscription will cover the company’s Jira Software, Confluence and Jira Service Management offerings.

    Bala Venkatrao, head of product for Enterprise Cloud at Atlassian, said the goal is to make it more cost efficient for organizations to consume the company’s software versus merely acquiring a license to deploy software in an on-premises IT environment.

    The company is also making controls available that enable governance of user and change management via a centralized admin hub. Administrators can assign users to instances, configure security policies and monitor usage trends through the hub. There are also built-in integrations with third-party identity-as-a-service providers, to enable administrators to automate provisioning and de-provisioning.

    Administrators can also set up and customize multiple application instances; they can keep data pinned to different regions to customize those instances with specific marketplace applications or configurations for compliance purposes.

    Finally, a marketplace will allow IT organizations to expand the number of applications they consume from Atlassian and its partners. A smart links and app switcher capability for Jira and Confluence Cloud enable easy collaboration across different instances of Atlassian applications.

    Atlassian currently has more than 194,000 customers, so it may take some time to transition the existing installed base to this model. In the meantime, Atlassian is pushing as many new customers as possible toward a cloud platform that makes it easier for Atlassian to keep customers current on the latest release of its software. Atlassian plans to support up to 20,000 users per application instance by later this year.

    Venkatrao said while the Atlassian portfolio is frequently consumed by individual end users, the Cloud Enterprise offering is designed to appeal to CIOs, and other senior level executives, that want to centralize billing for application services now accessed via the cloud. That approach will make it easier for large organizations to take advantage of discounts they may qualify for as overall usage increases, Venkatrao said.

    While Atlassian may be a little late to the software-as-a-service (SaaS) application game, Venkatrao noted that the Cloud Enterprise platform will make it simpler for Atlassian to apply AI to the metadata it will collect. Atlassian has already leveraged AI to improve document search within Confluence and Jira, in addition to employing predictive analytics to surface recommendations for including personnel on a project.

    It may be a slow transition to the cloud for Atlassian, but that transition is clearly underway.

  • vFunction Automates Conversion of Java Apps to Microservices

    vFunction Automates Conversion of Java Apps to Microservices

    vFunction has developed an eponymous platform capable of automatically converting a monolithic application written in Java into a set of microservices. The startup is emerging from stealth mode today.

    Fresh from raising $12.2 million in seed funding, vFunction CEO Moti Rafalin said the company’s platform employs dynamic analysis, static analysis, data science and automation to enable IT teams to reengineer, in a repeatable fashion, the source code used to create monolithic Java applications.

    As part of that process, vFunction also detects and eliminates code that is no longer executed to reduce the footprint of an application, minimize security risks and overall maintenance tasks.

    The vFunction platform is deployed as a server that communicates with agent software injected into the legacy monolithic application. The server then creates a microservice that is scanned by additional tools to determine how best to optimize it to run on, for example, a Kubernetes cluster based on the Red Hat OpenShift platform, said Rafalin.

    IT teams can also employ vFunction to determine which monolithic applications are better suited to being converted into a set of microservices that can be automatically extracted into separate compilable projects. Each project comes with an estimated timetable for completion that can be accessed via a Modernization Factory Dashboard and Application Complexity Assessment tool provided by the platform.

    Rafalin said most monolithic applications are made up of large amounts of ‘spaghetti code’ that was added over multiple generations by different development teams. Manually analyzing that code as part of an effort to refactor a legacy application would require weeks of effort, Rafalin said. As such, the rate at which most organizations are re-engineering applications is extremely slow, he said.

    In fact, it’s not unheard of for IT organizations to to start, but quickly abandon such because the time and effort required proved too costly. vFunction claims its automated, domain-driven processes accelerate manual refactoring by a factor of ten, resulting in a savings of anywhere from $300,000 to $500,000 per application.

    Pricing for vFunction is based on a per-application model. The company has also established alliances with system integrators such as HCL Technologies, Tata Consulting Services and Wipro that are regularly contracted by IT organizations to refactor their applications.

    Of course, not every monolithic application needs to be converted into a set of microservices. However, most monolithic applications have components that would be easier to maintain and support as a distinct microservice. Organizations, in general, are embracing microservices to build applications that are more resilient. In the event a microservice becomes unavailable, requests for services are rerouted to another microservice to make sure the application degrades gracefully, rather than crashes altogether. The challenge is that, over time, the dependencies that can exist between hundreds of microservices can be more challenging to manage than those of the monolithic application being replaced.

  • ARMO Aims to Simplify Microservices Security

    ARMO Aims to Simplify Microservices Security

    ARMO this week emerged from stealth to launch a platform to secure cloud-native workloads and improve visibility. The ARMO Workload Fabric technology attaches code within the memory invoked by a microservice to enable cybersecurity policies to be applied via a cloud service.

    Company CEO Shauli Rozen said the ARMO Workload Fabric is designed to enable IT organizations to implement a zero-trust architecture more easily within the context of a DevSecOps workflow.

    Fresh from raising $4.5 million in seed funding, Rozen said ARMO’s approach eliminates the need to deploy and manage agent software, container sidecars or runtime application self-protection (RASP) software to enforce security policies across what inevitably will become thousands of microservices distributed across an enterprise IT environment.

    That leaner approach then allows for a centralized management platform that can be deployed on a cloud or on-premises IT environment to apply policies that restrict which microservices can communicate with one another, Rozen said. The approach would ensure that only microservices developed using a continuous integration/continuous delivery (CI/CD) platform are allowed to communicate with other microservices, Rozen said.

    Integration with multiple CI/CD platforms is already provided, added Rozen.

    That approach allows policies to be applied to microservices regardless of how they are constructed, Rozen said. That capability is critical, because developers are building microservices using everything from Python and Java to containers, he said. Many of those microservices are also frequently replaced, Rozen said, which can make updating any associated agent software a significant DevOps challenge. Given all the existing dependencies between microservices, overall application environment security is only as strong as the proverbial weakest link. The ARMO Workload Fabric enables developers to add a small amount of code to implement security policies each time a microservice is rolled out into a production environment.

    As part of an effort to make it simpler for IT organizations to apply those policies, ARMO provides a pre-built set of policies that organizations can immediately apply, in addition to creating their own polices over time, Rozen said. In many cases, IT teams simply don’t have the time or expertise required to build those policies, Rozen added.

    Microservices are being built and deployed at such a breakneck pace that it’s nearly impossible for cybersecurity teams to keep up. The ARMO Workload Fabric provides cybersecurity teams a means to centrally manage security policies that would otherwise be implemented as code by developers. It provides a level of observability for how those cybersecurity policies are being implemented across microservices that typically have a lot of dependencies on one another, Rozen said.

    Most organizations today recognize there is a clear need to shift responsibility for application security further left toward developers. The challenge is finding a practical way to achieve that goal, and in a way that doesn’t adversely impact the rate at which applications are being developed. The key to achieving that goal is finding a way to apply microservice security polices that causes the least amount of friction possible to existing DevOps workflows.