The Scale, the Mask, and the REST
Tags: webdev
Published: 2021-01-20 13:34:05

![](https://dev-to-uploads.s3.amazonaws.com/i/kjvrbc1qohpfxj4t67n7.jpg)


*(Photo by Mila Sviderskaya)*

_Welcome to the fourth episode of "Tech Tales from Quarantine". This sequel to ["Agile, Flow, and a Filter"](https://dev.to/salesforcedevs/salesforce-conversations-3-4626) is all about scale. As always, this is a work of fiction—except for the technology, that is very real._

“Scaling is harder than it looks.”

I heard my housemate muttering across the living room. He was, as usual, hard at work – though not as bad as in the past. Meanwhile I, as usual, had extra time on my hands, that I was using very productively – well, not really. In fact, I was watching the cat wearing a mask.

Ok, not really wearing it – at least not always. More like grabbing and tossing it by the straps, and occasionally getting caught in it when it landed on her head. It was refreshing to see something to do with masks that had nothing to do with politics or pandemics.

“I think wearing a mask is harder than it looks,” I replied, pointing to the cat. “And why are you worried about scaling? You’re a developer – leave that to the infrastructure experts.”

“I can’t,” he said. "Remember that COVID-19 therapeutic startup? The one that we put on the Salesforce platform? Well, they’ve been thrilled with how things have worked out, but they are growing fast. They're building out a portal and have some tasks related to data analysis and computing results that potentially need to scale massively in the near future. They’ve asked me to come up with an approach that scales. And they can’t afford a mistake.”

At this point Angie chimed in. She’s a friend from college who worked with us on numerous class projects. Okay, let’s not kid ourselves, we worked with her. When it came to technology, she was always just one step ahead of us. A great person to have around in a project group, and any other time. These days we were all working from home, but we kept a remote session open most of the time so we could chat.

“But why you?” she said. “Rapid and reliable scaling is its own specialty – not something that every developer knows or should know even with the availability of automated scaling tools.”

“I know,” answered my housemate. “But it’s a combination of time and resources. Even if they can afford to hire the person they need, they don’t have the time to find one and bring them up to speed. Come on, Angie, you’re an architect – point me in the right direction?”

She shook her head. “I know a lot about scaling, and I know more about architecting a design for performance. But there’s a difference between building software that will scale well, and actually building out the hardware or virtual hardware, and then monitoring and managing it. If it’s a critical situation, it’s best to have someone around who’s actually done it.”

“How about microservice architectures?” my housemate asked. “One of their key advantages is you don’t have to think about scaling the hardware, right?”

Angie paused, then replied, “Yes and no. It’s true you don’t have to worry about spinning up virtual machines and distributing the load across them. But once you start building out a full microservice architecture in practice you discover all kinds of quirks – timeouts, rate limits, spin-up delays, backpressure and data capacity issues. Each part of your architecture from the lambda functions to the databases, to the queues and monitoring systems, have their own issues that you need to be aware of when assembling them into a solution. It’s not magic.”

At which point, both of them turned to me. My housemate grinned, “this is the part where you stand up in the chair, and in your best wizardly voice cast a fake spell, then explain to us how Salesforce will magically solve our problem. So, we’re ready.”

Both of them were looking at me expectantly, and their expressions turned to surprise when I stayed where I was.

“There’s magic, and there’s magic,” I replied slowly. “And you have a number of different requirements here.”

I continued, “As far as what you’ve already built – the internal processes that their staff has been building out using automation and some code – you don’t have to worry about scaling as the company grows and number of transactions increases – that’s going to scale magically. So you can reassure your client on that score. You _will _have to worry about the complexity and efficiency of some of the things they are building – it’s important to use best practices there. And some of the data analysis and computational tasks you hinted at can cause problems if you try to build them on the core platform.”

“Interesting – so it scales well by transactions, but not necessarily by complexity,” he said thoughtfully. “But what about creating a portal that’s open to the public? Some of the functionality we’re building there will need access to the Salesforce data, and the management functionality will need to live on the Salesforce side both to maintain access to the data and to leverage the built-in security – profiles and roles that we’re already using,” he continued.

“There are a number of options to consider,” I replied. “You could build a portal using[ Salesforce Sites](https://developer.salesforce.com/docs/atlas.en-us.salesforce_platform_portal_implementation_guide.meta/salesforce_platform_portal_implementation_guide/sites_overview.htm) – it’s a way to create consumer-facing public web portals. Because it’s part of the core platform, you won’t even have to think about scaling – the platform will handle that for you. But depending on what you’re trying to do with your portal, you might also consider one of the other Salesforce applications – like communities, that makes it easy to implement a community portal. It will also scale magically.”

Angie had been listening intently, and stepped in. “So it sounds like there are two areas where we still have to consider scaling. The first one is implementing complex tasks – whether business processes, or data analytics, or other tasks that are very computationally intensive.” I nodded as she continued, “the other is building out a customer portal if you can't find an existing Salesforce application or other SaaS service that provides the features you need. And in both cases, we have the challenge of scaling and the challenge of connecting to the Salesforce data.”

My housemate looked disappointed. “That’s not quite the magic I was looking for,” he said. “I’m still facing the challenges I started out with.”

“Oh, it’s not quite that bad,” I smiled. “Have you ever heard of[ Heroku](https://www.heroku.com)?”

Angie answered, “Sure – it’s a PaaS provider. I should have thought of that in the first place. PaaS makes manual scaling easy, and even offers some auto-scaling options. And it’s very developer-friendly. It’s a great choice for getting started in cases like yours – where you don’t have access to IT expertise for managing the virtual infrastructure.”

“Right,” I added. “And do you know who owns Heroku?” They both stared at me blankly. “Salesforce does.” They looked surprised.

“So of course it has amazing integration with Salesforce. There’s[ Heroku Connect](https://www.heroku.com/connect), which  syncs Salesforce data to a Heroku Postgres database. There’s[ Salesforce platform events](https://trailhead.salesforce.com/en/content/learn/modules/platform_events_basics) – a message queuing service that can be accessed from within Heroku and within Salesforce. There’s[ Heroku External Objects](https://devcenter.heroku.com/articles/heroku-external-objects) that exposes Heroku Postgres tables as objects within the Salesforce platform. There’s[ Salesforce Canvas](https://developer.salesforce.com/docs/atlas.en-us.platform_connect.meta/platform_connect/canvas_framework_intro.htm) that lets you surface a web-based UI from Heroku onto the Salesforce UI. And of course you can implement REST endpoints that allow your Salesforce app to call into Heroku or vice-versa.”

My housemate was nodding. “So maybe not one big magic, but enough medium-sized magics to support the client until they’ve grown to a point where they might be able to build out a full IT department and handle the massive scale that they hope to reach one day.”

“I hope that happens,” I sighed, looking again at the cat who was still fascinated by the mask. “It would be sure nice to reach a day where the only thing those masks are good for are playthings for cats.”

Angie spoke softly. “Choosing the right tools for the job will help bring that day closer. Salesforce is right for certain applications. Heroku and other cloud providers are right for other applications. Choosing the right technology and integrations between them is everything when it comes to modern software development.”

“And besides,” my housemate continued, “whether it’s healthcare, education, or dealing with any of the other problems in these crazy times, it’s nice to know that we in technology can help create the solutions.”

“Yeah,” I paused, then continued. “And it’s nice to do something direct as well – like adopting a cat even if it means eternal torment from allergies. Come here, Cat,” I waved at her. She looked up for moment, then went back to the mask. She’d get to me in her own good time. Unlike software developers, cats always have their priorities straight.

 

_Postscript_

_I hope you've enjoyed this series of Salesforce tales. But I have a confession... The part about this being a work of fiction except for the technology? That's not entirely true. The cat, you see, is real. This story was inspired by a co-worker of mine, who, along with his housemates, adopted a cat while stuck in quarantine, only to discover that he was allergic to it._