Reading Time: 18 minutes

I had the privilege of interviewing Audrey Honeycutt, Sr. MuleSoft Developer at RUSH University Health Systems, about their CloudHub 2.0 migration story. As an experienced MuleSoft Ambassador with many years of MuleSoft experience, Audrey shares what led her company to choose CloudHub 2.0, what challenges it has helped them overcome, and the technical use cases they have found CloudHub 2.0 supports. 

Below you’ll find my full interview with Audrey Honeycutt.

1:1 with Audrey Honeycutt, Sr. MuleSoft Developer at RUSH University Health Systems

Aston Whiteling: Thank you so much, Audrey, for being here today and talking to us about your CloudHub 2.0 story. If you could just introduce yourself, your title, and a summary of what you do.

Audrey Honeycutt: I’m a senior MuleSoft Developer at RUSH University Health Systems in Chicago. As the developer, I write integrations for healthcare data; in addition to that, I manage the CloudHub platform at RUSH.

Aston: I would love to understand a little bit what initially drew you to CloudHub 1.0 as a deployment platform when you were getting started with Mule.

Audrey: It was the patient 360 [implementation]. The customer had purchased Salesforce and wanted to get the patient 360 implementation going, so it seemed like the logical choice for doing integrations back to the EMR and other source systems. We had sort of simulated some of the functionality of private spaces.

What made CloudHub 2.0 the right solution for your needs?

Aston: Since now you have experience with CloudHub 2.0, was there anything specifically about CloudHub 2.0 that you wanted to explore and that made it the right solution when you found yourself in this next phase of deployments?

Audrey: In CloudHub 1.0, we were using the load balancer, which was more challenging to manage and configure. There was more setup and then there were also instances where it wasn’t quite what we wanted it to be in terms of this isolated space where we can connect our VPN and keep things from the public internet that don’t need to be there. So in our current implementation of CloudHub 2.0, the experience APIs can be public facing and then we have the other things not accessible and slowly connect back to our source systems through our VPN.

What does your IT landscape look like?

Aston: Could you explain the general IT landscape at RUSH University Health Systems and how having a platform like CloudHub 2.0 made sense? What was it like getting everyone on the platform and working together for that common deployment?

Audrey: The initial implementation was straightforward, especially when it comes to security, which is important because healthcare is a major target. Because of the documentation and all of the available resources, we felt comfortable with the architecture and presenting to our other groups. We weren’t looking to implement net new integrations aside from Salesforce, so there wasn’t much contact initially, but over the course of the year that started to change and the wider company started to see the benefit and the value. So it’s not just for Salesforce integrations, if we want to move cloud to cloud, using MuleSoft is the way we want to do it. 

How has CloudHub 2.0 helped with operational challenges? What features are “game-changers” for you?

Aston: How has CloudHub 2.0 influenced your approach to tackling these operational challenges? Are there any specific features you want to call out? 

Audrey: We’re starting to see that momentum because our internal teams are beginning to comprehend the capabilities of the product.I’ve been asked to start looking at other projects that include all  types of integrations. The evangelization of: “We’re building this API application network,” and the consistency of the data as we’re providing across the organization is a real game-changer when it can be challenging to match datasets across site to site.

We’re building a consolidated view, and we can easily bring in other sources that can close gaps on missing data. Being able to showcase: “We don’t have a specialty for this provider, but we can go to this other place where we may have that specialty, right?” – I think that’s where we’re gaining this momentum and getting a lot of other eyes from it from other business areas.

How has your team become more efficient with CloudHub 2.0?

Aston: Do you have any stats or figures that you could share with us? Could you highlight more about the efficiency gained through using CloudHub 2.0? 

Audrey: We actually did a presentation at Dreamforce about the access center but it was pretty new at the time as we were just in go-live mode. We were able to automate a lot with the agent. We’ve only been live a short while, so we’re still waiting on the numbers. What is easy to see is how quickly we’re able to do things in MuleSoft.

With regard to the collaboration of departments, you’ll find that in these midsize healthcare companies we don’t have a dedicated DevOps resource. Being able to set up and manage the pipelines, the CI/CD, always knowing what version is running in prod now, and so on, means a lot. Those features in CloudHub 2.0 allow us to relieve the burden from the central IT department with the managed platform and also allow us to focus on building integrations and not having to wear that DevOps hat all the time to manage the platform.

What is RUSH University’s approach to health monitoring?

Aston: Let’s talk about health monitoring. What’s your approach at RUSH University?  

Audrey: I actually wrote some custom monitors using the BAT CLI which was cool. I was able to create a monitor that would ensure that Salesforce can connect to our APIs which was incredibly important. We also needed a message broker and  we went with Anypoint MQ. We have HL7 messages that we’re parsing and sending to Data Cloud now. It seemed like the appropriate choice. 

What advice can you share with customers who haven’t switched to CloudHub 2.0 yet?

Aston: Given your experience with moving to CloudHub 2.0, what advice would you give to any other MuleSoft customer who’s kind of hesitant to make the switch from CloudHub 1.0? What’s the upside that you’re seeing and what would you use to convince them to join the CloudHub 2.0 wave?

Audrey: The example I mentioned regarding private spaces and configuring is definitely a huge benefit of CloudHub 2.0. Its expanded capabilities to create custom items is also impactful. The “behind the scenes” architecture of how the Kubernetes cluster functions in CloudHub 2.0 versus the way that it was in CloudHub 1.0 is something else, too. There are advantages to the processing and the way things are working in that cluster in CloudHub 2.0 compared to the old environment of CloudHub 1.0. 

Tell us about your Kubernetes experience and whether it’s relevant in context to CloudHub 2.0

Aston: Do you have any Kubernetes experience as well? Is that something that’s relevant with the CloudHub 2.0 context? I know it’s all kind of hands off and managed on our end, but it’s always interesting to see if that’s something that you think about as well.

Audrey: I’ve had many different roles throughout my career and have networked a lot. I’m also “big picture” person, so I really had to dive in and figure [Kubernetes] out. I set up this whole thing and then did a Visio diagram of how our Kubernetes cluster is working (even though we’re not managing it). It’s easier to gather information so when you see those things in the log, we can interpret issues and troubleshoot them. I took the Runtime Fabric training so that I could understand it from that perspective. Prior to that, I had no Kubernetes experience. I knew how it functioned and what it was, but not anything deeper.

Aston: So it seems like a good forcing function just to learn about Kubernetes and get that knowledge. If you are more interested in the Kubernetes world there’s RTF as well and providing these different options to get started with, but CloudHub 2.0 is the easiest as it is that fully managed service

Audrey: Exactly.

Let’s discuss horizontal autoscaling and troubleshooting features

Aston: Are you using any of the horizontal autoscaling features on CloudHub 2.0 as it supports clustering up to 16 replicas? You also  mentioned that troubleshooting has been an important value-add for you on CloudHub 2.0. Are you using the ingress logs as well as network troubleshooting?

Audrey: It’s a combination of both and one of the reasons is that the HL7 messages were using the MLLP connector. That’s why I had to dig into the Kubernetes, because in our original implementation we were just seeing some issues with that particular item. You push an upgrade and it loses the DNS, and we were trying to figure out what was happening there. It literally spins up a server and it’s listening. It’s TCPP traffic. We looked at the ingress logs there. I used an API to call those ingress logs, but didn’t know if there was a debug setting for those because it seemed high-level informational, and I wasn’t getting as much as what I expected.

Aston: HL7 is interesting because about a year and a half ago, CloudHub 2.0 added support for HL7 specifically for our HLS customers to support non-HTTP inbound traffic. So the fact that you mentioned MLP inbound traffic, I think it’s great to see that you’re using that feature.

How have you benefitted from new security controls in CloudHub 2.0?

Aston: What about the new security controls in CloudHub 2.0? How have you benefitted from them? 

Audrey: Security is obviously tight across HLS. When we’re developing a system API, even internally on the network connected, I still have to go to a specific host that has been allowed access. We’re only allowing that traffic. It’s very fine-grained, which helps with the whole security landscape. It’s being able to say it’s not even accessible on our own network unless you’re on the VPN. The API Manager has also been helpful because of the ability to do the API groupings. It’s beneficial to be able to set policies for groups as opposed to having to make sure that everything is getting defined as it should be individually.

Learn more about CloudHub 2.0

We want to thank Audrey for her thorough responses and feedback, and we welcome everyone to learn more about CloudHub 2.0, too! Check out the following resources for more information: