I recently wrote about how Amazon’s new Dash service embodies the Stackato vision; in that post I discussed how Dash reflects the Business Agility portion of our vision. As the image to the left shows, Dash is a service that offers a small button; when pressed, magic happens and an order is placed for the product (in this example, Tide detergent), which is eventually delivered to the customer.
Dash presents a very different model of retailing, changing the purchase execution from a physical retail outlet or an online website to the very location of product consumption. With this service, Amazon boxes out its retail competitors by offering a more convenient and immediate transaction. I think Dash is a really interesting and innovative offering that foreshadows the enormous changes the Third Platform portends.
In this post, I’d like to discuss the technical underpinnings of the Dash offering and how the Dash architecture aligns almost perfectly with what we’ve created in Stackato.
I analyzed the Dash service to understand what it would take, from a technical perspective, to begin with someone pressing a small magnetized button and end with a product showing up on the button presser’s doorstep. In effect, I reverse engineered the service to understand its architecture and the components that would be required to execute that transaction.
As you can see from Figure 1 below, the Dash architecture is comprised of four tiers, each of which has multiple components.
From left to right, the four tiers are:
- Customer tier: this is where the purchase transaction occurs. The notion of a button push isn’t quite accurate, as Dash also supports use of a wand that can scan or accept voice input (e.g., “Buy a roll of Saran Wrap”). In the future, the Dash service will be built into physical devices, which will trigger purchase actions when needed products run low. In the figure, these devices are represented by a washer/dryer; as the washer runs low on soap powder, the washer will order more. It doesn’t take a genius to recognize the power of a product being automatically ordered without human intervention -- it practically makes the default product choice (e.g., Tide) a lock-in, with very low probability of the consumer purchasing another product. Dash also supports a mobile app that can be used to review orders and approve or remove specific items.
- Event tier: this tier is where the Dash orders are captured by the service’s backend. A number of steps take place to process each order event to ensure the Dash application operates correctly. More on this below.
- Application tier: This tier executed the Dash logic -- managing orders, triggering ecommerce transactions, and enabling partners to interact with the Dash system.
- Ecommerce tier: This tier represents the Amazon retail offering, where orders are accepted, payments triggered, and products shipped.
Let’s look at each tier in turn.
In this tier one of several devices begins a purchase transaction via one of the Dash client devices -- a button, wand, or embedded hardware device (e.g., a washer). Each transaction is captured in a packet of information that is quite small -- probably a few hundred bytes; all it needs to contain is the Amazon product id and the purchase indicator flag.
However, the Dash wand also allows items to be ordered by voice, which complicates things in that a voice file must be captured and submitted (and, of course, ultimately undergo transcription and validation). This aspect of orders will be discussed in the Event Tier section, which follows.
In terms of how order events are communicated, I believe that the foundation of the device/application communication is the AWS Kinesis service, which is designed to be a very high-performance, scalable, real-time event processing service. Kinesis offers a client-side library that can be embedded into a device’s firmware; this library formats event submission packets in Kinesis format.
For orders submitted via voice input on the wand device, the event would probably have a flag set to indicate that a recording of the order has been stored in an S3 object.
No matter what type of device submits an order, therefore, an event is submitted to Kinesis, which resides in the Event Tier, with an optional voice recording object accompanying certain order events stored in an S3 bucket. This portion of the Dash service is indicated by the number 1 in Figure 1.
However, the Client Tier offers more functionality than submitting orders for items. The Dash mobile app allows customers to review orders and remove items which are unwanted or perhaps were ordered by accident. If orders are reviewed in this manner, approved items flow back into the system to eventually go through the ecommerce process.
The Client Tier, while quite intriguing, is actually relatively straightforward. The buttons, wands, and appliances are all transaction devices that communicate single item orders which can be transmitted in small packets and submitted to the Dash Kinesis service.
By contrast, the Event Tier functionality is sophisticated and relatively complex; moreover, I believe it takes advantage of a number of innovative AWS services.
As previously stated, order events are submitted to the Dash Kinesis service. Kinesis is designed to consume vast numbers of events in real-time. It does not, however, do much of anything with those events (it stores them for 24 hours, then discards those that remain in the service).
Kinesis streams (as the event recipients are known) allow programs to be attached to the stream; these programs perform operations upon the events to allow them to be processed. AWS recommends that these programs be simple, with little actual processing; instead, the event information should be extracted and then passed along to another AWS service, which can operate upon the events in a less time-bound manner than the real-time constraints within Kinesis.
Common techniques associated with additional processing include placing the event information into an SQS queue or storing the information in DynamoDB.
I believe the latter technique is what the Event Tier does, as indicated by Number 2 in the Figure. As the program attached to the Kinesis stream receives each order event, it stores it in DynamoDB; for those order events which have voice files associated with them, the DynamoDB record contains a pointer to the S3 bucket that holds the voice file.
At the November AWS re:Invent conference, Amazon announced a new service called Lambda. Lambda allows code segments to be attached to certain AWS services, with the code segment executed when a state change occurs in the AWS service. One of the AWS services which can be so configured with Lambda code segments is DynamoDB.
In the Dash service, when an order event is extracted from Kinesis, it is inserted into DynamoDB. In turn, that state change of insertion calls a Lambda code segment, which extracts an associated voice file (if submitted via a Dash wand voice command) and then calls into the Dash Application Tier for order filtering and processing.
In addition to extracting the orders from DynamoDB and submitting them to the Application Tier, the order events are placed into an AWS EMR system to facilitate Dash analytics.
While this description seems simple, the reality is anything but. In fact, in my opinion. the Event Tier is the heart of the Dash service. Most people underestimate the complexity of dealing with events in real-time. In the case of Dash, this is easy to do. First, it must be understood that the offering as it stands today, is only the beginning. Dash clients can reside in any number of devices -- buttons are only the start, as the client could be placed in any number of things, including product packaging, storage containers (e.g., pantries), and so on.
Moreover, the magnitude of the Dash service is easy to underestimate, as are all IoT applications. Eventually, Dash could be processing tens of millions of events each day. While the service certainly doesn’t do anywhere near that volume now, Amazon had to architect the system so that it could accommodate that sort of future load.
It certainly helps that Amazon was able to rely on existing highly scalable services like DynamoDB and EMR (and, indeed, Kinesis). Nevertheless, it had to validate functionality and performance at levels that might only be reached in several years; undoubtedly, Amazon ran load and stress tests submitting huge loads to ensure acceptable performance in the future.
Dash Application Tier
The Application Tier is where the service’s logical operations are performed. One of the key operations is to filter submitted events. It is possible that multiple orders could be accidentally submitted via a Dash client (e.g., by a delighted toddler fascinated by pressing a colorful Dash button); obviously, if someone were to receive 20 (or 200!) orders of Tide, that would reduce the value of the service and cause people to terminate its use. Since part of the motivation for rolling out the Dash service is to allow Amazon to develop new competitive mechanisms against companies like Walmart, anything that might reduce user satisfaction has to be avoided.
This is why the Dash service automatically rejects multiple orders. Moreover, it won’t accept even a single order if another order is already in process with the product not yet delivered to the customer. Consequently, the Dash application has to filter events to remove duplicate or premature orders.
The simplest way to accomplish this is to allow the Dash client to submit multiple orders and remove them at the back end. It is likely that the Dash application accomplishes this by inspecting every event submitted and discarding inappropriate ones.
From a technical perspective, I expect that Amazon uses the new AWS Lambda service, which allows code fragments to be attached to certain AWS services and have that code executed when a state change occurs in the service. Dash most likely attaches Lambda event filtering code to the Dash DynamoDB storage system. Every event that is inserted into it by the Kinesis event service is inspected for validity and inappropriate Dash orders are removed from DynamoDB. This filtering process is represented by the number 3 in the Figure above.
Valid orders are left in DynamoDB for a period of time so that, should the customer wish to delete one, it is possible to do so via the Dash Mobile App, represented by the number 4 in the Figure.
Once an appropriate period of time has passed, making it likely that the customers actually did want to order the product, the Dash application Order Processing takes place, pulling transactions from the Dash DynamoDB and submitting them (number 7 in the Figure) to the Amazon ecommerce engine, which then executes standard order processing and shipment, eventually resulting in the customer receiving the product.
The Application Tier is also where the Dash analytics are leveraged to share information with Dash partners -- the product companies whose goods are ordered via Dash. As my earlier piece discussed, the importance of these analytics should not be underestimated. Dash can provide Dash product partners with enormous insight about buyer behavior, which is tremendously valuable for their businesses. Knowing that products are, say, more frequently ordered mid-week rather than the weekend provides a lot of knowledge that can be used in product planning and promotion. To this point, Dash analytics have barely been mentioned, but you can bet that we’ll hear a lot more about them in the future.
In the Figure, the ecommerce Tier is deceptively simple. All that resides there is Amazon. Make no mistake, the Amazon ecommerce capability is at once more complex and yet simpler in terms of the Dash application.
Amazon’s ecommerce system is, perhaps, the most sophisticated online sales system extant. Amazon’s ecommerce operation is a finely-tuned amalgam of supply chain coordination, software development and operation, retail purchasing and promotion, not to mention human resource management.
From the Dash perspective, however, that can all be a black box. The Dash application needs know nothing about any of those capabilities; all it needs to do is, once it recognizes that it is time to submit an order, is to call an API with a small amount of information -- product, customer name, and, perhaps order date and time. Amazon ecommerce takes care of the rest.
Amazon Dash represents the future of Third Platform applications. It leverages extremely capable infrastructure and services and welds them together with application-specific functionality. For companies wishing to become Third Platform organizations, the message is clear:
- Identify your opportunity,
- Define the application to address it,
- Design the application to leverage existing services that are available to reduce development effort and accelerate rollout,
- Create a new offering that delivers distinctive differentiation compared to competitors in the market.
Our Stackato PaaS product is designed to address these situations perfectly -- our product motto is “enabling the future of applications.” Stackato is the perfect tool to implement the Dash-specific functionality -- the systems that reside in the Dash Application tier.
No matter what kind of company you are, you must be on the lookout for opportunities to create new offerings that leverage the Third Platform. Doing nothing is not an option; worse, it’s a recipe for obsolescence and failure.
In my next blog post, I’ll discuss the Dash application and the lessons it holds for a company seeking to avoid the “obsolescence and failure” path. I’ll talk about what steps you should take to create a Dash-like offering, and how you can ensure you stay on the right path and avoid straying into unsuccessful detours. In the meantime, if you haven’t taken the time to learn about the Stackato vision, watch the video here.