JSJ 417: Serverless with Microsoft Azure with Burke Holland

JavaScript Jabber - Ein Podcast von Charles M Wood - Dienstags

Podimo 30! Tage kostenlos testen

Ein Universum voller exklusiver Podcasts und Hörbücher. Klicken Sie hier um loszulegen!

Kategorien:

Burke Holland works for Microsoft on the Azure team in developer relations. He starts the show talking about how he got started in serverless. He’s careful to note that just because things are marketed as serverless doesn’t always make them so. In order for something to be serverless, it must be sufficiently abstracted in terms of technology, only require payment for what is used, and infinitely scalable. He talks about the statelessness of serverless, and the panel discusses what it means to be stateless. Burke reminds listeners that serverless is not for long-lived operations, but there are features in serverless providers that can help you get around this. Burke talks about how writing serverless code differs from standard or previous coding approaches and practices. He advises that serverless functions are best kept small, and talks about how to fit them in with other kinds of APIs.

The panelists talk about the multi-cloud and why people would want to be on multiple cloud servers. Burke talks about what Microsoft has done with Serverless Frameworks to accomplish multi-cloud compatibility. The JavaScript experts discuss the advantages and disadvantages of picking JavaScript over other languages, and Burke talks about why he prefers TypeScript and the Easy-Off feature. They talk about speed on a serverless platform, especially concerning the cold start time, which Azure is relentlessly trying to lower. He does talk about some things that can be done to decrease load time and about premium functions. The panel discusses how to debug serverless functions and tools that are available, such as the Azure Functions extension.

They talk about ways to set up more secure functions to keep things from racking up charges. Burke talks about some things Microsoft does internally to control cloud costs, such as sending monthly reports with reminders to delete and using tools like Azure Reaper to delete short-lived projects. Azure can also put spending caps on subscriptions, but when you hit that cap you can’t serve any more requests. Burke concludes by saying that most of the time, going serverless is a lower-cost way to improve productivity, and because it’s event-driven, it allows you to tie into things that you’re already doing in the cloud. Serverless almost always justifies itself from an ease of use point of view and a cost point of view.