Azure compute options Flashcards
a logical grouping of two or more VMs that help keep your application available during planned or unplanned maintenance.
availability set
The group of virtual machines that share common hardware are in the same fault domain. A fault domain is essentially a rack of servers. It provides the physical separation of your workload across different power, cooling, and network hardware that support the physical servers in the data center server racks.
Fault Domain
Update domains indicate groups of VMs and underlying physical hardware that can be rebooted at the same time
Update Domain
Azure Batch enables large-scale job scheduling and compute management with the ability to scale to tens, hundreds, or thousands of VMs.
When you’re ready to run a job, Batch does the following:
- Starts a pool of compute VMs for you
- Installs applications and staging data
- Runs jobs with as many tasks as you have
- Identifies failures
- Requeues work
- Scales down the pool as work completes
Azure Batch
This architecture is where you break solutions into smaller, independent pieces. For example, you may split a website into a container hosting your front end, another hosting your back end, and a third for storage. This split allows you to separate portions of your app into logical sections that can be maintained, scaled, or updated independently.
microservice architecture
The preceding figure depicts this process as follows:
You convert an existing application to one or more containers and then publish one or more container images to the Azure Container Registry.
By using the Azure portal or the command line, you deploy the containers to an AKS cluster.
Azure AD controls access to AKS resources.
You access SLA-backed Azure services, such as Azure Database for MySQL, via OSBA.
Optionally, AKS is deployed with a virtual network.
Migration APPs to Containers
Azure App Service enables you to build and host web apps, background jobs, mobile backends, and RESTful APIs in the programming language of your choice without managing infrastructure. It offers automatic scaling and high availability. App Service supports both Windows and Linux, and enables automated deployments from GitHub, Azure DevOps, or any Git repo to support a continuous deployment model.
This platform as a service (PaaS) allows you to focus on the website and API logic while Azure handles the infrastructure to run and scale your web applications.
Azure App Service
With Azure App Service, you can host most common web app styles including:
- Web Apps
- API Apps
- WebJobs
- Mobile Apps
Types of Web Apps
App Service includes full support for hosting web apps using ASP.NET, ASP.NET Core, Java, Ruby, Node.js, PHP, or Python. You can choose either Windows or Linux as the host operating system.
Web Apps
Much like hosting a website, you can build REST-based Web APIs using your choice of language and framework. You get full Swagger support, and the ability to package and publish your API in the Azure Marketplace. The produced apps can be consumed from any HTTP(S)-based client.
API Apps
WebJobs allows you to run a program (.exe, Java, PHP, Python, or Node.js) or script (.cmd, .bat, PowerShell, or Bash) in the same context as a web app, API app, or mobile app. They can be scheduled, or run by a trigger. WebJobs are often used to run background tasks as part of your application logic.
Web jobs
Use the Mobile Apps feature of Azure App Service to quickly build a back-end for iOS and Android apps. With just a few clicks in the Azure portal you can:
- Store mobile app data in a cloud-based SQL database
- Authenticate customers against common social providers such as MSA, Google, Twitter, and Facebook
- Send push notifications
- Execute custom back-end logic in C# or Node.js
On the mobile app side, there is SDK support for native iOS & Android, Xamarin, and React native apps.
Mobile apps
Serverless computing is the abstraction of servers, infrastructure, and OSs. With serverless computing, Azure takes care of managing the server infrastructure and allocation/deallocation of resources based on demand. Infrastructure isn’t your responsibility. Scaling and performance are handled automatically, and you are billed only for the exact resources you use. There’s no need to even reserve capacity.
Serverless computing encompasses three ideas: the abstraction of servers, an event-driven scale, and micro-billing
Serverless
Serverless computing abstracts the servers you run on. You never explicitly reserve server instances; the platform manages that for you. Each function execution can run on a different compute instance, and this execution context is transparent to the code. With serverless architecture, you simply deploy your code, which then runs with high availability.
Abstraction of servers
Serverless computing is an excellent fit for workloads that respond to incoming events. Events include triggers by timers (for example, if a function needs to run every day at 10:00 AM UTC), HTTP (API and webhook scenarios), queues (for example, with order processing), and much more. Instead of writing an entire application, the developer authors a function, which contains both code and metadata about its triggers and bindings. The platform automatically schedules the function to run and scales the number of compute instances based on the rate of incoming events. Triggers define how a function is invoked and bindings provide a declarative way to connect to services from within the code.
Event-driven scale
