L'architettura serverless va sempre più di moda e innovative tecnologie come le Azure Functions ci consentono di implementarla facilmente. Come possiamo calare in questa realtà un prodotto consolidato come SQL Server che all'apparenza sembra non essere tagliato per questi scenari? In questa sessione vedremo come sfruttare SQL Server e l'estensibilità delle Azure Functions per costruire solutioni Serverless. Sessione tenuta il 11/06/2021 a SQL Start 2021.

1. SQL
START!
2021
–
10°
ANNIVERSARY

2. Partners

3. Pay-per-use
Only pay for what you use: billing is typically
calculated on the number of function calls,
code execution time, and memory used.
Instant, event-driven scalability
Application components react to events and triggers in
near real-time with virtually unlimited scalability; compute
resources are used as needed.
Full abstraction of servers
Developers can just focus on their code—there are
no distractions around server management, capacity
planning, or availability.
What is serverless?

4. Azure Functions

5. What are Azure Functions?
Author functions in C#,
F#, Node.JS, Java, and
more
Code
Events
React to timers, HTTP,
or events from your
favorite Azure services,
with more on the way
Outputs
Send results to an
ever-growing
collection of services

6. What can I do with Azure Functions?
Azure Functions is a great solution for processing data,
integrating systems, working with the internet-of-things
(IoT), and building simple APIs.
Triggers
✓ NO SQL Trigger
Bindings
✓ NO SQL Bindings

7. Azure Functions SDK
All Triggers and Bindings (except for HTTPTrigger and
Timer Trigger) are available as external packages
(NuGet).
The Azure Functions SDK is based on the Azure
WebJobs SDK and inherits from it the extension SDK.
An extension is a class that implements the
IExtensionConfigProvider interface.

8. Azure Functions lifecycle phases
Startup
The runtime executes this phase
only when the host starts.
The runtime registers the built-in
binding (TimerTrigger and
HttpTrigger).
You must register your custom
extensions.
Runtime
The runtime executes this phase
every time a function is triggered
by an event.

9. The Startup phase
Registering
extensions
Functions
scaffolding
Function
dependencies
resolving
Function
internal
representation
Listeners
creation and
execution

10. Retrieving function
definition
Binding
conversion
Function
execution
The Runtime phase

11. DEMO
Implementing custom binding
for SQL Server

12. SQL Database
Serverless

13. What is a SQL Database Serverless
Serverless is a
compute tier for
single databases
in Azure SQL
Database
Automatically
scales compute
based on
workload
demand
Bills for the
amount of
compute used
per second.
Automatically
pauses
databases
during inactive
periods and
resumes
databases when
activity returns.

14. Configurations
Define the range of compute capacity
available for the database.
Memory and IO limits are proportional to the
vCore range specified.
Minimum &
Maximum
vCores
Defines the period of time the database must
be inactive before it is automatically paused.
The database is automatically resumed when
the next login or other activity occurs.
Auto-pause
delay

15. Cost
Sum of the compute cost and storage cost.
Usage between the min and max limits, cost is based on vCore or memory
used.
Usage below the min limits configured, cost is based on the min vCores or
min memory configured.
When the database is paused, the compute cost is zero and only storage
costs are incurred.
The storage cost is determined in the same way as in the provisioned
compute tier.

16. Cost example
✓vCore : 1 min – 4 max
✓Memory: 3 GB – 12 GB
✓Auto-Pause : 6 hr
✓Active Workload: first 2 hours
Day Time vCore used GB Used Dimension billed vCore equivalent
0:00 – 1:00 4 9 vCores 4 vCores * 3600 secs = 14400 vCore secs
1:00 – 2:00 1 12 Memory 12 GB / 3 * 3600 secs = 14400 vCore secs
2:00 – 8:00 0 0 Memory (min) 3 GB / 3 * 21600 secs = 21600 vCore secs
8:00 – 24:00 0 0 Paused 0 vCore secs
50400 vCore secs
9 GB of memory is equivalent to
3 vCores. vCores used are
greater then the vCore
equivalent for memory.
12 GB of memory is equivalent
to 4 vCores. vCores used are
less then the vCore equivalent
for memory.
SQL Database Serverless → $0.000145 * 50400 = $7.31
SQL Database Provisioned (4 core/20 GB) → $1.03/hour = $24.72
SQL Database Provisioned (2 core/10 GB) → $0.52/hour = $12.48

17. Scenarios well suited for serverless
Single databases with
intermittent,
unpredictable usage
patterns with periods
of inactivity and lower
average compute
utilization over time.
Single databases that
are frequently
rescaled and
customers who prefer
to delegate compute
rescaling to the
service.
New single databases
without usage history
where compute sizing
is difficult or not
possible to estimate.

18. Compute tier comparison
Serverless compute Provisioned compute
Database usage pattern
Intermittent, unpredictable usage
with lower average compute
utilization over time.
More regular usage patterns with
higher average compute utilization over
time, or multiple databases using
elastic pools.
Performance management
effort
Lower Higher
Compute scaling Automatic Manual
Compute responsiveness Lower after inactive periods Immediate
Billing granularity Per second Per hour

19. DEMO
Configuring SQL Database
Serverless

20. Azure Functions to
SQL Database Serverless

21. Managing transient errors
Today's cloud-based, microservice-based or internet-of-
things applications often depend on communicating with
other systems across an unreliable network.
Such systems can be unavailable or unreachable due to
transient faults such as network problems and timeouts, or
subsystems being offline, under load or otherwise non-
responsive.
When a SQL Database serverless is in pause, you receive
an error during the first call! You must consider it a
transient error!

22. Retry pattern
Retry after delay.
If the fault is caused by one of
the transient failures, the service
might need a short period while
the issues are corrected.
The application should wait for
a suitable time before retrying
the request.

23. Retry pattern with Polly
Retry Policy
definition
Retry Policy
utilization

24. DEMO
Using retry pattern in the SQL
Binding

25. Takeaway
Serverless is the best approach when you don’t know
the solution load and want to scale.
Azure Functions allow you to focus on business issues,
not infrastructural details.
SQL Database serverless allows you to evaluate and
scale your database if you don't know the workload.
Always handle transient errors.

26. Thanks for your
attention!!!!!
Massimo Bonanni
Azure Technical Trainer
massimo.bonanni@microsoft.com
@massimobonanni
Connect with me on LinkedIn
linkedin.com/in/massimobonanni/
http://bit.ly/MasteringServerless

27. References
Photo by Ekrulila from Pexels
➢ Azure Functions triggers and bindings concepts
https://docs.microsoft.com/en-us/azure/azure-functions/functions-triggers-bindings
➢ Event-driven scaling in Azure Functions
https://docs.microsoft.com/en-us/azure/azure-functions/event-driven-scaling
➢ Azure SQL Database serverless
https://docs.microsoft.com/en-us/azure/azure-sql/database/serverless-tier-overview
➢ Troubleshoot transient connection errors in SQL Database and SQL Managed Instance
https://docs.microsoft.com/en-us/azure/azure-sql/database/troubleshoot-common-connectivity-issues
➢ Error handling for resilient applications in Azure
https://docs.microsoft.com/en-us/azure/architecture/framework/resiliency/app-design-error-handling
➢ Retry pattern
https://docs.microsoft.com/en-us/azure/architecture/patterns/retry
➢ GitHub – Polly
https://github.com/App-vNext/Polly
➢ GitHub – SQLServerless triggers and bindings
https://github.com/massimobonanni/SQLServerless