Month: April 2025
MMS • Craig Risi
Article originally posted on InfoQ. Visit InfoQ
In February 2025, researchers at Socket uncovered a significant supply chain attack within the Go programming ecosystem. A malicious package, named github.com/boltdb-go/bolt, was discovered impersonating the legitimate and widely-used BoltDB module. This backdoored package exploited the Go Module Proxy’s caching mechanism to persist undetected for years, underscoring vulnerabilities in module management systems.
The Go Module Proxy is designed to cache modules indefinitely to ensure consistent and reliable builds. While this immutability offers benefits like reproducible builds and protection against upstream changes, it also presents a risk: once a malicious module is cached, it remains available to developers, even if the source repository is cleaned or altered. In this incident, the attacker leveraged this feature to maintain the presence of the backdoored package within the ecosystem, despite subsequent changes to the repository.
This case is part of a broader trend where attackers exploit package management systems through techniques like typosquatting. Similar incidents have been observed in other ecosystems, such as npm and PyPI, where malicious packages mimic popular libraries to deceive developers.
To reduce the risk of supply chain attacks, developers should carefully verify package names and sources before installation, ensuring they’re using trusted libraries. Regular audits of dependencies can help catch signs of tampering or malicious behavior early. Security tools that flag suspicious packages offer another layer of protection, and staying up to date with known vulnerabilities and ecosystem alerts is essential for maintaining safe development practices.
By adopting these practices, developers can enhance the security of their software supply chains and reduce the risk of introducing malicious code into their projects.
Podcast: Implement the EU Cyber Resilience Act’s Requirements to Strengthen Your Software Project
MMS • Eddie Knight
Article originally posted on InfoQ. Visit InfoQ
Transcript
Olimpiu Pop: Hello, everybody. I’m Olimpiu Pop, an editor with InfoQ, and tonight, we have Eddie Knight to demystify the European Cyber Resilience Act. I can try to give an introduction, but he’s a proper Knight, and he has so many titles in so many organizations, so I’ll just let Eddie do the intros. Eddie, tell us a bit about what you’re doing these days.
Eddie Knight: So Sonatype is my employer within Sonatype. I am the OSPO lead, which means I manage our relationships primarily externally with the Linux Foundation and a few others, such as the Eclipse Foundation and Apache Foundation. But most of my scope is within the Linux Foundation personally, which has me on the Technical Oversight Committee for FINOS, the financial technology arm of the Linux Foundation. And that’s because my background is in finance. I was at Bank of America and then at Morgan Stanley before Sonatype. Because I have a security and compliance background I am the co-chair for the security technical Advisory group for CNCF. And in the course of those duties, some of the stuff that we’ll talk about here in a bit, a lot of the activities have overlapped with OpenSSF, the Open Source Security Foundation, and so I maintain a few projects over there as well. So yes, you’re right. I am kind of everywhere.
Olimpiu Pop: So just to make it short, you are supported by Sonatype, your employer, to do a lot of good stuff in the open source field.
Eddie Knight: That’s exactly it.
Software supply-chain threats are growing at alarming rates [02:03]
Olimpiu Pop: Thank you for simplifying that for me. First of all, congrats for the keynotes that you just gave on KubeCon. Michael and you did an excellent job. So I will just try to dig deeper on those points because the Cyber Resilience Act in Europe raised a couple of eyebrows through the years. But before we go there, as you said, you’re with Sonatype and Sonatype has a decade behind it of doing reports on what happens in the open source community in the supply chain. And as we know the software is hitting the world, and obviously now the AI is hitting the world. So let’s look a bit at that. How did the supply chain evolve in this decade? Okay, good. Thank you for that.
Eddie Knight: Yes, so the last decade of the software supply chain. I think one of the biggest wins that we’ve had is there’s fewer and fewer people that are saying, “We don’t use open source”. I should put that in air quotes. Fewer people are saying that, and you’ll find that a lot of people who are saying that are using Java and they’re running Linux machines, and they say, “We don’t use open source”. Like, okay, cool, how are you doing anything? Like Python. “We’re a Python shop that doesn’t use open source”. Exactly, my friend. That is an open-source language. And so we’re seeing fewer and fewer of that. So that’s a big win.
We’re also seeing a massive influx in just discussion around supply chain security. A decade ago, we didn’t have the term supply chain security. I wasn’t working in this space. I wasn’t thinking about this space. I was a culprit in this space of backdooring dependencies into my firms and trying to take shortcuts to increase business value by taking shortcuts. But we see a lot more people just having these discussions now, and that’s a huge, huge benefit because on the flip side, the last three years we’ve seen the number of attacks on the open-source supply chain double every single year, and it’s just a huge space.
Olimpiu Pop: That means if it doubled every year, now after a decade, it’s a lot. You are the quant here.
Eddie Knight: That’s a good number.
Artificial Intelligence is an accelerator; it can be used for defending or on the offensive side [04:12]
Olimpiu Pop: You are the quant here. But for me it seems that that’s a lot. I remember the last time when I checked it, and I think that was last year in October, it was a quarter of a million attacks solely in the supply chain. So that’s a lot, and I’m expecting that things changed also, given that AI is creating a new leverage. Do you have any insights about that? How did the AI change the game?
Eddie Knight: On the defensive side, at least at Sonantype, we’ve always used machine learning for, I think the last… Again, before I joined the firm, maybe six or seven years ago, machine learning was starting to get brought into analyzing, and that’s how when you crack open our tools, we’re able to tell you, “Hey, your software has copy pasted code from a known vulnerability or known exploitable”. Whether it’s malware or a vulnerability, the way that we’re able to tell you, you copy pasted it over is through machine learning.
So machine learning in that aspect has been around for a while, but the generative AI that we have these days is kind of having the opposite effect. It’s allowing known exploits to be obfuscated, to be done in different ways, to be manipulated or just to be performed by people who otherwise knew nothing about it. At the beginning days of ChatGPT, I was able to go in there and describe the types of attacks I wanted to protect against and get ChatGPT to explain exactly how I would build malware to distribute. So that is definitely the reason that since generative AI has become public, we’ve seen this doubling every single year is definitely, it’s downstream from AI becoming a more publicly accessible resource for the good and the bad.
Olimpiu Pop: Okay, so just to put it that plainly, this new wave of generative AI, it’s a bicycle more or less. It makes you run faster, but if you’re on the wrong side, you just go over the cliffs or somebody will push you over the cliffs and then your falling will be much longer. Okay, thank you for that. And in order to just put, I know that I said a very academic term here, and it’s a lot in terms of the effects hackers have around us. I just read the other day a paper from Harvard that was putting it in context financially, and it was something like, currently the money that are being put into open source is around $4.15 billion, but the impact financially that is going on the other side, it’s around $8.8 trillion. So for each dollar that we invest in open source, we get $2,100 as a return. So that’s a good ROI. I know, and given it’s-
Eddie Knight: I think that even get past my marketing budget. I think they’d even be happy with that ROI.
Olimpiu Pop: Okay. That’s good. So just to make it even more plain than that, it could be a return of 212X. So that’s a lot. So I think everybody will be very happy with that output. Okay. And let me remember a bit the things that I did while I was doing research on these kind of things. And looking at what was happening in the supply chain and the hackers, I found a couple of enemies, let’s call them, for the plane developer, and those were malicious actors, obviously the people that they just want to put the hand in your pocket, take your money, bring it private information or anything else that can be sold on the black market. Then a couple of years back, state actors came into play and that was something new for me. It was becoming espionage. So all these kind of things that are done for. I’ll not name countries or anything else, but mainly state actors that just wanted our skin.
The open-source communities worked with the EU to shape the Cyber Resilience Act into the form that allows it to help developers [08:02]
And last but not least, it was used as a weapon, again, in different parts of the world. But the feeling was that also bureaucracy is an enemy of the plane programmer. And I know that you as a company, Sonatype, especially Brian Fox was very involved with the Cyber Resilience Act. I know that he was a partisan of making things plain. And me being a European, I was very happy to see that the European Union listened, took in the information that was provided by the companies involved in open source, and it actually came something out that everybody was happy with.
I know that last year when the final version was signed or voted, people were very happy and a bunch of companies, the Eclipse Foundation and probably the Linux Foundation as well, they just came together and they said, “Okay, now we’re going to work to see through in terms of implementation”. What’s your insight on that? I mean, you are actually one of the main contributors into making things right. Anything to be added there?
Eddie Knight: Oh, that’s an overloaded question.
Olimpiu Pop: Let’s make it plain. What’s the most important thing that we have to know now as an industry. Just plainly when should we start worrying about CRA?
Eddie Knight: I would say don’t worry about it. Think about it. Don’t have anxiety about it. There’s so many benefits to the CRA if we all play ball, but that’s not what you were meaning. You’re meaning when do we need to start actioning? And there’s two big numbers to remember. The first is, I believe it’s June 11th, 2026, which is if you have a known exploitable vulnerability in your software, you will have reporting requirements after that date. The second is going to be the… Well, there’s a mid-tier, there’s midline, but the end of 2027, so December 11th, 2027 is going to be the full effect. So all of the rules that are written down that your compliance staff are going to need to understand and metabolize are all going to be in full effect at the end of 2027, which is a pretty good amount of time to train people up, make sure we have the systems in place.
Olimpiu Pop: So we still have two years more or less?
Eddie Knight: Yes.
Olimpiu Pop: So it would be like a soft landing. There are intermediate steps, right?
Eddie Knight: That’s the intent. That’s the intent. Yes. And I’m actually really proud of the folks who made those decisions and those timelines because that middle timeline is actually more for themselves ish in that there’s this middle of 2027, there’s a requirement on themselves to have tooling, resources. They need to be notifying auditors. Those types of activities are all needing to be done something like half a year before the full rollout. And so there’s this staggering to it that’s actually really, really beneficial and makes it just a lot more possible for it to be done well.
Olimpiu Pop: Okay, good. That sounds digestible, but I know that during your keynote, you had the slide with a lot of dots and a lot of lines. I felt that I need a PhD only to comprehend half of it. So let’s look a bit-
Eddie Knight: Yes, the FUKAMI slide.
Olimpiu Pop: Yes.
Eddie Knight: That’s the FUKAMI slide. It’s the scary slide. It’s all you need to know is how these a hundred actors connect to each other in the relationships and responsibilities between them, and then you’re done. There’s a lot of different nuanced bits that are in there. Now in the keynote, the intention is like, hey, you don’t need to worry about all of that right now. If you find yourself in this picture, worry about the lines that you connect to. But understanding this entire ecosystem of the auditing, the regulation, the other regulations that are impacted by this regulation, all of those different types of things, don’t worry about understanding. Absolutely all of it. Action. Take action on finding yourself in this picture, finding the relationships that you have with other people in this picture and what responsibilities you have because of that. There is action that can be taken here, and it doesn’t mean you need to understand the entire giant picture.
How does the CRA help prevent other “Christmas Miracles” like the Log4Shell [12:10]
Olimpiu Pop: Okay, great. So let’s see if I got it right. It depends where I’m positioned in that picture. So in my plain understanding, that will be I’m either downstream or upstream. Somebody is using what I’m building or I’m using somebody else’s. Of course, it’s oversimplified because theoretically it should be both ways and I would consume other libraries and other people might use mine. So let’s get back to history. A couple of years back in December morning around 4:00 AM, I was just trying to do some proper work, and then I got an email that said that a brown splash hit the fan, and that brown splash was Log4J.
Eddie Knight: Yes. The Christmas Miracle.
Olimpiu Pop: Exactly the Christmas Miracle. That pretty much started everything. Well, it didn’t start everything, but it created a domino effect in that area because from that point on, a lot of countries started putting cyber legislation in place. I know that United States started doing something. I don’t know if something out of that is still available or it’s still in use today, but that what happened. So now I’m just thinking about the guys in Nebraska that were proper heroes for doing that stuff for the Log4J library and making sure that everything is fixed. What would the CRM mean for them today and tomorrow?
Eddie Knight: Yes, I made Log4J. You’re using Log for J. Somebody found an exploit on my software that I wrote, and now you have to clean up and find every single place that it was installed and do an update and make sure that that update’s not breaking things. So in that situation, your question is how does the CRA help you in this story?
Olimpiu Pop: To me as a consumer, and what’s the impact for you as the maintainer of Log4J?
Eddie Knight: So in the past, especially prior to this example of Log4J, it was not a universal standard to have much of anything between the maintainer and the consumer. Now we know that the financial services industry is highly regulated and it’s very standard. It’s an industry standard to have some middle steps in there where there’s an approval process, there’s a scanning process, there’s a artifact storage process in between you and me as the maintainer and the consumer. And when those systems are in place, we saw that the financial services industry, at least the customers of Sonatype who are using of those things, we know that those proper tools are properly in place, had an average of four days to recover all of their Log4J instances for large enterprises.
Comparatively speaking, the universal average of updating all resources from the Log4J incident was four weeks. So not having anything between the maintainer and the consumer is a serious problem because you need that visibility, you need those pre-checks. You need reminders, alerts, tracking, just everything. You need a lot of support there. And when it’s there, life is easy.
The CRA is doing something similar to that, not in a technical sense, but in a kind of a social sense. There’s these rules that are being put in place in between me as the maintainer of this code base and you as the consumer. So that way you know that somebody has come in and looked at this process all along the way before it got to you, and that might mean your bosses had to follow more rules. It might mean that the steward who is hosting and supporting me as a maintainer has more rules that they have to follow, but because of those rules and putting more steps between us, what we’re going to find is that there’s just going to be a lot more of a streamlined relationship so that way there’s less to worry about. And it’s going to be a win. It’s going to shift from compliance being done 100% inside your firm.
When you need to pull something down, you need to have somebody on your team go and research and look at who’s maintaining that. Just all the data that you need to pull in to be able to do a proper analysis of this. Instead of that always being done by you, what we’re going to see is a shifting outward to more shared responsibility, especially for these bigger packages like Log4J. We’re going to see a lot more shared responsibility happening because everybody’s going to be needing to follow the same rules, and it’s just going to be significantly more practical to have the stewards who are supporting those maintainers offset some of those costs and have the audits be done in a public space so that way everybody can share this knowledge and these resources. And when one enterprise is adopting a tool and bringing it up to snuff, everybody in the world is going to benefit from that.
Olimpiu Pop: So, for me, that doesn’t sound that scary. It sounds like we are just putting some steroids in open source, making sure that everybody really benefits from what it’s doing and that it becomes more of a community. Is that correct, more or less?
Eddie Knight: I know not everybody’s looking at it that way. That’s the way I’m looking at it. Absolutely. Yes.
OpenSSF Baseline assist with the CRA adoption [17:36]
Olimpiu Pop: Happy to have the same optic. Well, obviously while I was talking about these things, because I did the first share of presentations in this space, I was starting with the line that the European Union doesn’t innovate, but it regulates. We are very good at regulating things. But now looking at that, my feeling is that they are just looking that we do it properly and people are actually safe from that point of view because it has a huge responsibility. And just an example popped in my mind during that period, I was working in the company that was doing only JavaScript and everybody was laid back, okay, it’s good. We are not using Java. Nothing affect us. Two, three hours down the line, everybody was in panic mode because actually we were using a cloud service that under the hood obviously was using Java due to its benefits. And then again, we had to start over again and just work with other stuff. So yes, I understand the benefit for that.
And as you started initially, you are part of a lot of organizations, a lot of work groups in the open source space. What tools can we use? I mean, obviously understanding the legislation is very complex, but I know that OpenSSF has a bunch of tools that are very useful. For instance, I liked a lot the scorecards. What do you have in the back pocket that we can send developers to?
Eddie Knight: Yes, so scorecards is a really good tool to get a quick pulse. I would say make sure you’re sending developers to scorecard and not your regulatory compliance folks, because scorecard, there’s a set of recommendations that are in there that are actually really good recommendations, but they’re not vetted by a large community body. They’re not mapped to guidelines such as frameworks and regulations and things like that yet conversations are in place about changing that.
But as things currently stand, it’s what a core very good set of engineers has identified as things to improve, to lock down your projects, and a really good tool to be able to point that at a million and a half repos every single week and give every single developer a quick little snippet of code that you can put in your pipeline so you can update your checks whenever you want. You can just run it. And for the general public, there’s this massive database of results. So you can see what the score of any one of a million and a half projects is rating according to these checks.
So it’s really good for a quick view. It’s best for developers because it’s giving you actual practical changes that you can do right now. The other thing inside OpenSSF that contrasts to that. So the downsides that I just mentioned from Scorecard are being addressed in the project called the Baseline, which we’ve just been talking about, which it’s the open source project security baseline. And the purpose of the baseline is to compensate for exactly the things that I just listed off. We are trying to take a set of known cybersecurity best practices and guidance, things like NIST 800-53, things like the CRA, and bring those down and say, how does this apply to open source projects? But how does this apply to every single open source project generically as a literal baseline for open source projects?
In these set of controls there’s 40 of them. I think that’s the right number. It’s round numbers. So I never trust round numbers. Last I checked, there’s 40 and they’re divided into three levels. There’s some topical organization to them, and there are assessment requirements for every single one of them. So you can look at it and you can say… I almost want to recite off some to you, but just as an example, you need to have MFA turned on. And so now I can just stop and think, “Oh yes, for all of my projects MFA’s turned on except for, you know what? I think I didn’t think about it for one of them. Let me go and do that right now”.
And so it’s really good for developers in that aspect to just give this checklist all the way down of, hey, these are the things that are true for every single project. And those 40 are divided up into three levels where the bottom level is 18 or 20 checks that are just like, hey, if you’re a single developer, you could still do this. And the top ones are like, hey, you need to do a security self-assessment. And that’s connecting a lot to the CRA where the CRA is asking open source projects to assess their own security and make attestations and say like, hey, this is where I stand. And that’s the kind of stuff that we would expect from projects with more maintainers, more users, things like that.
But that level one criteria is something that just has never existed for open source projects. So you just have that key central cohesive recommendations. And so that’s something coming out of OpenSSF that I’m very proud of. I think it’s just a really good project that everybody can benefit from. And on the horizon from that last thing I’ll talk about, because there’s too much, and you’ll never get to talk again if I keep going, but on that topic of the baseline, we are currently working with the Linux Foundation, the LFX Insights platform, to get a subset of those checks that can be run against public repos, the way that scorecards being run against 1.5 million, some odd repos. We are working with LFX Insights to set up a system where that same kind of scanning can be done, but now the results are actually mapped to regulatory expectations such as the CRA, and that’s something that’s trying to be provided to open source maintainers, which is really, really exciting.
Olimpiu Pop: So let me break down in levels and points what you said. So the scorecard tool, by the way, it has really nice logo. I like the logo, so that’s how I choose the scorecard. Yes, it’s the best logo ever. That’s useful for day-to-day developers to ensure that they, first of all, they can check their open source project or even internally their project. And that was my recommendation usually. So now you can correct me whether it was proper or improper recommendation to be used when we are choosing a library to incorporate, to adopt in our project. At least that was my view. It was good to check and then compare between that.
Eddie Knight: Yes, so I’m a little bit on the fence about that because there’s not a guidance on what is a good threshold, and it’s a score of zero to 10, and the average score is less than 4.5. It’s something like four. So if you want to have just a decent number, five is a decent number, but that’s not considering. You might have done some of this stuff that isn’t actually securing your project. You might’ve set up a fuzzing tool, but for your project, that might not be boosting your security for your particular situation as much as some other elements. So you might be increasing your score without necessarily making a significant impact.
Olimpiu Pop: Improving the security.
Eddie Knight: And then on the other side of the exact same point is five out of 10 sounds horrible. That’s horrible. And so I think a lot of folks just don’t know how to read. If you see a nine, you see a 10, it’s like, oh, cool, they’re passing. No, no, no. Those projects are doing everything that these engineers that are maintaining scorecard could think that they could measure. That’s a really, really good score. I looked at one of the open telemetry scores, they have like 70 repos, but one of them was a 9.9, and I was here in middle of a conversation with them and I’m like, “How did you do that?” He’s like, “Oh, that’s not my repo. But yes, I guess they just did everything wild to see scores that high”. But as a reader, as a consumer, we’re not trained to know, “Hey, dude, above four is a pretty good score”.
How the CRA-related controls can be used to enhance the security of your project [25:32]
Olimpiu Pop: So that means that in life, like in everything else, we just have to make sure that the tool is fit for our purpose and understand exactly what’s there. So actually look beside the number. So we’ll have the number as a guiding principle, but then we should look at the things that are actually of interest to us because as you said, there are some things that are there, okay, we are communicating if we have bugs or not or stuff like that. So we actually have to aim to have the most important things in place. Good.
And then you mentioned about the baseline. And the baseline, it reminded me about during the period when I was doing certification. Not really happy about those times. So I still have some cold sweats during the night about those things, but my feeling is that these things are appropriate and they are level. So theoretically if I’m doing those, I’ll be ticking some boxes that will assure my audience that some particular operations were made and now some sanity mechanisms are in place. One more question on this. How often should it happen? Should it happen every time when we are doing a release or is it on a time-scale?
Eddie Knight: Yes, that’s a really good question. So on one hand, if you have automated checks, you should just run them all the time, put them on a cron, put them on your pull requests, put them on your commits, just run them all the time. Now granted, you’re going to burn a lot of energy doing that, and you might just lose your mind. So I think the thing to consider is, again, which of these values matter to you? With the baseline, what we’ve tried to do is say, hey, every single one of these values always matters. But some of them are like, hey, is this data populated?
The quality of that data might be arbitrary like your security policy. You might have a janky security policy, but you have it. It exists, but it’s maybe not super clear for readers. It doesn’t matter how often you run that check. There’s a degree to which compliance will not always equate to security, and that’s a really important thing that I think we don’t talk about enough.
Olimpiu Pop: So we should talk more about it, right? Okay, so what more… I mean, talking is okay, but more than that, what would be actions that we need to take in that spectrum to be on the safer side? Can you name one, two?
Eddie Knight: As far as what controls can we meet or what can we do as a community? Because I’ve got answers for both.
Olimpiu Pop: Let’s have both because it’s the day when we can be eager to hear more about it.
Eddie Knight: Yes. So there are plenty of controls on multi-factor that I talked about. There are very technical controls. Those should just always be in place and always check those. Always. You should just be scanning for those. If you’re a user and you’re seeing that some of these detailed technical controls are out of place, like there’s status checks aren’t being run on commits, things like that, it’s like, oh, they should raise a red flag. I have a repo right now that I am not running my status checks and not requiring code reviewers on. I hope that you would come to me and tell me, “Hey, we want to use this”, and this is where the community part comes in. I hope you would come to me and say like, “Hey, we want to be using this, but we know that the standard is that you should be doing these certain things”.
And then I would say, “Oh, well, I wasn’t ready for you to be using that in prod”. If your response is, well, we are ready to use it in prod, then you and I should work on implementing those things and making sure that’s in place. And then there’s the other side, which is the clarity of the security documentation. The secure by default is not always possible, so we have to have secure configuration documentation. This is how you turn on Flux, the continuous deployment GitOps platform. You can’t just kick it up and turn it on without there being some security risks that you need to account for in your system, and you need to flip some switches and stuff. It just came out of a meeting with their maintainers. Flux has documentation around what you should do, but every time a new feature is added, there’s a chance that that documentation is going to go stale.
Knowing what it means to do a securely configured deployment of this application is extremely, extremely important. And so as a community, we need to be more ready and willing to raise our hand when we say, “That wasn’t clear. That looks like it was out of date”. Nobody likes hearing make a pull request, but at least file an issue. At minimum say you have some security documentation that you clearly cared about at one point, and I don’t think it’s up-to-date anymore, or I’m not sure it’s up-to-date anymore. Could you just timestamp this and let everybody know that you reviewed it?
Maintainers are almost universally motivated by end user requests. What the user is asking for is what the maintainers are going to build. The exception is when their bosses are a user. That might be the more powerful line of feedback. But if you’re able to come in and just let folks know like, “Hey, I’m using this. I was trying to use that piece of documentation. Your documentation is a feature for me. Your security documentation is a key feature for me”. Help the maintainer prioritize it, even if you can’t help the maintainer improve it.
Olimpiu Pop: Okay, fair enough. So I don’t know why, but in my head, a simple rule came out, applied the Little Girl Scout rule. So either raise a hand, tell somebody that you found a problem or even better just go on and fix the issues. And that’s it. Okay. One last question. We are obviously in the land of CNCF. Kubernetes is obviously a very big community and looking around here, there are a lot of folks, what’s here to be taken from other people? I mean, not everybody’s in the operation side, but underneath the tool, a lot of things are running on Kubernetes. There are a lot of other tools that are here that are used on a day-to-day basis by all of us, either knowingly or unknowingly. Anything else that we have to take either as a learning from this event or even more, what should the guys on the CNCF learn from the CRA and what they have to do next?
Eddie Knight: So a lot of what I’ve been doing has been the security slam this week, right? We’ve had four different sessions, OpenTelemetry Flux, of the two graduated projects. The two sandbox projects are Mesury and Oskal Compass. And so my Headspace very much in lessons learned from this experience where we have been working with the project maintainers to create a backlog list of security tasks that could be done, security documentation that could be improved with the Flux guys. It’s been prototyping a new security feature, which has just been absolutely wild, occupying a lot of my Headspace clearly.
I think the biggest takeaway that I’ve been hammering on and trying to drill in is that all of these needs to be a community effort. So the Cyber Resilience Act divides us up into manufacturers as well as maintainers who might be manufacturers and might not be manufacturers. And then we have stewards that an open source project may fall under or an open source project may not fall under a steward.
So we’ve got maintainers, we’ve got stewards, we’ve got manufacturers, and we’ve got the consumers. And in middle of all of those are the members. So everybody here is most likely a member of CNCF, and if not, you’re a beneficiary of the members who are paying to keep the lights on here. So the members are at the middle of being maintainers and manufacturers and stewards and consumers of all of this open source tooling. And if we can just together collectively decide that we’re in this together for real, for real this time, we can start sharing so much of this burden of regulatory compliance. And instead of just doing compliance, we can start doing compliance in a way that results in real security outcomes. And that is only going to be coming from actual cross the aisle, cross the like JFrog and Sonatype working together sort of thing, right?
Cats and dogs need to be solving problems together. And when we do that and we approach these really difficult complex topics with an open heart, we are going to be able to upgrade and elevate the community in ways that have just never happened before. And this double every year attack on the software supply chain is going to keep going. People are going to keep just burning electricity on AI programs, trying to get vulnerabilities in trying to get exploits, building malware. And what they’re going to be met with is a mountain of community resistance that is growing just as fast.
How the CRA describes different roles of the individuals and organisation involved in open-source [34:32]
Olimpiu Pop: First of all, I think this would be a very good speech for winning the Miss Universe thing. It’s a lot of peace in the world and a lot, but yes, you’re totally right. So I think the message is that we should all work together for a brighter future, meaning that it’s us or them. On my presentation, I used to have a pirate flag that was positioning the dark side of the web, also pretty much the hacking right under China in terms of GDP. And that’s scary because both China and the US are the first in the second position, and we are talking about trillions, and that’s important that we all work together regardless of the name of the company that we are working under to make the future brighter and safer for all of us. And I know I promised that that will be the last question for you, but you said something that raised the question. You mentioned open source maintainers and then manufacturers. What’s the difference? How should I position myself from that point of view?
Eddie Knight: In our keynote, we’re not allowed to discuss vendors and manufacturers. We can discuss products and maintainers. With you, I can actually just say names to use examples about anything that is an open source piece of technology, and the maintainers are everybody who brings that thing to life. They’re reputationally associated with it. They’re the leaders in producing this thing.
Olimpiu Pop: That’s an individual.
Eddie Knight: An individual, yes.
Olimpiu Pop: Okay, so me, if I’m doing a pool request to Kubernetes, I’m becoming a maintainer of Kubernetes or it’s about the company that is powering and putting money and burning hours of their employees.
Eddie Knight: No. So you could be a contributor. The contributors aren’t really captured in the CRA as much just by making a PR, your contributor. The maintainers also kind of aren’t really called out too much in the CRA, right? Because even though the maintainers are part of the governance structure of this project, right? Open source is software standards and community. And so this open source project is the software that is built by the community. In the case of Kubernetes, you’ve got all three. Those maintainers who are part of the governance structure in this project are not necessarily manufacturers. However, our cloud providers are delivering Kubernetes to us at a price. They are bringing Kubernetes to market. The maintainers are not bringing Kubernetes to market. So Kubernetes, while it is still just in a code base, it is an idea, it’s a concept, it’s fun, but it’s not a product at that point.
Olimpiu Pop: Okay, good. So that means that if I’m manufacturing something, I’m just, I don’t know writing books and I put them on the shelf and then I’m more or less a maintainer and whatever. But if I transform that in a bookshop, then I’m providing that service. So that’s the point when I should be worried about, right?
Eddie Knight: Yes. There’s another spin on this where you have folks such as Control Plane who are the exclusive support providers for Flux. They pay their maintainers to work on Flux. So those humans are at once. Those humans are themselves maintainers and they’re employed by and associated with the manufacturer. So the manufacturer is the corporate entity at this point who is providing support, but the individuals within that corporate entity might also themselves be maintainers.
Olimpiu Pop: You can see that you work in finance. It’s a lot. It’s a mouthful. So yes, I understood it. Thank you. Any close statements, anything that I missed asking you to just wrap up everything?
Eddie Knight: Yes, I appreciate talking about this. I appreciate you creating space for this. Definitely. I appreciate you entertaining my Miss Universe philosophy. I think there’s going to be an increase in money changing hands where you’re going to have third party audits. You’re going to have a rise of manufacturers providing support, where now the consumers of Kubernetes are going to be incentivized to not run vanilla Kubernetes anymore because they don’t want to be the manufacturers. They want to offset some of that risk. And so their choice is going to be either continue paying their compliance and security staff to lock down their vanilla deliveries prior to bringing it to market or work with a support system, somebody that’s providing support, somebody that’s delivering this. And so where the money is being spent might start changing hands a little bit more. But the net value I anticipate is going to be largely beneficial.
I think that it is a zero-sum game in how we’re spending the money. It’s going to be spent somewhere, but what we’re going to see is we’re going to start consolidating who is actually taking on the liability of securing these different products. And in doing so, they’re going to have the capability of doing it at a much higher level than they’ve ever had before. And that is going to be a change. It’s going to be a different way of doing things, but it will be a net improvement for everybody. And that’s why Miss Universe, I’m saying, this is awesome. This is really good for us. We need to pay attention that we are doing this together.
Olimpiu Pop: Yes, I totally agree with that. It feels that the coming of age of the software industry, because up to now it felt like more or less people were working in their garages, even if they were working in corporations. And now it’s actually putting some structure into place that would allow us to play ball and just have a united front Eddie, thank you. Enjoy the rest of the conference.
Eddie Knight: Thank you. It’s always a pleasure.
Olimpiu Pop: Thank you, Eddie.
Mentioned:
.
From this page you also have access to our recorded show notes. They all have clickable links that will take you directly to that part of the audio.
Java News Roundup: JDK 25 Schedule, Spring 7.0-M4, Payara Platform, JobRunr 7.5, Jox 1.0, Commonhaus
MMS • Michael Redlich
Article originally posted on InfoQ. Visit InfoQ
This week’s Java roundup for April 14th, 2025 features news highlighting: the JDK 25 release schedule; the fourth milestone release of Spring Framework 7.0.0; the April 2025 edition of the Payara Platform; the release of JobRunr 7.5.0 and Jox 1.0.0; and Kroxylicious having joined the Commonhaus Foundation.
OpenJDK
Oracle has released versions 23.0.2, 21.0.6, 17.0.14, 11.0.26, and 8u441 of the JDK as part of the quarterly Critical Patch Update Advisory for April 2025. More details on this release may be found in the release notes for version 23.0.2, version 21.0.6, version 17.0.14, version 11.0.26 and version 8u441.
It was a busy week in the OpenJDK ecosystem during the week of April 14th, 2025, highlighting eight new JEPs having been elevated from their JEP Drafts to Candidate status. Four of these will be finalized after their respective rounds of preview. Further details may be found in this InfoQ news story.
JDK 25
Build 19 of the JDK 25 early-access builds was made available this past week featuring updates from Build 18 that include fixes for various issues. More details on this release may be found in the release notes.
After its review has concluded, Mark Reinhold, Chief Architect, Java Platform Group at Oracle, formally declared the release schedule for JDK 25 as follows:
- Rampdown Phase One (fork from main line): June 5, 2025
- Rampdown Phase Two: July 17, 2025
- Initial Release Candidate: August 7, 2025
- Final Release Candidate: August 21, 2025
- General Availability: September 16, 2025
For JDK 25, developers are encouraged to report bugs via the Java Bug Database.
BellSoft
Concurrent with Oracle’s Critical Patch Update (CPU) for April 2025, BellSoft has released CPU patches for versions 21.0.6.0.1, 17.0.14.0.1, 11.0.26.0.1, 8u451, 7u461 and 6u461 of Liberica JDK, their downstream distribution of OpenJDK, to address this list of CVEs. In addition, Patch Set Update (PSU) versions 24.0.1, 21.0.7, 17.0.15, 11.0.27 and 8u452, containing CPU and non-critical fixes, have also been released.
With an overall total of 740 fixes and backports, BellSoft states that they have participated in eliminating 38 issues in all releases.
Spring Framework
The fourth milestone release of Spring Framework 7.0.0 delivers improvements in documentation, dependency upgrades and new features such as: a new OptionalToObjectConverter class to automatically convert an Optional to its contained object; and a new ClassFileMetadataReader class that supports JEP 484, Class-File API, for reading and writing classes as Java bytecode. Further details on this release may be found in the release notes.
The first release candidate of Spring for GraphQL 1.4.0 ships with improvements in documentation, dependency upgrades and new features such as: a new graphql.dataloader observation that measures data loading operations so that recorded traces are much more precise; and improvements to the server transports so that reactive data fetcher operations will be cancelled in-flight and further data fetching calls (blocking or reactive) will be avoided. More details on this release may be found in the release notes.
Payara
Payara has released their April 2025 edition of the Payara Platform that includes Community Edition 6.2025.4, Enterprise Edition 6.25.0 and Enterprise Edition 5.74.0. All three releases deliver dependency upgrades and new features: the ability to customize logs sent to the remote system log servers for more control over log management; and the addition of a new connection pool property to disable the verification of client information properties when pooling is set to false. Further details on these releases may be found in the release notes for Community Edition 6.2025.4 and Enterprise Edition 6.25.0 and Enterprise Edition 5.74.0.
Micronaut
The Micronaut Foundation has released version 4.8.2 of the Micronaut Framework featuring Micronaut Core 4.8.11, bug fixes and patch updates to modules: Micronaut Maven Plugin; Micronaut JSON Schema; Micronaut Micrometer; and Micronaut Servlet. More details on this release may be found in the release notes.
JobRunr
The release of JobRunr 7.5.0 features: support for Quarkus 3.20.0 and Micronaut 4.8.0; improved detection of misconfiguration between JobRequest and JobRequestHandler interfaces; and the ability to configure an instance of the InMemoryStorageProvider class using properties. There is a breaking change for developers who use Quarkus and Micronaut. The behavior to automatically fall back to the InMemoryStorageProvider class if no instance of the StorageProvider interface has been removed. Developers will need to explicitly configure this by setting the jobrunr.database.type property to mem or by providing a custom bean. Further details on this release may be found in the release notes.
Jox
The release of Jox 1.0.0, a virtual threads library that implements an efficient Channel data structure in Java designed to be used with virtual threads, features many dependency upgrades and notable changes: the removal of the collectAsView() method from the Source interface and the CollectSource class as this functionality is offered from the Flows class; and configuration of the newly integrated Renovate automated dependency update tool. More details on this release may be found in the release notes.
Micrometer
The first release candidate of Micrometer Metrics 1.15.0 provides bug fixes and new features such as: enhancements to the OtlpMetricsSender interface that provides an immutable Request inner class and a corresponding builder for convenience; and the addition of metrics for the newVirtualThreadPerTaskExecutor() method defined in the Java Executors class. Further details on this release may be found in the release notes.
The first release candidate of Micrometer Tracing 1.5.0 ships with a dependency upgrade to Micrometer Metrics 1.15.0-RC1 and a new feature that removes the dependency on the incubation of the OpenTelemetry Java Instrumentation API. (opentelemetry-instrumentation-api-incubator). More details on this release may be found in the release notes.
Project Reactor
The second milestone release of Project Reactor 2025.0.0 provides dependency upgrades to reactor-core 3.8.0-M2, reactor-netty 1.3.0-M2, reactor-pool 1.2.0-M2. There was also a realignment to version 2025.0.0-M2 with the reactor-addons 3.5.2, reactor-kotlin-extensions 1.2.3 and reactor-kafka 1.3.23 artifacts that remain unchanged. Further details on this release may be found in the release notes.
Similarly, Project Reactor 2024.0.5, the fifth maintenance release, provides dependency upgrades to reactor-core 3.7.5 and reactor-netty 1.2.5. There was also a realignment to version 2024.0.5 with the reactor-addons 3.5.2, reactor-pool 1.1.2, reactor-kotlin-extensions 1.2.3 and reactor-kafka 1.3.23 artifacts that remain unchanged. More details on this release may be found in the release notes.
Commonhaus Foundation
The Commonhaus Foundation, a non-profit organization dedicated to the sustainability of open source libraries and frameworks, has announced that Kroxylicious has joined the foundation this past week. Kroxylicious is an “early-stage project which seeks to lower the cost of developing Kafka proxies by providing a lot of the common requirements out-of-the-box.” This allows developers to focus on the required logic to get their proxies to perform their tasks.
OpenJDK News Roundup: Compact Source, Module Import Declarations, Key Derivation, Scoped Values
MMS • Michael Redlich
Article originally posted on InfoQ. Visit InfoQ
There was a flurry of activity in the OpenJDK ecosystem during the week of April 14th, 2025, highlighting eight new JEPs having been elevated from their JEP Drafts to Candidate status. Four of these will be finalized after their respective rounds of preview.
JEP 512, Compact Source Files and Instance Main Methods, has been elevated from its JEP Draft 8344699 to Candidate status. Formerly known as Simple Source Files and Instance Main Methods, this JEP proposes to finalize this feature, with improvements, after four rounds of preview, namely: JEP 495, Simple Source Files and Instance Main Methods (Fourth Preview), delivered in JDK 24; JEP 477, Implicitly Declared Classes and Instance Main Methods (Third Preview), delivered in JDK 23; JEP 463, Implicitly Declared Classes and Instance Main Methods (Second Preview), delivered in JDK 22; and JEP 445, Unnamed Classes and Instance Main Methods (Preview), delivered in JDK 21. This feature aims to “evolve the Java language so that students can write their first programs without needing to understand language features designed for large programs.” This JEP moves forward the September 2022 blog post, Paving the on-ramp, by Brian Goetz, Java Language Architect at Oracle. Gavin Bierman, Consulting Member of Technical Staff at Oracle, has published the first draft of the specification document for review by the Java community. More details on JEP 445 may be found in this InfoQ news story.
JEP 511, Module Import Declarations, has been elevated from its JEP Draft 8344700 to Candidate status. This JEP proposes to finalize this feature, without change, after two rounds of preview, namely: JEP 494, Module Import Declarations (Second Preview), delivered in JDK 24; and JEP 476, Module Import Declarations (Preview), delivered in JDK 23. This feature will enhance the Java programming language with the ability to succinctly import all of the packages exported by a module with a goal to simplify the reuse of modular libraries without requiring to import code to be in a module itself.
JEP 510, Key Derivation Function API, has been elevated from its JEP Draft 8353275 to Candidate status. This JEP proposes to finalize this feature, without change, after one round of preview, namely: JEP 478, Key Derivation Function API (Preview), delivered in JDK 24. This features introduces an API for Key Derivation Functions (KDFs), cryptographic algorithms for deriving additional keys from a secret key and other data, with goals to: allow security providers to implement KDF algorithms in either Java or native code; and enable the use of KDFs in implementations of JEP 452, Key Encapsulation Mechanism.
JEP 509, JFR CPU-Time Profiling (Experimental) has been elevated from its JEP Draft 8337789 to Candidate status. This experimental JEP proposes to enhance the JDK Flight Recorder (JFR) to allow for capturing CPU-time profiling information on Linux OS.
JEP 508, Vector API (Tenth Incubator), has been elevated from its JEP Draft 8353296 to Candidate status. This JEP proposes a tenth incubation in JDK 25, with no API changes and no substantial implementation changes since JDK 24, after nine rounds of incubation, namely: JEP 489, Vector API (Ninth Incubator), delivered in JDK 24; JEP 469, Vector API (Eighth Incubator), delivered in JDK 23; JEP 460, Vector API (Seventh Incubator), delivered in JDK 22; JEP 448, Vector API (Sixth Incubator), delivered in JDK 21; JEP 438, Vector API (Fifth Incubator), delivered in JDK 20; JEP 426, Vector API (Fourth Incubator), delivered in JDK 19; JEP 417, Vector API (Third Incubator), delivered in JDK 18; JEP 414, Vector API (Second Incubator), delivered in JDK 17; and JEP 338, Vector API (Incubator), delivered as an incubator module in JDK 16. This feature introduces an API to “express vector computations that reliably compile at runtime to optimal vector instructions on supported CPU architectures, thus achieving performance superior to equivalent scalar computations.” The Vector API will continue to incubate until the necessary features of Project Valhalla become available as preview features. At that time, the Vector API team will adapt the Vector API and its implementation to use them, and will promote the Vector API from Incubation to Preview.
JEP 507, Primitive Types in Patterns, instanceof, and switch (Third Preview), has been elevated from its JEP Draft 8349215 to Candidate status. This JEP, under the auspices of Project Amber, proposes a third round of preview, without change, to gain additional experience and feedback from the previous two rounds of preview, namely: JEP 488, Primitive Types in Patterns, instanceof, and switch (Second Preview), delivered in JDK 24; and JEP 455, Primitive Types in Patterns, instanceof, and switch (Preview), delivered in JDK 23. This feature enhances pattern matching by allowing primitive type patterns in all pattern contexts, and extending instanceof and switch to work with all primitive types. More details may be found in this draft specification by Aggelos Biboudis, Principal Member of Technical Staff at Oracle.
JEP 506, Scoped Values, has been elevated from its JEP Draft 8352695 to Candidate status. Formerly known as Extent-Local Variables (Incubator), this JEP proposes to finalize this feature, without change, after four rounds of preview, namely: JEP 487, Scoped Values (Fourth Preview), delivered in JDK 24; JEP 481, Scoped Values (Third Preview), delivered in JDK 23; JEP 464, Scoped Values (Second Preview), delivered in JDK 22; JEP 446, Scoped Values (Preview), delivered in JDK 21; and JEP 429, Scoped Values (Incubator), delivered in JDK 20. This feature enables sharing of immutable data within and across threads. This is preferred to thread-local variables, especially when using large numbers of virtual threads.
JEP 505, Structured Concurrency (Fifth Preview), has been elevated from its JEP Draft 8340343 to Candidate status. This JEP proposes a fifth preview, with several API changes, to gain more feedback from the previous four rounds of preview, namely: JEP 499, Structured Concurrency (Fourth Preview), delivered in JDK 24; JEP 480, Structured Concurrency (Third Preview), delivered in JDK 23; JEP 462, Structured Concurrency (Second Preview), delivered in JDK 22; and JEP 453, Structured Concurrency (Preview), delivered in JDK 21. This feature simplifies concurrent programming by introducing structured concurrency to “treat groups of related tasks running in different threads as a single unit of work, thereby streamlining error handling and cancellation, improving reliability, and enhancing observability.” One of the proposed API changes involves the StructuredTaskScope interface to be opened via static factory methods rather than public constructors.
JDK 25 Feature Set (So Far) and Release Schedule
The JDK 25 release schedule, as approved by Mark Reinhold, Chief Architect, Java Platform Group at Oracle, is as follows:
- Rampdown Phase One (fork from main line): June 5, 2025
- Rampdown Phase Two: July 17, 2025
- Initial Release Candidate: August 7, 2025
- Final Release Candidate: August 21, 2025
- General Availability: September 16, 2025
With less than two months before the scheduled Rampdown Phase One, where the feature set for JDK 25 will be frozen, these are the two JEPs included in the feature set so far:
Despite not having been formally targeted at this time, it has already been determined that JEP 508, Vector API (Tenth Incubator), will be included in the feature set for JDK 25.
MMS • RSS
Posted on mongodb google news. Visit mongodb google news
Die Aktie von MongoDB (WKN: A2DYB1) befindet sich ausgehend vom zyklischen Hoch vom Februar 2024 bei 509,62 USD in einem intakten übergeordneten Abwärtstrend. Mit dem am 7. April dieses Jahres bei 140,78 USD gesehenen Verlaufstief ging der Anteilsschein mit dem zyklischen Tief vom November 2022 (135,15 USD) auf Tuchfühlung. Die dort bei hohem Volumen geformte bullishe Reversalkerze (Doji) leitete eine dynamische Kurserholung bis auf 174,03 USD ein. Diesen Aufschwung verdaut der Wert aktuell und vollzog dabei einen Pullback an das 50%-Retracement. Ein Anstieg über die nächste Widerstandszone bei 162,49-164,72 USD würde nun ein bullishes Anschlusssignal im kurzfristigen Zeitfenster senden. Potenzielle nächste Erholungsziele lauten im Erfolgsfall 170,04-174,03 USD, 178,10/180,32 USD und 188,66 USD. Ein Rutsch unter die Unterstützungszone 153,48-157,40 USD per Tagesschluss würde derweil zunächst für ein Wiedersehen mit dem Supportbereich 140,78-145,85 USD und eventuell einem zeitnahen Test des 2022er-Tiefs bei 135,15 USD sprechen.
Article originally posted on mongodb google news. Visit mongodb google news
MMS • Sergio De Simone
Article originally posted on InfoQ. Visit InfoQ
Coinciding with the generally availability of sub-issues, GitHub engineer Shaun Wong shared insights about how they added support for hierarchical issue structures, the lessons learned during development, and the key role sub-issues played in their workflow.
Launched in preview a few months ago, GitHub sub-issues enable developers to organize tasks using a parent-child hierarchy. This structure helps break down complex tasks into smaller, more manageable components. Additionally, by grouping related activities in a hierarchical format, teams can track progress more effectively and provide detailed insights into how each sub-task contributes to the overall project.
For example, a parent issue can broken down into discrete sub-tasks, each assigned to a distinct team in the organization— such as marketing, UI/UX design, backend development, frontend development, and so on.
The first decision GitHub engineers faced was whether to modify the existing task list functionality or design an entirely new hierarchical structure. They ultimately chose the latter, which required significant changes to the underlying data models and rendering logic.
From a data modeling perspective, the sub-issues table stores the relationships between parent and child issues. For example, if Issue X is a parent of Issue Y, the sub-issues table would store this link, ensuring the hierarchical relationship is maintained.
One key feature was the automatic updating of a parent issue’s progress based on its sub-issues, using a sub-issue list table. This eliminated the need to manually check or navigate through the hierarchy to monitor status.
At the implementation level, sub-issues are modeled using MySQL relationships and exposed via GraphQL endpoints, enabling efficient and flexible data retrieval.
According to Wong, their internal use of sub-issues across multiple projects has proven effective in simplifying and accelerating project management.
Our teams found that sub-Issues significantly improved their ability to manage large projects. By breaking down tasks into smaller, actionable items, they maintained better visibility and control over their work. The hierarchical structure also made it easier to identify dependencies and ensure nothing fell through the cracks.
Alongside sub-issues, GitHub also promoted other previewed features to general availability several. These include issue types, which allow classification of issues as bugs, features, tasks, etc; advanced search, with support for complex queries using and and or; and an increased issue limit in GitHub Projects, now supporting up to 50,000 issues.
MMS • Steef-Jan Wiggers
Article originally posted on InfoQ. Visit InfoQ
AWS has announced the open-source release of AWS Model Context Protocol (MCP) Servers for Code Assistants, a suite of specialized servers designed to enhance AI-powered code assistants with AWS best practices. According to the company, these servers leverage AI to provide context-aware guidance to accelerate development, improve code quality, and ensure adherence to security and cost optimization principles.
The open-source release of MCP Servers for Code Assistants bridges AI-powered coding assistants (like Amazon Q, Claude, and Cursor) and AWS services – it enables these assistants to understand the nuances of AWS, offering intelligent suggestions and automating tasks that would otherwise require manual effort and deep AWS expertise.
As the authors of an AWS blog post on the open source release describe:
Model Context Protocol (MCP) is a standardized open protocol that enables seamless interaction between large language models (LLMs), data sources, and tools. This protocol allows AI assistants to use specialized tooling and access domain-specific knowledge by extending the model’s capabilities beyond its built-in knowledge—all while keeping sensitive data local.
In addition, the blog post outlines the following key benefits:
- Accelerated Development: MCP Servers significantly reduce development time by providing ready-to-use code snippets and configurations based on AWS best practices.
- Enhanced Security: MCP Servers help developers implement secure configurations, ensuring IAM roles, encryption, and security policies align with AWS Well-Architected principles.
- Cost Optimization: The Cost Analysis MCP Server provides insights into AWS pricing, helping developers make informed decisions and avoid unnecessary expenses.
- Access to AWS Knowledge: MCP Servers seamlessly integrate with AWS documentation and knowledge bases, giving AI assistants access to information.
- Infrastructure as Code (IaC): The AWS CDK MCP Server automates the generation of IaC templates, simplifying infrastructure provisioning.
By leveraging AI to provide context-aware guidance, this open-source initiative has the potential to democratize AWS expertise and accelerate the adoption of secure and efficient cloud development patterns.
In a dev.to post, AWS Community Builder Arthur Schneider writes:
In today’s fast-paced tech world, we’re constantly looking for ways to accelerate development processes while improving quality. Especially in the AWS environment, where complexity increases with each new service, we need smarter tools that make our work easier. This is where MCP comes into play – a protocol that fundamentally changes the way we interact with AI models.
Lastly, the GitHub repository or Pypi package manager provides developers with example implementations to get started.
MMS • RSS
Posted on mongodb google news. Visit mongodb google news
MongoDB, Inc. (NASDAQ:MDB – Get Free Report) was the recipient of unusually large options trading activity on Wednesday. Traders acquired 23,831 put options on the company. This is an increase of approximately 2,157% compared to the average volume of 1,056 put options.
MongoDB Stock Performance
NASDAQ MDB traded down $0.78 on Friday, reaching $159.26. The stock had a trading volume of 1,549,284 shares, compared to its average volume of 1,814,860. The stock has a market cap of $12.93 billion, a P/E ratio of -58.12 and a beta of 1.49. The business’s 50-day moving average price is $208.15 and its 200 day moving average price is $252.43. MongoDB has a 12-month low of $140.78 and a 12-month high of $387.19.
MongoDB (NASDAQ:MDB – Get Free Report) last issued its quarterly earnings data on Wednesday, March 5th. The company reported $0.19 earnings per share (EPS) for the quarter, missing the consensus estimate of $0.64 by ($0.45). MongoDB had a negative return on equity of 12.22% and a negative net margin of 10.46%. The business had revenue of $548.40 million for the quarter, compared to analysts’ expectations of $519.65 million. During the same period in the previous year, the business posted $0.86 earnings per share. On average, sell-side analysts predict that MongoDB will post -1.78 earnings per share for the current year.
Insiders Place Their Bets
In other MongoDB news, CFO Srdjan Tanjga sold 525 shares of the stock in a transaction that occurred on Wednesday, April 2nd. The shares were sold at an average price of $173.26, for a total value of $90,961.50. Following the sale, the chief financial officer now directly owns 6,406 shares in the company, valued at $1,109,903.56. This represents a 7.57 % decrease in their position. The transaction was disclosed in a document filed with the SEC, which is available through this hyperlink. Also, CEO Dev Ittycheria sold 18,512 shares of the company’s stock in a transaction dated Wednesday, April 2nd. The stock was sold at an average price of $173.26, for a total value of $3,207,389.12. Following the completion of the transaction, the chief executive officer now owns 268,948 shares of the company’s stock, valued at $46,597,930.48. The trade was a 6.44 % decrease in their ownership of the stock. The disclosure for this sale can be found here. Over the last quarter, insiders have sold 48,680 shares of company stock valued at $11,084,027. 3.60% of the stock is currently owned by insiders.
Institutional Trading of MongoDB
Several hedge funds and other institutional investors have recently made changes to their positions in the company. B.O.S.S. Retirement Advisors LLC acquired a new stake in shares of MongoDB in the fourth quarter valued at approximately $606,000. Union Bancaire Privee UBP SA acquired a new position in shares of MongoDB during the fourth quarter valued at approximately $3,515,000. HighTower Advisors LLC lifted its position in MongoDB by 2.0% in the fourth quarter. HighTower Advisors LLC now owns 18,773 shares of the company’s stock worth $4,371,000 after purchasing an additional 372 shares during the period. Nisa Investment Advisors LLC boosted its stake in MongoDB by 428.0% during the 4th quarter. Nisa Investment Advisors LLC now owns 5,755 shares of the company’s stock valued at $1,340,000 after purchasing an additional 4,665 shares in the last quarter. Finally, Covea Finance acquired a new stake in shares of MongoDB during the fourth quarter valued at approximately $3,841,000. Hedge funds and other institutional investors own 89.29% of the company’s stock.
Analyst Upgrades and Downgrades
MDB has been the subject of a number of recent research reports. The Goldman Sachs Group lowered their target price on MongoDB from $390.00 to $335.00 and set a “buy” rating for the company in a research note on Thursday, March 6th. Wedbush cut their target price on shares of MongoDB from $360.00 to $300.00 and set an “outperform” rating on the stock in a research note on Thursday, March 6th. Morgan Stanley decreased their price objective on MongoDB from $315.00 to $235.00 and set an “overweight” rating for the company in a report on Wednesday. Piper Sandler lowered their target price on shares of MongoDB from $425.00 to $280.00 and set an “overweight” rating for the company in a report on Thursday, March 6th. Finally, Daiwa Capital Markets started coverage on shares of MongoDB in a research note on Tuesday, April 1st. They issued an “outperform” rating and a $202.00 price target on the stock. Eight analysts have rated the stock with a hold rating, twenty-four have issued a buy rating and one has assigned a strong buy rating to the company. Based on data from MarketBeat, MongoDB has an average rating of “Moderate Buy” and a consensus target price of $299.78.
View Our Latest Report on MongoDB
MongoDB Company Profile
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.
Learn the basics of options trading and how to use them to boost returns and manage risk with this free report from MarketBeat. Click the link below to get your free copy.
Article originally posted on mongodb google news. Visit mongodb google news
MMS • RSS
Posted on mongodb google news. Visit mongodb google news
MongoDB (NASDAQ:MDB – Get Free Report) was upgraded by Redburn Atlantic from a “sell” rating to a “neutral” rating in a research report issued on Thursday, Marketbeat Ratings reports. The firm presently has a $170.00 price target on the stock. Redburn Atlantic’s price target points to a potential upside of 6.74% from the company’s previous close.
A number of other equities research analysts have also weighed in on the company. Barclays reduced their price objective on MongoDB from $330.00 to $280.00 and set an “overweight” rating on the stock in a research report on Thursday, March 6th. China Renaissance started coverage on shares of MongoDB in a report on Tuesday, January 21st. They issued a “buy” rating and a $351.00 price objective for the company. Robert W. Baird decreased their price target on shares of MongoDB from $390.00 to $300.00 and set an “outperform” rating for the company in a research report on Thursday, March 6th. Tigress Financial increased their price objective on MongoDB from $400.00 to $430.00 and gave the company a “buy” rating in a report on Wednesday, December 18th. Finally, Mizuho reduced their price target on MongoDB from $250.00 to $190.00 and set a “neutral” rating on the stock in a research report on Tuesday. Eight research analysts have rated the stock with a hold rating, twenty-four have assigned a buy rating and one has given a strong buy rating to the stock. According to MarketBeat.com, the stock has an average rating of “Moderate Buy” and an average target price of $299.78.
MongoDB Trading Down 0.5 %
NASDAQ MDB opened at $159.26 on Thursday. The firm’s 50 day simple moving average is $208.15 and its 200 day simple moving average is $252.43. The firm has a market capitalization of $12.93 billion, a price-to-earnings ratio of -58.12 and a beta of 1.49. MongoDB has a 1 year low of $140.78 and a 1 year high of $387.19.
MongoDB (NASDAQ:MDB – Get Free Report) last issued its earnings results on Wednesday, March 5th. The company reported $0.19 earnings per share for the quarter, missing analysts’ consensus estimates of $0.64 by ($0.45). MongoDB had a negative net margin of 10.46% and a negative return on equity of 12.22%. The business had revenue of $548.40 million during the quarter, compared to analyst estimates of $519.65 million. During the same period in the prior year, the business posted $0.86 EPS. On average, equities research analysts forecast that MongoDB will post -1.78 earnings per share for the current year.
Insider Activity at MongoDB
In other MongoDB news, Director Dwight A. Merriman sold 1,000 shares of the firm’s stock in a transaction on Tuesday, January 21st. The stock was sold at an average price of $265.00, for a total transaction of $265,000.00. Following the transaction, the director now directly owns 1,116,006 shares in the company, valued at approximately $295,741,590. This trade represents a 0.09 % decrease in their position. The sale was disclosed in a legal filing with the Securities & Exchange Commission, which is accessible through the SEC website. Also, CAO Thomas Bull sold 301 shares of the firm’s stock in a transaction dated Wednesday, April 2nd. The shares were sold at an average price of $173.25, for a total transaction of $52,148.25. Following the transaction, the chief accounting officer now directly owns 14,598 shares in the company, valued at $2,529,103.50. The trade was a 2.02 % decrease in their ownership of the stock. The disclosure for this sale can be found here. In the last quarter, insiders have sold 48,680 shares of company stock valued at $11,084,027. 3.60% of the stock is owned by corporate insiders.
Institutional Inflows and Outflows
Hedge funds and other institutional investors have recently bought and sold shares of the business. Strategic Investment Solutions Inc. IL purchased a new position in shares of MongoDB in the 4th quarter worth about $29,000. Hilltop National Bank increased its stake in shares of MongoDB by 47.2% during the 4th quarter. Hilltop National Bank now owns 131 shares of the company’s stock worth $30,000 after purchasing an additional 42 shares during the last quarter. NCP Inc. bought a new stake in shares of MongoDB in the 4th quarter worth approximately $35,000. Wilmington Savings Fund Society FSB purchased a new position in MongoDB in the third quarter valued at approximately $44,000. Finally, Versant Capital Management Inc grew its holdings in MongoDB by 1,100.0% during the fourth quarter. Versant Capital Management Inc now owns 180 shares of the company’s stock valued at $42,000 after purchasing an additional 165 shares during the period. Hedge funds and other institutional investors own 89.29% of the company’s stock.
MongoDB Company Profile
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.
Recommended Stories
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
MMS • Ian Hoffman
Article originally posted on InfoQ. Visit InfoQ
Transcript
Hoffman: My talk is also a little bit about astronomy. This is the geocentric model of the solar system. For almost 2,000 years, people believed that the sun and the planets orbit around the Earth. They had pretty good reason to believe this. They saw in the morning that the sun would rise in the east, and at night it would set in the west. They thought naturally that the sun was circling the Earth. They also noticed that the stars didn’t appear to move. You would think if the Earth was moving, then your angle relative to the stars would change. The position of the stars would be different. Furthermore, using this model, ancient astronomers were able to make actually really accurate predictions about the positions of planets. They could predict the position of planets with up to around 90% accuracy. They could use these predictions to navigate, to sail, and to create calendars. This model actually worked really quite well.
By the Middle Ages, there were some issues. This is because the initial observations they had used to make their equations stopped applying as well. They had to continuously revise the model. One real problem with the geocentric model is that sometimes planets appeared to move backwards. We understand why that is today. It’s because the Earth and the planets are orbiting at different rates. When the Earth passes by a planet, that planet appears to move backwards. If everything’s going in a circle around the Earth, there really should be no backwards motion. Ancient astronomers solved this basically by making the model more complex. What they did is they introduced something called an epicycle. An epicycle is a micro-orbit within a planet’s orbit. The planet is going around in a circle, and it’s also going like this. Essentially, by introducing arbitrary epicycles and other such constructs, we might think of them as hacks, they were able to fit this model to the observed data pretty well.
However, in around 1500, Copernicus came along. He revived the heliocentric model of the solar system. This is a model in which the Earth and the planets orbit around the sun. We know this model to be mostly accurate. The Greeks had considered this. They had decided this is clearly nuts, but Copernicus revived it. One of the reasons why he liked it is because he thought it was conceptually simpler. For instance, with this model, theoretically, you don’t need epicycles to explain backwards motion. Copernicus was hamstrung in that he thought that everything has to go in a perfect circle. This was to match his notions of Aristotelian harmony and beauty. Because of this, he had to add back epicycles.
Then Keppler came along about 100 years later. Keppler realized that planets actually orbit in ellipses. Once you allow the planet to move in an elliptical form, then the heliocentric model not only has better predictive power than the geocentric model, for the first time, but is also far simpler. At this point, the heliocentric model became widely adopted by astronomers and scientists. It was also, in part, due to observations by Galileo.
What can we learn from this as software practitioners? First off, if you have a subpar model, a model you might have for many valid and good reasons, you can make that model work for a long time if you just add arbitrary complexity to it. You can just keep adding epicycles and things like that and adding complicated code on top of your already complicated architecture. You can make it work. A better architecture will solve the same problems as an inferior architecture in a simpler way. It will also let you solve additional problems that you probably could not have solved earlier.
Therefore, it pays to sometimes take a step back and to ask, is my foundational model, are my core assumptions still valid? Are they still serving me? Are they making my life easier, or are they making my life a lot harder? As software developers, we rightfully are a little risk-averse. We like to proceed incrementally for all kinds of excellent reasons. That’s usually what we should do. We should maybe add a little complexity here and a little complexity there instead of revising the core model. I’m not advising against that. If you notice yourself solving the same issues over and again, then it’s worth taking a step back and questioning the more core assumptions that you’re making, like Copernicus did.
Background
I’m Ian Hoffman. I’m a staff engineer at Slack. Previously, I worked at Chairish. I’m going to talk about a time when we at Slack revisited our core architecture and made some big changes to it for similar reasons to why the ancients started with this model and then why Copernicus revised it.
Slack Overview
First off, what is Slack? Slack is a communication app for businesses. You can use it if you’re not a business, but it is designed probably primarily for businesses. We have three first-party clients, a desktop/web client written in Electron and React and Redux, and then iOS and Android apps. Our backend is a monolith written in Hack, which is a language like PHP. It’s like a strongly typed, just-in-time compiled version of PHP. Most of our data is stored in MySQL databases sharded using the Vitess sharding system. This is what Slack looked like circa 2015 or something like that.
Slack’s V1 Architecture (The Workspace Model)
I’m going to begin by talking about the evolution of Slack’s architecture in order to motivate the changes we made. Then I’ll describe what the changes we made were, why we made them, and then how we went about making these changes. Finally, I’ll close with some takeaways. Slack began in 2013 with a pretty simple architecture that I like to call the Workspace Model, though it does not have an official name. In this model, a Slack workspace is equivalent to a Slack customer. A workspace contains users, channels, messages, apps, all the things you’re used to in Slack. Slack is this channel-based communication platform. You can enter a channel and send a message to other users who are in that channel. This is all contained within one workspace. Slack also has this concept of apps, which are third-party apps that developers can build and run in Slack. For instance, a bot that you can use to triage tickets from Jira, for example, or to look at issues in GitHub, you can run that in Slack.
Importantly, in this model, each workspace is a closed system. Workspaces share nothing between each other. That means if I, Ian Hoffman, I’m a human being and I have access to multiple Slack workspaces, Slack doesn’t know anything about that. These are separate logins. It’s not one account. This has a nice property, which is that the data for a single workspace can be put on a single database shard.
Basically, the server will route queries from a workspace to a shard. If you want to scale up, you just buy more databases and put more customers on them. We have this core assumption that the data for a single customer would fit on a single database shard. Maybe we have to buy a really big database, but we can still serve all of their traffic with one database. That’s because in the beginning, Slack was targeted at teams with maybe a hundred or maybe a thousand people. The chance of them producing so many messages and channels and just so much data that we couldn’t handle it on like an extra-large MySQL instance, seemed unlikely.
First off, I’ll walk through an example of how this worked in a little more detail. Let’s imagine you have a third-party app that you’ve built as a developer. Let’s take the GitHub app as an example. This lets you do GitHub-y stuff in Slack. That means the Slack client has to find out about this. It’s going to make a REST API call in order to load information about the GitHub app. How this works is the client makes an API call to the server and it has this token. It tells the server, I want to load the GitHub app. It uses this token, which is encrypted and authenticated. The token has a user ID and a workspace ID in it. The server then takes this workspace ID and it knows how to map that workspace to a specific database shard. It’s going to look on that shard for the GitHub app. If it finds the app on that shard, then great, the client is allowed to use the app. Otherwise the app is not installed for that workspace. It’s not allowed. That’s an error. This worked pretty well, but there are some problems.
One I was already hinting at, which is, what if the data for one customer doesn’t fit on one shard? This began to happen because Slack caught on much more than people originally expected. Soon enough, we had customers with 10,000 or 100,000 users sending millions of messages.
At that point we started to really knock over databases. Also, what if customers actually want multiple workspaces? There are all kinds of reasons why a large enterprise might actually want to partition their organization into multiple workspaces, because workspaces act as content boundaries. You can say, I want these employees to have access to this stuff and these employees to have access to this stuff, but I want to administer them as a unit. I want to handle billing in one place. I want to handle security in one place. I want to manage users in one place. That’s impossible to provide if there’s nothing shared between workspaces. We wanted to solve these problems, and we were also running into these scaling issues of just our customers getting too large and workspaces having too much traffic.
Slack’s Architecture V2 (Enterprise Grid)
To solve this, we made our model a little bit more complicated, just like the ancients introduced these epicycles. We introduced our Enterprise Grid architecture in 2017, which was our enterprise product. It’s interesting to note that actually the Workspace Model is still basically how Slack works for our smaller customers. For the really big fish, of which there are many, the Enterprise Grid model became a significant product that we sold a lot of. In Enterprise Grid, a customer can have many workspaces, all under the umbrella of their grid, of their enterprise. A user can belong to many of those workspaces, all within the enterprise. Are any of you aware of a company you work at using Enterprise Grid, or have you used this product? This is what I’m describing here.
Finally, data, such as like channels and apps and that sort of thing, can be shared across multiple workspaces. You can say, I want an announcements channel that is available in every workspace on my enterprise. This makes disseminating data throughout your Slack instance much easier than if you were trying to manage multiple totally isolated workspaces, as people were doing priorly. This is how Enterprise Grid looked. You can imagine this DF, JE, SM, these are just like design mockup nothings, but imagine these are all workspaces under the Acme, Inc. Enterprise. If you’re looking at DF, you’re only seeing data from DF, and same goes for the other ones. You have to switch between these workspaces in order to see everything that you can access within the enterprise.
The architectural implications here. The way we made this work is to say, we have these workspaces, and we’re going to have one special secret, invisible workspace, that serves as the org, the parent of all these other workspaces. Just as the data for each workspace is on its own shard, the data for the parent org is on its own shard too. What is org-level data? It’s any data that is shared. Anything that should be available to the entire organization, or entire enterprise, we use these words interchangeably, but anything that should be available to the whole org lives on the org shard.
Basically channels, apps, that are shared with more than one workspace go on the org shard, and everything else goes on the workspace shards. Now that you can find things in two places, how do you successfully route queries? We did something very simple, which the backend just now queries the current workspace shard and the org shard, always. We just always do two queries. Theoretically, this should decrease the load on any one workspace shard, because now instead of customers with one gigantic workspace, they probably partition their large workspace into many more focused workspaces, therefore spreading out the data and the load across these different workspaces. Here’s another beautiful architectural diagram. It’s not really on par with the models of the geocentric and heliocentric solar system from earlier. I’ll go through the same example again.
In this example, we’re going to load the GitHub app. Again, we pass up this authenticated token. It has the user. It has the workspace. Again, we query the workspace shard. This time, let’s say that this is an app installed on the org level. Let’s say it’s available to the entire org. This time, we find, it’s not available for the workspace. What do we do? We load the org ID for that workspace, assuming the workspace is part of an org. We get back the org ID, and we now route that org ID to a shard. We’re looking now for the GitHub app on the org shard. If we find it, again, we return it to the client, and we let the client use it. What this means is that any workspace under this org will end up querying the same org shard. This is a simple way of making that org-level app available to all the workspaces.
This model works really well, and Enterprise Grid became a really successful thing for Slack, but there were some problems that I’ll now go through. First off, there were some UX issues. When we conceived of Enterprise Grid, the users really belonged to one workspace on average. We weren’t really building something to handle a situation in which one user was in several workspaces, all within the same Enterprise Grid, and had to switch between them to do their work. As Enterprise Grid matured and more companies started to use it, people ended up in more than one workspace within the grid.
Actually, I’ll ask, of people here who use Enterprise Grid, do you know if you’re in more than one workspace? It’s quite common these days. That meant people had to switch between their workspaces to do their work. They would miss activity in workspaces they looked at less. We tried to fix this by introducing hacky things like a threads view and an unreads view, that actually aggregate org-wide data, but within the view of a single workspace. Here is the unreads view, and you can imagine that if this help customer support channel comes from a different workspace than Acme Sites, if you click on it, you would be bounced into that other workspace, which would be jarring. At least it would let you see everything in one place, and so it represented a slight improvement over the prior approach.
There were also bugs. One really interesting bug here is that there were inconsistent views of org-level data. Imagine a channel, like an announcements channel, that’s shared across all the workspaces on an organization. If you’re an administrator in only one of those workspaces, you can modify the channel so you can rename it when you’re looking at it from that particular workspace. When you switch to a different workspace, you now can’t. As a user, this makes no sense and it’s hard to explain to people. That was one persistent class of issues. Also, I’ve described how Slack’s backend, we partition our data by workspaces.
The data for a particular workspace is stored on a shard, on a database server for that workspace. We do the same on clients, actually. We take data from each workspace and all that data is completely separate on the client. It’s not munged together in any way. We have separate client-side data repositories for each workspace, even though you might be looking at multiple workspaces on the same client, you might be logged into several workspaces under your grid. What this means is that things can get out of sync because if you fetch org-level data for one of those workspaces, or let’s say for a few of those workspaces, you’ve now ended up loading this org-level data into the datastores for each of those workspaces.
Now you change it in only one of those workspaces, the one you’re currently looking at, and that update, for whatever reason, might not make it to those other workspaces. Then you’re looking at a stale view when you switch to the other workspace. We fixed a lot of these bugs, but they were inherent in the model. In the fact that you have these multiple views into the same piece of data, there’s always a chance for things to get out of sync. We had to be really vigilant to prevent this bug from reemerging.
Also, this model is just not the most efficient. If you have an org-level piece of data, you’re going to load it again in every single workspace you look at. For example, DMs are org-level. That means every time you go to a workspace within the grid, we’re reloading your DMs. That’s just enormously wasteful. It’s also a larger memory footprint. I was just talking about how we were duplicating org-level data into these workspace-partitioned data repositories on the client. That also just causes memory bloat. We did build an org-level datastore that lets you store org-level data in one place, but this took time to adopt. Slack is an interactive system, so it’s not just the client querying the backend, the backend will push updates to the client.
The way the backend does this is it maintains WebSocket connections for each workspace. Some of our customers actually have thousands of workspaces. That means whenever you make an org-level change that should impact all the workspaces, it has to be fanned out across thousands of WebSocket connections. This is inefficient. Eventually, we built an org-level WebSocket to fix this, but again, that was not widely adopted and took time to adopt. We felt like we were running up against this class of issues where there were these persistent UX problems, there were persistent user experience bugs and confusing bugs of the multiple perspectives bug I talked about earlier, and then there were just inefficiencies with this model too where we were doing a lot of redundant work.
Changing the Model
We decided that maybe we’d been going about this the wrong way. In 2022, we took a step back and we reconsidered some of our core assumptions here, like Copernicus did. We’re on a far lower plane than him, just to be clear. We asked the foundational question, which is, why should users view data from only one workspace at a time? What if you could see everything you needed in a single place? If you’re a user, why do you really care where a channel comes from as long as you know you have access to that channel? Wouldn’t this be a simpler experience? If we had this model, there wouldn’t be any context switching between workspaces because there are no workspaces. There wouldn’t be any missed activity, or at least no missed activity in different workspaces, because, again, there are no workspaces. You can’t have inconsistent views of org-level data because you’re only getting one view of your data.
There can’t be duplicate API calls, because, again, you’re only getting one view of your data. You’re not switching between workspaces. You’re not storing redundant data on clients because you only need to store the data once. You don’t need to store it per workspace anymore. We felt like this nicely simplified a lot of the issues we were running into with Enterprise Grid. We felt like this was also a better foundation for the product to continue evolving. Though Slack had started off with this Workspace Model and had started off being highly all about workspaces, we had moved in a more org-level direction over the years.
A lot of our new features like Canvas, which is our document editor, and Lists, which is like Google Sheets, and of course DMs are org-level by default. These are things that are available across the whole org. It was a weird experience to switch between workspaces but always see the same canvases, the same lists, the same DMs. Giving you an org-level view matched the direction that Slack has been evolving in any ways.
Slack Architecture V3 (Unified Grid)
With this, we introduced our v3 architecture, which I call Unified Grid. In Unified Grid, the user can see everything they can access within the enterprise in one view. However, access control is still determined by workspaces. The workspaces still act kind of like ACL lists, limiting what you can see. Importantly, Unified Grid does not change what users can do. It doesn’t actually change anything about the permissions model. It just reorganizes things in a quite fundamental way. You’ll remember, this is what Enterprise Grid looked like, and this is what Unified Grid looks like. Here you can see that we’ve reclaimed this sidebar, which used to show one tile per workspace. We now can use the sidebar to show other useful things, like all your DMs, all of your activity across all workspaces, your later feature, which is like a to-do list or a set of reminders. You can see within this Acme Inc., channel list, you can imagine that we’re incorporating channels from multiple workspaces all under Acme Inc.
How did we do this? In Unified Grid, the API token no longer determines the workspace shard. You’ll remember in all those prior architectural diagrams I showed, we were passing up the current workspace ID when we were making an API call to the backend. How do we select the workspace to put in that token when we’re in Unified Grid? There is no current workspace. We would have to pick arbitrarily. We don’t do that. Instead, we include the ID of the current org. You’ll remember the org is just a secret hidden workspace. We’re including that ID. Now the server needs to check both the org shard and also multiple workspace shards, because the data we’re looking for could be found on the org shard, as before, or it could be found on the shard for some workspace. We don’t know which one, because you’re looking at everything at once.
This sounds really non-performant, obviously, and we were, of course, a little bit concerned about this. It turns out that we can limit the workspaces that we check to just those that the current user is a member of. Most users are still in just a handful of workspaces, maybe three or four at most. This check ends up being fairly efficient. There is a long tail of users who are in hundreds of workspaces, but it turns out that most of these users are system administrators. They’re not actually using Slack and all those workspaces. They just need to administer them, and that means they really need to get to the admin site for those workspaces, which requires them to be a member of the workspace. The way we handled this was to say, we’re basically going to consider 50 workspaces when we do this check every shard logic, and we’re going to let you edit this list. It’s confusing, but this affects a minuscule subset of users, like we’re talking point something-something.
This strikes a good balance between handling these extreme outliers and allowing us to move forward with this architecture. This is an even more complicated diagram that I’ll go through. Same example as before, we want to load information about the GitHub app to display in Slack. We make an API call, but you’ll notice that this time we’re using the org ID. This E789 number is in the token instead of the team ID. That means that we end up querying the org shard first. We say, is this app installed at the level of the org? Let’s say that it’s not. Let’s go back to our first example where the app is actually just installed for one workspace. We get a miss on the org. The next thing we’ll do is we’ll load up all the workspaces for the user, and that’s a cache hit in memcache, 99.99% of the time. Then with that list, we’ll loop over every workspace, and we’ll query its shard. We’ll query at most 50 workspaces here, if that’s how many the user is in, but commonly we’ll query 3 or 4.
We strongly believe this offered a better user experience, and actually a better developer experience too, and just got rid of this concept of the workspace that was becoming increasingly vestigial, and moved things to be on the org level in a way that really matched the direction we wanted to go at Slack. It was of course a very large change. We were concerned that Unified Grid would be dead in the water from the start. To give you some stats, we had well over 500 API methods that depended on a workspace for routing.
What this means more concretely is that these were API methods that were called by a Slack client, a first party client that would be changing in Unified Grid, would be switching from using the workspace to the org, and that we’re routing to a database table where that routing depended on the workspace in the API token. You can imagine that any of those APIs/all of them, could break if we stopped including the workspace in that token. We also had over 300 team settings which could differ at the workspace level. This is a setting where for the same setting, you could have different values for each workspace on the org. There was a question of like, how do you rationalize that in one view? Each of these settings would need to be handled on a case-by-case basis basically, where we had product teams deciding what made sense for that setting.
Then, any backend change we made need to be replicated on all three clients. We were essentially doing 4x the work listed above. However, we didn’t want to take this all on at once, that would be crazy. We decided to begin with a prototype. We built a very simple prototype that could basically boot up, send a message, and show the messages in a channel. We began to use this prototype for our day-to-day work. We made it really easy to turn the prototype on and off with a single button. If you ran into an issue, you would just exit the prototype, keep doing your work, mark down that issue somewhere, and then when you had time, go and fix it.
At a certain point, we invited peers to start using the prototype, and they began to give us feedback. A really useful piece of feedback we got here is a focus mode. Some people missed having this per-workspace view, because they wanted to focus on only content from a particular workspace. Maybe they don’t care what’s going on in the social workspace today. This is a view where you can actually filter down your channel list to just channels from specific workspaces in the Slack client in Unified Grid. Eventually, as the prototype matured, we invited leadership to use it. At this point, leadership came on board, and Unified Grid became a top priority in January 2023.
At this point, the core team pivoted from prototyping into attempting to projectize what we were working on, creating resources and tools that other teams could use to help with this large migration. The first tool, which is very exciting for everyone, I’m sure, was a bunch of spreadsheets. We created spreadsheets just listing every API method and permission check and workspace setting, which might need to be audited as part of Unified Grid. As I mentioned earlier, we had data about which APIs were called using a workspace token, and then use that token to route to a particular table. All of those APIs were, of course, fair game.
Then any permission check they ended up making needed to be looked at, too. Any setting they looked at had to be checked, and all the way down the rabbit hole. Once we had these in place, we worked with project managers and subject matter experts to assign them to various product teams. We also created a bunch of documentation to make it easier for these teams to do this migration. We worked out these approaches during the prototyping phase, so that was another really invaluable part of prototyping, was we got a sense of how hard this migration was going to be. We realized that there were actually three primary tactics to migrate an API to be compatible with Unified Grid. This is a little bit of a sidebar, but several years ago, a Slack engineer named Mike Demmer came to QCon, and he spoke about our Vitess migration. He was also the architect of Unified Grid.
The Vitess migration was a change in which we moved away from this per-workspace, per-org sharding model, to a more flexible sharding model. We’re using Vitess, which is this essentially routing layer for MySQL. We could re-shard tables along more sensible axes. For example, we re-sharded our messages table, such that all the messages for a particular team, or a particular workspace, are not on that workspace’s shard. They’re now sharded by the channel ID. It’s now that all the messages for the same channel are on the same database shard. This is a much more sensible sharding strategy for messages, because it’s unlikely that one channel has too many messages for a database shard. You can easily imagine that one workspace has an incredible amount of messages in it.
The good thing about this is that if a table had been re-sharded, such that it no longer depended on the order of the workspace ID, then it didn’t have to change in Unified Grid, because we were already routing based on something that wasn’t going to change, because we were changing this API token from containing the workspace ID to the org ID, and that doesn’t affect how these queries are routed. There’s another class of API which actually requires workspace context. At Slack, every channel is created within a specific workspace. We could have revisited that for Unified Grid, but we decided not to. We decided that that’s still a decent baseline. In the past, the workspace in which to create a channel, would just be determined by the workspace you were currently looking at. If you’re in a workspace, that’s the workspace where you create the channel.
In Unified Grid, of course, there is no current workspace. We made this really simple. We just made this implicit decision explicit, by popping up literally a dropdown menu and having the user pick a workspace when they go to create a channel. Finally, if the API doesn’t fall into either of these buckets, so it’s still sharded by workspace ID or org ID, and it doesn’t require this more explicit context, then we do the strategy I described earlier where we have to check all the users’ workspaces potentially in this potentially expensive manner.
This was obviously a really big change, and with large changes, things can break. We wanted to make sure that we had good test coverage. Over 10 years of Slack existing as a product, we have written thousands of integration tests, probably more. We didn’t want to rewrite all these tests, and we also didn’t want to lose the coverage they provided. What we did is we created a parallel test suite that runs all of these tests, but it automatically switches the workspace context to the org level. The APIs suddenly began to receive an org, and they, of course, all break. This gave us a burndown list, and our product teams fixed them during the migration, which was very kind of them. By the time that we launched, there were actually zero tests failing as a result of this anymore. This allowed us to avoid rewriting our test suite and to still have pretty robust coverage.
Finally, we did some basic things like create easy-to-use helpers just wrapping up common logic. You know how I described earlier this bug in which you could administer a channel only from a workspace where you were an admin, and if you switched to another workspace with access to that channel where you weren’t an admin, you couldn’t administer it? What that means is that in the old Slack client, in Enterprise Grid, you could simply click through your workspaces until you found one where you were an admin, and then you could administer the channel. We do this for you. We just have a helper that says, can the user act as an admin for this channel? It takes the user, it takes the channel, it intersects their workspaces.
If the user is an admin in any of those workspaces, then the answer is yes. With this, we got to do something very gratifying, which was watch a shard go to zero as product teams jumped in and began to burn down these APIs and permissions checks and settings. We began our rollout in September 2023, and we finished in March 2024. We forced an upgrade of the last pre-Unified Grid mobile clients this October, so quite recently.
Takeaways
What did we learn from this whole process? Some of these takeaways will be more mind-altering than others, probably. First off, you should really centralize complexity. You might look at this and say, isn’t this a simpler model? This is our v1 architecture. Isn’t this a lot simpler than this? This seems like a step backwards. I think the counter argument is that we now handle such a broader range of use cases for our customers, and we’ve centralized complexity on the backend. Before, customers and clients and users had to think about things like, what workspace am I in? Now, they don’t anymore. While we’ve made things harder for the backend, we’ve made them simpler for clients.
In fact, in some ways, we’ve made things easier for backends, too, because the server now explicitly has to handle the possibility that something is in an arbitrary workspace. Whereas, before, the current workspace was always implicit in every operation. You can view an action prior to Unified Grid as a function of the current user, the resource, and implicit workspace. Whereas, in Unified Grid, we’ve made that explicit by saying the action is a function of the user and the resource, and that’s it. This could also be an example of explicit is better than implicit.
In terms of efficiency, the fastest API call is one that doesn’t happen. This is pretty anecdotal, but this is the calls required to boot the Slack client for a user in January 2022, prior to Unified Grid, versus January 2024. In Unified Grid, API calls can take somewhat longer, because they need to do more things. You’ll note that we make many fewer API calls. This client.counts API is the API that paints highlights on the sidebar. It figures out which channels have unread things and that sort of thing. We make almost twice as many calls to it priorly for this user, within their enterprise. Then, the boot API, we replaced our boot API, which is called client.boot, with an API called client.userboot. Doesn’t really matter. We make four times fewer API calls in Unified Grid as we made priorly. Even though each of those API calls is a little bit heavier, this is like a massive saving overall.
Also, you should really prototype. Prototyping is a great way to get feedback, to figure out if something is going to be feasible, to work out the rough edges of the UX. To bring it back to our friend Copernicus, his initial model was not so great. It was maybe an improvement on the geocentric model, but it had all kinds of problems. By putting this theory out there, he allowed people like Galileo and Keppler to make significant progress and to eventually make this model become accepted. If you don’t put your big ideas out there, and a great way to put them out there is with a working prototype people can play with, then they’re not going to become reality, ever.
Finally, take a step back and ask the big questions. For example, does the Earth actually orbit around the sun? Also, is our architecture serving us? I think as engineers, we, as I said in the beginning, can be a little averse to change. We like to make small incremental improvements. I think a way in which this manifests is that we often take the status quo that we’ve received as dogma. We say the product behaves like this, there must be a good reason why it behaves like this. We’re using this set of technologies, there must be a good reason why we’re using these technologies.
Often things that made a ton of sense several years ago, have changed for all kinds of valid reasons. When you’re considering how you might improve the architecture of your application just to solve real issues you’re facing, you should be empowered to question these holy cows. To like Copernicus and Keppler, take a step back and say, what is the inherited wisdom we’re just following, and what can we change to make our lives easier? Then, how can we make that change responsibly?
Questions and Answers
Participant 1: After all the lessons you’ve learned from those three models, and the path that you followed to get to where you are right now, is there anything that you’ve learned from failure that you would change?
Hoffman: At the time that Enterprise Grid was built in 2017, it wasn’t like we were unaware that we could have built something like Unified Grid instead. Given what we knew about the way users used Slack, we felt like it wasn’t worth it at the time, and given the pressure we were under as well. I wouldn’t say that we should have gone back and done that differently. I do wonder if we were to do it all over again, if we would consider like having just a more first-class person entity in the way that Discord does. I also think there’s some real advantages of having total separation between data for different customers. Given Slack is so business focused, I don’t know if that ever would have flown. Maybe we would have been bolder a little bit earlier and done this a little bit earlier.
Betts: Do you feel like you had to introduce those epicycles from Enterprise Grid before you realized it was so wrong?
Hoffman: At the time we did Enterprise Grid, it was the pragmatic thing to do. I think in retrospect, it certainly did increase complexity. Also, at the time, at least from a user experience standpoint, the average user was really in just one workspace within their org. It was really hard to justify the investment that reducing that complexity would have taken at the time. Again, maybe we could have started down this path a few years before we did. Though we were doing incremental things, like things like the Vitess migration made this so much easier to do than it would have been in 2017.
Participant 2: Do you do any sharding for the WebSockets connections to make sure that you efficiently push data to all of the relevant WebSockets connections?
Hoffman: I don’t know a ton about how our RTS system works under the hood. There’s a whole team that works only on that. In Unified Grid, we attempt to push most data to the org-level socket only. That means it just gets pushed to one place. For workspaces, we do check whether that workspace is online. The RTS server has an understanding of which workspaces are currently connected. Then we can avoid pushing to workspaces. This is for users. This is how users work. Users can be off or online, and users have their own sockets as well. That’s for users. For workspaces, I think they always get all pushes because they’re always online in some capacity.
Participant 3: Did you face resistance in part of the technical teams? Because I bet you faced them. There are always some of the engineers, maybe the older ones, which are protecting somehow the previous solutions because they feel like it’s theirs, it’s something which works, it’s not worth changing it. Did you face anything similar?
Hoffman: We didn’t face that much resistance from engineering teams within Slack. I think the prototype was a really big reason of why we didn’t. Because people began to use it, and it became something that people liked. One thing I left out of here too is that, every few years, Slack does a total UI revamp, it’s our IA series. We’ve had information architecture 1, and 2, and 3, and now 4. We managed to combine forces with this UI revamp. We said, we’re changing the UI in this fundamental way, let’s use this as a chance to do Unified Grid as well. Once we had both design and product pushing for this, and then also a significant portion of engineering, I think it was pretty easy to get buy-in at that point. There were certainly individual engineers who were like, I don’t want to work on migrating code for three months, but they were overall pretty accommodating about it.
Participant 4: Beyond the requirement from product, what about the financial side? Did the cost go up after changing to the more complex system?
Hoffman: I don’t know. I have not seen overall numbers for this. I think on first principles, we would expect the cost to remain stable or go down, because we do less traffic than we used to do. It’s possible the cost went up somewhat.
Participant 5: I’m curious for the question of, is our architecture still serving us and making decisions for either smaller steps and incremental changes, or big revamps? What information makes these conversations easier?
Hoffman: I think having lots of examples of things where the architecture has made things hard. All the similar bugs we had been fixing around inconsistencies and people seeing actions they could do in some channels and not others and not understanding this. There had been entire projects to consolidate API calls so that we weren’t redoing them for every workspace. All those projects failed because they were so complicated and they didn’t change the overall model. It made them even harder to ship, because you were changing the underlying architecture without changing the user-visible architecture. I think at a certain point, it was like, wouldn’t it be easier to just fix all of this at once? At that point, we were able to get buy-in. In some ways, I think if we hadn’t been running into these issues, it would have been very hard to make a pitch for this.
Participant 5: It’s more of a backward-looking data we have up-to-date.
Participant 6: In your presentation, you showed the older architecture and you just moved to the current one. Did you consider any other architectures? Because when you’re prototyping, you don’t know the outcome, unless with the production data and everything. Some prototypes will work well when there is a smaller subset of data, but when it is production, you have a large subset, sometimes the architectures go sideways. Did you consider any other architectures, like how did we make a decision?
Hoffman: We did. We considered an architecture where actually instead of just doing Unified Grid for the grid, we had user-level Unified Grid. You literally saw everything you could access in one place, whether or not it came from the current enterprise. If I was in a workspace for work and a workspace for my apartment building or whatever, that would all go in one place. A little bit more like the Discord model or something, where it’s one user getting access to everything. We decided that was counter to Slack’s position as an app that’s primarily focused on businesses.
See more presentations with transcripts