The “Building Cloud-Ready Applications” blog mentions Cloud Service Models i.e. Private Cloud / Data Center, IaaS, PaaS, and SaaS. The focus was on building PaaS applications.
In Summary, the Cloud Service Models are,
- IaaS (Infrastructure as a Services) – Virtual Machines (total control). Managing of VM’s is our responsibility.
- PaaS (Platform as a Services) – Deploy Apps on Virtual Machines (underneath and less control). Managing of VM’s is the responsibility of the vendor.
- SaaS (Software as a Service) – Subscription for the services like O365 or Gmail for email etc. Managing of Apps, Data and VM’s responsibility of the vendor.
Taking a step further will briefly explain Serverless Compute with the following diagram
With every shift, there has been a move of “unit of scale”, and “abstracted” away from a set of responsibilities from the customer to the vendor.
- With data centers, the “hardware” was the unit of scale and the “physical hosting environment” was abstracted away.
- With IAAS the “operating system” was the unit of scale, and the “physical hardware” was abstracted away.
- With PAAS the “application” was the unit of scale, and the OS was abstracted away.
- With Serverless technologies the “function” is the unit of scale and the “language runtime” is abstracted away.
“Serverless Computing” doesn’t really mean there’s no server. Serverless means there’s no server to worry about. Similar to PaaS, but it’s a higher level than that.
With PaaS the servers are known for e.g. on deploying your Website / Application the size of hosting environment can be configured, you might scale it up i.e. more CPU/Memory/Disk or out i.e. 1, 2, n instances.
With Serverless technologies like Azure Functions you can just upload the code and it will start executing seconds later. It can be a continuous jobs, functions that run on a triggered event or make Web APIs or Webhooks that are just a function with a URL.
|Event Driven||Limited Transparency as underlying infrastructure is abstract|
|Rapid Development||Immature Tooling (less debugging and Troubleshooting support)|
|Minimal Maintenance||Require Security Review|
|Very Scalable||Better Documentation|
|Pay Per Use||Vendor Lock-in (Dependency on Cloud Provider)|
Azure Functions provide event-based serverless computing that makes it easy to develop and scale application based on demand, paying only for the resources that code consumes during execution.
- Trigger – specify what conditions cause the function to be called
- Binder – specify how to get information into and out of method parameters
Details on Triggers and Binders are mentioned here.
Some Tips for Building Azure Functions
- Apply Single Responsibility Principle while creating an Azure Functions. Break business logic to functions. Focus only on application and not the underlying infrastructure. Azure Functions are written in extension “.csx” file.
- The function.json contains the binding’s details such as cron settings for schedule etc.
- Minimize dependency on reference libraries.
For e.g. Instead of Entity Framework use ADO.Net to perform CRUD operations.
- Framework Assemblies are the reference as #r “AssemblyName“. For e.g.
- For Custom Assemblies first the “bin” is to be created and the DLL’s are to be uploaded in the “bin” folder for the Azure Function
- Custom Assemblies are a reference as #r “AssemblyName.dll“. For e.g.
Remember that updating the custom assemblies will require the hosting server to be stopped.
- Packages i.e. project.JSON file specifies the NuGet packages. Framework Assemblies are automatically downloaded based on the project.JSON file once this file is uploaded to the functions folder.
- Azure Function Apps have built in logging capabilities as well as built-in statistics support.
- Don’t use verbose logging in production code. It has a negative performance impact.
Following are some URLs to start developing the Azure Functions –
Try Azure Functions – Visual Studio Tools for Azure Functions
Sample Azure Function – Use Azure Functions to perform a scheduled clean-up task