Yewes - Business Consulting | IT Services | Outsourcing

Case Studies

By every passing decade, industries strategize and mechanize to multiply production. These rampant growth requirements of the industries have opened up doors to smart and innovative technological solutions. Information technology has played a pivotal role in revolutionizing business processes. And this time the challenge comes in from the ‘Design n Print’ Industry.

Requirement Brief

To make it possible with ease, for product (print related) owners to put together or create a design for their product that can be sent over for print.

To create a software solution for product owners to create print ready designs for their products.

Product owners would generally have no skills on designing tools like adobe photoshop, coraldraw, adobe illustrator or adobe inDesign.

Conventional Method

Solution Considerations

SC01 - To implement software as a service (SAAS)

SC02 - To maintain pixel quality of print ready design

SC03 - To generate high resolution print ready design proofs

SC04 - To provide highly interactive web user interface

SC05 - To maintain user created designs and artworks

SC06 - To provide very quick response to user requests from the user interface

Solution per Consideration

SC01 - To implement software as a service (SAAS)

SC05 - To maintain user created designs and artworks

SC06 - To provide very quick response to user requests from the user interface

System Infrastructure

The implementation of the server components will be using EC2 server instances. There will be N application servers with access to a file share via a private NTFS file share to the Dynamic data (if any) will be stored on an EBS device. Application server instances will communicate with a single file server instance. The file server contents will be backed up to S3 asynchronously on a yet to be determined frequency. It is not believed that eventual consistency affects this design because it is using a single data store not distributed shared memory. S3 is simply the backup device from a snapshot of the EBS data store not the persistence layer for the data store.

Create two AMIs for EC2 servers: One(call it primary EC2 server) would behave as a central data store as well as load balancer for customer requests, while other servers(call then secondary EC2 servers) would behave as application node where actual code instances would be residing. Primary EC2 servers will be responsible for request routing and balancing them (requests) across the available secondary EC2 servers. To make the primary EC2 server behave as a central data store, an EBS would be connected to the primary EC2 server. All the secondary EC2 servers would be accessing this EBS through shared network drive i.e. the primary server with the secondary servers would be forming a network which would eventually render the local EBS(Drive) of primary EC2 server available for access from secondary sever code instances.

System Infrastructure Alternatives

The infrastructure specified above will satisfy the high availability requirements of the system and that deployment infrastructure is what we are developing towards. However, there are alternative deployment scenarios that we can potentially employ that may save cost but at the expense of less availability or other things.

Use One Instance of EBS vs. Two Instances of EBS
We can potentially use one EBS for storage to serve the Fileserver and the Backup Fileserver. Currently, the two EBS instance will be synchronized by DFS (Distributed File System) so that if the primary Fileserver fails, the backup Fileserver can take over immediately.

Pros:
Save cost on having only one instance of EBS vs. two.

Cons:
If we only have one, we will need to build a component to unmount the EBS from primary Fileserver and mount it to the Backup Fileserver. We would need to explore how much time it would take for such a process will take. Detect to see if an EBS is still mounted to primary. If so, but the server is down, how can we unmount it. Then, mount it onto the Backup Fileserver and re-establish mapping to the rest of the system.

Not Cluster the Database
If we store the database files (MDF/LDF) in the EBS, then we potentially do not need to SQL Server clustering and can do away with SQL Server Standard edition. The strategy here is that if primary Fileserver goes down, SQL Server engine in primary Fileserver would detach itself from the database files that reside in EBS. When the Backup Fileserver takes over, the SQL Server engine there would attach to the database files that are in EBS.

Pros:
Save licensing cost by deploying SQL Server Standard or lower, vs. SQL Server Pro or Enterprise.

Cons:
Would need to build a component to detect, determine state of database and attaching the database to Backup Fileserver if primary Fileserver failed. Since the database files reside in EBS, we do not know what happens if EBS goes down but the EC2 instance with SQL Server still running. We’ll explore how we can recover from that gracefully and make sure that such a scenario does not corrupt the database.

Use XML Files as a Database
Using XML files as a database will eliminate the need for database servers.

Pros:
Save database licensing costs.

Cons:
The cons to using a filebase data store are: slower performance, greater chance of data corruption, more difficult to query data when trouble-shooting. Lastly, potential lock issues since all writes must be single threaded.

SC02 - To maintain pixel quality of print ready design

SC03 - To generate high resolution print ready design proofs

In Design Server

SC04 - To provide highly interactive web user interface

1. Cross Browser Compatibility

2. Open Source SDK

3. Strong Community Help

4. Adobe Technology

Feedback