Posts Tagged aws
I am proudly announcing another incredible cross-departmental coding collaboration that resulted in an upgrade to our UW Web Services Registry (now a portal).
- Chris Heiland (UW Marketing)
- Kilian Frey (UW Marketing)
- Andrew S. McHarg (UWIT Network Tools)
- Nick Chen (UWIT Network Tools)
- Tony Chang (UWIT Application Integration Services)
After a one week (5 day) sprint, meaning we found a place to work face to face for one week with little to no interruptions, we were able to make the following changes:
1. New Developers – We got two new developers ramped up to help develop and support future updates to the UW Web Services Portal.
2. Amazon Web Services EC2 Micro Instances – The UW Web Services Portal is currently running on an EC2 micro instance saving the UW about $50 per month and supporting a critical piece of the UW Web Service infrastructure for only about $17 per month.
3. New portal and registry design – We now only have to give out ONE url to tell people about web services. Big thanks again to UW Marketing for helping our initiative with much needed UX help.
4. AWS EC2 SnapRest automation – A tool that provisions a new test or production instance directly from our running production instance in only 5 minutes by running one command line. This is key for disaster recovery and cost reduction related to server provisioning. Chris writes up a blog on this innovative work.
5. Auto-complete Service Search – A search text box has been added with the capability to search and filter services using an auto-complete design.
6. Upcoming Services – Now you can add services to the Registry that are not yet in production and tell everyone that its coming soon.
7. UserVoice Integration – We have integrated UserVoice feedback data into our site by using their RESTful APIs to correlate suggestions/feedback to and from our Portal for specific services.
8. Twitter – We integrated our Portal with twitter, using their RESTful APIs, so that we can talk about web services as a community using tweets. Just hit up twitter hashtag #uwweb.
9. Blog RSS – We integrated our OnTheROA blog into our Registry via RSS feeds, yes you can consider it another RESTful API.
10. Proven cross-department collaboration – we have proven yet again that people from diverse UW teams, across organizational boundaries, can work efficiently and collaboratively in quick order to provide real value to the UW. Oh by the way and have FUN doing so…
You can read in detail about all the hard work here: https://sig.washington.edu/itsigs/Registry/Portal_Sprint_Feb_2011
You can also get a list of all our GitHub code checkins here: https://github.com/tonychang/uw-registry-v1/commits/master
One of the tasks on the schedule for the Web Services Registry was to move from a small instance to the newly offered micro instance on EC2. The migration to an expandable drive was the largest amount of work, however, a huge benefit as an instance mounted with an EBS root volume enables any size drive up to 1TB.
This also changed how backups were done. Instead of creating an image.manifest and uploading the resulting data to S3, it’s now done via snapshots. However we still retained the ability to create an working server based on a current instance. The web console allows most of this activity but the real power comes in the command line tools.
For single operations the web interface is extremely easy to use but when dealing with hundreds of servers there is nothing better than accessing the AWS API. For this exercise we have only one server, but for efficiencies sake we are automating the mundane of the work. The current process starts with running the script, creatively called snaprest.
Once finished we can login to the control panel and see the results. The script takes a snapshot of the current drive, and registers it as an AMI. If we just wanted to backup the entire server we would be done. However one of benefits of this process is creating a additional environments for any necessary testing.
The AMI can now be launch as an instance and accessed just like the server it was generated from. We can launch a development environment for deployment of new code for testing in very short order. There is an elastic IP standing by so we can access the site via the development url so the server acts exactly like production. Switching development to production is also feasible via a few simple clicks.
The entire process is quick and due to the command line tools, entirely scriptable. Deployment is remarkably fast and reliable, the command line tools give plenty of flexibility and the process is very straightforward. No wonder so many companies are using AWS as a cloud solution for server infrastructure. Welcome to the future.