Web Architectures and Hosting (GAE and more) Willem Visser RW334

3-Layered Architecture

– Presentation Layer • HTML, etc.

– Application/Logic Layer – Persistence/Data Layer – Linear interaction Tier versus layered Layers are logical whereas tiers are physical

Two Related Concepts

• • Logical approaches to the architecture – Model-View-Controller (MVC) – Model-View-Presenter (MVP) MVC != MVP != 3-Layered

Model View Controller

• • • Every action in the View has a counterpart in the Controller View is stateless This is how we typically develop Browser request db query Controller response gui content View db data data Model

MVC

• • • Clear separation between presentation and domain – Presentation: View and Controller – Domain: Model GUI components split into – Controllers that react to stimuli – View that display state of model Both View and Controller observe Model for changes

Model View Presenter

• • • Every action in the View has a counterpart in the Controller, but no direct coupling, rather interface to allow mocking the View View is stateless and no direct connection to Model Makes testing simpler data request db query Browser View Presenter Model response db data data

Typical Physical Setup

Internet CDN Server Cache Server Cache Server Cache DB DB

• • • • • •

AppEngine

Run your web app on Google ’ s infrastructure Platform as a Service (PaaS) Takes the stress out of hosting your app – Scales automatically – No servers to maintain Can direct any URL to your app, or, use a free domain on appspot.com

Free up to a point Quotas to ensure fairness http://code.google.com/appengine/docs/whatisgoogleappengine.html

Languages Supported

• • • • Initially only Python Now also JVM-based languages – Java first and foremost – Also Scala, etc.

Eclipse plugin – GWT and GAE We will only consider Python

• • • • • • •

What you get

dynamic web serving, with full support for common web technologies persistent storage with queries, sorting and transactions automatic scaling and load balancing APIs for authenticating users and sending email using Google Accounts a fully featured local development environment that simulates Google App Engine on your computer task queues for performing work outside of the scope of a web request scheduled tasks for triggering events at specified times and regular intervals

Sandbox

• • • Apps run in a restricted environment where it has controlled interaction with the underlying operating system This allows migration to various servers Limitations – – – Apps can only speak to the server through http(s) Server can only communicate to the outside via URL Fetch and Email Storage is only via provided services such as Datastore and Memcache, no files can be written and can only be read if uploaded with the app – Code only runs if invoked by a request, must finish within 30s and cannot continue after the response is sent

Java Runtime Environment

• • • • • Java servlets Must stay within sandbox, no opening sockets for example Supports Java Data Objects (JDO) and Java Persistence API (JPA) for data storage Java Mail API for interaction with the Mail Service Multi-threaded with restrictions

• • • • •

Datastore

Distributed data storage Data Objects as Entities – Kind – Set of properties Schemaless – Application enforces the structure Transactions – – Fail or all pass Will retry if concurrently being updated Entity Groups – – – Application assign it when entity is created Entities from the same group are stored together Transactions manipulate data in a single group

Two types of Datastores

• • • • • Master/Slave – Default Writes data to other data center (Slave) Consistency Not availability Low Storage and CPU costs • • • • • High Replication Replicated over several data centers using Paxos Algorithm High availability – Even during planned outage – Higher latency for writes Entity groups very important now 3x the storage and CPU

One Type of Datastore

•

High Replication

– Replicated over several data centers using Paxos Algorithm – High availability • Even during planned outage • Higher latency for writes

Cloud SQL

• • • MySQL in the Cloud Not Free anymore!

– But free trial is avaliable Some minor restrictions

Google Accounts

• • • Use Google Account information during authentication Makes it easy to add access control to your app OpenID is supported since May 2010 (1.3.4)

• • • • • •

Services

URL Fetch – Allows you to access webpages Mail Memcache – High performance in-memory key-value store Image – Crop, resize, rotate and flip JPEG and PNG formats Scheduled Tasks Task Queues

• • • •

Quotas

Free accounts – 1Gb of static storage (Code) – 1GB each for incoming and outgoing data 10 applications per developer account Billable versus Fixed Quotas – Fixed quotas enforce architecture boundaries – Billable quotas are set by the application developer Detailed information is found here: – https://developers.google.com/appengine/docs/quotas

• •

GAE Verdict

Pros – Cheap and easy to use – Good integration with other Google services – SQL support (at a price) Cons – Not “ real ” Java • Very deep sandbox, with very many limitations • Limited Multi-threading – BigTable • Weak queries, hard to import/export data – Scalability, but not performance • 100 or 100M users and system perform equally slow

Amazon Elastic Beanstalk

• • • Apache Tomcat on top of EC2 (IaaS) Pros – No limitations on threading, file and network IO – Lots of Storage options • NoSQL, Relational (Relational Database Service), Your Own – Good integration with Amazon services Cons – Price!

• Nice for large deployments but too much for the little guy – However do have Free options now as well

CloudBees RUN@Cloud

• • • Also based on EC2 and Tomcat – – Automated version of Beanstalk+RDS Will have other back-ends in future Pros – – Sticky session management, unlike Beanstalk Multiple Tomcat servers per EC2 • Lower cost and in fact have free option – Native support for MySQL – Access to all Amazon services but also DEV@Cloud • Continuous Build, Integration and Testing in the Cloud Cons – Like GAE, will swap out inactive JVMs