Recently I got my Integration Solutions Architect certification (MCIA) and thought that this could be a good time to reflect on what I have experienced with Mulesoft as an Integration Developer so far. My background in integrations began over 6 years ago when I started developing integrations in the Health Sector with different toolsets and environments. This is my journey from non Mule developer to MuleSoft Integration Developer.
To be honest, when I began working with Mule integrations I had no idea what Mule was capable of and what it would enable. I had a hunch of capabilities but those expectations were surpassed over and over multiple times. However it was not a street for beginners since Mule has been here for years and most guides and help topics were about real life problems. Tips for setting up your toolset, development environment, and your practice for the new Mule version were not that easy to find and are passed verbally from developer to another. Rising pandemic did not make this any easier and I have spent many times bothering colleagues asking for their best practices.Those conversations brought me to discover various topics.
The first time I was working with Mule 4 early on I came across with the concept of unit testing for integrations. Now it seems obvious but I had a background with integrations where having unit tests were not feasible and in many cases not even possible. I was blown away that of course this is the way to go. I can hand over my creations and trust that they work and it works vice versa. During my studies in Mule 4 I was taught that there’s so much more within testing integrations with Mule. Not only can you enable Test Driven Development or automate your unit tests while building or regulating deployments based on how well your applications are tested, but integration testing, stress testing, etc. all that good stuff is possible too. If you need them you got them.
Developing integrations with Mule 4 gave me confidence that deployments to production are not that big of a deal anymore. I do not need to gather all stakeholders together to monitor deployment. No sir, there’s no need for that. By default Mule with its cloud based CloudHub provides different environments where integrations can be tested before they are transported to production. Having fluent CI/CD pipelines makes life so much easier due the simple reason that there is no need to figure out what is the production state and are my changes compatible with them.
While getting into speed as a Mule developer I was stumbling every once in a while onto issues and mystical errors. Luckily there was usually either a help article by MuleSoft or other colleagues who had experienced the same. I really never got to a point where something did not work and I did not know why. That is the beauty of this Mule community. Seniority support is available here at Solita and it can be utilised well. Even when there are those very rare cases where nothing comes up with Google but debug logging have always at the end revealed the reasons for mysterious behaviour of the issues.
It’s good to have formal learning by the technology vendor since Mule is constantly evolving with new features. Having completed both Developer and now Architect certifications I have noticed that some good practices have their roots in those training. Courses have elevated my understanding of the Mule ecosystem and the way Mule works. For a new integration developer who is getting into Mule world I would warmly recommend attending the MuleSoft Integration Developer course and try the Developer certification.
Almost all modern integration tools do follow Enterprise Integration Patterns and so does Mule. This book acts as an integration bible where as many other technologies do have their own i.e. MS SQL does have its own SQL Bibles. The architecture course I took was partly built upon that linking different Mule components to different patterns mentioned in the book. The beauty of it is that the book is universal and technology independent yet Mule does their best to follow it.
There is no need to reinvent the wheels since those general patterns can be created by different basic Mule components. There are already vast amounts of connectors to different backend systems that solve most of the problems, and they usually come with example solutions showcasing the patterns to utilise most of their capabilities. Often ready-made components are working best when used with their default settings and that does help integration developers entering the Mule world.
For the past 408 days with Mule it feels like being at ease as a developer. There is no need to spend time on building up everything but just focus on delivering business value fast. Compared to previous integration systems that I have experienced, the ramp up speed and possibilities for collaboration with colleagues and customers are absolutely great. As time passes the Mule and its ecosystem with all ready-made connectors will evolve, certainly there is more to learn and skills to improve. My journey from here will continue looking to focus more on the platform side of Mule and complete the stack of certifications with the last missing certification of Platform Architect (MCPA).
