Azure full

Editor's Notes

• #4: Speaking Points: There are numerous terms and definitions floating around in the industry for “the cloud”, “cloud computing”, “cloud services”, etc. Microsoft thinks of the cloud as simply an approach to computing that enables applications to be delivered at scale for a variety of workloads and client devices. The cloud can help deliver IT as a standardized service…freeing you up to focus on your business
• #5: Slide Objectives: Explain the three established industry terms for cloud services Speaker Notes: There is a lot of talk in the industry about different terms like Platform as a Service, Infrastructure as a Service, and Software as a Service. Since PDC08 when we first announced the Windows Azure our focus has been on delivering a platform as a service offering where you can build applications. Where the platform abstracts you from the complexities of building and running applications. We fundamentally believe that the future path forward for development is by providing a platform. In fact, as you’ll see in a few minutes, we believe that there are a number of new capabilities that should be delivered as services to the platform. Notes: There is a lot of confusion in the industry when it comes to the cloud. It’s important that you understand both what is happening in the industry and how we think about the cloud. This is the most commonly used taxonomy for differentiating between types of cloud services. The industry has defined three categories of services: IaaS – a set of infrastructure level capabilities such as an operating system, network connectivity, etc. that are delivered as pay for use services and can be used to host applications. PaaS – higher level sets of functionality that are delivered as consumable services for developers who are building applications. PaaS is about abstracting developers from the underlying infrastructure to enable applications to quickly be composed. SaaS – applications that are delivered using a service delivery model where organizations can simply consume and use the application. Typically an organization would pay for the use of the application or the application could be monetized through ad revenue. It is important to note that these 3 types of services may exist independently of one another or combined with one another.
• #6: Slide Objectives: Explain the differences and relationship between IaaS, PaaS, and SaaS in more detail. Speaking Points: Here’s another way to look at the cloud services taxonomy and how this taxonomy maps to the components in an IT infrastructure. Packaged Software With packaged software a customer would be responsible for managing the entire stack – ranging from the network connectivity to the applications. IaaS With Infrastructure as a Service, the lower levels of the stack are managed by a vendor. Some of these components can be provided by traditional hosters – in fact most of them have moved to having a virtualized offering. Very few actually provide an OS The customer is still responsible for managing the OS through the Applications. For the developer, an obvious benefit with IaaS is that it frees the developer from many concerns when provisioning physical or virtual machines. This was one of the earliest and primary use cases for Amazon Web Services Elastic Cloud Compute (EC2). Developers were able to readily provision virtual machines (AMIs) on EC2, develop and test solutions and, often, run the results ‘in production’. The only requirement was a credit card to pay for the services. PaaS With Platform as a Service, everything from the network connectivity through the runtime is provided and managed by the platform vendor. The Windows Azure best fits in this category today. In fact because we don’t provide access to the underlying virtualization or operating system today, we’re often referred to as not providing IaaS. PaaS offerings further reduce the developer burden by additionally supporting the platform runtime and related application services. With PaaS, the developer can, almost immediately, begin creating the business logic for an application. Potentially, the increases in productivity are considerable and, because the hardware and operational aspects of the cloud platform are also managed by the cloud platform provider, applications can quickly be taken from an idea to reality very quickly. SaaS Finally, with SaaS, a vendor provides the application and abstracts you from all of the underlying components.
• #10: And you get all the goodness shown in the previous slides across the WW
• #21: Azure Functions are part of the Azure Web + Mobile suite of App Services and are designed to enable the creation of small pieces of meaningful, reusable methods, easily shared across services. These serverless, event-driven methods are often referred to as “nanoservices” due to their small size. Although an Azure Function can contain quite a bit of code, they are typically designed to serve a single purpose, and respond to events in connected services.
• #22: Azure Functions can be created in most common development and scripting languages, and can be “triggered” by events in other Azure App Services, such as Web, Mobile, Logic, and API apps. Azure Functions can also be exposed via HTTP URL schemes for easy integration into legacy systems.
• #23: Azure Functions are “event-driven” meaning they run based on associated and configure events, or “triggers”. For example an Azure Function could be triggered by a simple timer, such as running a process once every 24-hours, or triggered by an event in a document management system, such as when a new document is uploaded to a SharePoint library. Azure Functions can also respond to Azure-specific events, such as an image added to a Storage Blob or a notification arriving in a Message Queue.
• #24: Although Azure Functions can be created from scratch”, the Azure Portal exposes a large number of ever-growing templates to help get developers started. These templates are typically designed with specific triggers in mind, such as a Blob Storage event, or a GitHub webhook event. Templates can easily form the basis for robust function creation, and are really designed just to get a developer started.
• #25: Timer Functions are exactly what they sound like: Functions triggered by a specific time event. Timer Functions are perfect for clean up and maintenance processes and can easily be combined with other functions for more robust scenarios. Timer Functions us CRON expressions to configure schedules. It’s a good idea to get familiar with CRON syntax, but in the meantime there are a number of tools online to help you build CRON expressions.
• #26: Data Processing Functions are triggered by activity in a datastore, such as a table, queue, or container. Data Processing Functions also typically have both “in” and “out” parameters, meaning they can accept an object as a parameter, and then process information and then return another object from within the function. This is not the same as a “return” value, as most Azure Functions either return void, or an HTTP response such as “created”, “accepted”, or “OK”.
• #27: Webhook and API Functions are designed to easily integrate with 3rd party systems, like GitHub, Office 365, and especially Microsoft PowerApps. Since Webhook and API Functions are often exposed to external or legacy systems, they typically need CORS settings managed in order to “allow” external resources to “see” and execute the function. Most Azure Logic Apps leverage Webhook and API Functions directly.
• #28: An Azure Function is really a group of a few files that work in harmony. All actual function logic resides in a “Run” file written in a language of choice. A “Project” file is similar to a project file in other technologies such as .NET Core or Universal Windows Platform and contains “secondary” assembly references such as NuGet packages. Finally a “Function” file contains information about triggers and parameters, such as locations of Storage Queue connection strings and whether the parameter is design as an “in”, “out” or “bi-directional”. Optionally, additional configuration is also found in the Function App Settings such as an API Key or database connection string.
• #29: Without bindings, an Azure Function would just be a “disconnected” algorithm without any way to serve a purpose. Bindings server to connect functions and output to other services. Some of the most common binding types and features are listed in the table, however variations and adaptations can and do exist.
• #30: Many Azure Functions are exposed via an actual URL that can be called directly from a web client or browser. When an Azure Function is not exposed via a URL its common practice to call the function from another function, such as a Timer-based Function for testing purposes only. Since Azure Functions can be nested, testing scenarios can be quite varied. For managing and testing Azure Functions that integrate with Storage Containers, Microsoft provides the Microsoft Azure Storage Explorer, as well as the Visual Studio Cloud Explorer. The Logs console in the Azure Function Designer is also a great way to view and trace function processing.
• #38: Azure Functions are part of the Azure Web + Mobile suite of App Services and are designed to enable the creation of small pieces of meaningful, reusable methods, easily shared across services. These serverless, event-driven methods are often referred to as “nanoservices” due to their small size. Although an Azure Function can contain quite a bit of code, they are typically designed to serve a single purpose, and respond to events in connected services.
• #39: Azure Functions can be created in most common development and scripting languages, and can be “triggered” by events in other Azure App Services, such as Web, Mobile, Logic, and API apps. Azure Functions can also be exposed via HTTP URL schemes for easy integration into legacy systems.
• #40: Azure Functions are “event-driven” meaning they run based on associated and configure events, or “triggers”. For example an Azure Function could be triggered by a simple timer, such as running a process once every 24-hours, or triggered by an event in a document management system, such as when a new document is uploaded to a SharePoint library. Azure Functions can also respond to Azure-specific events, such as an image added to a Storage Blob or a notification arriving in a Message Queue.
• #41: Although Azure Functions can be created from scratch”, the Azure Portal exposes a large number of ever-growing templates to help get developers started. These templates are typically designed with specific triggers in mind, such as a Blob Storage event, or a GitHub webhook event. Templates can easily form the basis for robust function creation, and are really designed just to get a developer started.
• #42: Timer Functions are exactly what they sound like: Functions triggered by a specific time event. Timer Functions are perfect for clean up and maintenance processes and can easily be combined with other functions for more robust scenarios. Timer Functions us CRON expressions to configure schedules. It’s a good idea to get familiar with CRON syntax, but in the meantime there are a number of tools online to help you build CRON expressions.
• #43: Data Processing Functions are triggered by activity in a datastore, such as a table, queue, or container. Data Processing Functions also typically have both “in” and “out” parameters, meaning they can accept an object as a parameter, and then process information and then return another object from within the function. This is not the same as a “return” value, as most Azure Functions either return void, or an HTTP response such as “created”, “accepted”, or “OK”.
• #44: Webhook and API Functions are designed to easily integrate with 3rd party systems, like GitHub, Office 365, and especially Microsoft PowerApps. Since Webhook and API Functions are often exposed to external or legacy systems, they typically need CORS settings managed in order to “allow” external resources to “see” and execute the function. Most Azure Logic Apps leverage Webhook and API Functions directly.
• #45: An Azure Function is really a group of a few files that work in harmony. All actual function logic resides in a “Run” file written in a language of choice. A “Project” file is similar to a project file in other technologies such as .NET Core or Universal Windows Platform and contains “secondary” assembly references such as NuGet packages. Finally a “Function” file contains information about triggers and parameters, such as locations of Storage Queue connection strings and whether the parameter is design as an “in”, “out” or “bi-directional”. Optionally, additional configuration is also found in the Function App Settings such as an API Key or database connection string.
• #46: Without bindings, an Azure Function would just be a “disconnected” algorithm without any way to serve a purpose. Bindings server to connect functions and output to other services. Some of the most common binding types and features are listed in the table, however variations and adaptations can and do exist.
• #50: A virtual machine is -- well -- a virtualized machine created and managed by a hypervisor such as VirtualBox or Hyper-V. Even though a VM runs on a machine that has an operating system, each VM requires its own complete operating system, even if it's the same operating system as the host OS. VMs offer a very high degree of isolation, but at a cost: longer startup times, lower portability (ever tried to move a 127 GB virtual hard disk, or VHD, from one PC to another?), and higher memory requirements. Containers, by contrast, leverage the operating system that is already in place but offer nearly as much separation. RAM requirements are lower since the OS isn't being duplicated in each container, and cost is lower, too, because while cloud platforms typically charge for each VM, a single VM can host multiple container instances.
• #51: Docker (www.docker.com) isn't the world's only containerization platform, but it is the most popular. It is free, open-source, and Linux-based, with Windows support (Windows Server 2016) in the works. It has earned massive mindshare in the developer community. And with Azure Container Service, you can deploy Docker containers to Azure with minimal effort. Moreover, Docker containers are easily moved between Azure and Amazon Web Services (AWS), affording developers portability between cloud platforms.
• #52: Docker utilizes a client-server architecture. You execute Docker commands through a Docker client such as the Docker CLI or Kitematic. The client uses REST commands to communicate with the Docker daemon running on a Docker host such as the Azure Container services. These commands can be used to push, pull (docker pull), and create Docker images, to run them in containers, and to manage those containers. Images can be built with the docker build command, and they can be stand-alone, or they can "inherit" from other images. Images are stored in Docker registries, which can be public or private, local or remote. Docker Hub is a popular public registry that is managed by Docker; it contains a "huge collection" of images that anyone may use. The docker run command runs a container using an image as a template.
• #53: The Docker Client, also known as the Docker CLI, is the primary tool you use to manage Docker containers. You can download container images from repositories such as Docker Hub, build container images, run container instances, list container images and instances, and much more. After connecting to Azure Container Service using SSH, you can use port forwarding to execute commands locally that act on an Azure Container Service running in the cloud. In this example, the -H switch used with the docker commands forwards commands sent to port 22375 on localhost to the Azure Container Services via SSH.
• #54: This command pulls the image named "Ubuntu" from Docker Hub (or a local registry if the image is cached there) and runs it interactively in a container. "Interactively" means standard input, output, and error are connected locally so you can provide input to the container and see its output. Of course, you are not limited to the "Ubuntu" image. You can specify other images and even create images of your own with docker build. Where the container runs depends on the context. The container can run locally in a docker host (for example, a VM on Windows), or it can remotely if you connect to a remote Docker daemon (for example, one running in Azure) via SSH tunneling and use port forwarding to forward docker commands to the daemon.
• #55: These are some of the most commonly used docker commands. You can also use docker push to push an image to a registry such as Docker Hub. Also, docker ps is often accompanied by a -a switch to list all containers, including those that are no longer running, while docker rm and docker rmi are used to delete (remove) containers and images, respectively. The docker build command uses a Dockerfile (a text file containing build commands) and a "context" -- for example, a specified directory in the file system -- to build Docker images.
• #56: From the documentation: "Azure Container Service makes it simpler for you to create, configure, and manage a cluster of virtual machines that are preconfigured to run containerized applications. It uses an optimized configuration of popular open-source scheduling and orchestration tools. This enables you to use your existing skills, or draw upon a large and growing body of community expertise, to deploy and manage container-based applications on Microsoft Azure." ACS supports Linux containers and Windows containers. The latter rely on Windows Server 2016.
• #57: Orchestration in the context of containers is the deployment and management of containers across infrastructure and networks. It provides the tools and software defined infrastructure needed to deploy containers. Containers by design are intended to be deployed in large volumes with some applications using dozen to even thousands of containers. With this type of scale, automating deployment and management of containers with Orchestration Software becomes necessary.
• #58: A container cluster is intended to have redundancy for load balancing, scalability, and high availability. A cluster is composed of one or more Master Nodes which control the orchestration for scaling and delegation of tasks to the agents as well as provide monitoring. The Agent Nodes actually run the container loads.
• #59: Kubernetes is an open-source platform for automating deployment, scaling, and operations of application containers across clusters of hosts, providing container-centric infrastructure. With Kubernetes, you are able to quickly and efficiently respond to customer demand: Deploy your applications quickly and predictably. Scale your applications on the fly. Seamlessly roll out new features. Optimize use of your hardware by using only the resources you need.
• #60: Datacenter Operating System is, as the name implies, an operating system for for a datacenter rather than for a phyiscal of virtual machine. DC/OS abstracts away the underlying hardware from applications and provides much of the needed infrastructure that would otherwise come from multiple disparate services on traditional networks. This enables operations and developers alike to deploy and maintain applications in a uniform fashion with less time and resources spent monitoring the supporting network and network services for those applications.
• #61: Docker Swarm is the orchestration engine from Docker. It has tight integration with Docker, so many of the same paradigms and tools that used with Swarm seamlessly as well as some additional features like overlay networks and Docker services that can run multiple containers spread across multiple hosts. These containers can seamlessly communicate and rapidly scale.