Month: September 2024

Article originally posted on InfoQ. Visit InfoQ

Transcript

Ruecker: I talk about long running, not so much about exercise, actually. We want to start talking about food first, probably more enjoyable. If you want to order pizza, there are a couple of ways of ordering pizza. You probably have ordered a pizza in the past. If you live in a very small city like I do, if you order pizza, what you do is actually you call the pizza place. That’s a phone call. If I do a phone call, that’s synchronous blocking communication. Because I’m blocked, I pick up the phone, I have to wait for the other person to answer it. I’m blocked until I got my message and whatever, whatnot.

If then the person answers me, I get a direct feedback loop. Normally, that person either tells me they make my pizza or they don’t. They can reject it. I get a direct feedback. I’m also temporarily coupled to the availability of the other side. If the person is currently not available to pick up the phone, if they’re already talking on another line, they might not be able to take my call. Then it’s on me to fix that. I have to probably call them again in 5 minutes, or really stay on the line to do that. Synchronous blocking communication. What would be an alternative? I know you could probably use the app. Again, I can’t do that where I live. You could send an email. An email puts basically a queue in between. It’s asynchronous non-blocking communication, and there’s no temporal coupling.

I can send the email, even if the peer is not available, even if they take other orders. How does it make you feel if you send an email to your pizza place? Exactly that, because there is no feedback loop at all. Do they read my email? I pick up the phone to call them. It could be. It’s not a technical restriction that there is no feedback loop. They could simply answer the email saying, we got your order, and you get your pizza within whatever, 30 minutes. You can do a feedback loop again, asynchronously. It’s not really the focus of today. I have another talk also talking about that this is not the same. You can have those interaction patterns decoupled basically from the technology you’re using for doing that. Synchronous blocking communication, asynchronous non-blocking.

The most important thing is on the next slide. Even if I do that independent of email, or phone, it’s important to distinguish that the feedback loop is not the result. I’m still hungry. They told me they send a pizza, I’m probably even more hungry than before the result of the pizza. The task of pizza making is long running, so it probably goes into a queue for being baked. It goes into the oven. They hopefully take the right time to do that.

They can’t do that in a rush. Then the pizza is ready, and it needs to be delivered to me. It’s always long running, it takes time. It’s inherently there. That’s actually a pattern we see in a lot of interactions, not only for pizza, but for a lot of other things. We have a first step, that synchronous blocking, but we have an asynchronous result later on.

Could you do synchronous blocking behavior for the result, in that case? Probably not such a good idea. If you take the example not of pizza but of coffee. If you go to a small bakery and order coffee, what happens is that the person behind the counter takes your offer, takes your money, basically turns around, going for the coffee machine, presses a button, waits for the coffee to come out of that. Going back to you, give you the cup. It’s synchronous blocking. They can’t do anything else. I can’t do anything else.

We’re waiting for the coffee to get ready. If you have a queue behind you, and if you’re in a good mood to make friends, you probably order 10 coffees. It takes a while. It’s not a good idea. It’s not a good user experience here and it doesn’t scale very well. The coffee making is relatively quick compared to the pizza making and other things. It doesn’t have to be that way. There’s a great article from Gregor Hohpe. He called it, “Starbucks Doesn’t Use Two-Phase Commit.” He talked about scalable coffee making at Starbucks, where you also separate the two things. The first step is the synchronous blocking thing. I go to the counter, order, pay. Then they basically ask for my names or correlation identifier. Then they put me in a queue, saying, to the baristas, make that coffee for Bernd. Then these baristas are scaled independently.

There might be more than one, for example, doing the coffee, and then I get the coffee later on. That scales much better. That’s another thing you can recognize here, it also makes it easier to change the experience of the whole process. A lot of the fast-food chains have started to replace, not fully replaced, but replace some of the counters or the humans behind the counter with simply ordering by the app. Because that’s very easy for the first step, but not so easy for the coffee making. There’s robotics also for that. There are videos on the internet, how you can do that, but it’s not on a big scale. Normally, the baristas are still there, the coffee making itself. We want to distribute those two steps.

With that in mind, if I come back to long running, when I say long running, I don’t refer to any AI algorithm that runs for ages until I get a result. No, I’m basically simply referring to waiting. Long running for me is waiting because I have to wait for certain things, that could be human work, the human in the loop, like we just heard, because somebody has to prove something. Somebody has to decide something that are typically things, or somebody has to do something. Waiting for a response, I sent whatever inquiry to the customer, and they have to give me certain data.

They have to make their decision. They have to sign the document, whatever it is, so I have to wait for that. Both of those things are not within seconds, they can be within hours, days, or even weeks, sometimes even longer. Or I simply want to let some time pass. The pizza baking is one example, but I had a lot of other examples in the past. One of my favorites was a startup. They did a manufactured service, which was completely automated, but they wanted to make the impression to the customer that it’s like a human does it. They waited for a random time, between 10 and 50 minutes, for example, to process a response. There are also more serious examples.

Why Is Waiting a Pain?

Why is waiting a pain? It basically boils down to because we have to remember that we are waiting. It’s important to not forget about waiting. That involves persistent state. Because if I have to wait not only for seconds, but minutes, hours, days, or weeks, or a month, I have to persist it somewhere to still remember it when somebody comes back. Persistent state. Is that a problem? We have databases? We do. There are a lot of subsequent requirements, if you look at that.

For example, you have to have an understanding what you’re waiting for. You probably have to escalate if you’re waiting for too long. You have versioning problems, like if I have a process that runs for a month, and I start at like every day a couple of times, I always have processes in flux. If I want to change the process, I have to think about already running ones, and probably do something different for them than for newer ones, for example. I have to run that at scale. I want to see where I’m at, and a lot of those things.

The big question is, how do I do that? How do I solve those technical challenges without adding accidental complexity? That’s what I’m seeing, actually, quite often. I wrote a blog post, I think, more than 10 years ago, where I said, I don’t want to see any more homegrown workflow engines. Because people stumble into that, like we simply have to write a status flag in the database. Then we wait, that’s fine. Then they start, “We have to remember that we have to have a scheduler. We have to have an escalation. People want to see that.” They start adding stuff. That’s not a good idea to do.

Background

I’m working on workflow engines, process engines, orchestration engines, however you want to call them, for almost all my life, at least my professional life. I co-founded Camunda, a process orchestration company, and wrote a lot of things in the past about it. I’ve worked on a couple of different open source workflow engines as well in the past.

Workflow Engine (Customer Onboarding)

One of the components that can solve these long running issues is a workflow engine. We’re currently more going towards naming it an orchestration engine, some call it a process engine. It’s all fine. The idea is that you define workflows, which you can run instances off, and then you have all these requirements being settled. I wanted to give you a 2-minutes demo, not because I want to show the tool, that’s a nice side effect. There are other tools doing the same thing. I want to get everybody to the same page of, what is that? What’s a workflow engine? If you want to play around with that yourself, there’s a link.

It’s all on GitHub, so you can just run it yourself. What I use as an example is an onboarding process. We see that in basically every company to some extent. You want to open up a new bank account, you go through an onboarding process, as a bank. You want to have a new mobile phone contract, you go through onboarding. If you want to have new insurance contract, onboarding. It’s always the same. This is how it could look like. What I’m using here, it’s called BPMN, it’s an ISO standard, how to define those processes.

You do that graphically. In the background, it’s simply an XML file basically describing that. It’s standardized, ISO standard. That’s not a proprietary thing here. Then you can do things like, I score the customer, then I approve the order. That’s a manual thing. I always like adding things live with the risk of breaking down. We could say, that takes too long. We want to basically escalate that. Let’s just say, escalate. Yes, we keep it like that. We have to say what too long is. That’s a duration with a period, time, 10 seconds should be enough for a person to review it. I just save that.

What I have in the background is a Java application, in this case. It doesn’t have to be Java, but I’m a Java person. It’s a Java Spring Boot application basically that connects to the workflow engine, in this case also deploys the process. Then also provides a small web UI. I can open a new bank account. I don’t even have to type in data because it does know everything. I submit the application. It triggers a REST call basically. The REST call goes into the Spring Boot application. That kicks off a process instance within the workflow engine. I’m using our SaaS service, so you have tools like Operate, where it can look into what’s going on.

There it can see that I have processes running. You see the versioning. I have a new version. I have that instance running. If I kick off another one, I get a second one in a second. I’m currently waiting for approval. I also already have escalated it, at the same time. Then you have tasks list, because I’m now waiting for a human, for example. I have UI stuff. I could also do that via chatbot or teams’ integration, for example. Yes, to automatic processing, please. Complete the task. Then this moves on. I’m seeing that here as well. I’m seeing that this moves on, and also sends an email. I have that one.

Process instance finish, for example. It runs through a couple of steps. Those couple of steps then basically connect to either the last two things I want to show, for example, create customer in CRM system, is, in this case, tied to a bit of Java code where it can do whatever you want to. That’s custom glue code, you simply can program it. Or if you want to send a welcome email, you already see that. That’s a pre-built connector. For example, for SendGrid, I can simply configure. That means in the background, also, my email was sent, which I can also show you hopefully here. Proof done, “Hello, QCon,” in email. We’re good.

That’s a workflow engine running in the background. We are having a workflow model. We have instances running through. We have code attached, or UIs attached to either connect to systems or to the human. Technically, I was using Camunda as a SaaS service here, and I had a Spring Boot application. Sometimes I’m being asked, ok, workflow, isn’t that for these like, I do 10 approvals a day things? No. We’re having customers running that at a huge scale. There’s a link for a blog post where we go into the thousands of process instances per second.

We run that in geographically distributed data centers in the U.S. and UK, for example, and this adds latency, but it doesn’t bring throughput down, for example. We are also working to reduce the latency of certain steps. What I’m trying to say is that that’s not only for I run five workflows a day, you can run that at a huge scale for core things.

When Do Services Need to Wait? (Technical Reasons)

So far, I looked at some business reasons why we want to wait. There are also a lot of technical reasons why you want to wait for things, why things get long running. That could be, first of all, asynchronous communication. If you send a message, you might not know when you get a message back. It might be within seconds in the happy case or milliseconds. What if not, then you have to do something. If you have a failure scenario, you don’t get a message back, you want to probably just stop where you are, and then wait for it to happen.

Then probably you can also notify an operator to resolve that. Or the peer service is not available, so especially if you go into microservices, or generally distributed systems, the peer might not be available, so you probably have to do something about it. You have to wait for that peer to become available. That’s a problem you should solve. Because otherwise, yes, you get to that. You get chain reactions, basically.

The example I always like to use is this one. If you use an airplane, you get an email invitation to check in a day before, 24 hours before that normally. Then you click a link, and you should check in. I did that for a flight actually to London. I think that was pre-pandemic, 2019, or something like that. I flew to London with Eurowings. I wanted to check in, and what it said to me was, “There was an error while sending you your boarding pass.” I couldn’t check in. That’s it. What would you do? Try it again. Yes, of course. I try it again. That’s what I did. Didn’t work. I tried it again 5 minutes later, didn’t work.

What was the next thing I did? I made a calendar entry in my Outlook, to remind me of trying it again in a couple of hours. Because there was still time. It wasn’t the next day. I just wanted to make sure not to forget to check in. That’s what I call a stateful retry. I want to retry but in a long running form, like 4 hours from now because it actually doesn’t work. It doesn’t matter because I don’t need it yet now.

The situation I envision is that, in the background, they had their web interface, they probably had a check-in microservice. They probably had some components downstream required for that to work, for example, the barcode generation, or document output management, or whatever. One of those components did fail. The barcode generation, for example, didn’t work, so they couldn’t check me in. The thing is that the more we distribute our systems into a lot of smaller services, the more we have to accept that certain parts are always broken, or that network to certain parts are always broken.

That’s the whole resiliency thing we’re discussing about. The only thing that we have to make sure, which is really important, that it doesn’t bring down our whole system. In other words, just that the 3D barcode generation, which is probably needed for my PDF boarding pass, I need to print out later, is not working, shouldn’t prevent my check-in. That’s a bad design. That’s not resilient. Because then you get a chain reaction here. The barcode generation is not working, probably not a big deal. It gets to a big deal because nobody can check in anymore. They make it my problem.

They transport the error all the way up to me, for me to resolve because I’m the last one in the chain. Everybody throws the hot potato ones further, I’m the last part in the chain as a user. That makes me responsible for the Outlook entry. The funny part about that story was really, the onwards flight, same trip from London, easyJet, “We are sorry.” Same problem, I couldn’t check in, but they give you the work instruction. They are better with that. “We’re having some technical difficulties, log on again, retry. If that doesn’t work, please try again in 5 minutes.” I like that, increase the interval. That makes a lot of sense. You could automate that probably.

The next thing, and I love that, “We do actively monitor our site. We’ll be working to resolve the issue. There’s no need to call.” It’s your problem, leave us alone. In this case, it’s very obvious because it’s facing the user. It’s an attitude I’m seeing in a lot of organizations, even internally to other services, their problem, which is, throw an error, we’re good.

The much better situation would be the check-in should probably handle that. They should check me in. They could say, you’re checked in, but we can’t issue the boarding pass right now, we’re sorry, but we send it on time. Or, you get it in the app anyway. I don’t want to print it out, don’t need a PDF. They could handle it in a much more local scope. That’s a better design. It gives you a better designed system. The responsibilities are much cleaner defined, but the thing is now you need long running capabilities within the check-in service. If you don’t have them, that’s why a lot of teams are rethrowing the error.

Otherwise, we have to keep state, we want to be stateless. That’s the other part, which I was discussing with a lot of customers over the last 5 years. The customer wants a synchronous response. They want to see a response in the website where it says you’re checked in, here’s your boarding pass, here’s the PDF, and whatever. We need that. People are used to that experience. I wouldn’t say so. If my decision as the customer is either I get a synchronous error message and have to retry myself or I get some result later on. I know what I’d pick. It’s still a better customer experience. It needs a little bit of rethink, but I find it important.

Let’s extend the example a little bit and add a bit more flavor on a couple of those things. Let’s say you’re still doing flight bookings, but maybe you also want to collect payments for it. That would make sense as a company. The payments might need credit card handling, so they want to take money from the credit card. Let’s look at that. The same thing could happen. You want to charge the credit card. The credit card service at least internally but maybe also on that level will use some SaaS whatever service in the internet. You will probably not do credit card handling yourself unless you’re very big, but normally, you use some Stripe-like mechanism to do that.

You will call an external API, REST, typically, to make the credit card charge. Then you have that availability thing. That service might not be available when you want to charge a credit card. You probably also then have the same thing, you want to charge it and want to probably wait for availability of the credit card service, because you don’t want to tell your customers, we can’t book your flight because our credit card service is currently not available. You probably want to find other ways. That’s not where it stops. It normally then goes beyond that, which is very interesting if you look into all the corner cases.

Let’s say you give up after some time, which makes sense. You don’t want to try to book the flight for tomorrow, for the next 48 hours. It does make sense. You give up at some point in time. You probably say the payment failed, and we probably can’t book your flight, or whatever it is that you do. There’s one interesting thing about distributed systems, if you do a remote call, and you get an exception out of that, you can’t differentiate those three situations. Probably the network was broken, you have not reached the service provider.

Maybe the network was great but the service provider, the thread exploded while you were doing it. It didn’t process it. Did it commit its transaction or not? You have no idea. Or everything worked fine and the response got lost in the network. You can’t know what just happened. That makes it hard in that scenario, because even if you get an exception, you might have charged the credit card, actually.

It might be a corner case, but it’s possible. Depending on what you do, you might not want to ignore it. Maybe you can. If that’s a conscious decision, that’s fine. Maybe you can’t, then you have to do something about that. You also can do that in a workflow way. You could also run monthly conciliation jobs, probably also a good solution. It always depends. If you want to do it in a workflow way, you might even have to check if it was charged and refunded, so it gets more complicated. That’s what I’m trying to say.

In order to do these kinds of things, again, embrace asynchronous thinking. Make an API that’s ready to probably not deliver a synchronous result. That’s saying, we try our best, maybe you get something in a good case, but maybe you don’t. Then, that’s HTTP codes. I like to think in HTTP codes, like 202 means we got your request, that’s the feedback loop, we got it, but the result will be later. Now you can make it long running, and that extends your options, what it can do. Speaking of that, one of the core thoughts there is also, if you make APIs like that, make it asynchronous, make it be able to handle long running.

Within your services, you’re more free to implement requirements the way you want. Let’s say you extend the whole payment thing, not only to credit cards, but probably to also have customer credits on their account. Some companies allow that. If you return goods, for example, you get credits on your account, which you can use for other things, or PayPal has that. If you get money sent via PayPal, it’s on your PayPal account, you can use that first before they deduct it from your bank account, for example. Then you could add that where you say, I first deduct credit and then I charge the credit card, and you get more options of doing that also long running. That poses interesting new problems around really consistency. For example, now we have a situation where we talk to different services, probably for credit handling, or for credit card charging.

All of them have their transactions internally, probably, but you don’t have a technical transaction spawning all of those steps. Where you say, if the credit card charging fails, I also didn’t deduct the customer credit, I just say payment failed. I need to think about these scenarios where a deducted customer credit card charge doesn’t work. I want to fail the payment. Then I have to basically rebook the customer credit. That’s, for example, also what you can do with these kinds of workflows. That’s called compensation. Where you say, I have compensating, like undo activities for activities if something failed. The only thing I’m trying to say here is, it gets more complex very quickly if you think about all the implications of distributed systems here.

Long Running Capabilities (Example)

Going back to the long running capabilities. My view on that is, you need long running capabilities to design good services, good service boundaries. That’s a technical capability you should have in your architecture. I made another example to probably also make it easier to grasp. Let’s say the booking service basically tells the payment service via method via REST call, saying, retrieve payment. I won’t discuss orchestration versus choreography, because that could be something you’re also interested in. Why doesn’t it just emit an event? Booking says, payment, retrieve payment for that flight, for example. Payment chose the credit card. Now let’s say the credit card is rejected. Service is available, but the credit card is rejected. That very often happens in scenarios where I store the credit card in my profile, it’s expired, and then it gets rejected.

Now the next question is what to do with that. Typically, a requirement could be, if the credit card is rejected, the customer can provide new details. They hopefully still book their flight. We want them to do that. They need to provide new credit card details. You can also think about other scenarios. Somewhere I have the example of GitHub subscriptions, because there, it’s a fully automated process that renews my subscription, uses my credit card. It doesn’t work, they send you an email, “Update your credit card.”

The question is where to implement that requirement. One of the typical reactions I’m seeing in a lot of scenarios is that, as a payment, we’re stateless again. We want to be simple. We can’t do that, because then we have to send the customer an email. We have to wait for the customer to update the credit card details. We have to control that whole process. It gets long running.

They understand it adds complexity, they don’t want to do that. Just hot potato forward to the booking, because the booking is long running anyway, for a couple of reasons. They also have that. They can handle that requirement better, so let’s just throw it over the fence over there. I’m seeing that very often, actually. If you make the same example with order fulfillment, or other things where it’s very clear that that component, like booking, order fulfillment has a workflow mechanism, then this happens. The problem is now you’re leaking a lot of domain concepts, out of payment into booking, because booking shouldn’t know about credit card at all. They want to get money. They want to have the payment. They shouldn’t care about the way of payment. Because that probably also changes over time, and you don’t always want to adjust the booking, just because there’s a new payment method.

It’s a better design to separate that. That’s questionable. If you go into DDD, for example, it also leaks domain language, like, credit card rejected. I don’t care, I wanted to retrieve payment. Either you got my payment or you didn’t. That’s the two results I care about as booking. You want to really put it into the payment service. That makes more sense. Then, get a proper response, like the final thing. In order to do that, you have to deal with long running requirements within payment. That’s the thing. You should make that easy for the teams to do that.

I added potentially on the slide. In such a situation, payment in 99% of the cases might be really super-fast, and could be synchronous. Then there are all these edge cases where it might not be and it’s good to be able to handle that. Then you can still design, for example, an API versus say, in the happy case I get a synchronous result. It’s not an exceptional case. It’s just one case. The other case could be, I don’t get that. I get an HTTP 202, and an asynchronous response. Make your architecture ready for that. Then you could use probably also workflows for implementing that.

Just because there’s a workflow orchestration doesn’t mean it’s a monolithic thing. I would even say, the other way round, if you have long running capabilities available in the different services you might want to do, it gets easier to put the right parts of the process in the right microservices, for example, and it’s not monolithic at all. It gets monolithic if, for example, payment doesn’t have long running capabilities, and you move that logic into the booking service, just because that booking service has the possibility to do long running. I find that important. It’s not that having orchestration, or long running capabilities adds the monolithic thing. It’s the other way round, because not all the services have them at their disposal. Normally, what they do is they push all the long running stuff towards that one service that does, and then this gets monolithic. From my perspective, having long running at the disposal for everybody avoids these, what Sam Newman once called, god services.

Successful Process Orchestration (Centers of Excellence)

Long running capabilities are essential. It makes it easier to distribute all the responsibilities correctly. Also, it makes it easier to embrace asynchronous, non-blocking stuff. You need a process orchestration capability. That’s what I’m convinced of. Otherwise, probably, I wouldn’t do it for all my life. That’s also easy to get as a team. Nowadays, that means as a service, either internally or probably also externally, to create a good architecture. I’m really convinced by that. Looking into that, how can I do that? How can I get that into the organization better? What we’re seeing very successful, all organizations I talk with that use process orchestration to a bigger extent, very successfully, they have some Center of Excellence, organizationally. They not always call it Center of Excellence. Sometimes it’s a digital enabler, or even process ninjas. It might be named very differently. That depends a little bit on company culture and things.

It’s a dedicated team within the organization that cares about long running, if you phrase it more technically, or process orchestration, process automation, these kinds of things. This is the link, https://camunda.com/process-orchestration/automation-center-of-excellence/, for a 40-page article where we collected a lot of the information about Center of Excellence: how to build them, what are best practices to design them, and so on. One of the core ideas there is, a Center of Excellence should focus on enablement, and probably providing a platform.

They should not create solutions. Because sometimes people ask me, but we did that BPM, where we had these central teams doing an ESB and very complicated technology and didn’t work. It didn’t work, because at that time, a lot of those central teams had to be involved in the solution creation. They had to build workflows. It was not possible without them. That’s a very different model nowadays. You normally have a central team that focuses on enabling others that then build the things. Enabling means probably consulting, helping them, building a community, but also providing technology where they can do that.

What I’m discussing very often within the last two or three years is, but we stopped doing central things. We want to be more autonomous. We have the teams, they should be free in their decisions. We don’t want to put too much guardrails on them. Isn’t a central CoE the path? Why do you do that? I discuss that with a lot of organizations actually. I was so happy about the Team Topologies book. That’s definitely a recommendation to look into. The core ideas are very crisp, actually. In order to be very efficient in your development, you have different types of teams. That’s the stream-aligned team that does business logic, that implements business logic, basically. They provide value. That’s very often also value streams and whatever. You want to make them as productive as possible to remove as much friction as possible so they can really provide value, provide features. In order to do that you have other types of teams.

The two important ones are the enabling team, a consulting function, like hopping through the different projects, and the platform team, providing all the technology they need, so they don’t have to figure out everything themselves. The complicated subsystem team is something we don’t focus on too much. It can be some fraud check AI thing somebody does, and then provides an internal as a service thing. You can map that very well. Our customers do that actually very well to having a Center of Excellence around process orchestration, automation, for example.

Where you say they provide the technology. In our case, that’s very often Camunda, but it could be something else. Very often, they also own adjacent tools like RPA tools, robotic process automation, and others. They provide the technology and also the enablement: project templates, and whatnot. That’s very efficient, actually. It frees the teams of figuring out that themselves, because that’s so hard. As a team, if you don’t have an idea how you build your stack, you can go into evaluation mode for two or three months, and you don’t deliver any business value there. That’s actually not new. There are a couple of recommendable blog posts out there also talking about that. One is the thing from Spotify. Spotify published about Golden Path, 2020, where they basically said, we want to have certain defined ways of building a certain solution type. If we build a customer facing web app, this is normally how we do it.

If we build a long running workflow, this is how we do it. They have these kinds of solution templates. The name is good, actually, they name it Golden Path, because it’s golden. They make it so easy to be used. They don’t force teams to use it. That’s the autonomy thing. They don’t force it upon people. They make it desirable to be used. They make it easy. It’s not your fault if it’s not working. Then it’s golden. I like the blog post, actually, I love that quote, because they found that rumor-driven development simply wasn’t scalable. “I heard they do it like that, probably you should do that as well.” Then you end up with quite a slew of technology that doesn’t work. I find this really important that you want to consolidate on certain technologies. You want to make it easy to use them across the whole organization. That makes you efficient. Don’t force it upon the people.

They also have a tool. That’s a big company, they do open source on the side. They made backstage.io. I have no idea if the tool is good. I have not used it at all. I love the starting page of their website, The Speed Paradox, where they said, “At Spotify, we’ve always believed in the speed and ingenuity that comes from having autonomous development teams, but as we learn firsthand, the faster you grow, the more fragmented and complex your software ecosystems become, and then everything slows down again.” The Standards Paradox, “By centralizing services and standardizing your tooling, Backstage streamlines your development environment.

Instead of restricting autonomy, standardization frees your engineers from infrastructure complexity.” I think that’s an important thought. They’re not alone. If you search the internet, you find a couple of other places, for example, Twilio, but also others. Same thing. We’re offering paved path, mature services, pull off the shelf, get up and running super quickly. What you do is create the incentive structure for teams to take the paved path, because it’s a lot easier. If they really have to go a different route, you make it possible. It’s not restricting autonomy, simply helping them. That’s important. I think it’s also important to discuss that internally.

Graphical Models

Last thing, graphical models. That’s the other thing I discuss regularly. Center of Excellence, yes, probably makes sense. Process orchestration, yes, I understand why we have to do that. Graphical models? We’re developers. We write code. Thing is, BPMN, that’s what I showed. It’s an ISO standard. It’s worldwide adopted. It can do pretty complex things. I just scratched the surface. It can express a lot of complex things in relatively simple model, so it’s powerful. It’s living documentation. It’s not a picture that’s requirement, but it’s running code. That’s the model you put into production. It’s running code. That’s so powerful.

This is an example where it’s used for test cases. That’s what the test case tests, for example. You can leverage that as a visual. Or it can use it in operations like, where is it stuck, or what is the typical way it’s going through, or where are typical bottlenecks, and so on? You can use that to discuss that also with different kinds of stakeholders, not only developers, but all of them.

If you discuss a complex algorithm, like a longer process or workflow, you normally go to the whiteboard and sketch it because we’re visual as a human. Just because I’m a programmer doesn’t make me less visual. I want to see it. Very powerful. It’s even more important, because I think a lot of the decisions about long running behavior needs to be elevated to the business level.

They need to understand, why we want to get asynchronous. Why this might take longer. Why we need to change, also customer experience to leverage the architecture. The only way of doing that is to really make it transparent, to make it visual. I think it was a former marketing colleague that worked with me, phrased it like that. What you’re trying to say is that in order to leverage your hipster architecture, you need to redesign the customer journey. That’s exactly that. That’s important to keep in mind.

Example (Customer Experience)

I want to quickly close that with another flight story. The first thing it’s happening, so you get everything asynchronous. They did change the customer experience a lot. Now I’m working on train companies. That’s the same thing. Mobile. You get automatically checked in for flights. You don’t even have to do that. Why should I do that? My flight to London was delayed by an hour. Ok, that’s delayed. That was canceled. That’s not so nice. Then I got a relatively quickly and automated email, that’s the only one in German, which I don’t get why. Did I get that one in German? It wasn’t German.

I got the link to book my hotel at Frankfurt airport. Why? I don’t want to get a hotel in Frankfurt, I want to get to London. Everything automated, everything pushed. Nice. Then I got, via the app not via email, a link to a chatbot where I should chat about my flight. It says, we rebooked you for tomorrow morning. It didn’t do that completely because it’s not Lufthansa, so you have to see a human colleague. I don’t want to get to London tomorrow, I want to get there today. I basically visit a counter.

The end of the story is they could rebook me to a very late flight to London, Heathrow, which was very late. I hated that. What I still like, everything was asynchronously. I got notification of everything in the app via email. I think there’s some good things on the horizon there. The customer experience for airlines at least changed quite a bit over the last 5 years. Funny enough, last anecdote, I read an article about the bad NPS score of Lufthansa, and I probably understand why.

Recap

You need long running capabilities for a lot of reasons. Process orchestration platforms, workflow engines, great technology. You should definitely use that for those, because it allows you to design better service boundaries, implement quicker, less accidental complexity. You can embrace asynchronicity better. Provide a better customer experience. We haven’t even talked about the other stuff like increased operational efficiency, automation, reduce risk, be more compliant, document the process, and so on. In order to do that successfully across the organization, you should organize some central enablement. I’m a big advocate for that, to really adopt that at scale.

See more presentations with transcripts

Posted on mongodb google news. Visit mongodb google news

DekaBank Deutsche Girozentrale lessened its holdings in shares of MongoDB, Inc. (NASDAQ:MDB – Free Report) by 4.5% during the 2nd quarter, according to its most recent filing with the Securities and Exchange Commission. The firm owned 43,141 shares of the company’s stock after selling 2,055 shares during the quarter. DekaBank Deutsche Girozentrale owned 0.06% of MongoDB worth $10,688,000 as of its most recent SEC filing.

Other hedge funds have also added to or reduced their stakes in the company. Transcendent Capital Group LLC acquired a new stake in MongoDB during the 4th quarter worth $25,000. MFA Wealth Advisors LLC bought a new position in MongoDB during the 2nd quarter worth about $25,000. YHB Investment Advisors Inc. bought a new position in MongoDB during the 1st quarter worth about $41,000. Sunbelt Securities Inc. increased its holdings in MongoDB by 155.1% during the 1st quarter. Sunbelt Securities Inc. now owns 125 shares of the company’s stock worth $45,000 after purchasing an additional 76 shares in the last quarter. Finally, J.Safra Asset Management Corp increased its holdings in MongoDB by 682.4% during the 2nd quarter. J.Safra Asset Management Corp now owns 133 shares of the company’s stock worth $33,000 after purchasing an additional 116 shares in the last quarter. Institutional investors and hedge funds own 89.29% of the company’s stock.

Wall Street Analyst Weigh In

A number of equities analysts have issued reports on the company. Oppenheimer increased their target price on MongoDB from $300.00 to $350.00 and gave the stock an “outperform” rating in a report on Friday, August 30th. Tigress Financial lowered their target price on MongoDB from $500.00 to $400.00 and set a “buy” rating for the company in a report on Thursday, July 11th. DA Davidson increased their target price on MongoDB from $265.00 to $330.00 and gave the stock a “buy” rating in a report on Friday, August 30th. Morgan Stanley increased their target price on MongoDB from $320.00 to $340.00 and gave the stock an “overweight” rating in a report on Friday, August 30th. Finally, Barclays decreased their price objective on MongoDB from $458.00 to $290.00 and set an “overweight” rating for the company in a report on Friday, May 31st. One equities research analyst has rated the stock with a sell rating, five have given a hold rating and twenty have issued a buy rating to the stock. Based on data from MarketBeat, the company presently has an average rating of “Moderate Buy” and an average price target of $337.56.

View Our Latest Stock Analysis on MongoDB

MongoDB Trading Down 0.0 %

Shares of MDB stock opened at $290.05 on Tuesday. The firm has a 50 day moving average price of $256.45 and a two-hundred day moving average price of $301.10. The company has a quick ratio of 5.03, a current ratio of 5.03 and a debt-to-equity ratio of 0.84. The company has a market capitalization of $21.28 billion, a PE ratio of -103.22 and a beta of 1.15. MongoDB, Inc. has a 12-month low of $212.74 and a 12-month high of $509.62.

MongoDB (NASDAQ:MDB – Get Free Report) last issued its quarterly earnings data on Thursday, August 29th. The company reported $0.70 earnings per share (EPS) for the quarter, topping the consensus estimate of $0.49 by $0.21. The firm had revenue of $478.11 million during the quarter, compared to the consensus estimate of $465.03 million. MongoDB had a negative net margin of 12.08% and a negative return on equity of 15.06%. The business’s revenue for the quarter was up 12.8% compared to the same quarter last year. During the same period last year, the business posted ($0.63) earnings per share. As a group, analysts predict that MongoDB, Inc. will post -2.46 earnings per share for the current year.

Insider Activity

In other news, CAO Thomas Bull sold 138 shares of MongoDB stock in a transaction that occurred on Tuesday, July 2nd. The shares were sold at an average price of $265.29, for a total value of $36,610.02. Following the completion of the sale, the chief accounting officer now directly owns 17,222 shares in the company, valued at $4,568,824.38. The transaction was disclosed in a document filed with the SEC, which can be accessed through this link. In related news, Director John Dennis Mcmahon sold 10,000 shares of MongoDB stock in a transaction that occurred on Monday, June 24th. The shares were sold at an average price of $228.00, for a total value of $2,280,000.00. Following the transaction, the director now directly owns 20,020 shares of the company’s stock, valued at $4,564,560. The sale was disclosed in a legal filing with the Securities & Exchange Commission, which is accessible through this hyperlink. Also, CAO Thomas Bull sold 138 shares of MongoDB stock in a transaction that occurred on Tuesday, July 2nd. The shares were sold at an average price of $265.29, for a total transaction of $36,610.02. Following the completion of the transaction, the chief accounting officer now directly owns 17,222 shares in the company, valued at $4,568,824.38. The disclosure for this sale can be found here. Over the last ninety days, insiders sold 32,005 shares of company stock worth $8,082,746. Corporate insiders own 3.60% of the company’s stock.

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.

See Also

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

Shares of MongoDB, Inc. (NASDAQ:MDB – Get Free Report) have received a consensus rating of “Moderate Buy” from the twenty-six brokerages that are presently covering the company, Marketbeat.com reports. One research analyst has rated the stock with a sell rating, five have given a hold rating and twenty have given a buy rating to the company. The average 12 month target price among analysts that have updated their coverage on the stock in the last year is $337.56.

MDB has been the subject of several analyst reports. Needham & Company LLC upped their price target on shares of MongoDB from $290.00 to $335.00 and gave the company a “buy” rating in a research report on Friday, August 30th. Canaccord Genuity Group reduced their price target on MongoDB from $435.00 to $325.00 and set a “buy” rating on the stock in a research report on Friday, May 31st. Piper Sandler boosted their price objective on MongoDB from $300.00 to $335.00 and gave the company an “overweight” rating in a research report on Friday, August 30th. UBS Group raised their target price on shares of MongoDB from $250.00 to $275.00 and gave the stock a “neutral” rating in a report on Friday, August 30th. Finally, Barclays lowered their price target on shares of MongoDB from $458.00 to $290.00 and set an “overweight” rating for the company in a report on Friday, May 31st.

View Our Latest Research Report on MongoDB

MongoDB Price Performance

Shares of MongoDB stock traded down $1.34 during trading on Tuesday, hitting $288.71. 254,481 shares of the stock traded hands, compared to its average volume of 1,490,700. The stock has a market cap of $21.18 billion, a price-to-earnings ratio of -103.22 and a beta of 1.15. The company has a quick ratio of 5.03, a current ratio of 5.03 and a debt-to-equity ratio of 0.84. MongoDB has a 52 week low of $212.74 and a 52 week high of $509.62. The firm’s fifty day moving average is $256.45 and its 200-day moving average is $301.10.

MongoDB (NASDAQ:MDB – Get Free Report) last issued its earnings results on Thursday, August 29th. The company reported $0.70 earnings per share (EPS) for the quarter, topping the consensus estimate of $0.49 by $0.21. The business had revenue of $478.11 million during the quarter, compared to analyst estimates of $465.03 million. MongoDB had a negative return on equity of 15.06% and a negative net margin of 12.08%. MongoDB’s revenue for the quarter was up 12.8% on a year-over-year basis. During the same quarter in the prior year, the firm earned ($0.63) earnings per share. Research analysts expect that MongoDB will post -2.46 EPS for the current fiscal year.

Insider Activity

In other MongoDB news, Director Dwight A. Merriman sold 3,000 shares of the business’s stock in a transaction on Tuesday, September 3rd. The stock was sold at an average price of $290.79, for a total value of $872,370.00. Following the sale, the director now directly owns 1,135,006 shares of the company’s stock, valued at $330,048,394.74. The transaction was disclosed in a filing with the Securities & Exchange Commission, which is available at this hyperlink. In other MongoDB news, Director Dwight A. Merriman sold 3,000 shares of MongoDB stock in a transaction dated Tuesday, September 3rd. The shares were sold at an average price of $290.79, for a total value of $872,370.00. Following the completion of the transaction, the director now directly owns 1,135,006 shares of the company’s stock, valued at $330,048,394.74. The sale was disclosed in a filing with the Securities & Exchange Commission, which can be accessed through this link. Also, CRO Cedric Pech sold 273 shares of the company’s stock in a transaction that occurred on Tuesday, July 2nd. The stock was sold at an average price of $265.29, for a total transaction of $72,424.17. Following the completion of the transaction, the executive now owns 35,719 shares in the company, valued at approximately $9,475,893.51. The disclosure for this sale can be found here. Over the last ninety days, insiders sold 32,005 shares of company stock worth $8,082,746. Insiders own 3.60% of the company’s stock.

Institutional Trading of MongoDB

A number of institutional investors and hedge funds have recently modified their holdings of MDB. Transcendent Capital Group LLC purchased a new position in MongoDB in the 4th quarter worth about $25,000. MFA Wealth Advisors LLC bought a new position in MongoDB during the second quarter valued at approximately $25,000. YHB Investment Advisors Inc. purchased a new stake in MongoDB in the first quarter worth approximately $41,000. Sunbelt Securities Inc. grew its position in MongoDB by 155.1% in the 1st quarter. Sunbelt Securities Inc. now owns 125 shares of the company’s stock worth $45,000 after purchasing an additional 76 shares during the period. Finally, J.Safra Asset Management Corp raised its stake in MongoDB by 682.4% during the 2nd quarter. J.Safra Asset Management Corp now owns 133 shares of the company’s stock valued at $33,000 after buying an additional 116 shares during the last quarter. Institutional investors own 89.29% of the company’s stock.

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.

See Also

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

Wondering when you’ll finally be able to invest in SpaceX, StarLink, or The Boring Company? Click the link below to learn when Elon Musk will let these companies finally IPO.

Get This Free Report

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

Article originally posted on InfoQ. Visit InfoQ

Researchers at Apple and the Swiss Federal Institute of Technology Lausanne (EPFL) have open-sourced 4M-21, a single any-to-any AI model that can handle 21 input and output modalities. 4M-21 performs well “out of the box” on several vision benchmarks and is available under the Apache 2.0 license.

4M-21 is a 3B-parameter Transformer-based encoder-decoder model. All 21 input modalities are mapped to discrete tokens using modality-specific tokenizers, and the model can generate any output modality given any input modality. The model was trained on around 500 million samples of multimodal data, including COYO and C4. Out of the box, 4M-21 can perform a wide range of tasks, including steerable image generation and image retrieval. On vision benchmarks including semantic segmentation and depth estimation, it outperformed comparable baseline models. According to Apple:

The resulting model demonstrates the possibility of training a single model on a large number of diverse modalities/tasks without any degradation in performance and significantly expands the out-of- the-box capabilities compared to existing models. Adding all these modalities enables new potential for multimodal interaction, such as retrieval from and across multiple modalities, or highly steerable generation of any of the training modalities, all by a single model.

4M-21 builds on Apple’s earlier model, Massively Multimodal Masked Modeling (4M), which handled only seven modalities. The new model triples the modalities, which include text and pixel data, as well as “multiple types of image, semantic and geometric metadata.” Each modality has a dedicated tokenizer; text modalities use a WordPiece tokenizer, while image modalities use variational auto-encoders (VAE). The model is trained using a single objective: “a per-token classification problem using the cross-entropy loss.”

By allowing inputs with multiple modalities and chaining operations, 4M-21 supports fine-grained image editing and generation. For example, providing a text caption input will prompt the model to generate the described image. Users can control details about the generated image by including geometric input such as bounding boxes, segmentation maps, or human poses along with the caption. The model can also perform image retrieval based on different inputs; for example, by finding images given a caption or a semantic segmentation map.

Research team member Amir Zamir posted about the work in a thread on X. One user asked Zamir why the model does not support audio modalities. Zamir replied that “It’s a matter of data,” and suggested their method should work with audio. He also wrote:

IMO, the multitask learning aspect of multimodal models has really taken a step forward. We can train a single model on many diverse tasks with ~SOTA accuracy. But a long way to go in terms of transfer/emergence.

Andrew Ng’s AI newsletter The Batch also covered 4M-21, saying:

The limits of this capability aren’t clear, but it opens the door to fine control over the model’s output. The authors explain how they extracted the various modalities; presumably users can do the same to prompt the model for the output they desire. For instance, a user could request an image by entering not only a prompt but also a color palette, edges, depth map extracted from another image, and receive output that integrates those elements.

The code and model weights for 4M-21 are available on GitHub.

Posted on mongodb google news. Visit mongodb google news

Acadian Asset Management LLC lifted its holdings in MongoDB, Inc. (NASDAQ:MDB – Free Report) by 1,677.3% in the 2nd quarter, according to its most recent filing with the SEC. The firm owned 3,679 shares of the company’s stock after purchasing an additional 3,472 shares during the period. Acadian Asset Management LLC’s holdings in MongoDB were worth $916,000 at the end of the most recent quarter.

Several other institutional investors also recently bought and sold shares of the business. Norges Bank bought a new stake in MongoDB during the 4th quarter valued at $326,237,000. Jennison Associates LLC grew its stake in MongoDB by 14.3% in the first quarter. Jennison Associates LLC now owns 4,408,424 shares of the company’s stock valued at $1,581,037,000 after purchasing an additional 551,567 shares during the last quarter. Swedbank AB raised its holdings in MongoDB by 156.3% in the second quarter. Swedbank AB now owns 656,993 shares of the company’s stock worth $164,222,000 after purchasing an additional 400,705 shares in the last quarter. Axiom Investors LLC DE purchased a new stake in shares of MongoDB during the fourth quarter valued at about $153,990,000. Finally, Clearbridge Investments LLC boosted its holdings in shares of MongoDB by 109.0% in the 1st quarter. Clearbridge Investments LLC now owns 445,084 shares of the company’s stock valued at $159,625,000 after buying an additional 232,101 shares in the last quarter. 89.29% of the stock is owned by hedge funds and other institutional investors.

Analysts Set New Price Targets

MDB has been the subject of several recent analyst reports. Loop Capital lowered their target price on shares of MongoDB from $415.00 to $315.00 and set a “buy” rating for the company in a research note on Friday, May 31st. JMP Securities reissued a “market outperform” rating and issued a $380.00 price objective on shares of MongoDB in a research report on Friday, August 30th. Citigroup upped their target price on MongoDB from $350.00 to $400.00 and gave the company a “buy” rating in a research report on Tuesday, September 3rd. Stifel Nicolaus raised their price target on MongoDB from $300.00 to $325.00 and gave the stock a “buy” rating in a report on Friday, August 30th. Finally, Monness Crespi & Hardt upgraded shares of MongoDB to a “hold” rating in a report on Tuesday, May 28th. One research analyst has rated the stock with a sell rating, five have issued a hold rating and twenty have assigned a buy rating to the stock. Based on data from MarketBeat, the stock has an average rating of “Moderate Buy” and a consensus target price of $337.56.

View Our Latest Stock Analysis on MDB

MongoDB Trading Down 0.0 %

MDB stock opened at $290.05 on Tuesday. MongoDB, Inc. has a 52-week low of $212.74 and a 52-week high of $509.62. The company has a quick ratio of 5.03, a current ratio of 5.03 and a debt-to-equity ratio of 0.84. The firm has a market cap of $21.28 billion, a P/E ratio of -103.22 and a beta of 1.15. The company’s 50-day simple moving average is $256.45 and its 200-day simple moving average is $301.10.

MongoDB (NASDAQ:MDB – Get Free Report) last posted its quarterly earnings data on Thursday, August 29th. The company reported $0.70 EPS for the quarter, beating analysts’ consensus estimates of $0.49 by $0.21. MongoDB had a negative return on equity of 15.06% and a negative net margin of 12.08%. The business had revenue of $478.11 million during the quarter, compared to analysts’ expectations of $465.03 million. During the same period in the previous year, the business earned ($0.63) earnings per share. The business’s revenue was up 12.8% compared to the same quarter last year. As a group, equities analysts forecast that MongoDB, Inc. will post -2.46 EPS for the current fiscal year.

Insider Buying and Selling at MongoDB

In other news, Director Dwight A. Merriman sold 1,000 shares of the business’s stock in a transaction dated Thursday, June 27th. The shares were sold at an average price of $245.00, for a total transaction of $245,000.00. Following the completion of the sale, the director now owns 1,146,003 shares of the company’s stock, valued at $280,770,735. The transaction was disclosed in a filing with the Securities & Exchange Commission, which can be accessed through the SEC website. In related news, Director Dwight A. Merriman sold 1,000 shares of the stock in a transaction on Thursday, June 27th. The stock was sold at an average price of $245.00, for a total value of $245,000.00. Following the completion of the transaction, the director now directly owns 1,146,003 shares of the company’s stock, valued at approximately $280,770,735. The transaction was disclosed in a filing with the SEC, which can be accessed through the SEC website. Also, Director John Dennis Mcmahon sold 10,000 shares of MongoDB stock in a transaction on Monday, June 24th. The stock was sold at an average price of $228.00, for a total transaction of $2,280,000.00. Following the sale, the director now directly owns 20,020 shares in the company, valued at approximately $4,564,560. The disclosure for this sale can be found here. Insiders have sold a total of 32,005 shares of company stock valued at $8,082,746 over the last ninety days. Corporate insiders own 3.60% of the company’s stock.

About MongoDB

(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

William Blair Investment Management LLC raised its holdings in shares of MongoDB, Inc. (NASDAQ:MDB – Free Report) by 268.5% during the 2nd quarter, according to the company in its most recent 13F filing with the Securities and Exchange Commission (SEC). The institutional investor owned 34,385 shares of the company’s stock after acquiring an additional 25,053 shares during the quarter. William Blair Investment Management LLC’s holdings in MongoDB were worth $8,595,000 at the end of the most recent quarter.

A number of other large investors also recently made changes to their positions in MDB. Pier Capital LLC raised its stake in shares of MongoDB by 112.5% in the 2nd quarter. Pier Capital LLC now owns 3,064 shares of the company’s stock valued at $766,000 after acquiring an additional 1,622 shares in the last quarter. Headlands Technologies LLC bought a new position in shares of MongoDB in the second quarter valued at approximately $622,000. Daiwa Securities Group Inc. lifted its stake in shares of MongoDB by 6.5% in the second quarter. Daiwa Securities Group Inc. now owns 9,191 shares of the company’s stock worth $2,297,000 after buying an additional 563 shares during the last quarter. Levin Capital Strategies L.P. bought a new stake in shares of MongoDB during the 2nd quarter worth $250,000. Finally, Exane Asset Management acquired a new position in MongoDB in the 2nd quarter valued at $1,066,000. Institutional investors and hedge funds own 89.29% of the company’s stock.

MongoDB Price Performance

NASDAQ MDB traded up $4.05 during trading hours on Tuesday, reaching $294.10. 88,974 shares of the company’s stock were exchanged, compared to its average volume of 1,489,775. The company has a current ratio of 5.03, a quick ratio of 5.03 and a debt-to-equity ratio of 0.84. The stock has a market cap of $21.57 billion, a PE ratio of -103.22 and a beta of 1.15. The firm has a fifty day moving average of $256.45 and a 200-day moving average of $301.10. MongoDB, Inc. has a one year low of $212.74 and a one year high of $509.62.

MongoDB (NASDAQ:MDB – Get Free Report) last announced its earnings results on Thursday, August 29th. The company reported $0.70 earnings per share for the quarter, beating analysts’ consensus estimates of $0.49 by $0.21. MongoDB had a negative return on equity of 15.06% and a negative net margin of 12.08%. The company had revenue of $478.11 million during the quarter, compared to analyst estimates of $465.03 million. During the same period last year, the company posted ($0.63) earnings per share. The firm’s quarterly revenue was up 12.8% compared to the same quarter last year. On average, equities research analysts predict that MongoDB, Inc. will post -2.46 earnings per share for the current fiscal year.

Analysts Set New Price Targets

MDB has been the subject of a number of research analyst reports. Monness Crespi & Hardt raised shares of MongoDB to a “hold” rating in a research report on Tuesday, May 28th. Oppenheimer boosted their price objective on MongoDB from $300.00 to $350.00 and gave the stock an “outperform” rating in a research report on Friday, August 30th. Guggenheim raised MongoDB from a “sell” rating to a “neutral” rating in a report on Monday, June 3rd. Piper Sandler upped their price target on MongoDB from $300.00 to $335.00 and gave the stock an “overweight” rating in a report on Friday, August 30th. Finally, Morgan Stanley increased their price objective on MongoDB from $320.00 to $340.00 and gave the company an “overweight” rating in a research report on Friday, August 30th. One equities research analyst has rated the stock with a sell rating, five have issued a hold rating and twenty have given a buy rating to the company. Based on data from MarketBeat.com, the stock presently has an average rating of “Moderate Buy” and a consensus price target of $337.56.

View Our Latest Analysis on MongoDB

Insider Transactions at MongoDB

In related news, Director John Dennis Mcmahon sold 10,000 shares of the business’s stock in a transaction that occurred on Monday, June 24th. The shares were sold at an average price of $228.00, for a total value of $2,280,000.00. Following the completion of the transaction, the director now owns 20,020 shares in the company, valued at approximately $4,564,560. The transaction was disclosed in a filing with the Securities & Exchange Commission, which is accessible through the SEC website. In other MongoDB news, Director John Dennis Mcmahon sold 10,000 shares of the company’s stock in a transaction dated Monday, June 24th. The shares were sold at an average price of $228.00, for a total transaction of $2,280,000.00. Following the transaction, the director now directly owns 20,020 shares in the company, valued at approximately $4,564,560. The transaction was disclosed in a filing with the SEC, which is accessible through the SEC website. Also, CAO Thomas Bull sold 138 shares of the firm’s stock in a transaction dated Tuesday, July 2nd. The shares were sold at an average price of $265.29, for a total transaction of $36,610.02. Following the completion of the transaction, the chief accounting officer now directly owns 17,222 shares in the company, valued at approximately $4,568,824.38. The disclosure for this sale can be found here. Over the last three months, insiders have sold 32,005 shares of company stock worth $8,082,746. Corporate insiders own 3.60% of the company’s stock.

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.

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

Looking to avoid the hassle of mudslinging, volatility, and uncertainty? You’d need to be out of the market, which isn’t viable. So where should investors put their money? Find out with this report.

Get This Free Report

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

Posted on mongodb google news. Visit mongodb google news

Percona Everest, an open-source cloud-native database platform, promises to break away from traditional Databases-as-a-Service (DBaaS) offerings. No hosted service or dependence on one vendor as with many DBaaS solutions, but database provisioning on any infrastructure of your choice. Whether in the cloud, on-premises, hybrid or any other solution.

Percona Everest, announced at the Open Source Summit in Vienna this week, offers support for multiple databases running on Kubernetes. These include MySQL, PostgreSQL, and MongoDB. According to creator Percona, the main advantage is that it does not rely on hosted infrastructure such as public DBaaS platforms. Instead, it allows companies to manage their own database clusters, either at third-party vendors or on their own infrastructure.

This means users are not locked into a specific cloud provider and are free to manage their databases on the platform of their choice. It doesn’t matter whether that’s Amazon Web Services, Google Cloud, OpenShift or their on-premises servers. This gives users the freedom to choose their database type without being locked into the constraints of any one platform owner.

As long, of course, as it is database engines like MySQL, PostgreSQL or MongoDB that work across platforms. Deploying Amazon RDS in Google Cloud, for example, is obviously impossible, as such proprietary solutions integrate deeply with the platform they were created for.

Optimal control and insight

Percona says this new solution offers the most flexibility in how and where users deploy their databases. It should also free them from expensive contracts with all sorts of restrictive ifs and buts that come with vendor lock-in. In short: as much control as possible over database configurations, optimal access to data and insight into all associated costs at all times.

Those who do not want to set this up on their own because they might lack experience with Kubernetes-based deployments can turn to Percona for enterprise-level support. That is how Percona pays its bills and makes money in this regard.

In addition to the promised flexibility in terms of supported database types and cloud environments, Percona Everest offers disaster recovery and comprehensive monitoring through its proprietary Percona Monitoring and Management (PMM). The platform also offers single sign-on (SSO) for centralized user access and private deployment options fully customizable by administrators. An intuitive user interface brings all this together in an attractive way for the user, whether that user is a developer or administrator, a QA engineer or DevOps specialist.

Also read: Percona survey: little movement in database market

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

Posted on mongodb google news. Visit mongodb google news

State of New Jersey Common Pension Fund D reduced its position in shares of MongoDB, Inc. (NASDAQ:MDB – Free Report) by 34.8% in the 2nd quarter, according to its most recent filing with the Securities and Exchange Commission. The fund owned 26,814 shares of the company’s stock after selling 14,324 shares during the quarter. State of New Jersey Common Pension Fund D’s holdings in MongoDB were worth $6,702,000 as of its most recent filing with the Securities and Exchange Commission.

Other institutional investors and hedge funds have also recently added to or reduced their stakes in the company. Transcendent Capital Group LLC bought a new stake in MongoDB during the 4th quarter worth about $25,000. MFA Wealth Advisors LLC bought a new stake in MongoDB during the 2nd quarter worth about $25,000. YHB Investment Advisors Inc. acquired a new position in shares of MongoDB during the 1st quarter worth about $41,000. Sunbelt Securities Inc. grew its position in shares of MongoDB by 155.1% during the 1st quarter. Sunbelt Securities Inc. now owns 125 shares of the company’s stock worth $45,000 after buying an additional 76 shares during the period. Finally, J.Safra Asset Management Corp grew its position in shares of MongoDB by 682.4% during the 2nd quarter. J.Safra Asset Management Corp now owns 133 shares of the company’s stock worth $33,000 after buying an additional 116 shares during the period. 89.29% of the stock is owned by institutional investors.

Analysts Set New Price Targets

Several equities analysts have recently issued reports on the company. Robert W. Baird decreased their target price on MongoDB from $450.00 to $305.00 and set an “outperform” rating for the company in a research report on Friday, May 31st. Monness Crespi & Hardt upgraded MongoDB to a “hold” rating in a research report on Tuesday, May 28th. Oppenheimer boosted their target price on MongoDB from $300.00 to $350.00 and gave the stock an “outperform” rating in a research report on Friday, August 30th. Tigress Financial decreased their price objective on MongoDB from $500.00 to $400.00 and set a “buy” rating for the company in a research report on Thursday, July 11th. Finally, Royal Bank of Canada reiterated an “outperform” rating and issued a $350.00 price objective on shares of MongoDB in a research report on Friday, August 30th. One equities research analyst has rated the stock with a sell rating, five have issued a hold rating and twenty have assigned a buy rating to the company. According to MarketBeat, the stock currently has an average rating of “Moderate Buy” and an average price target of $337.56.

View Our Latest Report on MDB

Insider Activity at MongoDB

In related news, CAO Thomas Bull sold 138 shares of the stock in a transaction on Tuesday, July 2nd. The stock was sold at an average price of $265.29, for a total value of $36,610.02. Following the sale, the chief accounting officer now owns 17,222 shares in the company, valued at approximately $4,568,824.38. The transaction was disclosed in a document filed with the SEC, which can be accessed through this hyperlink. In other MongoDB news, CAO Thomas Bull sold 138 shares of the company’s stock in a transaction on Tuesday, July 2nd. The stock was sold at an average price of $265.29, for a total value of $36,610.02. Following the transaction, the chief accounting officer now directly owns 17,222 shares of the company’s stock, valued at approximately $4,568,824.38. The sale was disclosed in a legal filing with the SEC, which is accessible through this link. Also, Director Dwight A. Merriman sold 1,000 shares of the company’s stock in a transaction on Thursday, June 27th. The shares were sold at an average price of $245.00, for a total value of $245,000.00. Following the completion of the transaction, the director now directly owns 1,146,003 shares in the company, valued at $280,770,735. The disclosure for this sale can be found here. In the last quarter, insiders have sold 32,005 shares of company stock worth $8,082,746. Company insiders own 3.60% of the company’s stock.

MongoDB Trading Down 1.7 %

Shares of MongoDB stock opened at $290.09 on Monday. MongoDB, Inc. has a 12-month low of $212.74 and a 12-month high of $509.62. The stock has a market cap of $21.28 billion, a P/E ratio of -103.23 and a beta of 1.15. The company has a quick ratio of 5.03, a current ratio of 5.03 and a debt-to-equity ratio of 0.84. The business’s 50 day moving average is $255.85 and its 200-day moving average is $302.21.

MongoDB (NASDAQ:MDB – Get Free Report) last announced its quarterly earnings data on Thursday, August 29th. The company reported $0.70 earnings per share (EPS) for the quarter, topping analysts’ consensus estimates of $0.49 by $0.21. MongoDB had a negative return on equity of 15.06% and a negative net margin of 12.08%. The company had revenue of $478.11 million for the quarter, compared to analysts’ expectations of $465.03 million. During the same quarter in the prior year, the business posted ($0.63) EPS. The business’s revenue was up 12.8% compared to the same quarter last year. Equities research analysts predict that MongoDB, Inc. will post -2.46 earnings per share for the current fiscal year.

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.

Read More

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

We recently compiled a list titled Jim Cramer’s Top 10 Stocks to Track for Potential Growth. In this article, we will look at where MongoDB, Inc. (NASDAQ:MDB) ranks among Jim Cramer’s top stocks to track for potential growth.

In a recent episode of Mad Money, Jim Cramer points out the surprising strength in the market, noting that many companies are performing better than Wall Street recognizes. He argues that people should stop doubting these companies every time there’s a negative data point. Cramer highlights the impressive management and execution by CEOs, which often goes unnoticed.

While Cramer acknowledges that some CEOs deserve skepticism, he emphasizes that many are outstanding and deserve recognition for their hard work. He criticizes the focus on short-term economic indicators and emphasizes that great companies aren’t distracted by minor fluctuations.

Cramer explains how Kroger CEO Rodney McMullen has led the supermarket chain to success despite challenges, including resistance to its acquisition of Albertsons and a tough economic environment. McMullen has managed to keep food costs down and deliver strong results through effective strategies like a superior loyalty program and regional store improvements. Despite high food prices, the company’s stock rose more than 7% following a positive earnings report, showcasing the company’s successful turnaround.

Cramer contrasts this with the tech industry, where complex details often lead Wall Street to misunderstand a company’s true potential. He believes that in tech, analysts frequently overlook the expertise and capabilities of CEOs who have a deep understanding of their businesses.

Our Methodology

This article reviews a recent episode of Jim Cramer’s Mad Money, where he discussed several stocks. We selected and analyzed ten companies from that episode and ranked them by the level of hedge fund ownership, from the least to the most owned.

At Insider Monkey we are obsessed with the stocks that hedge funds pile into. The reason is simple: our research has shown that we can outperform the market by imitating the top stock picks of the best hedge funds. Our quarterly newsletter’s strategy selects 14 small-cap and large-cap stocks every quarter and has returned 275% since May 2014, beating its benchmark by 150 percentage points (see more details here).

A software engineer hosting a remote video training session on a multi-cloud database-as-a-service solution.

MongoDB Inc.(NASDAQ:MDB)

Number of Hedge Fund Investors: 54

Jim Cramer believes MongoDB, Inc. (NASDAQ:MDB) is an enterprise software company delivering excellent results, but it isn’t receiving the same level of recognition as competitors like Salesforce.com (NYSE:CRM). He notes that investors generally seem to shy away from enterprise software companies, with the exception of Salesforce.com (NYSE:CRM). However, Cramer feels that MongoDB, Inc. (NASDAQ:MDB) is currently at a good price, suggesting it may be undervalued despite its strong performance. Cramer sees potential in MongoDB, Inc. (NASDAQ:MDB) and implies it deserves more attention in the enterprise software space.

MongoDB, Inc. (NASDAQ:MDB) offers a strong case for long-term growth, driven by its outstanding financial performance and strategic advancements. In Q2 2024, MongoDB, Inc. (NASDAQ:MDB) reported a 40% jump in revenue, reaching $423.8 million, with its cloud-based Atlas platform accounting for 65% of total revenue. This growth exceeded market expectations and demonstrates the growing demand for its flexible database solutions. MongoDB, Inc. (NASDAQ:MDB) also turned its operating loss from the previous year into a profit of $53.6 million, reflecting its ability to grow while controlling costs.

Analysts are optimistic about MongoDB, Inc. (NASDAQ:MDB), with KeyBanc raising its price target to $543, citing MongoDB’s dominant position in the NoSQL database market and its potential to capitalize on rising demand from cloud and AI-driven applications. MongoDB, Inc. (NASDAQ:MDB)’s educational initiatives, such as partnering with India’s Ministry of Education to train 500,000 students, further strengthen its developer community and support future growth.

ClearBridge All Cap Growth Strategy stated the following regarding MongoDB, Inc. (NASDAQ:MDB) in its first quarter 2024 investor letter:

Overall MDB ranks 6th on the list of Jim Cramer’s top stocks to track for potential growth. While we acknowledge the potential of MDB as an investment, our conviction lies in the belief that under the radar AI stocks hold greater promise for delivering higher returns, and doing so within a shorter timeframe. If you are looking for an AI stock that is more promising than MDB but that trades at less than 5 times its earnings, check out our report about the cheapest AI stock.

READ NEXT: $30 Trillion Opportunity: 15 Best Humanoid Robot Stocks to Buy According to Morgan Stanley and Jim Cramer Says NVIDIA ‘Has Become A Wasteland’.

Disclosure: None. This article was originally published on Insider Monkey.

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