This shift feels both fascinating and unsettling. Because of that, the need for clear rules and a neutral authority has never been greater. Such a framework must ensure balance so that AI develops in a way that remains fair, transparent, and aligned with human needs.

That need led to the creation of the Agentic AI Foundation (AAIF) within the Linux Foundation in December last year.

AAIF builds open, neutral foundations for agentic AI through collaboration – not control

AAIF mission focuses on neutral governance, open standards, and a collaborative ecosystem. The goal is to prevent a small number of proprietary companies and platforms from dominating AI.

In this context, the Linux Foundation provides reliable infrastructure, much like Linux does for operating systems or Kubernetes does for cloud environments. It ensures that these technologies remain open, secure, and interoperable.

Agentic AI Foundation hosts the Model Context Protocol (MCP), the emerging open standard that defines how AI agents communicate with external platforms, tools, and services. Companies that collaborate within AAIF will help determine which platforms will shape the infrastructure of the agentic AI era. Mazin Gilbert, Executive Director of the Agentic AI Foundation, stated:

The Agentic AI Foundation (AAIF) is the connective tissue, the plumbing behind how agentic systems operate. No one company can define or own these standards. We’ve seen this in cloud native with CNCF and in networking with the LFN. At every inflection point, the world moves from experimentation to production, and that shift needs open standards and community collaboration. With 170+ companies already in AAIF, we’re clearly at that inflection point in Agentic AI today.

What changes in the infrastructure when moving from APIs to AI agent-based systems

To better understand AAIF’s mission firsthand, I interviewed my colleagues, two developers from Infobip, a gold member of the foundation and the publisher of Shiftmag!

Josip Antoliš and Filip Srnec described how agentic AI transformation looks from a developer’s perspective, what changes it brings, which challenges arise, and what AAIF membership enables when it comes to participating in a global AI community.

We began by discussing what changes at the infrastructure level when moving from traditional APIs to AI agent-based systems. Josip Antoliš explained that MCP lets developers assign tasks to AI agents and ensures agents execute them in a standardized way. In practice, service providers who built products through HTTP APIs should now consider exposing the same functionalities through MCP.

In some cases, APIs can adapt automatically into MCP servers.

As an example, he noted that Infobip has open-sourced its own framework for exposing any HTTP API as MCP. He described this as only the first step. He explained that protocols like MCP let different agent systems connect, allowing one AI agent to delegate subtasks to another in a different environment through an MCP call. This makes it easier to build independent agents that collaborate, turning API providers into agent providers.

He also noted that AI agents become more valuable with every new tool they connect to, creating a positive feedback loop similar to network effects:

For example, an AI agent connected to an MCP server that tracks the stock market can analyze trends and suggest actions. If connected to a messaging provider like Infobip, it can send proactive SMS alerts when opportunities appear. Adding a trading tool then allows users to reply and instruct the agent to execute trades. Each new tool increases the value of all previous tools.

API providers are becoming agent providers

Filip Srnec expanded on this perspective by pointing out that Infobip’s mission to reach users wherever they are, through any available channel, naturally aligns with the agentic world. Their communication capabilities allow agents to interact through channels that users already know:

As we like to say, by using Infobip, AI agents gain communication superpowers. This applies across industries: agents that manage flight bookings and reminders, agents that run e-commerce processes, or marketing agents that create meaningful campaigns targeted at the right user segments.

He highlighted that Infobip has developed a range of products in the agent space, such as AgentOS, along with tools for connecting agents, including MCP servers. These solutions bridge the gap and enable agent-driven communication experiences:

From setting up communication through channel activation, sending messages, and feeding responses back to agents, Infobip covers the entire process. In addition, our platform offers advanced message optimization, fraud detection, and communication flow design.

Challenges in adopting MCP

Early-stage ecosystems often lack structure, and MCP is no exception. I asked my interviewees to identify the biggest gaps and limitations they encounter when building production-ready agent systems. Filip acknowledged that the ecosystem still feels unstructured, especially when it comes to adopting new standards and terminology:

I work in the MCP value stream, and we experience this firsthand. The biggest issue is that third-party client software, such as MCP clients, varies in maturity. Because of that, we cannot assume that everything behaves exactly according to the specification.

He added that specifications and terminology evolve quickly in this emerging space. These changes sometimes introduce breaking issues, both intentional and unintentional. Teams must remain agile and constantly balance product delivery with compatibility.

Josip pointed to another challenge. Anthropic originally developed MCP with a focus on coding use cases, particularly for its Claude Code assistant. Some assumptions from that use case remain embedded in the protocol:

For example, one of the two available deployment options requires the MCP server to run on the same machine as the AI agent. That works for servers that manipulate or compile local source files, but it becomes impractical when exposing functionality over the internet.

MCP does support remote servers, which enables broader use cases. Even so, authentication and authorization still require significant effort:

MCP adopted the OAuth specification. While this supports adoption, MCP relies on relatively niche parts of OAuth, which makes full compatibility harder to achieve.

How AAIF helps address these challenges

Since governance of the MCP specification moved to the AAIF, development and priorities have become more open and better aligned with the broader ecosystem, as Josip observed. The 2026 roadmap highlights key improvements such as scalable remote deployment, support for long-running tasks, and stronger enterprise readiness, including observability and integration with existing authentication systems.

These changes should make MCP servers easier to maintain and open the door to more complex use cases and new markets. Josip drew attention to the choice of Streamable HTTP as a transport protocol, which remains somewhat controversial:

Although it limits horizontal scaling, keeping it at this stage helps prevent fragmentation of the ecosystem. Planned improvements in this area will be especially important for DevOps and production environments.

He underlined the importance of support for long-running tasks. These tasks allow agents to manage processes that run for hours, opening entirely new categories of use cases. Improvements in enterprise integrations, especially single sign-on, will prove critical for broader adoption, since current complexity creates real barriers in production environments.

What does it mean to be AAIF member?

When discussing Infobip’s role as a Golden Member of the Agentic AI Foundation, I wanted to understand how this membership influences internal technical decision-making compared to simply adopting external standards.

Josip noted that the AI ecosystem evolves rapidly, and new standards seem to appear constantly. However, standards only create value when people adopt them. By participating in AAIF working groups, his team gains insight into the direction of key industry players:

We contribute by sharing our use cases and drawing attention to the challenges we encounter in our own implementations.

This involvement allows them to align new features and even entire products with the direction in which technology is moving:

Choosing the wrong technological direction can become expensive and create significant technical debt. By participating in AAIF activities, we ensure that we move in the right direction instead of following ideas that lead nowhere.

Through AAIF Josip stressed the importance of bringing real-world use cases into technical discussions from the very beginning. Standards that fail to address real user needs rarely succeed. Early input helps embed key concepts from the start instead of adding them later.

Filip described AAIF membership as a source of confidence and stability in the emerging agentic AI landscape. Open standards like MCP ensure that development does not rely solely on commercial interests. The community develops, maintains, and governs the technology together:

From the perspective of a developer building agent-based applications today, open standards provide strong foundations, best practices, and proven design patterns. This ensures that solutions remain robust and independent of any single vendor.

He pointed out that MCP acts as a universal connector for external tools and data sources. Building on open technologies allows individual engineers to become part of a global community and even influence the future direction of technology.

Filip concluded by noting that global collaboration remains essential at this stage, especially when it comes to reliability and security. The era of agentic AI has already begun. Many agents already operate in production. Now is the time to build a stable ecosystem that allows everyone to develop and use this technology safely.

The post How Agentic AI Foundation and MCP Are Redefining the Infrastructure for AI Agents appeared first on ShiftMag.

Roland Liposinović, Security Governance Generalist at Infobip, sees a critical shift: security should no longer be an afterthought or a compliance checkbox:

Make security a growth tool, not a tax. Build safety in from day one, and audits finish faster, big customers say yes sooner, and purchasing roadblocks disappear.

This mindset shift is one many organizations still struggle to make.

Too often, security is treated as a necessary evil, something to appease auditors and regulators. But Roland argues that security-first development is a competitive differentiator. By integrating controls early, companies can unlock new markets more quickly, shorten sales cycles, and establish trust in ways that directly impact the bottom line.

Security isn’t red tape. It’s quality control for modern, AI-powered products. Trust drives sales. Secure design grows trust over time.

Embed security across the entire development lifecycle

The question, then, is how to embed these practices across the entire software development lifecycle, from planning and coding to testing, deployment, and operations, without slowing down AI-driven innovation.

Roland’s answer is to make security invisible, automated, and developer-friendly.

“Think automatic seatbelts, not checklists,” he says. At Infobip, the team embeds rules directly into their cloud setup and delivery pipelines, ensuring that “the safe way happens by default.” Automated checks scan for vulnerabilities, exposed secrets, risky dependencies, and unvetted model files every time developers save code. If something is off, the build fails fast with clear feedback.

Feedback should arrive in minutes while developers are still working, not days later. Security runs next to the team, not in front of it, blocking the door.

One additional thing you can do before major projects is run lightweight risk assessments focused on a few key questions: How could this feature be misused or abused? What data does it touch? Who could misuse it? This practice, repeated whenever something changes, enables threat modeling to remain fast and continuous.

When it comes to testing, you should test like attackers would. “We throw malicious prompts, poisoned data, and guardrail-breaking attempts at our AI systems before release,” he says. “If our AI misbehaves, we fix it before anyone else can exploit it.”

Make it zero-trust!

AI helps defenders, but it also helps attackers. Adaptive phishing, deepfakes, and model inversion attacks are no longer hypothetical – they’re real. Roland advocates for a layered defense strategy that combines privacy-preserving techniques, governance frameworks, and culture change.

For model inversion, he points to regularization techniques, API access controls, and specialized defenses such as trapdoors to misdirect attackers.

However, data discipline matters just as much: teams minimize personal data, de-duplicate records, and apply strong consent and retention policies before training models. On the human side, Roland is blunt:

Make it zero-trust. Strong login, least privilege, and constant verification for people, services, and AI models.

His team conducts frequent, audience-tailored awareness sessions and real-world drills, ranging from deepfake scenarios to phishing simulations, so that employees can recognize emerging threats.

Strict communication rules help as well: sensitive actions like payments, access changes, and data requests must go through verified channels with two-person approval, never via informal messages or DMs.

If a request is urgent and secret, slow down. We give staff explicit cover to pause and verify even if it is “the CEO” on the line.

Security isn’t a cost center – it’s a revenue enabler

Roland emphasizes measurement as the bridge between technical controls and leadership buy-in. He recommends tracking metrics such as time to close deals, incident rates, audit duration, and verification rates before taking high-risk actions. Mapping controls to established frameworks, such as CIS Controls v8, NIST 800-53, and ISO 27001/27002, streamlines audits and makes funding more defensible.

When you can prove that certifications and clear proof of controls shorten sales cycles and open partnerships, suddenly security isn’t just a cost center. It’s a revenue enabler.

Treat the pipeline like production

As AI accelerates software delivery, the CI/CD pipeline has become the beating heart of modern development, but it has also become an increasingly attractive target for attackers. Roland warns that organizations can’t afford to treat their delivery pipelines as second-class citizens.

Treat the pipeline like production. It runs the factory, protect it like crown jewels.

Securing automated delivery flows starts with proof, not trust. Only signed code, images, and models are allowed through. “If it isn’t signed, it doesn’t ship,” he emphasizes. The system automatically scans dependencies, containers, secrets, and cloud configurations, and it halts the build immediately when it finds critical issues.

Teams isolate access using short-lived tokens and separate runners, eliminating the need for “kubectl from a laptop” shortcuts. The pipelines themselves are under constant surveillance.

Alert on strange runner behavior or workflow changes. If something looks off, pause and investigate before it spreads.

Track behavior, not just components

This rigor extends beyond internal code. As AI ecosystems grow more interconnected, the supply chain, spanning third-party libraries, pretrained models, datasets, and vendors, has become a prime target for sophisticated attacks. Roland advocates for a “trust, but verify” posture.

Track what’s inside. Ship an SBOM with every release, apps, containers, and model bundles, so you know every ingredient.

Teams must sign and verify every artifact, from model files to data packages, before using it. Teams don’t take third-party components at face value; they vet vendors for lineage, update habits, and incident history, and they require formal attestations.

Pretrained or open-source models are quarantined by default until they are scanned, wrapped, and continuously monitored for security vulnerabilities. Once the system is in production, teams can track behavior in real-time.

Don’t just list components, watch what they actually do.

Classify your AI by risk

With the EU AI Act and new data protection laws reshaping the regulatory landscape, Roland sees compliance not as a scramble at launch but as an architectural principle.

Design for the EU AI Act and friends from day one. Classify your AI by risk, attach the right controls, and plan human oversight where it is required.

This regulatory-first mindset drives concrete engineering practices: teams bake data minimization and purpose limitation into schemas and pipelines, not just policy documents. Model cards, decision logs, and clear appeal paths make AI decision-making explainable for both auditors and end users. Teams maintain immutable logs and model lineage with retention policies that align with legal obligations.

Be audit-ready, always. It’s much cheaper than retrofitting compliance later.

Get all signals in one place

As attackers adapt their tactics in real time using AI, defensive strategies must also become equally dynamic. Roland emphasizes the importance of observability, telemetry, and AI-driven defense in detecting anomalies before they escalate.

“Get all signals in one place,” he says. Teams aggregate logs from endpoints, identity systems, APIs, data jobs, and models into a single observability layer. Crucially, security teams monitor not just applications but the models themselves, tracking drift, unsafe outputs, and suspicious prompt behavior.

Detection should be trained on your own operational environment rather than generic threat baselines, so anomalies stand out quickly. When something triggers, automated playbooks in SOAR systems can take immediate action: isolating systems, rotating secrets, revoking tokens, or rolling back versions within minutes.

You can’t wait for a human ticket queue when the attack is adapting on the fly.

Make security a team habit

For all the technology and governance, Roland insists that the real force multiplier is culture. Security can’t live in a silo, it has to become a team habit.

Plant security champions in every squad. Peer-to-peer help beats one central bottleneck.

Regular tabletop exercises tied to real-world projects, such as handling deepfake scams, leaked credentials, or prompt injection attacks, keep teams alert and well-practiced.

Teams can also use positive reinforcement: they can celebrate clean audits, sharp threat models, and early bug catches publicly. To make good behavior the default, Infobip provides “paved roads,” opinionated templates, and secure defaults that make the safe path the easiest one.

With these layered strategies Roland is helping redefine what “secure AI” looks like in practice.

Security isn’t a brake on innovation. It’s what lets you innovate safely and keep that advantage.

The post Want Better Security? Test Like Attackers Would appeared first on ShiftMag.

The CAMARA open-source project delivers standardized APIs for network functions. Developers can now use network features as easily as any REST API. This is not a pilot experiment. Dozens of operators worldwide already support Open Gateway.

The CAMARA community now counts over 47 companies and thousands of experts. Standardization ensures the same API works across borders and operators. Developers can build applications that scale globally and stay portable and scalable.

At this year’s Infobip Shift conference, the panel “Unleash the Power of 5G in Your Code: Transform Your Apps” highlighted a significant shift for developers — bringing the network directly into their code. Korrey Sutherland (GSMA), Markus Kümmerle (CAMARA), and Cedric Gonin (Orange) shared a clear message: it’s time to unlock the power of 5G networks and put it directly in developers’ hands.

Korrey Sutherland

What 5G Networks Can Do for Applications

The panel showed practical cases of a codable network. In insurance, a user reports an incident, accompanied by a photo and GPS data. The API validates the claim, reducing the risk of fraud.

Infrastructure projects also benefit. Operators can use network data to monitor road conditions or guide new developments. Public sector use cases include identity protection and safety measures for children in schools.

One of the most powerful demonstrations came from remote vehicle control. A car in Finland responded in real-time to commands sent from Barcelona, over 3,400 kilometers away. The 5G network and API enabled this with ultra-low latency and reliable connectivity.

Cedric Gonin from Orange added business examples. Companies now process requests more efficiently with APIs, including digital document checks and real-time risk assessments in insurance.

Cedric Gonin

Behind all this progress stands CAMARA. As an open-source project under the Linux Foundation, it standardizes APIs and hides complexity. Developers don’t need to study network architecture or operator differences.

They utilize simple interfaces that are compatible with any device. The result is application portability, faster launches, and entirely new user experiences. The network no longer acts as background infrastructure. It becomes an active tool inside applications.

From Vision to Reality

What once sounded like a vision is now a reality in practice. GSMA Intelligence reported that by mid-2025, over 70 operator groups with nearly 300 networks had joined Open Gateway.

That accounts for approximately 80 percent of the global mobile market. Meanwhile, CAMARA expanded its API library to dozens of use cases. These include identity, location, authentication, quality-on-demand, and edge computing.

Some countries already deploy these APIs. In the UK, operators rolled out age verification and SIM swap protection. In Indonesia, telcos use unified API standards for device security and validation. Developer portals now display which APIs are supported in which countries. Interactive maps, clear docs, and testing tools lower the barrier to entry.

Markus Kümmerle

Developers can focus on value and innovation instead of struggling with network integration. The message is clear. The network is open.

Developers must seize it. With GSMA Open Gateway and CAMARA, applications no longer rely only on the cloud. They can now tap directly into the network. It’s time to unleash the network in your code. Only then will applications reveal what 5G networks can achieve in practice.

Want to know what else was discussed at Infobip Shift at Zadar in 2025? Find out here!

The post $300B Opportunity: 5G APIs Put Networks in Developers’ Hands appeared first on ShiftMag.

Meet Branded Caller from Infobip.

Unlike regular caller ID that might flash a name (or worse, just a number), Branded Caller puts verified, visual brand info front and center. Think: the company’s logo, a recognizable display name, and even a quick note about why they’re calling. No more mystery calls.

For developers, this isn’t just a nice-to-have feature – it’s a serious upgrade to the voice call experience.

By integrating Branded Caller, you’re helping businesses increase answer rates, build trust, and fight fraud, all while working inside a secure and standardized ecosystem built for interoperability and long-term use.

Why developers should care about branded calling?

With call fraud on the rise in the U.S., Branded Caller has stepped up by using cryptographic security under the STIR/SHAKEN protocol to verify caller numbers and significantly reduce spoofing and robocalls.

As Ryan McQueary (Manager of Voice Engineering, Infobip) explains, STIR/SHAKEN is a set of industry standards that enhance call verification by cryptographically signing voice calls – a critical step for ensuring call authenticity.

Here’s how it works from a technical standpoint:

When a call is placed, the originating service provider sends a verification request to an Authentication Service (AS). This request includes key details like the originating and receiving phone numbers, timestamp, and an important metric called the trust level or Attestation Level.

This trust level indicates how reliable the call is:

• Both the network and caller are trusted.
• The network is trusted, but the caller is not.
• Neither the network nor the caller is trusted.

The Authentication Service then returns an Identity Header, which includes a cryptographic signature and certificate. This data travels along with the call through the phone network. Before the call reaches the recipient, the terminating provider verifies this signature and trust level.

Based on the verification results, the provider can decide to mark the call as “trusted,” block it, label it as “SPAM Likely,” or flag it for further action.

For developers, this process offers a powerful way to build secure, trusted communication apps and services that can help businesses reduce fraud while improving customer trust and engagement.

STIR/SHAKEN – one protocol to rule them all

Early branded calling systems, or “legacy” approaches, explains McQueary, relied on a patchwork of databases, carrier deals, and handset partnerships. They showed logos or caller names but were fragmented, lacked cryptographic security, and varied in accuracy across networks and devices.

Legacy systems didn’t securely embed branding into call signaling, and before STIR/SHAKEN, there was no standard way to transport and validate branding across carriers – making calls vulnerable to tampering.

STIR/SHAKEN changes all that.

It builds a higher level of trust for carriers and users by ensuring the displayed brand identity stays legit and can’t be easily faked.

And because STIR/SHAKEN is based on industry – wide standards, it works seamlessly across carriers, mobile systems, and networks. Regulators, carriers, and standards bodies back it as the universal solution, making cryptographically signed branding more trusted wherever calls go.

How do I wire Branded Caller into my stack?

So, how do you plug Branded Caller into your existing setup, and what’s needed to make it work?

First off, Infobip acts as the Originating Service Provider and signs calls using a Signing Agent from the CTIA ecosystem. They picked SecureG to handle this crypto magic, making sure calls are legit and trusted.

Next, they team up with an Onboarding and Vetting Agent, NumHub, which lets customers securely add their brands to the mix. Think of it as the bouncer making sure only the right brands get in.

Security’s no joke here, Infobip runs a strict KYC (Know Your Customer) check before handing out Virtual Local Numbers. They follow CTIA’s standards to keep everything reliable and above board.

And it’s not just about old-school phone calls (PSTN). Infobip also supports cool OTT channels like Viber Business Calls and WhatsApp Business Calling, showing off verified business names and logos. That way, businesses can reach customers wherever they’re most likely to pick up.

Want to learn more about Branded Caller? We’re here to help!

The post Developers, Make Your Calls REALLY Legit with Branded Calling appeared first on ShiftMag.

So, the idempotency… What does it even mean and what makes something idempotent? Is it really that important for good architecture?

Adrienne Braganza Tacke, software engineer, and keynote speaker, explains this ‘secret ingredient’ and shares tools to help make your requests, APIs, or functions idempotent.

Explanation of idempotency – in simple words!

Adrienne shares an example: “My husband and I are on a road trip, and I want to order a cake from a bakery in Las Vegas. I lose a network connection in a tunnel right after placing the order. When I regain connection, I resubmit the order, thinking it didn’t go through the first time. Without idempotency, I end up with two cakes, even though my intent was to order only one.”

This is a simple example, but imagine this happening with something more serious – bank transactions or other critical operations.

So, idempotent in tech means that a certain operation can be applied many times, without changing the result. The lack of idempotency means the system cannot capture the true intent of a request, leading to harmful side effects like duplicate charges or withdrawals.

Idempotency is key to mitigating side effects while solving problems

And what does idempotency have to do with good architecture? According to Adrienne, it has everything to do with it.

Have you heard about the seven design principles of well-architected applications? These principles are:

1. Speedy,
2. Simple,
3. Singular (meaning focusing on doing a single thing at a time),
4. Sharing nothing, specifically in serverless (assuming no state or information sharing between servers),
5. Assuming no hardware affinity,
6. Using events to trigger transactions rather than function chaining,
7. Thinking about concurrent requests rather than total requests.

And the most important one here, claims Tacke, is designing for failures and duplicates. Without idempotency, says she, this principle is impossible to uphold. “Failure is always going to happen. If we keep that in mind, we develop our applications differently, considering edge cases, error handling, and how to deal with inevitable failures.”

So, failures lead to retries – we’ve been solving problems by trying something again, resending something, or turning it on and off again, knowing that retries are part of our toolbox means we need to understand that duplicates can and will occur.

If we’re the ones implementing retries, we are potentially introducing duplicates into our system. And that’s okay, as long as we handle it properly. This is where idempotency is key to mitigating side effects.

How to apply this in our projects?

Adrienne offers three key elements to apply idempotency: an idempotency key, an idempotency layer, and persistent storage.

1. Idempotency Key: This is usually generated by the client and uniquely identifies each request. It could be a unique identifier, a hash of the event, or a timestamp.
2. Idempotency Layer: This acts as a filter in the API layer, deciding what to do with the request by checking if the key has been seen before.
3. Persistent Storage: This stores the state and acts as the source of truth, allowing the idempotency layer to determine whether the request has been processed.

“Applying these, let’s revisit our bakery example. When I place an order, an idempotency key is generated and sent with the request. The API checks this key against persistent storage. If the key hasn’t been seen before, the order is processed, and the result is stored. If the request is retried, the API sees the key, recognizes it, and prevents duplicate processing, ensuring my intent is honored.”

And if you want to try idempotency, AWS Lambda Power Tools is a great resource. They have implementations for TypeScript, .NET, Python, and Java. This library includes features like preventing multiple executions of the same payload during a time window and handling concurrent executions. It uses persistent storage, like DynamoDB, to track idempotency keys and states, making it easier to debug and manage.

She adds that other tools and libraries include Stripe’s API, which has excellent documentation on implementing idempotency, and the idempotent API library for .NET solutions, which uses idempotent decorators to add idempotency to APIs. Finally, Cisco also has products using idempotent requests.

The post Learn about idempotency – the key ingredient for reliable APIs appeared first on ShiftMag.

Not long ago application and API security relied solely on manual methods like knights guarding a castle.

Now, with Agile and DevOps leading the charge and orchestrated ephemeral infrastructure as our new arsenal, we’ve upgraded to a tech-savvy defense, ensuring efficiency and effectiveness like never before.

In this interview, we talk about it with Larry Maccherone, Dev[Sec]Ops Transformation Architect at Contrast Security.

There are almost no dedicated QA departments anymore

“Back in the early days of Agile, I used to advocate for cross-functional teams owning software products, including quality. After these talks, QA professionals would often express concern about their siloed roles, fearing changes if development teams took over quality responsibility, often commenting, “What you said sounds idealistic. It’ll never work at my organization. The developers will just put out crap.”

A decade later, there are almost no dedicated QA departments, and the ones that are left are more of a body shop with all of their people on semi-permanent ‘loan’ to specific dev teams.

Also, we have to remember that back then, developers didn’t do QA the way QA people did QA. “They tried to eliminate all manual testing and replace it with automated testing.”

The DevOps and cloud-native movements were similarly disruptive to traditional IT Ops and were also dominated by automation. Security is now well into a similar tradition which is also marked by more tools deeply integrated into the process.

Shifting the responsibility for security to dev teams

We also asked Larry about the challenges that the industry faces when considering application and API security as a siloed function.

“Siloed functions tend to result in local optimization rather than holistic systems thinking. In systems thinking (referred to as “flow” as the first of three “ways” of DevOps), you try to optimize for value delivery of the entire software development system”, Larry claims.

To get more concrete, Larry says that in a silo, security folks find the vulnerabilities, but they can’t fix them themselves. That leaves them in the position of essentially begging the developers to fix them.

“In this same siloed example, the development teams are measured on how many features they ship. Security is responsible for security. So, the local optimization is to ignore the requests from security to fix the vulnerabilities they found.”

On the other hand, if you shift responsibility for security to the development team, they can optimize for the best overall outcome. Sometimes that means, they can make tradeoffs. At times they might legitimately decide that the risk of not fixing a vulnerability is outweighed by the risk of missing a market opportunity. At other times, they will decide that the security vulnerability fix is the most valuable way to spend their limited resources.

Also, according to Maccherone, developers are prone to automate things, which makes them more efficient overall.

Developers just want their code to be merged

A particular practice that is now universally used by development teams is the pull/merge request. It is the very center of how development teams coordinate their work.

It’s the process of a developer’s morning work reaching the shared codebase by afternoon and ultimately going into production. Almost all automated quality and security checks can (and should) be run prior to the decision to merge that code.

The person clicking on the “merge” button is generally a teammate of the developer for that pull/merge request.

This pull/merge request reviewer, will look at the changes but will also be informed by the automated quality and security checks that were run prior to their review.
Developers are passionate about the code they wrote and want nothing more than for it to be merged. They will see any negative feedback from a security check and respond to it immediately.

Done this way, the vulnerability is often resolved on the same day that it was injected. At this point, the code is very familiar to the developer, so the cost of fixing is an order of magnitude lower, especially when you consider that there was no vulnerability inventory carrying costs.

The situation Larry described above is only possible if each pull/merge request has its own isolated infrastructure for the automated quality and security checks to run.

With traditional methods, having five developers on one team would require maintaining five separate test environments, costly and often idle. Yet, with container-based ephemeral infrastructure, a single developer’s request can spawn multiple workers to conduct quality and security checks simultaneously, completing tasks rapidly and freeing up resources for others.

Technology, practices, and culture

And what about a future Larry sees emerging for application and API security testing?

He emphasized that significant industry transformations, such as the DevOps movement, hinge on three key components: technology, practices, and culture.

In DevOps, ephemeral build and test infrastructure alongside cloud-native technologies represent the technological shifts, while adopting the pull/merge request signifies a change in practices. Culturally, the pivotal shift involves transferring operational responsibilities to the development team.

So, what is the coming revolutionary change for Application and API Security?

It follows the revolution pattern for DevOps, namely those three things – technology, practices, and culture, but it also builds upon the changes that DevOps has brought.

However, before we jump into it, we are going to take a little detour to one discipline that fundamentally changed along with the DevOps movement: performance testing.

Performance testing in production: cheaper, faster, and safer

“Performance testing was long considered a necessary evil. It was expensive and inaccurate, but without it, you ran the risk of having an outage or at least annoyed customers when your application appeared non-responsive.”

Creating a test environment similar to production was necessary, but the closer it mirrored reality, the higher the costs, potentially doubling production expenses.

Then, running extensive automated test scripts in the performance environment incurred high costs, but the real issue was their reliance on artificial traffic, which would lead to inaccurate predictions of real user performance.

“Because of these difficulties, many didn’t even bother with performance testing and took the risk of releasing without it,” Larry says.

Then came technology, practice, and cultural transformations that disrupted the performance testing landscape and avoided all the previous problems. Developers started doing performance testing in production.

The enabling technological change came in the form of application performance monitoring agents that were efficient enough to run in production. The practice change was canary deployments. The cultural shift was realizing that doing performance testing in production was cheaper, faster, and safer than doing it in pre-production when we previously believed you must trade these factors off against each other.

Test your API security in production too

At this point, you might be thinking, “What does this performance testing diversion have to do with the future of application and API security testing?”

Well, what if we can safely accomplish app and API security testing in production?

Doing so avoids the downsides of the current methods:

• SAST’s inaccuracy and long scan times
• DAST and IAST’s poor coverage
• SCA’s lack of context
• WAF’s ineffectiveness

“Like the performance testing of yesteryear, these downsides, along with the cost of licensing, rolling out, and maintaining all of these disparate tools, cause many to skip some or all of them and risk getting hacked. However, to achieve a revolution like this, we’ll need all three elements of the other revolutions: technology, practices, and culture,” Larry emphasizes.

The technological innovation we need is the same as the one we need for the performance testing revolution – agents that are safe and efficient enough to run in production. We’ve been making steady improvements to our IAST agent for years such that it’s an order of magnitude more efficient than it was a few years ago, but we recently beta-released new agents that take a fundamentally different approach when running in production environments, which have improved the efficiency by another order of magnitude.

The practice change is that we need those agents installed by engineering teams in production environments. The cultural transformation is similar to the performance testing one—the conviction that doing application and API security testing in production is cheaper, faster, and more secure than doing it in pre-production.

So, Larry believes we are on the cusp of a revolution in app and API security testing like the one that occurred for performance testing.

The post “Developers should own security. And test in production.” appeared first on ShiftMag.

StackOverflow considers it against the collective collaboration nature of their community and causing significant disruptions to the site.

The freshly announced StackOverflow and OpenAI partnership will allow the AI company to “improve its AI models using enhanced content and feedback from the Stack Overflow community and provide attribution to the Stack Overflow community within ChatGPT.”. 

Translated from corporate lingo – the partnership will allow OpenAI to access the years and years of StackOverflow’s community contributions to train its AI model. Many users are unhappy with their answers being used to train AI and have started deleting them.

Some users have shared emails they got from StackOverflow, which banned them from the site for seven days because deleting contributed content causes “a lot of disruption” and warns them against further deletion. As much as the users are angry about it and claim they have the right to manage the content they created, StackOverflow’s Terms of Service contain a clause that states they have irrevocable ownership of all content members provide. 

The public announcement of the partnership does mention that it will enable ChatGP to provide attribution to the Stack Overflow community. Still, long-time StackOverflow users doubt the developer community’s sincerity regarding AI, as they have already changed their minds. 

For the last two years, StackOverflow has been trying to downplay the significance of AI tools and prove their supremacy in providing knowledge to developers compared to ChatGPT – they have even launched their own AI product, OverflowAI, in an attempt to counteract developers flocking to get instant answers from ChatGPT instead of searching on StackOverflow.

They have started praising the power of AI tools lately and a new set of new integrations and capabilities between Stack Overflow and OpenAI have been announced as part of this partnership that will be available in the first half of 2024. 

The post Do not delete: StackOverflow bans users protesting their OpenAI partnership appeared first on ShiftMag.

Mary Thengvall, Director of Developer Relations at Camunda, Matt Billman, CEO & Co-founder at Netlify, and Eric Schabell, Director of Technical Marketing & Evangelism at Chronosphere, are just some of the highly coveted pioneers and innovators within the global developer community who will take the stage at the iconic Perez Art Museum.

With over 500 attendees expected in 2024, Infobip Shift Miami is poised to solidify its place as a beloved annual gathering within the American developer community.

This year’s Infobip Shift Miami expands on the success of last year’s event. We’re dedicating a full day to lectures and panels, with networking on day one and hands-on workshops on day three.

Nikola Radišić, Head of the Infobip Shift team

Expanding its horizons, the conference now shines a spotlight on software with a thematic focus. This spotlight centers around APIs, the backbone of swift and seamless software operation. These APIs are not just vital; they’re indispensable tools for developers across various industries. Radišić says:

We chose to hone in on APIs due to their status as a burgeoning and incredibly vital sector within the software industry – an indispensable component for envisioning a modern developer profession. We aim to provide the audience with insights into the latest tools and solutions, empowering them to optimize their skills and stay ahead in the world of software development.

By expanding the program in this year’s edition, we cement our commitment to connecting and supporting developers worldwide.

Nikola Pavešić, Director of Developer Experience and Startups at Infobip

Get your ticket!

Calling all developers, tech aficionados, and industry experts!

Win a ticket for Shift Miami, from April 22nd to 24th, 2024.

The post Win 1 of 15 tickets for Shift Miami 2024 – and explore APIs! appeared first on ShiftMag.

In his talk at the Shift Conference in Miami, experienced Developer Experience Leader Jeremy Meiss will focus on some of the principles of DevOps and how a strong DevEx mindset can bring Dev and Ops together.

We talked about it in more detail.

Platform Engineering is revolutionizing by creating tailored environments for developers

Jeremy believes Developer Experience extends beyond just the frontend experience, so we asked him what DevEx is for him.

“DevEx encompasses the journey of developers as they learn and deploy technology”, he says.

When it achieves its goals, it aims to remove barriers that impede developers or practitioners from succeeding in their pursuits.

DevEx, is a vital aspect of your systems, encompassing all the ways developers interact with them, not just the frontend.

It directly influences developer productivity, satisfaction, and the quality of the products they build. The choice of development tools, technologies, and platforms significantly impacts DevEx.

Because of this, he adds, it is essential to factor in the ease of use, reliability, accessible documentation, build efficiency, testing effectiveness, and deployment smoothness to optimize the overall dev experience.

And how does platform engineering fit into that picture?

“A robust DevEx is essential for effective collaboration between DevOps teams, and Platform Engineering is a direct result of understanding this. The rise of Platform Engineering represents a paradigm shift towards creating comprehensive environments specifically catering to developers’ needs”

According to Meiss, this movement abstracts the complexities of infrastructure and backend services, allowing developers to focus on creating innovative value.

With access to scalable and easy-to-use platforms, developers can streamline development processes, reduce setup time, and eliminate the toil for developers (and practitioners) which leads to a reduced, or negative, experience.

There is no DevOps without collaboration, communication, and shared responsibility

Jeremy also described what he thinks are the core principles of DevOps: Collaboration, Communication, and Shared Responsibility:

“Without these principles in place, it won’t matter what tooling you choose – you will struggle to have a good developer experience for your teams”.

When considering the integration of DevOps and DevEx, and after implementing the foundational principles within your organization, you’ll begin to notice the brilliance of DevEx shining through.

We can think about it this way, says Meiss:

• Collaboration: With a good collaborative culture in place, you’ll be able to utilize the right tools and processes (for YOUR business) together that make it easier for developers, operations, and other stakeholders to work together. This includes IDEs, version control systems, and collaboration platforms for real-time co-editing and issue tracking.
  
• Communication: Once you have the culture and processes in place for honest and intentional, communication and feedback across teams, you’ll be looking at the tools and platforms that streamline that information sharing and feedback. That would include CI/CD, shared dashboards, automated alert systems, etc.
  
• Shared Responsibility: When you have a culture where all team members are collectively accountable for the software’s quality and reliability, you’ll be able to empower them with access to the tools and information necessary to contribute across the entire software lifecycle. This includes, but is by no means all-encompassing, access to deployment and monitoring tools as well as quality assurance, security, and performance optimization.

How can UI/UX Design and API Documentation elevate DevEx?

We also asked Jeremy what role UI/UX design plays in shaping Developer Experience and how it can be optimized for developer productivity.

“When you have well-designed interfaces for development tools and code, it can have a profound impact on a developer’s workflow”, he thinks.

To ensure a seamless development process, it’s crucial to prioritize clear and intuitive UI elements, consistency, and usability. A well-structured UX that emphasizes the discoverability of features and functionalities is necessary to reduce friction, optimize development time, and ultimately boost productivity.

By focusing on problem-solving and coding tasks, he adds, developers can achieve greater efficiency, making a significant and positive impact on their workflow.

And when it comes to APIs, how do you ensure they contribute positively to Developer Experience, particularly in terms of ease of use and documentation?

Jeremy says that when you give a developer access to an API to interact with your systems, services, and tools, you’re directly having an impact on their experience. “If the documentation differs in any way from how the API works, your chances of a developer having a positive experience goes down dramatically”, he emphasizes.

To ensure a positive experience, make sure that you extensively test each of the endpoints against the documentation, and conversely, the documentation matches up.

A good step would be to also have the least technical persons in your company participate as part of your documentation validation process. This helps find the core parts missing to ensure a developer achieves the first “path to joy” necessary to get them to dive deeper into your tool.

Finally, we wanted to know how Jeremy advocates for and prioritizes Developer Experience within an organization.

“A developer’s experience with a tool can be found, and sometimes influenced, via the team that is designed to be most closely linked with them: your Developer Relations (or Advocacy or Community) team!”

DevRel and DevEx, says he in conclusion, are so intrinsically mixed and rely so closely on each other that it is hard to separate them.

“As a result, it is extremely important that the DevRel team establish and participate in the feedback cycle. One way to accomplish this is to bring specific, non-anecdotal feedback (complete with names, the company they work for, job title, use case, etc.) to the Product and Engineering teams and then continue to interact with the feedback and close the loop back to the user when a decision has been made.”

The post DevEx is not just about frontend experience – it’s crucial to DevOps success appeared first on ShiftMag.

This year’s Shift Conference in Miami is approaching, and we took the opportunity to speak with Katie Miller, the MC of this year’s conference and Developer Relations Advisor in Data Protocol.

Keep reading because we asked her a burning question: what do developers prioritize while working for a company?

Top 3 things developers seek

According to Katie, the answer to a previous question can be found within the question itself: “What should companies keep in mind when building products for developers or when making technology purchasing decisions for their developer teams?”

So, when devising developer marketing strategies, she prioritizes three key considerations for this audience. Developers seek:

1. Opportunities to solve interesting problems;
2.  The tooling, documentation, and space to tackle said problems;
3.  Minimal “work about work.” They want systems and tools that minimize distractions, letting them focus on building transformative products.

To achieve this, it’s essential to gather feedback from them. Here is Katie’s strategy:

At a macro level, I recommend deep reads of global annual surveys from organizations such as StackOverflow, SlashData, Evans Data, and the Annual State of Developer Relations Survey. At a micro level, I advise using more custom information gathering through customer 1:1s, surveys, focus groups, advisory boards, social listening, and communities and forums.

For the latter task, she adopts a perspective of listening and empathy. She ensures that feedback channels effectively convey collected information to the relevant teams. Additionally, in appropriate forums, she establishes a response loop to keep participants informed of progress and outcomes.

Developers demand reliability and stability

However, it’s common for companies to struggle with sustaining a high level of new developer experience. They often fall into the same pitfall – going to General Availability before you’re ready (with ready including having documentation and support ready to go).

“If the product usage data and feedback you’re getting from developers in early adoption phases suggests that critical roadblocks and misunderstandings exist, the product is not ready to be released to a large audience, particularly without the “beta” flag attached to signal that it may be incomplete or unstable”, explains Miller.

The second common mistake is announcing sunsets and deprecations without proper communication, often catching people by surprise.

Developers expect a degree of reliability and stability in the products they use to build applications. They know change will happen, but need ample time and support resources to make the changes with minimal disruption to their end users.

Another crucial aspect, according to Katie, is ensuring that pricing strategies and rate limits are meticulously thought out and communicated, particularly in the current climate where every purchasing decision is closely scrutinized and requires thorough validation. Similar to rushing to General Availability prematurely, if feedback isn’t adequately integrated into the pricing strategy and if there isn’t thoughtful and comprehensive communication planned to share it, it can significantly erode developer trust.

DevRel is not just a nice-to-have

Having worked at Google for over 15 years, we also inquired about Katie’s perspective on Google’s approach to developer experience, including their key principles and methodologies.

The most significant lesson she emphasizes is the critical role of Developer Relations within a business. According to Katie, Developer Relations is not merely a nice-to-have. It’s essential for shaping developer product strategy and driving the adoption and amplification of those products.

You need to make sure that the team has a range of skills and functions (advocates, engineers, technical writers, program managers) and that it sits in a part of the organization that will champion it and set it up to have the most impact.

When focusing on developers as the main audience for products or services, she believes it’s important to remember basic marketing principles, as simplified by Google’s CMO: “knowing the user, knowing the magic, and connecting the two.”

“I begin with research. Understanding both macro trends and company-specific audience insights is crucial for shaping product strategy, messaging, positioning, and determining outreach channels and programs,” she explains.

Once these insights are collected and have gone into shaping product and program strategy, I ensure that the marketing assets and campaigns are built to communicate how the offerings solve actual problems, with transparency and honesty, and the resources to know how to make progress through the adoption funnel (with tracking and measurement built in, of course!).

APIs streamline tool inefficiencies

When it comes to creating clear and usable documentation for developer tools, Katie’s advice is to follow the three patterns she has seen hold steady over time:

• Strong search functionality;
•   Minimizing the need to bounce around to find all of the necessary resources to progress from awareness to curiosity, to experimentation, and to production;
•   Being intentional about when to require sign-ups to access content, making sure there’s exceptionally strong value offered if anything is behind a login gate.

“One note: with the shift to using chatbot technologies like ChatGPT and Gemini, I imagine that not only strong search functionality but also accurate and reliable synthesized results are expected,” she adds.

We also asked her to elaborate on the significance of APIs in developer relations and product development, and we struck gold. This topic resonates with her deeply, as it underscores why developers are crucial to business success.

From a SaaS perspective, APIs are what connect everything together so that the inefficiencies of so many tools can be minimized. From a consumer perspective, they are what allow apps and website experiences to be secure, complete, and powerful without companies needing to solve problems outside of their wheelhouses.

“Thankfully, there are outstanding resources out there, such as this recent blog post from Draft. dev for how to create exceptional developer documentation. In terms of distribution, some tips include adding key links in blog posts, video descriptions, and QR codes in event presentations (protip: don’t forget to add UTM parameters so you can also track traffic from each unique source!)”, she concludes.

And don’t forget, you can meet Katie at the Shift Conference in Miami. Join us on April 23 and 24 2024!

The post Priorities and pitfalls in developer satisfaction by Katie Miller appeared first on ShiftMag.