In the previous Cloud Broadcasting article, we took a very brief look at cloud security and its advantages over traditional datacentre systems. In this article, we delve further into Cloud Born systems and investigate the new requirements for software development and upgrades in broadcast software services.
Software development has progressed in leaps and bounds over the past few years to become a respected professional discipline. The processes and structures around programming are much better defined and implemented to give stable reliable services.
Low Level Software is Efficient
Twenty or thirty years ago, developers would write in low level languages such as assembly or C, and their mindset was heavily tied to the underlying hardware and operating system.
Low level software development has its advantages, it’s very efficient in terms of execution speeds, memory and disk space use. A program coded in assembly language or even C will execute much faster than today’s offerings of Node-JS or Java. However, they’re incredibly difficult to code, maintain and the resulting executable code is tied to a specific processor family such as Intel’s x86.
Holy Grail of Development
High level languages such as Java and Node-JS abstract the hardware and operating systems away from the developer and with their vast libraries are easier to program, they are slower than low level languages but the speed of processor and memory resource now available significantly outweighs the hit on performance.
The holy grail of software development is re-usable code, that is code that has already been used in another program – the code is more reliable as it’s proved it already works, and it doesn’t need to be re-written. Although code re-use is technically possible in low level languages, it becomes easier as we move to higher level languages. Code is compiled into libraries and is built by in house teams, or bought from third party providers, thus reducing development times even further.
The two samples of code both print "Hello, World!" to the screen, the low level assembly code on the left is significantly more complicated than the high level Java code on the right.
Re-usable code reduces the risk in software development, and as a library has proved its worth it can be used again with confidence.
Unknowns Kill Delivery Times
Software development was traditionally provided using waterfall methods of project management, the whole project would be scoped out, planned and designed before a single line of code was written. The process was slow and the specification would usually be out of date before coding started.
Complexities and unknowns in a system make development times notoriously difficult to predict, especially on big projects and infrastructures. Waterfall methods of project management make the problem worse as they don’t adequately consider the risks, and a project can often over-run in its first week of execution.
Agile is Lightweight
Agile software development was devised by a group of 17 developers who met in 2001 in Utah to design a system to overcome the short comings of waterfall project management. The Manifesto of Agile Software Development resulted, a document to encourage lightweight development. The manifesto promoted people interaction amongst software teams and users, focused on well written working software instead of pages of documentation, and would respond to user-change quickly and efficiently.
Agile delivers functions that are tested quickly, and prioritizes new features as the demand of the users change. This is a very important change in the mindset of software delivery, for developers, end users and business owners.
Development of functions is split into small time periods, referred to as “sprints” that usually last two weeks. At the end of a sprint the development team will have provided a function that can be released into the market place and made available to the end user. Feedback is quickly gathered, bugs identified and the impact on the business assessed.
The process of releasing code involves moving the release to an intermediary staging server so final tests can be performed before the code is made live.
One of the most important aspects of Agile is the connection between the development teams and the business users. With the waterfall method, the project manager would give weekly updates to the management team advising of the progress of development, a process that could go on for many months or even years without any code being demonstrated. When the release date finally happened, the code was often met with mixed reviews as many of the delivered features were either misunderstood, miscommunicated or just out of date.
Minimum Viable Product
Using Agile, a new software design will start with a list of required functions and then prioritized with product managers and business owners. The initial functions would be developed with the intention of providing a minimum viable product (MVP), this is the release that provides the minimum number of functions for the software to be useful. The program is tested within a matter of weeks and feedback quickly gathered.
During the life cycle of the product, many stake holders will have a view on which features take priority and which are the most important. Sales people, support engineers and development managers have all tried to change the course of a development team in the past to get a feature implemented which they think is a priority, often with disastrous consequences and annihilating release dates. With Agile, anybody requiring a change must create a user-story, a simple short specification of their feature and put it in the product-backlog.
Pre-Testing with Staging Servers
At planning meetings, product and development managers, and business owners will meet and evaluate the backlog to agree the priority of the next functions to be developed and released. Due to the dynamically changing business demands functions that have been a priority in the past can be moved to the back of the queue, a frustrating outcome for some stake holders, but a massive bonus for business owners who can look at the bigger picture and determine the best outcome for the whole business.
New functions are released to a staging server, a near-copy of the live service for pre-production testing. Once the test vectors have passed the software is pushed to the production servers and made live. Prior to Agile, software releases were very irregular, maybe six or twelve months apart, causing all kinds of stress and instability to the system. Releasing software every two weeks makes the whole system much more stable and reliable, and if a release proves to be buggy or problematic it can be easily rolled back.
Cloud computing benefits greatly from high-level language coding and Agile development, and collaboration is a key concept amongst developers and end users. Agile development enhances the cloud ethos of fast time to market and reacting quickly to customer demands.
You might also like...
The broadcast equipment industry is in the process of making the transition to IP based transport for video, audio and data. This has led to development of a suite of standards including SMPTE ST 2022-6 for encapsulation of uncompressed SDI…
Troubleshooting IP-centric technologies can be a new challenge for engineers. Often it becomes a case of “You don’t know—what you don’t know,” until it is too late. In addition, once the engineer knows there is a problem,…
As broadcasting moves to highly efficient production lines of the future, understanding business needs is key for engineers, and recognizing the commercial motivations of CEOs and business owners is crucial to building a successful media platform.
Broadcast engineers have a whole plethora of tools available in their kit-bag to integrate systems. The common denominators are SDI, AES and MADI for media exchange, serial and ethernet protocols for control, and the trusted GPI should everything else fail.
Unless you are a greenfield site, have one vendor to meet all your operational and creative needs, or are incredibly lucky, you will at some point need to integrate your Cloud Software-as-a-Service into the broadcast workflows. This is much easier…