Cloud as a Story - Vunvulea Radu

 When you're moving SQL to Azure, you'll face a lot of choices. Azure has several different ways you can run SQL, with each own tradeoffs around control, compatibility, cost, and how much day-to-day work is involved. If you focus only on moving quickly, you might end up with higher costs down the road, run into missing features, or give yourself more maintenance headaches than expected. Before you start comparing the different products, step back and think about what you really need to accomplish. As you weigh your options, keep these three big requirements in mind: 1. Scalability and cost shape Decide early on if you'll need to scale up (make a server bigger) or scale out (spread across more servers). Scaling up is usually easier, while scaling out gives you more flexibility, but might mean changing your application and being more disciplined operationally. Think about your workload: if it's pretty steady, provisioned compute is a good fit; if it varies a lot, you'...

 Traditional IT solutions typically remain stable for years, requiring only occasional patches, scaling, or feature additions. In contrast, AI systems operate in a changing environment, so ROI must be monitored and recalculated regularly. Here are the three main reasons for the volatility of AI in Azure and other cloud projects: Models are frequently replaced or retired. In the Microsoft and Azure ecosystem, model families evolve rapidly. A model used last year may become unavailable or inferior. Even without application changes, costs, speed, and quality can fluctuate. Quality can change over time. New documents in SharePoint, evolving policies, and new user questions can impact performance. Without regular updates to your RAG pipeline, prompts, and evaluation sets, accuracy and trust decline, reducing system adoption. Costs can increase with usage. Token cost is only one factor; vector search, storage, observability, and human review become crucial as adoption grows. What appears...

Most people know what ROI means, but it’s harder to calculate for AI projects. The numbers are less predictable than with traditional platforms because many AI projects never reach stable production. IDC says only about 44% of custom AI apps and 53% of third-party AI apps make it from proof of concept to production. That’s why it’s important to look at ROI through a risk lens, not just cost versus benefit. One useful approach is to use a risk-adjusted formula: AI ROI = (AI Business Value Income / (Initial Investment + Annual Costs)) × Success Probability where, >AI Business Value Income (over N years) Consider a 2 to 3 year period and include both direct and indirect value: Direct: time saved, fewer tickets, higher conversion, lower fraud. Indirect: improved customer or employee experience and quicker decisions. For these, use measurable stand-ins like CSAT, churn, time to resolution, or hours saved, and estimate conservatively. >Initial Investment This covers more than just buil...

 Many companies use AI tools such as ChatGPT Enterprise and Microsoft Copilot to raise efficiency and reduce repetitive tasks. However, it is essential to clarify the meaning of the “private” label. In an enterprise setting, “private” typically refers to daily sharing restrictions rather than absolute confidentiality. Organizations may still access these chats for governance, security, or legal reasons. ChatGPT Enterprise OpenAI states that, by default, ChatGPT Enterprise does not use business data (inputs and outputs) to train its models. Customers retain ownership and control over their data, including retention settings. OpenAI also maintains compliance with requirements such as GDPR through contractual agreements, such as a Data Processing Addendum (DPA). Within an enterprise workspace, “private chat” generally means chats are not shared with colleagues, but it does not guarantee that administrators cannot access them. Enterprise plans may use compliance tools such as the Compl...

After 17 years working with cloud technology, I’ve seen a clear pattern. AI projects rarely fail because the model is weak. More often, the problem is that the platform was built for traditional applications, not for AI. GenAI and agents add extra demands on the architecture. AI also brings unpredictable traffic and new security and governance challenges. Here’s a reference architecture I use when designing AI-native platforms on Microsoft Azure. It’s not a strict blueprint, but a practical structure to keep teams aligned and prevent surprises as the solution grows. User and API entry layer Start with a clear entry point. Focus on predictable performance, strong security, and access control. On Azure, many teams use Azure Front Door or Application Gateway for incoming traffic, then add Azure API Management to manage API exposure, throttling, authentication, and versioning. A common mistake is exposing AI endpoints directly to the internet. It might seem quick for a proof of concept, bu...

 For large organizations, Azure success depends on solid governance, clear requirements, planned initiatives, and business priorities. Start with a clear hierarchy to apply rules consistently across the organization, not just to individual projects. First, I set up core elements: management groups, subscriptions, resource groups, and then resources. This structure is practical and important for scaling access and compliance controls. Management groups matter if you have multiple subscriptions and want a uniform baseline. I keep them shallow, three to four levels, since more are hard to manage. Azure allows up to six (excluding the tenant root and subscription level). Assignments at higher levels cascade down, so hierarchy matters. I use subscriptions as boundaries for billing and scaling. Splitting development, testing, and production into separate subscriptions isolates costs and risks. A dedicated subscription for shared network services, such as ExpressRoute or Virtual WAN, simp...

 Cloud AI-Native delivery means turning AI from a basic demonstration into a scalable platform. This requires modern cloud infrastructure, up-to-date & well-organized data, engineering practices suitable for operating AI at scale, and processes to ensure AI is used safely and responsibly. So, what does a company actually need to do to make this work? Build platforms, not just projects A company must design and build reusable foundations. Reliable frameworks have to support products and teams, rather than creating isolated projects. This means the company must be able to create reference architectures, standard templates, clear approaches, and clear processes for how teams work. Security, cost control, and operational monitoring must be built into the platform design at the start, not added later. Modernise applications, not just move them A company must migrate from lift-and-shift systems to cloud-native ones. This calls for skills in refactoring, containerisation, breaking mon...

 By Phase 5, most organisations have working systems. Applications are refactored, data modernised, AI integrated, and governance established. It is tempting to think the journey is over. AI-Native platforms are not classic IT. You don’t deploy and forget. Models drift, prompts evolve, embeddings go stale, costs shift, and user expectations change quickly. This is why Phase 5 is a continual Build–Run–Evolve cycle. In the image I use for this phase, the cycle is simple: Build → Run → Evolve. Behind this simplicity lies a serious message: AI requires automation and operational discipline on par with engineering. Build: Focus on making delivery repeatable, not dependent on individual effort. In AI projects, ‘heroic delivery’ is common: one team member deploys the model, another fixes the pipeline, and a few keep the platform alive. This does not scale. Build means we standardise how we build and release everything: infrastructure, applications, data pipelines, prompts, models, policie...

 During the first three phases of the AI-Native journey, we focus on major engineering tasks. We refactor applications to be cloud-native, update data for RAG and real-time context, and make AI workloads a core part of the platform. At this point, many organizations are excited because the technology is working. Demos are impressive, agents respond, and models help users. However, a new challenge appears: intelligence also brings risk. Without proper governance, the same AI that creates value can also cause harm. This leads to Phase 4, where governance becomes as important as architecture and data. It is not just a compliance task, but a practical way to enable safe AI scaling. 1. Data security and access control become more critical than ever GenAI systems reveal information in ways that traditional applications never could. While a report or dashboard only shows what it is meant to, a GenAI assistant can combine data and produce unexpected answers. If access controls are weak, se...

 In Phase 1, we refactor applications to become cloud-native. In Phase 2, we modernise data so GenAI can work with trusted, fresh, and governed information. But even after these two phases, many organisations still treat AI like a side experiment. A small team builds a model, deploys it somewhere, and the rest of the platform stays the same. This is where real adoption stalls. Phase 3 is the moment when AI stops being a PoC and becomes a native workload inside the platform. It means training, inference, embeddings, retrieval, and orchestration are treated like first-class production components, with the same standards you apply to any critical service: scalability, security, observability, and lifecycle management. 1. Make inference a standard platform capability Most GenAI systems fail in production not because the model is weak, but because inference is not engineered as a real service should be. Inference presents latency, burst traffic, and cost challenges. Deploying it as a VM...

 As Microsoft’s AI platform has grown, so have the terms describing it, which can cause confusion about Foundry, Azure AI Foundry, and Azure AI Services. These tools support different aspects of AI adoption and are designed to work together. One way to look at the difference is that Azure AI Services offer specific AI features, while Microsoft Foundry gives you the platform and structure to use those features effectively as your needs grow. Azure AI Services (Foundry Tools): focused AI capabilities Azure AI Services are ready-made APIs that provide specific AI functions such as analyzing images and documents, recognizing and generating speech, understanding language, translating text, or connecting to large language models. These services are well-suited for scenarios where an application needs a clearly defined AI feature. They can be provisioned individually, integrated quickly, and scaled independently. This makes them ideal for feature enhancements, proofs of concept, and solut...

In Phase 1, we reshape applications so they can scale, change, and integrate intelligence. But even with a perfect cloud-native architecture, GenAI will still fail if the data foundation is weak. This is why Phase 2 is always about data modernisation. In simple words: GenAI is only as good as the data you feed it, and most organisations today still feed it ‘yesterday’. Many companies have data, but it is fragmented. Some sits in SQL databases, some in file shares, some in SharePoint, some in CRM, and much knowledge is hidden in PDFs, tickets, and Teams messages. When you build GenAI on top of this chaos, the result is inconsistent answers and low trust. And then people say, ‘GenAI doesn’t work for us’. Usually, it is not a model problem. It is a data problem. Below is how I see Phase 2, in a practical, structured way. Move from batch to near real-time data flows Traditional data platforms mostly use batch ETL. A pipeline runs overnight, updates the warehouse, and reports are accurate t...

 Multi-agent solutions sound fancy, but the value is actually very practical: you don’t have one ‘super assistant’ trying to do everything. Instead, you have a small team of specialist agents (architect, dev, tester, security, FinOps, writer, etc.). The big question becomes: how do they work together without chaos? That’s what orchestration is about. Orchestration is basically the operating model for your agent team: who speaks, who acts, in what order, and how results are combined. Different orchestration patterns fit different types of work, and choosing the right one can make the difference between ‘wow, this is productive” and ‘Why are these agents arguing and repeating themselves?’ Concurrent orchestration (parallel work) What: Send the same request to multiple agents at the same time, then combine the results. Examples where it fits naturally: Parallel architecture options: one agent proposes serverless, another containers/Kubernetes, and another a data-centric approach. You...

 When organisations tell me they're already in the cloud, I like to ask, 'Are you cloud-hosted or cloud-native?' This difference matters a lot for AI. If you move workloads to Azure without changing them (lift-and-shift), you keep old features like tightly connected parts, local state, vertical scaling, and manual processes. This setup works for everyday tasks, but it often can't keep up with AI inference, agent workflows, or real-time data pipelines. That's why, in our Intelligent Cloud Modernisation for AI-Native approach, cloud-native refactoring comes first. This isn't a complete rewrite all at once. Refactoring means carefully reshaping the system so it can scale, adapt, and safely add intelligence. Cloud-native usually means building strong, manageable systems with containers, microservices, clear infrastructure, and automation. Below is the journey, with examples from the Microsoft ecosystem  that can accelerate each step. 1 Understand what we have (appli...