Okay.
Hello bloggers.
And welcome to this lecture.
This is the application summary lecture so congratulations you've done really really well.
You've got just one more section left and then you'll be able to go ahead and book your exams and hopefully
pass on the first attempt.
The next section of the Course is super fun as well because we're going to do a whole bunch of service
stuff so let's have a look at what we learned and we're going to start with Eskew s so Eskew as is the
way to decouple your infrastructure.
So we use the example of a main web site or a travel Web site.
Essentially basically you store your messages in escudos and you see two instances will go get those
messages and go ahead and do something if those easy two instances for whatever reason stop working
or terminated the message will then reappear in the Q and another easy to instance will go in and get
it and then that way if anything fails it doesn't break your entire application stack.
Remember that escudos is pool based.
It's not pushed based if you want push based messaging you're going to use S.A. messages a 256 kilobytes
in size.
You can actually have them bigger but it won't be stored in Eskew.
So it'll be stored in S3 and messages can be kept in the queue from one minute to 14 days.
And the default retention period is four days and then just remember the two different types of escudos.
So we've got standard escudos and we've got 50 escudos and you have to understand the different use
cases for them.
So standard order is not guaranteed and messages can be delivered more than once with fee fo order is
strictly maintained and messages are delivered only once or really remember that going into your exam.
Remember the difference between standard and fee fo.
Also remember the visibility Time out.
This is the amount of time that the messages as invisible in the rescue as queue after a reader picks
up that message provided the job is process before the visibility timeout expires.
The message will then be deleted from the queue.
If the job is not processed within that time the message will become visible again.
And another reader will process it.
This could result in the same message being delivered twice.
So if you are getting the same message being delivered twice and this is the root cause you may want
to increase your visibility time out just to give your easy two instances that little bit of extra time
to process the message.
And just remember that the visibility time out maximum is 12 hours.
Also remember that SRK Eskew US guarantees your messages will be processed at least once and then long
polling is a way to retrieve messages from your rescuers rescues while regular short polling returns
immediately.
Even if the message queue being polled is empty long polling doesn't return a response until a message
arrives in the message queue or the long pole times out.
And this is a way of saving money with rescuers moving onto S.W. F..
I appreciate we just sort of you know glazed over it a little bit.
Really you just need to understand S.W. f versus excuse because you're going to get scenario based questions
and you really want to pick the right one.
So escudos has a retention period of 14 days with S W F simple workflow service workflow executions
can last up to one year and S.W. f presents a task orientated API whereas Eskew s offers a message orientated
API so if you go to scenario based questions talking about a task based structure and maybe it's got
human workers for example then you want simple workflow.
If you're talking about a message based system then you're going to go after Eskew S S W F ensures that
a task is assigned only once and is never duplicated with Eskew.
You need to handle duplicated messages if you're using the standard one.
If you're not using FIFO and you may also need to ensure that a message is processed only once and then
S.W. f keeps track of all tasks and event in an application with s.
You need to implement your own application level tracking especially if your application has multiple
cues.
Then we learned a little bit about S.W. F so simple workflow services actors.
So we have workflow starters.
These are applications that initiate will start a workflow could be your e-commerce website following
the placement of an order or a mobile app searching for bus times.
Then have our deciders.
These basically control activity tasks in the workflow execution.
And if something is finished or failed in a workflow a decider then decides what to do next.
And then we have our activity workers and these are basically people or programs or applications that
carry out activity tasks.
Do you see anything about a human working in a warehouse and you need a way of managing it.
Then think of simple workflow service.
As I mentioned a W.S. use.
Sorry Amazon.com use simple workflow to help run their warehouses.
Moving on to S.A..
Just remember what it is and the different benefits that it gives you so it's instance pushed based
deliveries.
So there's no polling like with rescuers.
If you want poll based you're going to go for escudos.
If you want pushed base you can go for S.A. gives you a simple API is an easy integration with applications.
You get flexible message delivery over multiple transport protocols.
It's inexpensive.
Pay as you go model with no upfront costs is a web based NWS management console offers the simplicity
of the point and click interface.
And then just like I said Remember SARS versus rescuers that both messaging services in AWOL but S.A.
is push escudos is poor or polls of your easy two instances poll.
The excuse Q Moving onto elastic trans is really simple just remember that it's a media trans coda in
the cloud it converts your media files from their original source format into different formats that
will play on smartphones tablets pieces etc. Then API gateway.
I appreciate that this was quite high level.
We are going to get our hands dirty with API gateway in the next section of the course API Gateway is
definitely worth 5 or 10 marks so just remember what it is at a high level it's basically a gateway
in to your Adobe US resources your Adobe US infrastructure.
It has a casing or caching capabilities to increase performance.
It's low cost and scales automatically.
That being said you can throttle API gateway to prevent attacks and you can log your results to cloud
what's using API Gateway and then a few using Java's gripped or Ajax that uses multiple domains with
API Gateway.
You have to ensure that you have enable cores on your API gateways across origin resource sharing.
And remember that cause is always enforced by the client's browser.
Moving on to.
Just remember the difference between canister streams and canisters firehose canister streams has data
persistence.
It's going to store your data by default for 24 hours but can go up to a longer period of time so you
get your data persistence and then you have your easy two instances going in and getting the data from
the streams cornices firehose is where you need to analyze your data in real time and then find a place
to store it because there is no persistence you could have lambda functions running in firehose that
then store that data into S3 or they could put into elastic search clusters etc etc..
So if you see anything mentioning about shards or about data persistence you want streams if you want
real time analytics and then a place to put it instantly with no data.
Data persistence then you're going to be using firehose and you're going to be given scenario based
questions where you must choose the most relevant service and then you have consensus analytics which
basically helps you analyze your data in both firehose as well as Kansas streams and then finally we
looked at cognitive so cognitive allows us to do web identity Federation Federation essentially allows
users to authenticate with web identity providers such as Google Facebook and Amazon and essentially
the way it works is the user authenticates first with the Web I.D. provider and receives an authentication
token which is then exchanged for temporary AWOL credentials allowing them to assume an I am role Incognito
is an identity broker which handles the interaction between your applications and the web I.D. providers.
You don't need to go ahead and write your own code for this and then the main thing to remember for
cognitive is the difference between our user pools so our user pools are user based and they handle
things like user registration authentication and account recovery etc. Whereas identity pools authorize
access to our AWOL resources.
So that is it for this section of the course.
You've done really really well in the next section we're going to go in and learn all about lambda and
service architectures and then we going to start building some service websites.
So if you've got the time please join me in the next lecture.
Thank you.