From Zero to Serverless

Editor's Notes

• #6: Get Hardware Get and install Operating System Get and install application framework (No Click) Deploy code to the server Host all of this somewhere in your datacenter (No Click) Bunch of questions Backup for your apps Physical Security Scaling Up Monitoring (hardware and application) And so on Realy important question – but not key to core competency
• #7: Infrastructure as a Service
• #8: Platform as a Service A lot of decisions are easily configurable (Click) But still have to think about how to scale
• #9: Only Problem: How to build your app to best solve business problem?
• #10: Like many trends in software there is no one clear view of what ‘Serverless’ is, and that is not helped by it really coming to mean two different but overlapping areas. Area #1 – Serverless was first used to describe applications that significantly or fully depended on 3rd party applications or services (“in the cloud”) to manage server-side logic and state. These are typically “rich client” applications (think single page web apps or mobile apps) that use the vast ecosystem of cloud accessible databases, authentication services, etc. <CLICK> These type of services are better referred to as Backend as a Service (BaaS) Area #2 – Serverless can also mean applications where some amount of server-side logic is still written by the application developer but unlike traditional architectures is run in stateless compute containers that are event-triggered, ephemeral (may only last for one invocation), and fully managed by a third party. <CLICK> One way to think of this is Function as a Service (FaaS).
• #13: Monolith Microservices Functions  Nano Services
• #14: Complexity: Managing a monolithic application as a single unit is more straightforward than managing a fleet of purpose-built functions and the dependencies between them. Organization Support: It’s a non-trivial consideration for some to move to a serverless paradigm No Runtime Optimization: By its very nature, you mostly do not have control over the execution environment for the workload.
• #16: The first “pay as you go” code execution platform was Zimki, released in 2006, <click>but it was not commercially successful – domain is for sale Google Cloud Functions : Event-driven serverless compute platform AWS Lambda : Run code without thinking about servers. Pay only for the compute time you consume. IBM Cloud Functions: Based on Apache OpenWhisk, IBM Cloud Functions is a polyglot function-as-a-service programming platform for developing lightweight code that scalably executes on demand Auth0 WebTask: All you need is code
• #17: Azure Functions is an event-driven compute experience that allows you to execute your code, written in the programming language of your choice, without worrying about servers. Benefit from scale on demand and never pay for idle capacity. Logic Apps provides serverless workflows that allow developers to easily integrate data with their apps instead of writing complex glue code between disparate systems. Logic Apps also allow you to orchestrate and connect the serverless functions and APIs of your application. Event Grid is a fully managed event routing service that enables rich application scenarios by connecting serverless logic to event coming from multiple Azure services or from your own apps.
• #18: Backend as a Service Azure Databases deliver a database ally for your serverless app. Azure SQL, MySQL, and Progress provide industry standard database capabilities. Cosmos DB is a multi-model database service that provides transparent scaling and replication of your data to wherever your users are. Azure Storage provides durable, highly available, and massively scalable cloud storage to developers for cloud applications. Get options for unstructured object data, structured datasets, file storage, and queue storage for serverless communication between cloud apps. Azure Active Directory provides cloud-based identity and access management. Using it, developers can securely control access to resources and manage and authenticate the users of their serverless apps. IoT Azure Stream Analytics is a fully managed analytics service for real-life streaming data. It allows you to author queries in simple, declarative, SQL-like language, and you only pay for the processing used per job. Event hubs is a fully managed service that simplifies mass ingestion of small data inputs, typically from devices and sensors, to process, route, and store the data. Azure Bot Service allows you to build intelligent serverless bots that can interact with your users contextually through multiple channels like text/SMS, Skype, Microsoft Teams, Slack, Office 365, Twitter, and other popular services. Cognitive Services allows you to easily add intelligent features such as emotion and sentiment detection, vision, and speech recognition, language understanding, and knowledge and search – into your app. Using these services through serverless code or logic workflows minimizes the learning curve for creating intelligent apps.
• #20: Cake Diagram Azure Functions are built on top of Azure App Service and WebJobs SDK
• #21: Choice of language: Azure Functions is a polyglot solution which allows you to write functions in not just C#, F#, and JavaScript, but also Java, Python, PHP, TypeScript, Batch, Bash, and PowerShell
• #22: Pay-per-use pricing model: Pay for only the time spent running your code. Azure Functions consumption plan is based on per-second resource consumption and executions.
• #23: Bring your own dependencies: Functions support both NuGet and NPM, so you can use your favorite libraries.
• #24: Integrated security: Protect HTTP-triggered functions with OAuth providers such as Azure Active Directory, Facebook, Google, Twitter, and Microsoft Account.
• #25: Simplified integration: Easily leverage Azure services and software-as-a-service (SaaS) offerings. These services can trigger your function and start execution or they can serve as input and output for your code. Such services include Cosmos DB, Event Hubs, Event Grid, Mobile Apps, Notification Hubs, Service Bus, Azure Storage, GitHub, and Twilio SMS messages
• #26: Flexible development: Code your functions right in the portal or set up continuous integration and deploy your code through GitHub, Visual Studio Team Services, and other support development tools including OneDrive, Bitbucket, Dropbox, and either a local or external Git repository
• #27: Open-source: The Functions runtime is open-source and available on GitHub
• #28: Grate for processing data, integrating systems, working with IoT, simple API’s, and microservices There are a number of templates that can get you started in a lot of different possibilities
• #29: Key with Azure Functions is that is supports Triggers to start execution Bindings to simplify code for input and output of data
• #30: There are two major versions of the Azure Functions runtime: 1.x and 2.x Cross-platform development: Runtime 1.x support development and hosting only in the portal or on Windows. Runtime 2.x runs on .NET Core, which means it can run on all platforms supported by .NET Core, including macOS and Linux. This enables cross-platform development and hosting scenarios that are not possible with 1.x.
• #31: Languages: Runtime 2.x uses a new language extensibility model. Initially, JavaScript and Java are taking advantage of this new model. Azure Functions 1.x experimental languages have not been updated to use the new model, so they are not supported in 2.x. The experimental languages are Python, PHP, TypeScript, Batch, Bash, and PowerShell.
• #32: Runtime 2.x uses a new binding extensibility model that offers several advantages: Support for third-party binding extensions Decoupling of runtime and bindings. This allows binding extensions to be versioned and released independently. You can, for example, opt to upgrade to a version of an extension that relies on a new version of an underlying SDK. A lighter execution environment, where only the bindings in use are known and loaded by the runtime Microsoft Graph bindings – allow you work with data, insights and events from the Microsoft Graph. Use the Microsoft Graph API to connect to the data that drives productivity – mail, calendar, contacts, documents, directory, devices, and more. Durable Functions is an extension of Azure Functions and Azure WebJobs that lets you write stateful functions in a serverless environment. The extension manages state, checkpoints, and restarts for you.
• #33: Four different tools you can use to work with Azure Functions Azure Portal – Quickly get started without having to install anything else Visual Studio 2017 – First class C# development experience Visual Studio Code – First Class Node.js development experience plus you can edit any function project generated via the CLI Azure Functions Core Tools (CLI) – Build any kind of function and edit in IDE of your choice
• #38: Azure Functions Proxies allows you to forward requests to other resource. You define an HTTP endpoint just like the HTTP trigger, but instead of writing code to execute when the endpoint is called, you provide a URL to a remote implementation. This allows you to compose multiple API sources into a single API surface which is easy for clients to consume. This is particularly useful if you wish to build your API as microservices (or nanoservices). A proxy can point to any HTTP resource, such as: Azure Functions API apps in Azure App Service Docker containers in App Service on Linux Any other hosted API Routing
• #40: Azure Functions Proxies allows you to forward requests to other resource. You define an HTTP endpoint just like the HTTP trigger, but instead of writing code to execute when the endpoint is called, you provide a URL to a remote implementation. This allows you to compose multiple API sources into a single API surface which is easy for clients to consume. This is particularly useful if you wish to build your API as microservices (or nanoservices). A proxy can point to any HTTP resource, such as: Azure Functions API apps in Azure App Service Docker containers in App Service on Linux Any other hosted API Routing
• #41: Consumption Plan restrictions The timeout value can be changed by changing the functionTimeout property in host.json Durable Functions is an extension of Azure Functions and Azure WebJobs that lets you write stateful functions in a serverless environment. The extension manages state, checkpoints, and restarts for you.
• #43: Online orders are picked up for a queue, processed, and the resulting data is stored in a database
• #44: Colleagues use mobile backing to reimburse each other for lunch; the person who paid for lunch requests payment through his mobile app, triggering a notification on his colleagues’ phone.
• #45: Patient records are securely uploaded as PDF files. That data is then decomposed, processed using OCR detection, and added to a database for easy queries.
• #46: Huge amounts of telemetry data is collected from a massive cloud app. That data is processed in near real-time and stored in a DB for use in an analytics dashboard.
• #47: A customer database is analyzed for duplicate entries every 15 minutes, to avoid multiple communications being sent out to the same customers.
• #48: A SaaS solution provides extensibility through webhooks, which can be implemented through Functions, to automate certain workflows.
• #51: You can run Azure functions in two different modes <click>: Consumption plan and App Service plan. The Consumption plan automatically allocates compute power when you code is running, scales out as necessary to handle power when your code is running, scales out as necessary to handle load, and then scales down when code is not running. You do not have to pay for idle VMs and do not have to reserve capacity in advanced. In the App Service plan, your function apps run on dedicated virtual machines similar to Web Apps. <CLICK> Basically the Consumption plan takes care of everything but your code for you; whereas the App Service plan requires you to handle at least the configuration of all that. The Consumption plan is the default hosting plan and offers the following benefits: Pay only when your functions are running Scale out automatically, even during periods of high load Consider an App Service plan in the following cases: You have existing, underutilized VMs that are already running other App Service instances You expect your function apps to run continuously, or nearly continuously. In this case, an App Service Plan can be more cost-effective. You need more CPU or memory options than what is provided on the Consumption plan You need to run longer than the maximum execution time allowed on the Consumption plan (of 10 minutes) You require features that are only available on an App Service plan, such as support for App Service Environment, VNET/CPN connectivity, and larger VM sizes You want to run your function app on Linux, or you want to provide a custom image on which to run your functions
• #52: Usage is aggregated at the function app level and counts only the time that function code is executed. Azure bills using two different units: Resource consumption in gigabyte-seconds (GB-s). Computed as a combination of memory size and execution time for all functions within a function app. So if a function uses 512-Mb of memory and runs for 1 seconds, then each execution uses 0.5 GB-s. Executions: Counted each time a function is executed in response to an event trigger.
• #53: Pricing Example: A function with observed memory consumption of 512-Mb executes 3,000,000 times during the month and has an execution duration of one second. Monthly billing would be calculated as follows: <CLICK> Resource Consumption Billing Calculation 3 million executions x 1 second per execution equals 3 million seconds If the resource consumption is 512-Mb over 3 million seconds; you get 1.5 million GB-s There is a monthly free grant of 400,000 GB-s, so that reduces our scenario to 1.1 million GB-s to be charged for Resource consumption is charged at $0.000016/GB-s; so that would come out to $17.60 Execution billing calculation There were 3 million execution and Microsoft gives you 1 million free executions a month So we are billed for 2 million executions at 20 cents per million executions; so that would be 40 cents Total consumption billing calculation So when you add the $17.60 from resource consumption cost and 40 cents for the execution cost; our total month bill is $18.00
• #54: The following are best practices in how you build and architect your serverless solutions using Azure Functions.
• #55: Idempotent – Clients can make the same call repeatedly while producing the same result. In other words, making multiple identical requests has the same effect as making a single request. Note that while idempotent operations produce the same result on the server (no side effects), the response itself may not be the same – a source’s state may change between requests.
• #56: Large, long-running functions can cause unexpected timeout issues. A function can become large due to many Node.js dependencies. Importing dependencies can also cause increased load times that results in unexpected timeouts. Dependencies are loaded both explicitly and implicitly. A single module loaded by your code may load its own additional modules. Whenever possible, refactor large functions into smaller function sets that work together and return responses fast. For example, a webhook or HTTP trigger might require an acknowledgment response within a certain time limit; it is common for webhooks to require an immediate response. You can pass the HTTP trigger payload into a queue to be processed by a queue trigger function. This approach allows you to defer the actual work and turn an immediate response.
• #57: Durable Functions and Azure Logic Apps are built to manage state transitions and communication between multiple functions. If not using Durable Functions or Logic Apps to integrate with multiple functions, it is generally a best practice to use storage queues for cross function communication. The main reason is storage queues are cheaper and much easier to provision. Individual messages in a storage queue are limited in size to 64-KB. If you need to pass larger message between functions, an Azure Service Bus queue could be used to support message sizes up to 256-Kb in the Standard tier, and up to 1-Mb in the Premier tier. Service Bus topics are useful if you require message filtering before processing. Event hubs are useful to support high volume communications.
• #58: Functions should be stateless and idempotent if possible. Associate any required state information with your data. For example, an order being processed would likely have an associated state member. A function could process an order based on that state while the function itself remains stateless. Idempotent functions are especially recommended with timer triggers. For example, if you have something that absolutely must run once a day, write it so it can run any time during the day with the same results. The function can exit when there is no work for a particular day. Also if a previous run failed to complete, the next run should pick up where it left off.
• #59: Assume your function could encounter an exception at any time. Design your functions with the ability to continue from a previous fail point during the next execution. Consider a scenario that requires the following actions: Query for 10,000 rows in a database. Create a queue message for each of those rows to process further down the line. Depending on how complex your system is, you may have: involved downstream services behaving badly, network outages, or quota limits reached, etc. All of these can affect your function at any time, You need to design your functions to be prepared for it. How does your code react if a failure occurs after inserting 5,000 of those items into a queue for processing? Track items in a set that you have completed. Otherwise, you might insert them again next time. This can have a serios impact on your workflow. If a queue item has already processed, allow your function to be a no-op.
• #60: There are a number of factors which impact how instances of your function app scale. The following are some best practices to ensure optimal scalability of a function app. Functions within a function app share resource. For example, memory is shared. If you are using a function app in production, do not add test-related functions and resource to it. It can cause unexpected overhead during production code execution. Be careful of what you load in your production function apps. Memory is averaged across each function in the app. Do not use verbose logging in production code – it has a negative performance impact.
• #61: Asynchronous programming is a recommended best practice. However, always avoid referencing the Result property or calling the Wait method on a Task instance. This approach can lead to thread exhaustion.
• #62: Some triggers like Event Hub enable receiving a batch of messages on a single invocation. Batching messages has much better performance.
• #63: The host.json file in the function app allows for configuration of host runtime and trigger behaviors. In addition to batching behaviors, you can manage concurrency for a number of triggers. Often adjusting the values in these options can help each instance scale appropriately for the demands of the invoked functions. Settings in the hosts file apply across all functions within the app, within a single instance of the function. For example, if you had a function app with 2 HTTP functions and a concurrent request set to 25, a request to either HTTP trigger would count towards 25 concurrent requests. If that function app scaled to 10 instances, the 2 functions would effectively allow 250 concurrent requests (10 instances * 25 concurrent requests per instance).