Serverless Computing - Simply Explained

0:00 Welcome to the M365 FM podcast, where we explore the people, ideas and technologies shaping the future of work. Why the word serverless trips almost everyone up. The word serverless is a lie, and the truth behind it is far more useful. There's no such thing as computing without servers, but there's a way to stop renting machines you barely use that quiet waste drains real budgets, and it's the exact problem this whole idea was built to attack. Welcome to the M365 FM podcast, where we explore the people, ideas and technologies shaping the future of work. By the end, you'll understand serverless in plain language. Spot it inside power Automate and know where it honestly doesn't fit what serverless computing actually means. Start with the honest definition, because the name does you no favors.

0:41 Serverless computing is a cloud model where the provider runs the machines. You supply the thing you actually care about, which is your code or your workflow. Microsoft describes it as a model that removes the need to manage servers you focus on building while the platform handles the infrastructure, the scaling, and the upkeep. The servers are still there, and that's the part the name gets wrong somewhere in a Microsoft data center, real machines run your code and real people patch them, replace failed disks, and watch the power draw. You simply never see any of it. That's why the industry calls the term a misnomer, because serverless was never about deleting servers. It was about deleting your responsibility for them. You might assume this is a club for developers only, but the door is wider than it looks, and this episode walks you through it at your own pace. You will hear two flavors of this idea, and they're easy to tell apart once the acronyms drop away.

1:26 The first is function as a service, where you write small pieces of code that run when an event arrives. A function is a short unit of work that does one job, like resizing an image or sending a notification. The other is backend as a service. Instead of building a service yourself, you use one that already exists and connect to it through an application programming interface. That interface is simply a way for two pieces of software to talk to each other. The phrase that ties both together is event driven. An event is simply something happening, like a file landing in a folder, a message arriving, or a timer going off. When the event happens, the code runs. When nothing happens, nothing runs, and that quiet is the entire point of the model. Compare that to renting a virtual machine, which is the older way of doing this.

2:06 You pick a size, you start it up and it sits there waiting for work to arrive. It builds you whether it's busy or completely idle. And for a lot of small projects, it sits idle almost all the time. Serverless was the answer to that waste, and it's why the idea spread so quickly across the cloud world. One honors point belongs up front because it matters later. Serverless doesn't delete complexity. It moves it. Your team still deals with identity, networking, security, and the bill at the end of the month. What changes is Who patches the operating system at midnight. And that job now belongs to the provider instead of to you. How serverless decides when to run and what it costs. With the idea clear. The next question is mechanical, and it comes down to how serverless knows when to work. Every function needs exactly one trigger, and the trigger is the event that sets it off.

2:49 That might be a timer, a new file, a message in a queue, or an incoming web request. You don't run the function yourself. You describe the condition and the platform watches for it around the clock. Scaling is the part that feels like magic until you see how plain it is. When a burst of requests arrives, the platform adds more copies of your function to handle the load, and when the burst ends, it takes them away again. On the flex consumption plan, Azure functions can scale out to as many as one thousand instances. That's a way of saying it will meet a crowd without you planning for the crowd in advance. That flexibility isn't a setting you switch on. It's a behavior you inherit the moment you deploy. Then comes the cost. And this is where serverless earns its reputation. You pay for executions and for the memory and time each run uses.

3:30 And you pay nothing at all while your code is asleep. Microsoft's older consumption plan includes a monthly free grant of one million executions and four hundred thousand gigabyte seconds. A gigabyte second is a measure of memory multiplied by time. The newer flex consumption plan grants two hundred and fifty thousand executions and one hundred thousand gigabyte seconds each month. A storage account is created by default with each function app, and that storage is billed separately at normal storage rates. So the free grant is a real allowance rather than a blank cheque. Read the fine print before you celebrate a zero on the invoice. Think of it the way you think about electricity. You don't run your own generator all night just in case somebody flips a light switch. The grid already handles that, and you only pay for the power you actually use.

4:11 Serverless applies the same logic to computing, which is why a personal project can cost almost nothing while still being ready to serve real traffic. The mental shift here is bigger than the arithmetic. There's no line on the invoice for a machine that sat unused, because there was never a machine waiting for you in the first place. You're not renting capacity, you're buying completed work. And that's a very different relationship with the bill. That paper moment model is also where serverless quietly bites people. And I will show you exactly how a little later in this episode, where serverless already lives in Microsoft three hundred sixty five. Before you go looking for serverless, look at the tools you already open. Chances are you've built a flow in Power automate that fires when a file lands in SharePoint. If you have, you've been using this style of computing without writing a single line of code.

4:52 Power automate is a Microsoft cloud service for building workflows that automate time consuming tasks across apps and services. It connects to more than one hundred data sources out of the box, including SharePoint and OneDrive. Picture a small example a contract gets uploaded to a document library. A flow notices it, sends it to the right person for approval, and files the result when they respond. Nobody bought a server for that. The work happens in Microsoft's cloud on demand, and it costs nothing. While it waits for the next document to arrive. Three siblings are worth knowing by name, and their differences are simpler than the marketing makes them sound. Power automate is built for business users and citizen developers, the people closest to the problem who don't want to wait on a development team. Logic apps is the Azure service for heavier workflows, and it comes with more than one thousand four hundred pre-built connectors for systems that need serious plumbing.

5:37 As your functions. Is the code first option for when you need custom logic that a drag and drop step can't express. The useful part is that these services aren't competitors. They are building blocks that call each other a power automate flow can call a Logic Apps workflow, and a Logic Apps workflow can call an Azure function. That means you can start low code and add code only where it earns its place. Azure functions even has managed connectors that reach into Microsoft three hundred sixty five teams and SharePoint. The platform quietly handles the webhooks, the authentication, and the retries on your behalf. The code first path is friendlier than it sounds as well, because Azure Functions supports languages people already know, including C, sharp, JavaScript, PowerShell, and Python. You're not forced to learn something exotic just to try it.

6:17 Power automate also sits inside a wider family that includes PowerApps, Dataverse, dynamics three hundred sixty five and office three hundred sixty five. That's why so much of your daily work already touches this model. Without announcing it, there's a low risk way to test that for yourself. Power automate has a free offering and a ninety day trial, so you can explore the idea without a purchase order or a conversation with finance. So the next time someone tells you serverless is only for hardcore developers, you can point at their own approval flow and smile. The job serverless is genuinely good at. You can spot a serverless job from across the room once you know the shape of it. The best fits are short, triggered, and occasional with clear inputs and clear outputs. If a task only needs to exist when something happens, it's a candidate. If it needs to run for hours without stopping, it's probably not.

6:59 Here are the jobs people hand over. Most often a file arrives and needs processing, so a function picks it up the moment it lands and turns a photo into a thumbnail or a messy spreadsheet into a clean record. Other jobs fit just as neatly. A nightly cleanup needs to run at two in the morning, so a timer handles it while everyone sleeps. A chatbot or voice assistant needs to answer on demand, so a function does the thinking only when a question arrives. A small web tool needs a back end that stays out of the way until somebody clicks, and serverless is happy to wait. Microsoft's own list of Azure Functions scenarios reads like a greatest hits of small automation processing file uploads, transforming data in real time as it streams in running scheduled tasks, exposing a scalable web interface, and reacting to changes in a database.

7:41 Each of those jobs shares one trait, which is that the work is brief and tied to an event rather than to a clock. Now bring it back to your own week. Picture a scheduled flow that tidies up a shared folder or a webhook that reacts to a message in teams. A weekly summary could even assemble itself and land in your inbox before you have to ask. None of that needs a machine sitting awake and billing you, and every one of those chores is exactly the kind of work serverless was designed to catch. The fit test is worth repeating in plain words because it will save you time later. Ask whether the job can finish quickly and ask whether it only needs to run when something happens. Two yes answers point you towards serverless. Any no answer points you toward a different tool. That's the bright side, and it's genuinely bright. But every list of wins invites an obvious question, and the answer is where most beginner guides go quiet.

8:25 The limits that surprise people keep the promise from earlier. Serverless isn't magic, and it isn't automatically cheaper. There are a few limits worth knowing before you commit to anything, and the first one you will feel rather than read about. It's called a cold start. To save money, the platform can scale your code all the way down to zero when nobody is calling it. That's wonderful for the bill, and then the next request has to rebuild the environment before it can run. The first person to knock after a quiet spell waits a little longer. Recently used functions feel fast and long. Idle functions feel slow, and that difference is the cold start. The second limit is statelessness. Each run starts fresh with no memory of the one before it. A function can stash a value and expect it to still be there next time. It has to fetch what it needs at the start and save what it produces before it ends.

9:06 That's a design rule rather than a bug, and it shapes how you build everything around it. The third is lock in and it deserves a straight answer. What you build leans on one provider's services, and moving it to a different cloud later is genuinely hard. The languages, the triggers, and the surrounding tools all differ from one platform to the next. You can soften this by writing in a widely supported language and leaning on ordinary services, but the trade off never fully disappears. The fourth is visibility. You can't log into the machine and poke around because there's no machine that belongs to you. You work through logs and metrics instead. Since one user action can set off several functions in a chain, tracing a problem back to its source takes more effort than on a single server. There's a cost risk worth naming as well. A public endpoint or a runaway loop can quietly run up a bill, and security researchers have a name for this, calling it a denial of wallet attack.

9:53 And there's a hard ceiling. People trip over an HTTP triggered function has two hundred and 30s to respond before the platform gives up on it, and the older consumption plan caps a single run at ten minutes. Anything longer than that belongs on a plan built for long work. Not on the plan built for quick bursts. None of these limits are permanent walls. You can keep a function warm to soften cold starts. Choose a plan with always ready instances right in a language. Most clouds except to ease, lock in and add logging from the first day. The point isn't to fear the trade offs, it's to see them coming. The mistakes beginners make with serverless. Most of the pain with serverless comes from a handful of habits, and each one is easy to avoid once you see it clearly, the first mistake is assuming it's always cheaper for steady, always on work.

10:34 A reserved machine you pay for by the month can cost less than paying per execution. Serverless is priced for bursts and quiet spells, not for a constant load. A service that runs all day every day is a poor fit for a model that charges by the run. Another is chopping everything into tiny functions. When the pieces get too small, the overhead and the wiring start to outweigh the benefit. Chains of functions calling one another add delay and make problems harder to see. The industry has names for these patterns, but the plain version is enough. Do not split a job so finely that you can no longer follow it. A third trap is treating serverless as fire and forget without monitoring and alerts. Failures happen quietly in the background, and you find out only when a user tells you something broke.

11:15 Silent failures are the expensive kind because nobody notices until the work has already piled up. A few alerts on errors and run counts will spare you a bad week. Then there's the security side of the deal, which plenty of people forget. Cloud providers work on a shared model where the provider secures the cloud and you're responsible for security inside it. That means your keys, your access, and your data are still yours to protect, no matter who runs the hardware. And plenty of people pick the wrong plan for the job. The legacy consumption plan is on its way out, and Microsoft recommends the flex consumption plan for new serverless apps. Long running work needs a plan with no time outs. Ceiling not the one built for quick, occasional runs. A quiet sixth mistake is ignoring the bill itself. Set a budget alert because the same paper use model that saves you money can surprise you if traffic spikes or a loop gets stuck.

11:59 None of that is a reason to avoid serverless. It's a reason to match the job to the model. Keep an eye on the bill and watch what your code is actually doing. How to start with serverless without overthinking it. Here's the smallest first step. And it doesn't require a credit card. Open power, automate and build one flow for one recurring chore, something like moving new files into the right folder or posting a reminder on a schedule. Watch it run for a week. That single flow teaches you the feel of event driven work without a line of code. If you want to go further, Azure Functions comes with a free monthly allowance that makes experimenting almost free, and flex consumption is a gentle place to start. You don't need to design a whole system. You need one small function that does one clear thing before you write anything.

12:40 Ask those two questions again, because they'll spare you a rebuild. The first is whether the job sits idle until something kicks it off. The second is whether it can finish quickly. If the answer to both is yes, serverless is a strong fit and you can move ahead with confidence. If either answer is no, reach for a different tool and save yourself the trouble. One more habit will make the first attempt smoother. Start with a job you already do by hand so you know exactly what a good result looks like when the flow runs on its own. You can tell in seconds whether it did the right thing. You also don't need to move everything at once. Pick the smallest task that annoys you every week. Automate that one thing and let the wind point you toward the next. The people who get comfortable with serverless usually start with exactly one boring chore to close the loop.

13:20 Serverless means renting moments of work instead of machines, so the bill follows the work rather than the clock. You already use this way of working through Power Automate, and the same idea runs underneath Azure Functions and Logic apps. It shines for short triggered jobs and struggles with steady, long running ones. And knowing that line is most of what you need. So here's my question for you. Which recurring task in your week would you hand over first if you knew it would simply happen on its own? If this made the topic feel less intimidating, subscribe to M365 FM to master the tools and the mindset shaping the future of work.