Azure for
Game Developers
Marco Parenzan
Scenario: Indy=Startup=Short
Term
Azure for Game Developers
Scenario: Indy=Startup=Short Term
• CAPEXOPEX
• No On Premise, Prefer PaaS over IaaS
• Abbassa l’investimento iniziale
• Design For SuccessScaling
• StatelessnessHorizontal Scaling
• Resiliency
Microsoft Azure
• Worldwide Cloud Provider
• 38 regions nel mondo
• Complete IaaS, PaaS, SaaS experience
• Pay as you use
• Hourly pricing, invoiced my minute
• Si può applicare un Service Level Agreement (SLA)
Scegliere uno o più regions
• Diminuire la latenza verso gli utenti
• Le regions sono sempre in coppiaZones (Eu, Gb, De, Fr, per quanto
riguarda l’Europa)
• Gestire la «sovranità»/ «nazionalità»/regolamentazione sui dati
• Azure è il cloud pubblico con il maggior numero di certificazioni che si ereditano
automaticamente deployando la soluzione su Azure (in realtà responsabilità
condivisa)
• I servizi core sono disponibili in tutti i datacenter
• Alcuni servizi possono essere presenti solo in alcune region
• I servizi in preview (non GA) vengono
• Ogni region è sempre accoppiata ad un altra region in una zona per il
failover (se abilitato)
• (ad esempio North Europe/Irlanda con West Europe/Amsterdam)
Fun with Azure
Demo: analyticsgames.azurewebsites.net
Mobile Controller (html)
WebApi MVC + Web Api
Event Hub-
Stream Analytics Service Bus (Queue)
Web Worker
Remote (html)
Json Tap event
SignalR Message
http notificationJson Tap event
Json Event Hub
Input source
Service bus
output queue
Input service bus
output queue
Devices
IoT Hub
• È un servizio di Gestione e comunicazione dei device
• Qualunque device, non solo Windows 10 IoT Core
• Lavorare con piattaforme note e protocolli standard
• HTTPS, MQTT, AMQP
• Stabilire una comunicazione bi-direzionale con i dispositivi IoT
• Eventi (DeviceHub)
• Comandi (HubDevice)
• Gestisce l’autenticazione per device
Microservices
Microservices
• Deployment agile di servizi (HTTP?)
• Gestione corretta dell’accoppiamento tra servizi
• Backend generico per funzioni accessibili da server e da client
• Tre soluzioni oggi
• Container
• Actor Model
• Serverless
• WebApi? No...
ContainerDocker
• Container come Microservice boundary
• Container=Processo Isolato
• Docker non è il «container», ma è l’infrastruttutura costruita attorno
per deployare container (registry, immagini, ...)
• Al momento Linux, ma aspettiamo i Windows Container a breve
• C’è un clusterAzure Container Services (ACS)
Service Fabric
• Actor come Microservice Boundary
• Stateful object
• Una sorta di Aggregate Root del DDD, anche se non focalizzato sulle entità e
sulla persistenza
• C’è un cluster
Function Apps (a.k.a. Azure Functions)
• Serverless proposition
• Dynamic AppServicePlan
• Supporta .NET Core e Node.js
• script based (.csx)
• Stesso «modello» di ASP.NET Core: scripting+ core in package NuGet
• Basato sui WebJobs (task runner)
• Trigger based
• Http Trigger (request, response)
• Http Trigger (webhook)
• Db Trigger
• Storage Trigger
• Queue Trigger
• Supporto per la command line
• Backend generico per funzioni accessibili da server e da client
Long-Term Storage
Storage Opportunities
• Azure Storage
• Azure Document Db
Azure Storage
• Strong Performances
• 500Tb
• 40000IOPS
• LRS/ZRS/GRS/R-GRS
• Cold/Warm
• Founding Performances
• Azure Disks for VMs are stored in Azure Storage Accounts
Azure Storage Blob
• Memorizzare Blob (Paged/Block)
• Organizzato in container
• Sicurezza gestita con gli Shared Access Secrets
• Possibilità di condividere container e/o blob pubblicamente readonly
• Possibilità di usare le CDN per avvicinare i contenuti all’utente tramite
la rete Edge (partnership con Standard Akamai, Standard Verizon,
Premium Verizon)
• Si usa al posto di un File System
• Long Term Storage
• Non si usa il file system delle VM se non per i files temporanei
• Si usa per gli asset statici dei giochi
Azure DocumentDb
• HyperscaleHighly ingestionScale on write
• SSD based
• Geo replica readonly nativa, automatica, configurabile
• Database documentale basato su Json
• No-validazione dello schema (genericamente detto non strutturato)
• Embedding di relazioni one-to-some
• Developer-oriented
• No impedance mismatch (ORM)
• Container
• Elemento di partizionamento
• Elemento di scalabilità
• Elemento di throttling
• Elemento di costo
• RURequest Unit («moneta» che media il costo di CPU, Memoria e IOPS)
• https://www.documentdb.com/capacityplanner
• Si interroga in un linguaggio simil-SQL
• Supporta Stored Procedures/Triggers/User Functions in JavaScript
• Per chi ha esperienza di Mongo, ha una API nativa per migrare progetti Mongo
• Si usa per tutto lo storage generico che non sia strettamente relazionale (one-to-many o many-to-many) e non sia meno conveniente
di altri storage
App
App Service
• Stack per il deployment di servizi con endpoint http(s)
• App Service Plan per vertical scaling e multitenancy
• Basato su una piattaforma di deployment (Kudu) molto efficace
• Continuous Delivery
• Configuration (AppSettings+Connection Strings)
• Horizontal Autoscaling features
• Monitoring
• Slot management
• Automatic backup
• Supporto di .NET/PHP/Python/Java/Node.js
• Supporto per Traffic Manager
• Autenticazione
• Diversi application models
• Web App
• Api App
• Mobile App
• Logic App
• WebJobs
• Function App
Web App
• Application Model per HTML+HTTP(s) applications
• Frontend generico per funzioni accessibili da server e da client
Conclusioni
Adottare Microsoft Azure
• Per cominciare con Microsoft Azure
• Visual Studio Dev Essentials
• https://www.visualstudio.com/products/free-developer-offers-vs.aspx
• 25$/month credit
• Azure App Service Free Plan
• Visual Studio Community 2015
• 6 month Pluralsight subscription
• DreamSpark per gli studenti
• Medium Term
• Bizspark per le Startup (3/5 anni)
Azure for Game Developers
• marco.parenzan@1nn0va.it
• http://www.slideshare.net/marco.parenzan
• http://github.com/marcoparenzan
Thank You

Azure for Game Developers

  • 1.
  • 2.
  • 3.
    Scenario: Indy=Startup=Short Term •CAPEXOPEX • No On Premise, Prefer PaaS over IaaS • Abbassa l’investimento iniziale • Design For SuccessScaling • StatelessnessHorizontal Scaling • Resiliency
  • 4.
    Microsoft Azure • WorldwideCloud Provider • 38 regions nel mondo • Complete IaaS, PaaS, SaaS experience • Pay as you use • Hourly pricing, invoiced my minute • Si può applicare un Service Level Agreement (SLA)
  • 5.
    Scegliere uno opiù regions • Diminuire la latenza verso gli utenti • Le regions sono sempre in coppiaZones (Eu, Gb, De, Fr, per quanto riguarda l’Europa) • Gestire la «sovranità»/ «nazionalità»/regolamentazione sui dati • Azure è il cloud pubblico con il maggior numero di certificazioni che si ereditano automaticamente deployando la soluzione su Azure (in realtà responsabilità condivisa) • I servizi core sono disponibili in tutti i datacenter • Alcuni servizi possono essere presenti solo in alcune region • I servizi in preview (non GA) vengono • Ogni region è sempre accoppiata ad un altra region in una zona per il failover (se abilitato) • (ad esempio North Europe/Irlanda con West Europe/Amsterdam)
  • 6.
  • 7.
    Demo: analyticsgames.azurewebsites.net Mobile Controller(html) WebApi MVC + Web Api Event Hub- Stream Analytics Service Bus (Queue) Web Worker Remote (html) Json Tap event SignalR Message http notificationJson Tap event Json Event Hub Input source Service bus output queue Input service bus output queue
  • 8.
  • 9.
    IoT Hub • Èun servizio di Gestione e comunicazione dei device • Qualunque device, non solo Windows 10 IoT Core • Lavorare con piattaforme note e protocolli standard • HTTPS, MQTT, AMQP • Stabilire una comunicazione bi-direzionale con i dispositivi IoT • Eventi (DeviceHub) • Comandi (HubDevice) • Gestisce l’autenticazione per device
  • 10.
  • 11.
    Microservices • Deployment agiledi servizi (HTTP?) • Gestione corretta dell’accoppiamento tra servizi • Backend generico per funzioni accessibili da server e da client • Tre soluzioni oggi • Container • Actor Model • Serverless • WebApi? No...
  • 12.
    ContainerDocker • Container comeMicroservice boundary • Container=Processo Isolato • Docker non è il «container», ma è l’infrastruttutura costruita attorno per deployare container (registry, immagini, ...) • Al momento Linux, ma aspettiamo i Windows Container a breve • C’è un clusterAzure Container Services (ACS)
  • 13.
    Service Fabric • Actorcome Microservice Boundary • Stateful object • Una sorta di Aggregate Root del DDD, anche se non focalizzato sulle entità e sulla persistenza • C’è un cluster
  • 14.
    Function Apps (a.k.a.Azure Functions) • Serverless proposition • Dynamic AppServicePlan • Supporta .NET Core e Node.js • script based (.csx) • Stesso «modello» di ASP.NET Core: scripting+ core in package NuGet • Basato sui WebJobs (task runner) • Trigger based • Http Trigger (request, response) • Http Trigger (webhook) • Db Trigger • Storage Trigger • Queue Trigger • Supporto per la command line • Backend generico per funzioni accessibili da server e da client
  • 15.
  • 16.
    Storage Opportunities • AzureStorage • Azure Document Db
  • 17.
    Azure Storage • StrongPerformances • 500Tb • 40000IOPS • LRS/ZRS/GRS/R-GRS • Cold/Warm • Founding Performances • Azure Disks for VMs are stored in Azure Storage Accounts
  • 18.
    Azure Storage Blob •Memorizzare Blob (Paged/Block) • Organizzato in container • Sicurezza gestita con gli Shared Access Secrets • Possibilità di condividere container e/o blob pubblicamente readonly • Possibilità di usare le CDN per avvicinare i contenuti all’utente tramite la rete Edge (partnership con Standard Akamai, Standard Verizon, Premium Verizon) • Si usa al posto di un File System • Long Term Storage • Non si usa il file system delle VM se non per i files temporanei • Si usa per gli asset statici dei giochi
  • 19.
    Azure DocumentDb • HyperscaleHighlyingestionScale on write • SSD based • Geo replica readonly nativa, automatica, configurabile • Database documentale basato su Json • No-validazione dello schema (genericamente detto non strutturato) • Embedding di relazioni one-to-some • Developer-oriented • No impedance mismatch (ORM) • Container • Elemento di partizionamento • Elemento di scalabilità • Elemento di throttling • Elemento di costo • RURequest Unit («moneta» che media il costo di CPU, Memoria e IOPS) • https://www.documentdb.com/capacityplanner • Si interroga in un linguaggio simil-SQL • Supporta Stored Procedures/Triggers/User Functions in JavaScript • Per chi ha esperienza di Mongo, ha una API nativa per migrare progetti Mongo • Si usa per tutto lo storage generico che non sia strettamente relazionale (one-to-many o many-to-many) e non sia meno conveniente di altri storage
  • 20.
  • 21.
    App Service • Stackper il deployment di servizi con endpoint http(s) • App Service Plan per vertical scaling e multitenancy • Basato su una piattaforma di deployment (Kudu) molto efficace • Continuous Delivery • Configuration (AppSettings+Connection Strings) • Horizontal Autoscaling features • Monitoring • Slot management • Automatic backup • Supporto di .NET/PHP/Python/Java/Node.js • Supporto per Traffic Manager • Autenticazione • Diversi application models • Web App • Api App • Mobile App • Logic App • WebJobs • Function App
  • 22.
    Web App • ApplicationModel per HTML+HTTP(s) applications • Frontend generico per funzioni accessibili da server e da client
  • 23.
  • 24.
    Adottare Microsoft Azure •Per cominciare con Microsoft Azure • Visual Studio Dev Essentials • https://www.visualstudio.com/products/free-developer-offers-vs.aspx • 25$/month credit • Azure App Service Free Plan • Visual Studio Community 2015 • 6 month Pluralsight subscription • DreamSpark per gli studenti • Medium Term • Bizspark per le Startup (3/5 anni)
  • 25.
    Azure for GameDevelopers • [email protected] • http://www.slideshare.net/marco.parenzan • http://github.com/marcoparenzan Thank You