Will MuleSoft 4 Be the MS-DOS 4 for Integration?
The release of MuleSoft 4 makes a Zone Leader reminisce of the challenges with upgrading to DOS version 4 back in the late 1980s. Will MuleSoft suffer the same fate?
Join the DZone community and get the full member experience.Join For Free
Starting with MS-DOS 2, I began to understand the importance of an operating system that provided a command-line interface (CLI) into the connected system. I could use basic commands to organize and create files, configure the disk drives, plus launch programs on the system. Once there was a good understanding of the CLI, navigating around your system became far easier. Microsoft continued enhancing their product with version 3. I think I remember MS-DOS 3.3 was the version I used for a very long time.
Then, MS-DOS 4 (a joint effort between Microsoft and IBM) was created, and it was quite different than the previous versions. At least, that was the word on the non-Internet-based street. After all, the year was 1988.
With IBM assisting with the development, there were some attractive features:
Support of drive partitions greater than 32 MB
Avoid the need to use of the SHARE.EXE utility
Introduction of DOS Shell
However, there were bugs...especially with those not utilizing IBM's PS/2 line of computers. Additionally, changes to core aspects led to numerous utilities and networking programs to become incompatible. As a result, there were issues fully converting from earlier versions of DOS. Some (like me) opted to remain on MS-DOS 3, while others decided to pursue the use of DR-DOS 5 from Digital Research. MS-DOS 4 was certainly the least adopted version of MS-DOS and could be considered the least adopted product upgrade of all time.
When I started looking at MuleSoft 4, I started getting flashbacks from the late 1980s.
In June, MuleSoft announced Mule 4 (and Anypoint Studio 7), code-named Titan. With this anticipated release, there is a long list of features — a few are noted below:
Simplified core concepts and language.
Transparent data access and streaming.
Non-blocking, self-tuning runtime.
Simplified error handling and introduced a new "Try" scope.
Revamped core connectors such as FTP, File, Email and JMS.
These are attractive features to add upon three prior major releases of solid development. However, the Titan upgrade has a couple major caveats:
Inability to use MuleSoft Expression Language (MEL) in favor of DataWeave.
Changes in the Mule message, require a new approach to processing events in Mule 4 and causing pre-release 4 flows to no longer work.
These lead to a not-so-straight road for current users to migrate to version 4.
The Road to MuleSoft 4 (Titan)
Corporations already embedded in earlier versions of MuleSoft have a detailed road ahead of them to adopt the Titan release. I can't help but see the similarities with MS-DOS 4 noted above.
Prior version modules and flows will not run in version 4, requiring a complicated conversion effort.
Components have been removed, replaced with new components which are not known to the user community.
The current product has had some challenges, with customers trying to gain a full understanding of the correct way to configure their environment for the Titan release.
In talking to a few MuleSoft customers, they are not in a hurry to fully embrace version 4. Instead, they are in a "wait and see" pattern, based upon the feedback and direction resulting from the current version of Titan.
Eventually, MS-DOS version 5 arrived and was greeted with universal praise among the DOS-based community. The consequences of releasing 4 did cause some loss in market share (to competitors), but the stragglers still on version 3 found their way to the new and improved product provided by Microsoft.
For the record, I am very much a fan of MuleSoft and the multiple needs their suite of products fill in the marketplace. In fact, my hope is that MuleSoft learns from the challenges DOS faced when their version 4 was introduced. Without a clear pathway from version 3 to version 4, it will likely cause their customers to either linger behind or opt for alternative solutions.
I am not a fan of backward compatibility for the sake of backward compatibility — as I discussed in my "Backward Compatibility — Friend or Foe?" article from December 2015. However, I believe that when making significant changes, some tooling needs to be included to assist users with their upgrade. After all, in a large number of MuleSoft installations, handling MuleSoft development and support is only a fraction of the individual's responsibilities.
Thinking MuleSoft 3 users will linger until an improved version arrives (like the MS-DOS 3.3 users) is not a recommended approach. After all, that was 1988, and there really weren't as many alternatives for valid operating systems as there are in the integration market space today.
I am hopeful the product teams at MuleSoft avoid the same faults the MS-DOS 4 team encountered with their similarly numbered version (4).
Have a really great day!
Opinions expressed by DZone contributors are their own.