Welcome back to BackSpace Academy. In this lecture we're going to look at all 2
things serverless on AWS. We'll start off by having a look at what actually serverless 3
means and then we'll go into the different offerings that are available on 4
AWS for creating serverless applications. We'll look at the compute service 5
offerings that are available, storage such as s3, database services such as 6
DynamoDB and API services that allow us to create an API back-end that is 7
completely serverless. We'll look at application integration and 8
orchestration services that can allow us to tie in all of these different serverless 9
offerings together and finally we'll look at the analytic services that are 10
available that are completely serverless as well. So what is serverless? 11
Well it's anything that allows you to build and run applications and services 12
without having to think about servers. So what that means is that you may have a 13
file server that's running on ec2, you need to worry about load balancing the 14
requests that are coming in, you need to look at auto scaling for changes in 15
demand, you need to look about redundancy and failover and all these sorts of 16
things, whereas if you used Amazon s3 for uploading and serving of those files 17
then you don't need to worry about what's going on at the back end there 18
with those servers. So your apps they don't require that provisioning, 19
maintaining and administering of those servers for those back-end components 20
such as would be with an ec2 architecture, and under the shared responsibility 21
model it shifts more of that operational responsibility over to AWS. 22
Because you're doing that it can be more expensive. So on a compute only cost basis 23
Lambda will be more expensive than ec2 but the total cost of ownership 24
can be quite significantly lower because with ec2 you're going to have that 25
server sitting there even when it's not being used. So with Lambda it's going to 26
be invoked when you need it and it's going to be destroyed after that when 27
you don't need it and, so that will lower the cost of those wasted resources and 28
it will also reduce your support costs because you're not going to have to 29
worry about having someone to monitor this server, to provision it, to design it, 30
to make sure it's running quite regularly. So it's going to lower those 31
support costs as well. AWS has many serverless offerings available on their 32
serverless platform and they are fully managed services that you can use to 33
build and run your serverless applications. They include compute such as Lambda, 34
storage such as s3, database such as DynamoDB, application programming interfaces 35
application integration and also orchestration of application components 36
serverless analytics and developer tools to implement these 37
serverless applications. Microservices are small independent services and they will 38
make up a much larger application and those small independent services within that 39
larger application will communicate between each other using well-defined 40
application programming interfaces. Microservices architectures can be 41
facilitated using serverless technologies and serverless technologies do work very 42
well in this sort of architecture but that said you can also facilitate a 43
Microservices architecture using containers that are running on an ec2 44
server but serverless technologies are a great way of doing it. The benefits of a 45
microservices architecture is that it's going to provide increased agility 46
we're going to be able to get to the market quicker. It's going to provide 47
good ownership by your developers of these microservices and it's going to 48
enable reusable code and that is quite important because in a continuous 49
integration and continuous deployment environment you're going to be deploying 50
only what needs to be updated, only those individual microservices, so it's going to 51
really speed up any deployment of any updates. You will achieve right-sized scaling 52
because your application is broken up into individual microservices 53
each one of those microservices can scale independently. So when there's 54
demand on one individual part of your application, that part of your application 55
will get those resources that it needs it will also be very resilient 56
to single point failures. So although one individual microservice 57
may not work, the rest of your application will work. So unlike where 58
you had your application on a single server that can go down as a single 59
point of failure, microservices can increase the resilience of that architecture. 60
The AWS service application model or SAM for short is a 61
framework for defining your serverless applications that you are going to be 62
deploying using Cloudformation. Now you don't necessarily need to use the SAM to 63
deploy a serverless service on Cloudformation but it does provide a good 64
structure around how you do that. The SAM templates they are YAML templates 65
the same as Cloudformation and they look very similar to a Cloudformation 66
template because they are an extension of Cloudformation. So what they do is that 67
they define your serverless application at a very high level and 68
then Cloudformation will reconstruct that and put that into 69
a Cloudformation template that will define it at a more lower level for you 70
there is the SAM command-line interface or CLI you can use that to invoke your lambda functions 71
you can also use it to create a deployment package and the 72
command to use is SAM package, and you can also deploy those applications that are 73
created using that package using Sam deploy. When you talk to people about AWS 74
serverless they'll automatically think about AWS Lambda, but of course there's 75
more to serverless than just lambda but that seems to be a very popular service. 76
It automatically runs code in response to triggers and you only pay for the 77
compute time that is used, when you don't use lambda you're not paying for it 78
when it's invoked you're paying for it. The code it runs in parallel so you can 79
have multiple functions running at the same time and it processes each trigger 80
individually and that's great because it allows you to scale up and scale down 81
because it's all running in parallel and when it's not being used they are terminated 82
those individual functions are terminated 83
This is short-lived raw compute power, because of that, they cannot do everything that an 84
ec2 instance can do. For example if you wanted to create a web server you're not 85
going to be able to do that with lambda. If you want to have a WebSocket 86
connection which is a persistent connection you're not going to be able 87
to do that because lambda is just going to respond to individual requests and 88
then it's just going to terminate itself, so you need to take that into consideration 89
lambda cannot do everything that EC2 can. Also you 90
must take care not to introduce unnecessary complication into your 91
architecture by using lambda in situations where you 92
don't necessarily need to. So here we have an application which consists of an 93
Amazon s3 bucket and when a photograph is uploaded to the s3 bucket that will 94
trigger an s3 trigger for lambda to be invoked and then from there we can use 95
lambda to run some code to apply some filters to that image to resize an image 96
or do something to their image and then we can save that back to Amazon s3 and 97
that can be used for different mobile or tablet or whatever.So that's a great 98
application but you need to consider what if that photograph was taken by a 99
mobile phone or was taken by a tablet? Wouldn't it be better to do that 100
processing before it is uploaded by the mobile device or that tablet and by 101
doing that you're not going to use AWS Lambda you don't need to use AWS Lambda 102
and you're going to save the cost of doing that. So always take these 103
things into consideration, if your client has compute resources either using a 104
mobile phone or they're using a desktop computer or whatever, why not use their 105
computer sources rather than yours you're going to have to pay for? 106
The other advantage of that is it's going to be a lot quicker and simpler for the end-user 107
they're going to get much better latency on these requests 108
so here we have another application which has a web application running on s3 109
and being served by Amazon s3 service and that front end code is going to be 110
running in the browser on a mobile device or a desktop or a tablet or 111
whatever it is and that's running a weather information application and so 112
when the user clicks to get their local weather information their application 113
that's running on that desktop computer or whatever it is running on that device 114
we'll connect to the API gateway service and that can trigger our lambda function 115
to be invoked to process that information and then to access the 116
dynamodb table to get the correct information that's needed, send that back 117
to API gateway and back to that browser application. Now one thing to consider 118
here is that you don't need to have lambda for API gateway to access 119
DynamoDB. That can access that directly you don't need lambda there. So unless 120
there's something specific that you can't do with the API gateway then you 121
don't really need to use lambda because you can set up your API gateway service 122
the schema on that to access dynamodb directly depending on what that request 123
is asking for. So there's a classic example of where land that may not be 124
needed and you can say the cost of doing that the other thing that you may want 125
to consider is actually doing that if there is processing that's required 126
maybe do that on the browser side do that on the device that the application 127
do that and then send that request to api gateway which will then access 128
DynamoDB another thing to consider again is that you're creating a custom api gateway 129
here to access DynamoDB but you need to remember that DynamoDB has its 130
own APIand it can do a lot and there's not a lot that you can't do for 131
accessing dynamodb that you need an api gateway to do that. So there's no reason 132
why you couldn't actually get rid of the api gateway service as well, use your 133
browser application to access dynamodb directly and have the appropriate 134
securities for that to be established. 135
Lambda@edge it's a function of Amazon CloudFront and allows you to run 136
a Lambda function in response to triggers that are generated by Cloudfront 137
A number of use cases for that is that you could add security headers to HTTP 138
responses before they go back to the client, you can use it for bot mitigation, 139
for search engine optimization, for sending back requests that are SEO 140
optimized for processing requests, for data from dynamo DB and also for 141
real-time image transformation, but of course remember Lambda@edge 142
it's not a free service so make sure that you do your costing before you implement it 143
So here's a good application of how you might want to use lambda@edge 144
here we've got a website so when a user visits our website we want to know 145
whether it's actually a real user or whether it's a bot. So Cloudfront can 146
trigger a lambda@edge function when that request is made, and that lambda@edge 147
function can run code that can check whether or not that traffic is 148
from a bot or whether it's from a real user and block that bot or allow that 149
real user to have access. So here we have another application of where a user that 150
is visiting your website may want to have the images on that website 151
delivered and resized to smaller or larger sizes depending on whether 152
they're using a desktop or whether using a tablet or mobile or whatever 153
Sp if they're using a mobile they want to have small images sent to them rather than 154
big images, and so the way that works is that we are going to upload our original 155
high definition images into an s3 bucket and when someone accesses that Amazon 156
CloudFront will invoke a lambda@edge function they can resize their image and 157
then present their back to that user, now at the same time all of those responses 158
will be cached using the lambda@edge cache so we're not going to be paying every 159
time someone accesses that that image it will be stored in a case and so that's 160
going to save you a lot of costs. AWS Fargate that is a serverless environment 161
that allows you to deploy Docker container applications and those 162
individual tasks running on that Docker application run in their own individual 163
environment and that provides a high secure isolation when you're comparing it to 164
multiple containers running on a single ec2 instance. A big advantage of Fargate is 165
that it allocates the right amount of compute resources for each one of those 166
individual containers. So what that means is that one of those parts of your 167
application is under heavy demand it will give those compute resources to 168
that part of your application and you're only paying for the resources that are 169
required to run that container but unlike lambda which runs in parallel 170
so when you get multiple requests for a Lambda function you will get multiple 171
functions operating at once and when those individual requests are finished 172
then that Lambda function will terminate itself. AWS Fargate is different in that 173
you're deploying your application, you're defining what your application 174
needs and it will be deployed in a serverless environment but when you're not 175
using that you're still going to be paying for it so when it is deployed and 176
it's not receiving requests that is still going to be a cost for you 177
so here we can see the advantage of using Fargate and the disadvantage of not 178
using Fargate. So we're going to build our container image, we're going to have 179
to deploy and define our ec2 instance, we're going to have to provision that 180
we're going to have to manage it and then and 181
administrate all of those ec2 resources, we're going to have to provide isolation 182
of our applications in separate virtual machines and then we're going to have to 183
run and manage both the application and that infrastructure and then finally 184
we're going to pay for those ec2 instances and it might be a lot of them 185
or it might not be enough of them depending on how we've set that up 186
Now with Fargate it's a lot simpler and a lot easier. We simply build our container 187
image we define what we need as far as memory and compute resources and then we 188
can simply run our application on AWS Fargate and then we simply pay for what 189
we requested of those compute resources and our application will be isolated 190
simply by design because each one of those components will be operating on 191
its own isolated environment. We already know quite a bit about Amazon simple 192
storage service. We've deployed a serverless application using Amazon s3 and that was 193
a serverless static website, and we've hosted it completely on Amazon s3 194
but we also know that we've got storage and archiving using Glacier but we can also 195
integrate it with Lambda and use the s3 service to trigger a Lambda function 196
so if we upload an image to a bucket we can trigger a Lambda function that can 197
process that image put some filters on it resize it or whatever. We already know 198
quite a bit about the EFS service, we know that it's a fully managed network 199
file server and it enables parallel shared access to those files by multiple 200
ec2 instances it's scales on demand to petabytes and it does that without 201
interruption and it can grow and shrink automatically as you add or remove files 202
the data is stored in a region it's a shared across multiple 203
availability zones so it has redundancy within a region but if you want more 204
than that if a whole region goes down then you're going to have to have a 205
multiple system set up in another region. You cannot mount EFS to a Lambda function 206
it just won't work the reason it won't work is because lambda is not EC2 207
Lambda is short-lived functions, they're created and they're 208
destroyed depending on a request. So if a request comes in a Lambda function 209
will be created to respond to that request and then that Lambda function 210
will then be terminated afterwards. So that is no good for EFS, you cannot mount 211
an EFS to a lambda function. DynamoDB we already know it's a fully managed NoSQL database 212
it can be accessed directly and securely from an application 213
for example we may have a browser application that we're deploying 214
using Amazon s3 and we've got that running on a mobile device, so we can set 215
that up using the AWS software development kit the JavaScript SDK and 216
we can implement security for access to that DynamoDB database using the AWS 217
Cognito identity service. It can also be integrated with Amazon's 218
API gateway service and also we can secure that access to that API gateway 219
using Cognito again. Ok so here's an application that 220
is being deployed using Amazon s3, it's running on a web browser on a device 221
be it a mobile device or desktop laptop whatever and it's using Amazon Cognito 222
for authentication. So to authenticate who that person is and 223
whether they have access to that dynamodb database, if they do then the 224
Amazon API gateway service which we set up as a custom service will receive 225
those API calls from our web browser application you can then trigger a 226
Lambda function which can then access Amazon DynamoDB. Now as we saw before 227
We need to think about whether we need to use AWS Lambda there to do that or 228
whether we can run their actual code on the web browser and whether we can 229
modify our API gateway to access their Amazon DynamoDB 230
without using lambda. So we need to take that into consideration that is an extra 231
cost and again we may also be able to not even require Amazon API gateway 232
because DynamoDB has its own API for accessing data and we can secure that 233
access using Cognito, so it's quite possible that you don't need AWS lambda 234
there or Amazon API gateway, so you need to take that into consideration when you're 235
using DynamoDB. You don't necessarily need to use API gateway and create your 236
own custom gateway to access DynamoDB you can access it directly if you want 237
to save costs. Amazon Aurora service it's a fully managed MySQL database service 238
so unlike standard Amazon Aurora where you're deploying a cluster of 239
service this is completely service and it's doing on-demand and auto scaling 240
and when you're not using it it can hibernate when not in use but be careful 241
when it goes into hibernation it needs to come out of hibernation which is not 242
an instantaneous process, so it's not like lambda where things just 243
instantaneously happen and instantaneously shut down when something 244
goes into hibernation, it takes a while to come back out of that, so it's a 245
simple cost effective option for infrequent intermittent or unpredictable 246
workloads so it's very good for developers that want to quickly deploy 247
something and then when they're not using it for 248
it to basically shut itself down so you're paying on a per second basis for 249
the database capacity that you use but you're still going to pay for the 250
storage when it's not in you so when it goes it goes into hibernation although 251
you're not paying for that database capacity you are still going to be 252
paying for the storage that is there ready to go for it when it comes out of 253
hibernation so that is something to consider so it's not necessarily free 254
when you're not using it. Amazon API gateway it's a fully managed service to 255
create publish maintain monitor and secure application programming 256
interfaces at any scale. So if you've got an application that has a massive amount 257
of requests API gateway can handle that for you 258
now application programming interfaces or api's for short 259
they provide the front door to your applications to access data or process 260
requests for AWS resources. A very good feature of API gateway is that it has a 261
cache for result caching, so if someone comes back with the same request it will 262
cache that and return that back and save you significant amount of costs over 263
going back to your database and getting those results again. Another great 264
feature is that it's WebSockets capable, so if you've got a browser-based 265
application that relies upon real time data and having that application user 266
interface updated in real time you can have a WebSocket connection to API 267
gateway they can deliver that real time data for you 268
okay so here's an application of how we might use it, so we've got some devices 269
there some Internet of Things devices or a web and mobile application or whatever 270
it may be and we require a connection to our 271
back-end data or our back-end services so we can receive those requests from 272
your application to the Amazon API gateway service and we can create and 273
design an API and then we can publish that using the API gateway service it 274
will receive those requests and it will then forward those requests through to 275
one of our services could be DynamoDB, could be Kinesis, could be Lambda, could 276
be one of many different things and that will be forwarded back to your device 277
If that request comes in again for the same data and then that can be cached using 278
the API gateway cache and we can also monitor the performance of that API 279
gateway using Amazon Cloudwatch as well. There are a number of services available 280
on AWS for integrating our serverless applications and also for orchestrating 281
different components of our application. So SNS or simple notification service 282
for short, we can use that for sending notification messages between 283
applications, or to Amazon CloudWatch or to even an end user via email or whatever 284
simple queue service we can use that for queuing of requests to our 285
serverless applications. AWS step functions we can use that to coordinate multiple 286
serverless components of our application and making sure that each one of those 287
processes works in a sequential function from one to the other 288
AWS Appsync allows us to create a GraphQL back end for our browser applications 289
Amazon Eventbridge which is a serverless event bus service and we'll talk a 290
little bit more about that in the upcoming slide. 291
AWS Appsync is a fully managed GraphQL server. If you don't know what GraphQL is, 292
make sure that you go out and Google it and have a look at it because 293
it is really taking the world by storm and it's a great way of defining your 294
data and provides a glue between your application and those back-end services 295
being a REST API being a datasource whatever it may be. So you can use that 296
to connect to DynamoDB, Aurora, Elasticsearch, a Lambda function or a 297
HTTP endpoint. If you need to, it provides real-time data subscription and 298
synchronization so you can have real live and reactive data applications 299
The Apollo client is an application that has been created by the Meteor development 300
group and what it does it provides that front end for your graphQL connection 301
and so database appsync it provides plug-ins for that Apollo client to allow 302
you to create really good reactive front ends with live updating data and also 303
that have offline support so when that connection drops out you still have a 304
case of that regularly used data in that Apollo client. Here we have an 305
application that is running AWS Appsync. So it could be running on a web application 306
it could be a mobile application a real-time dashboard it 307
could be an Internet of Things device whatever it may be. So we have our 308
application running on one of those devices and we want to access a data 309
source it could be dynamodb or Aurora or whatever it may be and so we can define 310
a graphQL schema about how that data is structured and then we can design 311
resolvers that define how we go from that graph QL schema 312
to our back-end data service and how we achieve that once it's all done I Debus 313
appsync can talk to that client application look at that graphQL schema 314
look at that resolver and get that data in the format that it's required if 315
we've got the Apollo client running on those applications if that connection is 316
broken then that data will still be available or a subset of that data will 317
be available still on that device. Amazon Eventbridge it's a serverless event bus 318
service what that means is that you can create applications they can connect to 319
a software as a service or a service such as Sugar CRM, Symantec, Zendesk 320
whatever, or it could connect to an AWS service and it connects by reacting to events 321
how we do that is that we define our data in a schema and we store that 322
in a schema registry and then we can write some code that is written to react 323
to an individual event and by defining rules we can integrate using that code 324
those events with our targets and those targets could be a Lambda function could 325
be an sqs queue, an SNS, could be step functions, or it could be a Kinesis stream 326
here we have an application on the left is our event sources so that could be 327
coming from AWS application it could be from a custom application about it could 328
be from wherever and we want to react to events that occur on that source and we 329
want to be able to do something to a target and so we can see on the right 330
there we've got our targets could be lander could be a Kinesis data firehose 331
it could be SNS or whatever it may be and so event bridge will respond to an 332
event from that event source and then it will look at its scheme 333
from the schema registry and it will look at the rules around how it reacts 334
to that event and it will do something to those targets and finally we can have 335
analytic services run completely without servers Kinesis we can use a Kinesis 336
stream which is a fully managed data capture streaming and analysis service 337
we can also use amazon athena if we've got data stored in an amazon s3 service 338
and that will provide a fully managed interact your query service for that s3 339
bucket so the way it works is we define that bucket and the schemer around the 340
data that is stored in that bucket we can query that data using standard SQL 341
commands and our results will be delivered within seconds we pay per 342
terabyte scanned so each time we scan we have to pay again based on the amount of 343
terabytes that we scan. So that brings us to the end of a very broad overview of 344
the AWS serverless platform. I hope you enjoyed it and I look forward to seeing 345
you in the next lecture