标签：#Azure

Microsoft is placing greater emphasis on controlling disruption in Azure Kubernetes Service (AKS) Node Auto-Provisioning (NAP), publishing new guidance to help platform teams balance the efficiency benefits of automated node consolidation with application availability. By Craig Risi

You shut the VM down to save money, and next month it is still on the bill. This is one of the most common Azure billing surprises, and it comes down to a distinction Azure does not make obvious: there is a difference between a VM that is Stopped and one that is Stopped (deallocated) , and only one of them stops the compute charges. Here is exactly what is happening, and the cost that survives even when you do it right. Stopped vs Stopped (deallocated) Azure has two "off" states, and they bill completely differently. Stopped (from inside the OS). If you run shutdown inside the guest OS, the VM powers off but Azure keeps the compute resources allocated to it. The status shows Stopped . You are still paying full compute price for a VM doing nothing. This is the trap. Stopped (deallocated). If you stop the VM from the Azure Portal, CLI, or PowerShell, Azure deallocates it, releasing the underlying compute. The status shows Stopped (deallocated) , and compute billing stops. So the rule: shutting down from inside the guest does not save you money. You must deallocate, and deallocation only happens when you stop it through Azure, not through the OS. # This deallocates and stops compute billing: az vm deallocate --resource-group my-rg --name my-vm # Inside-the-OS "shutdown" does NOT deallocate. Status stays "Stopped", billing continues. Check which state you are actually in: az vm get-instance-view --resource-group my-rg --name my-vm \ --query "instanceView.statuses[?starts_with(code, 'PowerState')].displayStatus" -o tsv If that returns VM stopped you are still paying. If it returns VM deallocated you are not paying for compute. The disks nobody mentions Here is the part that catches people even after they deallocate correctly: deallocation stops compute billing, not storage billing. The managed disks attached to the VM (the OS disk and any data disks) keep costing money whether the VM is running, stopped, or deallocated. A deallocated VM with a 512 GB Premium SSD is still

Your datacenter needs to talk to Azure. You can send that traffic through an encrypted tunnel over the public internet, or over a private circuit that never touches it. That single choice — shared road or private rail — decides cost, speed, and reliability. Almost every organization moving to Azure keeps something on-premises, and those two worlds have to connect privately. Azure gives you two hybrid-connectivity options, and they take opposite routes to the same destination: VPN Gateway and ExpressRoute . Understanding them is really understanding one question — does your traffic ride the public internet, protected by encryption, or a dedicated line that bypasses it entirely? VPN Gateway: an encrypted tunnel over the internet Microsoft's description is exact: Azure VPN Gateway "can be used to send encrypted traffic between an Azure virtual network and on-premises locations over the public Internet." Your traffic still travels the ordinary internet, but inside an IPsec/IKE tunnel, so it is private even though the road is shared. It comes in a few shapes: site-to-site (your datacenter's VPN device to Azure), point-to-site (an individual remote worker to the VNet), and VNet-to-VNet . It is quick to stand up, needs no third party, and is inexpensive — the pragmatic default for dev/test and small-to-medium production links. ExpressRoute: a private, dedicated circuit ExpressRoute takes the other road entirely. It "lets you extend your on-premises networks into the Microsoft cloud over a private connection with the help of a connectivity provider." The defining fact: because ExpressRoute connections do not go over the public internet , they offer "more reliability, faster speeds, consistent latencies, and higher security than typical connections over the internet." You are not tunnelling through shared roads; you have a private rail line into Microsoft's network, arranged through a connectivity provider. That extra reliability and consistency costs more and takes longer t

Link to the Source Code As a data engineer, I spend my days designing clean, optimized data structures. But at home, I face a much tougher crowd: my family. We manage our shared finances together to optimize our budget, and because of where we live and work, we have to do this in several different currencies (like USD, EUR, CZK, and UAH) Like any developer, I first tried to find a ready-made app to solve this. But I ran into a classic problem: they were either bloated with a million features we didn’t care about, or they were missing the exact features we actually needed. So, we did what any desperate family does: we opened a Google Sheet . We tracked our money there for a while, not because it was perfect, but because it helped us figure out what we actually needed from a real application. It was our "living schema design" before I wrote a single line of code. In this article, I want to show you how I looked at this problem from two sides—as a frustrated user who just wants to log expenses, and as a data engineer obsessed with clean database design. Here is the story of how I built our custom home accounting server. Part 1: Django, a Star Schema, and the Framework Battle By 2025, I was ready to replace our Google Sheet. My main programming language is Python, so I had three realistic choices: FastAPI, Flask, or Django. FastAPI is the cool kid on the block for high-speed APIs, but we didn’t expect millions of requests (unless my family suddenly grew by a factor of a million). We also needed a friendly web UI, which FastAPI isn't naturally built for. I had just used Flask for my previous project, but I wanted to challenge myself and learn something new. Django felt like an old friend I hadn't seen in years. It has amazing built-in tools (like the admin panel and great translation support), and using it was the perfect way to refresh my skills and grow as a developer. The Database: Why a "Star Schema" Actually Makes Sense As a data engineer, I didn’t want a messy data

When someone asks whether to use Azure OpenAI Service or the direct OpenAI API, the starting point is this: the models running on both platforms are identical. GPT-4o, GPT-5, and the o-series models you deploy on Azure have the same weights, the same capabilities, and the same output quality as the ones you call from platform.openai.com, and what changes between the two platforms is the infrastructure where they run, the authentication mechanism, and the compliance guarantees the provider can offer on those requests. What changed in 2026 Azure AI Foundry was renamed Microsoft Foundry on January 1, 2026, and Azure OpenAI Service now lives inside that unified platform alongside the model catalog, development tooling, and agents. References to Microsoft Foundry in new documentation point to what used to be Azure AI Foundry. In July 2026, the GPT-5.6 family arrived with Sol, Terra, and Luna available on Azure the same day as on the direct OpenAI API. Historically Azure lagged four to eight weeks behind new model releases because Microsoft validates them within their compliance frameworks before making them available, and while that gap still exists for some specific features and APIs, for the main models in the GPT-5 family availability is converging. Where data is processed When you call GPT-4o from the OpenAI API, the request goes to OpenAI's own infrastructure, which is centralized and gives you no control over which region processes your data. For most use cases that doesn't matter, but for organizations with data residency requirements, regulatory compliance needs, or industries like healthcare, banking, or government, that detail can determine whether the service is usable at all. Azure OpenAI runs the same models within the boundary of your Azure tenant, so the data you send in prompts doesn't leave to OpenAI's infrastructure but processes in the Azure regions you choose. That's what makes it possible to meet HIPAA, SOC 2, EU data residency, and other certificati

Building a Scalable, HIPAA‑Compliant Healthcare Document Processing Pipeline in .NET & Azure Quick Answer A deep dive into architecting a production‑grade Healthcare Document Processing Pipeline—covering AI extraction, FHIR integration, vector search, and compliance at scale. In my experience, the biggest cost is not the AI model, but the orchestration that turns raw scans into audit‑ready FHIR resources. The right mix of services can reduce latency by 30‑50% while keeping the bill below 10% of the raw compute budget. Choose services that expose a BAA and native hybrid search (Azure Cognitive Search) to avoid a second compliance layer. Prioritize deterministic scaling (Container Apps + Aspire) over elastic serverless when real‑time SLAs are tight. Version your embeddings; treat the vector index as a first‑class contract. HIPAA‑Ready High‑Volume Document Ingestion When a health system starts ingesting thousands of paper‑to‑digital documents per day, the naïve “scan‑and‑store” approach quickly becomes a compliance and performance nightmare. The real challenge is to produce HIPAA‑ready, FHIR‑compliant, low‑latency data that can be consumed by downstream clinical decision support or billing systems. Compliance is not a checkbox; it’s a series of audit trails that must survive a 30‑day retention policy and survive a forensic review. In production, the cost of a single PHI exposure can exceed the annual budget of the entire platform. Real‑World Example Consider a mid‑size hospital that receives 25,000 inpatient discharge summaries, 8,000 lab reports, and 12,000 imaging PDFs every month. Each document is a mixture of scanned images, PDFs, and legacy forms. The billing team needs structured diagnoses and procedure codes within 30 seconds to avoid claim denials, while the analytics team wants similarity search for rare disease cases in the last 12 months. The pipeline must: Extract structured entities with ≥95% accuracy. Redact PHI in transit and at rest. Provide audit logs

The cloud ecosystem in 2026 isn't just about moving VMs to the public cloud—it's heavily driven by hybrid operations, unified security telemetry, AI integration, and complex governance across multi-region architectures. As enterprise tech stacks evolve, Microsoft Azure certifications remain a primary yardstick for technical competence, but knowing which track to target is where most engineers get stuck. As someone who works closely with cloud certification blueprints and enterprise deployments, I wanted to map out where Microsoft credentials stand today, what the market actually demands, and how specific exams fit real-world scenarios. Market Trends: Why Azure Credentials Still Drive Real ROI in 2026 The value of certification has shifted from basic feature recognition to proving operational problem-solving under real constraints. Hands-on Scenario Focus: Exams increasingly test scenario-based trade-offs—balancing performance, cost, and strict security requirements rather than simple definition checks. Role-Based Specialization: Instead of broad, generic tracks, Microsoft continues to refine specialized pathways for developers, security analysts, and hybrid infrastructure specialists. Continuous Free Renewal: Earning the badge is step one, but maintaining active status requires passing annual, open-book renewal assessments directly through Microsoft Learn, ensuring skills don't stall out. Mapping Azure Exams to Real-World Enterprise Scenarios Depending on your daily engineering focus or career targets, here is how the core role-based tracks align with active projects: App Modernization & Cloud-Native Dev: AZ-204 (Azure Developer Associate) The Scenario: Refactoring monolithic legacy apps into containerized microservices using Azure App Service, Azure Functions, and Cosmos DB while setting up secure authentication via Microsoft Entra ID. Hybrid Infrastructure & Server Ops: AZ-800 (Administering Windows Server Hybrid Core Infrastructure) The Scenario: Managing mixed e

With the Azure Kubernetes Services (AKS) platform, containerized workloads can be efficiently managed and scaled. However, the full potential of AKS is only realized when it is seamlessly integrated with other Azure services. This enables a complete cloud-native environment that is scalable, secure, and automatable, while providing maximum flexibility. In this final post of the series, we will show you how AKS can be integrated with other Azure services to create a robust and holistic platform for your applications. Why Integrating AKS into the Azure Cloud Is Crucial AKS provides a highly available and scalable infrastructure for managing containerized applications. However, integrating it with other Azure services like Azure DevOps, Azure Monitor, Azure Active Directory (Entra ID), and Azure Storage extends functionality and optimizes workload management. By leveraging Azure services alongside AKS, companies can: Ensure enhanced security for their containerized applications. Build robust monitoring and logging solutions to monitor the state of applications at all times. Set up automated pipelines for deployment and scaling. Seamlessly exchange data and status information across various Azure services. Key Azure Services to Integrate with Your AKS Platform Azure Active Directory (AAD) for Authentication and Security Azure Active Directory (AAD) provides comprehensive identity and access management that can be directly integrated with AKS. This ensures that only authorized users and services can access your Kubernetes clusters. With Azure RBAC (Role-Based Access Control), you can define granular access permissions for different users and teams, increasing the security of your environment. AAD Pod Managed Identities enable your AKS applications to securely access Azure resources like Azure Key Vault or Azure Storage without the need to manually manage sensitive credentials. Azure DevOps for CI/CD Pipelines Azure DevOps is one of the best solutions for automating CI/CD

The Problem In one of our Azure DevOps pipelines, nuget restore suddenly started failing with an error stating, in essence, that the requested package could not be found in the referenced version. The task referencing the package hadn't changed — yet the restore stage kept failing. At first glance, this looks like an issue with the package source, some caching effect, or a broken .nuspec/lockfile. It wasn't. The Root Cause The actual culprit was the version of the NuGetToolInstaller@1 task itself. The pipeline had NuGet pinned to version 6.12.2. The Fix Bump the versionSpec in the NuGetToolInstaller@1 task from 6.12.2 to 7.9.0: - task : NuGetToolInstaller@1 displayName : ' Use NuGet 7.9.0' inputs : versionSpec : 7.9.0 checkLatest : false That's it. After the update, nuget restore ran through cleanly again.

Originally published at prepstack.co.in Part 4 of 4 — 14 Years of Enterprise ASP.NET (finale). Where the system actually runs: choosing Azure architecture by cost and scaling profile, making the system observable, and treating AI as a real architectural component — not a demo. Running example: Mattrx — .NET 9 / ASP.NET Core, 110k MAU, Azure SQL, ~3,200 req/sec peak. Lesson 10 — Azure: match the platform to the workload Pick the compute by your scaling and operational profile, then right-size — don't default to the biggest box or the trendiest platform. Most enterprise .NET runs perfectly on Azure App Service; you reach for Container Apps or AKS when you have a specific reason, not because Kubernetes is on your résumé. The decision framework: App Service for standard web/API (default), Container Apps when you want containers + scale-to-zero without running a cluster, AKS only when you genuinely need its control plane and have the ops capacity. A 5-person team has no business running Kubernetes. Over-provisioning is the most common and most invisible cloud waste — it never pages anyone, so nobody fixes it. Right-sizing the web tier (P2v3×6 always-on → P1v3×2 + autoscale), moving to managed Redis, and tuning the SQL tier saved roughly $2,000/month total — with better peak headroom, because autoscale handles the month-end burst the fixed fleet was over-sized for. Lesson 11 — Observability is essential For years I "had logging" and was still blind in production. The shift from logging to observability — answering new questions about a running system without shipping new code — is the difference between a 4-minute incident and a 4-hour one. You can't fix what you can't see, and you can't see what you didn't instrument. Three pillars, tied by a correlation ID: logs (what happened), metrics (how much/how often), traces (where the time went). // structured fields + a correlation scope so every line in the request is linkable using ( logger . BeginScope ( new Dictionary < str

n today's world of cloud-native development, businesses require powerful, scalable, and flexible platforms that help developers efficiently build and operate their applications. An Internal Developer Platform (IDP) based on Azure Kubernetes Services (AKS) provides an optimized environment that brings together all the key components for modern software engineering. This article explains how to develop such a platform using AKS, what key components are required, and how to integrate them optimally. What is an Internal Developer Platform (IDP)? An internal developer platform is a set of tools, processes, and automations provided to developers to simplify the entire software development process. It offers a standardized environment where developers can write, test, and deploy code without worrying about the infrastructure or underlying complexities. An IDP built on Azure Kubernetes Services (AKS) also allows for the operation of containerized applications in a fully managed, highly available, and scalable environment. Core Components of a Development Platform on AKS When building an internal developer platform based on AKS, several key components ensure an efficient and robust system. Here are the essential elements: Azure Kubernetes Services (AKS) as the Central Platform AKS forms the core of the development platform. It provides a scalable and managed Kubernetes environment where all containerized applications run. With full integration into other Azure services, developers can access a wide range of tools to efficiently manage, monitor, and scale their workloads. Service Mesh for Managing Microservices Communication In a microservices architecture, which is commonly used in modern cloud-native applications, communication between services plays a crucial role. A Service Mesh like Istio or Linkerd enables the management and monitoring of this communication. It provides features such as load balancing, traffic management, security policies, and monitoring for microservi

Digital transformation has led companies to organize their infrastructure and development processes in entirely new ways. To address the challenges of modern cloud-native applications, concepts like Platform Engineering are gaining increasing importance. Especially in environments using Azure Kubernetes Services (AKS) , platform engineering plays a crucial role in efficiently managing and scaling containerized applications. What is Platform Engineering and Why is it Important? Platform engineering is the process of designing, implementing, and managing internal platforms that provide developers with a stable and efficient environment. These platforms bundle all the necessary resources and services to ensure smooth development and operation of applications. A well-developed platform engineering team ensures that recurring tasks are automated, allowing developers to focus on writing code without dealing with the underlying infrastructure. In a container environment like AKS, automation and standardization are critical. Platform engineering provides the framework to simplify these complex workflows. How Does Platform Engineering Support AKS Deployments? A key advantage of platform engineering is the ability to standardize the entire lifecycle of applications—from development to testing and deployment. When working with AKS, the main task of the platform engineering team is to create a seamless and scalable environment for container orchestration. Here are some key aspects of how platform engineering supports AKS: Standardizing and Automating Deployments Platform engineering enables the automation of Kubernetes cluster deployments in AKS using best practices and tools such as Infrastructure as Code (IaC) (e.g., Terraform or Azure Resource Manager templates). This automation reduces human errors and accelerates the time needed to deploy applications in production environments. Self-Service Platforms for Developers A well-designed platform engineering team builds self-ser

In today's digital world, businesses face the challenge of developing, deploying, and scaling applications faster and more efficiently. One of the key technologies supporting this transformation is container technology. What are Containers and Why Are They Important? Containers allow applications to be packaged into lightweight, self-contained, and portable units that can run consistently in any environment—from a local development machine to a cloud platform. This reduces dependencies and significantly simplifies application deployment and scalability. Unlike virtual machines (VMs), containers share the operating system kernel, making them more resource-efficient. This leads to higher efficiency and allows businesses to run more applications on the same infrastructure. Introduction to Kubernetes: Orchestration of Containers While containers represent a revolutionary approach to developing and running applications, it’s not enough to simply have containers. Once applications consist of dozens or hundreds of containers, managing, orchestrating, and scaling them becomes critical. This is where Kubernetes comes in. Kubernetes is the world’s most widely used container orchestration platform. It enables the automatic deployment, scaling, and management of containerized applications in clusters. With Kubernetes, companies can ensure their applications are always available, automatically recover from failures, and roll out new versions without downtime. Azure Kubernetes Services (AKS): Kubernetes in the Cloud Azure Kubernetes Services (AKS) is Microsoft’s fully managed Kubernetes solution. With AKS, businesses benefit from simplified Kubernetes deployment by offloading infrastructure management to Microsoft. This means you can focus on developing and scaling your applications while AKS simplifies the management and maintenance of Kubernetes clusters. Benefits of AKS: Fully managed: AKS takes care of the management and patching of Kubernetes, allowing businesses to focus on

Microsoft released a dedicated AI Gateway tier of Azure API Management in public preview, with a control plane built around models, MCP servers and tools rather than APIs. It fronts Foundry, Bedrock, Vertex AI and OpenAI behind one endpoint, with policy cards instead of XML. Architects welcomed the consolidation while questioning where the governance boundary sits. By Steef-Jan Wiggers

Part 3 of the User Connectivity Architecture series. Introduction The first post in this series described the pattern: a heartbeat on a timer, an Event Hub, a worker writing sessions into Redis, and Redis key expiration driving facility online/offline status. One detail matters later. The heartbeat interval is not hard-coded in the client. The API tells the client when to call next, and the default is 30 seconds. The second post covered two years of running that in production. This post is about the month it stopped working. In January 2026 our heartbeat traffic went from boring to terrifying and stayed there for about four weeks. This is the story of what broke, why the original design had a ceiling we never noticed, and the changes that fixed it: more Event Hub partitions, Azure Container Apps, and KEDA . The Storm A normal day looked like this: 51,000-58,000 heartbeats per hour , hour after hour Roughly 15-16 events per second at idle Flat, predictable, forgettable On January 5, around 7:00 AM PST , it stopped being flat. Time (PST) Heartbeats/hour Baseline ~57,000 12:00 PM 80,005 1:00 PM 216,351 5:00 PM 343,480 9:00 PM 466,760 That is eight times normal event volume in a single hour, and it was still climbing. Events were only half the story. SignalR connection counts told the other half. At the worst of it we were holding roughly eleven times the connections we normally maintain, and every one of those was a browser session we had to track, keep alive, and report status for. It did not spike and recover. It stayed elevated for weeks while we hunted for the cause. When we finally found it, the answer was almost funny: 507 zombie sessions that never ended, running months-old cached client code, and a single user account responsible for 33% of all our token API traffic . One account. Eight times the load. Four weeks. What Eight Times Load Actually Did Here is the part that matters, and it has nothing to do with the number itself. Our Event Hub had one partition. I

CryptoCabana: Azure Cloud CTF Walkthrough 🏖️ Introduction Room: TryHackMe - CryptoCabana Category: ☁️ Cloud Difficulty: Medium Objective: Exploit a misconfigured Azure cloud environment to retrieve a hidden flag. This writeup details a classic cloud privilege escalation path: an exposed SAS token → storage enumeration → credential discovery → Key Vault access → secret reconstruction. The challenge simulates a real-world scenario where poor security practices lead to a complete compromise. Table of Contents Reconnaissance & Initial Access Cloud Enumeration Service Principal Discovery Key Vault Exploration The "Freshly Rotated" Clue Reconstructing the Flag Key Security Takeaways Tools Used Reconnaissance & Initial Access Action: Visited the target website: https://cryptocabanaf5scjagc.z13.web.core.windows.net/ Finding: The website offered to back up seed phrases. Right-clicking and selecting "View Page Source" revealed critical information in the JavaScript code. JavaScript Code: javascript const STORAGE_ACCOUNT = "cryptocabanaf5scjagc"; const BACKUPS_CONTAINER = "backups"; const BACKUP_SAS = "?sv=2022-11-02&ss=b&srt=sco&sp=rl&se=2099-12-31T23:59:59Z&st=2024-01-01T00:00:00Z&spr=https&sig=ZAo05W8KXdSLM9afYCNGogNRV2N5a6aB4dQI3LXz%2Fh0%3D"; Analysis: The SAS (Shared Access Signature) token was hardcoded in client-side JavaScript. Permissions: Read (r) and List (l) Expiration: 2099 – far too long! This token grants anyone access to the storage account. bash az storage container list --account-name cryptocabanaf5scjagc --sas-token "$BACKUP_SAS" -o table Cloud Enumeration Action: Listed all containers in the storage account. Command: bash az storage container list --account-name cryptocabanaf5scjagc --sas-token "$BACKUP_SAS" -o table Output: Name Lease Status Last Modified $web 2026-07-16T18:26:22+00:00 backups 2026-07-16T18:26:22+00:00 vault 2026-07-16T18:26:23+00:00 Analysis: $web: Standard container for Azure Static Website hosting. backups: Appeared empty. vault: Hidden

In a recent Azure Architecture blog article, Azure lead engineer Kishorekumar Pattabiraman outlines practical criteria for choosing between skills, sub-agents, and other approaches when building AI systems, emphasizing reusability, simplicity, and long-term maintainability. By Sergio De Simone

Microsoft's Agent Framework now ships a supported runtime. Build 2026 brought the Agent Harness, the GitHub Copilot and Claude Agent SDK connectors, and the orchestration patterns to stable release; the harness and Foundry Hosted Agents have since reached GA. The shift is from an SDK for building agents to a governed platform for running them. By Steef-Jan Wiggers

The Situation Our team's CI/CD pipeline on Azure DevOps was taking 15 minutes to complete on every push to develop. You'd merge a PR, grab a coffee, come back — and it was still running. A 15-minute feedback loop breaks flow state — by the time the pipeline finishes, you've already switched context twice and forgotten what you were checking. I spent an afternoon digging into the Azure DevOps logs. Here's what I found. The Numbers (Before) Artifact content (uncompressed): 1,218 MB (1.2 GB) Artifact downloaded (compressed): 614 MB Download time: 3-4 min Pipeline breakdown: Build stage: ~5 min (Docker build + artifact) Download artifact: ~3 min (614 MB over the wire) Configure App Service: 2m54s (5 Azure API calls) Deploy (AzureWebApp@1): ~1 min Validate: 2m07s (sleep 30 + 3×30s probes) ───────────────────────────────── Total: ~15 min Root Cause #1: Ignoring output: 'standalone' next.config.js had this: const nextConfig = { output : ' standalone ' , // ← was there the whole time ... }; output: 'standalone' tells Next.js to produce .next/standalone/ — a self-contained directory with only what's needed at runtime. Trimmed node_modules . Auto-generated server.js . No source files. No dev dependencies. But the pipeline was ignoring it: # Old pipeline — copies everything from Docker docker cp deployImage:/app/node_modules . # 600 MB 😱 docker cp deployImage:/app/src . docker cp deployImage:/app/.next . docker cp deployImage:/app/server.js . # ... more files /bin/zip -r deploy.zip .env .next public node_modules package.json \ next.config.js jsconfig.json postcss.config.mjs decs.d.ts src server.js # Then published the ENTIRE working directory as the artifact - task : PublishPipelineArtifact@0 inputs : targetPath : ' $(System.DefaultWorkingDirectory)' # 1.2 GB of loose files + zip Azure DevOps compressed this to 614 MB for transfer. The deploy stage downloaded 614 MB to use a 24 MB zip buried inside it. The fix: # New pipeline — standalone only docker cp deployImage:/app/.next/

Microsoft has released a reference architecture for routing agent traffic on Azure Kubernetes Service. It breaks down the issue into three key choices: which model answers a call, how the call is managed, and which GPU replica handles it. By Claudio Masolo