Case Study: 4 - Dress4Win case study Company Overview Dress4win is a web-based company that helps their users organize and manage their personal wardrobe using a website and mobile application. The co

Case Study: 4 - Dress4Win case study Company Overview 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, e-commerce, referrals, and a freemium app model. Company Background Dress4win's application has grown from a few servers in the founder's garage to several hundred servers and appliances in a colocated data center. However, the capacity of their infrastructure is now insufficient for the application's rapid growth. Because of this growth and the company's desire to innovate faster, Dress4win is committing to a full migration to a public cloud. Solution Concept For the first phase of their migration to the cloud, Dress4win is considering moving their development and test environments. They are also considering building a disaster recovery site, because their current infrastructure is at a single location. They are not sure which components of their architecture they can migrate as is and which components they need to change before migrating them. Existing Technical Environment The Dress4win application is served out of a single data center location. Databases: MySQL - user data, inventory, static data Redis - metadata, social graph, caching Application servers: Tomcat - Java micro-services Nginx - static content Apache Beam - Batch processing Storage appliances: iSCSI for VM hosts Fiber channel SAN - MySQL databases NAS - image storage, logs, backups Apache Hadoop/Spark servers: Data analysis Real-time trending calculations MQ servers: Messaging Social notifications Events Miscellaneous servers: Jenkins, monitoring, bastion hosts, security scanners Business Requirements Build a reliable and reproducible environment with scaled parity of production. Improve security by defining and adhering to a set of security and Identity and Access Management (IAM) best practices for cloud. Improve business agility and speed of innovation through rapid provisioning of new resources. Analyze and optimize architecture for performance in the cloud. Migrate fully to the cloud if all other requirements are met. Technical Requirements Evaluate and choose an automation framework for provisioning resources in cloud. Support failover of the production environment to cloud during an emergency. Identify production services that can migrate to cloud to save capacity. Use managed services whenever possible. Encrypt data on the wire and at rest. Support multiple VPN connections between the production data center and cloud environment. CEO Statement Our investors are concerned about our ability to scale and contain costs with our current infrastructure. They are also concerned that a new competitor could use a public cloud platform to offset their up-front investment and freeing them to focus on developing better features. CTO Statement We have invested heavily in the current infrastructure, but much of the equipment is approaching the end of its useful life. We are consistently waiting weeks for new gear to be racked before we can start new projects. Our traffic patterns are highest in the mornings and weekend evenings; during other times, 80% of our capacity is sitting idle. CFO Statement Our capital expenditure is now exceeding our quarterly projections. Migrating to the cloud will likely cause an initial increase in spending, but we expect to fully transition before our next hardware refresh cycle. Our total cost of ownership (TCO) analysis over the next 5 years puts a cloud strategy between 30 to 50% lower than our current model. For this question, refer to the Dress4Win case study. As part of Dress4Win's plans to migrate to the cloud, they want to be able to set up a managed logging and monitoring system so they can handle spikes in their traffic load. They want to ensure that: - The infrastructure can be notified when it needs to scale up and down to handle the ebb and flow of usage throughout the day - Their administrators are notified automatically when their application reports errors. - They can filter their aggregated logs down in order to debug one piece of the application across many hosts Which Google StackDriver features should they use?