Cloud adoption and business modernization
Hearst is a leading global, diversified media, information, and services company with more than 360 businesses. Founded by William Randolph Hearst as an owner of newspapers, the company’s holdings now include a wide variety of media including newspapers, magazines, television channels and television stations, including the San Francisco Chronicle, the Houston Chronical, Cosmopolitan and Esquire.
Hearst’s previous partner was not meeting the requirements necessary to help Hearst increase their cloud adoption and to help modernize their business. They required greater governance and visibility into their cloud assets and resources to make better decisions
We helped them establish cloud frameworks for governance to ensure resources are properly utilized and environments are secure with the visibility for management to make informed decisions.
Hearst’s business benefits from tightening cloud governance will protect the company from unwarranted costs and security risks as they scale their cloud services. With additional visibility into their cloud resources through their current tool set, Hearst has the ability to help the business units innovate while protecting them from unnecessary threats.
Modernize and migrate a legacy MAM/CMS application to take advantage of cloud native services for the Hearst UK division & make it more generally available for the rest of the organization outside of the UK.
Due to both being deployed on-premise as well as within a geographic region that did not provide low latency access to the rest of the larger organization, the application was not able to perform it’s intended function as a media asset management & content management solution for all use cases. By locating it in AWS on Amazon EC2, we were able to provide a central location from which various areas of the business could access with low latency tools or workflow(s).
An AWS Premier Partner, Ollion, worked with Hearst UK division and the application vendor, Censhare, to assess the application’s architecture documentation, including recommended AWS architecture design and requirements for networking, storage, HA, DR, security, and governance.
Knowing that the intended use for Censhare would scale up once deployed in AWS, much thought and consideration was given to the underlying architecture hosting the application with specific attention given to network IOPS as well as storage IOPS.
How AWS was part of the solution
The on-premises workflow involved Censhare exporting static files via a Network File Share (NFS) which were imported into the next phase of the workflow, OneVision, via SMB. On-premises, an Isilon network-attached storage array exposed a common filesystem via both a Network File Share (NFS) and a Server Message Block (SMB).
Neither Amazon Elastic File Share Service (EFS) (a Network File Share) or AWS FSx mimic this dual functionality. In AWS, storage was split between 2 services: Amazon S3 for asset storage, and an Amazon FSx for Windows Server Message Block (SMB) share is used for hotfolders & scratch space.
Amazon Elastic Block Store Service (EBS) volumes are used for all block level storage for application servers, with default Amazon Elastic Block Store Service (EBS) encryption enabled.
The primary database platform for the Censhare application is Oracle Server. In the AWS environment, Amazon Relational Database Service (RDS) is used. Amazon Relational Database Service (RDS) has the benefit of being a managed service eliminating any operational footprint.
Successful completion of the project provided Hearst with the necessary cloud natives application performance, quality of service, and optimized cost efficiency for their Censhare DAM/CMS application.
There was also a significant reduction in latency for end users to check assets in or out of Amazon S3 backed storage and into hotfolders VS the on-premise Isilon backed solution. This enabled adjustments to be made to the underlying edit, post & final workflow(s) that leveraged this MAM/CMS for assets and enabled some editors to make use of AWS workspaces or Amazon EC2 VS high-end desktop hardware to use their toolsets (premier, resolve, photoshop).
Considerable amounts of time were spent to find configuration information or install documentation off their knowledge base. Their knowledge base is designed for more standard installations which Hearst engineers have made non-standard and highly customized. This requires more effort from the Censhare team and caused confusion for the Ollion team thus requiring more engineering time to troubleshoot the application install process.
Additionally, the Censhare application direction is starting to move to a Kubernetes development platform. Soon they will have a new release of their software. This will create some redundant effort in the automation of deploying Censhare on Amazon EC2, while some will be re-usable in Kubernetes should that be the direction that Censhare goes.
The check-in/check-out CMS design of Censhare limits the size and type of assets that you can manage with it for certain workflows. For things like high bitrate HD & UHD video, there are much better solutions that do not require check-out of an entire asset but can stream individual blocks to the end user. A reevaluation of the marketplace offerings would be good practice for Hearst now.