SamSpeak - Amazon Web Services

Sorting SimpleDB queries on Multiple Attributes

Mon, 12 Jan 2009 16:20:10-0700

I was recently working with a dataset in Amazonâ�"s SimpleDB, and I needed to be able to sort query results on multiple attributes. SimpleDB currently only allows sorting by a single attribute, so I was stuck. The solution is rather simple: combine the columns that I need to sort on into a single new attribute, and use this new composite attribute to perform my sorting. I kept the existing attributes in their current form, but added a new attribute that is the concatenation of the two attributes I wished to sort.

SimpleDB sorts lexicographically, so concatenating two fields produces exactly the expected results provided you handle a few situations properly. There are a few things to keep in mind as you produce the multi-sort attribute.

Properly pad your fields

Sorting numbers in SimpleDB requires some encoding to provide the expected results. The SimpleDB documentation provides examples of this. If you have properly encoded your numeric fields, then the length of each attribute will be the same as all the rest. Each values of an attribute must be the same length to provide consistent results.

Align the sort order of each field

You can only sort your one field one direction; ascending or descending. If you wish to sort column 1 ascending and column 2 descending, then you must reverse the encoding of field 2 prior to concatenation, then sort the combined column ascending. You could also do the reverse: reverse the encoding of field 1, then sort the combined attribute descending.

The SimpleDB documentation describes encoding numeric values, but this concept applies to both numeric an alphanumeric fields, as long as the length of the attribute value is either the same, or can be padded to be the same.

Reversed encoding is nothing more then changing the data to be the reverse of what it really is. A single digit number attribute value could be subtracted from a base value, such that 0 becomes 9, 1 becomes 8, and so on. Characters can be reversed as well, turning a into z, b into y, etc. The exact encoding used will depend on the properties of the data being stored.

Keep in mind that the value of the multi-sort attribute never needs to be parsed or read: it is only used for sorting results. Even if the translation is an ugly one, it only needs to be done on an update.

Concatenate attributes in order of sorting preference

If you wish to sort on attribute A, then attribute B, followed by C, your combined attribute must be combined in that order, left to right.

Flexibility

This approach is fairly flexible, including creating a sorting attribute from any number of attributes and creating multiple sorting attributes, as long as the attribute length and number of attributes fall within the restrictions of SimpleDB.

While this technique is not new, I wanted to explain it here to provide hints to others with no idea how to solve the problem. Credit for revealing this concept to me go to Phil Windley, who told me that the only reason I donâ�"t know it already is that Iâ�"m â�Stoo youngâ�? to remember a time when most database platforms carried the same restriction. Iâ�"m just glad to have experienced old guys to learn from. :)

Cloud Computing - The 5th Utility

Mon, 22 Dec 2008 20:19:21-0700

Image by stan via Flickr

This post is part of a series of posts relating to distributed system design that I'm completing as part of my Computer Science MS program at BYU.

My 6th paper was written by some good folks at The University of Melbourne, Australia. They discuss the emerging cloud computing paradigm as the 5th Utility, and compare it with both clusters and grids. The paper (PDF) argues that clusters and grids cannot be considered a utility by themselves, but cloud computing fits the necessary requirements.

Clusters are groups of machines that work together to accomplish a single task, such as serve web content. Each machine is the same, and they all perform the same task. Clusters can scale in size to handle varying loads. Grids support multiple jobs of different characteristics, typically within a required framework. Clouds can scale (like clusters), and support a wide variety of jobs simultaneously. Clouds take scaling to such an extreme that they can scale to nothing, which neither clusters or grids support. This minimal commitment, without minimum usage levels, is what makes clouds so useful. Just as water, electricity, gas, and telephony (the first 4 utilities) can scale from nothing to very high usage, clouds can scale to any reasonable load.

As Iâ�"ve mentioned in several of my other paper reviews, it is very clear that cloud computing exists in a layer underneath clusters and grids. Clusters and grids can be built on top of cloud computing systems, as cloud systems utilize virtual machines as a hardware abstraction. The unique piece that makes it possible is the dynamic provisioning made available through the API. While some hosting providers can provision servers in only a few hours, cloud providers provision their resources within minutes, and sometimes within seconds.

At this point, there are few cloud providers, and each has their own API, terms of use, and types of services. As more providers enter the market, a consistent interface will be needed in order to tame the API chaos. While some services may end up sharing an API, consistency can also be provided via a meta-interface that can translate the users commands into whatever syntax is required by the particular provider and service being utilized. This layer can either be constructed in the cloud itself, in client based toolkits, or as a combination of the two. The concept of a metalayer is demonstrated in the paper through the creation of a meta-storage service, capable of storing data in several cloud services through a single API.

Just as interfaces are not likely to completely converge, the properties of each service are also not likely to be identical between providers. Speed, price, reliability, and other factors will vary, allowing users to select the proper service to fit their particular need. Some services will provide an SLA, providing service guarantees.

It is still very early in the development of cloud services, and Iâ�"m sure that we will be seeing new entries for years to come. Amazon has hinted at some of the services that will be made available in this next calendar year, including load balancing and monitoring and automation management. As we see more entries in the space, it will become easier to understand the strengths and weaknesses of cloud computing, as well as define itâ�"s limits.

Iâ�"m excited for the expansion of cloud computing, and I look forward to more studies that can help us understand better.

Really Bad reasons not to auto-scale cloud based systems

Sat, 06 Dec 2008 19:26:57-0700

O'Reilly writer George Reese posted today what I consider to be a poor evaluation of the perils of auto-scaling in the cloud.

He does mention the concept of using a governor to limit the power of the auto-scale agent to spin up servers (and spend money), but his insight ends there. Anyone following cloudy issues will have read Don MacAskill's excellent post this past June, where he explains their auto-scale operation, and the need to set limits.

George also makes a few arguments against auto-scaling, which I'll address briefly:

1. Amazon and other clouds cannot respond fast enough to increased capacity needs.

George claims that a 10 minute instance spin up time cannot respond fast enough to help. This is only true if you start to spin up your service when the existing is already (or nearly) toast. Common strategies involve already having some extra capacity running, so as to not immediately fold under an increase. Solving this problem is just tuning the thresholds.

2. Got any disgruntled employees, unhappy customers, or malicious competitors?

George claims that auto-scaling will waste your money in the event of a denial-of-service attack. What he doesn't mention is that a DoS on a non-auto-scaled system will likely take it down. At the very least, it will artificially inflate your usage anyway, and you will still have to spin up more resources to handle the load. I'd rather spend a few extra bucks and STAY UP.

3. So you think you'll stick some governors in place...

George's main claim here is that your governor is likely to be set at the wrong value. Although he doesn't explicity say, he seems to be implying that a governor can only be used to limit the total number of machines. SmugMug (in the aforelinked post) indicates that their governor limits the rate at which new machines can be started. Using this strategy, only the rate of traffic growth.

4. So what about getting slashdotted?

The main complaint here is that an auto-scale agent cannot tell the difference between true traffic growth and a random spike. Clearly, George has never worked with noise filters, which smooth data to reveal real trends. Evaluating load data from the past few minutes will allow agents to ignore spikes easily. Again, this is reduced to tuning thresholds.

5. Don't you lose a key value of the cloud without auto-scaling?

Despite George's claims that no value is lost, there are clear cases where auto-scaling can save your bacon. He claims that 'capacity planning' is the clear answer. I agree with him on the importance of capacity planning, but disagree that proper capacity planning eliminates the need to auto-scale. A good auto-scaling system can save quite a lot of money in cloud processing expenses, which will do wonders for the bottom line.

Summary

I'm not bashing capacity planning here. I believe that capacity planning concepts work very well with auto-scaling, that that proper user of governors and properly set thresholds are the right way to go.

I rarely respond to lousily written posts and dumb opinions, but this one irked me for some reason. At this point, I have nothing but logic and the experiences of others to rely upon. Over the next few years, I plan on gaining some extensive experience in auto-scaling cloud based systems, and perhaps then I'll be in a better position to dish a proper smack-down.

The Power of Epidemics

Wed, 12 Nov 2008 19:33:31-0700

This post is part of a series of posts relating to distributed system design that I'm completing as part of my Computer Science MS program at BYU.

As systems grow, the task of communication between nodes in the system can become a herculean task. Frequently, the limitations of the communication protocol serve as the upper bound of system size despite plentiful system resources. Many methods exist for allowing communication to scale with system size, but most succeed only in raising the threshold for system size.

Epidemic communication protocols, also known as gossip protocols, approach the communication problem from a completely different angle. I read about these concepts in a 2002 paper entitled The Power of Epidemics: Robust Communication for Large-Scale Distributed Systems [pdf] by Werner Vogels, Tobbert van Renesse, and Ken Birman. Whereas many other protocols follow rigid and organized communication patterns, Epidemic protocols rely on random communication between nodes to achieve rapid and robust information spread.

Naming these protocols after patterns of disease spread and the gossip patterns of human social groups is not an accident. These protocols have the advantage of being very simple because of our familiarity with these situations in society. Just as disease spreads through a population through random contact between two society members, information spreads between two nodes as each node chooses another at random with which to compare state. Gossip protocols rely on frequent communication between nodes to spread new information. Putting these two concepts produces the system described by Vogels et. al.

Each node selects another node from it's stored membership list once per second. The two nodes transfer a representation of state quickly, and upon discovery of a mismatch send updates to the other party. When a single node becomes aware of new information, it will share that information within one second to another node. The two copies become 4 copies, then 8, 16, 32, and so forth for each second passed. There are three important properties of these systems: speed and reliability, and constant load

Speed

In my previous example of spread, I assumed a doubling of information for each time period. This is in fact low, as on average each node will be in contact with two other nodes per time period, causing the number of informed nodes to grow by a factor of 4. One copy becomes 4 copies becomes 16, 64, 256, and so on. This growth can spread information even throughout very large systems in a very short time. Assuming our average of two gossip connections per second, the theoretic message spread is 1 million nodes after 10 seconds. For a system of 250 thousand nodes, the chance of a node NOT receiving the information update within 10 seconds becomes vanishingly small

Reliability

The paper introduces the concept of probabilistic guarantees. While it sounds counter-intuitive, considering the probability that a node will NOT have received an update within a period of time isn't insane. The probability is so low, given even only a few seconds, that it exceeds the probability of system and network failures.

Constant Load

The really cool thing about these types of protocols is the constant load required of each machine at any scale. Used in a cluster of 3 nodes, each node talks to (on average) 2 other nodes per time period. Expand that cluster to 250,000 nodes, and each node talks to ...... 2 nodes per time period. Few communication protocols operate under such constant load. Because of the randomness required for node selection, each node may talk to only one node or quite a few during a single period. Measured over a few time periods, the load will appear to be quite constant.

So there you have it. Next time you need to design a scalable communication system, consider giving your system the flu.

Amazon's Dynamo - Highly Available Key Store

Tue, 28 Oct 2008 20:41:25-0700

This post is part of a series of posts relating to distributed system design that I'm completing as part of my Computer Science MS program at BYU.

Amazon's Dynamo is a key-value storage system used internally at Amazon. It provides high-speed simple storage at extremely high levels of availability. The paper is available online.

In addition to describing the Dynamo system, this paper is an excellent resource for issues relevant to system design. I've selected a few of the topics mentioned in the paper, with some comments on each.

Symmetric Nodes

Dynamo clusters have two basic duties. Each read or write has a coordinating server, and each read and write uses several storage servers. Rather then form Dynamo into a 2 layer system with a layer of coordinators and a layer of storage servers, they formed the servers to perform both the coordination services and storage services. They cite simplified system provisioning and maintenance as their reasons for this choice.

This design does make scaling a little easier, as deploying a node adds resources to both services, but I think it applies so well here because of the predictable levels of work and the constant ratio between each of the services. An increase in requests will increase work for both the coordination services and the storage services, and adding additional servers will support both services to approximately the same degree.

In a system where the processing at each layer is highly variable, this strategy could result in an unbalanced situation, where launching more servers will only support one of the services. As always, considering the characteristics of the service will guide the proper solution.

Dynamically Scaling Under Load

Throughout the paper, they discuss the requirement that the system be capable of adding and removing nodes under load without impacting the external performance of the system. They noted that their first design required significant background processing, and they had to develop systems to carefully monitor and control the processing power consumed by the background services.

This issue is a sneaky one, because serving requests must continue during the process of re-distributing data and processing assignments. They mentioned some changes they made to reduce the background processing required, which allowed them to devote more processing time to serving requests.

Nearly every service will have background processing of some kind, and setting these services to be 'kind' to the performance of requests will help improve performance when the system comes under load.

Eventual Consistency

Dynamo (and several of the public Amazon Web Services) follow an eventually consistent model. By relaxing consistency, they can offer greater levels of availability and speed. Near the end of the paper, they reveal that 99.94% of the read requests had no artifacts of this relaxed requirement.

Their design leaves the process of conflict resolution to the client, which allows a resolution process specific to the nature of the data. Allowing the most recent write to win will work in many situations, and is easy to resolve. Under more specific requirements, the client may want to combine the conflicting data. Fortunately, passing the resolution buck to the client allows each application to resolve this issue in whatever way is appropriate. (CouchDB follows this same principle.)

Eventual consistency forces the consideration of failure; when it fails, how hard is it to recover? Understanding the consequences of failure can allow proper tuning of the system, as well as guide resolution processes.

Smart Clients

The paper describes two methods for distributing requests to the nodes in the cluster: load balancers and smart clients.

Load balancers are a common solution, and are considered standard fare in most systems. They forward inbound requests evenly among nodes, and then return the node's response to the client. Most large websites use load balancers to serve traffic, enabling many servers to act like one.

Smart clients are a powerful tool that can provide the same levels of fail over at increased speeds. If the client is programmable, then it can choose the server to ask itself, and eliminate the need for a load balancer. It chooses it's node according to embedded logic, and will also fail over to a different node if the first one does not respond. The clients must be 'smart' enough to discover cluster nodes and handle failure gracefully. In a load balanced configuration, these tasks are performed by the load balancer.

Smart Dynamo clients poll a random cluster node every 10 seconds to retrieve a list of nodes. The clients will also retrieve a new list if they detect a failure situation.

In many applications of smart clients, an update frequency of 10 seconds is far too fast and can be reduced to match the speed of adding or removing nodes. Smart clients can also choose cluster nodes based on network speed, allowing easy geographic load balancing.

The speed gains measured through the user of smart clients is remarkable. response times were more then 50% shorter as a result of removing the load balancer from the picture.

Thoughts

Each of these concepts, and others in the paper, can be applied to a wide variety of systems. I'm grateful to the Amazon team that published this paper, and I'm grateful for the insight it provides.

smart clients - improved performance by half by removing the load balancer. they polled frequently 10s for server lists, could be much longer. smart polling on failure.

Missing Pieces of Cloud Computing

Thu, 21 Aug 2008 09:00:56-0700

Between Google's AppEngine and Amazon's Web Services platform, you can build almost everything you need to run a scalable system. The 'almost' is what is currently preventing these platforms from supporting truly beautiful cloud systems. I believe that the two most important pieces of Cloud Computing are scheduled processes and load balancing.

Scheduled Processes in a cloud computing application are necessary for tasks both simple and complex. On the simple side, a task can be used to send reminder emails to system users, or generate periodic reports based on system data. On the complex side, scheduled processes might communicate with a processing grid via asynchronous queues, or perform orchestration functions to manage a scalable computing cluster. The best provider of this service is likely to be Google's AppEngine.

During an AppEngine session at Google IO, the presenter did mention that offline processing was a planned (and often requested) feature, but they did not give details. Their offline processing may only be the ability to launch threads and return rapidly to the user, but I hope it also contains some mechanism for the timing of script execution.

In the meantime, it is possible to invoke processing scripts from an automated system, either running on hardware you own or a service such as WebCron, but it will be nice to have a more elegant solution.

Load Balancing allows for a group of computers to be joined into a cluster, allowing service of more requests then a single machine can handle. While AppEngine does not require load balancing to scale, clusters within EC2 need this functionality if they service public requests. Load balancers exist in both hardware and software form, and generally provide several methods of load distribution, system failure handling, and sometimes SSL termination for secure connections. Currently, software load balancers must be used to load balance within the EC2 environment, and at least 2 of these machines are required to gracefully handle machine failures.

Providing this service in a scalable way would greatly simplify the design of computing clusters within the EC2 environment. It would also make managing public IP addresses a little easier, as only the load balancing service needs a public address. Amazon is currently testing a form of persistent storage within their EC2 environment, and I imagine that a load balancing solution could be offered in a similar form. Amazon may decide not to offer this service, preferring 3rd party solutions.

In Summary, I look forward to the future of cloud infrastructure. I'm excited to be able to develop to these platforms, and I expect great things in the future from both of these companies and others as well.

Needed: Mini EC2 instance sizes

Mon, 14 Apr 2008 23:38:25-0700

Amazon Web Services Elastic Compute Cloud (EC2) currently has three instance sizes: Small, Large, and Extra Large, priced at 10 cents, 40 cents, and 80 cents per hour. Allowing different instance sizes is pretty powerful, as it allows some scale-up in addition to scale-out. Scale-up ends up being pretty useful running things like database servers.

What's missing is a mini instance. To run a scalable application on Amazon's cloud, an orchestration server is required to keep things running the way they ought to. The orchestration server is the system that keeps an eye on SQS queue lengths, launches or terminates EC2 instances, and provides uptime and availability checking. The processing requirements are minimal.

Running an EC2 instance 24x7 costs ~ $72 per month. If you want 2 servers (in different zones, of course) for redundancy, it's going to cost $144 per month just to monitor your system. Because of this situation, most people run their orchestration server on their own hardware.

If they allowed a mini instance with one quarter of a Small instance's resources and charged 2.5 cents per hour, it would cut the cost down to $36 per month for redundant orchestration services.

With their recent improvements to EC2, mini instance sizes would greater flexibility and control of systems built on the cloud.

Amazon EC2 Persistent Storage

Sun, 13 Apr 2008 23:18:34-0700

Amazon announced what appears to be a private beta of a new extension of their EC2 and S3 platform: Persistent Storage. You can create a drive in any size between 1 GB and 1TB, and then mount it as a drive onto any single EC2 instance. Although the virtual machines already have storage available on the instance itself, this allows virtual machines to access quite a large disk space. Restricting the volume to a single EC2 instance eliminates the scale/concurrency problem, so no eventual consistency requirements are placed on this volume.

In a very Amazon 'building blocks' way, they create the volume as an unformatted drive, allowing you to use any filesystem you would like. Further, they have built the system to allow fast access between the volume and EC2 instances. This portion of their puzzle is clearly built on a high-performance SAN well connected into the EC2 network.

This type of storage solves two problems with EC2: Needing more then the provided drive space, and eliminating lost data problems caused by vanishing instances. They mention that this type of storage is perfect for running a database server.

I like the idea, but I need a few things cleared up first. A database server needs to be redundant. How do we configure the system to move the mounted drive to the hot spare instance in the event of a failure? Detecting a failed instance, starting up a new one and reattaching it to the existing volume seems to make sense, but will require some downtime.

It will be interesting to see how this plays out.

Designing an Interface - SimpleDB CFC

Wed, 20 Feb 2008 18:55:00-0700

I'm working on a ColdFusion library for Amazon's SimpleDB, and I'm mulling over the options for how I want the library to work. I've completed the authorization code and the methods that deal with creating, listing, and deleting domains. They exist well as function calls, with the listing method returning a query object for easy iterating.

The two pieces that remain are the methods that deal with items (records within the domain) and queries against a domain. Here are a few options that I have, and I'd love some feedback!

Item Methods

SimpleDB allows you to add attributes to an item and remove them, as well as retrieve all (or a subset) of the attributes of an item.

There are two main approaches here: Present an Item object with methods, or present the methods within the main CFC itself.

Presenting an Item as an object would work like this:


item = simpledb.getItem(domainname, itemname)
item.setAttribute(attributename, attributevalue, replace=false)
item.deleteAttribute(attributename)
foo = item.getAttribute(attributename)
item.persist()

Presenting methods from the main cfc would look like this:


simpledb.setAttribute(domain, item, attribute, value, queue=false)
simpledb.deleteAttribute(domain, item, attribute)
foo = simpledb.getItemAttribute(domain, item, attribute)
mystruct = simpledb.getItemAttributes(domain, item)
simpledb.persistChanges(domain, [item])

In either case, changes could be queued in the system until persist() or persistChanges() was called. This way, multiple attribute sets could be combined together to speed processing.

The examples I provide here are a bit rough, but I'm sure you get the idea.

Which of these options is going to be more simple / coldfusion like?

Queries

The SimpleDB API returns a list of itemnames to queries. This means that to access the data, you need to query the attributes for each item. The simplest option would be to return the list of itemnames, and allow use of the other methods to get the desired attributes.

A more full-featured interface would have the option to get the attributes for each item and form it into a query. An iterator object could be another option, with either attribute access methods or simply returning an item object similar to the one mentioned in the item section.

Plea For Thoughts

So, does this rambling question make any sense? Which style (thin and rough, fat and friendly) of API interface do you prefer?

If my thoughts need to be better formed before any worthwhile answer can be given, please let me know.

Amazon Web Services SQS Price Changes

Wed, 06 Feb 2008 16:14:38-0700

Amazon Web Services announced a price change for SQS today. They changed prices, but also how the prices were charged. Some are claiming huge savings. I did a little math to see who it would affect and how much.

The price changed from $0.10 per 1,000 messages to $0.01 per 10,000 requests. Charging by request means that pushing a message and asking for messages counts as two requests. You can make 100 requests (new pricing) for the cost of 1 message (old pricing). This means that if you poll 99 times for every message you pass through the queue, you will pay exactly the same amount.

If you poll once every 5 minutes, 3 messages per day will have you break about even. Polling once a minute, it takes 15 messages per day to break even. Systems of this size will not see much change. The monthly fee with 15 messages/1 minute polling is only 5 cents (not counting bandwidth) anyway.

Larger systems will see a much bigger difference. If you have 10 servers polling a queue once per second, you will need 8640 messages per day to break even. But seriously: Your monthly fee for a system like this? $26.44 (not counting bandwidth).

In either case, clever polling schemes (fallback, based on time of day, etc) could save some money. If the other end of your queue is a scalable EC2 layer, and you only run servers when there is stuff in the queue, then your savings are likely to be pretty good.

So in any case, it's all still pretty cheap.

Goog-411, Checkout, and Amazon Web Services

Mon, 17 Dec 2007 07:33:25-0700

When Google announced their 1-800-GOOG-411 free business lookup service, I realized pretty quickly that their purpose was to collect a huge volume of voice data for text-to-speech training. I didn't post about it at the time, so you are going to have to believe me. Or perhaps not, as Google Blogoscoped reports that Marissa Mayer claims that to be the case.

Is it unheard of for a company to set up a service for a purpose other then making money directly from it? Consider Amazon Web Services. They offer storage, computing, and other infrastructure services, and you pay for the use of these services. But does Amazon actually make any profit from these services? They do, but the real advantage for Amazon is in their cost savings by offering the services to customers.

Huh? Cost savings from offering a service?

Consider all the additional bandwidth consumed by users of the S3 and EC2 services. Since users pay for the bandwidth they consume, it doesn't cost Amazon much to move the traffic through their network. What it does do for Amazon is qualify them for cheaper bandwidth from their service providers because of the additional volume. That's right: by using S3, you are saving Amazon money on all of their own bandwidth.

I'm told that the savings caused by Amazon Web Services in such a way far outweighs the profit from the actual services themselves.

I believe that Google built their Checkout platform for precisely the same reasons. While I'm sure that Adwords also had something to do with it, I think the main purposes of Checkout was to draw more credit card transactions, allowing Goggle to qualify for additional discounts on their own transactions.

Amazon's Flexible Payment Service was probably built for the same purposes. Smart I tell you. Offer an awesome service that helps other people save, and then leverage their use of the services to make (save) additional money.

DataCenter

Tue, 04 Dec 2007 09:47:38-0700

This note is just for the 462 Students:

Barry Dixon is expecting you about 4:30 at the ViaWest data center next Wednesday (Dec 5). You're responsible for getting yourself there and back. Feel free to carpool or whatever. The data center is located in the Canopy building at 333 S 520 W, Lindon, Utah 84042. Take exit 273 from I-15 and its just east of the freeway north of Home Depot. Here's a map. The tour will take about an hour.

Amazon EC2 Welcomes Paid Platforms

Thu, 08 Nov 2007 05:25:50-0700

Red Hat Enterprise Linux, a paid software platform, has recently announced a private beta of a service that allows users to deploy their software onto Amazon's EC2 computing cloud, paying $19 per month plus hourly usage fees. The fees are in addition to the computing time and bandwidth charges paid to Amazon.

I could not be happier to see this happen. I'm a huge ColdFusion fan for web-app development, but I'm struggling with the prospect of using ColdFusion for a system that I will need to be able to scale in a way that EC2 provides. Red Hat will lead the way, and hopefully many others will follow with similar instance/hour payment options.

If Adobe allowed such license terms, it would allow me to write web applications completely in ColdFusion, and then deploy code either to a regular licensed production box or onto a computing cluster when demand calls for extra computing power.

JavaScript Driven Load Balancing

Mon, 08 Oct 2007 22:25:00-0700

Digital Web magazine has an article on the idea of using JavaScript on the client side to manage the load balancing of a server cluster without an actual load balancer in place. This is a very cool idea, particularly for virtual server farms such as Amazon's EC2. If you introduce a load balancer (hardware if possible or software), you must use more then one in a cluster configuration. If we can eliminate the need for a traditional load balancer by writing intelligent clients, we can have a much more scalable, reliable system. What I wish for is a nicer way of doing cross domain Ajax calls. Flash uses a crossdomain.xml file, and I think something similar would benefit JS based clients in a very nice way.

Adobe's Services Play

Tue, 02 Oct 2007 19:28:00-0700

Today at Adobe's MAX Conference in Chicago, they highlighted in a general session some new services that Adobe is getting into. Adobe has long been a software company of the install variety. They announced some services that lead them into a very different model as a company. These new services will likely never be the core of Adobe, but do help it expand into new areas of business. The most interesting service is what they introduced as CoCoMo. The services expose all the underlying features present in their Connect application as Flex components that can be built into any Flex application. This allows integrating conferencing, audio, video, whiteboard, and screen sharing into any application. They appear to be billing this similar to their current model. The components must connect to a Connect room, which could likely be used with their current interface as well. They also announced a different product called Pacifica that seemed to have the same set of features, but somehow was listed under a different product name. I'm very confused on the difference between these two products. In a different space, they released SHARE, an online file sharing service with 1GB of space for free. You add files (of any type) into the system, and then you can share them with anyone or only specific users. I couldn't find the ability to update a file by uploading a new version, but did see several places list both a Created and a Last Updated date for the file. They do have REST APIs for the entire service, so you can build a front end onto this, or mash it up with a completely separate service. I expect to see both an AIR version (with drag and drop upload and download) and file system extensions to have this space mounted as a drive very soon. I am very much a fan of Amazon Web Services. Amazon's services are very aligned with their core competencies of infrastructure and scale. These services (with the exception of the SHARE service), play very well to Adobe's strengths. I'm excited to see more companies entering the service/infrastructure business.