Nine is Australia’s largest locally owned media company — covering television, digital publishing, and content production. Recently, Nine migrated from Mule 3 to Mule 4 to support its growing business demands and utilize the latest technologies available. By migrating, Nine improved its environment and increased the speed of its process that runs 19 million records every night from 1.5 hours to 8 minutes. Joseph Trachman, Technical Development Lead at Nine, shares his migration journey as well as how Nine prioritized various APIs and apps to minimize the disruption to customers.
At Nine, we have several systems that need to be integrated and used MuleSoft to achieve this. One of our major accomplishments using Mule 3 — and now Mule 4 — is the creation of the 9Galaxy Platform. This platform has the ability to trade against audience segments as well as utilizing cross-platform trading with broadcast video on demand. It has won an IT award and introduced a new concept of buying TV. Rather than buying specific ad slots in television shows, customers can now buy ad time based on audience which extends to both broadcast and digital viewing.
MuleSoft’s involvement in the 9Galaxy Platform
Within the 9Galaxy Platform, there are various systems that must work together to deliver on our mission of selling accurate, audience-based advertising inventory. From internal booking systems, campaign optimizers, and prediction models to third-party rating services and optimizing systems.
Each of these platforms are vital to the success of our award-winning 9Galaxy Platform — and to ensure its continued success, we need to ensure each has solid, reliable integrations. Thus, Nine decided that in order to continue providing a leading-edge platform for our customers, it was time to migrate from Mule 3 to Mule 4.
Why we decided to migrate to Mule 4
Our decision to migrate to Mule 4 came down to three things: a strategic approach to always staying up-to-date on the latest technology, DataWeave as a powerful data transformation language over our custom Groovy code, and the advanced monitoring capabilities that come with using Mule 4 — such as Anypoint Visualizer.
At Nine, we like to stay current with the latest technology — which allows us to be agile in today’s rapidly changing technology landscape. Compared to Mule 3, Mule 4 is a better performing runtime at scale. Previously, we would design our integrations to run in specific environments — and if those environments ever changed, the integrations would need to be changed too. When we moved to Mule 4, we had the opportunity to take advantage of the “build-once, run anywhere” methodology native to Mule 4. This allowed us to run the same Mule app across multiple environments without the need for drastic changes. We could have one global configuration and versioned local configurations where needed. This saved our developers significant time by making it faster to develop APIs.
DataWeave is one of the reasons we were looking forward to migrating to Mule 4. This tooling allowed us to begin removing one of the less maintainable parts of our Mule 3 codebase, which was the embedded groovy scripts. Groovy — as a part of the scripting component in Mule 3 — was used frequently to manipulate XML and JSON payloads and save the outputs into a Mule variable. However, the scripts themselves were difficult to debug and maintain as there was no easy way to test them locally. This required the use of online “playground” tools during development. Mule 4 no longer allows for scripts to output to Mule message variables or attributes and the improvements to DataWeave 2.0 more than covered our use cases for Groovy. These changes allowed us to improve the maintainability of many of our data transformations by replacing them with easy-to-test and maintain DataWeave 2.0.
Anypoint Visualizer was also key to our success as we were able to identify how our integrations interact with one another which helped us determine which apps to migrate first to minimize disruption. Another Mule 4 benefit is the improved logging and exception handling. Lastly, it was also just much easier ramping up developers on Mule 4 compared to Mule 3.
How we successfully migrated to Mule 4
In addition to treating our migration to Mule 4 as a project rather than a lingering backlogged task, we took a hybrid approach — meaning that we used Mule 3 and Mule 4 in parallel.In doing so, we chose to migrate our System APIs first since Process and Experience APIs consume the System APIs and rely on the data they uncover. System API migration is simple as you take a payload and transfer it from Mule 3 to Mule 4 and there isn’t too much transformation.
Furthermore, we would point third-party systems to new Mule 4 integration endpoints that we created, while parts of the API that weren’t migrated would still use Mule 3. We recreated each app in Mule 4 so that we would have these endpoints available to work in a parallel fashion using both the endpoints in Mule 3 and Mule 4 as needed. Or, for example, if we had a few nightly scheduled migrations in the same integration, we would switch to the one that we migrated to Mule 4 while the one we didn’t migrate was still using Mule 3.
We also utilized Teamcity and the Maven plugin to build our artifact. Then, Octopus picks up the artifact and deploys it (IIS). It’s easier to integrate with Maven and helps make the Anypoint Studio setup minor.
This allowed us to spread out the migration in chunks, making it faster to deliver with minimal disruption. Additionally, because we had 23 apps to migrate, some of the processes would go to production in Mule 4 earlier than others. This included smaller, independent apps that wouldn’t affect other systems and/or didn’t rely on other apps to run properly. For example, our expense process is an independent app so we knew that it was not dependent on any other systems and we could migrate it to Mule 4 easily and test it first.
Contrarily, more complex processes included in the Galaxy Platform mentioned above, required more time and effort to migrate from Mule 3 to Mule 4. When migrating these processes, we split them up. For example, when migrating our third-party optimizer integration, we migrated upload processes onto Mule 4 before the download processes because it was faster and less disruptive than trying to migrate as a large chunk. This was due to the fact that these processes utilized Groovy in the Mule 3 environment which we had to convert into DataWeave in Mule 4. This took the most time and required us to use Vs studio 2019 and new Mule components to convert it to DataWeave 2.x which had better scripting capabilities. This improved scripting capability allowed for data transformations as well as variable updates all in one, for example the ability to append to a Java array and then transform the entire updated array into a JSON output with just one minor DataWeave 2.0 script:
The other benefit was the improvement for default values, date time handling, and filtering. These changes allowed us to streamline much of our migrated DataWeave, as simple guards or variable defaults could be more easily handled:
Or mapping through filtered result sets could be done in-line with dates more easily manipulated into the correct time zone and format:
We also scaled our solutions, saving us time and money as a company. Using Mule 4 we moved from 12 hours to 3 hours to create processes and optimize integrations to create a smarter architecture. We redesigned our architecture so that we run on a global environment on one machine compared to each environment having its own on-prem machine.
Impact of MuleSoft Training
In addition to the tools we used to migrate to Mule 4, MuleSoft Training was key to our success. Our team is experienced with MuleSoft and with only three developers originally, we completed the migration of 23 apps in a year. Now we have a team of seven developers to help us scale using Mule 4!
These were:
- Anypoint Platform Development: Fundamentals (Mule 4)
- Anypoint Platform Development Mule 4 for Mule 3 users
- Anypoint Platform Architecture Application networks
These courses helped us better understand the differences between Mule 3 and Mule 4 as well as identify how we could restructure our architecture.
Outcomes of our MuleSoft migration journey
By migrating to Mule 4, Nine has best-in-class technology to help continue delivering our award winning 9Galaxy Platform to customers. We have also saved money and time while creating a faster and scalable solution for the future. Plus, our customers were amazed by the lack of disruption they experienced throughout our migration journey. Our team is also growing and becoming more skilled in MuleSoft. We have also improved our issue resolution and overall performance ultimately making us more productive in our work.
For more information on how to easily migrate to Mule 4, learn more about our Mule Migration Assistant.
