Overcome governor limits in your workflow apps

know_your_limits_by_kab3on-d32mpx3Those of you that are making the most of your Salesforce instance are likely to have tested the limits. These limits are put in place by Salesforce, who are trying to make sure that ‘fair is fair’ on the playing field. There is only one choice as a client of Salesforce, a single deployment option – multi-tenant public cloud. You, and many other customers of Salesforce share server space (hopefully this isn’t news to you).

The globally adopted vision of what the cloud can bring, is elasticity. A world where everything is stretchy and availability can match consumption in a way that doesn’t break something.

This model has many advantages – but each tenant is required to act as a ‘good neighbor’. Salesforce enforces neighborly behavior through governor limits. If one customer suddenly needs to suck up a lot of bandwidth, without these governor limits in place, performance for adjacent clients in the same shared space could be detrimentally affected, and without warning. So, we need limits.

Boom! Suddenly the cloud is no longer elastic.

The problem is though, these governor limits can add to the complexity of delivering your apps. And don’t be fooled into thinking these are the sort of issues reserved for the likes of consumer, angry birds style apps – these issues are very real in the enterprise world. You are worrying about the architecture, data sources, security, usability, speed, deployment options, on-line/off-line, potentially coding that app – what if the business want to change the process half way through?

Most organizations we are talking to are in the business of speeding up their workforces and increasing their competitive advantage – they can’t afford for their workflow processes to miss the mark.

Hitting governor limits is just another thing to worry about.

The ManyWho architecture recognizes this problem. We are fundamentally architected differently to take advantage of elastic scale on a tenant-by-tenant basis and are able to grow to an enormous capacity should any client require. But it’s not really about multi-tenant vs. single tenant deployment. It’s more about “how” that multi–tenancy is delivered. We are elastic because we don’t run on fixed boxes – we run our PaaS (Platform as a Service) on an IaaS (infrastructure as a Service) – and pass that elasticity onto you, our customers. With ManyWho applications governor limits are completely removed.

So that’s one less thing on your mind.

ManyWho Architecture Deployment options

Image curtesy of Kab3on via google images