Welcome back to BackSpace Academy 2
In this lecture we'll talk specifically 3
about serverless architectures we'll start 4
off by talking about the core components 5
we should already know what they are 6
we'll talk about the AWS serverless 7
application model or SAM for short 8
then we'll talk it's about some 9
application architectures first off 10
looking at rest api's and how we can 11
implement those a mobile backend how we 12
can create a web application that is 13
completely serverless and finally we'll 14
finish up by talking about how it can 15
access VPC resources from our serverless environments 16
in the compute services 17
first off there we've got AWS lambda 18
that allows us to run stateless serverless 19
applications by stateless what we mean 20
is that these are very short-lived 21
server environments and once they've 22
finished after a millisecond or a second 23
or whatever it is they disappear they're 24
terminated along with any temporary data 25
that was associated with them 26
next we've got Amazon API gateway that allows us to 27
run a fully managed rest application 28
programming interface that integrates 29
with the lambda so we could have our web 30
application and it could be calling our 31
API back-end that could then integrate 32
with lambda and tell lambda to go and 33
retrieve something for us for example 34
some data from a database 35
finally there we've got AWS step 36
functions now they are similar to AWS 37
simple workflow services but it's a new 38
service and AWS recommends that you use 39
step functions over SWF when you're 40
making a decision on new applications so 41
what it does is that you can define your 42
business process and any conditions 43
within that business process and we 44
could have applications that pass 45
information from one application to 46
another application and a doe newest 47
step functions will allow you to 48
orchestrate that entire process workflow 49
now there is another serverless compute 50
service from AWS and that is lambda at 51
edge and that allows you to run code at 52
a cloudfront edge location and to have 53
your code modify and interact with that 54
cloud front distribution so here is an 55
example from the cloudfront 56
documentation and what we've got there 57
is we've got an Amazon s3 origin that 58
will contain images that are quite large 59
and what we'd like to do is we'd like to 60
resize those images modify them in some 61
way we might want to put a watermark on 62
those we might want to put metadata 63
inside of those images for combating 64
piracy for example and then we want to 65
deliver that to be stored in that cloud 66
front distribution at our edge locations 67
so what we can do is that we can set up 68
a lambda@edge function inside our 69
cloud front distribution and what that 70
will allow us to do is that when cloud 71
front fetches an image and either image 72
hasn't been processed for cloud front 73
previously it will invoke an AWS lambda 74
function to process an image and then 75
that image will then be forwarded on to 76
that CloudFront distribution and that 77
way our end user gets to see exactly 78
what they want and at the same time 79
we're not processing all of these images 80
only the ones that we need on-demand in 81
data and edge delivery of content we've 82
got Amazon DynamoDB as we know it's a 83
fully managed serverless NoSQL database 84
and we also have the DynamoDB 85
accelerator or Dax and what that does it 86
is a case that we can put in front of 87
dynamodb and what that allows us to do 88
is to cache our frequently access to 89
requests from that dynamodb back-end 90
which will of course reduce our load on 91
dynamodb and our subsequent costs Amazon 92
s3 as we know that is great for 93
website hosting and for storing of 94
objects cloudfront content delivery 95
network for caching again frequently 96
access content to reduce a load on 97
Amazon s3 and again our costs 98
finally there we have Amazon Elastic 99
search which is a fully managed search 100
engine that also has analytics tools 101
available as well messaging and 102
straining first off simple notification 103
service we have a pub/sub messaging 104
service what that does it allows us to 105
create a topic and subscribers can 106
subscribe to that topic and we can 107
publish to that topic and our 108
subscribers will receive that 109
publication it also allows us to do 110
mobile push notifications to Android iOS 111
and other devices next up we've got 112
Amazon Kinesis for streaming it collects 113
and processes real-time data streams we 114
have analytics for Amazon 115
Kinesis as well and that allows us to do 116
real-time analytics and we do that using 117
our standard SQL statements and finally 118
they've got Amazon Kinesis fire hose 119
that allows us to direct that stream to 120
more permanent data storage so it 121
transforms and loads at streaming data 122
into Kinesis analytics to Amazon s3 or 123
redshift or elasticsearch 124
user management and identity 125
we've got Amazon Cognito 126
it allows us to have user sign 127
up and signing capabilities for our 128
applications we can manage those users 129
with user pools and we can also have our 130
data for those users stored and synced 131
in a sink store it can also incorporate 132
federated identities for example you 133
might have an OAuth process, a third party 134
OAuth process such as login with 135
Facebook or login with Amazon 136
you could have a SAML process as well 137
or Microsoft Active Directory that could 138
also integrate in with Amazon Cognito 139
for deployment of our serverless 140
environment we can use the 141
serverless application model or Sam 142
for short and that allows us to define our applications in a cloudformation 143
template we'll talk more about 144
that in the next slide 145
for monitoring we've got cloud watch of course for 146
metrics and logs and we've also got AWS 147
x-ray that allows us to carefully 148
analyze the performance of our 149
applications by creating tracing and 150
service maps of its performance so how 151
it works is that on your application you 152
will have the AWS x-ray software 153
development kit and that will allow you 154
to send information at different stages 155
of your application back to an AWS x-ray 156
daemon which will be running on a 157
computer environment so that could be an 158
ec2 instance if it's running in your 159
application is running on Elastic 160
Beanstalk you can have elastic Beanstalk 161
create that x-ray daemon for you 162
automatically or you could have it 163
running as a container on the same 164
instance as your application but that 165
daemon will collect that information 166
that is being sent to it from your 167
application and it will send that off to 168
the AWS x-ray service and from there you 169
can view a service map and that will 170
break down all of the time frames for 171
different parts of your application to 172
work so if your application is slow you 173
can have a look and see what is causing 174
the problem you can see what can be done 175
concurrently rather than sequentially 176
and it allows you to really thoroughly 177
analyze the performance issues of your 178
application now the serverless application 179
model isn't actually a service of AWS as 180
such it's a model for defining your 181
serverless applications and it defines the 182
syntax that you need to conform to so 183
that they can be interpreted by the 184
cloud formation service and then 185
deployed so within your cloud formation 186
template you will have a transform 187
section and that is where you will put 188
your Sam model that describes your 189
serverless environment in and that will 190
define those serverless resources and what 191
you want 192
do with those serverless resources so here 193
we've got a very simple cloud formation 194
template and as you can see there it's 195
got the transform section which defines 196
AWS serverless application model and in 197
our resources there we've got an AWS 198
serverless function a lambda function and 199
we have the properties for that there is 200
the index handler 201
the runtime known js8 and the URI for 202
the code being an s3 bucket there that 203
has our a code package there in a zip 204
file in this cloud formation template 205
we're defining a dynamo DB table so 206
again we've got our transform section 207
defining the serverless application model 208
and then we've got our resources here 209
which is a type it's a serverless and type 210
simple table which is a simple dynamodb 211
table and there we have the primary key 212
and the provision throughput details of 213
that DynamoDB table a very common use 214
case for AWS serverless environments is to 215
create a RESTful API or application 216
programming interface for your mobile or 217
web applications so the good thing about 218
using a serverless environment such as 219
Amazon API gateway is that it integrates 220
with Amazon Cognito and so that will 221
allow you to have Amazon kognito sign-in 222
and sign-out capability have user ports 223
for storing that user information you 224
can have a sink store for personal 225
information about that user and you can 226
also control access to what that user 227
can get through that Amazon API gateway 228
the Amazon API gateway would communicate 229
with AWS lambda and add abuse lambda 230
will require an iam role to allow it to 231
access information in an Amazon DynamoDB 232
table and also AWS lambda will require a 233
role to be able to send information and 234
logs back to Amazon Cloud Watch for 235
metrics and logging of its performance 236
if we wanted to improve the performer 237
of this architecture even further we 238
could have an Amazon API gateway cache 239
in front of that Gateway service that 240
would cache our frequently accessed 241
requests we could also have a case or a 242
dynamo DB accelerator or Dax for short 243
in front of our dynamodb database as 244
well or our dynamodb table as well and 245
that will reduce a load on our back-end 246
DynamoDB service AWS has a very good 247
offering for mobile backends first and 248
foremost we would secure our application 249
and all of the access to our AWS 250
resources in our account using AWS 251
kognito and so that could allow for 252
sign-in and sign-out capability it can 253
manage our users using kognito user 254
pools and we could also store profile 255
information about our users in a kognito 256
user pool our application might require 257
our users to upload files to Amazon s3 258
or upload images or whatever so we can 259
use Amazon s3 for receiving that and we 260
can deliver those back using Amazon 261
CloudFront 262
for our frequently access content we 263
could have a search engine capability 264
built into our application and we could 265
use elastic search and use lambda for 266
that communication between elastic 267
search and our web application we could 268
also have an API back-end that could be 269
delivering dynamic content from a 270
database so for that of course we could 271
use API gateway we could have a gateway 272
cache in front of that to reduce a load 273
on our API gateway service we could have 274
a lambda function that will be accessing 275
the data from dynamodb we could also 276
have a Dax dynamodb accelerator that 277
will cache our frequently accessed 278
requests from dynamodb and finally we 279
can use the SNS service to provide 280
mobile push notifications directly to 281
the device that our user is using and we 282
could use a lander function to 283
orchestrate that as well Amazon s3 as we 284
already know is great for hosting web 285
applications we also know that we can 286
put a cloud front distribution in front 287
of that s3 bucket and that will reduce 288
the latency for our end users and reduce 289
our overall costs we can use an Amazon 290
Cognito usable for sign-in and sign-out 291
capability and management of our users 292
we can use an Amazon Cognito 293
data sync store to save profile 294
information about our users and we can 295
also use that to secure our Amazon API 296
gateway that we could use for delivering 297
data back to our web application and as 298
before we can quite easily put a gateway 299
cache in front of Amazon API gateway and 300
we can put a Dax dynamodb accelerator in 301
front of DynamoDB to again increase that 302
performance reduce that latency and to 303
reduce our costs overall now up until 304
now we've been creating architectures 305
that are completely serverless but what 306
happens if we have a serverless environment 307
that needs to communicate with something 308
that is inside of the private subnet of a VPC 309
for example you may have an RDS 310
instance and you that is located in a 311
public subnet your lambda function will 312
be able to access that and connect to 313
its endpoint because it's in a public 314
subnet and it will go through the 315
internet gateway as you would from your 316
desktop at home not a problem 317
but if it's located in a private subnet 318
by default it will be private that is 319
your private space within the cloud and 320
the AWS Lander function won't be able to 321
access it so here we have an 322
architecture that is a combination of a 323
serverless environment and a server 324
environment so for example if we have 325
got there our Amazon redshift 326
elastication and RDS instances if 327
they're located 328
side of that private subnet by default 329
our AWS lambda function won't be able to 330
access it it would be able to connect to 331
the for example the RDS instance and the 332
end point of the RDS instance if that 333
instance was located in a public subnet 334
cuz it would just go through to the 335
internet gateway as you would do on your 336
desktop at home not a problem but if 337
that RDS instance is inside of a private 338
subnet you're not going to be able to do 339
that so what you need to do is you need 340
to define after you have launched your 341
outlet your lambda function you need to 342
define the private subnet and the 343
security groups of those resources that 344
you need to access that are inside of 345
that private subnet and once you've done 346
that the AWS lambda service will 347
orchestrate the creation of an elastic 348
network interface to that private subnet 349
the other advantage of that is that you 350
can also use that to access your Amazon 351
s3 service because you can access that 352
through your private subnet and then on 353
through to that Amazon s3 or that VPC 354
endpoint now one thing to remember is 355
that this is purely and simply for 356
connecting to these instances so you're 357
going to be connecting to the Amazon RDS 358
instance through its endpoint if you 359
wanted to actually use your software 360
development kit on the AWS Lander 361
function for example if you wanted to 362
launch RDS instances then your lambda 363
function would also need to have a role 364
to be able to do that with the RDS 365
service so to enable this to happen it's 366
really quite easy after you have you 367
launched your lambda function just 368
scroll down to the network section and 369
there you can fill in the details so 370
what we've got there is that we've got 371
our V PC that we define we define the 372
subnets that are going to have these 373
resources inside of them and then we 374
also define these security groups that 375
are associated to those instances inside 376
of that private subnet 377
and what will happen is that the Lambda 378
service will automatically orchestrate 379
all that for you and create an elastic 380
network interface to that private subnet 381
all those private subnets that you have 382
defined and it will allow you to 383
communicate through to any instances 384
inside that private subnet that are 385
associated to that security group that 386
you've defined here as well so that 387
brings us to the end of this lecture and 388
I hope you've enjoyed it and I look 389
forward to seeing you in the next one