serverless computing with aws lambda - ijsrcseit.comijsrcseit.com/paper/cseit11833187.pdf ·...

CSEIT1833187 | Received 05 March 2018 | Accepted 14 March 2018 | March-April-2018 [ (3) 4 132-138 ]

International Journal of Scientific Research in Computer Science Engineering and Information Technology

copy 2018 IJSRCSEIT | Volume 3 | Issue 4 | ISSN 2456-3307

132

Serverless Computing with AWS Lambda G Hari Prasad1 A J Rajasekhar2

1Department of MCA Sree Vidyanikethan Institute of Management Sri Venkateswara University Tirupati

Andhra Pradesh India 2Assistant Professor Department of MCA Sree Vidyanikethan Institute of Management

Tirupati Andhra Pradesh India

ABSTRACT

Serverless models speak to another way to deal with planning applications in the cloud without having to

unequivocally arrangement or oversee servers e designer specifies capacities with well defined passage and

leave focuses and the cloud supplier handles every single other part of execution In this paper we investigate a

novel utilization of serverless designs to data recovery and portray a web crawler worked in this way with

Amazon Web Services postings records are put away in the DynamoDB NoSQL store and the postings traversal

algorithm for query assessment is executed in the Lambda benefit e result is a web crawler that scales flexibly

with a compensation for every demand show as opposed to a server-based model that requires paying for

running cases regardless of whether there are no solicitations We exactly evaluate the execution and financial

matters of our serverless engineering While our execution is as of now too moderate for intuitive seeking

investigation demonstrates that the compensation per-ask for show is financially convincing and future

foundation enhancements will expand the attractiveness of serverless outlines after some time

Keywords Serverless computing Server Cloud Computing

I INTRODUCTION

Servers referring to both software stacks and the

machines they keep running on are fundamental to

the design of data recovery frameworks In the

standard outline a look benefit sits tight for demands

from a customer in view of some outstanding

convention (eg HTTP or a RPC structure) executes

the query and returns the outcome In an

appropriated seek engineering every server may just

be in charge of a little segment of the whole report

accumulation and there might be numerous

imitations of a similar service yet servers remain the

essential building piece e appearance of cloud

computing implies that physical machines are these

days progressively supplanted by on-request

virtualized examples under a compensation as-you-

go display Be that as it may running a web index

still requires overseeing servers in some shape

Regardless of whether there are no solicitations

despite everything one needs to pay for some

essential level of provisioning in reckoning of

approaching queries As the query stack expands one

at that point needs to arrangement more servers and

load adjust crosswise over them In spite of the fact

that there are devices to help with scaling up (and

down) flexibly we will likely investigate elective

designs that rearrange service Another pattern in

cloud computing under the standard of serverless

engineering or serverless processing intends to

separate from the execution of stateless services from

the server machines they keep running on (regardless

of whether physical or virtualized) For instance

Amazons Lambda benefit gives an engineer a chance

to run code without provisioning or overseeing

servers e engineer specifies a piece of code that

Volume 3 Issue 4 | March-April-2018 | http ijsrcseitcom

133

should be executed with all around defined passage

and leave focuses and Amazon handles the real

execution of the codemdashfrom a couple of times each

day to a great many solicitations for every second is

paper investigates uses of serverless models for data

recovery and portrays a pursuit application fabricated

completely utilizing this approach with Amazon

Web Services Our key understanding is that query

separates into two parts postings records that include

the list and postings traversal algorithms that control

the postings to figure query comes about e postings

records speak to the state of the application which

we store in Amazons DynamoDB NoSQL store e

stateless query assessment algorithm is embodied in

Lambda code that gets postings of query terms put

away in DynamoDB to process query comes about e

commitment of this work is the first use of serverless

processing to data recovery that we know about We

demonstrate that it is surely conceivable to fabricate

a completely useful web crawler that does not

require the express provisioning or service of servers

Exploratory outcomes demonstrate that our plan

yields end-to-end query latencies of around three

seconds on a standard web test accumulation of

roughly 25 million records While this dormancy

isnt worthy for intuitive recovery today the

financial matters of the compensation per-ask for

demonstrate is convincing We trust that our outline

is fascinating and as serverless structures pick up

prominence foundation enhancements will build the

attractiveness of our approach after some time

II BACKGROUND

Serverless computing speaks to the intelligent

augmentation of the as an service cloud computing

pattern that started vigorously 10 years prior (despite

the fact that points of reference go back numerous

decades to the appearance of timesharing machines)

Infrastructure as a service (IaaS) gives flexible on-

request registering resources ordinarily as virtual

machinesmdashAmazons EC2 was the first and remains

the most noticeable case of this model despite the

fact that Microsoft Google and numerous others

have comparable offerings These cloud suppliers

additionally oer capacity and other framework

segments (eg arrange virtualization) in a

compensation as-you-go way Platform as a service

(PaaS) raises the level of reflection where the cloud

supplier deals with a total registering stagemdasha run of

the mill illustration is Google App Engine which

underpins facilitated web applications Database as a

service (DBaaS for example Amazons Relational

Database Service (RDS) Microsofts Azure SQL and

Googles Cloud SQL gives oversaw database benefits

that disentangle provisioning regulating and scaling

social databases in the cloud Database and capacity

as a service can be seen as giving engineers the

capacity to ooad the service of state to a cloud

supplier Numerous cutting edge web applications

bring together state in a database or some backend

information store to rearrange plan and to help level

adaptability Therefore most if not all application

rationale winds up stateless as in state isnt protected

over various summons of a specific usefulness us

the application just turns into a bundle of capacities

that entrance a typical information store On the off

chance that the obligation of overseeing state is then

pushed to a facilitated cloud arrangement In such

engineering the designer does not so much care how

these capacities are executedmdashthus serverless

Serverless figuring does not really imply that code

can keep running without serversmdashyet rather that

from the engineers point of view the execution of

independent capacities progresses toward becoming

another persons concern in particular that of the

cloud supplier e designer does not have to stress

over turning up servers (or VM pictures)

accumulating various execution examples to expand

usage stack adjusting over numerous server cases

scaling all over flexibly and so on e appearance of

lightweight compartments with extra namespace

virtualization and tooling exemplified by Docker

makes serverless processing viable To date most

exchanges of serverless registering occur with regards

to overhauling client confronting applications in this


134

worldview Such decay is consonant with the

mircoservices engineering that is in vogue today

For instance Hendrickson et al conjecture about

what it would take to revamp Gmail in a totally

serverless outline and the leaps forward important to

make it a reality In this paper we center on the

backend and investigate what serverless data

recovery may resemble

III SERVERLESS DESIGN

This area depicts the plan of our serverless pursuit

engineering appeared in Figure 1 We clarify how

list structures are mapped to DynamoDB and how

the query assessment algorithm is executed utilizing

Lambda capacities At show we have planned our

framework altogether around Amazon Web Services

and along these lines seller secure is a worry Other

cloud suppliers oer comparable abilities in spite of

the fact that they are not as develop as Amazons

services Cloud interoperability is a critical issue in

its own right however past the extent of our work

In this paper we consider the JASS score-at once

query assessment algorithm on affect requested

records is approach has been appeared to be both

effective and efficient contrasted with state-of the-

craftsmanship record at once approaches

Figure 1 Our serverless search architecture

AWS infrastructure is appeared in blue (Lambda and

DynamoDB) and our custom segments are appeared

in green For each portion its effect score is stacked

and for each docid in the section the effect score is

added to its aggregator In JASS the gatherers are

actualized as a variety of 16-bit whole numbers one

for each record listed by the docid To abstain from

arranging the gatherers once all postings fragments

have been prepared a pile of the best k can be kept

up amid handling at is aer adding the present

effect score to the collector we check if the record

score is more prominent than the littlest score in the

load assuming this is the case the pointer to the

gatherer is added to the store Aer all postings

portions have been handled the best k components

are extricated from the load and returned as results

31 DynamoDB Index Storage DynamoDB is

Amazons completely oversaw NoSQL store that

backings a fundamental keyndash esteem display One of

its key highlights is that the client pays just for

information stockpiling and readcompose

activities is evaluating model is really pay-per-ask

for as opposed to Amazons Relational Database

Service (RDS) which requires installment for server

cases paying little heed to query stack DynamoDB

has three center parts tables things and

characteristics Tables store accumulations of related

information A thing is an individual record inside a

table and a quality is a property of a thing In

DynamoDB things in a similar table can have

properties that are not shared over all things

DynamoDB bolsters two sorts of essential keys One

attribute is chosen as the segment key and is utilized

inside by the service itself for information

arrangement Alternatively a moment trait can be

chosen as the sort key No two things inside a table

can share an essential key yet DynamoDB bolsters

extra records At development time each DynamoDB

table needs a name and a related essential key

characterized Something else the tables are schema

less which implies that neither the traits nor their

sorts must be characterized before information

addition DynamoDB things have a size point of

confinement of 400KB which is a vital restriction we

have to beat (subtle elements underneath) A

credulous mapping from a reversed list to a NoSQL

store is utilize the term as the parcel key and to store


135

the postings for that term as the esteem e issue with

this plan is that notwithstanding for little

accumulations the measure of the postings records

will surpass the 400KB size farthest point of

DynamoDB things Luckily the association of effect

requested lists exhibits a characteristic method for

separating the postingsmdashby their effect scores

Notwithstanding with sufficiently expansive

accumulations a postings fragment (especially for

little effect scores) can in any case surpass as far as

possible To suit this we present the thought of

gatherings a requesting of different keeps running

of docids that offer a similar effect score In

DynamoDB we utilize a half and half sort key

contained the effect score and the gathering number

inside that effect score Review that for JASS score-at

once traversal we should recover postings for a term

and a given effect score Sadly our half and half sort

key outline does not make this simple to do As a

workaround we made an optional list on the

postings table with the term as the hash key and the

effect score as the sort key to help querying

straightforwardly by affect score Since there is no

uniqueness requirement for essential keys in an

auxiliary list this approach works paying little

respect to regardless of whether the postings for an

effect score are part crosswise over DynamoDB

things (ie different gatherings) Notwithstanding

the postings table we made a different metadata

table which stores the quantity of archives in the

gathering (vital for the instatement of query

assessment) and in addition a rundown of effect

esteems that have postings for each term is

configuration enables us to abstain from getting non-

existent effect scores At last we assembled an

ingester program that takes affect requested files

from an outside source and embeds the postings into

DynamoDB as indicated by our plan Our present

usage is fairly guileless and does not oversee

hotspots in the fundamental DynamoDB table that

create while embeddings numerous things with a

similar parcel key and thus does not accomplish high

throughput 32 Lambda Query Evaluation Amazons

Lambda gives engineers a chance to run code

without provisioning or overseeing servers despite

the fact that making a Lambda requires indicating

the measure of memory that is accessible to each

code conjuring (up to a greatest of 15GB) and a

timeout period (not surpassing 300 seconds) Code

summons are charged by the term of the execution

gathered together to the closest 100ms of every a

fine-grained way While there are no determinations

of computational resources gave to execute the

Lambda both the system transfer speed and the

measure of preparing power have been seen to scale

straightly with the memory asked Lambda code

must be composed in an upheld dialect JavaScript

Python Java or C Nonetheless there is no

confinement against conjuring code written in

different dialects It is trifling and to be sure normal

use to package resources for example local pairs and

libraries alongside the capacity code itself Our

Lambda work is actualized in Python which at that

point summons a program written in C++ that plays

out the real query assessment At the point when a

conjuring demand touches base at the API Gateway

(a trigger that summons a Lambda on HTTP

occasions) Amazon is in charge of provisioning the

vital resources to execute the Lambda and dealing

with its lifecycle

Figure 2 Performance of our serverless architecture

The greater part of this occurs without our mediation

Inside the Lambda itself our code first demands data

about the quantity of records and the effect scores for

the query terms from the metadata table After

bringing this data the aggregators and the load are

introduced trailed by the genuine preparing of the

effect fragments of the query terms in dropping

request For each effect score the DynamoDB asks


136

for are issued no concurrently and the outcomes are

prepared when accessible While it is conceivable to

play out all solicitations no concurrently this was

not done since it would not yield a right score at any

given moment traversal arrange Aer handling has

finished the best k comes about are returned (k =

1000 in our examinations) Our usage right now

returns inside numeric docids rather than outer

(string) docids that are gathering particular

IV EXPERIMENTS

To approve our outline we actualized the serverless

recovery engineering portrayed in the past area on

the Gov2 gathering contained around 25 million site

pages For assessment we utilized subjects 701ndash 850

(with stopwords expelled) utilized as a part of the

Terabyte Tracks from TREC 2004 to 2006 For

practicality we just ingested into DynamoDB the

postings arrangements of the query terms

Performance Analysis We report trial brings about

Figure 2 indicating standard box-and-bristles plots

for query inactivity with the mean appeared as a

white precious stone Inertness figures are separated

as takes after Customer is estimated from the query

customer utilizing the Unix order time (mean

3087ms) Lambda is the billable length as estimated

by Amazon (mean 1887ms) Program is the inner

planning by our query assessment algorithm (mean

1722ms) and Handling catches the measure of time

spent performing query assessment outside of sitting

tight for DynamoDB asks for (mean 87ms)

difference between the Program and Lambda

estimations catches the overhead of the Python

Lambda summoning the local C++ pairs for query

assessment e contrast amongst Lambda and

Customer speaks to the extra overhead of

summoning the Lambda itself and recovering the

outcomes In general everything other than the

Handling estimation reflects overheads of the

serverless design in different structures Indeed even

with all the self-evident advancements that we

have actualized end-to-end customer query

inertness is longer than is commonly viewed as

usable for an intuitive query application To beer

contextualize these outcomes a current public-

source reproducibility challenge sorted out by Lin et

al detailed a query idleness of JASS under

comparable exploratory conditions as 51ms (same

accumulation same queries on an EC2

occurrence) is contrasts positively and our

Preparing time and the execution hole can be

likely credited to CPU contrasts in the basic

occurrences Generally speaking our tests recognized

numerous wellsprings of latencies in the present

outline the greatest of which includes bringing

postings from DynamoDB ere is significant

opportunity to get better and we would expect that

as serverless outlines turn out to be more well known

Beyond DynamoDB latencies there are a couple of

evident wasteful aspects for instance the conjuring

overhead of the C++ program can be disposed of if

AWS upheld C++ Lambdas Moreover there is time

squandered in unnecessary information

transformationmdashall Lambda solicitations and

reactions must be in JSON organization and double

properties in DynamoDB are encoded in base64

which is ease back to unravel It would not be

extremely troublesome for Amazon to give the

designer more eurone-grained control over serverless

execution in such matters Past these trials there are

a few extra queries with respect to our setup In

execution assessments it is standard to recognize

icy runs and warm runs where the laer

advantage from reserving impacts Since both

DynamoDB and Lambda are fully managed services

this is troublesome for us to achieve the same

number of parts of execution are not as

straightforward as we might want In any case since

our work is principally plausibility examine we

concede these more point by point investigations to

future work

Cost Analysis A key element of our serverless plan is

the compensation per-ask for display and the

programmed even versatility of Lambda and


137

DynamoDB in light of interest In this segment we

give a cost investigation examination of serverless

and server-based models For a reasonable

correlation we indeed divert to come about because

of the reproducibility investigation of Lin et al

which likewise analyzed JASS on a similar

accumulation and queries On an EC2 r34xlarge

occasion Lin et al detailed a query inactivity of

51ms on a solitary string Since the example has 16

vCPUs on the off chance that we accept direct

scaling we touch base at a throughput of around 313

queries for each second on a completely stacked

server is occasion costs USD$133 every hour paying

little respect to stack which implies that the cost is

the same whether the server executes zero one or

one million queries in any given hour Then again

Lambda is charged on a for each demand premise in

augmentations of 100ms e normal billable time for

our framework was 1887ms for each query which

means USD$0000047951 DynamoDB stockpiling is

charged at USD$025 per GB every month in addition

to extra expenses for read and compose activities In

any case our use levels stay in the DynamoDB

complementary plan for these tests despite the fact

that a heavier query load would not generously aect

our examination

Figure 3 Cost of serverless vs server-based

architectures

n Figure 3 we demonstrate the per-query cost in

pennies for the server based and serverless structures

accepting the arrangements above as a component of

query stack in queries every second (qps) e Lambda

configuration has a steady cost for every query while

the EC2 case turns out to be more practical at higher

burdens with the breakeven point around 77

queries for every second Likewise with Lambda we

accomplish (conceivably boundless) adaptability

without manual intercession While a heap of 77 qps

appears to be low consider that in the diagram of the

TREC 2016 Public Search Track it was uncovered

that CiteSeerX gets about 100000 queries for each

day which converts into 12 qps by and large We

wander that in everything except the most

requesting applications (eg business web indexes) a

serverless plan would force from a cost viewpoint

V CONCLUSION

Trends point to an unavoidable move of figuring to

the cloud and serverless designs reect this

advancement is work speaks to as far as anyone is

concerned the principal outline of a serverless

engineering for data recovery We promptly

surrender that this underlying emphasis suers from

execution issues despite the fact that our cost

examination legitimizes the compensation per-ask

for show for most hunt needs We expect that future

changes in cloud framework alongside extra

improvements in our outline will render serverless

data recovery progressively referring

VI REFERENCES

[1] Jimmy Lin Ma Crane Andrew Trotman Jaime

Callan Ishan ChaopadhyayaJohn Foley Grant

Ingersoll Craig Macdonald and Sebastiano

Vigna 2016 Toward Reproducible Baselines e

Public-Source IR Reproducibility Challenge In

ECIR 408-420

[2] Jimmy Lin and Andrew Trotman 2015

Anytime Ranking for Impact-Ordered Indexes

In ICTIR 301-304

[3] Jimmy Lin and Andrew Trotman 2017 e Role

of Index Compression in Score-at-a-Time ery

Evaluation Information Retrieval 20 3 (2017)

199-220

[4] Dirk Merkel 2014 Docker Lightweight Linux

Containers for Consistent Development and

Deployment Linux Journal 2014 239 (2014)

Article No 2

[5] Krisztian Balog Anne Schuth Peter Dekker

Narges Tavakolpoursaleh Philipp Schaer and


138

Po-Yu Chuang 2016 Overview of the TREC

2016 Public SearchTrack

[6] ceciliaaws 2014 Re Lambda CPU relative to

which instance type (9 Dec 2014) Retrieved

February 2 2017 from

hpsforumsawsamazoncommessage

jspamessageID=588722

[7] Charles Clarke Nick Craswell and Ian Soboro

2004 Overview of the TREC 2004 Terabyte

Track In TREC

[8] Ma Crane J Shane Culpepper Jimmy Lin Joel

Mackenzie and Andrew Trotman 2017 A

Comparison of Document-at-a-Time and

Score-at-a-Time ery Evaluation In WSDM

201-210

[9] Giuseppe DeCandia Deniz Hastorun Madan

Jampani Gunavardhan Kakulapati Avinash

Lakshman Alex Pilchin Swaminathan

Sivasubramanian Peter Vosshall and Werner

Vogels 2007 Dynamo Amazonrsquos Highly

Available Key-value Store In SOSP 205-220

[10] Vineet Gopal 2015 Powering CRISPR With

AWS Lambda (25 Sept 2015) Retrieved


hpbenchlingengineeringcrispr-aws-

lambda

[11] Sco Hendrickson Stephen Sturdevant Tyler

Harter Venkateshwaran Venkataramani

Andrea C Arpaci-Dusseau and Remzi H

Arpaci-Dusseau 2016 Serverless Computation

with PublicLambda In HotCloud

[12] Haslhofer B Sanderson R Simon R

Sompel H Public annotations on multimedia

web resources Multimedia Tools and

Applications pp 1-21 (2012)

[13] Ridge M Pelagios project blog Pelagios

usability testing results (September 2011)

httppelagios-

projectblogspotcoat201109draft-

resultshtml

[14] Simon R Pelagios project blog The pelagios

graph explorer A first look (August 2011)

httppelagios-projectblogspotcoat201108

pelagios-graph-explorer-first-lookhtml

[15] Thompson HS McKelvie D Hyperlink

semantics for standoff markup of readonly

documents In Proceedings of SGML Europe

97 The next decade Pushing the Envelope p

227229 (1997)

About Authors

Mr GHariPrasad is currently

pursuing his Master of Computer

Applications Sree Vidyanikethan

Institute of Management Tirupati

AP He received his Master of

Computer Applications from Sri

Venkateswara University Tirupati

Mr AJRajasekhar is currently

working as an Assistant Professor

in Master of Computer

Applications Department Sree

Vidyanikethan Institute of

Management Tirupati AP


133

should be executed with all around defined passage

and leave focuses and Amazon handles the real

execution of the codemdashfrom a couple of times each

day to a great many solicitations for every second is

paper investigates uses of serverless models for data

recovery and portrays a pursuit application fabricated

completely utilizing this approach with Amazon

Web Services Our key understanding is that query

separates into two parts postings records that include

the list and postings traversal algorithms that control

the postings to figure query comes about e postings

records speak to the state of the application which

we store in Amazons DynamoDB NoSQL store e

stateless query assessment algorithm is embodied in

Lambda code that gets postings of query terms put

away in DynamoDB to process query comes about e

commitment of this work is the first use of serverless

processing to data recovery that we know about We

demonstrate that it is surely conceivable to fabricate

a completely useful web crawler that does not

require the express provisioning or service of servers

Exploratory outcomes demonstrate that our plan

yields end-to-end query latencies of around three

seconds on a standard web test accumulation of

roughly 25 million records While this dormancy

isnt worthy for intuitive recovery today the

financial matters of the compensation per-ask for

demonstrate is convincing We trust that our outline

is fascinating and as serverless structures pick up

prominence foundation enhancements will build the

attractiveness of our approach after some time

II BACKGROUND

Serverless computing speaks to the intelligent

augmentation of the as an service cloud computing

pattern that started vigorously 10 years prior (despite

the fact that points of reference go back numerous

decades to the appearance of timesharing machines)

Infrastructure as a service (IaaS) gives flexible on-

request registering resources ordinarily as virtual

machinesmdashAmazons EC2 was the first and remains

the most noticeable case of this model despite the

fact that Microsoft Google and numerous others

have comparable offerings These cloud suppliers

additionally oer capacity and other framework

segments (eg arrange virtualization) in a

compensation as-you-go way Platform as a service

(PaaS) raises the level of reflection where the cloud

supplier deals with a total registering stagemdasha run of

the mill illustration is Google App Engine which

underpins facilitated web applications Database as a

service (DBaaS for example Amazons Relational

Database Service (RDS) Microsofts Azure SQL and

Googles Cloud SQL gives oversaw database benefits

that disentangle provisioning regulating and scaling

social databases in the cloud Database and capacity

as a service can be seen as giving engineers the

capacity to ooad the service of state to a cloud

supplier Numerous cutting edge web applications

bring together state in a database or some backend

information store to rearrange plan and to help level

adaptability Therefore most if not all application

rationale winds up stateless as in state isnt protected

over various summons of a specific usefulness us

the application just turns into a bundle of capacities

that entrance a typical information store On the off

chance that the obligation of overseeing state is then

pushed to a facilitated cloud arrangement In such

engineering the designer does not so much care how

these capacities are executedmdashthus serverless

Serverless figuring does not really imply that code

can keep running without serversmdashyet rather that

from the engineers point of view the execution of

independent capacities progresses toward becoming

another persons concern in particular that of the

cloud supplier e designer does not have to stress

over turning up servers (or VM pictures)

accumulating various execution examples to expand

usage stack adjusting over numerous server cases

scaling all over flexibly and so on e appearance of

lightweight compartments with extra namespace

virtualization and tooling exemplified by Docker

makes serverless processing viable To date most

exchanges of serverless registering occur with regards

to overhauling client confronting applications in this


134











































































135






































































with its lifecycle











136










IV EXPERIMENTS






































































future work





137


























our examination


architectures


















V CONCLUSION













VI REFERENCES






ECIR 408-420



In ICTIR 301-304




199-220




Article No 2




138










Track In TREC





201-210











lambda












httppelagios-


resultshtml









227229 (1997)

About Authors















134











































































135






































































with its lifecycle











136










IV EXPERIMENTS






































































future work





137


























our examination


architectures


















V CONCLUSION













VI REFERENCES






ECIR 408-420



In ICTIR 301-304




199-220




Article No 2




138










Track In TREC





201-210











lambda












httppelagios-


resultshtml









227229 (1997)

About Authors















135






































































with its lifecycle











136










IV EXPERIMENTS






































































future work





137


























our examination


architectures


















V CONCLUSION













VI REFERENCES






ECIR 408-420



In ICTIR 301-304




199-220




Article No 2




138










Track In TREC





201-210











lambda












httppelagios-


resultshtml









227229 (1997)

About Authors















136










IV EXPERIMENTS






































































future work





137


























our examination


architectures


















V CONCLUSION













VI REFERENCES






ECIR 408-420



In ICTIR 301-304




199-220




Article No 2




138










Track In TREC





201-210











lambda












httppelagios-


resultshtml









227229 (1997)

About Authors















137


























our examination


architectures


















V CONCLUSION













VI REFERENCES






ECIR 408-420



In ICTIR 301-304




199-220




Article No 2




138










Track In TREC





201-210











lambda












httppelagios-


resultshtml









227229 (1997)

About Authors















138










Track In TREC





201-210











lambda












httppelagios-


resultshtml









227229 (1997)

About Authors














serverless computing with aws lambda - ijsrcseit.comijsrcseit.com/paper/cseit11833187.pdf ·...

Documents