Applying DevOps Principles on Lean Infrastructure. Lessons From Scaling to 102K Users.
Hi Azure Community, I'm a Microsoft Certified DevOps Engineer, and I want to share an unusual journey. I have been applying DevOps principles on traditional VPS infrastructure to scale to 102,000 users with 99.2% uptime. Why am I posting this in an Azure community? Because I'm planning migration to Azure in 2026, and I want to understand: What mistakes am I already making that will bite me during migration? THE CURRENT SETUP Platform: Social commerce (West Africa) Users: 102,000 active Monthly events: 2 million Uptime: 99.2% Infrastructure: Single VPS Stack: PHP/Laravel, MySQL, Redis Yes - one VPS. No cloud. No Kubernetes. No microservices. WHY I HAVEN'T USED AZURE YET Honest answer: Budget constraints in emerging market startup ecosystem. At our current scale, fully managed Azure services would significantly increase monthly burn before product-market expansion. The funding we raised needs to last through growth milestones. The trade: I manually optimize what Azure would auto-scale. I debug what Application Insights would catch. I do by hand what Azure Functions would automate. DEVOPS PRACTICES THAT KEPT US RUNNING Even on single-server infrastructure, core DevOps principles still apply: CI/CD Pipeline (GitHub Actions) • 3-5 deployments weekly • Zero-downtime deploys • Automated rollback on health check failures • Feature flags for gradual rollouts Monitoring & Observability • Custom monitoring (would love Application Insights) • Real-time alerting • Performance tracking and slow query detection • Resource usage monitoring Automation • Automated backups • Automated database optimization • Automated image compression • Automated security updates Infrastructure as Code • Configs in Git • Deployment scripts • Environment variables • Documented procedures Testing & Quality • Automated test suite • Pre-deployment health checks • Staging environment • Post-deployment verification KEY OPTIMIZATIONS Async Job Processing • Upload endpoint: 8 seconds → 340ms • 4x capacity increase Database Optimization • Feed loading: 6.4 seconds → 280ms • Strategic caching • Batch processing Image Compression • 3-8MB → 180KB (94% reduction) • Critical for mobile users Caching Strategy • Redis for hot data • Query result caching • Smart invalidation Progressive Enhancement • Server-rendered pages • 2-3 second loads on 4G WHAT I'M WORRIED ABOUT FOR AZURE MIGRATION This is where I need your help: Architecture Decisions • App Service vs Functions + managed services? • MySQL vs Azure SQL? • When does cost/benefit flip for managed services? Cost Management • How do startups manage Azure costs during growth? • Reserved instances vs pay-as-you-go? • Which Azure services are worth the premium? Migration Strategy • Lift-and-shift first, or re-architect immediately? • Zero-downtime migration with 102K active users? • Validation approach before full cutover? Monitoring & DevOps • Application Insights - worth it from day one? • Azure DevOps vs GitHub Actions for Azure deployments? • Operational burden reduction with managed services? Development Workflow • Local development against Azure services? • Cost-effective staging environments? • Testing Azure features without constant bills? MY PLANNED MIGRATION PATH Phase 1: Hybrid (Q1 2026) • Azure CDN for static assets • Azure Blob Storage for images • Application Insights trial • Keep compute on VPS Phase 2: Compute Migration (Q2 2026) • App Service for API • Azure Database for MySQL • Azure Cache for Redis • VPS for background jobs Phase 3: Full Azure (Q3 2026) • Azure Functions for processing • Full managed services • Retire VPS QUESTIONS FOR THIS COMMUNITY Question 1: Am I making migration harder by waiting? Should I have started with Azure at higher cost to avoid technical debt? Question 2: What will break when I migrate? What works on VPS but fails in cloud? What assumptions won't hold? Question 3: How do I validate before cutting over? Parallel infrastructure? Gradual traffic shift? Safe patterns? Question 4: Cost optimization from day one? What to optimize immediately vs later? Common cost mistakes? Question 5: DevOps practices that transfer? What stays the same? What needs rethinking for cloud-native? THE BIGGER QUESTION Have you migrated from self-hosted to Azure? What surprised you? I know my setup isn't best practice by Azure standards. But it's working, and I've learned optimization, monitoring, and DevOps fundamentals in practice. Will those lessons transfer? Or am I building habits that cloud will expose as problematic? Looking forward to insights from folks who've made similar migrations. --- About the Author: Microsoft Certified DevOps Engineer and Azure Developer. CTO at social commerce platform scaling in West Africa. Preparing for phased Azure migration in 2026. P.S. I got the Azure certifications to prepare for this migration. Now I need real-world wisdom from people who've actually done it!
Locked out of Azure account for 5 months! Spent hours on phone, still no resolution! PLEASE HELP!!!
As per the title, back in April I somehow managed to lock myself out of my Azure portal. Typically to sign in my browser would auto-fill in the password field - for some reason that fateful day the auto-fill function didn't work. So I typed in what I believed to be the password, it wasn't. Annoyed, I typed in a few more passwords (even checked browser password manager to ensure I was typing the correct password) and finally locked myself out. Worse still, the email address that Microsoft wanted to send its verification code as a back-up contingency is no longer active (domain wasn't renewed and has since been bought). So Microsoft is sending a verification email to a dead email address... When I try to reset the password via Microsoft's questionnaire, once submitted I then get an automated email response back stating I haven't provided enough correct/relevant information, so the password can't be reset. I have long since lost any hope or faith in Microsoft rectifying this issue. Being courteous on the phone and apologising constantly is all well and good, but is only meaningful if there is a resolution. All that's happened is I've been passed around from one department to another and back again, before eventually being ghosted back in the summer. I have since opened another support ticket which is already winding its way around to ultimately leading me down another dead end. At this stage, all I want is for Microsoft to release my SQL database (my intellectual property) back to me. I am able to provide old invoices relating to my Azure account (when I was able to log in and download invoices!), as well as proof of ID to prove I am who I say I am - enough is enough! Please advise.
Replicate workload from VMWare to Azure using Azure Site Recovery(ASR)
Hello, I am working on a project to replicate worklooad hosted on a VMWare to Azure Site Recovery for disaster recovery purpose. Current Environment: More than 80 VMs hosted on VMWare managed by VMWare Sphere running both Linux and Windows OS.. Databases: Oracle DB, Microsoft SQL and MySQL Requirements: seamless failover and disaster recovery requirements. scalable setup No down-time integrate identity and access mgt. integration with Microsoft Entra ID. RTO < 2 hrs and RPO > 15 minutes Backup: critical database backup every 3 hours App servers: Daily*incremental) and weekly (full) Transaction Logs: every 10 mins backup config. should be Daily Questions I have confirmed ASR supports fail back from Azure- on premise(VMWare specifically). Hence ASR(Azure site recovery) will be used for the project. However, what is the seamless method to replicate the databases(Oracle, Microsoft SQL and MySQL). https://learn.microsoft.com/en-us/azure/site-recovery/vmware-azure-failback What is the best approach to replicate the Application Servers? integrating existing on-premise 3rd party network security tool for firewall etc instead of the azure cloud native security tool. recommendation?? cost optimization techniques/recommendations Best practices for conducting non-destructive DR drills.
Scaling Smart with Azure: Architecture That Works
Hi Tech Community! I’m Zainab, currently based in Abu Dhabi and serving as Vice President of Finance & HR at Hoddz Trends LLC a global tech solutions company headquartered in Arkansas, USA. While I lead on strategy, people, and financials, I also roll up my sleeves when it comes to tech innovation. In this discussion, I want to explore the real-world challenges of scaling systems with Microsoft Azure. From choosing the right architecture to optimizing performance and cost, I’ll be sharing insights drawn from experience and I’d love to hear yours too. Whether you're building from scratch, migrating legacy systems, or refining deployments, let’s talk about what actually works.Comparision on Azure Cloud Sync and Traditional Entra connect Sync.
Introduction In the evolving landscape of identity management, organizations face a critical decision when integrating their on-premises Active Directory (AD) with Microsoft Entra ID (formerly Azure AD). Two primary tools are available for this synchronization: Traditional Entra Connect Sync (formerly Azure AD Connect) Azure Cloud Sync While both serve the same fundamental purpose, bridging on-prem AD with cloud identity, they differ significantly in architecture, capabilities, and ideal use cases. Architecture & Setup Entra Connect Sync is a heavyweight solution. It installs a full synchronization engine on a Windows Server, often backed by SQL Server. This setup gives administrators deep control over sync rules, attribute flows, and filtering. Azure Cloud Sync, on the other hand, is lightweight. It uses a cloud-managed agent installed on-premises, removing the need for SQL Server or complex infrastructure. The agent communicates with Microsoft Entra ID, and most configurations are handled in the cloud portal. For organizations with complex hybrid setups (e.g., Exchange hybrid, device management), is Cloud Sync too limited?
Former Employer Abuse
My former employer, Albert Williams, president of American Security Force Inc., keeps adding my outlook accounts, computers and mobile devices to the company's azure cloud even though I left the company more than a year ago. What can I do to remove myself from his grip? Does Microsoft have a solution against abusive employers?Como lograr una solución con un sistema multirregión de Azure
Si busca optimizar la disponibilidad de su aplicación web, no busque más allá de Microsoft Azure que ofrece una infinidad de servicios y herramientas que pueden ayudar a optimizar la disponibilidad de sus aplicaciones web, mejorando el rendimiento de estas y así reducir la latencia, lo que se traduce en una mejor experiencia del usuario. Entre ellas, FrontDoor, Traffic Manager, Application Gateway y Hybrid DNS, son algunas de las herramientas más potentes y versátiles que pueden utilizarse para garantizar que sus aplicaciones web estén siempre en funcionamiento con la máxima disponibilidad. Como bien lo mencionamos, encontramos a FrontDoor y Traffic Manager, son un servicio de gestión de tráfico global que se encarga de dirigir las solicitudes de los usuarios a los servidores más adecuados en función de diversos criterios como la ubicación geográfica, la carga del servidor o la latencia. Esto significa que, si un punto final se cae, el tráfico se redirigirá automáticamente a otro punto final, asegurando que su aplicación web permanezca disponible en todo momento, Traffic Manager puede configurarse para utilizar diversos métodos de enrutamiento, como round-robin, rendimiento y geográfico. Esta herramienta utiliza la ubicación del cliente para dirigir el tráfico al punto final más cercano y adicional puede detectar fallas en el servicio y redirigir el tráfico a servicios alternativos si es necesario. Contamos además con Application Gateway, que proporciona funciones avanzadas en su servicio al brindar balanceo de carga a nivel de aplicación, características de seguridad y escalabilidad para sus aplicaciones web. También proporciona Secure Sockets Layer (SSL) con funciones como la descarga del procedimiento de SSL, de sus servidores de aplicaciones, la afinidad de sesiones y el enrutamiento basado en URL. Application Gateway puede ayudar a configurar y a garantizar que el tráfico entrante se distribuya entre varias instancias de aplicaciones en diferentes regiones de Azure de forma que se maximice el rendimiento, la disponibilidad, escalabilidad y que pueden ayudar a su aplicación para satisfacer demandas cambiantes. Cuenta con la compatibilidad integrada con la autenticación de Azure Active Directory y WAF (Web Application Firewall), ya que puede estar tranquilo sabiendo que su aplicación web es segura y está disponible. Finalmente, esta herramienta nos ayuda con la prevención de ataques maliciosos y garantiza que solo los usuarios autorizados puedan acceder a las aplicaciones, y proporciona características avanzadas frente al equilibrio de carga y almacenamiento en caché de contenido que ayudan a optimizar el rendimiento y ayudar a reducir la latencia, brindando a los usuarios el mejor acceso posible al rendimiento. Otra opción que podemos brindar para nuestros clientes es aquella en donde pueden usar Azure para implementar una solución híbrida de Sistema de nombres de dominio (DNS), un enfoque que les permite integrar sin problemas sistemas locales con Azure y proporcionar una resolución de nombres de dominio uniforme en toda su infraestructura. Esto significa que puede utilizar los mismos nombres DNS tanto en las instalaciones como en la nube, lo que facilita la gestión de sus registros DNS y garantiza que su aplicación web esté siempre disponible y con funciones como la delegación de zonas y el reenvío condicional, puede personalizar su configuración DNS para satisfacer las necesidades únicas de su organización. Azure DNS Managed Service le permite configurar, administrar y monitorear registros DNS para los dominios de su organización, le brinda la flexibilidad de administrar los dominios de su organización desde las instalaciones y desde la nube. Puede usar Azure DNS para administrar zonas DNS públicas y Azure Private DNS para administrar zonas DNS privadas. Este enfoque permite a las organizaciones aprovechar la escalabilidad y la rentabilidad de los servicios de DNS en la nube mientras mantienen el control sobre su infraestructura de DNS local, con una solución DNS híbrida, puede garantizar una alta disponibilidad y escalabilidad de sus aplicaciones web multirregionales. Por último, también podemos elegir una aplicación web multirregional muy accesible que se desarrollará para proporcionar una solución de gestión de información robusta y fiable. Azure DNS Multirregión es una herramienta útil para empresas que buscan una solución de DNS escalable y altamente disponible, ya que es posible administrar y distribuir zonas DNS en múltiples regiones de Azure, lo que permite una mayor resiliencia y redundancia para la gestión de nombres de dominio. Una de las principales ventajas de Azure DNS Multirregión es su capacidad para administrar cada región como una sola colección de recursos, lo que brinda una mayor flexibilidad en la gestión y el control del entorno de DNS. El objetivo es hacer que la aplicación sea accesible desde cualquier parte del mundo, independientemente de la ubicación del usuario. Para lograrlo, se implementa una arquitectura de nube multirregión para alojar la aplicación, que permitirá a los usuarios conectarse a la aplicación desde cualquier parte del mundo, asegurando un alto nivel de seguridad y disponibilidad y acceso a su información más reciente. Por ejemplo, es posible redesplegar una región sin afectar el resto de la configuración, además, Azure DNS Multirregión se integra sin problemas con otras herramientas y servicios de Azure, como las VPN multisitio, lo que permite conectar redes virtuales y sitios locales en una topología que se adapta a las necesidades de la empresa. Los recursos de la nube se distribuirán en múltiples regiones geográficas, proporcionando una alta tolerancia a fallas, lo que significa que, si ocurre una falla en una región, las aplicaciones seguirán estando disponibles en otras regiones. Además, se introducirá tecnología de replicación de datos para garantizar la sincronización de datos entre regiones. En términos de seguridad, se implementará tecnología de encriptación de datos para brindar una capa adicional de seguridad para garantizar que solo los usuarios autorizados puedan acceder a la información. Así mismo se implementarán herramientas de monitoreo para detectar y corregir errores en tiempo real, lo que permitirá a los administradores de aplicaciones reaccionar y corregir errores antes de que afecten la disponibilidad de la aplicación. En resumen, Azure DNS Multirregión es una herramienta valiosa para empresas que buscan una solución de DNS escalable y altamente disponible, capaz de ofrecer redundancia y resiliencia en la gestión de nombres de dominio en múltiples regiones de Azure. Desafíos a los que nos enfrentamos Implementar el equilibrio de carga multirregional con FrontDoor, Traffic Manager y Application Gateway, una aplicación web multirregional de alta disponibilidad y Azure DNS Multirregión puede presentar algunos inconvenientes y desafíos. Para lo cual también presentamos algunas de las soluciones más significativas, y así tener en cuenta que para los posibles inconvenientes, podemos aplicar las soluciones adecuadas para superarlos. A continuación, se describen algunos de los posibles retos: Latencia: si los usuarios están distribuidos en diferentes regiones geográficas y el tráfico se redirige a una región distinta, puede haber un aumento en la latencia, lo que afectaría la experiencia del usuario. Dificultades en la configuración: La configuración de la arquitectura multirregional puede ser compleja, lo que puede aumentar la posibilidad de errores en la configuración y la implementación. Costos: La implementación de una arquitectura multirregional puede ser costosa en términos de infraestructura, mantenimiento y gestión de la red. Frente a estos desafíos, contamos con diversos recursos que nos permiten ver el valor agregado que estas herramientas brindan a su organización, dentro de las cuales cabe mencionar: Utilizar FrontDoor, Traffic Manager y Azure DNS Multirregión: FrontDoor es la nube moderna de Microsoft Content Delivery Network (CDN) que proporciona acceso rápido, confiable y seguro entre los usuarios y el contenido web estático y dinámico de las aplicaciones en todo el mundo, por otro lado el Traffic Manager permite dirigir el tráfico al punto de conexión más cercano al usuario en función de su ubicación geográfica. Por su parte, Azure DNS Multirregión proporciona una resolución de nombres de dominio rápida y global. Usar Application Gateway para balancear el tráfico: Application Gateway puede equilibrar el tráfico a nivel de la aplicación y optimizar la entrega de contenidos en función de la región de origen del usuario. Además, puede mejorar la seguridad mediante la aplicación de políticas de seguridad específicas. Utilizar políticas de ajuste de tráfico: Las políticas de ajuste de tráfico de Azure permiten gestionar el tráfico para asegurarse de que se redirija a la región más cercana al usuario. Esto ayuda a reducir la latencia y mejorar la experiencia del usuario. Automatizar la configuración: Es posible utilizar herramientas de automatización como Azure Resource Manager (ARM) o Azure PowerShell para automatizar la configuración y la implementación de la arquitectura multirregional. Utilizar herramientas de monitoreo: El monitoreo continuo de la infraestructura y las aplicaciones puede ayudar a identificar y resolver problemas en la arquitectura multirregional. Entonces, ¿Por qué elegir nuestras herramientas con Azure? Si entramos a resumir, podremos encontrar que el uso del equilibrio de carga multirregional con FrontDoor, Traffic Manager y Application Gateway, Aplicación web multirregional de alta disponibilidad y Azure DNS Multirregión ofrece varias ventajas, entre las que se incluyen: Alta disponibilidad: Al utilizar varias regiones, se puede garantizar que, si una región falla, el tráfico se dirija automáticamente a otra región activa, lo que reduce la posibilidad de interrupciones del servicio. Mejor rendimiento: Al utilizar el equilibrio de carga multirregional, los usuarios se conectan automáticamente al servidor más cercano a ellos geográficamente, lo que reduce la latencia y mejora el rendimiento. Escalabilidad: Al utilizar varias regiones, se puede aumentar la capacidad de la aplicación de manera fácil y rápida sin afectar la calidad del servicio. Reducción de costos: Al utilizar varias regiones, se pueden aprovechar los precios más bajos en las diferentes regiones de Azure, lo que reduce el costo total de la arquitectura. Seguridad: Al utilizar varias regiones, se puede garantizar que los datos estén disponibles en diferentes ubicaciones, lo que reduce el riesgo de pérdida de datos debido a un desastre natural o una falla en la región. Dada la diversidad de servicios, vemos que se pueden proporcionar a las empresas la escalabilidad, la disponibilidad y el rendimiento para mantener sus aplicaciones funcionando sin problemas y escalar hacia arriba o hacia abajo según sea necesario y al trabajar juntos podemos garantizar que sus operaciones comerciales sigan siendo eficientes y seguras. Con estas potentes herramientas a su disposición, puede asegurarse de que su aplicación web siga estando disponible y respondiendo pase lo que pase. ¿Por qué esperar? Comience a optimizar la disponibilidad de su aplicación web hoy mismo.
Conditional access policy or User risk policy set to force password at high risk doesnt work
Hi all, When setting Conditional access policy or User risk policy set to force password at high risk doesn't work instead I get a blocked windows on users. I have set SSPR too and I think this is a requirement What am I doing wrong?
