I know exactly where I am, but I’m not sure where I’m going. How critical is my technology architecture?
While the business problems vary widely, in today’s rapidly changing technology climate, there is a common need for business agility. Adapt or die.
The Media and Entertainment market is no exception. Customer demands for MORE have led to the emergence of Netflix, Hulu and Amazon, forcing change in how companies conduct business. Add in the proliferation of cloud infrastructure, artificial intelligence/machine learning with the open source first mindset, and there’s a lot going on. With all the change, how does a company or vendor solve the problems in front of them but remain agile to respond to market forces?
A Little History
Prior to 2006, Media companies stored and moved much of their content using tapes and hard drives. Shipping companies like FedEx, DHL, UPS had tremendous businesses moving the world’s media content. Things changed dramatically in 2006 with the conversion to file-based delivery. The content was moved over the WAN (public or private) between private data centers within the same company or between business partners e.g. studios, post production, aggregation and distribution.
FTP was the method of choice for WAN file movement. However, network latency coupled with file sizes made the transfers often unreliable and slow. In 2007/2008, a few companies including Aspera and Signiant began to deliver accelerated transfers solutions to solve the FTP issues.
Media technologies and workflows in these data centers were often unique to each company or organization. This worked well for a while, but the deployment and support for these bespoke implementations were complicated, not re-usable and expensive. In spite of the drawbacks, bespoke workflows continued to gain momentum.
Early Cloud Hype
Sometime around 2012/2013, public cloud vendors burst on to the scene. The Cloud would be the panacea. Theoretically, I could do things faster while saving money by closing some of my data centers. Not so fast. There were many unanswered questions:
Security - Will my content be secure? Who has access?
Uptime - What about my 99.9999% SLA requirements?
Cost – Will it be expensive?
Cloud Choices– Amazon or Azure? Do they understand my business?
What happens to my workflows? Can my custom and commercial applications that were deployed in my data center run in the cloud?
The Cloud has layers, and early business concerns cut across all of them:
Infrastructure as a Service (IaaS) – I need reliable, fast servers with a lot of memory.
Platform as a Service (PaaS) – My business requires redundancy, and the ability to load balance and scale to more servers.
Software as a Service (SaaS) – I need the software I have been using for 5 years to just run in the cloud.
Early Cloud Reality: Lift and Shift
The early cloud implementations were almost all done by simply moving on-premise workflows to the cloud, which meant opening new data centers to run legacy workflows. They were almost identical to the private datacenter only they ran in Amazon.
This approach actually made sense at the time because the public cloud vendors (Amazon and Microsoft) had the platform and infrastructure services, but the services were limited. They weren’t full featured and required a fair bit of custom code.
Many software vendors who claimed to be SaaS were really just allowing their enterprise software to run in the cloud and the pricing was changed to subscription. This was the fastest way to market a “cloud” solution. They were deployed as single tenant, which made them very expensive. Eventually, the industry began calling this practice “lift and shift” or “cloud washed,” since it was taking advantage of some cloud benefits but certainly not all.
The SDN vendors were the real pioneers
The Software Defined Networking (SDN) market worked though some challenges around standards and APIs, and began successfully deploying 9-10 years ago. The overall approach of SDN was to separate the control plane from the data plane, which had many benefits including flexibility, scale, speed, and interoperability. The Open Source movement and cloud each contributed key factors in some of the decisions around SDN.
How to Really Cloud
Although many vendors still support and implement the “lift and shift” or “cloud washed” approach in 2019, it’s not necessary or even practical anymore. It’s too expensive, rigid, difficult to support and very custom. Cloud services have come a long way, and many of the top software vendors have built their applications from the ground up in order to take advantages of more advanced cloud services.
The current way to develop cloud software started around 2013, but even then the services were limited. There were a very small number of true SaaS vendors who were forced to write some of the code to augment the PaaS provided by the public cloud vendors. Many of these vendors were new entrants to the market with very few customers. Others had customer footprints and redesigned their product from the ground up to be cloud native. Sometime between 2016-2017, public cloud vendors really enhanced the Platform services, enabling enterprise SaaS vendors to accelerate their product development.
Today, the Media industry can learn from some of our pioneers in the networking space. Security, usability, scalability and flexibility are available at costs un-imaginable 5-10 years ago. Approaches using single or multiple clouds working in concert with enterprise assets — regardless of storage, network or location — provide the flexibility needed for business agility. For content or data-centric organizations, this SDCX (software-defined content exchange) or “SDCX like” architecture provides foundational technology attributes required to enable an agile business model.
Ultimately, the SDCX model prevents lock in, giving businesses the freedom to choose where to go next based on an agile understanding of where they are now.