Category: Uncategorized

Article originally posted on InfoQ. Visit InfoQ

Transcript

Posta: I’m going to be talking about moving off policy and resilience to your internal developer platforms. How many people are working on or use an internal developer platform at the company at which they’re at? I work for a company called solo.io. Solo is based here in Boston, actually, in Cambridge. At Solo, we work on open-source cloud networking technologies. We are very involved in the Istio project, the founders and the lead contributors. We lead the innovation and a lot of the stuff that’s happening in the Istio project, as well as some of the surrounding periphery projects, some of which we’ll be talking about.

Digital Experiences – Driven by APIs and Services

As you know, digital experiences are how we do things today, when we get around. I flew here to Boston. I got on my phone. I booked to travel. How many of you remember what it was like before that? You had to pick up a phone and make a call to a travel agent to book your flights, to book your hotel. You had to call some random number to book a taxi, and hopefully that taxi showed up. Digital experience has made our lives a lot easier today. We save a lot more time, and that’s extremely valuable. APIs and services underpin the apps on our phones and the digital experiences that we use. These organizations, these businesses, they see APIs and services and the infrastructure to get those live and into production as driving a lot of business value, being differentiating.

The developers and the time that they put into building out these new services, new capabilities, are extremely valuable. The challenge with that is getting code and getting these changes into production. I work with organizations that experience those all the time. A big part of that is the siloed nature of their organizations. They build their code. They stage. They get it ready. You got to now make changes to your API management system, to your load balancers, to your firewalls. The way these organizations have been structured aren’t conducive to being able to do this very quickly. They’ve made decisions in their own silos. The integrations between those silos are very complex and brutal and expensive. If you want to get anything done, what do you do? You open tickets, and you sit and you wait.

Hopefully, these teams will go off and go to these UIs, and point and click, and these manual steps to get things done, make the changes, and then eventually you can get things into production. That’s why you’re probably seeing and we see this. We work, like I said, very closely with these organizations that are going down this path of building platform engineering teams. Building internal developer platforms to try to bridge and work across these silos, to try to build internal APIs, to support automation so that they can build the tools, the workflows, the UIs, the experiences for their developers to be able to self-service, and build, deploy their code into production as quickly and safely as possible. They build these paved paths or these golden paths.

The platform engineering team and the platform itself is intended to be a business value accelerator. We want to improve the ability to get these APIs and these services out into production faster. We want to improve efficiencies. We want to maintain or improve compliance, do things like reduce cost, and lock-in, and so on. This is a trend that we’re seeing.

Internal Developer Platforms

How many people have built their own house? It’s not easy. It’s not something I would want to do. I’ve lived through a remodel, and don’t want to do that again. When you build a house, you don’t start with laying electrical wire or putting doors. You start with the foundation. You start building walls and a roof and so on. I think about internal developer portals like a house. It’s a foundation, a platform on which you can get value out of it. Build value. Do things. Work from home. Raise a family. Raise your pets. Sleep comfortably, and then be productive the next day. Internal developer platforms lay that foundation so developers can actually get their work done and be efficient.

The organizations that we work with are trying to improve their cross-team and silo communications. They’re adopting new technologies like containers and cloud, and building automations, CI/CD, putting in observability tools, and so on. There is something missing, and it is fairly glaring when we start working with them. Anybody care to take a guess what’s missing from this list right here? Security is very important. Absolutely. These services need to communicate with each other.

Gregor Hohpe just released a book on platform engineering, platform strategy. He identifies the needs for an internal developer platform, and he calls it the four-leaf clover of engineering productivity, and delivery pipeline, monitoring operations, the runtime, compute, all that stuff. Obviously, very important. You need to solve the communication problem. You need to solve the networking problem. When we work with these organizations, we see this as, they built the foundations, they put the containers and lambda and whatever else they’re going to use, CI/CD, and they still have challenges getting code out into production.

T-Mobile did an internal review of, why is it taking weeks to get changes out into production, even though they’ve adopted these modern platforms? You can go and take a look at this talk where Joe Searcy goes into the details of that research and how they built their platforms to solve some of this. They found that 25% of developers’ time was spent on these nonfunctional requirements, like routing, like security, some reliability stuff. That they would open these tickets, try to get changes into production, and sit and wait. They would find that for production issues and outages and stuff that they had, 75%, three-quarters of those were caused by network misconfigurations.

Modernizing Networking

If you’ve not addressed the networking and communication parts of your platform, you’re still relying on some of the existing ways that don’t quite fit the way you’re building your cloud platforms, then your house is not finished. It’s probably not a good idea to live in it. Some of the outdated assumptions that we run into, especially in the networking and API management space, is those around how you specify policy. Oftentimes, this is implemented as firewalls and firewall rules and so on in these organizations. Things like, we’re going to write our policy in terms of network location or network identity, things like IP addresses. If something in the network changes, those policies become invalidated.

In this very simple case, we’re saying, this IP address can talk to this IP address. What we really mean is service A can talk to service B. If we start adding more workloads to the node that has service B, now we have this drift in policy. Service A can now talk to service C also because it’s deployed on this IP address, but that’s not really what we intended. This is a very simplistic example, and this can get very complicated, but as the network changes, the workloads change and shift and move, you get this policy bit rot, just like you do with code. Another one that frequently pops up in the cloud space is, these IP addresses are ephemeral. A host or a VM can go down and come back up and potentially come up with a new IP address. Or, in Kubernetes, pods will recycle and have new IP addresses. Policies written in terms of those IP addresses are going to be invalidated as IPs get reassigned.

Another one that we see is, these organizations, they’ve implemented these API management systems to solve things for rate limiting and security and observability, and so on, originally intended for external APIs, now they’re using them for internal APIs. Now to go make changes and get changes into production, you have to open tickets. It’s not uncommon that we see organizations saying it takes couple weeks to make changes to their load balancers, to their API management systems, and so on. From a workflow standpoint, this causes bottlenecks. From a technology standpoint, these systems, the tenancy model we see where certain APIs misbehaving will impact other APIs and so on.

From a technology standpoint, there’s bottlenecks and issues there as well. They can force unnatural traffic patterns. We’ve seen this many times, where workloads in a single cluster want to communicate with each other, one API calls another. To do that, they have to be forced out of the cluster, out through load balancers, out into some centralized API gateway, then through the gateway, back down through load balancers, eventually back into the cluster. These workloads might have been deployed on the same host, but for them to get the policies and authentication, authorization, observability, they have to go through these unnatural patterns.

One thing that I pointed out in T-Mobile, is that, developers sometimes they’re like, “I don’t want to open tickets. I don’t want to deal with all this infrastructure stuff. I’ll just write it in my code. I’ll just write the security stuff, the load balancing. I’ll just write the service discovery stuff. I just put it into my code”. That gets expensive, doing across different languages, different frameworks, making the business logic all convoluted, because now you have this networking code in there. From a security standpoint, it’s not that easy to get right. Using tokens, using keys, usernames, passwords, putting that all over the environment, it’s very easy to have a mistake creep in and have a security vulnerability. I blogged about this in much more detail, especially around using JWT tokens as service identity. Using JWT tokens, all that stuff, for user identity, you log in, OAuth, whatever, that’s all good.

For service-to-service communication and workload identity, there’s a lot of things that can go wrong there. What we need for modern networking is something that’s not highly centralized. We don’t need a distributed implementation. We need to tie it into our existing infrastructure as code, GitOps style workflows and automation. We want standard interfaces to be able to integrate with other pieces. There’s not going to be one technology that does everything. We need standard interfaces. We need to do the networking stuff that we’ve been doing already, traffic routing, load balancing, authentication, authorization, rate limiting, observability. We still need those capabilities. If you’ve built your platform and you don’t have those capabilities, then your house is unfinished.

Finishing the House (Istio)

Like I said, I remodeled my house probably about 5 years ago now. It was a bit of a pain. Eventually, we did reinstall new pipes, new electrical, ACs, especially in Phoenix right now. To live comfortably in your house, you need those pieces. The analogy there is, the locks on the doors are like the authentication/authorization for specific requests, for every request between services. You need load balancing, retries, timeouts, circuit breaking, zone-aware load balancing, things like telemetry collection, distributed tracing, logging. Then, like I said, integrating with other parts of the systems. Maybe you have a policy engine like OPA, or Kyverno, or something, or your own homegrown one.

Maybe you have your own existing API gateway, and you need to integrate with that as well. We need nice, standard interfaces, just like when you’re building a house, to assemble these components. It needs to work for all the applications in your environment, regardless of what language, regardless of what framework they’re using. We don’t want the developers to go off and re-implement this themselves. That’s where things like a service mesh come into the picture. Something like Istio, I’ve been working on it for about seven-and-a-half years now, comes into the picture to solve this problem, transparently enabling things like mTLS, mutual authentication, telemetry collection, distributed tracing, and traffic control.

Anybody using Istio? Istio has been out for a bit, and has traditionally been implemented by deploying proxies next to the instances of your workload. If it’s a Java app, next to your JVM. If it’s a Python app, the actual process that runs the Python code. If it’s in Kubernetes, actually inside the pod. Deploying, getting this infrastructure-y stuff into your applications creates this coupling and friction.

First of all, how do you onboard? How do you get applications on? Now you have to inject this thing into it. If you already have other sidecars, do those play nicely together? How do you do upgrades? You got to restart all your apps because you got a new sidecar. Then there’s the performance, there’s the overhead. Sidecars were a necessary evil to implement this type of functionality, but this is the last thing I’m going to talk about sidecars. We’re going to talk more about the functionality of the service mesh, and we’ll dig into a little bit how we implement this functionality without using sidecars. In September 22, I think we announced publicly in the Istio community an implementation of Istio that doesn’t use sidecars. In May, actually, we finally got it to the point where it is now in a state where it’s usable in production. We have people using it in production already.

Demo

Let me just show you a quick demo what that looks like. In my demo app, we have three apps in three different namespaces. We have web API. We have recommendation. We have purchase history. If I go into web API, you’ll see we have an app running there. This signifies the web API team, different teams across the Kubernetes cluster. We don’t have Istio. We don’t have any sidecars or anything installed. Recommendation looks the same. Purchase history actually has two different versions, which we’ll use later in the demo to illustrate routing. In the default namespace, there’s a sleep app that we’ll use as a client, at least in this next step. In httpbin, another sample application. Web API calls recommendation.

Recommendation calls purchase history. If we call web API through the sleep app, we’ll see that, indeed, web API calls recommendation and recommendation calls purchase history here. We’re going to come over here and we’re going to actually start our demo. What we’re going to do is we’re going to install Istio. This will take a second, but you’ll notice in the command here, I’m going to use the new ambient profile. This is going to install Istio’s ingress gateway, which is just a default. It’s an Envoy proxy for getting traffic into the mesh or into the cluster. It’s going to install the Istio control plane, Istiod. Then it’s going to install a couple components that will enable us to do the sidecar-less implementation of Istio. I’ll talk a little bit more about what those components are.

As part of the installation, I want to install Grafana. I want to install some observability apps so that we can see some of the tracing. We’ll give it a second. We’ll take a look. You can see here in the namespace list, Istio system now appears. I click into there. Let’s see, things are still coming up. Grafana’s up. Istiod, right here, the control plane, the ingress gateway, and a few other components, ztunnel. We’ll wait for Kiali to come up. We’ll use Kiali here in a second. The first step we’re going to do is we want traffic into the mesh. We want it to come in through the Istio ingress gateway. We’re going to apply some routing policies to allow traffic in through the ingress gateway. The ingress gateway is exposed on this external IP address.

Once we apply this policy, we’ll end up using that IP address to make the call. The routing policy is very simple, match on a particular host, istioinaction.io. Then, route it to web API. Like I said, traffic comes into web API. Web API calls recommendation, which calls purchase history. We’ll do that. If we actually make a call through that IP address back here, you can see that we’re getting the correct response, and it goes through the Istio ingress gateway. What we’re going to do is we’re going to add our web API, recommendation, and purchase history, to the mesh, and we’re going to do that by labeling each respective namespace. In this case, we’ll also do the default namespace. There are some sample apps there. It will label the recommendation, and then the last one here, purchase history. That’s it. Our apps are now part of the service mesh. There is no sidecar running here, as you can see. This is Istio Ambient mode.

If we come over here to the Kiali console, yes, let’s go ahead and port forward that. Let’s do some port forwarding and get the Kiali console to come up. We don’t have much traffic going through here, so let’s get some traffic. We’ll send about, I think it’s 250 requests through the gateway, and that’s good. We should take a look at our workloads that we have deployed here, web API, recommendation, and purchase history. We see that Kiali recognizes the workloads here. If we look at the Istio config, we can see the Istio config that’s been deployed just not much going on, really, just allowing traffic into the ingress gateway. Then, lastly, if we click on the traffic graph? We still don’t see the traffic. Give it one more run, generate the metrics.

The metrics end up going into Prometheus. Kiali scrapes Prometheus, and should show the traffic flow. There we go. We can see web API calls recommendation, which calls purchase history. What we also see is through the lines between the different services, we see this lock. If I click on these locks and look off to the right-hand side here, we see that Istio is enabled. We have mTLS enabled between these services. The services are using SPIFFE workload identity, which we’ll talk about. We’ve done nothing more than just label the namespaces. We’ve already got the services into the mesh. They’re protected by mTLS, so their traffic’s encrypted. We have workload identity assigned here. That’s pretty good for just labeling a namespace.

Istio Ambient Mode (High-Level Overview)

The way Istio Ambient works, just at a high level, is it deploys an agent to each of the nodes in the cluster. This agent binds directly into the pod’s network namespace. What that means is traffic will leave the pod, but Istio Ambient will have already done some stuff to that traffic, so the ztunnel will have done that. In this case, what it’s doing is matching an mTLS certificate to that pod, and enabling mutual TLS. Once the traffic leaves the pod, it is already encrypted. It is already participating in mTLS. It’s being tunneled to whatever the destination is. Obviously that other side will participate in the mTLS as well. I’m certain I’m going to get this question, so I’ll draw a picture about exactly what the ztunnel is doing. Traffic is not going from the pod to the ztunnel. It is leaving the pod already having been encrypted by the ztunnel.

The ports are opened up inside of the network namespace of the pod, so we get the same behavior that we do with sidecars, sidecars actually deployed into the pod, but without deploying sidecars. That’s great for layer 4 connections mTLS, but what about layer 7, things like request-based routing, or retrying of a request that failed, or JWT validation and authentication and authorization. For that, what Istio Ambient does is it injects a layer 7 proxy that we call the waypoint proxy, into the traffic path.

Since we already control it with the ztunnel, if there are layer 7 policies, we can route it to a layer 7 proxy. That layer 7 proxy, we don’t want to treat that as some big, centralized gateway. What we want to do is have better tenancy for it. In Kubernetes where the default is to deploy a waypoint proxy per namespace, so for each namespace, you have your own layer 7 proxy. If you need more fine-grained tenancy, what you can do is deploy a waypoint proxy per service identity or service account in Kubernetes, for example.

You can control the tenancy of these layer 7 proxies. You don’t get these big centralized API gateways, but you do have API gateway functionality. In these proxies that now live in the network somewhere, they can be scaled. If you want high availability, you scale multiple of these waypoint proxies. You can size the proxies more appropriately to the traffic that is destined, in this case, for pod B. The sidecar approach, you just scale up more pod B’s, but then you get more sidecars, more proxies.

We’ve gone into a lot of performance analysis, resource cost analysis, comparing it to sidecar, comparing it to other service meshes. This was a fairly large deployment. I think we were doing in the order of 112,000 requests per second through this environment and setup. We took measurements of the baseline, what ambient looks like, what other service meshes look like, what the sidecar looks like, for comparison. Because of this optimization, where if you just need mTLS, you don’t have to inject sidecars, you don’t have to do anything, this network path becomes extremely fast. It’s just layer 4. If you need to use layer 7 capabilities and inject the waypoint, this also ends up being faster than the sidecar, because we’re processing HTTP only one time.

Sidecar does it twice, once on each side. The network hop that you take to get to the waypoint, the cost of that, we’ve seen in our performance testing is lower than having the sidecars perform the HTTP parsing, all the stuff that they need to do. Ambient ends up being simpler to onboard, simpler to upgrade and maintain, especially for security patches and all kinds of stuff that you have to do. It’s a fraction of the resources that need to be reserved for CPU and memory to run sidecars, because you don’t run sidecars. Performance is improved, especially in the layer 4 only cases. Actually, security gets a slight improvement as well. I’ll leave you with this link here – https://bit.ly/ambient-book . Lin Sun and I wrote a book, “Istio Ambient Explained”, and it goes into a little bit more detail about Istio Ambient. Go ahead and take a look at the istio.io website. Istio Ambient, like I said, just became available for production usage. It will eventually become the default data plane. Not right now, sidecars won’t go away. That’s the path that we’re on with Istio.

Auth, Policy, and Resilience

Let’s talk in more detail about auth, policy, and resilience, and how moving that to the platform makes a lot more sense, drives down costs, and so on. We’ll look at a few examples. One is Trust Bank. I’m going to use public references, so you can go and if you’re interested look them up. Trust Bank was this new digital bank that was starting up as a joint venture between a bunch of other big banks in Singapore, and they went from nothing to a million users in a very short amount of time. They were cloud first. They built on EKS and AWS, but for their networking components, they used Istio. The problems that they were trying to solve were around compliance, security, encrypted traffic. Things like, they started off with a handful of clusters. They wanted to add more clusters and deploy workloads into more clusters, but they didn’t want downtime for their apps. They wanted to be able to move apps to different clusters, different regions. They started to encounter regulatory concern around data gravity and that kind of stuff as well. They needed to be able to control the routing.

From an authentication, authorization standpoint, they didn’t want to force everything through these centralized systems. They needed a decentralized networking approach. That’s where Istio came into the picture. We talked a little bit about what the existing assumptions and existing approach to defining policy looks like with IP addresses and firewalls and so on. What we want to solve is the service-to-service communication and authentication problem. How does service B know that it actually is service A that’s calling it? That’s where a specification called SPIFFE comes into the picture. SPIFFE is a spec for workload identity and how to get those credentials that prove you are a certain workload. It specifies what they call a verifiable identity document, SPIFFE, verifiable identity document, that is usually in the form of an X.509 certificate. It doesn’t have to be, it can be other formats, but X.509 is a common one.

Then workflows for how does a workload get that document? How does service A prove that it is service A? The way that it works is, service A will request its verifiable identity document, an X.509 cert that says I’m service A. The SPIFFE workflow and the implementations behind the scenes will then go and say, I need proof that you’re service A. I’m going to go do a background check, basically. I’m going to go attest that you are indeed service A. I’m going to go check the machine that you’re running on. I’m going to check the context that you’re running in. I’m going to check the attributes assigned to you. If that all lines up and you really are service A, then I’ll give you this document. That X.509 document is presented by service A to service B, saying, I am service A.

Service B can look at it and check the authenticity of that document. A common way to do that is TLS and mTLS. This is where Istio comes into the picture. Istio can automate the mTLS connection transparently for your applications. Istio does implement SPIFFE, so they work very nicely together. Now if workload A is workload A, is cryptographically provable, and it’s talking with workload B, and we know these identities, these identities are durable, we can write policy about what services are allowed to talk with which other services. In regulated environments, this type of policy is extremely important. Istio allows you to write this type of policy in terms of workload identity in a declarative format that can be automated, fit into your GitOps workflows and pipelines, and so on.

Demo

I’m going to jump into a quick demo that shows what that looks like. Again, we have web API calls recommendation, which calls purchase history. The first thing that we’re going to do is we’re going to lock down all communication in the mesh. We’re going to deny all. In a realistic world, you can’t just come in and shut off all traffic. You can iterate and incrementally add these authorization policies and eventually get to a zero-trust environment where you deny all. For this demo, we’ll start with just lock down all traffic. The only thing we will allow is people can call the ingress gateway. We’ll apply this authorization policy, and we’re going to try to make a call to the gateway.

By the error message, you can’t really tell, but it makes it to the gateway, but that gateway says, I can’t route this to web API. Traffic can’t proceed in the mesh right now, everything is denied. What we want to do is adjust the policy. We want to allow the ingress gateway to call web API. Using an Istio authorization policy, what we’re going to do is do that based on identity, not what cluster this thing’s running on, or what IP address this thing’s running on, or what pod it is. We’re going to do it based on workload identity, the SPIFFE workload identity that I just described. We’re going to allow that traffic for web API. If we allow it and now make a call, we should see traffic go from ingress gateway to web API.

Not surprisingly, the rest of the traffic is still disallowed. Let’s go ahead and add that. We’ll add the policies to allow traffic between the rest of the chain of the services. Now, if I make that call through the gateway, everything proceeds. The calls work again. From the sleep app, which is in the default namespace, I shouldn’t be able to call web API. Ingress gateway can. Other apps cannot. Let’s take a look. I try to call it. That does not work, which is what we expect.

So far, this has been mutual authentication and policy enforcement based on identity, but we can be even more fine-grained than that. We can specify policies about what services can call what other services, and specific endpoints, specific HTTP verbs that they can call, specific headers that have to be present, or not present. We see a little bit of that in this next part. I want to allow the sleep service to call httpbin, but only at /headers, and only if this x-test-me header is present. Now we’re looking at layer 7. We’re looking at the request itself, the details of the request, and we’re going to build some authorization policies in terms of some of those details. In Istio Ambient, if you’re going to do anything with layer 7, you need that waypoint proxy that I mentioned.

This is that layer 7 proxy that gets injected into the network path. Those get deployed in Istio Ambient by default, one per namespace. I just created this waypoint proxy, if I come into the default namespace, we can see sleep, which calls httpbin. Now we’ve included this new waypoint proxy, and we’re going to apply that policy to allow sleep to call httpbin. It won’t work if we call /IP, that was not whitelisted, that was not part of our authorizations. If we call it with the right header on the right path, in this case, the call will go through. We get very fine-grain layer 7 authorization policies declaratively with Istio.

Traffic Control and Traffic Routing

The last section here goes into a little bit more of the traffic control and traffic routing. Intuit has given a number of presentations on how they’ve built their platform using Istio multi-cluster. One of their big use cases is, when they deploy a service, and they make an upgrade, they deploy the new version of that service into a different namespace. They might move it into a different cluster. What they need is globally-aware routing. When we deploy a new service, we don’t want to take an outage. Another company gave a similar talk, but their motivation, their reasons for needing that global routing and failover, were for data gravity and compliance reasons.

GDPR, you have to have your data in a certain region, and if you want to access it, you have to go through and to that that region. Istio is really good at controlling traffic, both load balancing, being zonal aware, being multi-cluster aware, and routing across multiple clusters. When we have traffic control down to the level of a request, we can also implement things like resilience. We can be resilient in terms of load balancing. We can be smart and cost optimized in terms of load balancing. We can also do things like timeouts, retries, and circuit breaking, and offload that from the app developers having to worry about that.

Like I mentioned, globally-aware routing. If a service is talking to a service in one cluster, but the destination service fails, we can fail over to a different cluster transparently, and still have mTLS, still have our authorization policies enforced, and do it in a smart way. We’re not going to automatically fail out to a different region. We would try to prefer locality. We’ll try to prefer zonal affinity. Then fail out to a different region as necessary. I mentioned circuit breaking. If I’m making a call to a service and it’s misbehaving, stop calling it, or at least for a period of time, back off. Then, slowly, try to call back into it.

Demo

This is the last part of the demo. Purchase history has two deployments, a v1 and a v2. If I call that, we see, in this instance, we had a response from purchase history v2. I call it again, also v2 it looks like. We should see it load balance. There we go. There’s a v1, v1, v2, so it’ll load balance about 50% is what Kubernetes does automatically, out of the box. What we want to do is force all the traffic to v1. That’ll be the production available version. We’ll write a default routing rule here that says, 100% of the traffic should go to v1, 0% should go to v2. However, we might want to introduce v2 as a canary. We want to be very specific and fine-grained about what services can call the v2 version.

To do that, we’ll add a match that looks for a specific header, and if it has this header, then we’ll route it to v2. Again, we’re doing Istio layer 7 stuff, so we’re going to add a waypoint proxy into the purchase history namespace. We can see that down here at the bottom. Let’s go ahead and apply that routing rule. Now let’s start making calls. Actually, we have deny all authorization policy. We have to enable that for the waypoint. Now what we’re going to do is call the services 15 times. We’re going to use jQuery to pull out the bodies, we see 15 times in a row. The call ends up going to purchase history v1. If I want to do the canary part, you can’t see it, but at the bottom here, we called the services with this header, which triggers that match in the routing, and routes it to purchase history v2. What if purchase history is misbehaving? What if it’s returning errors? I just deployed a version of purchase history that half the time is going to return 500 errors.

As we can see here, we call it a handful of times. With Istio, we can do timeouts, retries, circuit breaking type thing. Let’s take a look at a retry policy that we will want to add here. If you’re calling purchase history v1, down here in the bottom, you can see, I want to implement retries. I’ll retry up to three times on 500 type errors. If I apply this and then make calls, we should see, every time the calls succeed. They might be failing. We can check the retry metrics. They might be failing in the background, but the retries are kicking in and making it so that the call succeeds eventually.

Conclusion

Istio in general provides a lot of capabilities for fine-grained modern networking. Solving this networking challenge should be part of your modern internal developer platform. You can see that here in the stack. This is how it lines up in block diagrams. One thing I will say, and you’ll notice here, Istio is buried down here in the bottom of the stack. This is networking. Application developers shouldn’t have to know about Istio. The APIs, the workflows, the interfaces, the experiences that you build for your developer platform should enable things like maybe doing a canary release, or publishing telemetry and metrics to Grafana dashboards and so on, so that they can see what’s happening with their services.

Things like security policy are probably not driven by developers, but if your workflow includes that, then your workflow can generate those authorization policies and the details around what services can call which other services or API endpoints. All of that stuff should be automated away. They shouldn’t have to know about this. From a platform like, what are the business outcomes of the platform?

Originally, I mentioned, you want to increase business value. You want to increase compliance. You want to make things more efficient, and reduce cost. From a value standpoint, your code on the developer’s laptop, or in CI does nothing unless it gets into production. You can’t get value out of that. Tools like Istio implementing something like this allows you to do more safe releases, canaries, blue/green deployments. A lot of network telemetry can be pulled back, distributed tracing, and so on. You can make those decisions about whether to go forward and so on.

See more presentations with transcripts

Posted on mongodb google news. Visit mongodb google news

After tech investors licked their wounds yesterday on the launch of the Chinese artificial intelligence (AI) chatbot DeepSeek, today they saw an opportunity from the upheaval.

Software stocks broadly rallied as the stock market bet that costs to run AI infrastructure could come down and efficiencies could improve, benefiting the software companies that rely on that infrastructure and are launching their own AI platforms and looking to leverage the power of agentic AI.

That makes sense, as the AI infrastructure is being built to ultimately run software applications. Among the winners today were MongoDB (NASDAQ: MDB), Salesforce (NYSE: CRM), and GitLab (NASDAQ: GTLB). As of 11 a.m. ET, the stocks were up 8%, 5.4%, and 10.3%, respectively, on the news.

Continue reading

Source Fool.com

Article originally posted on mongodb google news. Visit mongodb google news

Posted on mongodb google news. Visit mongodb google news

MongoDB, Inc. (NASDAQ:MDB – Get Free Report) was up 7.4% during mid-day trading on Tuesday . The stock traded as high as $285.10 and last traded at $284.28. Approximately 819,510 shares changed hands during mid-day trading, a decline of 43% from the average daily volume of 1,427,558 shares. The stock had previously closed at $264.58.

Analyst Upgrades and Downgrades

Several research analysts have weighed in on MDB shares. Wells Fargo & Company upped their price objective on shares of MongoDB from $350.00 to $425.00 and gave the stock an “overweight” rating in a report on Tuesday, December 10th. JMP Securities reaffirmed a “market outperform” rating and issued a $380.00 price target on shares of MongoDB in a research report on Wednesday, December 11th. Robert W. Baird boosted their price objective on MongoDB from $380.00 to $390.00 and gave the stock an “outperform” rating in a report on Tuesday, December 10th. Scotiabank dropped their target price on MongoDB from $350.00 to $275.00 and set a “sector perform” rating on the stock in a report on Tuesday, January 21st. Finally, Cantor Fitzgerald assumed coverage on MongoDB in a report on Friday, January 17th. They set an “overweight” rating and a $344.00 price target for the company. Two equities research analysts have rated the stock with a sell rating, four have issued a hold rating, twenty-three have issued a buy rating and two have issued a strong buy rating to the company’s stock. Based on data from MarketBeat.com, the company currently has an average rating of “Moderate Buy” and a consensus price target of $361.00.

Get Our Latest Analysis on MDB

MongoDB Price Performance

The stock has a market capitalization of $21.11 billion, a PE ratio of -103.48 and a beta of 1.25. The firm’s 50 day simple moving average is $275.02 and its 200 day simple moving average is $269.23.

MongoDB (NASDAQ:MDB – Get Free Report) last posted its quarterly earnings results on Monday, December 9th. The company reported $1.16 earnings per share for the quarter, topping the consensus estimate of $0.68 by $0.48. MongoDB had a negative net margin of 10.46% and a negative return on equity of 12.22%. The business had revenue of $529.40 million during the quarter, compared to the consensus estimate of $497.39 million. During the same period in the previous year, the firm posted $0.96 earnings per share. The firm’s revenue for the quarter was up 22.3% on a year-over-year basis. Analysts expect that MongoDB, Inc. will post -1.79 earnings per share for the current fiscal year.

Insider Buying and Selling at MongoDB

In related news, CEO Dev Ittycheria sold 2,581 shares of the business’s stock in a transaction dated Thursday, January 2nd. The shares were sold at an average price of $234.09, for a total transaction of $604,186.29. Following the transaction, the chief executive officer now owns 217,294 shares in the company, valued at $50,866,352.46. The trade was a 1.17 % decrease in their ownership of the stock. The sale was disclosed in a filing with the Securities & Exchange Commission, which is available through this hyperlink. Also, CAO Thomas Bull sold 169 shares of the firm’s stock in a transaction dated Thursday, January 2nd. The stock was sold at an average price of $234.09, for a total transaction of $39,561.21. Following the completion of the sale, the chief accounting officer now owns 14,899 shares of the company’s stock, valued at $3,487,706.91. This trade represents a 1.12 % decrease in their ownership of the stock. The disclosure for this sale can be found here. Over the last 90 days, insiders sold 34,156 shares of company stock worth $9,220,473. 3.60% of the stock is currently owned by insiders.

Hedge Funds Weigh In On MongoDB

Institutional investors and hedge funds have recently made changes to their positions in the business. Hilltop National Bank grew its position in MongoDB by 47.2% during the 4th quarter. Hilltop National Bank now owns 131 shares of the company’s stock valued at $30,000 after purchasing an additional 42 shares during the last quarter. Quarry LP grew its holdings in shares of MongoDB by 2,580.0% during the second quarter. Quarry LP now owns 134 shares of the company’s stock valued at $33,000 after buying an additional 129 shares during the last quarter. Brooklyn Investment Group bought a new stake in shares of MongoDB during the third quarter valued at approximately $36,000. GAMMA Investing LLC raised its holdings in MongoDB by 178.8% in the 3rd quarter. GAMMA Investing LLC now owns 145 shares of the company’s stock worth $39,000 after acquiring an additional 93 shares during the last quarter. Finally, Continuum Advisory LLC lifted its position in MongoDB by 621.1% in the 3rd quarter. Continuum Advisory LLC now owns 137 shares of the company’s stock valued at $40,000 after acquiring an additional 118 shares in the last quarter. Institutional investors own 89.29% of the company’s stock.

MongoDB Company Profile

(Get Free Report)

MongoDB, Inc, together with its subsidiaries, provides general purpose database platform worldwide. The company provides MongoDB Atlas, a hosted multi-cloud database-as-a-service solution; MongoDB Enterprise Advanced, a commercial database server for enterprise customers to run in the cloud, on-premises, or in a hybrid environment; and Community Server, a free-to-download version of its database, which includes the functionality that developers need to get started with MongoDB.

See Also

This instant news alert was generated by narrative science technology and financial data from MarketBeat in order to provide readers with the fastest and most accurate reporting. This story was reviewed by MarketBeat’s editorial team prior to publication. Please send any questions or comments about this story to contact@marketbeat.com.

Before you consider MongoDB, you’ll want to hear this.

MarketBeat keeps track of Wall Street’s top-rated and best performing research analysts and the stocks they recommend to their clients on a daily basis. MarketBeat has identified the five stocks that top analysts are quietly whispering to their clients to buy now before the broader market catches on… and MongoDB wasn’t on the list.

While MongoDB currently has a “Moderate Buy” rating among analysts, top-rated analysts believe these five stocks are better buys.

View The Five Stocks Here

MarketBeat’s analysts have just released their top five short plays for February 2025. Learn which stocks have the most short interest and how to trade them. Enter your email address to see which companies made the list.

Get This Free Report

Article originally posted on mongodb google news. Visit mongodb google news

Posted on mongodb google news. Visit mongodb google news

Artificial intelligence is the greatest investment opportunity of our lifetime. The time to invest in groundbreaking AI is now, and this stock is a steal!

The whispers are turning into roars.

Artificial intelligence isn’t science fiction anymore.

It’s the revolution reshaping every industry on the planet.

From driverless cars to medical breakthroughs, AI is on the cusp of a global explosion, and savvy investors stand to reap the rewards.

Here’s why this is the prime moment to jump on the AI bandwagon:

Exponential Growth on the Horizon: Forget linear growth – AI is poised for a hockey stick trajectory.

Imagine every sector, from healthcare to finance, infused with superhuman intelligence.

We’re talking disease prediction, hyper-personalized marketing, and automated logistics that streamline everything.

This isn’t a maybe – it’s an inevitability.

Early investors will be the ones positioned to ride the wave of this technological tsunami.

Ground Floor Opportunity: Remember the early days of the internet?

Those who saw the potential of tech giants back then are sitting pretty today.

AI is at a similar inflection point.

We’re not talking about established players – we’re talking about nimble startups with groundbreaking ideas and the potential to become the next Google or Amazon.

This is your chance to get in before the rockets take off!

Disruption is the New Name of the Game: Let’s face it, complacency breeds stagnation.

AI is the ultimate disruptor, and it’s shaking the foundations of traditional industries.

The companies that embrace AI will thrive, while the dinosaurs clinging to outdated methods will be left in the dust.

As an investor, you want to be on the side of the winners, and AI is the winning ticket.

The Talent Pool is Overflowing: The world’s brightest minds are flocking to AI.

From computer scientists to mathematicians, the next generation of innovators is pouring its energy into this field.

This influx of talent guarantees a constant stream of groundbreaking ideas and rapid advancements.

By investing in AI, you’re essentially backing the future.

The future is powered by artificial intelligence, and the time to invest is NOW.

Don’t be a spectator in this technological revolution.

Dive into the AI gold rush and watch your portfolio soar alongside the brightest minds of our generation.

This isn’t just about making money – it’s about being part of the future.

So, buckle up and get ready for the ride of your investment life!

Act Now and Unlock a Potential 10,000% Return: This AI Stock is a Diamond in the Rough (But Our Help is Key!)

The AI revolution is upon us, and savvy investors stand to make a fortune.

But with so many choices, how do you find the hidden gem – the company poised for explosive growth?

That’s where our expertise comes in.

We’ve got the answer, but there’s a twist…

Imagine an AI company so groundbreaking, so far ahead of the curve, that even if its stock price quadrupled today, it would still be considered ridiculously cheap.

That’s the potential you’re looking at. This isn’t just about a decent return – we’re talking about a 10,000% gain over the next decade!

Our research team has identified a hidden gem – an AI company with cutting-edge technology, massive potential, and a current stock price that screams opportunity.

This company boasts the most advanced technology in the AI sector, putting them leagues ahead of competitors.

It’s like having a race car on a go-kart track.

They have a strong possibility of cornering entire markets, becoming the undisputed leader in their field.

Here’s the catch (it’s a good one): To uncover this sleeping giant, you’ll need our exclusive intel.

We want to make sure none of our valued readers miss out on this groundbreaking opportunity!

That’s why we’re slashing the price of our Premium Readership Newsletter by a whopping 70%.

For a ridiculously low price of just $29.99, you can unlock a year’s worth of in-depth investment research and exclusive insights – that’s less than a single restaurant meal!

Here’s why this is a deal you can’t afford to pass up:

• Access to our Detailed Report on this Game-Changing AI Stock: Our in-depth report dives deep into our #1 AI stock’s groundbreaking technology and massive growth potential.

• 11 New Issues of Our Premium Readership Newsletter: You will also receive 11 new issues and at least one new stock pick per month from our monthly newsletter’s portfolio over the next 12 months. These stocks are handpicked by our research director, Dr. Inan Dogan.

• One free upcoming issue of our 70+ page Quarterly Newsletter: A value of $149

• Bonus Reports: Premium access to members-only fund manager video interviews

• Ad-Free Browsing: Enjoy a year of investment research free from distracting banner and pop-up ads, allowing you to focus on uncovering the next big opportunity.

• 30-Day Money-Back Guarantee:  If you’re not absolutely satisfied with our service, we’ll provide a full refund within 30 days, no questions asked.

Space is Limited! Only 1000 spots are available for this exclusive offer. Don’t let this chance slip away – subscribe to our Premium Readership Newsletter today and unlock the potential for a life-changing investment.

Here’s what to do next:

1. Head over to our website and subscribe to our Premium Readership Newsletter for just $29.99.

2. Enjoy a year of ad-free browsing, exclusive access to our in-depth report on the revolutionary AI company, and the upcoming issues of our Premium Readership Newsletter over the next 12 months.

3. Sit back, relax, and know that you’re backed by our ironclad 30-day money-back guarantee.

Don’t miss out on this incredible opportunity! Subscribe now and take control of your AI investment future!

No worries about auto-renewals! Our 30-Day Money-Back Guarantee applies whether you’re joining us for the first time or renewing your subscription a year later!

Article originally posted on mongodb google news. Visit mongodb google news

Posted on mongodb google news. Visit mongodb google news

Article originally posted on mongodb google news. Visit mongodb google news

Posted on mongodb google news. Visit mongodb google news

After tech investors licked their wounds yesterday on the launch of the Chinese artificial intelligence (AI) chatbot DeepSeek, today they saw an opportunity from the upheaval.

Software stocks broadly rallied as the stock market bet that costs to run AI infrastructure could come down and efficiencies could improve, benefiting the software companies that rely on that infrastructure and are launching their own AI platforms and looking to leverage the power of agentic AI.

That makes sense, as the AI infrastructure is being built to ultimately run software applications. Among the winners today were MongoDB (MDB 7.34%), Salesforce (CRM 3.70%), and GitLab (GTLB 12.34%). As of 11 a.m. ET, the stocks were up 8%, 5.4%, and 10.3%, respectively, on the news.

Image source: Getty Images.

Software stocks are soaring

All three stocks have staked their future on AI in different ways.

MongoDB is a provider of NoSQL database software, and AI has huge potential applications in the database sector. MongoDB has launched an AI Applications Program (MAAP), and is working with companies like Meta Platforms.

It also said that using AI tools along with professional services can reduce the cost of migrating legacy applications onto MongoDB by more than 50%.

However, management also told investors that AI wouldn’t be a meaningful tailwind for fiscal 2025, which ends this month, though it sees it as a valuable opportunity and a question of when, not if. The technology behind DeepSeek could help accelerate AI demand for companies like MongoDB by making it more efficient and accelerating its deployment.

Salesforce is already pushing hard into AI with Agentforce, its agentic AI tool that it launched in September. Agentforce hasn’t made a notable impact on Salesforce’s business yet, though it’s still very early, and the company has not yet reported fourth-quarter results.

However, Salesforce is the kind of company that looks well positioned to capture demand for AI software, as it’s well entrenched as the leader in customer relationship management (CRM), with more than 150,000 customers, including Fortune 500 companies and small and medium-sized businesses.

Like MongoDB, Salesforce helps organizations manage data, in this case related to sales and customer service, as well as AI tools that make that easier and cheaper for customers.

Finally, GitLab is a specialist in cloud-based DevSecOps, or helping developers and organizations securely manage their IT infrastructure and deploy new applications and programs. It automates DevSecOps, and its software replaces a number of point solutions that businesses had traditionally used to meet those needs.

AI can play a role in GitLab in a number of ways. It launched GitLab Duo, a suite of AI features that assist developers, while they work in GitLab, and DeepSeek could also drive increased interest in building on platforms like GitLab, making it cheaper to build AI features into programs. That could attract more interest in using GitLab as it increases its potential utility.

What’s next for the software sector?

Investors have jumped to a number of conclusions over the last two trading sessions in response to DeepSeek, but at this point, a lot is still unclear about how AI might change.

In a geopolitical environment where TikTok has essentially been banned because of a national security risk, it’s hard to imagine a Chinese AI chatbot not facing a similar restriction. Still, the technology is out there, which means American companies are likely to copy it or improve upon it. Already, Meta is reportedly working on a war room to reverse-engineer DeepSeek’s technology so it can beat it and capture the related cost savings.

Technology costs tend to go down over time, even when there isn’t a major leap like DeepSeek, so software companies like these three should benefit from falling AI costs and improved efficiencies over time, no matter what happens with DeepSeek.

Taking the long view, MongoDB, Salesforce, and GitLab are all industry leaders and should benefit from AI over the long run. That’s one reason to be bullish on these stocks as the AI future continues to unfold.

Article originally posted on mongodb google news. Visit mongodb google news

Posted on mongodb google news. Visit mongodb google news

MongoDB Inc. (NASDAQ: MDB) has experienced a notable 7.4% surge in its stock price today, reaching approximately $282.34. This bullish momentum comes amidst a backdrop of positive market sentiment and strategic developments within the company. As investors look to understand the factors contributing to this rise, several key elements emerge that highlight MongoDB’s growth potential.

What’s Driving the Surge in MDB Stock?

A significant factor contributing to today’s price increase is the anticipation surrounding MongoDB’s upcoming earnings report scheduled for March 5, 2025. Analysts forecast that the company will report revenues of approximately $1.98 billion, reflecting a year-over-year growth of 17.39%. This optimistic outlook is supported by expectations of strong performance across its Atlas platform and Enterprise Advanced segments.

Positive Market Sentiment and Analyst Upgrades

Recent analyst upgrades have also fueled investor enthusiasm for MDB stock. Following the release of favorable guidance and growth forecasts, several analysts have revised their price targets upward. The consensus among analysts indicates a strong buy sentiment, with many projecting that MDB could reach an average price target of around $380, suggesting a potential upside from current levels.

Innovations in AI and Cloud Services

MongoDB’s strategic focus on artificial intelligence (AI) integration within its products has positioned it favorably in a competitive landscape. The company’s Atlas platform benefits from increased adoption of multi-cloud solutions and AI-driven applications. As businesses continue to modernize their data infrastructure and leverage cloud capabilities, MongoDB stands to gain significantly from this trend.

Resilience Amidst Market Challenges

Despite facing challenges such as heightened competition in the database market and macroeconomic headwinds that have impacted growth rates over the past year—where the stock had declined by nearly 38%—MongoDB’s fundamentals remain robust. The company has made strategic investments in enterprise accounts and expanded its professional services to accelerate legacy application modernization.

Technical Analysis: Insights from Recent Trading Patterns

From a technical perspective, today’s surge indicates a positive shift in investor sentiment towards MDB after a period of volatility. The stock opened at $267.58, reached a high of $286.83, and established a low of $263.88 during trading hours. This movement suggests that investors are responding favorably to recent developments and are optimistic about future performance.

Key Market Metrics

• Market Capitalization: Approximately ₹2.10K Cr
• 52-Week High: $509.62
• 52-Week Low: $212.74

These metrics highlight the significant fluctuations in MDB’s stock price over the past year and underscore the potential for recovery as market conditions improve.

Broader Market Context: The Tech Sector’s Influence

The performance of MongoDB is also reflective of broader trends within the technology sector. As companies increasingly prioritize digital transformation and cloud adoption, demand for robust database solutions continues to grow. This environment creates opportunities for MongoDB to expand its customer base and enhance its service offerings.

Future Outlook: What Lies Ahead for MongoDB?

Looking ahead to fiscal year 2025 and beyond, analysts project continued growth for MongoDB as it capitalizes on emerging trends in AI and cloud computing. The anticipated revenue growth rate of 17% year-over-year aligns with industry expectations for robust demand in cloud database services.

Furthermore, as businesses increasingly adopt hybrid cloud strategies and seek scalable database solutions, MongoDB is well-positioned to benefit from this shift. Analysts predict that if current trends continue, MDB could see significant gains throughout the year.

Related

Article originally posted on mongodb google news. Visit mongodb google news

Posted on mongodb google news. Visit mongodb google news

Nisa Investment Advisors LLC increased its stake in MongoDB, Inc. (NASDAQ:MDB – Free Report) by 428.0% during the 4th quarter, according to the company in its most recent disclosure with the Securities and Exchange Commission. The fund owned 5,755 shares of the company’s stock after purchasing an additional 4,665 shares during the period. Nisa Investment Advisors LLC’s holdings in MongoDB were worth $1,340,000 as of its most recent SEC filing.

Other hedge funds have also bought and sold shares of the company. Jennison Associates LLC lifted its position in MongoDB by 23.6% in the 3rd quarter. Jennison Associates LLC now owns 3,102,024 shares of the company’s stock worth $838,632,000 after buying an additional 592,038 shares during the last quarter. Geode Capital Management LLC lifted its position in MongoDB by 2.9% in the third quarter. Geode Capital Management LLC now owns 1,230,036 shares of the company’s stock valued at $331,776,000 after purchasing an additional 34,814 shares during the last quarter. Westfield Capital Management Co. LP boosted its position in MongoDB by 1.5% during the 3rd quarter. Westfield Capital Management Co. LP now owns 496,248 shares of the company’s stock valued at $134,161,000 after buying an additional 7,526 shares during the period. Holocene Advisors LP grew its holdings in MongoDB by 22.6% in the 3rd quarter. Holocene Advisors LP now owns 362,603 shares of the company’s stock worth $98,030,000 after acquiring an additional 66,730 shares during the last quarter. Finally, Assenagon Asset Management S.A. increased its holdings in MongoDB by 11,057.0% during the 4th quarter. Assenagon Asset Management S.A. now owns 296,889 shares of the company’s stock valued at $69,119,000 after purchasing an additional 294,228 shares during the period. 89.29% of the stock is currently owned by institutional investors.

Insider Buying and Selling

In other MongoDB news, Director Dwight A. Merriman sold 1,000 shares of the firm’s stock in a transaction that occurred on Tuesday, January 21st. The stock was sold at an average price of $265.00, for a total value of $265,000.00. Following the sale, the director now directly owns 1,116,006 shares of the company’s stock, valued at approximately $295,741,590. This trade represents a 0.09 % decrease in their ownership of the stock. The sale was disclosed in a document filed with the Securities & Exchange Commission, which is accessible through this hyperlink. Also, insider Cedric Pech sold 287 shares of MongoDB stock in a transaction on Thursday, January 2nd. The shares were sold at an average price of $234.09, for a total transaction of $67,183.83. Following the completion of the sale, the insider now directly owns 24,390 shares in the company, valued at $5,709,455.10. This represents a 1.16 % decrease in their position. The disclosure for this sale can be found here. Insiders have sold a total of 34,156 shares of company stock valued at $9,220,473 over the last ninety days. Company insiders own 3.60% of the company’s stock.

MongoDB Price Performance

NASDAQ MDB traded up $19.42 during trading on Tuesday, hitting $284.00. The company’s stock had a trading volume of 3,452,990 shares, compared to its average volume of 1,615,993. MongoDB, Inc. has a fifty-two week low of $212.74 and a fifty-two week high of $509.62. The company has a market cap of $21.15 billion, a PE ratio of -103.65 and a beta of 1.25. The business’s 50 day simple moving average is $275.02 and its 200-day simple moving average is $269.23.

MongoDB (NASDAQ:MDB – Get Free Report) last announced its quarterly earnings data on Monday, December 9th. The company reported $1.16 earnings per share for the quarter, beating analysts’ consensus estimates of $0.68 by $0.48. The firm had revenue of $529.40 million for the quarter, compared to analyst estimates of $497.39 million. MongoDB had a negative net margin of 10.46% and a negative return on equity of 12.22%. The business’s quarterly revenue was up 22.3% compared to the same quarter last year. During the same period in the previous year, the company earned $0.96 earnings per share. Analysts expect that MongoDB, Inc. will post -1.79 EPS for the current fiscal year.

Analyst Ratings Changes

Several equities research analysts have recently commented on MDB shares. The Goldman Sachs Group raised their target price on shares of MongoDB from $340.00 to $390.00 and gave the stock a “buy” rating in a research report on Tuesday, December 10th. Rosenblatt Securities initiated coverage on MongoDB in a research report on Tuesday, December 17th. They set a “buy” rating and a $350.00 price target on the stock. JMP Securities reiterated a “market outperform” rating and issued a $380.00 price objective on shares of MongoDB in a report on Wednesday, December 11th. Piper Sandler restated an “overweight” rating and set a $425.00 target price on shares of MongoDB in a report on Tuesday, December 10th. Finally, Loop Capital increased their price target on shares of MongoDB from $315.00 to $400.00 and gave the stock a “buy” rating in a research note on Monday, December 2nd. Two analysts have rated the stock with a sell rating, four have given a hold rating, twenty-three have assigned a buy rating and two have assigned a strong buy rating to the stock. According to MarketBeat, the stock presently has a consensus rating of “Moderate Buy” and an average price target of $361.00.

View Our Latest Stock Report on MongoDB

MongoDB Profile

(Free Report)

MongoDB, Inc, together with its subsidiaries, provides general purpose database platform worldwide. The company provides MongoDB Atlas, a hosted multi-cloud database-as-a-service solution; MongoDB Enterprise Advanced, a commercial database server for enterprise customers to run in the cloud, on-premises, or in a hybrid environment; and Community Server, a free-to-download version of its database, which includes the functionality that developers need to get started with MongoDB.

Featured Stories

Before you consider MongoDB, you’ll want to hear this.

MarketBeat keeps track of Wall Street’s top-rated and best performing research analysts and the stocks they recommend to their clients on a daily basis. MarketBeat has identified the five stocks that top analysts are quietly whispering to their clients to buy now before the broader market catches on… and MongoDB wasn’t on the list.

While MongoDB currently has a “Moderate Buy” rating among analysts, top-rated analysts believe these five stocks are better buys.

View The Five Stocks Here

Discover the 10 Best High-Yield Dividend Stocks for 2025 and secure reliable income in uncertain markets. Download the report now to identify top dividend payers and avoid common yield traps.

Get This Free Report

Article originally posted on mongodb google news. Visit mongodb google news

Posted on mongodb google news. Visit mongodb google news

Nisa Investment Advisors LLC grew its stake in MongoDB, Inc. (NASDAQ:MDB – Free Report) by 428.0% in the fourth quarter, according to its most recent disclosure with the Securities and Exchange Commission (SEC). The institutional investor owned 5,755 shares of the company’s stock after purchasing an additional 4,665 shares during the period. Nisa Investment Advisors LLC’s holdings in MongoDB were worth $1,340,000 as of its most recent filing with the Securities and Exchange Commission (SEC).

A number of other large investors have also made changes to their positions in the stock. Hilltop National Bank grew its position in MongoDB by 47.2% in the fourth quarter. Hilltop National Bank now owns 131 shares of the company’s stock worth $30,000 after acquiring an additional 42 shares during the period. Quarry LP grew its position in MongoDB by 2,580.0% in the second quarter. Quarry LP now owns 134 shares of the company’s stock worth $33,000 after acquiring an additional 129 shares during the period. Brooklyn Investment Group purchased a new position in MongoDB in the third quarter worth approximately $36,000. GAMMA Investing LLC grew its position in MongoDB by 178.8% in the third quarter. GAMMA Investing LLC now owns 145 shares of the company’s stock worth $39,000 after acquiring an additional 93 shares during the period. Finally, Continuum Advisory LLC grew its position in MongoDB by 621.1% in the third quarter. Continuum Advisory LLC now owns 137 shares of the company’s stock worth $40,000 after acquiring an additional 118 shares during the period. 89.29% of the stock is currently owned by hedge funds and other institutional investors.

Insider Buying and Selling at MongoDB

In related news, Director Dwight A. Merriman sold 3,000 shares of MongoDB stock in a transaction on Monday, November 4th. The shares were sold at an average price of $269.57, for a total value of $808,710.00. Following the completion of the sale, the director now owns 1,127,006 shares of the company’s stock, valued at approximately $303,807,007.42. The trade was a 0.27 % decrease in their position. The transaction was disclosed in a document filed with the Securities & Exchange Commission, which is accessible through this link. Also, CAO Thomas Bull sold 1,000 shares of MongoDB stock in a transaction on Monday, December 9th. The shares were sold at an average price of $355.92, for a total transaction of $355,920.00. Following the completion of the sale, the chief accounting officer now directly owns 15,068 shares of the company’s stock, valued at approximately $5,363,002.56. The trade was a 6.22 % decrease in their position. The disclosure for this sale can be found here. Insiders sold 34,156 shares of company stock valued at $9,220,473 in the last quarter. Company insiders own 3.60% of the company’s stock.

MongoDB Stock Performance

MongoDB stock opened at $264.58 on Tuesday. The firm has a market cap of $19.70 billion, a price-to-earnings ratio of -96.56 and a beta of 1.25. MongoDB, Inc. has a 1 year low of $212.74 and a 1 year high of $509.62. The firm’s 50 day moving average price is $275.02 and its two-hundred day moving average price is $269.23.

MongoDB (NASDAQ:MDB – Get Free Report) last posted its quarterly earnings data on Monday, December 9th. The company reported $1.16 EPS for the quarter, topping analysts’ consensus estimates of $0.68 by $0.48. The firm had revenue of $529.40 million during the quarter, compared to analyst estimates of $497.39 million. MongoDB had a negative net margin of 10.46% and a negative return on equity of 12.22%. The company’s revenue was up 22.3% on a year-over-year basis. During the same quarter last year, the business posted $0.96 EPS. As a group, equities analysts predict that MongoDB, Inc. will post -1.79 EPS for the current fiscal year.

Wall Street Analyst Weigh In

Several research analysts recently weighed in on the company. Scotiabank lowered their price objective on MongoDB from $350.00 to $275.00 and set a “sector perform” rating for the company in a research report on Tuesday, January 21st. Cantor Fitzgerald began coverage on MongoDB in a research note on Friday, January 17th. They set an “overweight” rating and a $344.00 price target on the stock. Needham & Company LLC upped their price target on MongoDB from $335.00 to $415.00 and gave the stock a “buy” rating in a research note on Tuesday, December 10th. Robert W. Baird upped their price target on MongoDB from $380.00 to $390.00 and gave the stock an “outperform” rating in a research note on Tuesday, December 10th. Finally, Piper Sandler restated an “overweight” rating and set a $425.00 price target on shares of MongoDB in a research note on Tuesday, December 10th. Two investment analysts have rated the stock with a sell rating, four have issued a hold rating, twenty-three have given a buy rating and two have issued a strong buy rating to the company’s stock. According to MarketBeat.com, the company has a consensus rating of “Moderate Buy” and an average price target of $361.00.

Get Our Latest Stock Analysis on MongoDB

MongoDB Company Profile

(Free Report)

MongoDB, Inc, together with its subsidiaries, provides general purpose database platform worldwide. The company provides MongoDB Atlas, a hosted multi-cloud database-as-a-service solution; MongoDB Enterprise Advanced, a commercial database server for enterprise customers to run in the cloud, on-premises, or in a hybrid environment; and Community Server, a free-to-download version of its database, which includes the functionality that developers need to get started with MongoDB.

Further Reading

Want to see what other hedge funds are holding MDB? Visit HoldingsChannel.com to get the latest 13F filings and insider trades for MongoDB, Inc. (NASDAQ:MDB – Free Report).

Receive News & Ratings for MongoDB Daily – Enter your email address below to receive a concise daily summary of the latest news and analysts’ ratings for MongoDB and related companies with MarketBeat.com’s FREE daily email newsletter.

Article originally posted on mongodb google news. Visit mongodb google news

Posted on mongodb google news. Visit mongodb google news

Pathfinder Acquisition (NASDAQ:PFDR – Get Free Report) and MongoDB (NASDAQ:MDB – Get Free Report) are both unclassified companies, but which is the superior business? We will contrast the two businesses based on the strength of their dividends, institutional ownership, risk, earnings, profitability, analyst recommendations and valuation.

Profitability

This table compares Pathfinder Acquisition and MongoDB’s net margins, return on equity and return on assets.

Analyst Recommendations

This is a breakdown of recent ratings and target prices for Pathfinder Acquisition and MongoDB, as provided by MarketBeat.com.

MongoDB has a consensus target price of $361.00, indicating a potential upside of 36.44%. Given MongoDB’s stronger consensus rating and higher possible upside, analysts clearly believe MongoDB is more favorable than Pathfinder Acquisition.

Insider & Institutional Ownership

77.8% of Pathfinder Acquisition shares are owned by institutional investors. Comparatively, 89.3% of MongoDB shares are owned by institutional investors. 20.0% of Pathfinder Acquisition shares are owned by insiders. Comparatively, 3.6% of MongoDB shares are owned by insiders. Strong institutional ownership is an indication that hedge funds, large money managers and endowments believe a company will outperform the market over the long term.

Volatility & Risk

Pathfinder Acquisition has a beta of -0.02, meaning that its share price is 102% less volatile than the S&P 500. Comparatively, MongoDB has a beta of 1.25, meaning that its share price is 25% more volatile than the S&P 500.

Earnings & Valuation

This table compares Pathfinder Acquisition and MongoDB”s revenue, earnings per share and valuation.

Pathfinder Acquisition has higher earnings, but lower revenue than MongoDB.

Summary

MongoDB beats Pathfinder Acquisition on 8 of the 12 factors compared between the two stocks.

About Pathfinder Acquisition

(Get Free Report)

Pathfinder Acquisition Corporation does not have significant operations. It intends to effect a merger, share exchange, asset acquisition, share purchase, reorganization, or similar business combination with one or more businesses in the technology or technology-enabled sectors. The company was incorporated in 2020 and is based in Palo Alto, California.

About MongoDB

(Get Free Report)

MongoDB, Inc., together with its subsidiaries, provides general purpose database platform worldwide. The company provides MongoDB Atlas, a hosted multi-cloud database-as-a-service solution; MongoDB Enterprise Advanced, a commercial database server for enterprise customers to run in the cloud, on-premises, or in a hybrid environment; and Community Server, a free-to-download version of its database, which includes the functionality that developers need to get started with MongoDB. It offers professional services comprising consulting and training. The company was formerly known as 10gen, Inc. and changed its name to MongoDB, Inc. in August 2013. MongoDB, Inc. was incorporated in 2007 and is headquartered in New York, New York.

Receive News & Ratings for Pathfinder Acquisition Daily – Enter your email address below to receive a concise daily summary of the latest news and analysts’ ratings for Pathfinder Acquisition and related companies with MarketBeat.com’s FREE daily email newsletter.

Article originally posted on mongodb google news. Visit mongodb google news