Tag: microservices

  • Cortex Taps GitLab to Help DevOps Teams Manage Microservices

    Cortex Taps GitLab to Help DevOps Teams Manage Microservices

    Cortex, a provider of a platform for tracking ownership of microservices, this week announced its platform can now import services from the GitLab continuous integration/continuous delivery (CI/CD) platform.

    Anish Dhar, Cortex CEO, said the company’s platform is now integrated with more than 30 tools that are regularly employed by DevOps teams, including offerings from GitLab, Datadog, Sonarqube, Snyk and PagerDuty, as well as open source platforms such as the Kubernetes container orchestration engine and the Istio service mesh.

    Designed for site reliability engineers (SREs) and other DevOps professionals, the Cortex platform eliminates the need to rely on spreadsheets to manually track ownership of microservices. Instead, Cortex imports data residing within the tool employed by developers to surface who within an organization is responsible for maintaining which microservices.

    In addition, a Cortex dashboard enables DevOps teams to see which developers are on-call in the event of an unexpected incident, the latency rate microservices are experiencing and which vulnerabilities have yet to be remediated.

    Grades can also be assigned to specific microservices based on metrics that are associated with a specific microservice. That approach allows DevOps teams to apply gamification techniques using a scorecard to encourage developers to continuously improve their microservices, noted Dhar. That approach will also make it apparent to other developers which microservices running in a production environment can be most reliably employed, added Dhar.

    Cortex

    At the core of the platform is Cortex Query Language (CQL), a domain-specific language that allows DevOps teams to define granular rules that can be applied to, for example, on-call rotations, security vulnerabilities, package versions, service level objectives (SLOs) and the overall health of the microservice. Engineers can employ code in the form of YAML files to set reliability standards across teams and types of services through direct integrations with a variety of tools. In effect, Cortex provides a reliability-as-code platform, said Dhar.

    As responsibility for applications shifts further left, each development team is being held accountable for the life cycle of any microservice or application they create. The challenge enterprise DevOps teams are encountering is that when there are hundreds, even thousands, of microservices, it’s difficult to determine who on the development team is responsible for a specific microservice. Rather than trying to keep track of the relationship between development teams and microservices using a spreadsheet, Cortex is making a case for a tool that automates that discovery and tracking process.

    Most organizations today are embracing microservices to build and deploy more flexible applications at varying rates. However, it’s only a matter of time before they find themselves trying to navigate a web of interdependencies between microservices that can’t be managed using spreadsheets. DevOps teams, of course, might be inclined to use their skills to create their own tool for tracking microservices. However, given all the tasks at hand, maintaining a custom platform for discovering and tracking ownership of microservices is likely something better done by a vendor willing to maintain and support a purpose-built tool.

  • 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.

  • Automation is Needed for Reliable Cloud Platforms

    Automation is Needed for Reliable Cloud Platforms

    From six to 1,400 microservices in less than five years? At first glance, that sounds like overwhelming complexity. Can you actually see the entire system across all of the microservices? This is the key to highly available and reliable SaaS cloud platforms. But what does this mean, and how can SaaS providers achieve it?

    Over the past decade, the cloud has become the virtual space where the majority of companies’ business processes and communications take place. Considering the accelerated digitization processes of the last year alone, cloud computing plays an increasingly crucial role when it comes to making distributed teams more productive. As a result of these developments, the number of applications, microservices and interfaces is increasing, creating a more complex IT infrastructure.

    The reliability and availability of cloud services must, therefore, be a high priority for providers. Weak services and downtime not only cause frustration among customers, but can also lead to considerable financial losses on the customer side. Accordingly, SaaS providers must establish processes and methods that help them provide secure and highly reliable cloud infrastructures, or risk losing their customers.

    Microservices as the Foundation for Reliability

    Complexity is implied with every SaaS cloud platform. This can be managed in two different ways. On one hand, management can be done via a centralized monolith. Through this, complexity arises from a single system with only one interface to external systems. On the other hand, complexity can be distributed via smaller system units in the form of microservices. This means that the various functions of an application or service are broken up and assigned to several individual instances that communicate with each other. The advantage of this is that if a microservice fails, the entire application is not necessarily affected.

    Microservices in cloud environments have been enjoying steadily growing popularity for some time now. In fact, 76% of the companies surveyed as part of a 2019 Forrester study stated that microservices will be high on the business agenda for many companies in the future. Only 4% disagreed with this statement at the time. In 2020, a TechRepublic survey found that the majority of experts surveyed (73%) have already integrated microservices into their application processes, and 66% of respondents use them in the form of cloud services. Microservices are everywhere!

    Service Level Objectives and Automation

    Due to the numerous interfaces that arise with microservices and the need to be monitored, this architecture appears, at first glance, to be more error-prone than traditional monolithic systems. Some companies already rely on service level objectives (SLOs) – i.e., targets and measurable KPIs to ensure service quality – for a higher level of security. However, these are often limited to the outer layer of the entire system.

    Formulating appropriate SLOs for each microservice with additional alerts can counteract this. In combination, these provide profound protection of the system against creeping errors.

    In order to maintain an accurate overview with regard to security and security-related incidents, and thus ensure the reliability of the system, the microservices and their respective SLOs must be closely monitored and continuously tested. When we surveyed software and IT professionals back in 2019, we found that 71% of respondents reported that microservices-based architectures are much easier to test than monoliths. And with the help of automation, operational teams can ensure that the overall reliability level is close to 100% in every single instance of the systems, no matter how complex. A separate, centralized automation tool monitors all microservices in use and is able to alert appropriate teams about any abnormal activity with respect to individual breached SLOs. In addition, this tool should be linked to an incident management platform so that any breach can be remediated directly. By following this framework, software developers will enjoy the benefits of a more manageable and scalable microservices system.

    We live in a time when consumers expect technology to be updated regularly and run reliably. If this is not the case, they will simply opt for better alternatives. To prevent this, companies need to invest in more effective service structures. Microservices, combined with a central platform that automates testing and management, is the foundation for achieving reliability and scalability.

  • Despite Cloud Adoption, Enterprises Demand On-Premises Software

    Despite Cloud Adoption, Enterprises Demand On-Premises Software

    A recent report from Dimensional Research reveals that the demand for on-premises software is equal to that of public cloud. The report, which was commissioned by Replicated, a company specializing in on-premises software modernization, queried 405 participants in software development, executive, product management, sales and services roles to determine the needs, usage and challenges of on-premises software.

    The report revealed that some 90% of companies surveyed said their on-premises sales of software solutions continue to rise, while 70% that do not currently offer on-premises solutions intend to in the near future. 

    “In the past few years we’ve experienced a steady increase in interest from leading global companies who see that modern on-prem software delivery through containers and Kubernetes can make data protection and security much easier,” said Grant Miller, co-founder and CEO of Replicated. “Coupled with growing customer demand, it’s a win-win scenario for any industry.”

    While Miller’s view may be optimistic, the survey also revealed that the majority (65%) of companies cited privacy compliance as the top reason for using on-premises software delivery; an indication that the market is being influenced by cybersecurity issues more than any other factor. However, 54% also stated uptime and reliability were a primary driver for on-premises solutions, while 45% noted the importance of integration.

    The report indicates that enterprises, which have cited digital transformation and a movement towards the cloud as critical factors over the last two years, may also be thinking more about on-premises solutions in light of cybersecurity and compliance concerns. This, in turn, means that DevOps has the potential to gain even more traction in the enterprise. 

    While the report mentions the merits of an on-premises software strategy, it does raise the question of why more enterprises have not moved in that direction already. That hesitation to re-embrace on-premises software can mostly be attributed to perceived complexity, time commitments and the cost of engineering resources to make it happen. 

    Complexity is further highlighted by 74% of survey respondents reporting that it would take more than a week to install and configure on-premises software, and 29% stated an install could take over two months. For the 16% that claim they can rapidly install and configure on-premises software in less than a week, the potential for growth in the market is notable. 

    While the future remains somewhat uncertain, the report from Dimensional Research runs counter to other reports, such as a Synergy Research Group report that revealed in 2019, spending on cloud platforms edged past the resources spent on acquiring servers and software for on-premises data centers. “60% of the servers now being sold are going into cloud providers’ data centers and not those of enterprises,” said John Dinsdale, a chief analyst at Synergy Research Group, confirming the trend. “Clearly, companies have been voting with their wallets on what makes the most sense for them.”  Dinsdale said the growth of cloud infrastructure will continue to accelerate aggressively over the next five years. 

    Although conflicting observations tend to add to the market confusion, one thing is certain – DevOps shops have market opportunities to service customers deploying both to the cloud and on-premises software.

    on-premises

  • Web Application Security is not API Security

    Web Application Security is not API Security

    Do you follow the same procedures to secure a web application as you do an API? Is there a difference between the two?

    We’ve spoken about API security quite a bit in the past few months because we believe that there are critical differences between API security and traditional web application security. A lack of understanding of those differences is dangerous.

    Let’s look at the differences between the two and why you should treat API security differently from application security in general.

    What is API security?

    API security is the practice of defending web APIs against attacks. Building APIs, typically with microservices as the foundation, has become a growing trend. Many mobile applications and websites send and retrieve data using APIs, even if the end user is unaware of this fact.

    APIs are different from traditional web applications, and those differences can lead to critical security issues.

    What Makes APIs Different From Traditional Web Applications?

    I’ll answer that question with a picture, then proceed to “drop the mic.”

    Here’s the entire Netflix architecture, comprised of about 700+ microservices. (Source)

    (Picking the mic back up.)

    The above picture illustrates why APIs are fundamentally different from traditional web applications. What was once one request to one server has become dozens or hundreds of requests to dozens or hundreds of microservices.

    Previously, the work was relatively easy; defend one large application. Now, you have to protect hundreds of small web applications and the data they access. Authentication and authorization don’t look the same. The built-in session management of your favorite framework has gone out the window. Each microservice is its own little kingdom.

    In addition, you now have to know where all of these API endpoints reside, what version they’re running, and how to scale them when demand increases.

    Finally, changes to the development and deployment environment cause changes in how malicious actors attack applications. Are you familiar with the new ways attackers target APIs?

    What Are the Most Significant Threats Against APIs?

    The OWASP API Top 10 project outlines 10 dangerous risks with APIs. (See this post for the breakdown.)

    Instead, let’s look at the big themes the API Top 10 brings to the forefront. Then we’ll discuss some specific breaches that illustrate what happens when APIs are vulnerable.

    Authentication and Authorization Win Top Prize

    Okay, maybe “Most Likely To Get You Hacked” isn’t much of an award, but authentication and authorization are the most prolific and dangerous API security flaws.

    Authentication and authorization in APIs feel like a new world for many developers. A development framework doesn’t manage a session, but instead, applications pass JSON Web Tokens (JWT) around with claims attached.  In a nutshell, every microservice must verify the caller’s identity and permissions before performing any work on their behalf.

    As the number of APIs grows, it’s more likely that developers will miss some authorization checks, and a data breach is waiting to leap out and strike when you least expect it.

    API Endpoints Are Everywhere

    I remember taking my two-year-old daughter to Disney’s Magic Kingdom during spring break. I had to slip a kiddie leash on her to make sure she didn’t disappear in the crowd. It was challenging to keep track of only one child in that vast mass of people.

    An explosion of microservices fills your infrastructure with a crowd of endpoints, and kid leashes don’t seem to fit Docker containers very well. It’s easy for APIs to disappear.

    Unfortunately, these “shadow APIs,” whether spun up by a developer for testing purposes or just an old version left out in the wild, can become a point of attack. They may not be secure, and if you don’t know they’re still publicly exposed, someone could be attacking it without your knowledge.

    Examples of Real API Vulnerabilities

    Let’s illustrate the differences between API and web app security by looking at real vulnerabilities.

    Shopify “Collaborator” Vulnerability

    Security researcher Uzsunny found a critical flaw in the Shopify “collaborator” functionality that allowed an attacker to assign themselves the “collaborator” role on any store. This feature unlocks all sorts of administrative functionality.

    It turns out that the API endpoint that handles this collaborator business logic didn’t verify that the request to add a collaborator to a store came from the store manager. Therefore, anyone could call that endpoint with the right arguments and get admin rights to any store on the Shopify platform.

    Check out our detailed post on how this vulnerability works and why it’d be hard to detect.

    Facebook Authentication Bypass Using Shadow APIs

    Obscurity isn’t security, and determined attackers will find forgotten API hosts. The AppSecure cybersecurity research team found a way to gain access to any Facebook account via a couple of API endpoints Facebook forgot existed. The AppSecure team received a $15,000 bug bounty.

    Although found in 2016, this bug illustrates a kind of vulnerability prevalent in API architectures. This bug was subtle but demonstrated how the smallest crack could let an attacker run amok.

    The bug existed in Facebook’s password recovery logic. When a user requested to recover their account because of a forgotten password, they received a random six-digit code via text message. They enter the code in the browser, which sends an API call with the code.

    Facebook placed rate-limiting on the endpoint to protect against brute-force attacks. The API blocked client requests after 10 failed attempts. However, API endpoints existed on other hosts, and Facebook’s engineers didn’t realize it. An attacker could send payloads to “beta.facebook.com” and “mbasic.beta.facebook.com” and brute force the recovery code. These endpoints didn’t have the ten try limit.

    Check out our detailed post on this vulnerability for more on how modern app sec tools probably would’ve missed this vulnerability.

    Uber API BOLA Vulnerability

    Broken Object Level Authorization (BOLA) is number one on the API Top 10 list. Uber’s API had this vulnerability. Thankfully, it was discovered by security researchers before malicious actors did damage (as far as we know). But it illustrates well how dangerous BOLA can be.

    The vulnerability leaked sensitive information, including an authentication token that could be used to perform a full account takeover.

    The vulnerability appears when a new driver joins the Uber platform. The browser sends the “userUuid” to the API endpoint, and the API returns data about the driver used to populate the client.

    Unfortunately, the API endpoint didn’t check if the calling client had the authorization to view its returned details. An attacker could add another “userUuid” and get a sizable JSON object with the other user’s account details, including first and last name, email address, and user identifiers.

    This vulnerability illustrates that revealing too much information is dangerous for any API (Excessive Data Exposure is number three on the Top 10). Also, inadequate authorization checks can lead to account takeover with minimal effort.

    Check out our detailed post to learn more about this vulnerability.

    The Future of API Security

    Application security technologies such as Web Application Firewall, Next Generation Web Application Firewall, and Runtime Application Self-Protection don’t typically find the kinds of vulnerabilities we’ve discussed. These attacks present as ordinary traffic, so many defenses let them through.

    The future of API security lies with business logic. Application security tools have to understand the application’s context and business logic to know that non-managers shouldn’t be adding collaborators to a store or that a client shouldn’t access that user ID’s information.

    Traceable AI uses machine learning to learn the application’s business logic, so these types of attacks are found and stopped. See Traceable AI in action and see what the future of API security looks like.

  • RapidAPI Adds Library to Invoke Kafka via API

    RapidAPI Adds Library to Invoke Kafka via API

    RapidAPI announced it has added support for the open source Kafka messaging software as another type of application programming interface (API) that DevOps teams can centrally access.

    An open source library provided by RapidAPI, available in beta, makes it possible to discover Kafka clusters and topics, view schemas and test and consume records from a browser via either the RapidAPI Marketplace or the RapidAPI Enterprise Hub. The library is based on Apache Avro and Confluent wire formats found in the open source confluent-schema-registry library. RapidAPI extended that library to add support for JSON and a protocol buffer, which is now being shared with the open source Kafka community.

    RapidAPI CEO Iddo Gino said DevOps teams can now discover all available Kafka clusters and instances in the same location where they find, test and connect to microservices based on REST, SOAP and GraphQL APIs. That effort is designed to complement initiatives, such as the AsyncAPI specification, that is now being advanced under the auspices of the Linux Foundation, Gino noted.

    RapidAPI is adding this capability because usage of Kafka to enable asynchronous communication across event-driven applications has significantly increased, Gino said. As the number of digital business transformation initiatives increased in the wake of the COVID-19 pandemic, Gino said reliance on asynchronous messaging platforms such as Kafka became a requirement. In many cases, synchronous communications across highly distributed applications simply isn’t feasible, Gino added.

    That doesn’t mean asynchronous requirements will replace the need for traditional synchronous APIs. Rather, developers will find themselves incorporating a greater mix of both as enterprise IT environments become more distributed, noted Gino. Applications are increasingly become one large puzzle that developers need to construct using various classes of APIs, added Gino.

    The library created by RapidAPI is expected to be generally available in the third quarter. In the meantime, adoption of Kafka continues to accelerate. The open source community that oversees development of Kafka, under the auspices of the Apache Software Foundation, claims more than 80% of all Fortune 100 companies are using the platform for everything from constructing data pipelines to running streaming analytics applications. In some cases, data is being queried directly while in transit versus waiting for it to be stored on-premises or in the cloud.

    Regardless of how Kafka is employed, developers are rediscovering event-driven architectures, that can trace their lineage to the 1980s, for building applications. The difference now is there an open source framework for handling the asynchronous communications required to build and deploy those applications at scale.

    It’s not quite clear how the rise of event-driven applications will impact DevOps workflows, as event-driven applications become more commonly built and deployed. However, as the APIs become more widely employed within the context of these applications, it should become simpler to incorporate them.

    The challenge is event-driven architectures typically requires developers to think differently about how their applications are structured, so it might be a while before Kafka – and other similar platforms – are pervasively employed across the enterprise.

  • CircleCI Adds Private Orbs to DevOps Toolchain

    CircleCI Adds Private Orbs to DevOps Toolchain

    CircleCI announced today it is enabling IT reams to configure their own private integrations around its namesake continuous integration/continuous delivery (CI/CD) platform.

    The company enables integrations with third-party services via reusable config packages, based on YAML files, known as orbs. Now, internal IT teams can create private orbs that they can securely reuse to invoke, for example, a frequently accessed microservice via the command line interface (CLI) and invoked via the CircleCI platform.

    CircleCI CEO Jim Rose said the goal is to make DevOps teams more efficient at a time when the number of microservices organizations are reusing is increasing steadily. Rather than having to manually integrate each of those services every time they are needed, a private orb will consistently automate the process using the same template, said Rose. That approach, over time, will enable DevOps teams to more easily build and maintain an ecosystem of microservices, Rose added.

    In general, Rose said, with more DevOps teams now working from home to help limit the spread of the COVID-19 pandemic, there is a greater need to automate as many tasks as possible to enhance overall DevOps productivity. Constructing an orb gives DevOps teams a relatively simple way of achieving that goal, Rose said. Today, there is often a small, elite group within DevOps teams that builds tools to automate processes in a way that the rest of the DevOps team can more easily consume. Private orbs make it easier for anyone on the DevOps team to create a reusable process, said Rose.

    Many of those DevOps teams are, of course, attempting to accelerate digital business transformation initiatives launched in response to the pandemic. Those initiatives are generally based on applications being constructed using microservices that, ideally, developers will reuse across multiple projects. The CircleCI private orbs can be remotely invoked from anywhere via the CI/CD platform the company manages on behalf of DevOps teams that employ it.

    It’s not clear to what degree IT organizations are shifting CI/CD platforms to the cloud in the wake of the pandemic. In theory, a cloud-based platform is more accessible to DevOps teams that, like most employees, are working from home. Even after the pandemic eventually subsides, many members of DevOps teams will undoubtedly be working from home more regularly.

    In the meantime, a recent analysis of data from 11 million workflows on the CircleCI platform suggests that, after an initial spike of activity in the early days of the pandemic, DevOps teams settled into a more deliberate pace of application development after quickly adjusting to what has become the new DevOps normal. That new normal is likely to change again once COVID-19 vaccines become more widely distributed, but there will certainly be no returning to the way applications were built and deployed prior to the pandemic.

  • 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.

  • 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.