Platform as a Service lecture 2

Size: px

Start display at page:

Download "Platform as a Service lecture 2"

Cuthbert Greene
6 years ago
Views:

1 Politecnico di Milano Platform as a Service lecture 2 Building an example application in Google App Engine Cloud patterns Elisabetta Di Nitto

2 Developing an application for Google App Engine (GAE)! Install Eclipse and GAE SDK! Create GAE project! The tool automatically creates a simple example

3 GuestbookServlet package guestbook; import java.io.ioexception; import javax.servlet.http.*; public class GuestbookServlet extends HttpServlet { public void doget(httpservletrequest req, HttpServletResponse resp) } } throws IOException { resp.setcontenttype("text/plain"); resp.getwriter().println("hello, world");

Web.xml <?xml version="1.0" encoding="utf-8"?> <!DOCTYPE web-app PUBLIC "-//Oracle Corporation//DTD Web Application 2.3//EN" "http://java.sun.com/dtd/web-app_2_3.dtd"> <web-app xmlns="http://java.sun.com/xml/ns/javaee" version="2.

4 Web.xml <?xml version="1.0" encoding="utf-8"?> <!DOCTYPE web-app PUBLIC "-//Oracle Corporation//DTD Web Application 2.3//EN" " <web-app xmlns=" version="2.5"> <servlet> <servlet-name>guestbook</servlet-name> <servlet-class>guestbook.guestbookservlet</servlet-class> </servlet> <servlet-mapping> <servlet-name>guestbook</servlet-name> <url-pattern>/guestbook</url-pattern> </servlet-mapping> <welcome-file-list> <welcome-file>index.html</welcome-file> </welcome-file-list> </web-app>

5 appengine-web.xml <?xml version="1.0" encoding="utf-8"?> <appengine-web-app xmlns=" appengine.google.com/ns/1.0"> <application></application> <version>1</version> </appengine-web-app>

6 Running the project! Can be run locally in the debugging environment! Can be uploaded on Google App Engine! You need to register

7 package guestbook; Modifying GuestbookServlet to use google user accounts import java.io.ioexception; import javax.servlet.http.*; import com.google.appengine.api.users.user; import com.google.appengine.api.users.userservice; import com.google.appengine.api.users.userservicefactory; public class GuestbookServlet extends HttpServlet { public void doget(httpservletrequest req, HttpServletResponse resp) throws IOException { UserService userservice = UserServiceFactory.getUserService(); User user = userservice.getcurrentuser(); } } if (user!= null) { resp.setcontenttype("text/plain"); resp.getwriter().println("hello, " + user.getnickname()); } else { resp.sendredirect(userservice.createloginurl(req.getrequesturi())); }

Entity creation Using the datastore Entity greeting = new Entity("Greeting", guestbookkey); greeting.setproperty("user", user); greeting.setproperty("date", date); greeting.

8 Entity creation Using the datastore Entity greeting = new Entity("Greeting", guestbookkey); greeting.setproperty("user", user); greeting.setproperty("date", date); greeting.setproperty("content", content); Datastore service instantiation DatastoreService datastore = DatastoreServiceFactory.getDatastoreService(); datastore.put(greeting); Retrieving entities from datastore Query query = new Query("Greeting, guestbookkey).addsort("date,query. SortDirection.DESCENDING); List<Entity> greetings = datastore.prepare(query).aslist(fetchoptions.builder.withlimit(5));

9 Task queues in GAE! Task are queued and their execution if performed based on their order in the queue! Note: queue does not contains data but references to code + parameters! Push semantics (default): Code (task) is pushed out of the queue and executed! Processing rate for tasks in a queue can be defined! App Engine scales computing resources according to the number of tasks in your queue! Pull semantics: allows an alternate task consumer to process tasks at a specific time! Task consumer can be either in or outside App Engine! Application needs to care about scaling of workers based on processing volume, as well as delete tasks after processing.

10 Task queue definition! queue.xml <queue-entries> <total-storage-limit>50m</total-storage-limit> <queue> <name>greetingprocessingqueue</name> <rate>1/s</rate> <max-concurrent-requests>1</max-concurrent-requests> <bucket-size>10 </bucket-size> <retry-parameters> <task-retry-limit>7</task-retry-limit> <min-backoff-seconds>10</min-backoff-seconds> <max-backoff-seconds>200</max-backoff-seconds> <max-doublings>2</max-doublings> </retry-parameters> </queue> </queue-entries>

11 Putting a task in a queue (1) Queue queue = QueueFactory.getQueue("GreetingProcessingQueue"); TaskOptions taskoptions = TaskOptions.Builder.withUrl("/processGreeting").param("userName", user.getnickname()).param("content,content).method(method.post); queue.add(taskoptions); NB: /processgreeting has to correspond to a servlet

12 Putting a task in a queue (2) In web.xml <servlet> </servlet> <servlet-name>processgreeting</servlet-name> <servlet-class>guestbook.processgreetingservlet</servlet-class> <servlet-mapping> <servlet-name>processgreeting</servlet-name> <url-pattern>/processgreeting</url-pattern> </servlet-mapping> Servlet processgreeting is activated asynchronously after the corresponding task is put in the queue

createKey("Guestbook", guestbookname); String content = req.

13 processgreetingservlet code (dopost) UserService userservice = UserServiceFactory.getUserService(); User user = userservice.getcurrentuser(); String guestbookname = req.getparameter("guestbookname"); Key guestbookkey = KeyFactory.createKey("Guestbook", guestbookname); String content = req.getparameter("content"); Date date = new Date(); Entity greeting = new Entity("Greeting", guestbookkey); greeting.setproperty("user", user); greeting.setproperty("date", date); greeting.setproperty("content", content);

14 processgreetingservlet code (dopost) - cont DatastoreService datastore = DatastoreServiceFactory.getDatastoreService(); datastore.put(greeting); // Create Task and push it into Task Queue Queue queue = QueueFactory.getQueue("GreetingProcessingQueue"); TaskOptions taskoptions = TaskOptions.Builder.withUrl("/processGreeting").param("userName", user.getnickname()).param("content", content).method(method.post); queue.add(taskoptions); resp.sendredirect("/guestbook.jsp?guestbookname=" + guestbookname);

15 Cloud architectural patterns! Provide suggestions on how to design, build, and manage applications that use these cloud services.! Are independent of the actual technologies and cloud services that they are using.

16 Classification of patterns! Basic Architectural Patterns! Composite Application! Loose Coupling! Stateless Component! Idempotent Component! Elasticity Patterns! Map Reduce! Elastic Component! Elastic Load Balancer! Elastic Queue! Availability Patterns! Watchdog! Update Transition! Multi-Tenancy Patterns! Single Instance Component! Single Configurable Instance Component! Multiple Instance Component

17 Composite application! Context! An application shall be composed out of multiple independent components.! Challenge! Divide at impera always useful! In a cloud environment each application service should be able to scale independently from the others! Solution! Divide the application functionality into multiple independent components that are integrated by the same means as if they were completely individual applications.

18 Composite application! The application is extendable right from the beginning! The integration of other applications is simplified.! Critical design decision: the distribution of functionality among components.! Too few components: reduced flexibility! Too many components: communication overhead

19 ! Context Loose Coupling! A componentized application or a set of applications that shall be integrated.! Challenge! Dependencies among components should be reduced. The addition, removal, failure, or update of one component should have minimal or no impact on other components.! This is especially true when low availability compute nodes are used! Solution! Decouple components by reducing the assumptions one component makes about another one when they exchange information.

20 Loose Coupling! Price: performance reduction.! Overhead to the information exchanged.! Longer communication path.! Asynchronous communication! Intermediary handles communication format transformation and message routing.! NB: in elastic clouds this can be overcome easily

21 Stateless components! Context! A componentized application subsumes components that can fail.! Challenges! Cloud resources can display low availability.! Component instances can be added and removed regularly when the demand changes.! Solution! Implement the components in a way that they do not contain any internal state, but completely rely on external persistent storage.

22 Stateless components! No data is lost if an instance fails! Multiple components have a common internal state! The scalability of the central data store becomes the major challenge! Distributed data stores

23 ! Context Idempotent component! Communication partners exchange messages via a Message Oriented Middleware (MOM)! Challenges! MOM could not guarantee the exactly-once delivery semantics! Even if it guarantees this through a reliable mechanism, we could have some legacy component unable to work with this guarantee! Solution! Implement the receiver so that it can receive a message multiple times safely,! through a filter that removes duplicates or! by adjustment of message semantics

Idempotent component! Filter-based solution! Messages are associated with a unique identifier that is stored upon receiving a message! duplicates are detected based on the identifier!

24 Idempotent component! Filter-based solution! Messages are associated with a unique identifier that is stored upon receiving a message! duplicates are detected based on the identifier! Adjustment of message semantics! Message are modified so that they produce the same effect even when they are received multiple times! E.g., in a bank transfer app, message carries the new balance, not the quantity of which it should be modified! Out of order messages should be handled properly

25 Map reduce! Context! A cloud based application using data storage that does not support complex queries, such as NoSQL storage.! Challenge! In many cloud computing storage querying capabilities are limited. This leads to larger data sets being returned to the applications that need to be handled efficiently! To support scalability, handling of complex queries has to be distributed among multiple compute nodes.! Solution! Map the data set into smaller sets and distribute it among multiple compute nodes, each executing the complex query on the assigned data set.! Then reduce the solutions into one common data set that matches the complex query.

Map reduce! See lecture on Cloud storage! Often to query large amounts of weakly structured data for analysis purposes.! E.g., analysis of web service logs to determine user access statistics or!

26 Map reduce! See lecture on Cloud storage! Often to query large amounts of weakly structured data for analysis purposes.! E.g., analysis of web service logs to determine user access statistics or! analysis of order information to find popular products.

27 Elastic component! Context! A componentized application uses multiple compute nodes provided by an elastic infrastructure.! Challenges! To benefit from the elastic infrastructure, the management process to scale-out a componentized application has to be automated.! Manual resource scaling would not support pay-per-use nor quickly changing workload! Solution! Monitor the utilization of compute nodes that host application components and automatically adjust their numbers using the provisioning functionality provided by the elastic infrastructure.

28 Elastic component! If the utilization of compute nodes exceeds a specified threshold, additional hosting components are provisioned that contain the same application component.! If the components are implemented as stateless components, the operations for adding and removal of components are significantly simplified.

29 Elastic load balancer! Context! A componentized application uses multiple compute nodes provided by an elastic infrastructure.! Challenges! As for elastic component! Service requests are a good indicator of workload and therefore shall be used as a basis for scaling decisions! Solution! Use an elastic load balancer that determines the amount of required resources based on numbers of requests and provisions the needed resources accordingly using the elastic infrastructure s API

30 Elastic load balancer! The number of requests that can be handled by a computing node is a crucial design parameter! It has to be adjusted at run time! Information about the time needed to provision new compute nodes can also be necessary to deduct effective scaling actions

31 Elastic queue! Context! A componentized application uses multiple compute nodes provided by an elastic infrastructure! Challenges! If the application components handle asynchronous requests additional optimization of the workload execution can be performed by delaying some of them! This is useful if resources costs fluctuate or the elasticity of the environment is reduced (see private or small clouds)! Solution! Use an elastic queue that is used to distribute requests among application components and that scales these components depending on the number and type of messages it contains

Elastic queue! The elastic queue can contain different message types that are handled by different components! It determines the number of computing nodes to be provisioned based on queue content!

32 Elastic queue! The elastic queue can contain different message types that are handled by different components! It determines the number of computing nodes to be provisioned based on queue content! It takes into account environmental information, such as the overall utilization of the elastic infrastructure or resource prices! So it can choose if to provision new resources or if to delay non-critical messages

33 Watchdog! Context! An application is build upon a cloud infrastructure that offers a low availability, but it should assure a higher availability! Challenges! Sometimes, (high) availability is only expressed regarding the possibility to start new compute nodes! Thus, the application architecture needs to be adjusted to enable redundancy and fault-tolerant structures! Solution! Application architecture includes redundant compute nodes performing the same functionality! High available communication between these nodes is assured, for example by a messaging system! Compute nodes are monitored and replaced in case of failure

34 Watchdog! Messaging system and data stores have to be highly available! Each component extracts data from input queue and produces data into the output queue within a transaction! If transaction fails, data appear again in the input queue and can be taken by the next component

35 Update transition! Context! A componentized application that has to be highly available and that uses multiple compute nodes provided by an elastic infrastructure! Challenge! To reduce unavailability of application to the minimum when updates are needed! Solution! Introduce new versions while the old versions are still running! Afterwards, shutdown the old compute nodes

36 Update transition! Images for compute nodes with the new software version are created, tested, then provisioned! Potential problems:! Incompatibilities between versions! Different versions cannot handle requests at the same time

37 Single instance component! Context! A componentized application is provided to multiple customers! Challenge! Sharing application instances can save costs and imply a more efficient use of resources! This can happen is applications are configured equally for all tenants! Solution! Deploy components with equivalent configuration for all tenants only once and share it between tenants

38 Single instance component! Multiple tenants access the same application component pool! Sometimes customer requirements do not allow sharing! shared components have to be provided as multiple instances

39 ! Context Single configurable instance component! A componentized application is provided to multiple customers that may configure it! Challenges! Sharing application instances can save costs and imply a more efficient use of resources! However, customers need to apply individual configurations to shared components! E.g.: shared component is a DBMS. Each tenant has its own DB schema! Solution! Deploy one component that uses individual configurations for each tenant

40 Single configurable instance component! The component adjusts its functionality according to a configuration that is determined by the tenant accessing it! If sharing is not allowed by customer or if configurations differ too much shared components have to be provided as multiple instances

41 Multiple Instance Component! Context! A componentized application is provided to multiple customers that may configure it and deploy individual instances! Challenges! Tenants have similar needs but they cannot share the same components! Solution! Deploy individual component implementations and configurations for each tenant

42 Multiple Instance Component! Tenants can adjust components very freely! However, this pattern hinders resource sharing between tenants! Whenever possible, prefer single instance or single configurable component

References! Google App Engine! Tutorial https://developers.google.com/appengine/docs/java/ gettingstarted/! Code labs http://googcloudlabs.appspot.com/! Cloud computing patterns!

43 References! Google App Engine! Tutorial gettingstarted/! Code labs Cloud computing patterns! Christoph Fehling, Frank Leymann, Jochen Rütschlin and David Schumm, Pattern-Based Development and Management of Cloud Applications, Future Internet, April 2012, pages futureinternet

Cloud Computing Platform as a Service

HES-SO Master of Science in Engineering Cloud Computing Platform as a Service Academic year 2015/16 Platform as a Service Professional operation of an IT infrastructure Traditional deployment Server Storage