Well, what is it?

If you've developed, administrated, or managed Salesforce projects in the past, chances are you've heard of Heroku. In this four-part article, we will unpack:

  1. What Heroku is
  2. How it compares to Salesforce
  3. How it complements Salesforce
  4. How to integrate Heroku with Salesforce

The goal of this series is to help readers understand the various ways in which Heroku can help companies succeed, regardless of whether or not they are current Salesforce customers.

If you saw Salesforce and decided to bug out, hang on a second!! While Heroku is a great resource for Salesforce customers and projects, it is only a tiny portion of Heroku's capabilities. Stick around to hear about how Heroku can benefit non-Salesforce projects as well.

When might you need it?

You're the product owner overseeing the development and maintenance for an important offering for your company. You just learned that your product was featured on a popular industry blog, causing your traffic to spike. Your on-premises solution has been down for two hours and the extra hardware and staffing needed to ramp up and serve your new users will take weeks, if not months. What do you do?

Enter… Heroku

Heroku Hero

(source: https://image.slidesharecdn.com/sd-meetup-01-140917023404-phpapp01/95/cloud-101-handson-heroku-aws-10-638.jpg?cb=1410921309)

Infrastructure, Platform or Software as a Service

While Heroku integrates with and is owned by Salesforce, Salesforce integration is not actually the main selling point for Heroku customers. Heroku is a Platform-as-a-Service (PaaS) for everyone from hobbyists to enterprises. Before discussing Heroku's main features, let's first understand exactly what a PaaS is, and what it is not.

Internet hosting and infrastructure usually have three main categories:

  • Infrastructure-as-a-Service (IaaS)
  • Platform-as-a-Service (PaaS)
  • Software-as-a-Service (SaaS)

IaaS

IaaS products generally provide the most basic resources needed to power an internet application, namely, the hardware on which it will run. In recent years, this hardware layer is almost always abstracted away in the form of a virtual machine (VM) or container. The customer is in charge of setting up and configuring all services on the host hardware/VM all the way down to the operating system (OS). Once the OS is chosen and installed, the entire runtime must be configured by the customer, including things like routing, firewalls, databases, the file system, and so on. Additionally, the customer is responsible for keeping the installed OS patched and up-to-date to defend against attacks. Some examples of available IaaS products include Amazon EC2, Microsoft Azure VM, and Google Compute Engine.

PaaS

While IaaS products give customers a myriad of choices in terms of operating systems and the like, PaaS products provide the hardware/VM, OS, and basic runtime. PaaS products generally take care of lower-level configurations, such as port management, basic OS security, and keeping the OS and runtime components up-to-date. In this way, PaaS customers give up some amount of freedom and choice in exchange for a minimally configured, more-secure environment. Some examples of available PaaS products include Heroku, Amazon Elastic Beanstalk, DigitalOcean, Microsoft App Service, and Salesforce.

SaaS

The final category of services, known as SaaS, builds on top of PaaS by providing and maintaining the full stack of capabilities for the customer. Customers of these products are generally paying for an "out-of-the-box" or lightly configured experience. SaaS products' main selling point is that customers do not need teams of developers and administrators in order to keep a site or product available, secure, and up-to-date. Employee management, customer relationship management, and enterprise resource planning are examples of needs that are commonly addressed by SaaS offerings. These products may be thought of as contained applications, usually accessible via a website. Some examples of available SaaS products include WorkDay, Salesforce, Microsoft Office 365, Concur, and Dropbox.

Key Terms

As Heroku's features are described, it is helpful to first lay out some specialized Heroku terms.

  • Dyno - A basic application container that can be customized by the user or application.
  • Application (App) - A collection of source code, binaries, and dependencies. An application is often composed of several types of dynos, potentially with several dynos of each type active at any moment.1
  • Stack - Specialized operating system, maintained by Heroku. Each application and dyno will run on the same stack.2
  • Slug - The term "slug" has widely-varied meanings across software development. For Heroku, slugs are pre-compiled copies of an application that are optimized for quick distribution to dynos.3 As dynos are spun up on-demand, slugs are loaded into the dyno and immediately started.
  • Buildpack - Framework that translates deployed code into a slug. Buildpacks contain instructions and scripts on how to organize, retrieve dependencies for, compile, or otherwise "build" the source code and binaries into a package that will run properly on a dyno. All first-class languages and frameworks on the platform have buildpacks that are officially maintained by Heroku.4
  • Add-on - Add-ons are components, both Heroku-maintained and third-party, that support various parts of an application.

Developer-Centric Components

Heroku was built by developers, with developers in mind. While some PaaS products have complicated processes for deploying applications, Heroku uses Git, a well-known and well-loved Version Control System, to promote code from a developer's local machine into an app. This means that the process of developing code and deploying code can often be accomplished with a single piece of free, open source software that developers have already used in the past. Additionally, most configurations to an application can be made via configuration files and the Heroku Command Line Interface (CLI). This includes provisioning add-ons, setting environmental variables, etc.

Heroku encourages developers and product teams to develop applications in whichever languages they desire. The platform offers first-class support for nine languages, including, but not limited to: Python, Node.js, Java, PHP, and Ruby. Additionally, the [Heroku Elements marketplace](https://elements.heroku.com) has a plethora of third-party buildpacks for languages, tools, frameworks, and more. The big advantage to this design is that it allows developers to get up and running on a project very quickly, leaving the lower-level build and configuration pieces to the platform.

Add-ons

In addition to reducing complexity with development, the Heroku platform also helps solve common and/or difficult architecture pieces with add-ons. Its Elements Marketplace hosts a variety of add-ons that service areas such as database management, message-passing, caching, asynchronous tasking, and monitoring. Most add-on plans have a free tier, which allows developers to tinker with an add-on before committing to it. This system gives customers the option to farm out complex portions of a site to other providers within the Heroku ecosystem, saving time, headaches, and money.

Continuous development, integration, and delivery are heavily promoted on the Heroku platform. The Heroku Pipelines product groups together apps that share the same codebase, bucketing them as Development, Staging, or Production apps. Code from any Development app can be promoted, via the user interface (UI), to Staging, and then to Production. Review Apps can also be configured to spin up whenever a GitHub pull request is made, allowing pull request reviewers to open up the app and functionally review pull request changes. The Heroku CI product is used to orchestrate unit- and browser-tests for pull requests. Lastly, Heroku Flow ties all of these individual pieces together to create a comprehensive approach to continuous integration and delivery (CI/CD).

Enterprise-Centric Components

While Heroku is a great platform for development, to be considered competitive, it also needs to be a great platform for enterprises and production-ready apps. Utilizing Heroku instead of on-premises servers can help reduce IT budgets, resources, and infrastructure, produce better uptime, and greatly reduce the time-to-market for new products, features, and patches.

As Heroku customers, companies are finally freed from needing to dedicate IT resources to the never ending role of managing security patches, OS upgrades, and other infrastructure requirements. Heroku has dedicated resources for managing its software stack, which enables customers to stay ahead of the curve on network vulnerabilities. These resources can quickly apply security patches and upgrades to its stacks and then push the changes out to all applications, eliminating threats for all customers in a timely and scalable fashion. IT departments are also relieved of the need to constantly monitor the underlying infrastructure in order to maintain uptime. Instead of being forced to hope that your IT administrators are always up-to-date on the latest network attacks, software bugs, and even benign troublesome networking scenarios, companies are able to rely on Heroku to manage this monitoring and maintenance.

Application Resource Management

Take application resource management as an example of one of these mundane yet critical networking scenarios. Heroku handles this problem with scaling and load balancing. Manual scaling may be performed from the UI or the CLI and will spin up or tear down the dyno types as configured. This can be a tedious, inefficient process so most customers instead prefer to use autoscaling. With autoscaling, the customer can control all of the conditions around how scaling performs: minimum and maximum dyno counts, heuristics, maximum latency, and more. These settings provide a fine-tuned method for controlling how much money customers are comfortable spending on an application. In addition to computational resource spikes, Heroku also manages network resource spikes through load balancing. For all customers, Heroku manages this with routers set out in front of applications to ensure that all dynos are receiving comparable volumes of traffic.

Historically, companies have paid for on-premises solutions since they can manage and control every aspect of an application. However, in the current age of cloud offerings, more and more executives are seeing the benefit of transitioning their products to PaaS systems. As is common with PaaS systems, Heroku apps run on a [multi-tenant architecture](https://en.wikipedia.org/wiki/Multitenancy). This means that apps on the platform share various resources, such as networking, load balancing, and database infrastructure. Each of these shared resources can be independently located in various regions around the world. While these trade-offs may be sufficient for hobbyists and small companies, larger companies - especially those transitioning from on-premises solutions - often have stricter requirements and regulations for their applications. In this case, such enterprise customers can opt for the Private Spaces product which provides access to network-isolated applications paired with dedicated stacks.5 Applications within a customer's Private Space can securely communicate and the customer can enable IP restrictions, as well. The Private Spaces jurisdiction also includes dynos and add-ons, meaning that the entire end-to-end application exists in a secure, controlled environment. Additionally, these stacks are guaranteed to be provisioned in a region specified by the customer, cutting down on latency and adhering to various data regulations around the world, whether it be in finance, government, healthcare, or others. This feature of Private Spaces is especially relevant given the European Union's recent General Data Protection Regulation (GDPR) enforcement.

But Wait, There's More!

While the above discussion explains some of the main features of Heroku, there are even more products and services offered by Heroku that can be extremely beneficial to customers. For instance, Heroku has curated versions and implementations of databases ([PostGres](https://www.heroku.com/postgres)), data-stores ([Redis](https://www.heroku.com/redis)), and real-time stream-processors ([Apache Kafka](https://www.heroku.com/kafka)). Heroku's [OpEx]() product is tailored towards application health and monitoring. [Heroku Connect](https://www.heroku.com/connect) is designed from the ground up to interact with Salesforce environments. Through its breadth of products and services, Heroku seeks to provide as much direction and architecture as desired, but ultimately leaves the customer free to define exactly how they would like to design and architect their product.

Heroku vs. Salesforce

When To Use (And Not Use) Salesforce

When a company embarks on a new product, it will often need to decide at some point whether it will build the product, buy the product, or some combination of the two. If the product exists within the Customer-Relationship-Management (CRM), Case-Management-System (CMS), Marketing, or Commerce spaces, Salesforce can be an attractive offering. Its products are more-or-less turn-key, available for use with little configuration. Additionally, if a company wants to use some combination of these products in concert, the data and functionality may be shared between them. Salesforce markets itself as providing "no-code" and "low-code" products, which appeals to many smaller, less complex businesses.

Pricing

Salesforce's pricing structure is largely based on a customer's active user license count. In exchange for a per-user licensing structure, customers are given a standard amount of storage, computing time, and other resources. A portion of these limits can be lifted with add-on purchases; however, some are fixed for all customers. These limitations are a non-issue for most smaller, turn-key customers, who are primarily looking for the return-on-investment (ROI) of an out-of-the-box product coupled with stability, security, and uptime with few or no in-house IT staff to manage it.

With its Lightning Experience, Salesforce has emphasized products, reporting, and monitoring, replete with beautiful user interfaces. Salesforce's plethora of security options provides its customers with almost limitless combinations of field-level, record-level, and object-level security controls. For companies who rely on these features, or who can't afford to construct and maintain these features themselves, Salesforce is a lifesaver.

SaaS Drawbacks

However, most of the features listed above describe a Software-as-a-Service (SaaS) product, more-so than a PaaS. Larger companies, or companies with complex business requirements often need to customize these Salesforce products. There are several limitations of the Salesforce ecosystem that may impact developers, managers, analysts, and product teams. Salesforce's multi-tenant architecture in and of itself can cause headaches for companies with multifaceted needs. The multi-tenant nature of Salesforce means that multiple customers share the same hardware and software resources. In order to accommodate a certain number of customers per server, Salesforce places limits on most actions and resources. For instance, if a company needs to perform complex logic on data events, it may quickly run up against database limits (known as DML Limits), computation limits (known as Apex CPU Time Limits), or even API limits.

For developers, there can be other difficulties on the platform. Though Salesforce is beginning to create developer-friendly tools and ecosystems (known collectively as Salesforce DX, or SFDX), current offerings make code deployments difficult, time-consuming, unreliable, and inconsistent. Because the state of a product largely exists in an environment (as opposed to a source-code repository), developer environments, the release pipeline, and the production environment can all have different states at any given time. Additionally, for almost all Salesforce customizations, developers are required to use Salesforce-specific languages. These language restrictions have an ancillary implication beyond just limiting things like developers' choices and the pool of available developers. If a company ever decides that Salesforce is no longer the right PaaS for their needs, they will be forced to re-write all of their customizations into a non-Salesforce language.

When Not to Use Heroku

While Salesforce offers strong support for companies that need common industry products with little to no customization, Heroku instead offers basic building blocks to facilitate complete customization. However, since Heroku's key features have already been covered, it is instructive to discuss its drawbacks for a fair comparison.

Resources

Because Heroku focuses more on giving developers a clean slate to build upon, it doesn't have pre-built products like Salesforce. For instance, if a company with a small IT department needs a basic CRM tool to help manage sales, it would be far more costly and time-consuming to spend the effort developing and maintaining a custom CRM. To build it in-house, the product team would need to accommodate legal and business requirements for user data, handle database management, design customer experiences and user interfaces, construct asynchronous tasking, and much, much more. Consider the effort needed to manage the database alone, including security, efficient queries, data relationships, caching, concurrency, and scalability. While these complexities are reasonable for larger companies with a big staff, smaller companies may not see an acceptable ROI with a custom-built solution.

Pricing Differences

As noted above, Salesforce primarily bills customers on a per-user-license rate. Heroku primarily bills customers based on add-ons, enterprise features, and dyno usage. Add-ons are determined by the agreement between the add-on provider and the customer. Enterprise features may either bill by whether or not the feature is used or as a multiplier for another cost factor. For instance, Private Spaces have both a base cost and use a multiplier on each dyno running within the Private Space. This means that a dyno running in a Private Space consumes more of a customer's dyno units than a regular dyno. The dyno cost is calculated based on the number of dynos, the amount of time those dynos were used, and other factors, like whether or not the dyno is a performance dyno or within a Private Space. Given all of these variables, it is plain to see that the arithmetic needed to forecast or predict a bill is much more complex than Salesforce.

Final Comparison

Salesforce and Heroku approach product development and maintenance from different angles. Salesforce is more prescriptive in that it favors customers who need well-tread products that support a common way of interacting with data.

  • While Salesforce markets itself as being a platform for complete out-of-the-box functionality all the way to completely custom products, it clearly trends towards the former.
  • Heroku offers complete customization though at the expense of pre-packaged products.

It is true that customers can use or purchase add-ons that provide certain aspects of application needs, such as database hosting, message queues, real-time stream-processors, and the like. However, none of these add-on packages can be used as a stand-alone replacement for a Salesforce product, such as CRM. Both approaches are valuable and can be empowering for companies but offer different avenues through which companies can create value.

Heroku + Salesforce

Earlier in this article, readers learned some of the shortcomings - both deliberate and unintentional - of Salesforce. Salesforce has done a masterful job at helping companies to create great-looking customer experiences that also have layers of security on top of customer data. Given that Salesforce uses a multi-tenant architecture, the controller layer (the glue that connects the data to the user interface) has strict boundaries and limits enforced for all customers. This can become a headache or, more accurately a nightmare for customers with complex business logic or custom functionality, as these computations will often run up against Salesforce's limits. When this situation is imminent or already occurring, Heroku can be used to reduce the computation footprint of a Salesforce customer.

Extending Salesforce Via Salesforce API's

Salesforce provides several different methods of programmatic interaction with the platform. This includes SOAP and REST API's and higher-level API's built on top of these technologies, such as Chatter REST, Bulk, Streaming, and Apex web service API's. These API's allow a customer to have more control over Salesforce data. In addition to making Salesforce data accessible, these API's also allow customers to process data off-platform and receive the results later, such as on-demand number crunching, scheduled data grooming, and administrator-initiated events.

The SOAP, REST, Chatter REST, and Bulk API's allow external platforms to perform basic database functions on Salesforce data. The Streaming API provides a publish-subscribe model that allows external platforms to subscribe to data changes on Salesforce. The Apex REST and SOAP API's go a step further and allow customers to create public-facing API endpoints for their Salesforce applications. With the multitude of API's that Salesforce provides, it is easy for platforms and applications to integrate with Salesforce, whether or not the applications are built on Heroku. Because Salesforce has embraced common web technologies for their API's, the effort required to connect external resources to the platform is much more reasonable than one might think.

Extending Salesforce Via Heroku Connect

In addition to supporting a bevy of API's, Salesforce partnered with Heroku to create Heroku Connect. To the developer, Heroku Connect appears to be a set of PostgreSQL tables that happen to contain Salesforce data. Behind the scenes, Heroku Connect maintains a bi-directional sync of data for a Salesforce org. As data changes are applied to the data in a Heroku Connect table, the modified data is synced to Salesforce in near-real-time. Likewise, as data changes in a connected Salesforce org, the data is updated in the corresponding Heroku Connect table. The net result of this syncing is a unified view of data as it exists in Salesforce. This removes the idea of having to think about callbacks, requests and responses, promises, sessions, and many of the other components required to interact with API's. Once Heroku Connect is set up, developers can focus on developing.

Because data arrives as row updates and not API calls, developers may be concerned about their ability to be notified of new data and respond to the data. Thankfully, PostgreSQL natively supports event triggers. Much like Salesforce Apex triggers, PostgreSQL event triggers may be constructed to fire on changes to tables or rows. In this way, developers need only concern themselves with adding functionality to the platform allowing Heroku Connect to support the interface between Salesforce and Heroku.

Last but certainly not least, Salesforce whitelists Heroku Connect calls from its standard API limits. This means that Heroku Connect transactions are essentially "free" for Salesforce customers. As a company's business processes continue to grow and push the boundaries of Salesforce, it will be a relief to know that computation can be offloaded to Heroku without creating additional stress on other Salesforce-connected external integrations.

Wrapping Up

As noted before, the multi-tenant nature of Salesforce can create tension for customers who are constantly adding functionality to their organization. While Salesforce does a great job of displaying and storing data, computational limits often inhibit larger customers from running complicated and intensive calculations on that data. To alleviate this problem, Salesforce customers can use Heroku to offload these calculations and store the results once completed. This pattern is already gaining adoption by [Salesforce customers and vendors] (https://www.youtube.com/watch?v=SYg_LLNDCgw) to make their Salesforce orgs more stable and scalable.

How to Integrate Heroku with Salesforce

Now that we've discussed the benefits of using Heroku in concert with Salesforce, let's see what this partnership looks like in action. This demo uses Heroku Connect to highlight how well both platforms work together.

Getting Set Up

If you'd like to follow along with this demo, you will need a free [Salesforce Developer Edition environment](https://developer.salesforce.com/signup) and a [Heroku account](https://signup.heroku.com). The application source code and detailed instructions may be found at the [project's GitHub repository](https://github.com/shawalli/contact-card)6

Creating Your Very Own Contact Card App

Contact Card, the app that you are about to create, is a sample application that demonstrates some core aspects of Heroku Connect. The application displays all Salesforce contacts in a searchable table. By clicking on a particular contact, the user may view the information for that contact. Additionally, the user is able to edit the contact's information and save those changes back to Salesforce.

Create The App

First, you will need to create a new Heroku application, install the sample application code, configure the database, and start the server. Sounds scary, right? This historically complex, brittle, time-consuming process is now just two button-clicks thanks to a Heroku Button. Navigate to the [Contact Card project repository](https://github.com/shawalli/contact-card), and click the purple "Deploy to Heroku" button in the Readme. Once logged into Heroku, scroll down to the bottom of the page and click the (also purple) "Deploy app" button. After a few moments, all of the build statuses should have green check marks, and two buttons will appear. Click the "View" button to open your brand-new app. See? Two clicks were all it took to stand-up a new application from start to finish!

"The Heroku Button is a configuration that describes how to set up an application. This free feature from Heroku is perfect for demos (like this one!) and generic microservices and products. Once deployed, the application can be modified using standard Heroku development flows."

Configure Salesforce

Next, we need to setup our connection with our Salesforce org. On your app, click the blue "Connect Salesforce Environment" button. Once on the app's dashboard page, select the Heroku Connect item (under the Add-ons section), then click the purple "Setup Connection" button. After choosing DATABASE_URL, clicking Next, then clicking Authorize, you should be prompted with a Salesforce login. Login with your credentials and then click Allow Access, which allows your shiny new app to connect to your Salesforce org.

Because Heroku Connect supports all database actions against Salesforce, it needs a way to ensure that record creations and updates are race-condition-safe. Without going down a technical rabbit hole, let's just say that Heroku needs a way to mark new records as originating from Heroku when syncing the records to Salesforce. The instructions for creating this field, known as an external ID field, may be found in the [Configure Salesforce Environment section] (https://github.com/shawalli/contact-card#congure-salesforce-environment) of the repository Readme. Once this step is complete, pop back over here.

Create Mapping

The last remaining item in this configuration is setting up the actual database mapping from Salesforce to Heroku, which is done on your app's Heroku Connect page. Follow the instructions in the [Configure Heroku Connect Mapping section](https://github.com/shawalli/contact-card#congure-heroku-connect-mapping) of the Readme to create the mapping. This mapping tells Heroku how to map Objects and fields from Salesforce into tables and columns in Heroku. Once the mapping is complete, modifying Salesforce data is as simple as modifying rows in the PostGreSQL database locally in Heroku.

After the mapping is complete, hop back over to the tab containing your app. Refresh the page, and you should be greeted with a list of contacts that matches the contacts in your Salesforce org.

Final Thoughts

This contrived example demonstrates a simple use-case for Heroku Connect. In the real world, Heroku and Heroku Connect can be used in conjunction with Salesforce to do much more complex things. Use Heroku Connect to pipe large volumes of data to dynos that can crunch the data and return results back to Salesforce. Build customer-facing applications that funnel surveys, feedback, service cases, and other types of customer data back into Salesforce for your employees to consume and analyze. Construct B2B integrations that are easy to maintain in universally-known languages, without giving external developers access to your entire org and data. In short, begin to see Salesforce and Heroku as individually powerful platforms, with complementary strengths and weaknesses. Apart, they are satisfactory, useful platforms. But together, they can take your business to a whole new level.

1 - [https://devcenter.heroku.com/articles/how-heroku-works#defining-an-application](https://devcenter.heroku.com/articles/how-heroku-works#defining-an-application)

2 - [https://devcenter.heroku.com/articles/stack](https://devcenter.heroku.com/articles/stack)

3 - [https://devcenter.heroku.com/articles/slug-compiler](https://devcenter.heroku.com/articles/slug-compiler)

4 - [https://devcenter.heroku.com/articles/buildpacks](https://devcenter.heroku.com/articles/buildpacks)

5 - [https://www.heroku.com/private-spaces](https://www.heroku.com/private-spaces)

6 - [https://github.com/shawalli/contact-card](https://github.com/shawalli/contact-card)