At Mulesoft, a critical part of integrating everything is building the Mule Applications that make those integrations. For such, Mulesoft has many different options for our customers to use, including Composer<\/a>, Flow Designer<\/a>, and Studio<\/a>, among others. All of those need a Mule Runtime in the back to help the customer quickly build their integrations through Design Operations. Design Operations are basically any actions that make the user\u2019s life easier: we test their connections to see if they are still valid; we autocomplete anything that we can; we inspect all the attributes the third-party accepts and their types; and we allow for a smooth experience in the UI by validating each field. Does the user want to see what kind of data will be going through a step of the integration? No problem! Design Operations have their back. Not only that, once they are done drafting their integration, they can quickly test it and see in detail what happened at each step just like with any debugging tool for any high-level language.<\/p>\n So now that we understand Design Operations, we\u2019re going to be taking a closer look at Mulesoft Composer<\/a>, which extends the integration-building powers of Mulesoft\u2019s AnyPoint Platform to non-developers. It provides a no-code, point-and-click environment experience, coupled with enterprise-grade reliability, security, and governance. Behind the scenes, it\u2019s powered by Mulesoft Design Services (MDS). MDS is the first serverless architecture built within Mulesoft that helps customers build their integrations by using the full stack of the Mule Runtime\u00a0tools.<\/p>\n MDS is what delivers all of the Design Operations, spelled out above, for users of Composer. And everything happens in near real-time, so the customer doesn\u2019t need to know anything about Mule Runtimes or Infrastructure while they\u2019re building their integration. To make this work, MDS uses a Kubernetes farm of pre-warmed-up Mule Runtimes to handle multi-tenancy and security isolation with high concurrency and autoscaling. Read on to find out how we built\u00a0it!<\/p>\n We\u2019re not Super Architects. No one woke up one morning with a fully-formed vision for how to architect MDS, how to provide a serverless API, or how to achieve fast response times. Innovation here needed baby steps, iteration and lots of research.<\/p>\n It all started during a company-wide hackathon a few years ago, fueled by energy drinks and lots of snacks. The problem we wanted to solve was, \u201cMule Runtimes are slow to start and may fail during an integration, requiring manual restart (even in our cloud product Flow Designer<\/a>). How can we improve the customer experience so they don\u2019t need to care about\u00a0those?\u201d<\/p>\n During the hackathon, we succeeded in having a Mule Runtime execute a single Design Operation and then destroy itself. This was the first step toward an ephemeral Mule. The idea was simple: let\u2019s break the coupling between a Mule application being designed and a Mule Runtime. Soon after, we started a Proof of Concept (POC) to find the best way to achieve this in production.<\/p>\n The POC began with research into all the serverless tools out there. We didn\u2019t want to reinvent the wheel if we didn\u2019t need\u00a0to.<\/p>\n We first looked into using AWS Lambda<\/a> to start a Mule Runtime, execute an operation as a lambda operation, and then delete the Runtime. However, we found this took too long. Additionally, we discovered that we had some scenarios that were incompatible, as we needed some \u201cstate\u201d between certain operations (like clicking \u201cTest\u201d and having a Mule App deployed for a certain amount of\u00a0time).<\/p>\n We also looked into AWS API Gateway<\/a>, Google App Engine<\/a>, Microsoft Azure Serverless<\/a>, IBM Apache OpenWhisk<\/a>, Kubeless<\/a>, and some other technologies that were aiming to solve the serverless paradigm through different strategies. With each POC, we would learn something and we would advance a bit more, but eventually we would hit a roadblock. It seemed our solution was not out there, and we would need to build something\u200a\u2014\u200abut maybe not all the way from\u00a0scratch.<\/p>\n Along came Mulesoft Runtime Fabric<\/a> (RTF), which was freshly released at about that time in our innovation journey. RTF offers a way to deploy Mule applications into a Kubernetes cluster. It includes know-how on deploying Mule Runtimes into Docker images, as well as how to connect them to the outside world using our RTF integrated ingress solution<\/a>. It also includes configuration, secret management, and monitoring. RTF offered us enough of a head start to build on. The POC became super-focused on having MDS work on top of an RTF\u00a0cluster.<\/p>\n We started with a single service deployed inside the RTF Kubernetes cluster, and a single Design Operation to be covered: Test Connectivity. A Mule Runtime would already be deployed as a pod and we would just use it to solve the operation. We executed a request from Postman and the first scenario was a roaring success! That\u2019s it? Did we make it? No, we were FAR from finished, but this was a good start. Now that we had the simplest scenario covered we built a roadmap and started coding in\u00a0earnest.<\/p>\n What were our next steps? We needed to make sure we covered all possible Design Operations. Also, if we ever wanted to go to production, we needed to have high availability (HA) everywhere, which means we needed MDS to be able to scale. All of this led us to decide that we needed to start storing some distributed state\u200a\u2014\u200abut\u00a0where?<\/p>\n To avoid any incompatibilities between databases and our Kubernetes clusters, we wanted something living within the same MDS cluster. The Mule Runtime had been working for ages with Hazelcast<\/a>, a clustered, NoSQL, in-memory database that works pretty well inside contexts like Kubernetes and that was already working for the Mules in RTF. Without hesitation, we put our POC hats on and gave it a try. It worked! With simple Java Collections, we had a scalable distributed state. We started building everything on top of Hazelcast.<\/p>\n So now that we had all of our tools in place, the mission became clear: make it to a staging environment in time to debut at Dreamforce, Salesforce\u2019s annual customer conference.<\/p>\n With hard work and a lot of focus, by Dreamforce, we had everything we needed: feature parity, a scalable product, everything deployed in a staging environment and\u2026uh oh\u200a\u2014\u200aNO SECURITY at all. Innovation is about the journey and this journey was still far from over. Luckily, the Dreamforce demo of the staging environment was a success, so we had the confidence and support from everyone to keep going on the MDS journey and make it to production.<\/p>\n Along came the security and architecture reviews<\/strong>, which helped us work on great features like Network Policies and a strategy to isolate customers and avoid multi-tenant Runtimes. After that, we prepared for production and realized we needed better performance. This led us to work on a full new set of features for warming up runtimes: pre-loading dependencies, exercising classloading in a dynamic way to make it future proof, and many\u00a0others.<\/p>\n With performance testing<\/strong>, we discovered that our communication with Hazelcast was not concurrency-friendly, so we had to rewrite the interaction from scratch and then do even a bit more to make it performant.<\/p>\n We couldn\u2019t have predicted any of these things without walking the path of innovation, testing and iterating frequently.<\/p>\n The journey took us to a point of becoming the backend of Flow Designer and onward to adding new features to work behind Composer, which takes us back to the introduction of this post. As you can see, innovation wasn\u2019t a straight line, nor was there a singular \u201ceureka!\u201d moment. Rather, innovation proved to be the result of doing the work, documenting results, and iterating until we finally have a version of MDS that we\u2019re proud of. The goal from the very beginning was to help our customers in a significant way, and we\u2019ve achieved that with MDS, which is currently generally available.<\/p>\n In the end, innovation is about the journey, and this journey is still not over. Our options for the future are wide open as we work on new features regarding performance, high availability and scalability to provide a continuously better experience to a growing customer base. MDS could become a full-time Mule Serverless as a new standalone offering, it could be used by all integration tools in and out of Mulesoft, or it could be integrated with machine learning technologies to reach new unprecedented faster response times. Anything is on the\u00a0table!<\/p>\n If you\u2019re interested in innovating with us, <\/em>join our Talent Portal<\/em><\/a> to check out open roles and get periodic updates from our recruiting team!<\/em><\/p>\n Innovation is About the Journey: The Mulesoft Design Services Story<\/a> was originally published in Salesforce Engineering<\/a> on Medium, where people are continuing the conversation by highlighting and responding to this story.<\/p>\n Read More<\/a><\/p>\n","protected":false},"excerpt":{"rendered":"A Hack is\u00a0Born<\/h3>\n
Proof of Concept\u00a0Research<\/h3>\n
The Solution Was In Our Own\u00a0House<\/h3>\n
On a Mission to Dreamforce<\/h3>\n
Testing and Iterating<\/h3>\n
Where We Are\u00a0Now<\/h3>\n