Transcript File - ROYALTECHNOLOGIES

Web Hosting and Management
"Past, Present, Future of web services from Wishart's lab"
Nelson Young
Wishart's Lab Presentation
May 7, 2010
Outline
• Web Hosting Process
o DNS forwarding, firewall and routing, virtual hosting
• Web Development Process
o Design, implement, document, revision control, wiki
• Web Technologies and Frameworks Involved
o C, Perl, CGI, Java Servlet, Ruby, AJAX
o Java Struts/JSF, Ruby on Rails Framework
o Infrastructure/Applications Virtualization
• Web Administration and Management
o On-campus dedicated servers
o Off-campus hosting: shared/managed web hosting,
dedicated servers, cloud computing
• Off-Campus Web Hosting
o Compare options, services, viability, maintenance
Web Hosting Process
1. Register domain name (ie. hmdb.ca) from Domain Service
Provider (ie. Verio, Justhosting)
2. Register web server's IP with Domain Service Provider
3. Set up server's AND department's firewalls to open web
ports (ie. 80,8080)
4. Set up VirtualHosting
1.Apache
2.Apache port-forwarding Tomcat
3.Apache port-forwarding Glassfish
4.Glassfish independent of Apache
5.Mongrel / Passenger Ruby on Rails
Web Development Process
Past:
• redpoll.pharmacy.ualberta.ca/wishart.biology.ualberta.ca are
homes of all legacy programs
• Static HTML web pages
• Develop and test on production server
• Front-end web pages to display results from programs in the
back-end:
o Wrote standalone C/Perl programs (ie. thrifty, shifty,
shiftor, vadar, etc...)
o Interconnect programs via piping
o Aggregate and wrap final results in a web interface (ie.
bacmap, basys, PANAV, CS23D, etc...)
Web Development Process
Present And Future:
• Separate development servers from production servers for
testing and developing
• Current web apps are more sophisticated, interactive, and
well-managed;
• Current web apps tend to follow some framework (ie Rails,
MVC paradigm, JSF); data persistence via back-end
database;
• Check out latest source codes from SVN repositories;
o facilitate code sharing and revision control
Web Technologies and Frameworks
Past:
• Web Technologies:
o C, Java Servlets/Applets and Perl
• Framework:
o Use CGI from Apache to handle dynamic contents from
results generated by independent C/Perl programs
o Use Java servlets from Tomcat
o Use flat-files instead of relational database for data
storage
o Use cronjobs to monitor and eliminate "run-away"
processes
o Very little data persistence
Web Technologies and Frameworks
Present:
• Web Technologies:
o Java Servlets, JSF, AJAX, Ruby, Perl, Python
• Framework:
o For ease of deployment and management
 JSF/Struts Framework
 Ruby on Rails
o Use MYSQL relational database for data storage and
persistence
o JSF/Java Struts
Web Technologies and Frameworks
Future:
• Web Technologies:
o Virtualization (ie. VMWare, Xen, Parallel, KVM)
• Framework:
o Virtualize existing servers
o Package, distribute, and deploy web apps via virtual
machine images (VMs)
o Take snapshots of VMs from time to time before update
as a form of infrastructure revisioning
Web Technologies and Frameworks
Future:
• Web Technologies:
o Virtualization (ie. VMWare, Xen, Parallel, KVM)
o
• Frameworks:
o Virtualize existing servers
o Upload virtualized servers to remote datacenters (ie.
Amazon, Eucalyptus, VMWare VCloud, etc...)
o Package, distribute, and deploy web apps via VMs
o Take snapshots of VMs from time to time before update
as a form of infrastructure revisioning
Web Administration and Management
Past:
• Host all the web apps at the root location on the same
server
• Dependent libraries were installed and shared on a system
level
o intricate level of dependencies
o minimal application isolation
• Cronjob to monitor and bypass run-time errors
• Documentation reside in individual programs
• No revision control or centralization of source codes (ie.
make copies of source codes in user dirs)
• Loose server security policy
o Password-authentication; no enforcement
o Simple passwords => security breach => HACKING!!!
Web Administration and Management
Present:
• Decentralize and separate web apps to different servers oncampus (ie. Rail apps, JSF apps, Java Servlets apps,
Legacy apps);
• Web apps are isolated to their own directories
• SVN repositories for application documentation and source
code revision control
• GoogleExcel to keep track of and share information about all
the servers and their hosting web apps
• Implement and enforce stricter server policy
o Private/Public key pair authentication
Web Administration and Management
Future:
• SVN repositories for application documentation and source
code revision control
• WishartWiki to document all web and standalone programs
(ie. README.txt, INSTALL.txt, NOTES.txt, RELEASES.txt)
• Migrate to off-campus web hosting
• Current production servers on campus will become
testing/development servers for users
• Implement and enforce stricter server policy
Web Administration and Management
Future:
• Off-campus web hosting
• Shared/managed web hosting
• Dedicated physical/virtual server
• Cloud Computing
• Off-campus Pros
• Save office spaces = $$$
• More reliable network uptime (ie. 99.5% uptime)
• Off-campus Cons
• No immediate hardware support
• Pay for infrastructure support and hosting services
Off-Campus Web Hosting
Shared Web Hosting (ie. OCS Solutions):
Off-Campus Web Hosting
Managed Web Hosting/Dedicated Server (ie. OCS Solutions):
Off-Campus Web Hosting
Dedicated Physical/Virtual Server (ie. OCS Solutions):
Off-Campus Web Hosting
Cloud Computing (ie. Amazon):
•
•
•
•
•
•
•
On demand, Internet-based computing utility services
Pay for what you consume
Self-administration of operating system
Low hourly charge
Support full virtualization and administrative API tools
EBS or S3 services for persistence data storage
Ideal for
• Memory and cpu-intensive web apps
• Web apps that are not “well-behaved, structured” that require
“privileged”, system access
Questions?