Month: February 2025

Article originally posted on InfoQ. Visit InfoQ

Security can be at odds with a fast and efficient development process. At QCon San Francisco Dorota Parad presented how to create a foundation for security without negatively impacting engineering productivity.

Traditionally, security is all about defense, Parad said. We focus on stopping the attackers, so we put obstacles in place to stop them. These very same obstacles often get in the way of our own employees as much, if not more, as the malicious actors, she mentioned.

Considering software development, engineers have the power to bring our whole system down, so it’s not much of a mental jump to treat them as a source of security risk, Parad argued. But it’s the same engineers who make the system run and release the features that keep our business going:

Putting too many obstacles in their way means slowing down our value delivery, which in the long run costs the business more than a security incident would.

Parad mentioned that there is the tension between security and productivity, which traditionally gets resolved by an unsatisfying mixture of security theater and lax security posture, all dressed up as “compliance”. In that situation, no one wins except the attackers, she added.

Parad presented a framework she created, called BLISS, which helps implement security without negatively impacting engineering productivity. BLISS stands for bulkheads, levels, impact, simplicity, and pit of success:

• Bulkheads let you limit the blast radius of security incidents through separation and isolation.
• Instead of applying a single, strict strategy to everything, have different levels of protection proportionate to the level of risk.
• Focus on minimizing the impact of the incidents instead of just limiting the probability.
• Keep your processes and tools simple to make them easier to secure.
• Create a pit of success, where it’s so easy to do the right thing that it happens by default.

This way, you can make your security strategy almost invisible to the engineers while embedding it deep into the culture at the same time, Parad said.

Focusing on minimizing the impact of breaches can be more effective than trying to prevent the breach in the first place, Parad said. What security teams often overlook is that modern software development already includes a lot of ways that make a successful attack less likely compared to the early days of the internet. CI/CD pipelines, ephemeral test environments with automated tests, code reviews, serverless infrastructure are just some of the examples, she explained:

I’m not saying we should completely ignore prevention, things aren’t so black and white. From what I see in the industry though, security teams often overindex on measures intended to prevent breaches, and that’s ineffective.

None of these offer full protection, but when we consider them all together, they create a baseline that’s good enough, Parad said. At that point, trying to reduce the likelihood of a breach tends to bring diminishing returns, so it makes sense to look at the impact side of things.

Assume every part of your system is going to get compromised at some point; it’s not a matter of if, but when, Parad said. She suggested thinking about what you do so that an event doesn’t turn into a total catastrophe.

InfoQ interviewed Dorota Parad about improving security and productivity.

InfoQ: What can be done to improve both engineer productivity and security?

Dorota Parad: An example is logging in with Single Sign On (SSO) instead of having to use multiple usernames and passwords. Not only is that easier for the user – no need to remember or type in that annoying password every time, it’s also more secure.

Any time you make a part of your development process simpler or more robust is going to be a productivity win; we all understand that intuitively. What’s less obvious is that those same optimizations tend to improve security as well. If it’s automated, it’s fewer places for a malicious actor to use social engineering to get access. Fewer steps in a process mean fewer attack vectors. Removing tools from our tool chain means fewer things to break and fewer vulnerabilities to patch.

InfoQ: You highlighted the importance of “bulkheads” to limit the blast radius of incidents—what are some practical ways teams can achieve this?

Parad: It’s all about the separation: separate git repositories with separate access controls, separate deployments, cloud accounts, databases, and so on. I always say security starts with the architecture and how well you can achieve that separation is going to be constrained by your architecture choices.

If you have a monolith where everything has to be deployed all together into a single cloud account, you’re going to be pretty limited on where you can place your bulkheads. But even then, having a separate instance for each customer will offer some way to limit the blast radius in the event that one instance gets compromised.

Ideally, we want a modular architecture with different parts of the system deployed and operated independently. That way, if one part becomes compromised, it doesn’t automatically mean the whole system is.

Posted on mongodb google news. Visit mongodb google news

Los Angeles Capital Management LLC acquired a new stake in MongoDB, Inc. (NASDAQ:MDB – Free Report) in the fourth quarter, according to the company in its most recent disclosure with the Securities and Exchange Commission (SEC). The fund acquired 37,641 shares of the company’s stock, valued at approximately $8,763,000. Los Angeles Capital Management LLC owned approximately 0.05% of MongoDB as of its most recent filing with the Securities and Exchange Commission (SEC).

A number of other large investors have also modified their holdings of the company. Hilltop National Bank increased its stake in shares of MongoDB by 47.2% in the 4th quarter. Hilltop National Bank now owns 131 shares of the company’s stock valued at $30,000 after purchasing an additional 42 shares in the last quarter. Brooklyn Investment Group purchased a new stake in shares of MongoDB in the third quarter valued at approximately $36,000. Continuum Advisory LLC raised its stake in shares of MongoDB by 621.1% during the 3rd quarter. Continuum Advisory LLC now owns 137 shares of the company’s stock worth $40,000 after buying an additional 118 shares during the period. Versant Capital Management Inc raised its stake in shares of MongoDB by 1,100.0% during the 4th quarter. Versant Capital Management Inc now owns 180 shares of the company’s stock worth $42,000 after buying an additional 165 shares during the period. Finally, Wilmington Savings Fund Society FSB purchased a new position in shares of MongoDB during the 3rd quarter valued at approximately $44,000. Institutional investors and hedge funds own 89.29% of the company’s stock.

Analysts Set New Price Targets

MDB has been the subject of a number of research analyst reports. Piper Sandler restated an “overweight” rating and set a $425.00 price objective on shares of MongoDB in a research report on Tuesday, December 10th. Rosenblatt Securities assumed coverage on shares of MongoDB in a research report on Tuesday, December 17th. They set a “buy” rating and a $350.00 price target for the company. Oppenheimer lifted their price objective on MongoDB from $350.00 to $400.00 and gave the stock an “outperform” rating in a report on Tuesday, December 10th. Macquarie assumed coverage on MongoDB in a research note on Thursday, December 12th. They set a “neutral” rating and a $300.00 price objective for the company. Finally, Canaccord Genuity Group raised their target price on MongoDB from $325.00 to $385.00 and gave the company a “buy” rating in a research report on Wednesday, December 11th. Two research analysts have rated the stock with a sell rating, four have given a hold rating, twenty-three have given a buy rating and two have issued a strong buy rating to the company. Based on data from MarketBeat.com, MongoDB has a consensus rating of “Moderate Buy” and an average price target of $361.00.

Read Our Latest Research Report on MDB

MongoDB Price Performance

Shares of NASDAQ:MDB traded down $5.89 during midday trading on Thursday, reaching $262.41. 1,388,930 shares of the company’s stock were exchanged, compared to its average volume of 1,489,873. The stock has a market cap of $19.54 billion, a price-to-earnings ratio of -95.77 and a beta of 1.28. MongoDB, Inc. has a fifty-two week low of $212.74 and a fifty-two week high of $449.12. The firm’s 50 day simple moving average is $261.95 and its two-hundred day simple moving average is $274.67.

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

Insider Buying and Selling at MongoDB

In related news, CEO Dev Ittycheria sold 8,335 shares of the company’s stock in a transaction that occurred on Tuesday, January 28th. The shares were sold at an average price of $279.99, for a total transaction of $2,333,716.65. Following the sale, the chief executive officer now directly owns 217,294 shares of the company’s stock, valued at $60,840,147.06. This represents a 3.69 % decrease in their position. The sale was disclosed in a filing with the Securities & Exchange Commission, which is accessible through this hyperlink. Also, Director Dwight A. Merriman sold 3,000 shares of the firm’s stock in a transaction that occurred on Monday, December 2nd. The shares were sold at an average price of $323.00, for a total transaction of $969,000.00. Following the completion of the transaction, the director now directly owns 1,121,006 shares of the company’s stock, valued at $362,084,938. This represents a 0.27 % decrease in their position. The disclosure for this sale can be found here. Insiders have sold a total of 41,979 shares of company stock valued at $11,265,417 over the last quarter. 3.60% of the stock is owned by company insiders.

MongoDB Company Profile

(Free Report)

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

Featured Articles

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

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

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

View The Five Stocks Here

As the AI market heats up, investors who have a vision for artificial intelligence have the potential to see real returns. Learn about the industry as a whole as well as seven companies that are getting work done with the power of AI.

Get This Free Report

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

Article originally posted on InfoQ. Visit InfoQ

Microsoft recently introduced a quantum chip called Majorana 1 powered by a new Topological Core architecture. The company claims it’s the world’s first Quantum Processing Unit (QPU).

Majorana 1 leverages what the company calls breakthrough material that can observe and control Majorana particles to produce more reliable and scalable qubits, which are the building blocks for quantum computers. In a press release, the company states:

In the same way that the invention of semiconductors made today’s smartphones, computers, and electronics possible, topoconductors and the new type of chip they enable offer a path to developing quantum systems that can scale to a million qubits and are capable of tackling the most complex industrial and societal problems.

The topoconductor, or topological superconductor, creates a unique state of matter that enables the development of stable, fast, and controllable qubits without the trade-offs of existing alternatives. A new study in Nature details how Microsoft researchers created and accurately measured the properties of topological qubits, an essential advancement for practical computing.

In a Microsoft blog, Chetan Nayak, technical fellow and corporate vice president of Quantum Hardware, writes:

Our measurement-based approach dramatically simplifies quantum error correction (QEC). We perform error correction entirely through measurements activated by simple digital pulses that connect and disconnect quantum dots from nanowires. This digital control makes managing the large numbers of qubits needed for real-world applications practical.

However, some researchers are critical of the company’s choice to publicly announce the creation of a qubit without releasing detailed evidence. Georgios Katsaros, a physicist at the Institute of Science and Technology Austria in Klosterneuburg, comments in a Nature article:

Without seeing the extra data from the qubit operation, there is not much one can comment on.

Microsoft’s top conductor comprises indium arsenide (a semiconductor), a material with unique properties currently utilized in applications such as infrared detectors, and aluminum (a superconductor). When cooled to near absolute zero and tuned with magnetic fields, topological superconducting nanowires with Majorana Zero Modes (MZMs) are formed at the wires’ ends. MZMs are the building blocks of Microsoft’s qubits.

(Source: Microsoft Blog Post)

Berci Mesko, a medical futurist, tweeted on X:

Here is Microsoft’s new quantum chip called Majorana 1 that could help realize quantum computers capable of solving meaningful, industrial-scale problems in years, not decades.

Imagine the impact quantum computers could have on healthcare, especially in drug design and diagnostic decision-making. No, we cannot even imagine that. It would bring the impact of AI into a new dimension. I’m not overhyping the technology. This is the scale we have to keep in mind for quantum computing.

Lastly, the Defense Advanced Research Projects Agency (DARPA) has selected Microsoft as one of two finalists in its Underexplored Systems for Utility-Scale Quantum Computing (US2QC) program, part of the broader Quantum Benchmarking Initiative (QBI), which aims to assess quantum systems capable of tackling challenges that classical computers cannot.

Article originally posted on InfoQ. Visit InfoQ

Transcript

Fike: I’m hoping you all can help us settle something. We’ve been trying to figure out something between us. She thinks she’s right. I think I’m right. We figure, there’s a bunch of very clever engineers out here. Let’s see who they think is right. The decision we’re trying to make is turning out to be a little more controversial than we’d expected.

Martell: Historically, we’ve built our systems using Django. Our monolith uses it. A lot of our standalone services use it too. We’ve got a new team. They’re looking at bringing up a new service, and they really want to use SQLAlchemy instead. My take on this is that Django will meet their needs and do the job, and it’s good to keep a consistent approach across our teams and projects.

Fike: I don’t disagree with this sentiment, but Django is a whole web framework. It’s so much more than we need. We use it today to build REST APIs and legacy SSR pages, but this team just needs an ORM. Asking future hires to ramp up on an entire web framework just for that seems excessive. It’s like trying to plant a rose bush with a bulldozer.

Martell: I don’t disagree, but I just don’t think it’s the right take in this case. Can you help us out?

We’re not here to talk about Django, or SQLAlchemy, or any ORM. We’re here to talk about the debate, the decision, because this decision, like most hard decisions, doesn’t have an objectively correct answer. It depends.

Fike: This is always the answer, it depends.

Martell: We weren’t even talking about the feature sets of these different technologies. Do we need something that supports Postgres specific column types? That could be an input to this decision. Instead, we were talking about the principles and the people. It’d be a lot easier if we only had to deal with the technology, because the principle and the people’s problems, that’s when it gets real sticky. Getting all the priorities and context into a room and ensuring that it’s considered can be a lot of work, and in my experience, sometimes just pretty frustrating.

Often, you go through all this work. You talk to all these people, and you end up just making the same decision. Maybe you feel a little bit better about it, but the more time you spend in these debates, the more likely it is that everyone’s going to walk away saying, we don’t have an engineering strategy. What we want to talk to you about is some changes we’ve made to how we work at Carta, to consolidate the inputs to these decisions and empower our engineers to drive outcomes with higher conviction and in less time.

Background

My name is Shawna Martell. I’m a senior staff engineer at Carta.

Fike: I’m Dan Fike. I’m the Deputy CTO at Carta.

We are the creators of a program at Carta that we call navigators. Navigators are essentially individual contributors that we task with applying and evolving our engineering strategy. The real core thesis behind navigators is that it exists to empower our individual contributors to lead, to do their best work, and to land better outcomes for themselves and the company. I imagine some of you are here trying to develop leadership skills in yourselves and others might be here trying to develop it in your peers and your teams.

Some others, like Shawna and I, are probably here for a bit of both. Shawna and I are both individual contributors in fairly different leadership roles, and we’ve taken very different career paths to get here. We have both seen and participated in several past attempts to make decisions more quickly. Nothing has worked as well as what we are doing now, which is why we want to talk to you about some of these past attempts we’ve seen and why they failed. We want to talk about what we’re doing instead. Why it’s working. What we’ve learned along the way. What you can do to recreate this.

The Importance of Leadership in Decision-Making

Martell: If you’re building software of any complexity, or you’re selling software in any complex business space, your life is invariably filled with questions where the only correct answer is, it depends. Do we need a relational database or a non-relational one? Do we want to buy this off the shelf or build it ourselves? Can this procedure be eventually consistent or not? Do we want to move fast and accrue some tech debt or do it right the first time? Do we want a monolith or microservices? Are we going to push or pull?

Fike: It depends.

Martell: You said it depends. What does it depend on?

Fike: It depends on a lot of things. It depends on how much it’s going to cost. It depends on your time to market and other business goals. It depends on the existing architecture patterns in play today. It’s going to depend on the staffing of the team, their skill set, and who’s going to be the long-term owner of this. It’s going to depend on your performance requirements and your failure tolerance. I’ve seen architecture decisions decided by whether or not our support staff observe daylight saving time.

Martell: It depends on a dozen things. Which one is most important?

Fike: It depends.

Martell: This is why leadership is so important. So much about leading is making decisions. What do we do? We put on our leadership hats, and we do some research and we make a decision. How does that play out in practice? On my experience, it’s often countless documents and meetings. Then, in the really worst-case scenarios, you end up in a situation where the meeting is actually about the document and not the decision, or you’re negotiating the decision-making of others.

Often, you find yourself chasing consensus, and consensus can get pretty hard, especially as your organization grows. You either need to get a representative from all your teams into a room, and that doesn’t scale particularly well once you have dozens of teams, or you have to slowly build your sphere of consensus over time. How does that look? Probably looks something like this. You got to get some time with Sarah, because she’s the real influencer in SRE, but Mike from infra, he’s going to have some input too.

Based on his feedback, you have to go back to Sarah. Then go talk to Omar. His product’s going to have a bunch of work, but you need he and Mike to really iron out a few of these details. You can’t forget about Jill in product. You can spend weeks, if not longer, building this plus one at a time consensus tree, and then by the time you’re done, half the people you talk to don’t remember you ever talked to them.

I’m being a little bit cheeky here, but like consensus, it can be a pretty big time sink. Sometimes you get to the end of this exercise, only to realize no one actually agrees on who the final decision maker is. I’ve seen this a lot in my career. I’ve also seen several examples of companies trying to streamline this path to consensus, and very frequently it takes some form of committee. In one case, it was literally called the Jedi Council.

Fike: I’m a big Star Wars fan, and even I found this one really hard to believe.

Martell: Dan, I find your lack of faith disturbing. This isn’t an obviously silly idea. It’s got a lot going for it. It’s really clear who you need to convince. The decision makers, it’s pretty plain. You can even get time with them during their biweekly review hour or whatever, to bring your proposal. It has some drawbacks too.

Sometimes it ends up being a thing you have to go present your proposal to get promoted or to establish your clout. It can be really hard to know how much context to bring to the committee, because you don’t know how much context they need. I’ve even seen cases, especially in larger organizations, where you can end up waiting weeks to get a slot, and maybe you’re blocked that entire time because you don’t have the committee’s blessing yet.

Carta Engineering Architecture Review, and Engineering Council

Fike: We’ve tried a few simpler versions of this at Carta. When we were smaller, we had something called the engineering architecture review. This was a periodic meeting where some engineer would throw a proposal onto the agenda, they’d show up, and all of our most senior engineers from different products would just show up and weigh in and offer feedback.

The idea was, if you can get the blessing from that crew, if you could get them happy, you were probably making a good decision. Anybody want to venture a guess how that played out? In practice, consensus was just impossible, and it was really unclear how to make a decision in light of that. Slowly, engineering architecture review just became the place where neat but controversial ideas would go to die. People started just finding a way to work around it entirely. We scrapped that, and we put together something we instead called the Carta Engineering Council. This is another council.

This was a smaller group, and it was curated to have a specific membership that included some staff-plus engineers and some VPs and some managers from around the company. The idea was, instead of them having this de facto role of saying no to bad ideas or just ideas they couldn’t agree on, they were explicitly tasked with saying yes to good ideas. They saw a lot of ideas and got a lot of questions. You can see some examples up here. There are conversations around tech debt, conversations around new technology and best practices.

If anybody was building something complex across team boundaries, where they typically would find themselves unsure who to consult or who makes a decision, who approves it, the council existed in theory to provide those answers. In practice, your council members were too far from each other in their day-to-day work, to actually have any shared principles that inform their decision-making, and they were often too far from the work that was being discussed to actually participate in the discussion very effectively.

When you don’t have the right context to critique an idea, you often fall back on critiquing the proposal, like the document and its structure and stuff like that. The Carta Engineering Council wasn’t as destructive as the engineering architecture review of the past, but it wasn’t terribly helpful either.

Engineering Strategy

Martell: This whole time, Carta was going through a lot of change, changes in leadership, rapid growth. We were outgrowing our monolith, acquisitions. The list really goes on. All of these changes made it harder for our engineers to make decisions with conviction. The tools we had to offer them left a little bit to be desired, and we found ourselves in this position again, where folks were saying, we don’t have an engineering strategy.

It turns out that this is actually the root of our problem, even when we knew, ostensibly, who could decide something. Without some set of shared principles, that decision could, at best, feel arbitrary or unfair, and at worst, just never get made at all. It means when we say it depends, folks don’t know what all it depends on or how to resolve those dependencies. We did something that probably seems pretty obvious at this point, we wrote an engineering strategy.

Fike: I can hear some of you saying, “I thought this was a talk about navigators, not strategy”. You are in the right place. Navigators works at Carta because of our strategy. I know some of you hear the word strategy and are going to picture very different things in your head. Let me go ahead and tell you what strategy means to us, because a strategy is not a vision and it’s not a plan. A vision is just an outline of where you want to be in the distant future, whereas a strategy, these are the real principles in play that you can apply to help move closer toward that vision.

A plan is just the actual work you’re going to do. Ideally, the vision is going to inform your strategy, and you employ the strategy when building your plan. I know it gets pretty abstract talking about strategy. Here are some concrete examples from ours. If you look at that first one, it’s actually pretty easy to imagine architecture decisions and sequencing decisions that are more or less made easy by trying to pursue that. To put it very simply to the engineering organization at large, our engineering strategy, it’s just the principles and guidelines that drive our decision-making.

Martell: We did have an engineering strategy. We were making decisions, weren’t we? Even if we’d just been flipping a coin on every decision, which I can assure you we weren’t. We were making decisions underpinned by some principles. If we had been flipping a coin, wouldn’t have been fair to say our strategy was to spend no time making decisions, and just go-go-go.

Fike: There are probably people who maybe think they don’t have a strategy, but in reality, the strategy exists only implicitly or culturally. We would argue that that’s not enough. There’s a lot of power in simply writing it down. Half of the value in writing it is going to come from the writing process itself. It really forces you to think deeply and critically about why this is the right principle for your company.

Since good writing pursues brevity, it also forces you to differentiate between the principles that actually provide valuable decision-making characteristics and those that might just be your opinion. Lastly, if you write it down, it gives you something to argue about. I’m only half joking. You might think that you and your peers and your teams are very aligned, but you would be surprised at how much misalignment is going to surface just by simply trying to document this.

Martell: Most importantly, once we’ve written it down, it allows us to elevate our ideas, to give voice to the engineering organization itself. This isn’t just your opinion. This is the company’s opinion. Instead of engineers needing to ask, what does Matt or Karen think about this? They can ask, what does the company think about this? Additionally, once it’s written down, it becomes much easier to communicate changes, because your strategy will change over time.

Fike: We’ve never written anything quite like this, especially at an organization with 400 people. When we set out to do this, we started doing research, looking for prior art. How have other people approached this in the past? One of the things we came across was this guy, Will Larson. He’s written extensively about engineering strategy.

This really jumped out at us, because Will Larson also happens to be the guy who literally wrote the book on staff engineering. We subscribe to so many of his thoughts on IC leadership, and frankly, you should too, that we really took his direction on engineering strategy to heart, and we sought to apply his learnings.

Martell: This whole time while we were doing this work, we were actually between CTOs. In a lot of ways, it was up to a small group of us to put this together. Then, a few months later, we got a new CTO, it was Will Larson. You can imagine how validating that felt.

Fike: Will’s perspective is actually an extension of Richard Rumelt from his book, “Good Strategy Bad Strategy”. As such, our strategy really has three primary components to it. The first is the diagnosis. This is really describing your current situation. What’s working well, what’s working poorly? You’ll see an excerpt from ours on the right there, just to serve as an example. The second component, this is where the real guidance is. These are an outline of the principles that underpin our decision-making.

Ideally, these follow from the diagnosis. The third component, this is really an enumeration of any actions that we want the organization to take holistically, to either apply or maybe even just enable that guidance. Sometimes a strategy might only have guidance and no action. That’s totally cool, too. As we put this together, we were really focused on what we were doing today. When we looked around, as you might imagine, there are one or two areas where maybe things weren’t working quite as well as we’d hoped, where maybe in the past, we’d seen some of the wrong things get prioritized in our decision-making.

We were very tempted to fix that, to create guidance that would explicitly prevent that. We knew, if our engineering strategy was a wish list of how we could imagine the company operating in some alternate universe, it would be viewed as merely aspirational or unrealistic. The engineers in the organization are likely to reject or dismiss it as vaporware. We sought instead to just document reality. How are we making decisions today? What are the principles being applied today?

If we were making decisions with a coin flip, which again, we were not, we should write that in the strategy, and we should feel properly ashamed by it. Once this status quo strategy is out in the wild and the controversy had started to settle, now we could start to enact changes incrementally, where the before and after is very clear, and the rationale for the pivot is well explained.

Martell: Our example here in maintaining the status quo in v1 was around how we’re breaking out services from our monolith. We’d spent so much time thinking about what not to do, which was grow the monolith. We hadn’t spent enough time understanding what we expected people to do instead. At the end of the day, our operating principle there really ended up being, do what works for you.

Fike: Before we rolled this out to the organization, more broadly, we got a couple other staff-plus engineers in the room together in person with our new CTO, really to finalize the details and pick out a couple strategic follow-ups we’d want to land. You can see some notes here. As an illustrative example, know that one of the things we wanted to do was extend the engineering strategy after release with some guidance around how we build platform technology.

One of our other takeaways from that gathering was that we can’t just drop some strategy docs into Slack and ride off into the sunset and consider our job done. We recognize that it can be difficult to understand how to apply that strategy in every team, that there are often going to be edge cases where the strategy doesn’t work as intended. One of the pieces from these original notes that I do want to call out is that we knew we needed to identify some individual contributors around the company that would act as local guides to help other teams interpret and apply that strategy.

Navigators – How it Works

This is really where the idea of what we call navigators was born. How is this going to work? How do we actually make this look? We found ourselves recalling two patterns we’d seen previously, one of which was this concept of what Netflix calls an informed captain. They describe it really well on their website.

For every significant decision, Netflix identifies an informed captain of the ship who is an expert in their area. They are responsible for listening to people’s views and then making a judgment call on the right way forward. We avoid decisions by committee which would slow us down and diffuse responsibility. It is sometimes challenging and always important to identify up front who the informed captain is for a project. We really liked this.

The second thing we recalled that we really liked was this blogpost from Martin Fowler’s blog back in 2021 titled, scaling architecture conversationally. The main takeaway is that the author was advocating that decisions should be made locally on teams. They should be free to act with autonomy, so long as they first satisfy a duty to seek advice. We wanted the autonomy from the Fowler article supported by a well-defined, explicit advice giver, such as an informed captain, but with adherence to a central strategy. This is navigators. It might sound like another word for a committee. It’s not a committee, and I’ll explain why.

In a committee, generally, the strategy would be centralized, and all of this domain and context would be decentralized. Some poor engineer would be responsible for bringing that context to the committee, where it gets combined with a strategy and a decision comes out.

Instead, with navigators, we don’t send the context to where the strategy is. We send the strategy to where the context is. Navigators are already members of the teams they support, and every team is in scope for exactly one navigator. This navigator maintains alignment with that central strategy. They combine it with the domain context and technical context they already have, and they make a decision locally. It’s all decentralized.

Martell: It’s one thing to decide what we want navigators to be. It’s another to decide who we want them to be. I think the best way to describe this is to show you how we roll this out to the organization. Let me highlight just some of the really important parts of this document. How about we dig in to our core thesis? I want to break this into three really important pieces. The first piece here, we talked about this a lot already, it’s really important that our navigators maintain an alignment with our engineering strategy.

The second, we’ve talked about this a bunch too. This is around how we want to boost velocity and reduce our reliance on consensus. The third part, though, this we haven’t really talked about yet. Here we’re discussing what it means to be a good navigator. Navigators are existing technical leaders. They already have deep technical and domain context, and we trust their judgment, but we’re equipping them with a new tool, the engineering strategy. With that new tool, we’re also offering them an extension of the CTO’s authority in their teams.

The CTO is going to hold them accountable for how they use that authority. We’ve decided at Carta that all of our navigators are going to be ICs and not managers. In our experience, giving this type of authority and autonomy to your ICs is uncommon, but we would encourage you not to underestimate your engineers. A sufficiently senior IC can take their deep understanding of the technical details and combine it with a pretty well-informed understanding of the organization more broadly.

Their lens is going to be different from your managers, who are focused, or at least more focused on teams and execution rather than software and systems. We believe that this IC perspective is a critical component in making decisions in software, and not just architecture and design decisions. Carta expects managers and navigators to work together as a team with complementary perspectives. We talked about this at the very beginning.

Most technical decisions aren’t just technical so managers and navigators understand collectively our technical and people constraints and use that information to guide their teams. We find that it makes both the navigator and the manager more effective in their role. To that end, we do expect our navigators to help make technical decisions with their teams about what we build and how we build it. They’re not expected to micromanage every design or implementation, and they shouldn’t be writing every design spec.

They do need to stay close enough to their teams to understand decisions that might conflict with the engineering strategy, and stay close enough to the strategy and the intent behind it to know how to resolve those conflicts. Maybe the engineering strategy is wrong or lacks an exception. Our navigators are best equipped to understand those things and escalate as needed.

Fike: I would wager, some people think this sounds like a bit of a promotion. What do you think?

Martell: I don’t blame you if you think so. In our experience, that’s not how this has played out. For the most part, the folks that we made navigators were already doing this work in their teams already. It’d be hard to convince me you’d be a great navigator if that weren’t true. We really changed these three things for the folks that we made navigators.

We established a well-defined point of contact that even folks outside of their teams were well aware of. We created the opportunity for smoother working relationships with navigators across the organization. Through their very tight alignment with the engineering strategy, they were now given the authority of the CTO within their teams.

Fike: I put up a slide earlier that said we wanted 12 navigators. I also said we had 400 people in the organization, and full coverage, everyone has a navigator. If you do some reasonable math, the manager has 10 engineers. That would be 36 navigators. We do, in fact, only have 12. I wish we had fewer. The challenge in trying to keep this group small is really rooted in having teams that are very siloed, or they operate with some unique context.

In one place in the organization, we had an existing individual contributor, technical leader in an organization of about 60 engineers who had pretty good context on what was going on over there, that was easy. Elsewhere, I had a team of about five people who have a niche skill set and are working on unique data problems. In that situation, I really have two choices. I can add one more navigator to the collection with a relatively narrow scope, or I can find an existing navigator and stretch them over that area to avoid growing the group.

You will find examples of both amongst our navigators. It’s really a balancing act between the effectiveness of any single navigator forced to ramp up on a new area and hold context, and the effectiveness of the navigators collectively, where too many and it becomes hard for those navigators to maintain an effective relationship with each other, and it becomes hard for them to work together to iterate our strategy.

Martell: Navigators are a really important part of the future iterations of our strategy. We’ve already talked about, navigators are the result of our engineering strategy. They’re also the interpreters of our engineering strategy, and we expect them to help us iterate it going forward. This creates a virtuous cycle. The example for us here was around those items we talked about adding to our engineering strategy that were specifically focused on platform technology.

Our navigators being the senior tenured ICs that they are, had seen enough examples at Carta of platform gone wrong and platform gone right to have deep insights into how to help us repeat past successes while avoiding past mistakes. All strategy is inevitably going to be a balance between global optimization and local optimization.

For some teams, it’s almost certainly going to be worse locally. Our navigators are best positioned to identify and help their teams navigate these edge cases, ultimately working to improve our strategy. It also means that no single navigator is quite positioned to own the strategy in its totality. We definitely don’t want it to be blocked by consensus. We talked before about how expensive consensus can be. We would recommend that your strategy be owned by your executive, a CTO or an SVP. I’m going to keep saying executive, but it doesn’t have to be the CTO.

Really, any senior leader can own your strategy. Your navigators are going to be a resource to that executive, helping them understand how to, over time, iterate the strategy. Also, your CTO or your executive is going to be a resource to the navigators. We’ve been incredibly fortunate to have a CTO that works really closely with our navigators, and that’s created a relationship that’s symbiotic, making everyone better in their role. It’s honestly a unique group in my almost 20 years of working, and one that I’m incredibly proud to be a part of.

Fike: I totally agree with that. We’re about a little over a year into it now. We’re on our second cohort of navigators. Shawna, how do you think it’s going?

Martell: Pretty good. It’s not just us who think so. We’ve gotten really great feedback like this. Decisions going from months to days is quite literally exactly what we were going for. I know it’s one thing to throw up this mostly anonymous quote and be like, going great. I’m going to tell you a story of a before and after to show you how this has changed our decision-making. Let’s rewind all the way back to the beginning. Should we use Django or SQLAlchemy?

This is a real decision that I had to make several years before we were talking about navigators or engineering strategy. I’m going to tell you the truth. I talked to so many people, and I spent so much time making this decision. In the end, I think I made the wrong choice. We deviated from the common Django model, and we used SQLAlchemy instead. With the benefit of hindsight, and now our engineering strategy, I would go back and change this if I could. I want to contrast that with a decision that we had to make after navigators and engineering strategy.

One of the teams that I was responsible for navigating was discussing building a new platform service. We were encountering a problem we’d seen a few times previously, and it really didn’t take that much imagination to imagine it showing up in some other domain in the future. The team was excited to dig in and solve this problem once and for all. It’s true, there were a lot of surface area similarities, but when you dug into the details, it seemed to me there was enough deviation that a platform wasn’t immediately obviously the right choice.

In a pre-navigator’s world, I was going to spend a bunch of time, and I was going to talk to a bunch of people building consensus around the idea of not building this platform. I was also going to have to convince people who in the world the final decision makers were. In a navigator’s world, as the navigator equipped with our strategy, I could very easily say, no, we weren’t going to build this platform because it wasn’t aligned with our strategy.

It actually wasn’t aligned in several different ways, but I’m going to highlight just one of them here. This was trying to be a one-size-fits-all solution: solve it once for everybody. Carta had decided that wasn’t how we wanted to start new platforms.

Fike: I really like this example, for a number of reasons. First and foremost, it’s very clear who the decision maker was. You also had documented guidelines to inform your decision-making. You could hold that decision up against the engineering strategy to show others how it was and wasn’t aligned. You didn’t have to litigate or relitigate the principles that inform that decision. You could just weaponize the platform strategy.

Martell: In a lot of cases, navigators can resolve these issues in their teams, like in this case. If there are cross-team concerns, we expect both navigators to be involved. This cropped up for us last year just as ChatGPT was taking off. Our data team and our SRE teams were misaligned on how to ensure that our engineers could prototype with the software while not running afoul of our data handling policies.

The two appropriate navigators got into a room, and they were able to find a direction pretty quickly. If they hadn’t been able to gain alignment, then we would have expected them to escalate. Escalations are actually a really important part of how navigators navigate. I know that word has a negative connotation. Something gets escalated, then something went wrong.

Fike: Wrong? It means something went right.

Martell: When you’re trying to increase the velocity of your decision-making, escalations are actually really great. Our intention is to inject strategy locally, so that we can decide things locally. That’s not going to work in 100% of cases. You’re going to have decisions that involve the tradeoffs of business priorities of multiple teams, and that’s something that navigators alone can’t fix. Those types of decisions need to go to someone with a wider field of vision, so you need to escalate. Give it to somebody who can reconcile misaligned incentives or competing business goals. The quicker you escalate to that person, the quicker you’re going to get a decision.

Fike: As often as we’ll find navigators escalating up to our executive, interestingly enough, we’ll also find our executive escalating to our navigators. Maybe escalating isn’t quite the right word there. If the executive found themselves in a unpleasant phone call with a very high profile customer, or if they’re hearing incompatible stories from different parts of the organization, a navigator can actually be immensely valuable as a direct resource for that executive.

They’re not uniquely capable of doing so, but the navigator’s existing relationship with that executive, their well-defined area of scope in the business, and the confidence that that executive has in their deep technical context can give that executive a very accelerated path to the answers and action that they might need, following those events.

Implementing Strategy (Strategic Thinkers and Navigators)

We talked about a lot of stuff so far. Consensus, bad, strategy, good, navigators, useful. Maybe some of you are thinking of trying it yourself. How do you go about that? We would encourage you, no matter whether you’re an IC or an executive, wherever you are in the organization, start by writing down your engineering strategy and make sure it reflects the truths in play where you are today. Take the wish list that might come up along the way and set that aside.

After you’ve got this out, then it’s time to start identifying some concrete follow-up actions. These can be actions that are part of the strategy, or things you’re going to want to do in like v2. If you’re an IC out there, you can just work on a team strategy. This doesn’t have to exist only for the entire engineering organization. Remember, when you’re writing, half of the value comes from the writing process itself.

After all, writing is organizing your thoughts. If you’re having trouble figuring out where to get started, look back, look at decisions you’ve seen made already. Why was tech debt acceptable in situation A and totally unacceptable in situation B? Dig into that and understand the principles that are informing these decisions. This is going to help you understand what your strategic guidance should be, and maybe where it needs to change going forward. We mentioned earlier, we got a lot of guidance from Will Larson before we started this.

The most valuable piece of guidance we got from him at all was to just do it. I’m going to shamelessly quote him, “Start wherever you are, and start now”.

Martell: I can assure you, if you’re looking for reasons not to get started, they will be absolutely everywhere. You will be missing context and information, and that’s ok. You’ll be surprised at how much you learn just by getting started. You’re also going to have pages of stuff that looks like this that you end up just throwing away later. We have so much stuff that didn’t make the final cut. Some of it was just aspirational and unrealistic. A lot of it was simply broad and unactionable.

If we’re being really honest with ourselves, some of it was just us pontificating. If your strategy doesn’t help you make decisions, it’s not strategy. Maybe you still want to write it down, but write it down somewhere else. This is one of my favorite examples of something we just cut, only accrue tech debt intentionally. I agree with that sentiment completely, but if you’re already having a discussion around tech debt, you surely have at least formed some intentionality.

If you aren’t, writing it down in this document probably wasn’t going to change that. We couldn’t see how this was going to substantially change our decision-making, so it didn’t make the final cut. If you’re the IC on the team and you’re writing the strategy, congratulations, you are also now the navigator. Ask yourself, how can my strategy inform my team’s decision-making? You have a new tool in your toolbox now, use it, and show other people how to use it to make decisions.

Once you have a few examples of your strategy informing your decision-making, empower your manager to encourage other teams to write a strategy too. This can work from the ground up, especially if you can show results, because I’ve never met a manager who didn’t want to hear about better, faster decision-making.

Fike: If you’re an executive or a senior manager out there, you’re probably already aware of who the people are in your organization who are strategic thinkers, who are supporting the company more holistically, get them together and collaborate on a strategy with them. If they’re included in the process, if they have more ownership over this strategy, they will be more aligned with it, and they will be more effective at implementing it in their teams.

These ICs, these are probably your first batch of navigators, and you should see how far you can stretch them, maybe further than you have in the past. After you’ve done that, now it’s time to find some other folks to fill in the gaps, but only if you’re confident in their ability to align with that strategy, to collect new context, and to demonstrate good judgment.

Martell: We understand that the navigator’s pattern has some risk with it. You’re putting a lot of trust into these ICs to make decisions with autonomy, and it’s a lot of responsibility. It’s another reason why this accountability piece is so important. Your executive needs to be prepared to hold these folks accountable for their decisions, and another reason we think it’s important to keep this group pretty small. You won’t get it right the first time or the second time, and probably not the 10th time either. We took two-and-a-half months to get this from idea to launch, and we’ve been iterating it ever since. Success is finding ways to adapt as your organization learns and grows.

Recap

Fike: Essentially, a written strategy and a dedicated group of individual contributors can really help us skip out on consensus and accelerate decision-making. That same group of individual contributors can help us iterate that strategy and act as a very valuable resource to your executives in other ways. At Carta, we have found this to be very transformational in how we work.

Questions and Answers

Participant 1: How easy is it to form staff engineer in Carta, the navigators?

Fike: Staff engineer is almost like an orthogonal axis on how we think about these. We do have levels that go up through staff engineer. Most of our navigators, not all of them, are staff engineers. There’s definitely a lot of intersection in what constitutes a good staff engineer versus what constitutes a good navigator.

Generally speaking, a staff engineer is going to be accountable to the team for some outcomes in slightly different ways. Navigator’s jurisdiction really starts and ends around the engineering strategy for the company. It’s the reason we call them navigators and not cartographers. They are there to follow a map that they’ve been given and ensure that it works well, and surface areas where it doesn’t. They’re not going to be making decisions beyond that.

Their authority doesn’t extend outside of the context of what the strategy is really espoused to cover. Staff engineers are going to have slightly different roles. We put up earlier, navigators are not micromanaging every decision, and they’re not writing every tech spec. I don’t think staff engineers should be doing that either. It’s closer to what a staff engineer role might be in a team, in that they have accountability beyond what the strategy says, and more locally, to even things the strategy is indifferent about.

Participant 2: In your company, how do navigators work together? How do they collaborate, or do they at all? Because you could say, they work in different teams. They are the decision makers that apply the company strategy in their respective teams. Maybe there’s no need for them to even talk to each other, but I assume they do. How do they work together? What does the relationship look like?

Martell: It depends. It is the truth. When we have things that cross team boundaries, the expectation is that both navigators would be involved in making that decision. It’s a place I go when I have something that I’m trying to align with the engineering strategy and I want a second opinion. We don’t work as a collaborative. This isn’t a cabal. We’re individuals that work within our teams, but we are people who work together to answer strategic questions and place to get advice. It’s a place that also our CTO will come to us for advice.

As far as like, do we work together in a committee and have lots of meetings and stuff? We don’t. It depends on the individual situation. I talk to other navigators at least every week, if not every day, about something.

Fike: From a process point of view, there’s a navigator Slack channel, and that’s really it.

Participant 3: How would you compare this role to enterprise architect or technology architect?

Fike: In much the same way I was talking about staff engineers earlier, architects are going to have obligations beyond what the strategy is covering. For example, the Django and SQLAlchemy example we put up earlier, the strategy does have an opinion on that, because of Django’s existing presence in Carta.

If somebody was building some new service to do something, we’re writing Java code, and we need to understand the right way to represent timestamps and deal with time zones, because there’s 45 ways to do that in Java. How are we going to do it in our process?

The strategy does not care. Somebody should care. Somebody should try and pursue consistency locally for that. Architects, or even tech leads are well suited to do that. I think that there’s a world where the way that tech leads and navigators work with managers ideally looks the same. I don’t think all tech leads do. We all have examples out there, counter examples. I think good tech leads will interoperate in much the same way we’re trying to establish our navigators do, in terms of collaborating with managers to take in context that’s beyond the technology.

Participant 4: One of the things that I’ve seen when we’ve done something similar, or we’ve tried something similar, is that actually maintaining that strategic alignment between these types of people becomes quite difficult, particularly if they come from different backgrounds or radically different parts of the company. What are your tips and tricks for actually getting that alignment?

Fike: It’s not always easy. I’m not going to say tense, but it’s not always easy. We haven’t really had many examples of needing people to disagree and commit, and that’s in large part because our navigators tend to be people who are tenured and understand a lot of the rationale behind what we’ve done. We haven’t had someone we hire recently coming in without the deep Carta context, and then we throw this responsibility on them. We have had some disagree and commit, although it’s usually more about the surrounding decisions around how this strategy gets applied, as opposed to the raw principles therein.

The raw principles are pretty well agreed upon. Part of how we get that to work is by avoiding the stuff we might be tempted to put in there that’s just opinions. I have a lot of opinions about how maybe we should do something differently, or one way or another. That does not belong unless these are truly dealing with some diagnosis we’ve established around what’s working well or working poorly at the company. It’s short. It’s succinct. Our entire engineering strategy document is two pages.

Participant 5: I was wondering about the concept of scalability of this idea of just making a group not too large? For a couple of hundred people, that might work, but what happens when the company grows to thousands or tens of thousands of people? What is your feeling on that?

Martell: I think we feel pretty confident that we’re not totally sure. We haven’t done this at an organization any larger than the one that we have. This is me talking off the cuff, imagining how it might work. It could very well be that, instead of having a group of navigators that, in our case, really is very closely aligned with our CTO, that you have lots of individual groups of navigators that stay closely aligned with their engineering executive. Maybe it is an SVP. I used to work at an organization of 120,000 people, which is more.

What I imagine if we had tried to get navigators there, there’d be a little bit more localized groups that did adhere to engineering strategy that maybe does come from the top, but actually has its own individual strategies in their pockets of the world. We do even see that at Carta. There are individual teams that have their own strategy documents that inform their localized decision-making.

Participant 6: Is there a relation and how does it work with product managers, with product development by the navigators, or there is no relation and they don’t show up with that?

Martell: There’s no official relationship that I can think of in anything we have written down. I’ve historically worked on a few different teams as their navigator, and in 100% of cases, I was also dealing with our product folks. I think that at Carta, it tends to be that our senior engineers do generally work with our product folks more than in some of the other companies that I’ve worked.

There are definitely senior engineers who are not navigators that work very closely with their product counterparts. It’s something that I think actually is very refreshing at Carta that the engineering and the product stay pretty well aligned, at least in my experience. It’s not unique to navigators.

Fike: I actually think that the reason our navigators are working so closely with product is because they’re existing technical leaders, they’re really good senior engineers, and all of them should be close to product.

Participant 7: I think what you’ve shared is very interesting. In my opinion, it’s within the spheres of engineering. How does that play out when you bring in the business side of things, when you bring in the priorities that this is really something we should be working on now, not later? Were there any showdowns between the navigators and the product managers? How does engineering strategy play alongside with product strategy, if there’s such a thing, at Carta?

Fike: One of the main reasons we wanted to establish this engineering strategy to begin with, is to help settle these debates. When I tell a product manager, actually we need to slow down and build this right, I have the voice of the executive in the strategy that is written for the whole engineering organization, to wheel in that conversation. It no longer becomes, this product manager assuming I’m just an engineer who likes to do things one particular way.

It becomes, no, this is a very deliberate calculated move on behalf of engineering to say that this particular audit logging, we must have audit logging, or some security thing. It’s established and proven, this is something we need to do. There are things we didn’t put in the strategy explicitly because we actually might want them to bend toward product a little bit more. That’s ok.

Martell: In the example that I mentioned where I ultimately had to say no to a proposed platform, that original idea actually had come from our product organization. We had to have a conversation about why that particular approach was not going to be the solution to this problem. I was able to use the engineering strategy as my tool there.

See more presentations with transcripts

Article originally posted on InfoQ. Visit InfoQ

Now generally available, GitHub Copilot Extensions allow developers to use natural language to query documentation, generate code, retrieve data, and execute actions on external services without leaving their IDEs. Besides using public extensions from companies like Docker, MongoDB, Sentry, and many more, developers can create their own extensions to work with internal libraries or APIs.

The GitHub Marketplace already offers a couple of dozen extensions covering a wide range of development-oriented services. For example, you can use the Stack Overflow extension to ask questions about coding tasks without leaving the editor; instead, the GitBook extension allows you to ask questions about GitBook docs.

Besides providing access to documentation, Copilot extensions may help developers interact with a service directly from their IDEs. For example, the Docker extension allows you to generate Docker assets and analyze vulnerabilities; the LambdaTest extension lets developers manage testing workflows and streamlines test execution, automation, and insight generation; the Mermaid Chart extension can generate various kinds of diagrams based on you GitHub Actions, SQL, or other files you are currently working within your IDE.

As mentioned, developers can also create their own extensions to access private data or in-house services. To make it easier for developers to create extensions, GitHub has published several repositories showing how you build a basic “Hello World” extension, how to gather feedback from extension beta users, and more.

There are two ways to build Copilot extensions. On the one hand, you can define a skillset, meaning you have Copilot handle all AI interactions with the extension providing a description of several endpoints it can call to process user requests. Currently, a single extension can use up to five distinct skills.

On the other hand, you can use your own AI agent, in which case you pass certain information from the user context to the agent, such as details about a user’s current file, selected text, and repository. In this case, the agent receives server-sent events (SSEs) with user messages and references to their current environment. The actual context information varies with the client hosting the extension. For example, while Visual Studio and Visual Studio Code pass the current selection or the whole file content, GitHub.com doesn’t, but provides the URL of the page the user is currently visiting.

To make it easier for extension builders to manage authentication, GitHub has recently added support for OpenID Connect (OIDC). This frees developers from having to verify a GitHub token’s validity on each request by allowing them to use a pre-exchanged token.

GitHub Copilot Extensions can be used in a variety of clients, including Visual Studio and Visual Studio Code, GitHub.com and GitHub’s mobile app, and JetBrains’ IDEs. They are not supported in Xcode or GitHub Codespaces, though, nor vim or emacs.

Article originally posted on InfoQ. Visit InfoQ

Transcript

Elesin: My name is Olalekan. I was the director of engineering, now I’m VP of engineering. The title says, elevate developer experience with generative AI capabilities on AWS.

We go through, we introduce Amazon Bedrock, code review assistant, agentic code generation, code summarization, and I have a bonus material which I would share with you. Personally, I’m a fan of football. I would show you an example of, I was watching a game, and then in 20 minutes or so, built a simple application.

Introduction to Amazon Bedrock

What is Amazon Bedrock? It’s a fully managed service. I’m not, as I said, maybe AWS hero, but I just want to introduce you to this. Not a marketing slide. I would also give a critique of my own of this service, or AWS services that I have used to elevate developer experiences at my workplace. Fully managed service comes with foundation models out of the box from leading companies, AI21, Anthropic, and things like that. Key features, Bedrock Studio, Knowledge Bases.

I’m not here to talk about Bedrock, but I’m just trying to give you an introduction to it and how we can use it to elevate developer experience, which for me is very important. If you have access to an AWS console, you look at Bedrock, this is what it looks like. It’s why Meta, which is also a very key contributor in the open-source community for the development of foundational models or large language models. This is where it gets interesting, everyday developer experience. For me, this is what I care about, not Bedrock.

Code Review Assistant with Amazon Bedrock

As an engineer, who loves code reviews? If you’re an engineer, you love code reviews, you’re from Mars, everybody else is from Earth. Let’s take that. I still do code reviews, and at every point in time I’m wondering, why do I have to do this? If you look at the coding flow, there is 19 hours of coding on average, pickup time takes about 9 hours on average. Review takes five days because, if someone says, yes, in this daily standup, I need you to review this. Don’t worry, I’ll pick it up. Who picks it up? Nobody. I also do the same, nobody picks it up. Then the deployment time is on an average 80 minutes. There is a lot of work getting stuck in the review phase.

The value that we as engineers create is that we are very excited when the value that we create with code, when the problems that we solve with code, gets into hand of customer. For me, this is very important. How do we reduce this? One day, I was super pissed at code reviews, and I realized that the engineers on my teams also were struggling with code reviews. I sat and said, how can I solve this? Then I came up with this architecture. Fortunately, it’s quite simple, so you look at a third-party Git repository, think of GitHub or whichever one. Created a webhook with API gateway, which goes to a lambda function, sends the information to Bedrock.

Once you create a pull request, it triggers the webhook. Goes straight, does the review of the code, goes back and comments, and does review. This is something that can shorten that nine hours plus five days to minutes, if not seconds. I was super excited on working on this, only to realize that people already built this on GitHub, and they’re putting in the GitHub Marketplace.

Then again, this is something that can take you from nine hours plus five days, into minutes. It doesn’t mean that the reviews are super perfect, but it gets you up to speed as quickly as possible. Now think of the webhook, and think of how you can extend this use case within your organization. You can also exchange Amazon Bedrock. You can change it to Mistral code assistant, you can change it to Claude code assistant. You can change it to anything that you want. It’s simple. Gets you up to speed as quickly as possible.

Agentic Code Generation with Amazon Q Developer

Who loves moving from Java 8 to Java 17 and Java 19 or 21? Who has ever embarked on that journey where we say, we’re running on Java 8, we have CVE issues, now we need to go from 8 to 95? Who enjoys that? I think there was some Log4j issue in, I think 2022, where lots of people had old Java versions that we had to migrate. This was really interesting for a lot of us. If I see this, I know I’m excited. Who’s excited, to do code migrations? Here comes Amazon Q Developer. Amazon has mentioned a lot about this. They’ve done migrations on their own, they’ve done 1000-plus migrations. I can tell you that this actually works, from my own personal test.

What I did not like about the Amazon Q was that it took us months to provision. The reason, you have to connect it to AWS SSO, which for most of us, in our organizations, we already have an SSO provider. What we did was not to use Amazon Q Developer, but we used GitHub Copilot. I cannot share the stats, but I will share with you what I observed with the engineers that used Copilot in my teams and engineers that didn’t use Copilot.

Every morning we use our instant messaging tool, and then I see at least four engineers sending pull requests every day saying, please review this. It turns out that these engineers are actually using GitHub Copilot. When we ran a survey with them, estimated again, they had between 15% to 30% efficiency gain by using Copilot. Then I asked myself, the colleagues in suits saying, in five years, engineers will go away. I don’t think so. I think in five years, engineers will become better at the craft. We will be problem solvers.

One of the things that I noticed with the engineers that used Copilot or AI assistants in writing code was that they became better problem solvers than code implementers. It can be Amazon Q. It can be GitHub Copilot. It can be Cursor. What I’m trying to say is that, as engineers, you can start introducing this to your workflow, as long as it aligns with the security policy of your company.

Let me see if I play this video. I’m actually a Manchester United fan. When I was preparing for this, was one of the football games on a Saturday afternoon. I wanted to watch the football match, and at the same time, I wanted to prepare for this. I wrote a prompt saying, give me this particular project that would perform this particular activity.

It generates the sequence of tasks as an LLM agent, and here I am for about five minutes just sitting and watching Manchester United. This is what we do as engineers. We tell the product manager and the engineering manager that, yes, I’m working remotely, just give me a bit of time. We’re chilling, sipping some coffee, whatever you drink. It’s October 1st, so you can get the idea.

Then, you wait for the LLM to generate the code. Definitely it generates code, but it doesn’t mean it’s accurate. It means that you still have to look through it by guiding it through the problem you’re trying to solve. What do I do after? That’s it. It generates my CloudFormation template. Generates the code itself, and I spend maybe another 10, 15, 20 minutes editing to make sure it aligns, and testing it. What would have taken me about three hours, I got it done watching a football match, and also in 20 minutes. Again, better problem solvers as engineers. Engineers are not going to be replaced in five years, we’re going to evolve and be better at the craft.

Code Explanation and Summarization

Code explanation and summarization. How many of us have people joining our teams regularly? Tell me if you actually enjoy explaining to them how the code works. Nobody does that. Is there anybody that loves to do that, to explain? I don’t enjoy it. When I joined HRS, I led the data platform team, and we built it from scratch together, the Kinesis data ingestion and data lake, and S3, and here we have about four years after someone was asking me a question, and I’d left the team. I was like, how do I start explaining how this works? I got tired.

Then comes code summarization and explanation. What I’m showing you right now is an architectural blueprint that you can give a try to. We have repositories that exist on GitLab, Bitbucket, GitHub, you can put that in an S3 bucket securely, making sure that there is no public access. That’s very important. Then put that in the Amazon knowledge base with OpenSearch, either the OpenSearch with instance, or OpenSearch Serverless, and then with a foundation model, the new team members can ask questions to it. Very easy.

Even within GitHub Copilot and Amazon Bedrock, you can also have that in there, in the code repository itself. They can highlight the code and ask you to explain. This way, you can easily generate documentation that’s really closest to the code as much as possible. You can have interesting automation in here.

Example, think about when you do a git push, you can attach a webhook to it to automatically update the documentation and make publishing it as an HTML, where they can go to and see. Think of platform engineering teams as well that are maybe publishing CDK templates or CloudFormation templates or Terraform templates. These can really help onboard engineers into what you’re building. This is something that you can get started with without writing as much code as possible.

Support Case Investigation

This is the bonus material. I work in a B2B environment. How many of us get someone saying there was a customer somewhere that complained about an issue in production, but our infrastructure monitoring never picked it up? What happens is, when a customer raises an issue, sometimes it takes a couple of days for us to find the underlying issue. One of the things that we realized was that the information about the issue reported by the customer exists in different systems. If you’re not using super complicated architecture, super complicated login systems, it might be difficult to find.

Then the customer service agent with the application support, the product manager are all pissed and wondering, why can’t you find it? Here is a simple architecture. Let’s say you have a case management system as an example. Someone logs in and creates a case saying, we have this issue in front of customer x, customer y, you can easily trigger a webhook similar to the git integration earlier, which invokes an agent. What that agent does is that it goes through your login system.

You can do that with Python or Java SDK, both with three SDKs, saying, search CloudWatch with CloudWatch Insights for this particular string. If you use Prometheus, you can use OpenTelemetry to query it. If you have a database that you have read only access, you can also put that in place to do a read.

Then, once you find all that information, what LLMs are good at is that they are good at really synthesizing unstructured data. What inspired this was what I described earlier, but I think late last year, just to give you a bit of background context, we had colleagues in our HR department. They run surveys multiple times every year where they ask colleagues, how do you feel about the onboarding process? How do you feel about this? This is give or take, they receive 240 responses, unstructured, in an Excel file. Who can go through 240 and still have not drank maybe five or six cups of double espresso?

What I did was to sit with the HR colleague, this is to say that, even with using LLMs as elevating developer experience, you can also extend to other parts of the organization. Sat with the HR colleague and said, let’s look at all these files. Let’s put them in a large language model, and let’s map the result of this file to our onboarding process. What would have taken seven hours, we did it in five minutes.

Again, developers are not going away. We’re here to stay. Tell the suits that. What I’m saying here is, support case triggers a webhook, API gateway invokes a lambda function, queries all possible locations that you have your logs, and then sends the information back into the support case application. What used to take about three days, nine hours, whatever time, with this approach, you can do it in five minutes.

Then nobody has to sit on my neck and start asking me, where’s the answer to the question. This is very important. Like I said, you can think about multiple use cases and try to reshape this based on your organizational context, your current problems, but I can tell you that this would elevate your experience as an engineer, because now you focus on the actual problem solving. It’s good to explain code to the colleagues, but what we love is to create value with software.

Questions and Answers

Participant 1: Have you gathered any experience using GenAI for when you have a refactoring, like the upgrade you mentioned, that you have to roll out across 200 services, and services are different enough that you cannot really script it. Have you ever had any use cases like that?

Elesin: Yes. One example was that we wanted to put a REST interface in front of an internal gRPC protocol. We put it in GenAI, and it messed up bad. What we did was to think about the problem we’re trying to solve and then write it by ourselves. We couldn’t trust GenAI in that regard. In some cases, it behaves really well. In this case, it was really terrible.

In fact, I could not believe the result myself, because then I had to sit on the call with the engineer, saying, can you please show me which went through? I was like, we have to do this on our own. I know, it happens. It’s not perfect, but what it does is that it gets us a head start.

Participant 1: If you have to roll that out across a lot of repositories, you could probably make the change once, show it to the AI and tell it to do the same thing everywhere else.

Elesin: At least what I know is that in Amazon Q Developer, you can integrate your own code and train the underlying model with your own code, but due to our own security compliance, we haven’t done that.

Participant 2: Can you give me an idea of what an AI code review looks like? You make a 2000-line code pull request, what does it say?

Elesin: One of the things that it looks like is that it doesn’t have context of the entire application itself. What we realize is that with the new models, which say they have 200,000 token size, which is about a book of maybe about 500 to 600 pages, you can actually give it your entire book itself, and then it’s able to understand the context. You can give it the entire repository, and then it understands the context. What it does is that it says this particular line behaves like this. This is the expected result, maybe adjust it in this way to simplify the runtime.

Then it comments one after the other that way. Very human readable and very understandable. Like I said earlier, I have a team that is using this integration as we have it, and every day it’s about four to five pull requests, anytime I open the instant messaging. On the other hand, we have teams that are not using this, so I did more like A/B testing with the team, and this is the result.

Participant 3: How much do you spend approximately on the tokens for inaudible 00:21:13. You might not need to measure it, because you’re free on tokens, I assume. Was it more in the dollars or the tens of dollars? Because the repository can get arbitrarily long when it comes to the tokens you need to consume to even embed it.

Elesin: I didn’t see it pop up in my AWS costs. I know that if I exceed the budgets, my FinOps colleagues will reach out to me. So far, no.

Participant 4: Could you share some rookie mistakes which you did when starting to build on an AWS Bedrock. What are the things which you would recommend if I’m starting out now, not to do?

Elesin: What not to do when starting out with Bedrock? Number one, check with your security, check with your compliance. Number two, and this is my personal understanding, anything that we consider as high proprietary company information, intellectual property, don’t put it in there unless you have the compliance check from your security department. I don’t think it’s more of don’t do, but I think it’s more to do. What I would say to do is to try it out once you have some validation, immediately. We’re in business travel as HRS, and then we’re also heavy on sustainability, which is helping companies to align their company strategy when it comes to business travel with building a sustainable planet.

One of the things that we have, it’s called a Green Stay, which is about sustainability classing for the hotels that work with us. That information is very voluminous. One of the engineers on the team asked me a question, how can we simplify this? I said, you don’t need to train an AI model, so put all this information in a Word document, because it’s public information.

Let’s go to the Bedrock UI, put it in there, let’s start asking it questions. We have the version of that chatbot in a development area where someone could log into and actually play with it. This engineer had no experience with machine learning at all or AI at all. Check security. Get started immediately. Get into validation as quickly as possible. Do’s, not so many don’ts.

Losio: You mentioned before, one example is, I have Java 8, I want to bring it to Java 17, whatever it was. The scenario, usually, you have Java 8, or whatever else it is, you have probably a project that’s been running for many years. A person that has been probably quite senior, old, whatever adjective you want to have, a project that maybe has been there for many years. Think of that scenario. You want to convince the team to do that, because it’s easy to say, yes, Amazon did it, they migrated 10,000 projects.

Automatically, if you go to the developer team that has been playing with that code for the last 10 years, probably are going to tell you, I’m not going to put my entire code base and see 50 changes in every single class, all committed together tomorrow morning. How do you convince your team to follow you on your machine learning journey?

Elesin: How do you convince experienced engineers to use this tool to accelerate? It’s a difficult one. In my area, we’ve all come to the realization that this journey is almost impossible without some automation in place. That’s the first part. The second is, I had to show. Like I said, we have a team that is using it, and the colleagues see the efficiency gain with the team using it. That’s one of the proof points. The first fact that we came to the realization that this is almost impossible for us to do. The second is that we have a team that is using GenAI in one way or the other, and we’re seeing accelerated value delivery with software.

The question is, why not go in this route? Right now, when I’m hiring engineers on the team, I’m actually expecting them to tell me that they use GenAI to solve a problem, and then we go into detail. To your point, it’s change management. It’s difficult. For me, the communication is that, as an engineer, it’s not about someone getting rid of you in five years. It’s about you evolving to solve problems faster and get value into the hands of the customer quicker. It takes time, but yes, once they see the benefit, then they begin to understand. Because I myself also demonstrate how to use it. I think that’s what I do.

Apart from the developer experience, I also do product managers as well. Who loves estimations? We have refinement, now we have to do estimate. Then you get into the meeting the product owner or the product manager says, I’m not sure, I’ve broken them down into user stories, but let’s start discussing. Who enjoys those kinds of meetings? I ran a session just to also explain to you that this also takes time, not only from an engineering perspective, but also from product ownership perspective. I had a session with our product owners and said, I know that this is a problem, and I know that you might not trust this software, but let me show you the benefits of this.

First, map out who are the users of this and let’s take the problem that you have, put it into this large language model and say, generate user stories based on this problem, acceptance criteria, and then you’re better prepared to have discussions with the engineers in the refinement sessions. Now we have better refinement sessions because this helps better preparation.

The development experience, from that perspective, it also took time. Because I’ve mentioned it to the colleagues before, it took them time to understand, now they understand this, now it’s accelerating. The change management is difficult, but it is a journey that we keep on trying and improving over time.

Participant 5: You mentioned so many use cases about generative AI. One case you didn’t mention is generation of test cases. Is that it can’t handle Bedrock, or is that you deliberately allow it?

Elesin: I actually did this myself. Because I’m in business travel, like I said, we had a use case where we had so much work for our QA engineer to do, and nobody was taking care of this. Because I understood the context of the problem we wanted solve, we simply took that and put it into the large language model, in this case I think it’s Bedrock, one of the models on it, closed source models, and it generated the test cases. It was then based on this test case that we created tasks for other people, so that we could parallelize the work. It’s possible, and I’ve actually done it myself. It does work.

Participant 5: If it does, then how can it generate test oracles for your program? How does it know that it is doing what it’s supposed to do? It doesn’t know. You feed in code, which could be wrong, but that the test case needs to be coming from the requirements, for example, that A plus B is equal to C, and you have programmed A plus B is equal to D, how the Bedrock or any algorithm would know that actually it needs to write the test?

Elesin: When it comes to generative AI, it’s generative. Then, for it to generate something, you need to give it a prompt. In my case, I understood the context of what was expected. There were policies with regards to the expected behavior of the system which I had clear understanding of. It was basically my clear understanding of the problem. I said, this is the expected outcome of the user, this is the expected outcome for the problem itself.

Based on this, generate test cases. Then we looked at the test cases, some of them made sense, quite a number of them didn’t make any sense. Then we ruled out the ones that didn’t make sense. The one that made sense, we simply took them and said, let’s create the work for the colleagues to do.

Participant 5: You need a human in the loop?

Elesin: Definitely, yes. You saw, it was starting from engineers, then people are there. There’s always a human in there. In this case, the human was me.

Participant 6: Maybe one question on the specific topic you had with the repository and embedding it. How did you handle the generally weird structure of repositories being deeply nested. Because normally if you embed a document, you have this one embedding for this one document. Did you start building a hierarchy, or is it something that’s just natively handled in Bedrock?

Elesin: I didn’t care. I simply uploaded it into S3 but I excluded the irrelevant parts. What RAG, retrieval augmented generation, does is that it converts all text form into some vector representation and then stores that in OpenSearch. For me, it doesn’t matter if it’s nested or not nested. It’s simply making sure that it goes into the vector database, in this case, OpenSearch.

If you are planning to do maybe something more complicated that might require hierarchical structuring, and I think there have been techniques like the graph RAG, graph which is connecting nodes and edges based on the retrieval augmented generation, you can also try that. For me, I wanted to get it to work as quickly as possible. First phase this. If it requires more fine-tuning based on the work, then you can add that hierarchical structure in there. First, don’t care about the hierarchical structure.

Participant 6: I was just wondering if it handles it internally.

Elesin: Yes, it did it quite well.

Participant 7: Did you measure that, because inaudible 00:33:26 with installing the stuff, at least for Java code, not using Amazon but customly just build embeddings and just started to search through the Java code, and it provided completely unsatisfactory results. Because if you just think about Java code, they are just tokens that are not relevant to the language directly and just there are indeed should be some techniques, you overcome these limitations. Basically, yes, it’s interesting. What were the results? Basically, at the end these new team members were satisfied.

Elesin: How do you measure the accuracy of the response from large language models. Because it’s not a classical machine learning problem, that is, you have an outcome or an output that you can predict. It’s difficult to say the accuracy is this. This is another point where you need the human in the loop to do a thumbs up or a thumbs down, and say, this was relevant, this was not relevant. In this case, it was 60% relevant for the queries that we issued. In some cases, the remaining 40%, it wasn’t relevant at all because it was missing the context.

Especially we saw this in the pull request example, where, when we first tried the pull request use case, we were only giving it the snippet of the code that was written, not the entire context of the classes that were involved. That’s the case. In the 60% of this time, about 60%, there was a thumbs up that the responses were relevant.

Participant 8: You mentioned about the test scenarios generation, which is nice, during the refinement sessions, they will help. Is it also helping scripting the tests, such as that automated test, because there are some development environments which generate unit tests very easily, but in terms of unit test or API layer automated tests, it would be really useful to have a level of automation where afterwards developers can make changes and make it workable. Maybe also connected question in terms of test automation coverage, because if it is intelligent enough to detect the areas around pull request reviews, maybe also in terms of coverage, it can be useful then.

Elesin: Can it generate unit tests? What’s the unit test coverage? Can it also increase?

The team that uses GitHub Copilot, my expected outcome for them was to increase the unit test coverage of the projects that they have in their purview, the target was 70%. This was really almost impossible for colleagues that joined newly to write unit tests and also still ship value with code. They optimized by using GitHub Copilot to generate unit tests, which then increased our test coverage from around 0 to about 50%. We’re still getting there, but we’re not there yet. It also increases the test coverage. I think they improved efficiency by 15% to 30%, so there’s unit test generation, which is now increasing the unit test coverage of the projects in their purview.

Losio: You mentioned at the beginning that you didn’t use Amazon Q, I think you said, just for the SSO configuration. I was wondering if that’s the only reason, or actually you got better results as well with Copilot. What’s your feeling about it?

Elesin: That was the reason. Now we have it enabled. The main reason, and the only reason we didn’t use it initially, was because of the access reason. Amazon SSO, we had Azure SSO already. Why maintain two things? Because that’s a security exposure on its own. That was the reason. Now we solved that.

The other side of GitHub Copilot is that we didn’t get statistics of the usage, so we didn’t know how many people were using it, and what they were using it for. Now we’re switching to Q. It gives us the cost visibility. It gives us how many times that engineers are accepting the recommendations from Q Developer itself. Gives us the number of times that recommendations are rejected. It also gives us visibility into how the cost is developing. We just started rolling that out. The main reason was the fact that we had to use AWS SSO, which at that point we didn’t want to use.

Losio: I was quite curious about the integration of different services in that sense. I was curious if there was as well a choice of like, try to pick up the best of every provider, or integrate different providers, how it works as well, or it’s more an effort to them.

Elesin: It was more of the security. Now, also to your point, we want to do a comparison to be sure of what to roll out at scale for the entire organization. Because, for us, we want to double down on this as much as possible. It wasn’t the comparison. It was more of the limitation at that point in time.

See more presentations with transcripts

Article originally posted on InfoQ. Visit InfoQ

Google DeepMind’s AlphaGeometry2 (AG2) AI model solved 84% of the geometry problems from the last 25 years of International Math Olympiads (IMO), outperforming the average human gold-medalist performance.

AlphaGeometry2 is a new iteration of DeepMind’s earlier geometry AI, AlphaGeometry (AG1), which could only solve 54% of the IMO problems. Both models operate by using a domain-specific formal language to describe the problems and a symbolic deductive engine to generate proofs. The new model’s improvements include a more powerful LLM based on Gemini, which translates the natural language form of the problem into formal language. AG2 solved 42 of the 50 IMO geometry problems from the years 2000 to 2024, while the average gold medalist solves about 41. Flagship commercial reasoning LLMs, such as OpenAI’s o1 and Gemini Thinking, cannot solve any of the problems. According to DeepMind,

Despite achieving an impressive 84% solve rate on all 2000-2024 IMO geometry problems, there is still room for improvement…AG2 has not solved all IMO and IMO [short list] problems. We hypothesize that breaking problems into subproblems and applying reinforcement learning approaches could close this gap. Finally, in this paper we reported progress on building a fully automated geometry problem solving system, which takes input in natural language and outputs a solution reliably without any hallucinations. Despite good initial results, we think the auto-formalization can be further improved with more formalization examples and supervised fine-tuning.

AG2, like AG1, solves geometry problems by stating them in a formal language which consists of predicates: for example, acompute a b c d means “Find the angle between AB and CD.” AG2’s predicates can cover 88% of the IMO problems; the model will not attempt to solve the other problems.

But first, the problems written in natural language must be expressed in this formal language. To do this, DeepMind uses a Gemini LLM with few-shot prompting: the prompts contain “several dozens” of examples of problem translation. This approach is “very consistent and makes almost no mistakes” on the easier problems.

Once the problems are specified as formal predicates, they are solved using a symbolic engine called Deductive Database Arithmetic Reasoning (DDAR). If the engine fails to find a proof, AG2 uses a language model and tree search algorithm to generate auxiliary constructions, then it re-runs the DDAR engine; this loop is repeated until a proof is found.

Writing on X, Berkeley CS PhD student Yuxi Liu said, 

AlphaGeometry2 is pretty cool, but clearly not bitter-lessoned. It has a very 1950s auto theorem proving feel, with handcrafted representation language, logical inference engine, etc…They are just doing autoformalization (succeeding 30/39) and proposing auxiliary constructions during tree search. Many of them require just a single auxiliary construction! Though there are cursed examples that required 12.

Oxford University ML researcher Simon Frieder also wrote on X:

AlphaGeometry2 was published, 2.5 months since we released Newclid without much fanfare (in true scientist style! :D) and two months after TongGeometry. It seems no code was provided for AG2. So now we have two closed systems, AlphaGeometry2 and TongGeometry that we cannot compare. Newclid…is fully open-source, fixed many AlphaGeometry bugs and slightly improved it in terms of performance – and we also have GeoGebra support for better input.

Although the AG2 code has not been released, the code for AG1 is available on GitHub.

Article originally posted on InfoQ. Visit InfoQ

AWS has introduced a new capability for AWS Organizations members, allowing administrators to centrally manage and restrict root-user access across multiple AWS accounts. This update enhances security and governance by providing organizations with greater control over the most privileged access within their cloud environments.

Administrators can now get a consolidated view of root- user access across all accounts within an AWS Organization. This includes insights into whether multi-factor authentication (MFA) is enabled, helping security teams enforce best practices.

With the new functionality, AWS Organizations can enforce service control policies (SCPs) to regulate root-level actions, either restricting them entirely or allowing them under specific conditions. This strengthens security by preventing unauthorized use of the root user across accounts and ensures compliance by enforcing critical controls, such as requiring MFA before executing sensitive actions. By mitigating the risk of misconfigurations or accidental privilege escalations, these policies help maintain a more secure and well-governed cloud environment.

AWS recommends keeping root access to a minimum, using it only for essential operations, following the concept of least-privilege access, and preventing any user from having access to full -admin capabilities.

With centralized management, organizations gain greater control and visibility over root- account activity. They can now monitor when and how root accounts are accessed, tracking usage across all accounts to detect potential unauthorized access or security threats. Security teams can also audit compliance by ensuring that root users adhere to organizational policies, such as requiring multi-factor authentication (MFA) or restricting high-risk actions. Additionally, administrators can enforce MFA and apply service control policies (SCPs) to limit root-user privileges, ensuring access is restricted to only essential actions and reducing the risk of misuse or compromise. Should a person need to be granted root access to perform a specific task, there is still a provision of a root session that can provide this access temporarily without needing to provide a person with this level of access permanently.

Previously, organizations in AWS had to manage root-user access at an individual account level, increasing the risk of inconsistent policies and potential security gaps.

Both Azure and Google Cloud also provide hierarchical management structures and centralized identity and access management through their respective Management Groups and Identify and Access Management systems, and this update brings AWS up to standard with these approaches.

This feature is available to all AWS Organizations customers. Administrators can configure root access policies within AWS Organizations and use AWS IAM policies and SCPs to enforce restrictions.

Article originally posted on InfoQ. Visit InfoQ

Transcript

Rajan: I’ve been in cybersecurity for a little over 14 years. For the past 7-plus years, I’ve been primarily working in the public cloud space, so AWS, Azure, Google Cloud, Kubernetes, cloud native. That’s primarily the space I’ve been. I’m fortunate enough that I’ve worked with a lot of Fortune 500 companies. I’ve worked with them on strategy or how to get those things implemented.

A lot of the things you would hear are learnings from what a lot of people have tried doing, what we have failed at. Hopefully that comes across as well. My last one was a CISO. I’m still a CISO for now in an EdTech company called Kaizenteq. I recently discovered my love for cloud security training. That’s the Cloud Security podcast I run with my co-founder.

Zero Trust (ZT) – Basics

I know we had a few different levels in terms of experience and people who’ve seen zero trust. I did want to start by leveling up the playing field for everyone once. Don’t worry, I would not try and bore you guys with a government diagram, which is a very tiny one there.

Essentially, the way I would describe zero trust, as much as there’s a negative connotation to it, and a lot of companies try and change it to something more better than zero trust, because I think the initial thinking behind this was that we do not trust where the communication is coming from, so I want there to be a “trust zone” created between whether it’s my network, whether it’s my identity in the network, whether it’s the applications that are running in the network, or whether it’s my devices that are in the network. There are different ways to describe this.

Another common term that is very used quite often is ZTA, or zero trust architecture that a lot of people talk about. The idea is that you’re using the principles of zero trust to build an architecture. When you Google it, that’s where most of your terms come in from, ZTA, ZT, this one called ZTNA, which is network.

I did want to show this. This is the NSA diagram for how they describe zero trust. This is 8th of March 2024. You probably find that a lot of the information you find, or at least when we started googling for it, because we are trying to find a consulting company that could do it, but then most of your time, you land on a government document. The reason for this was because when America, as they do, they started saying, we need zero trust everywhere, especially when the presidential order came in.

A lot of the government documentation got updated, and they had a limit, or at least they had a timeline they had to do something about within the next two years. You’ll find a lot of updated documentation, if you’re looking for a reference point, primarily from the government organizations, and they’re trying to do this at their end. How much of it is done? It’s a work in progress. I’ll probably go through the pillars in a bit. For anyone from the UK, I definitely covered, try and finding a local source, but NCSC has not updated their diagram since 2021. NCSC has some documentation, but there hasn’t been updates since 2021.

The point being, they all still rely on the same basics that I called out earlier. If you are thinking in terms of where it is important, and maybe you are not in a public sector at this point in time, but there’s a very popular analyst firm which makes all these predictions and makes our life difficult with more acronyms. Gartner is the company that I’m talking about. They came up with a prediction that by 2025, 60% of the public sector would be at least doing something in zero trust.

In fact, if you talk to most government organizations across the U.S. and some parts of UK, they’d already have some projects already in line, starting with zero trust. There’s a lot of conversation just comes up, “We’re doing this for zero trust. We’re working towards zero trust”. Mostly the public sector. I personally have not seen a lot of the private sector talk about it as much, and different reasons for it. Most of them are busy with GenAI, but maybe zero trust will come in soon.

In terms of the market cap, and I feel I should have an asterisk next to it, because this is a second prediction from Gartner on how big the market would be by 2027, it’s $3.99 billion. If I go back to my previous slide, public sector usually has a lot of money, so I can imagine that’s where the money is coming from. I’m sure it’s all a mix of private and public. That’s where the number is coming from.

Zero Trust – Practical Foundations

Now that I’ve laid the foundation for zero trust, and at least everyone understands it, I wanted to add a few more layers onto that diagram that I was talking about earlier. This is the simplest way to understand zero trust. When people talk about zero trust, they usually talk about these five pillars. They talk about identity. They talk about device, network, environment, application workload, and data. A lot of you are already quite experienced, and I don’t need to explain what each one of them mean.

In the context of zero trust, this is probably more referred in the context of how these five foundational pillars are applied. We’re not going to go into the diagram. If you just focus on the middle, there’s a thing called policy enforcement point. The whole idea of zero trust is that across these five pillars, we have some policy engine or policy enforcement point that helps us make the call for, is Ashish the right person to authenticate? Yes, he or she has the right username, password. Is Ashish authorized to log in into this? That’s another policy call. Is Ashish coming from a trusted network? That’s another policy call.

The idea is that you would be able to use a policy engine and hopefully get to a point where you can automate a lot of that policy to be able to do zero trust. I do want to call it out. It’s an ideal scenario. This is an ideal diagram. I don’t know how many people have policy enforcement points. We have a lot of policies and procedures that we have seen and we’ve worked with for a while. This is what they would like people to go.

Again, this is a diagram from 2021. I do want to keep you guys updated in terms of the timeline, in terms of how quickly things are moving. At this point in time, the idea behind those five pillars is to be able to put this through a policy engine that helps us make the call, because we don’t really want to be doing manual approvals for every time Ashish wants to access this HR application.

This is the foundational piece. I’m not going to talk about the five pillars, because I think you guys are smart enough for that. I wanted to start by what they mean by what should the zero trust journey or architecture stand on? I’m assuming everyone has some understanding of IAM. Everyone knows IAM? All of us know authentication. Everyone knows username, password. Everyone knows the fact that we need to have single sign-on, if we want it to be like a federated authentication. The reason I bring this up is, identity has become the new perimeter across cloud, across your on-premise, even though network used to be the first one.

The way I would describe identity these days is how on-premise used to be, at least for people who are from a security background. The way we joke about this is that on-premise was like a castle. You have one bridge in, one bridge out. If you get in, you can access everything you want. If you have to get out, there’s this one path out to the internet. I would describe public cloud as an amusement park. Imagine Disneyland, we have multiple entries, multiple exits, you have no idea who’s coming in, but everyone wants a VIP pass as well.

They want to get on every ride that’s possible. You’re trying to go, I get it, but why don’t we just start with the limited pass first and then start adding a lot more? The point being, identity is a lot more complex. When we talk about identity in 2024 where we have cloud environments, we have on-premise environments, we even have OT, IoT devices that are out there as well.

We have started having a lot more conversation about not just human users, but non-human users as well. I’m sure people who are in the cloud space already know this. Whether you’re Azure, AWS, or GCP, you’re already dealing with non-human users, machine users that are going to just do a task, servers that have identities, that have permissions that can be used for it as well. The foundation pillar for zero trust in 2024, at least the way we have envisioned it has been more around the fact that human users, non-human users, for example, for humans we know MFA works.

For humans, I want to know that, yes, Ashish has authenticated. What does that look like from a non-human user perspective? What is machine user doing already? As I say that, I will also say, this is probably the place where most people start. A lot of us have already proved we know IAM. A lot of us have been doing IAM for a long time. We’ve already started on the zero trust journey without even knowing it. We wouldn’t let any random person on the internet just authenticate to our application. Hopefully I’m keeping some part of my promise where all of us are at least walking away with doing zero trust, at least starting to do it.

The second thing that we will talk about after this is, yes, I’ve made sure that Ashish has the right username, password, but is he coming from the right device? Do I trust the device he’s coming from? That’s the second layer of foundation that people talk about, where, if you’re trying to implement this in your organization, the very first tier, the reason people start with identity is because it’s probably the most understood so far. It’s also the place where we have the most maturity in most organizations, since we’ve been doing it for so long. Unless you’re using a custom application. I don’t know if someone works in mainframe? Those things use a numeric password still, like a 4-digit numeric password. Hopefully you’re not in mainframe.

Outside of it, primarily, you’ll find we have a good handle on identity as a general tech community. The next layer that is spoken about these days is non-human users. The second one after that is identity of the actual endpoint, or the device, or the server, or the laptop that we’re coming in from. That’s our second layer of foundation, where, once we have started working on the identity piece, we have some sense of, I’m pretty confident, identity is good. I’ve got MFA for human users. I have hopefully least privilege or role-based access control in place to have some confidence that only the right people have access to the right information.

The next layer of zero trust you probably would think about is, the device they’re coming in from, is that trusted? The second foundation is the unified endpoint management. To start in that journey is when a lot of people start doing your network segmentation, is another word people use. They said, on-premise, I had this super DMZ zone that I’ve maintained for a while. I’m able to look at this and go, I’ve got a demilitarized zone. Anyone can do anything in there, but I have a private zone. The point being, you need to know what your identities are and what your endpoints are going to be that you trust. I will talk a bit more about this in a bit later slide when I talk about the use cases.

The next one, this is probably the hardest one to go for, resource ownership, tools, and processes. Everyone I’m sure has an asset management system which is very mature, very dynamic, which is more than Excel sheet. For context, I was on a call with a CISO for a FinTech company, and they have over 400 AWS accounts. They were using Google Excel for recording 400 AWS accounts. I’m going, “This is great. You’ll be fine”. My hope is you guys have a better one.

The reason I say this is the hardest one is because of the complexity of environments these days, you have on-premise, hybrid cloud, multi-cloud, cloud native. There’s Kubernetes self-hosted, Kubernetes which is managed. Complexity in compute as well. Now we have multiple CI/CD pipelines. A lot of you are dealing with multiple languages being used in the organization as well.

At the same time, you have to find the balance on being developer friendly, because you don’t want to limit their speed. These days it’s not easy for you to keep at least a log of how many real-time assets you have. If you were to go down the path of doing zero trust from a foundation perspective, I personally feel this is probably the hardest piece. Like, identity, we got this.

Endpoint, to an extent, we have all these endpoints that we know that at least someone in corporate network knows how many devices we have. Someone in DevOps team or cloud security team or cloud engineering team would know how many cloud accounts we have. It gets a bit muddy at the more complex environment. At least for me personally, I found this is the hardest one. Because even if you get the resource, next hardest part is, who’s the product owner? Who’s the owner for this? Is the owner still in the company? No idea. The longer the organization has been in existence, the more complex this third one goes. That’s why, at least for me, it’s the third one.

Data classification, of course, is a security thing, so we have to talk about data as well. At least since I moved from Australia, I find data is even more important in the Europe and UK regions. GDPR is actually a thing. I’ve been using it wisely. A lot of organizations sometimes don’t even have a data classification. I was joking about the whole GenAI and AI space earlier. I’ve been fortunate enough, through the podcast, I get to talk to a lot of people.

A lot of people have over 200 GenAI or AI related applications already, they’re working on today. Kubernetes or containers first, is a very real strategy for a lot of organizations that are trying to go fast, even if it’s doing AI projects. You’ll find what at the moment is not spoken about is the incident response for it. Being security people, we’re a bit paranoid. There’s a reason for that paranoia sometimes, where, if an incident does happen, do we know the risk that we are exposing ourselves to? Is it a high risk? Is it a low risk? Is it really something that we should be worried about, if it’s just public data? I’m like, yes, we have the website, as long as it’s not defaced.

If it’s PII or personal identifiable information, like my driving license or my passport number? Think about this from a developer perspective, the application you’re building, you would not want that to have any secrets or anything which is customer data sensitive, because that’s where the trust of the actual customer is coming from. This one is partially easy, because you can have a data classification for. I think the simple ones, if you’ve never done this before, it’s literally what is confidential, what is private, what is public.

Those three are the simplest data classification to go for. Anyone can do it. As an organization, it’s very easy to tell what is confidential, what is private, what is public. The hard part over here is, imagine if you are an organization that’s been there for years. This is before internet, and there are a lot of companies that have done this, before data center was a thing, and now there were data centers, and now they moved to cloud, and now they’re doing multi-cloud and the data center.

One of the biggest challenges we found was that a lot of data from certain number of years ago is no longer relevant. Would you have the time and money to spend on going back on that mountain of data that has been left for years? No one has classified it. No one knows it’s even relevant. No one wants any data that is probably about something which is not even a system these days. Is the business ready to spend money on a project that’s going to go through data for 25, 30 years?

At what point do you draw a line for, actually, I only care about data for the last 10 years or 5 years, whatever that tenure is. As you can see, the complexity and the practicality keeps going down as I keep going down. The intent is to at least have you informed for what is practical. Hopefully this gives you that information.

From data classification implementation or foundationally, when we spoke about, we have a data classification, we know confidential, private, public. How do we find out about this data? The first challenge we had was, how much data are we ok to classify? The second challenge we had was data sprawl. Maybe all of you have done a big data project when people were talking about big data before GenAI.

A lot of that conversation was primarily around, we have a data scientist who happens to work for a university who wants access to the data, and I promise they’ll delete this after. Give it to them. They said they deleted it. You have no idea if they’ve actually deleted it. That’s just one scenario, that’s called data sprawl. That’s a very real thing as well. There’s a whole category again Gartner has created called DSPM, if people are interested. It’s a data security posture manager which helps you identify any sensitive information across your network. The idea being, it is a real challenge.

Even if you were to just classify data, just to identify where’s my data, if you still want to call that, but that’s basically the other part which a lot of people struggle with. I didn’t even know where to start if I were to just go 20 years, 10 years, 5 years back. How many projects have we done? We have 400-plus applications with many contractors that came in and went, is that in their personal laptop, not in their personal laptop? Who is going to answer that question? At least that’s where I felt that’s the complexity for that.

The other one is unified logging. This is kind of like IAM. A lot of us already do logging for performance monitoring. A lot of us do logging for error management, troubleshooting. Some of you may already have security logging being separate as well. The idea behind zero trust foundation is also to have unified logging for data lake. I feel like this data lake’s work has been thrown everywhere. Everyone has a product called data lake as well. I think this is where it came from, unified logging.

The idea behind that all of us, instead of just basically having these multiple sources for logs, we should probably be able to have all of that into a central storage called data lake. As we do that, we can use it for security, we can use it for performance monitoring. We should be able to use it for troubleshooting and any other unusual activity that you have to monitor on a day-to-day basis for application. That’s where the unified logging comes in for.

The biggest challenge you find here is that there is no unified framework for how do I differentiate between an application log versus a security log versus a memory log? There is no common framework that brings all of it together, so I can just type in a query for, Ashish logged into linkedin.com today, and he basically made a post, which was weird, because he’s at the moment speaking, but somehow there’s a post out. Someone has to go and find out that in the log.

Separating that information, what that query would look like, that’s a lot more complex question to answer. There are some answers. Cybersecurity specifically has an open-source cybersecurity framework for logging. Security logs can be generally categorized into a known template so you can use it.

Last one, this is probably my favorite topic these days, at least for 2024, for two reasons. One, in general, there has not been a lot of conversation about incident response in the public cloud, cloud native world. Most organizations that I speak to, they believe that their on-premise incident response plan works one to one in the cloud context. Even though we’ve now used Kubernetes for building the same application, we’ve rebuilt the application using cloud native, somehow we have complete confidence that incident response plan from our on-prem is going to work in cloud.

The idea behind including incident response in zero trust is that, if you were to successfully go through all the initial ones, to an extent, over time, the number of incidents should reduce. You should technically get to a point where you should be able to connect without a VPN onto any network, and they should be able to validate that, yes, Ashish is coming from a trusted device. Doesn’t matter if he’s on the internet, but we know that device. We know Ashish has the right credential. We can maybe ask for a second form of authentication if we just want to level up the trust.

Primarily, we trust where he or she is coming from. That level of trust over time should mean that the number of incidents that you have to respond to should reduce. Initially, you’ll definitely find that building up what would an incident response look like in the new world of zero trust, if you’ve gone through all of that, significantly changes.

Even something as simple as, there’s an incident, how do I give access to my SOC team or incident response team to that environment? That’s a very difficult question to answer when people have multiple ways of doing zero trust. That was the foundational pieces. Hopefully, that at least sets some foundation for how real some of these foundational pieces may be in your organization.

Zero Trust – Misconceptions

I want to talk about some misconception as well. Some of you have tried doing zero trust. Some of you may have heard about zero trust. The first misconception that I’ll talk about is that asset management thing that I was complaining about earlier with an Excel sheet with 400 AWS accounts. It’s not a bad place to start. At least you know what you’re looking at. As much as I was complaining about it, the myth is that you should need to have a perfect inventory for you to start doing zero trust.

Let’s not aim for perfection, because even zero trust people themselves don’t want to aim for perfection. It’s supposed to be a journey. If you have an inventory that you feel is of critical applications that you want to enable with zero trust, I think it’s a good place to start. You don’t have to have a perfect inventory to go for. The other one is, you can buy a product for zero trust. There’s a lot of vendors. They would say, you can just buy zero trust, including Microsoft.

A lot of vendors have started calling out that we’ll be that one solution for zero trust. We all know how realistic that is. There is no product that can solve zero trust for you. Even let’s just go to foundation pieces, there’s no machine out there that can solve that problem for everyone. Even if they tried to, it’s only part of it that would be solved. To make sense all of it together, it’s not even practical. That is definitely a big misconception. Hopefully people don’t have that in mind.

The other one is end-state vision. I was talking about perfection on my first one. Most of the zero trust work we have done has been around the fact that we have a North Star. We go with the fact that we want to at least have our identity, which is at least our new perimeter that we’re dealing with. We trust that should be zero trust. What that looks like may differ for the risk level of your organization.

Some people are ok with the fact that, for me, zero trust is that Ashish can log in from any device he wants, as long as he has the right username, password, has MFA. Some people may say, actually, that’s not good enough. I want Ashish to be able to come from a laptop that is issued by the company and has the right software, so we can check for endpoint security as well. Or I have a device log that checks for what that device is. It depends on how you would want to approach it.

Depending on how flexible your organization is with that definition of what that could look like for zero trust for you, feel free to make the choice, because no one has really set out that it’s prescriptive architecture for this is how you build zero trust. You would find various examples of people trying to implement their version. The best version is the one that you find that works for your organization, so the best tool for the job.

Obviously, I’ve been caught talking about identity perimeter. The network perimeter is still important. We still have on-premise environments. We still have data centers a lot of us that work in. Network perimeter isn’t gone away. It’s just that now you need additional context around it as well. Some of you may be getting out of network perimeter soon. If you feel network perimeter is not needed, it is still very much needed, because that’s what your trusted zone would be. That was all the misconception. I’m sure there’ll be plenty more. I just wanted to add that in. Don’t buy a product which says zero trust. It’s probably the theme over there.

Zero Trust – Business Use Cases

Business use cases. I did promise you guys, at least you’ll be able to walk away knowing whether you can implement zero trust today, if you have implemented, what else you can add to it. I’m going to go through a few use cases. The first one, which, again, links back to identity. Already, as you can see, there’s a theme coming, human to application. We’ve been doing human to application, username, password, for a long time. To a large extent we trust that the username, password with an MFA or some other verification for trust, were good enough to validate that, yes, this is a really good use case for you to start building zero trust at least with identity in mind.

As I said, based on the risk level of your organization, you may already be doing zero trust because you’re doing IAM with MFA, or federated identity with MFA. Service to service is the next business use case. This is not just your application to application, but it’s also application to your cloud service provider. For people who use Terraform, it could be to your Terraform cloud. It could be to your CI/CD pipeline. There’s a lot more services in play these days, which is not custom, which is not a thick application, which is basically something installed on a server. A lot of the applications these days they have APIs. They allow for you to have a programmatic access to them.

Everything that you do on the cloud service provider is enabled by API. It has authentication. It has allowance for MFA. A lot of the business use case, you would find that they start with human to application, which gets to a point of comfortable, human to application. In this context, humans are internal employees, but for your case, it may be external customers as well who use your SaaS application. Or maybe you’re a bank and I’m a user who complains on the internet about you guys.

That’s probably the most well aware business use case people have been doing for a while. It’s about adding layers based on the foundation we spoke about, what layers would you want to add for zero trust. The same goes for service to service as well. A lot of us may have been doing mutual TLS as a thing between services, two microservices want to talk to each other. You probably want to authenticate them.

If there’s a backchannel, you can use SSL certificates for it. Or you could go down the path of saying, we probably want to have some user that we rotate passwords for. That’s a bit more complex, but mutual TLS usually does the job. What layer would you want to add to that? Would you want to have a trustful network? Would you want to have a data classification down there that, for any external third party, we only want non-personal, non-PII data to go out. Again, how you want to do it for your organization, but that’s what this business use case is about.

Essentially, the OT and IoT environments are probably the next business use case where it’s an environment which has become a very software defined network. You can have APIs there. You can communicate with devices which traditionally would have just been, someone has to walk up there, plug in a laptop and plug a USB and update the firmware. We’ve come a long way from it. There are sensors these days that are available on devices. Think about any physical thing. I’m thinking of a tractor for people in the farming industry.

People in the road whenever you pass the toll gate, that’s basically automated as well. I did an interesting project in Australia where we have motorways, we used to have this massive boom gate, so you never have to tap in, tap off anywhere. Most cars these days are smart enough to have that little tiny box in your car which detects the fact that you’ve passed a gate. The project that we were involved in doing security was around, how do you make sure the information that’s collected on those toll gates on the road, on the highway or the motorway, how do you ensure the integrity of the information coming across?

Because literally, no one’s really standing at every toll gate to make sure no one’s plugged in a laptop in there. It’s like, how do you trust that information? How do you trust the fact that, yes, Ashish did jump into the highway or the motorway in the first gate, came out in the 10th gate, or the second gate? Can he bypass it? There was a lot of interesting scenarios that came up as part of that project. I think for me, that was the closest experience that I had with it. I’m sure your scenario would be a bit more different. We didn’t end up doing zero trust there, I think, but had some principles. That was an interesting project that I got to be part of.

Next one is operator to infrastructure. Operator to infrastructure is a lot more about the fact that I have automation, I don’t want to be, maybe NoOps is a thing, apparently, but we’re very far from it. As much as I’ve tried seeing it, it’s not there. I personally feel that all of us do generally want to get to a point where humans don’t have to intervene a lot in things that can be automated. Even things that are automated these days still requires a human to trigger the action.

The idea behind this is that if there is a known set of processes that we can work with, we should just be able to use them, and it can be just scheduled. I think my alarm at 7 a.m. every morning should just happen every day, for Monday to Friday. I don’t have to schedule it. The use case over here, and I personally have not seen it worked out, but they’ve said some people have done it, but you’re able to get to that point where we are already doing a lot of automation.

How do we get to that automation through zero trust that we don’t have to level up our trust every single time, but we can still do automation. Many of you who may have tried doing automation with MFA, I can tell you, super hard. As engineers would ask you, it gets a bit difficult in a complex environment. I personally haven’t seen this, but it’s a business use case that has been shared publicly on the internet, so I wanted to put that in there.

Last one is human to data. This is more in that privacy space, as well as knowing what data we have access to. I spoke for the data classification earlier, so I probably would not share a bit about this. It’s very obvious what that human data piece is. Last one is probably more important, which is custom applications. A lot of us have legacy applications. Hopefully, no Windows 2000 anywhere, but if there is, you can remove it now. I give you permission to remove Windows 2000 from your environment.

The idea being, we have a lot of legacy applications that we unfortunately still carry, because it’s very critical for our business. A lot of focus for what I spoke about earlier has been around microservices, cloud environments, Kubernetes, containers, but these legacy applications are still required. They are still going to be there for another 20, 30 years. Mainframe probably even longer.

Once you’ve done most of the use cases on the top, you should be able to eventually get to the point where you can actually work on custom applications that you have developed internally, which may just use username, password, which may not even have MFA. How do you develop trust for that? I haven’t seen anyone do that, but it’s the ultimate dream for people who would be able to get there.

Zero Trust – Where to Start

I spoke about foundation. I spoke about misconceptions around zero trust. I’ve spoken about the use cases as well. For some of you who probably have not started this, this is probably a good one to at least set the foundation for where or how you want to go with this. The first one being, reasonable zero trust project goal.

As I was talking about the risk level, your organization may just say, we got the identity pillar covered because we have applications that are authenticating. We have applications that are authenticating and require MFA. No one who’s not an authorized user can access the application. You’re happy with that coarse grain. You don’t want to go fine grain in terms of how much level of checks you’re doing in terms of the user authenticating.

That could be a good enough reason as well. It’s about articulating what that North Star would be for your organization if you were to walk that journey of being zero trust, or at least, when I say, being zero trust more like you want to walk that journey of getting to that end point. What does that North Star look like for you? That is probably the first place I’d recommend you start. Ideally, the identity, my personal favorite is because a lot of us already understand it. It’s already been done.

Human to application, again, another one that is a lot more. We’ve done that for years. Those two are the easiest ones. Networking and data classification, as I’ve spoken about challenges, data, the moment you start the conversation, I at least found that the last time we tried having the conversation, it got shut down really quickly, because who’s going to spend the money to go back to 20 years of data.

That just basically just meant dead end. I totally understand this. It’s not a business use case. Is the upside of having us go through maybe one or two resources looking at 20 years of data, classifying how much we actually care about, how much we don’t care about, and probably spend a whole year on it. Is it really worth the investment, or should we just try and go on this GenAI train? Maybe. It’s a question for the organization. I would say the big two, if my personal recommendation, would be that identity piece and the human to application. Those two are usually good ones to start, because we’ve been doing it for a while.

We already talk about service to service in terms of microservices already. A lot of it has already been done. The foundation is already there. We just need to add what our North Star for zero trust looks like. That would be probably my recommendation for big two. You could totally go down the data path and do other things as well.

This is probably a hard one for everyone, even if developers, security people, documentation is not a thing. Hopefully GenAI is supposed to make it easy. Maybe this is possible now, that we don’t have to document anymore. At least the way I see it is that a lot of us have started walking the path now that most of our environments are supposed to be dynamic. A lot of us may be mature enough that we make changes in environments on a daily basis, on a weekly, monthly, quarterly, much more frequently than what we used to. If you are one of those organizations, you probably are already doing a living architecture diagram where it just keeps changing, or maybe it doesn’t change.

The idea behind zero trust is that, more than the living part, it’s more the flexibility part, where it provides you flexibility to add more layers, rather than make it more stringent. That’s where the living architecture piece comes in. It’s not from a perspective that we have defined that there’s a three-tier web architecture which is going to do all these microservices, API, whatever. It’s more around, how can we give flexibility that we still continue to work at the speed that we have always worked as an organization. That’s where that comes in from.

Other one being, realistic scope to building authenticity. This goes back to the first point, which is the reasonable expectation for what you want your North Star to be. That would help you scope for what you want to cover. Again, if you start the journey for zero trust, it’s not a six-month project. It is definitely going to be a while. I think I have been involved with projects I’ve been running for at least two years, and we’re still doing at least the networking part. Segmentation is what we’re working on still.

Having a realistic scope and the realistic timeline for how long it may take, especially if you’re an enterprise that has been there in the industry for a long time, I would probably have a realistic scope from that perspective. Say, the business wants to know, what’s the return of investment for us going on the zero trust path, because you believe in it, how quickly can you show some points on the board for, yes, we are making progress. Have some realistic scope around it.

Retrofitting versus modernization. This is taken from the whole conversation about moving to cloud, but it’s still relevant. You can retrofit into an existing environment, which is where it goes back to the North Star again, for how you classify zero trust. Whatever you’re doing today, you could add layers of zero trust in there, and that becomes like a business use case.

This is what we understand zero trust to be in our organization, and we’re doing this. This is what we are retrofitting it in. Or, you could do what a lot of other organizations are doing or being forced to do in public sector because of the government narrative, they have to completely change how the network works. They have to completely change how the architecture is done. The choice is made based on the North Star that you would probably end up on. I’m going to throw over DevSecOps here, but it actually is something which we talk a lot about in the security community, because we want to work with developers.

I think the idea is all of us want to create great quality code written for great applications that we all can be proud of. Making security integrated, not by making it a stopper, is definitely something all of us believe in. The same policy or the same thought process is required for the zero trust as well. You would find that not everyone is on the zero trust board. One of the organizations had to reword the zero trust because somehow it came across negative to a lot of people. It was more like, “You don’t trust us. We’ve been working together for 20 years and you don’t trust us?” I’m like, no, I didn’t mean it in the English context, but in general.

Some people had to change the name. You may hear the word high trust sometimes as well. There’s a lot of different variations on it, but the idea is the same, where we believe that this would mean that we’ll have fewer incidents. This would also mean that we can give a lot more flexibility to developers. It doesn’t really matter if it’s work from home or work from wherever, the level of trust can still be heightened easily, and the number of threat scenarios also change quite dramatically as well. That is also the point that I want to call out.

Zero Trust – Business Metrics

Business metrics. Some of you are obviously leaders. Some of you may want to share this with your leaders. This is some of the metrics we basically started working on to start showing the ROI for what’s the point of all this money being invested, especially if it’s going to be invested for a long time. Some of the metrics that helped us, in terms of coverage, was how many applications are already zero trust enabled? If your zero trust North Star is, I want to have all my human to application identity covered for that.

How much coverage do you have across the board for your applications? Maybe you have a data lake. Maybe you don’t have a data lake. Is there a centralized telemetry you can have for all your applications? Do you have a security data lake? Maybe adding another layer. The other part where people also get interested in at least from a security perspective, is that, if zero trust means more security, does that mean that the number of detections I can do for threats are higher? Do they reduce over time?

If they do reduce over time, then the ROI is the fact that before zero trust, we used to be 60 incidents in a day, now we’re down to 10. That’s a great ROI to show to organizations as well. Having some historic comparison for the number of security events, that definitely goes a long way in showing that before the zero trust implementation, this is how good we got. Last one, for security people, is probably a pain, which is the number of false positives we get in the environments. This is across the board for most security products out there as well, that sometimes the first time you implement something, there’s a lot of false positive. Over time, the intent is to reduce it.

Zero Trust – What’s Next?

What is the next step after this? My hope is at least you have some practical understanding of where you want to get to with zero trust. You have some idea of where you may already be for zero trust, and some idea for how you can have a positive impact in your organization for implementing zero trust.

See more presentations with transcripts

Article originally posted on InfoQ. Visit InfoQ

The latest release of the Go language, Go 1.24, introduces several important features, including generic type aliases, weak pointers, improved cleanup finalizers, and more. It also enhances runtime performance in map default implementation, small object allocation, and mutexes handling.

A type alias in Go provides a synonym for an existing type, which can be useful for readability and conciseness. Now, Go 1.24 allows creating type aliases for generic types, that is, a type alias can specify a type parameter.

type ComparableVector[T comparable] = Vector[T]
type ComparableVectorOfInts = ComparableVector[int]
type ThisWouldBeAnError = ComparableVector[[]int]

It’s worth recalling here that Go provides a similar syntax for defining a new type based on an existing type, e.g. type NewInt int. Albeit the syntax only differs in the missing =, the implications are great since NewInt cannot be used in place of int.

Interestingly, the discussion about whether introducing generic type aliases and their implications on the language has been going on for over three years.

Weak pointers do not increase the reference count of an object, so when an object is referenced only by weak pointers, the garbage collector can free it. As a consequence, you should check a weak pointer is not nil before attempting to use its value:

var strongInt int = 5
var weakInt *int
weakInt = &strongInt
...
weakInt.Value()

Weak pointers may be useful when you want to implement, for example, an object cache to avoid objects being retained for the mere fact of being included in the cache.

Go finalizers serve the purpose of cleaning up things when an object is garbage collected. Prior to Go 1.24, this could be accomplished using [runtime.SetFinalizer](https://tip.golang.org/pkg/runtime#SetFinalizer), which has several caveats, including the impossibility of defining more than one finalizer on the same object, the fact that finalizers will not work on objects involved in a reference cycle, and so on. To overcome these limitations, Go 1.24 provides a new runtime function, AddCleanup, which can be used to register a cleanup function with an object:

runtime.AddCleanup(objPointer, cleanupFunc, resourceToCleanUp)
...
func cleanupFunc(resourceToCleanUp CleanUpArgType) {
 ...
}

The cleanup mechanism fixes the issues with finalizers mentioned above. Additionally, it ensures all cleanup functions are called sequentially in a separate goroutine.

As mentioned, Go 1.24 improves the runtime performance of maps. In particular, it adopts SwissTable as a base for map implementation and uses a concurrent hash-trie for the implementation of sync.Map.

Using SwissTable brings 30% faster access and assignment of large maps, 35% faster assignment on pre-sized maps, and 10-60% faster iteration depending on the number and size of items in the map.

Similarly, adopting a concurrent hash-trie enables the new sync.Map implementation to beat the old one on almost every benchmark.

Go 1.24 includes many more improvements and changes than what can be covered here, including new functions in bytes and strings packages, omitzero json tag, directory-limited filesystem access, etc. While the release notes are as usual quite terse you can find great video summaries on Reddit user GreenTowel3732’s YouTube channel.