The State Of Serverless

Raymond Mulligan, Mike Myers at UXDX Europe. Video: https://youtu.be/1uSWEi3vHNc

Readable transcript: edited from the recording's captions for readability (fillers and false starts removed, punctuation and section headings added). Wording is the speaker's own. Timestamps are positions in the video. Names marked [?] could not be verified against the audio.

Introductions and what serverless means

[00:00:06] Raymond: Hey everybody, is everyone okay? Thanks very much for that introduction, Olivia. My title, which was up on the board, is a little bit hard to say, so I've actually changed it myself to application modernization specialist, which makes it easier to talk about. The important note there is that I work with customers a lot, enterprise customers, most of our enterprise customers in Ireland, helping them transition their workloads to the cloud and everything that involves, whether it's rehosting, just lift and shift, all the way to modernization. And Mike here.

[00:00:45] Mike: Mike Myers. Get the jokes out of the way; Dr. Evil, I've heard them all before. My role is cloud solution architect, so very similar to Raymond's. I work with a lot of major companies around cloud adoption, and software architectures as well.

[00:01:05] Raymond: Cool, thanks, Mike. On the agenda: hopefully by the end of this you'll have an understanding of what serverless is and what you can use it for, and learn what we've got available in the Azure platform for serverless capabilities.

[00:01:24] I suppose the first question is, what is serverless? It's a fairly new term. Well, it's not that new, but it's being used a lot more often now. The idea behind it is that no matter what we say, there are still servers there; it's just that you don't have to manage them. You don't have to care about scaling them. You don't have to care about the underlying infrastructure. It allows developers to focus on what they should be doing, what they think about doing: building applications, building scalable applications, without wondering how it's going to scale and how it's going to be managed. The important thing there is that the likes of IDC and Forrester, what the market is saying, is that serverless is becoming really popular, and most enterprise businesses are going to start adopting it a lot more over the next couple of years.

[00:02:18] It's a transition. Very recently we had the adoption of microservices, and everybody has used microservices a lot. This is the next step on. It's more like nano services, or function as a service, so it's even smaller than a microservice. It's a small piece of something that does one thing, but does it very well, and it's handled independently and can scale on its own.

The Azure serverless landscape

[00:02:44] Here's some of the functionality that we have in Azure to help with serverless principles and serverless methodology. We work with customers all the time, and some of them are already well along their cloud adoption journey and some haven't done anything with it at all. We start to talk about lift and shift, and as you move towards the top end of this graph, that's where you're going to get the most benefit, using something that's in the top: your software-as-a-service offerings, the likes of PowerApps or Office 365 or Microsoft 365 or whatever it is. At the start, the bottom of the journey, you talk about infrastructure as a service, and that's Windows or Linux, open source or whatever it is, and you can talk about rehosting, refactoring [?] or rebuilding your applications in the Azure platform.

[00:03:29] When you move further up, you start to think about the containerization of those solutions and what we've got available in Azure for that: Container Instances, Kubernetes Service, App Service and Service Fabric. Then you move up to the more modernized functions, what we've got for serverless capability: your Azure Functions, your Event Grid, your Logic Apps, and then PowerApps and Flow. On the right-hand side, for your automation, you've got your Event Grid, Azure Functions and Logic Apps. I'll go into each one of these a little bit more later. But it's important to think about serverless: serverless is not just functions. It's not just something that sits there that you can action. There are a lot of services that we have available in Azure that help the serverless journey, and one of them is storage.

[00:04:25] One thing before I go into each one of these: how many people in the room are actually using Azure at all? Just give us a show of hands. I'd say well less than half. So you might not know that all this capability is there, and they're serverless functions, effectively: you can use them as you need. With storage, you can use it for unstructured or structured data, or files, or queues, and you can integrate them into your applications. There are quite a few services here. What I said earlier on is that this is about what serverless is; Mike is going to go into why you would use it and how you would use it a little bit more. So this is just giving you an idea of what we've got available and what serverless actually is.

Cosmos DB, Active Directory, Event Grid and Service Bus

[00:05:16] Azure Cosmos DB is a brilliant service. It's the move on from DocumentDB, if anybody has used DocumentDB. It's multi-channel, multi-scale, multi-application. There are multiple APIs available, and you choose what you want to use: a graph API, DocumentDB, columns or key-value pairs. You can choose whatever you want to use. But the most important part is that it's a truly global application, and more importantly a truly global database, and more importantly it's multi-master. You can master the database in Australia or in the US or wherever, but you can also master the database in Dublin or Amsterdam or wherever you want in your region, and Cosmos DB manages the synchronization in the background. You can bring the data as close to your customers as is needed using Azure Cosmos DB.

[00:06:24] Mike: One of the things that we're seeing working with a lot of customers is that when you talk about global solutions, truly global solutions, Cosmos DB plays a part. When we talk about having a data center in, say, Europe, a data center in the US or in Asia, Cosmos DB tends to underpin that, underpin the services that actually use it.

[00:06:45] Raymond: Thanks, Mike. Azure Active Directory: this is synchronization of your on-premises Active Directory for single sign-on [?] authentication for your application in the cloud, and it synchronizes your users directly to Azure, so you can use that. There are multiple services in there: Azure Active Directory, Azure Active Directory B2B and B2C as well. They're all available as part of that, so you can use them for strong authentication.

[00:07:11] Event Grid is a simple way of managing events from any source to any destination. It's a very powerful tool, and it's fully managed as well. Service Bus is also a communication tool that a lot of the enterprise customers we're working with at the moment use. There are some very important things there that you don't get in storage. Storage has queues as well, but with the likes of Service Bus you get first in, first out [?], out of the box, with Service Bus queues, and you can use it to decouple your application. It really falls into the serverless architecture as well.

Logic Apps, API management and streaming services

[00:07:55] Logic Apps allows you to build simple workflows for your applications. If you haven't tried it, have a go. It's a drag-and-drop interface, but there are thousands of connectors there that you can use to pull in things like Cognitive Services, which I'll talk about in a second. It's a powerful tool that you can pull in. It's very similar to a fourth-generation tool.

[00:08:24] Mike: Yeah, it reminds me a bit of BizTalk, the orchestration engine there. It's really for integration.

[00:08:32] Raymond: Yeah. API Management as well. When you want to monetize your data and your services, but also bring channels out to your customers, you use API Management for that. I know I'm flying through these; there are a lot of services, but I wanted to give you an idea of the breadth of the services that we have. Function Proxies allows you to manage your APIs, but it's also a separate billable service. It's a smaller version of API Management, like API Management Lite, but for your functions.

[00:09:15] Stream Analytics: with Stream Analytics you can process multiple parallel streams of information from non-IoT or IoT devices or services, and use a simple SQL-like query language to query them. Event Hubs is a hub that can be used for big data streaming and event processing. It can handle millions of messages per second, so it's a very, very powerful service.

[00:09:58] Mike: Just to indicate there on Event Hubs: it's designed for maximum IOPS, so it's designed for high volumes of data. What we'll see when we go later into some of the slides is that there are a lot of these services, and the challenge tends to be which service you actually use, because each of these services will have its own guarantees and its own SLA, et cetera. We'll go into that later on.

Bots, Cognitive Services and Azure Functions

[00:10:24] Raymond: The Bot Service. There's a lot of talk about bots at the moment, but the Bot Service is a complete environment that you have available for building your bots. You can build them, test them, automate them and deploy them as part of this service. It's a really powerful service, and it's really easy to use as well; there are lots of tutorials available that you can use. Cognitive Services is probably one of my favorite services in the serverless technology. You can build intelligent algorithms to infuse into your applications very simply: they can listen, they can see, they can speak, and they can understand what you put into your application and give you some real-time analysis around it. Sentiment analysis is one of the things that I've used lately: just monitoring text that's coming in, and how positive or how negative it was, and then you can use that to do something with a function later on.

[00:11:29] Azure Functions. For a lot of people, when you talk about Azure serverless components, functions is the only thing that comes to mind. I've talked about all the other things, but functions is really important as well. It's probably one of the bigger areas. It's something that you can deploy to the cloud, but it's completely independent. It can scale independently, and it does a simple action, or a fairly complicated action, and I'll show you in a second how you would implement them. It can be used from anywhere: from your API services, from applications, or from event-driven sources, directly from something that landed in OneDrive, or something that has an event hub, or whatever else. Function as a service has been adopted as the serverless technology term.

[00:12:25] These are the important parts that we talked about. Serverless functions have a single responsibility. They're short-lived, so they do something, do it really quickly and move on. They're completely stateless, they're event-driven, and they're independently scalable as well. There are some ways that you can run these. You can use consumption, so every time it's fired, it just consumes for however long it's running. The important thing to note here is that you can use any language you want. It doesn't matter what you use, whether it's Windows or Linux or any dependent technologies. Then the App Service plan: you would use the App Service plan for deploying a web application, an API or mobile apps, but you can also use it for functions as well, if you've got a long-running application.

[00:13:13] Mike: It's worth, before we go on, highlighting the difference between the two. The consumption side is really where, with the function, you only pay for the execution time of that function. Previously, when you were building applications, you had to deploy the application, put it on a VM, and pay for the full consumption of that virtual machine 24/7. When you move to the consumption model with serverless, you only pay for a couple of milliseconds of consumption. If you architect your systems correctly, you reduce the cost. The other model is where we move to an App Service plan, where you may need something that's long-running. Think about building a service itself that has to be long-running. That's where you would use the App Service plan, because you're running against a virtual machine, so you're paying 24/7 for that one. The way you architect the system, the software architecture, plays a big part in your consumption.

Where functions can run: isolated, on premises and on the edge

[00:14:07] Raymond: Thanks, Mike. App Service Environment is another way of running your serverless functions as well, but the important part about this is network isolation. It's a completely dedicated cloud environment. If you need to keep it completely separate, in your own VNet and subnet, and lock it down that way, you can use your App Service Environment.

[00:14:34] Further, Azure Stack. Azure Stack is our on-premises version of Azure. It's hardware that you deploy on your premises network, and most of the services that you've got in the Azure cloud are available on Azure Stack. They're slightly behind the current version of what we've got in the Azure cloud, and that's intentional, and they always will be. But it's a really important service for running a completely isolated environment. If you have a contractual application where you can't push something to the public cloud, you can still get the Azure capabilities but run on premises. Some of the uses are things like cruise ships or oil rigs, which are completely isolated. And the Azure Functions runtime. Mike, do you want to mention a bit about that?

[00:15:26] Mike: Basically it allows you to run on a local server, so you can run it locally without consuming on the cloud, and therefore you can reduce the cost. If you move to the next bit there, Ray: this is similar to IoT Edge. IoT Edge is important. When you're building IoT systems, it tends to be that the devices send a message to the back end, the Azure side, where a function will kick in, and that's where you start consuming. What we're actually showing here is that the functions can run on the device. That means if you want to do any pre-processing, you can pre-process on the device before it even hits the cloud, and that way reduce the cost. The message across all of this stack is that there are different options, different ways of architecting your system, and again, if you architect it correctly, you can reduce the cost.

[00:16:21] Raymond: There's a massive uptake on IoT Edge, because think about all the IoT devices constantly streaming data to the cloud. Before IoT Edge, they weren't doing anything smart with that data. They were pushing it up, and the cloud had to do all the crunching on it. But now you can use the likes of Azure Functions to do some of the crunching locally on the device and then push it up after you've done that. It's a really important message, and there's a lot of uptake on that.

[00:16:48] Mike: What we're seeing, particularly in the IoT space, is that the devices are quite smart. They actually have microservices on the devices themselves, and functions and so forth, so it's quite clever.

[00:17:01] Raymond: Some of the ways to write functions: in the Azure portal, Visual Studio Code, Visual Studio and IntelliJ. Again, the important thing is that it doesn't matter if you're a C# developer or a Java developer or whatever language you want to use. Bring it, and you can use it to create your functions. So why and when should you use functions, Mike?

When to use functions

[00:17:22] Mike: Typically, the way you need to look at this serverless architecture is when you need something that's going to respond to an event. The two typical architectures you will use it with tend to be event-driven architectures, or APIs, where you're building out APIs. You need to think about serverless architectures as falling onto functions for the most part, although there are the other services Ray listed there. We're at the functions level. We had services, then we had microservices, and functions fall into the nano services model, so it's breaking that microservice down even smaller. Because you've broken it down even smaller, those functions are event-driven, and you only pay for when those functions work, if it's in that consumption model.

[00:18:11] Another thing to understand is that it's for when you don't need full control of your environment for a task. In other words, you're passing it off. It's almost like a fire-and-forget model: you fire it off, you let it do whatever it does, and maybe there's a callback happening or something else. It's very much an asynchronous programming model, and you need to accept some latency there. Obviously understand that it's a fire-and-forget model; that's the way it's designed. It's an asynchronous model by nature.

[00:18:47] Here are some of the scenarios where we see people use this. Web application back ends, where you're building an API and you have an application consuming and talking to the API. Similarly, mobile devices, Android or iOS, talking to a back end where functions are going to kick off. IoT is big for us; functions tend to be used there quite a lot. Conversation, using the bot framework; we have our own bot framework. File processing, real-time stream analytics, and then automation. When you build out solutions with any cloud provider, you build the solution and get it working, and then you may need to do some automated tasks around the upkeep of that environment or the application. Functions can be used as part of this process as well.

Sample architectures

[00:19:41] I just want to show you some sample architectures of how you would use this. This is an example showing a web page which calls into a webhook. At that point, the webhook fires off some code. The code executes, maybe calling against the SQL database or Cosmos DB, doing some query operation, gets the data and returns the results, and then the page is consumed. From how that would look on the Azure side: that function would be completely hosted in Azure in a consumption model, because you're only paying for it to run. It's not a long-running option at all; you'd fire off the function, and the web application would just be in an App Service model. So the cost of it would actually be quite cheap.

[00:20:37] IoT: this is a typical IoT solution. IoT systems by nature are very complex. I've been involved in a few of them, and they take a long time. But at the basic level, this is what we're talking about: some sort of device, or maybe a mobile application, sending data into Azure. Typically that comes in through Stream Analytics, which consumes the data, performs some action on it, and pushes it out for some action to happen. What's actually happening here is that it's sending it out to a function, which acts as a trigger. The function does some operation on the data, talks to Cosmos DB, and pushes the data wherever it needs to be, or takes an action. A typical scenario might be command and control, to turn on a heater or something like that.

[00:21:28] This is a typical SaaS integration. In this example we show how you can take an Excel spreadsheet and save it up to OneDrive. A function is listening on that location. The function kicks off, does something against the Graph API, modifies the data in the spreadsheet, adds some graphs or whatever, puts it back in the location, and sends an email to the person that it's ready.

[00:21:57] This is one we see a lot. We actually have this as a dedicated scenario: a lot of times we do shortcut scenarios where we will build some code for you, and this is one of those. A lot of times you have to store an image and break it down into smaller images, so that you can display them in your product catalog on an e-commerce site. This shows what happens. The image is sent from a mobile device, a function kicks off and puts it into blob storage just to store the image, and then another function takes it from blob storage in an asynchronous manner, modifies it, and saves it as multiple file versions, and then we're done.

[00:22:38] The point of what you're seeing in this one is that we have multiple functions working. The danger you may face when using serverless, and using functions particularly, is that you over-engineer your software architectures with too many functions, and it becomes a bit of a Spaghetti Junction. I'd strongly advise you to make sure you get your architecture right and don't do too many functions. If you can manage them, great, but just be careful. That's more of a software design thing.

Event processing and serverless APIs

[00:23:11] The two key architectures I want to talk about: first, the event processing architecture. This is the one we see all the time, where basically we're coming from some source, kicking into an event broker. Typically that tends to be an event hub or an IoT hub. It doesn't always have to be an IoT system; Event Hubs tend to get used quite a bit. Maybe a Service Bus queue, maybe a storage queue, or an Event Grid or HTTP process. The point is this sits in most of your software architectures. I can think of hundreds of reasons why you'd do it. But fundamentally, what's happening is it's kicking into an Azure function, which will talk to a destination, and at that point you enact on it.

[00:24:02] In an event processing architecture, some of the key considerations are that each of the sources you use from the previous slide has different guarantees, and they are designed to do certain things. You need to understand that some of the services look the same, but they are aimed at particular scenarios. Don't get confused between using queues and, say, using an event hub. An event hub, as I mentioned earlier, is designed for IoT, for fast IOPS, whereas something like a storage table or a storage queue is not designed for that. It's got a restriction of about 20,000 requests per second, which wouldn't be the case with an event hub. You need to understand the services you're using and the SLAs associated with each of these as well.

[00:24:50] Just conscious of time here. The other one I want to talk about is the serverless API, and this is what we're seeing most customers do. I can't actually think of any customers who aren't building some sort of API. What's happening is they've moved from the SOA world into the microservices world. Everyone's doing microservices. They're doing either Kubernetes or Service Fabric of some sort. Everyone's deploying containers; that's where the marketplace is at the moment. But you can see where it's going. The next step beyond containers is serverless architectures: from microservices to nano services, and that's where we build these out with multiple functions together. The challenge will always be the maintenance of these functions, the software design.

[00:25:38] When you get into this architecture, what's really key is API management. Is anyone using any API management tools at the moment? I'd strongly advise that you get into API management, because it provides an ecosystem for those APIs. Typically they provide services like authentication and policy, traffic routing and monitoring, versioning of these nano services, these functions, and documentation, the Swagger documentation. It will also do things like, maybe one customer wants this function to return data in XML form and another wants it in CSV; it will do that transformation for you as well. There are multiple products out there: MuleSoft, our API Management, Apigee. There are loads of these products, but it is certainly key to a successful software architecture around this.

Resources and closing

[00:26:43] With that, I just want to highlight some of the case studies where we've actually done this. We have a marketing case study site and a technical case study site. The technical case studies are actually quite good, because they have Git repositories. There are an awful lot of samples there, a lot of code libraries, and some basic serverless bits for Visual Studio as well. There's an additional link I will send out, around a microservices reference architecture that uses functions as well, and we provide all the code to use in either Service Fabric or Kubernetes. We'll amend this slide and put that link in.

[00:27:26] Raymond: They're available under reference architectures in the Microsoft documentation anyway, so if you search for it, you'll find it very easily. And I suppose the last closing comment on this: if you're not looking at serverless, please do. It is the future. Customers are moving to it, and it reduces your cost, it reduces your spend, and it also reduces the maintenance and uptime problems you may face. Thank you very much.