New to AWS and looking to gain a foundational knowledge about key AWS services? Our “Introduction to AWS” series includes free, on-demand instructional videos and labs that enable you to learn about AWS in 30 minutes or less. Start by watching a short video about an AWS service to learn about key concepts and terminology and see a step-by-step console demonstration. Next, get hands-on practice using the AWS service with a free self-paced training lab.
via AWS Training – Free Online Videos and Labs.
I didn’t, but I do now. These are great for learning about the fundamentals of AWS cloud computing. Topics covered include intros to Simple Storage Service (S3), Elastic Compute Cloud (EC2), Identity and Access Management (IAM), Relational Database Service (RDS), and Elastic Load Balancing. Used along with the AWS Free Tier these represent an excellent for anyone to become more familiar with running servers and systems and getting a better understanding of cloud computing.
What I want is a web/cloud based authoring environment that gives me the capability to create documents that can are digital and can be displayed as needed. Some examples include a blog post, an essay, a research article, a presentation, documentation, notes, and so on.
First up is a flexible text markup system. I need something that is capable of handling a lot of different markup elements. Some of the documents that I need to create have complex structures that are not easily simplified. After looking at a number of markup schemes including various wiki languages and Markdown, I decided to go with AsciiDoc. AsciiDoc provides text markup for most elements of DocBook 4.5 allowing for the creation of highly structured documents using a simple text editor.
At this writing there are 2 tool chains for rendering AsciiDoc. The original AsciiDoc, which is written in Python and AsciiDoctor, a new native Ruby version. I plan on using AsciiDoctor for most of the work, but will need to fall back to the original tool chain for some features (like PDF generation). I will be installing both.
Next up, solving the web-based editor issue.
The Amazon Relational Database Service (RDS) was designed to simplify one of the most complex of all common IT activities: managing and scaling a relational database while providing fast, predictable performance and high availability.
RDS in Action
In the 3.5 years since we launched Amazon RDS, a lot has happened. Amazon RDS is now being used in mission-critical deployments by tens of thousands of businesses of all sizes. We now process trillions of I/O requests each month for these customers. We’re seeing strong adoption in enterprises such as Samsung and Unilever, web-scale applications like Flipboard and Airbnb, and large-scale organizations like NASA JPL and Obama for America.
via Amazon Web Services Blog: Amazon RDS: 3.5 years, 3 Engines, 9 Regions, 50+ Features and Tens of Thousands of Customers.
As part of recent rebuild of Classcaster, I shifted the MySQL database for the system to Amazon RDS. I found the process of importing an existing database to be straight forward and was up and running in no time. Since it is just an instance of MySQL running in the Amazon cloud, I administer it as I do the other my other MySQL databases running on AWS EC2 instance using SQLyog on Mac and Windows and MySQL Workbench on Linux1» .
As far as performance goes, RDS seems a bit more responsive than the AWS EC2 hosted databases I run. It is important to note that it is possible to knock it over by overloading the connection pool2» . Logging and backups are handled well and access to these from the RDS dashboard is pretty good. Although I haven’t tried it yet, the features exist to scale the database as needed. I may take advantage of some of this if I decide to move our main databases to RDS.
Overall, I’d recommend RDS as a good way to get a database up and running quickly and to provide a stable backed for your systems.
Usually I might not be too keen to lose some of my job responsibilities, but in this case I couldn’t be happier. CALI is adding a systems administrator to wrangle all our servers, more than 20 at last count, on a full time basis. Since I started working at CALI 9 years ago my time has been split between web/database/cool project development and administering CALI’s servers and systems.
Back in 2003 that meant riding herd on an aging Windows NT server, a Win2K server handling some video streaming, and a couple of dark servers whose futures where not yet set. Of course the servers where in Chicago and I was in Atlanta. Things changed rapidly. The dark servers where brought online running Linux and our production web and storage systems where built out on the LAMP stack. Within a couple of years I added 3 servers at Emory in Atlanta to handle the increased demand for CALI services and resources online.
It wasn’t very long before we were struggling with large spikes in demand that were taxing our servers and we needed a better solution. Simply increasing the amount of hardware we owned wasn’t really an option since we were borrowing space and bandwidth from the law schools at Kent and Emory. At just the right time, Amazon Web Services came along and CALI jumped into the cloud.
Moving our web infrastructure to the AWS cloud gave us tremendous flexibility at a reasonable cost. After some trial and error I was able to configure a load-balanced web cluster that could be scaled up and down as demand for CALI resources and services flowed over the course of an academic year. Using the cloud meant that I could provision some services on their own servers so that things like Apache Solr and Asterisk could stand alone. As a result of the move to the cloud, by the beginning of 2011 I found myself administering 15 to 20 servers in the cloud alone (exact numbers depended on the time of year) plus another half dozen physical servers in 2 geographically dispersed locations.
All that sounds like a full time job itself, but that was only half the job. While all that infrastructure was being built out I was also developing 3 different versions of the CALI website, the Classcaster phone-to-blog system, a couple of iterations of eLangdell, the Free Law Reporter, and dealing with various other projects. Working on these development projects is what I really enjoy, but they often get pushed aside since I need to keep the servers running as a priority.
Now CALI is hiring a systems administrator to take over (or clean up) the running of our infrastructure. I’m looking forward to handing the keys of the cloud over to someone else so I can focus on all of the great projects that are in the pipeline. When can you start?
Details on the CALI sys admin job, which is located in our Chicago office, are at http://cca.li/6J.
The promise of network block storage is wonderful: Take a familiar abstraction (the disk), sprinkle on some magic cloud pixie dust so that it’s completely reliable, available over the same cheap network you’re using for app traffic, map it to any instance in a datacenter regardless of network topology, make it so cheap it’s practically free, and voila, we can have our cake and eat it too! It’s the holy grail many a storage vendor, most of whom with decades experience in storage systems and engineering teams thousands strong have chased for a long, long time. The disk that never dies. The disk that’s not a disk.
The reality, however, is that the disk has never been a great abstraction, and the long history of crappy implementations has meant that many behavioral workarounds have found their way far up the stack. The best case scenario is that a disk device breaks and it’s immediately catastrophic taking your entire operating system with it. Failure modes go downhill from there. Networks have their own set of special failure modes too. When you combine the two, and that disk you depend on is sitting on the far side of the network from where your operating system is, you get a combinatorial explosion of complexity.
Magical Block Store: When Abstractions Fail Us « Joyeur.
Fascinating piece on the perils of disk abstraction. Raises a very good question: Why do we worry about disks at all in the cloud? I wonder how many folks would just be tossing data into the cloud without the comfy metaphor of disk and machine to lean on?