When you have a full ideal schematic model in place, then it's time to think about production realities.
Not by any means a rule, but I like to think about design from four approaches:
- • Political - Manage disruptive change gently.
- • Success - Who defines success? What does success look like?
- • Constraints - Keep the worldview model in hand all the time.
- • Delivery - What are the key deliverables and when are they promised. No more than high-level milestones needed.
And always be prepared to throw away yesterday's “best idea ever” and replace it with today's “even better idea!”
Figure 9.1 CDN design template I have used on occasion.
Risk, Responsibility, and Reassurance
Make sure the client's expectations are pragmatic. IP is generally provided in a shared network environment, and its service is best effort. While SLAs may guarantee nine-nines availability, if that 2 seconds of annual outage happens in the middle of the 100 m final, then the rest of the uptime means nothing to the end users and client. Your clients have to understand that risk!
As the number of eyeballs consuming content from your distribution network grows, the heat from those 2 seconds of outage grows in the actual event of that failure happening.
As a CDN designer you need your clients to be judicious and to understand that risk, and that they cannot pass that ultimate liability on to you! So you must build trust, and ensure that they know you are aligned in reducing that risk, but that it is ultimately their risk, not yours.
However, rather than phrase it in those terms, ensure that the client is clear about what “good enough” will be from the outset, and put 80% of your effort into that, and only 20% into the nice-to-have extra features.
Only once you have a good enough system live, and a happy client, then you might consider starting to test new technologies in a DevOps fashion, constantly rolling out new features to small groups and expanding the availability of that new capability to larger actual audiences.
By evolving the system this way, you can quickly find the Heisenbugs that are almost impossible to find in any other form of testing. This type of pragmatic evolution of the design is a tricky concept to introduce to a traditional broadcaster. The benefit of virtualization is counterintuitive for those who have themselves evolved their legacy networks in a very different mode. But there is almost no doubt in my mind that it leads more quickly to a better deployment than any other model I have had first-hand witness to.
-  https://en.wikipedia.org/wiki/Heisenbug