PaaS Model as a part of Google Cloud, that is Google App Engine Google App Engine is for developing and hosting web applications, launched on April 2008. The applications are designed to serve a multitude of users simultaneously, without incurring a decline in overall performance. To ensure highly scalable, dynamically allocating resources based on the number of requests in a given time, it is designed in a different way.
The power of Google App Engine is higher than other PaaS providers and development and hosting of web applications are highly scalable. The service does not include initial investments or long-term subscriptions, but implements the principle of pay-per-use is only required for better infrastructure and resources from the PaaS Model, such as CPU, storage and bandwidth input / output. Specifically, there is a fixed limit of usage up to which, the resources are free to use, which can be extended to meet individual needs through a Billable Quota.
PaaS Model and Architecture of Google App Engine : The Architecture
Applications developed with AppEngine are designed to meet the demands from the users via the web. Specifically, an user uses the application by performing an HTTP request, usually through a browser. A load balancer directs the request to a particular server frontend, which identifies the resource of interest by ID, domain and any subdomain specified in the URL,. For each application a free sub-domain like appspot.com is assigned.
---
The resource of interest is analyzed to determine the following operations. If the URL identifies a static file, such as an image, the request is served directly. Static files that do not involve in the application code are therefore processed by Google App Engine using specially dedicated server, optimized for the management of this type of resource. The URL can identify a request handler, which is a piece of code relating to an application. In this case the request is forwarded to the application server, where it is decided on a particular physical or virtual server if has to be instantiated in the application according to the estimated time management. In particular, an instance of the application is invoked using the HTTP request and is expected to be completed by returning the data as a result to the result to the client or user. However, there is the possibility that an instance suitable for handling the current request is already active, in which case the request is queued. The server is also responsible for managing the resources for the application (CPU, memory) and check that the consumption does not exceed the specifications. If the URL does not identify any known resource the client receives a HTTP 404 error.
PaaS Model and Architecture of Google App Engine : Going in to more details
The frontend server can be configured to handle authentication and authorization of clients. In particular, they can be implemented for restrictions on URLs in the category of user on role base or the domain. Programs that reside in the application server takes the advantage of both several essential components, such as the Datastore and Memcache for the functionality of Storage, which uses the auxiliary services such as URL Fetch Service or Mail Service. The different types of servers described are governed by a total of an entity that can be denoted as “master”. Its main function is the updating of applications in conjunction with increases in the version set by the developer. All requests that precede the definition of a new standard version are however fulfilled according to the specifications of the request, as the update occurs gradually and for domains, not to affect the validity of the application.
In view of the various system requirements, there is no explicit notion of state for the execution environment. The applications must therefore be concocted to comply with this principle, according to a design type of loose-coupling of the components and using appropriate mechanisms for the maintenance of a concept of state (memcache, datastore). Scalability is indeed a critical issue for cloud applications in general and in particular for Google App Engine, which allows you to distribute the overall load on the application to different servers dynamically in a scalable way. To enable deployment of applications, whilst avoiding interference between different applications that are resident on the same physical server, each program resides within an execution environment, that is the “sandbox” block that fits between the operating system and the applications. The environment limits the domain of the functionality allowed by prohibiting certain transactions.
PaaS Model and Architecture of Google App Engine : Conclusion
Google App Engine is one of the earliest PaaS Model which is fully scalable and simply an small example of how high frequency of requests can be efficiently handled. Despite the excellent architecture, there are too much restrictions, which makes the PaaS Model inclining towards the properties of a SaaS with too much Lock-in. For example, PHP can not run natively on the App Engine.
Tagged With Google App Engine Architecture , Architecture of google app engine , google app engine is an example of paas , google app engines follows which cloud model , Google App Engine Mobile architecture , google app engine as paas , which application architectures are being used with the google app engine , descrition of google app engine architecture , Cloud PaaS Architecture , architecture Google