Synaptics manufactures the majority of touchpad devices shipped on laptop computers, and the related drivers.
The company has hundreds of patents related to touchpad technology, including gesturing on the touchpad.
A Synaptics executive learned about Leszynski Group's invention of inDirect®, a gesture-based application
launcher for tablet computers. inDirect was similar to a utility under development at Synaptics called Scrybe, so
Synaptics decided to work with us to help them complete the Scrybe application and to create a web farm in the
cloud to distribute the software.
Figure 1 in the image carousel below shows the Scrybe utility in action.
Leszynski Group determined that it would be less expensive to create a web farm for Scrybe using the Amazon Web Services (AWS) cloud
than to use Synaptics' existing internet infrastructure and bandwidth. We also targeted AWS because of the rapid
scalability it provides, which would allow us to dynamically ramp-up the web farm as user traffic increases, especially for
traffic spikes related to product update releases.
We designed the web farm around the following primary components:
- Apache web servers running on Linux to deliver the web pages for UScrybe.com.
- Apache Tomcat servlets running web services to receive usage information and update requests from users' computers running Scrybe.
- Amazon S3 virtual storage to host drivers for each of Synaptics' OEM (computer manufacturer) partners.
- MySQL databases running in the Amazon Relational Database Service (RDS), to host a data library that supports
driver installation and stores usage data sent by users.
- A reporting engine to provide data to executive sponsors.
- A monitoring and scaling system to watch and maintain the health and throughput of the web farm.
First, Leszynski Group had to help Synaptics complete the Scrybe software product, written in C. Our developers contributed
technical guidance and coding cycles to this effort. To support cross-team collaboration on the project between
Synaptics and our engineers, we mentored Synaptics to set up its first cloud-based development environment, which included:
- A source control system using hosted Subversion.
- A cross-team task and issue management system using hosted Unfuddle.
- A customized cross-team build engine running in the web farm.
- A complete build and test workflow on the web farm using separate Development, Test, Staging, and Production environments.
Next, we designed and coded an installation package to deploy Scrybe and its matching driver on end users' computers.
Synaptics' driver library includes more than 50 OEM-specific drivers, and before installing Scrybe on a laptop, the appropriate driver
must first be identified and installed. To solve this problem, we designed a detection utility and installation workflow that executes as follows:
- The user clicks a 'Download Scrybe' link on the website.
- A bootstrapper executable downloads and runs on the user's laptop. This utility, dubbed the 'Driver Detective',
queries the user's computer for information from the Registry and other locations, and sends this information to a service endpoint on the web farm.
- Using the provided information, the web farm database logic determines the appropriate Scrybe installation package and returns the S3 setup file URL to the bootstrapper.
- The bootstrapper downloads the designated installer from the web farm and runs the customized InstallShield setup program to deploy the targeted driver and Scrybe.
Figure 2 in the image carousel below shows the data flow for the Driver Detective component.
Based on our experience working on software update engines, including early versions of Windows Update at Microsoft, Leszynski Group defined
and coded an auto-update model for the Scrybe software. We created and included in the Scrybe installer a Windows Service that checks
the web farm weekly to determine if the user's software version is current and, if not, it automatically downloads and runs an updated installer.
We coded the update service to randomize the day and time for update checks to smooth the load on the web services.
Our auto-updater also programmatically controls which web farm any given Scrybe user communicates with during the weekly handshake,
allowing us to geographically distribute the update check load to web farms at different data centers around the globe.
Collecting and Analyzing Data
Deploying an update service to users' computers provided Synaptics with a great opportunity to instrument the Scrybe utility to capture
and analyze usage patterns.
Because we have a wealth of experience with creating instrumented software for collecting data, Leszynski Group suggested the inclusion of a data
collection mechanism in the service.
First, we coded a logging mechanism within Scrybe to anonymously record in XML each user's option settings and customizations of the gesture launcher.
Next, to collect the XML data in cloud databases, we attached it to the weekly call to the update service.
This model allows for the collection of tens of millions of usage records for analysis by Synaptics about how their customers engaged with the software.
A third challenge was to address scalability issues.
The web farm had to be able to scale quickly for loads resulting from marketing campaigns by Synaptics or its OEM partners, and for the download bursts
of the initial launch and future major releases.
We solved this problem by ensuring that there were no bottlenecks in our web farm implementation of Amazon Machine Image (AMI) deployments.
We coded the web farm to use the AWS Auto-Scaling service, which enables applications to specify how to scale up or down to handle changes in traffic.
This model allows us to automatically add and subtract running AMIs from the web farm, ranging from five to a dozen servers and back down again with no human intervention.
Further, we scaled our database by sharding (spreading the data across multiple servers) and storing it in geographically distributed RDS instances.
Our fourth design goal was high availability.
For this, we actively monitored the servers in the web farm, configuring the load balancer to disable any instance that was not responsive and
to quickly start up another one in its place.
We also enabled real-time replication of our databases across different datacenters.
By creating a multi-step, automated deployment utility, we ensured that the web services were always available, even during the deployment of application updates.
Finally, Leszynski Group created the uScrybe.com website, with support for multiple languages, where users learn about and download Scrybe.
The website, the databases, the AMIs, and all other cloud assets were replicated to two different AWS locations to provide failover.
Figure 3 in the image carousel below shows the uScrybe.com home page.
The Scrybe web farm delivered all the expected value to Synaptics.
In just nine months, Leszynski Group's seasoned team created a complex utility and its web farm in the cloud by providing the
experienced design, development, management, and testing resources required.
The use of the AWS cloud provided a huge cost advantage over Synaptics' internal Oracle-based infrastructure and private bandwidth.
The website and services correctly auto-scaled to support initial launch traffic of a million visitors, and then scaled back down
as the load decreased to reduce costs and maximize ROI.
Our scaling model ensured that Synaptics only paid for actual usage of data, bandwidth and CPU,
and would not pay in advance for projected usage.
Also, stress tests determined that the web farm we built would be able to handle over a hundred million Scrybe users and still
achieve the targeted performance goals.
In 2011, Amazon experienced its most famous outage, where the Virginia datacenter was down for nearly a day
and sites like Reddit and Foursquare went dark during that time.
Although we were hosting an instance of the Synaptics web farm in that datacenter, because of our distributed
web services and 100% real-time replication model, the failover locations immediately picked up the additional load,
and our system experienced zero downtime or data loss during the outage.
Figure 4 in the image carousel below shows the AWS architecture for the web farm.