Dress4Win is a web-based company that helps their users organize and manage their personal wardrobe using a website and mobile application. The company also cultivates an active social network that connects their users with designers and retailers. They monetize their services through advertising, eCommerce referrals, and a freemium app model. Dress4Win is going to try Cloud solutions using three tests to provide proof of concept. The development processes, testing processes, and disaster recovery are their first three experiments with cloud computing. So, each of these are infrastructure and development pieces of their environment. If these solutions work well, they'll have confidence to consider migrating parts of their application to the Cloud. Dress4Win provides a wardrobe management service via a web UI and mobile app. They use social networking to identify style trends and adjust their recommendations. For example, if people are sharing images wearing acid washed jeans and there are favorable comments, then acid washed jeans will become more popular in the recommendation engine. The application is free to users. The monetization model is to sell ads to directly sell products through the interface and to provide referrals to other sites and services. Since inception, the system has grown from 10 servers to 100 servers. The company has actually committed to Cloud adoption. They just want a gradual approach. So, phase one is DevTest and DR, and phase two will be the application services and recommendation engine. Immediately, they need capacity for growth. They need to fit the cloud migration activity into the current cycle, so they don't have to buy additional hardware for their data center. Immediate business goals are lower IT overhead through the use of managed services while meeting growth requirements and managing cost. The company has predicted it will see an immediate expense for moving into Cloud, and then a gradual reduction in cost over five years which will save 30 percent to 50 percent. So, the move to Cloud will eventually pay for itself. Dress4Win will migrate in phases. Phase one will be DevTest and disaster recovery. Future migration will be dependent on phase one. Disaster recovery and high availability will be considerations. We will migrate the least critical software components first. The plan is to reduce operation costs by moving towards more of a DevOps model. The development and test process should increase the velocity of product and feature releases. They plan to use a CICD approach. The existing environment uses MySQL to keep user data and other application data. The social graph recommendation engine is using Redis. There are a number of application servers running TomCat with a micro-services design, and it uses NGINX to serve up static content. The Apache Beam is running the batch processing for recommendations. There are a lot of details in the case study covering storage and compute capacity for a range of use cases. Here are some technical watch points: They have static or infrequently changing data stored in a relational database. They're using high-speed in-memory caching database for some parts of the application. So, micro-services architecture, that should start you thinking about what kind of compute services on Google Cloud could support a micro-services design. They're already using VMs in the data center, so, lift and shift should be an option. If we lift and shift the compute service directly to VMs and Compute Engine, we'll need a multi-region approach because the customers are global. Their application uses multiple kinds of storage in the data center, and some of these will need to be mapped to services in Google Cloud to support all the requirements. Data analysis and trending are run on Hadoop and Spark pipelines. That probably means offline batch processing for the social graph, and analytics are run on the same platform, so we're looking mainly at batch processing and not streaming. What's a direct managed service solution for Hadoop and Spark? Right, Cloud Dataproc. They're using some message Q services. This is implemented in the data center as an MQ service running on individual servers. We need to see when it might make sense to migrate this to Cloud Pub Sub. They have some security concerns. We'll need to have the discussion about the kinds of security and encryption services that are built into the Google Cloud platform. Then we can look at additional security services if those are not sufficient. It looks like they might want some auditing capabilities so they can understand and manage security. And, for a Continuous Integration and Continuous Delivery, CICD, they can use Jenkins open source software. So, let's be clear about this. The disaster recovery objective is really about building an entire solution. It kind of encompasses the whole migration to Cloud, because we want to bring everything back if the data centers go down. The development and test environments are going to create and update software and data that works with current production and also with disaster recovery. So, this whole activity is almost like a dress rehearsal for phase two, for full migration to the cloud. Take some time to come up with your solution, and then when you've got your solution, you can compare it with the sample solution.
