Categories
Development Salesforce Technology type-recorder

Heroku and Other Cloud Services

Learn about Heroku and where it fits into the mix of Cloud Services as well as why I think that it is one of the best services for launching a web app.

Interested in building a web application? There are a bunch of tools out there and services to consider when it comes to building and hosting an application. This article discusses different types of cloud services for supporting web applications, and it specifically talks about the benefits of using Heroku for quickly launching a web application.

Heroku (in my opinion) provides the perfect space to quickly setup, test, deploy, and launch your application. And for small businesses, hobbyists, and those who simply want to learn and teach themselves, Heroku makes it easy to get started for free.

Disclaimer

This article is not affiliated with Heroku – the recommendations made here are the recommendations and opinions of type-recorder only. type-recorder is not compensated by Heroku in any way for or through this article.

Please perform your own additional and comprehensive research when making decisions for yourself or for your business regarding cloud service selection and website development/hosting tools.

Why did you write this article?

Good question. It’s an especially good question when you consider that I appear to really be selling Heroku in this article’s opening paragraph.

I wrote this article because I built type-recorder on Heroku. Heroku made the job of building type-recorder straightforward and (I would say) fun. As I will discuss in this article, Heroku allowed me to not have to worry about the complicated infrastructure pieces involved in hosting a web application – I only had (and have) to really worry about the application itself. I want to share the tools and methods that I used to get type-recorder off the ground with anyone that might be interested in building their own web application. I also want to help give others a better understand of the different cloud tools/services available to individuals and businesses for developing applications.

Building type-recorder has given me a terrific avenue to improve my knowledge of application development, website hosting, source control, and so on. Plus, it has allowed me to work on building a brand and a business (however small). The project has turned into a huge learning experience for me, and it is something that (at the very least) I can add to my portfolio. I highly encourage any techies as well as any wannabe techies interested in building an application for themselves to do so (with whatever tools that you want to use)! You will learn and reinforce a lot!

What is Heroku

Heroku (owned by Salesforce) is a PaaS (Platform as a Service). A PaaS system is a cloud service that is (usually) generally available to the public, used to build and host custom applications. Heroku, specifically, is a PaaS that allows users to build and host web applications built in modern application languages and framworks. For more information on Heroku from Heroku, see What is Heroku. (Now, say Heroku three times fast.)

What is a PaaS

As mentioned, a PaaS or Platform as a Service is a cloud service.

What’s a Cloud Service?

A cloud service is a service that is available (for free or for a fee) to users over the internet that would traditionally require hardware if the cloud service did not exist. A simple example of a cloud service is Google Photos. Normally, or maybe I should say “in the old days,” you would need a hard-drive to store photos. Today, you can store photos in the cloud on services like Google Photos or Google Drive, and you do not need to have a large hard-drive somewhere to keep those photos. The other awesome thing about storing photos in the cloud is that you can access them from anywhere and from any device, and you don’t need to worry about losing your photos if you lose your hard-drive(s).

Cloud services abstract away the infrastructure required to perform those services so that users only need to focus on what the services allow them to do. Looking at Google Photos again, users only need to think about their photos, making sure that they get loaded into Google Photos, making sure that any tags are applied to the photos as desired, editing the photos as desired, and so on. Users of the service don’t have to worry about where the photos are physically stored, how they are stored, making sure the storage drives are on or hooked up to the internet, or any of the concerns one might associate with managing the infrastructure required to store photos.

Cloud Services: IaaS, PaaS, SaaS

So we know conceptually what a cloud service is, and we know that there is a type of cloud service known as a PaaS (Platform as a Service). As you may have guessed (or as you may already know), there are multiple types of cloud services. Here is a list of the ones that I am fully aware of along with common tools that fit within each category.

Cloud ServiceExamples
IaaS: Infrastructure as a Service– Google Cloud
– Amazon Web Services
– Microsoft Azure
– DigitalOcean
PaaS: Platform as a Service– Heroku
– Salesforce.com
– AWS Elastic Beanstalk
– Google App Engine
SaaS: Software as a Service– Atlassian
– Zoho
– Slack
– Microsoft 365
– Google Photos
Cloud Service types and well-known examples of each type

Note: Some consider Salesforce to be a SaaS instead of a PaaS. If your business primarily uses Salesforce’s out-of-the-box capabilities, then yes, I would agree from that perspective. However, if your business, like many businesses, leverages Salesforce’s capabilities to build out custom solutions, tools, integrations, and the like, than I would argue that Salesforce is being used as a platform.

Another Note: Through my (albeit brief) research on this subject, I have found that the definitions for what may or may not be considered SaaS or Paas, or IaaS, or none of the above are somewhat varied. Some arguments (like this one from an IBM blog post in 2014) suggest that any software that provides a service through the internet and that does not require download/installation and additional hardware by a user is inherently XaaS. This would include Facebook, Google, and any web application out there. Others, however, argue that applications/tools may only fall in the XaaS realm if their business model is such that users subscribe to the services and pay a monthly or annual fee for the services (see this thread on Quora, or this blog post by SaaStr). With all of that said, I suggest understanding the concepts of Cloud Services and what differentiates IaaS, PaaS, and Saas so that you can make your own determination.

To understand the differences between IaaS, PaaS, and SaaS, we can break out, at a high level, the pieces of infrastructure that are required to support a software application.

  • Applications – the service or tool that an end-user interacts with
  • Data – this encompasses the metadata (the definition of the data) as well as the data itself
  • Runtime – the libraries necessary to run an application
  • Middleware – software used to connect an application to external applications via a standardized set of APIs
  • OS – the operating system that allows all programs to interact with a computer
  • Virtualization – creation of virtual resources to support multi-tenancy in large scale computing systems that support large numbers of users and large numbers of highly complex tasks
  • Servers – the physical computers that any and all software tasks and programs are completed on
  • Storage – the physical databases that store information
  • Networking – routers, cables, WiFi, and the tools needed to allow separate computers to talk to one another

Not all software tools will use all of these pieces, but these pieces are required for any comprehensive application with a front-end for user interaction, a processing layer (back-end) for computing, sending, and transforming data, and a storage component for storing data. Think GMail, Box, Slack, etc. Most user facing applications will use most, if not all, of these components.

In most cases, an application is the thing being supported by a cloud service, whether that application is hosted by the cloud service or somewhere else.

The fundamental difference between the types of cloud services is in what pieces of infrastructure the cloud service provider manages and controls and what pieces the provider allows the user to manage and control:

Diagram from Microsoft Learn depicting the resources involved in running a software application and who is responsible for managing those resources in each category (IaaS, PaaS, SaaS). On-premises is the scenario where all of an applications resources and support framework are entirely owned and managed without the use of a cloud service.

On-premises in the diagram above illustrates the scenario where you acquire, manage, and maintain the entire physical infrastructure required to host an application. The on-premises scenario does not involve a cloud service. Though there may be valid scenarios requiring the use of on-premises solutions, this article, as mentioned, focuses on cloud services.

SaaS

As we can see from the diagram above from Microsoft Learn (check out their learning module on Types of Cloud Services), the entire underlying framework for a SaaS tool including the application itself is completely managed by the service provider. If you think about GMail (a SaaS), all of the underlying components like the storage of email and the sending/delivery of email are managed by Google (the service provider). Users access GMail over the internet. You do not have to download and install anything on your own computer, and you do not need your own email Server even if you have a custom domain (example@myCustomDomain.com) – you simply pay Google to set it up and maintain it for you.

SaaS solutions are targeted at specific needs like GMail for email management, Google Photos for photo storage, Microsoft 365 (Word, Excel, PowerPoint) for office tools, or Jira for business productivity. SaaS providers make money by charging a monthly or annual fee to users for use of their tools (though a number of SaaS solutions are free for individuals).

PaaS

With SaaS, the application is already built for you. What if you wanted to build your own custom application that allowed you to input/output/transform data as needed and desired by you and/or your business? That’s where PaaS comes in.

For users that want to develop custom applications without worrying about the setup and maintenance of additional layers (such as determining the servers, operating systems, runtimes, databases, and so on), a PaaS solution is optimal. A PaaS provider handles all of the items indicated in the graphic above, and it leaves the actual application and data definition to the application developer (you).

For instance, if you want to build an application in Python for users to be able to log in and upload and share their favorite quotes, you could do this with a PaaS. You would develop the Python application to allow users to create an account, log in, and upload a quote. You would define how the quote gets uploaded and where it gets saved (do you have the user fill out a form on your website and enter some text, or do you let the user upload a file?). You also define the user experience and how your application looks/feels. When you are done, or as you continue to build out new features, you deploy your application to your PaaS host. The PaaS gives you a framework and infrastructure to host and run your application after you’ve developed it and as you work to maintain and improve it. You may have to build your application locally (on your own computer) depending on what capabilities the PaaS offers, but after deploying your application to the PaaS, it will run from there. It won’t matter if your computer is on or off, or at the bottom of the ocean at that point.

As a PaaS user, you pick an application framework and language (from what is supported by your PaaS*), and you define the type of data that your application will handle (and how it will handle it). Again, the beauty here is that you don’t have to spend tons of time setting up servers, managing traffic, or keeping operating systems up to date. Your main focus is on the application itself, how it looks, how efficiently the code is written, and so on.

* As mentioned in parentheses above, you choose your language and application framework from options that are supported by your given PaaS, and these options may vary between different PaaS systems. Due to the fact that PaaS systems manage and maintain the underlying infrastructure to build and host applications, only certain application frameworks and languages are supported based on the whatever the PaaS system and infrastructure has been optimized for. Thus, if you are building an application in Salesforce, you can only build your application using Salesforce tools (Apex, Visualforce, Lightning, etc.). Heroku, on the other hand, offers support for a wider range of more common languages/frameworks (Python, Go, Scala, Java, Node.js, and others).

IaaS

What if you want more control? What if you want to use an uncommon, unsupported (or maybe even proprietary) application language and framework ? How about a complex scenario where multiple custom, complex applications need to be supported, connected, and available to end-users with seasonal or variable demand?

IaaS is where you turn here. IaaS solutions give users more control (as indicated by the diagram above). Users can set up virtual machines or containers that will run their applications. Users can specify the operating systems used on these virtual machines in order to support their custom application frameworks, and users can implement middleware solutions to connect applications together.

Google, AWS, Microsoft Azure, and DigitalOcean are cloud service providers and are bucketed as IaaS providers because they provide a range of cloud tools and services that allow users/businesses to fully manage and customize their technology stack in the cloud. For example, within a single IaaS system, a business could set up an array of resources to support its business operations:

  • Multiple databases with specific type (relational, no-SQL, etc.), security, and space requirements
  • Virtual Machines where operating systems and scripts can be specified
  • Load Balancers to manage traffic and resource demands
  • Big Data Tools for IoT
  • AI Tools for Natural Language processing
  • And the list goes on…

Why Heroku

Essentially because it is straightforward, well-documented, and user friendly. Heroku supports a clearly specified set of languages and frameworks, it offers clear documentation for getting up and running, and it is very easy to create an account.

Why use Heroku over Google, AWS, Microsoft Azure, or DigitalOcean?

For one thing, the UI is not littered with a million different options 🙄! Plus (I think) the documentation is easier to find and navigate.

The big IaaS players (Google, Amazon, Microsoft, DigitalOcean, and others) offer a ton of services. They even offer services like the following that group together their other services in order to make it easy for users to launch and scale applications:

Elastic Beanstalk, App Engine, and App Service are basically PaaS systems analogous to Heroku in that they manage the underlying infrastructure required to launch and host an application.

So Google Cloud, AWS, or Microsoft Azure are viable alternatives to Heroku?

Yes, most definitely. I suggest Heroku, though, over these solutions because Heroku is simpler. The Heroku platform is targeted at hosting applications built in specific languages and frameworks, and it removes all of the extra frills, headache, and mumbo-jumbo associated with the larger IaaS providers. I mean, just take a look at the sheer quantity of services under the Products tab on AWS and Google Cloud compared to Heroku. (It’s really intimidating when you look at all of the options under Services after logging into your AWS console.)

For someone like me, interested in quickly building applications in popular coding languages, Heroku is perfect. I don’t want to spend lots of time setting up my environments or databases, thinking about scaling and system maintenance. I don’t want to have to sift through boatloads of information to understand and use my hosting platform.

Granted, many people want to learn more about (and/or want more control over) the underlying components of a web application. To those persons, I say go forth, immerse yourself, and use Google, AWS, Microsoft Azure, DigitalOcean, or any other tools that you wish.

Why use Heroku as opposed to Wix, Squarespace, WordPress, etc.?

The answer to this has to do with the difference between a website and a web application, which I want to highlight in this article.

A Website

Wix, Squarespace, and WordPress are terrific tools and services for building custom websites, but they are not optimized for creating custom web applications.

A standalone website to showcase a product, a brand, a blog, or a portfolio is powerful. Any legitimate entity is expected to have a website in our current day and age. Wix, Squarespace, WordPress, and other website builders are great tools for setting up, configuring, designing, and even launching a website for these purposes. These website builders also allow users to market and sell products through their websites, capture contact information for mailing lists, and share calendars, photos, and other content. A number of these capabilities are often provided through plugins and add-ons that make building a traditional website super easy.

Though there is some capturing and sending of data, the fundamental focus of a traditional website is on its front-end and the data presented to the user.

A Web Application

A web application has a front-end (HTML, CSS, JS, etc.) like a traditional website with pages, images, and other content for users to interact with, but in addition, a web application has a back-end (Java, Node.js, Python, etc.) for processing and transforming data. The front-end and back-end of a web-application are closely tied together (usually with a web application framework), passing data back and forth to display data to and capture input from the user. Building a custom application requires the ability to define and host the front and back-ends.

As an example type-recorder (😁) is a custom web application. The website shows users information, and it accepts data (text) as an input. That text data is sent from the front-end to the Node.js back-end. The back-end interacts with an API from Microsoft Azure Cognitive Services to transform the text data into audio data. Finally, that audio data is further manipulated by the back-end and sent to the front-end to be presented to the user.

Heroku because…

Again, because it is the simple option for those looking to build an application (as opposed to building a website or a blog).

For those looking to build a website, I think Heroku is a solid option to consider when your site is highly custom with custom styling (let’s say you are using Sass or Less), and/or a highly dynamic front-end with lots of JavaScript. Adding custom CSS or JS in common website builders can be cumbersome (if not allowed).

That said, if you only want to build a site for your portfolio, for your political campaign, or for your line of watches that you sell on Amazon, then a website is all you need, and any one of the website builders out there are worth looking at. For the same reasons that I suggest using Heroku over a more complex solution provider for a straightforward web application, I would suggest using a website building over Heroku for a straightforward website.

Why not Heroku?

I hope that my explanation of and comparison between different cloud services has already answered this question, but I will reiterate the main points and add a couple additional ones here.

You may not want to use Heroku because

  1. Heroku doesn’t support the application tools that you want to use to build your application.
  2. Heroku is overkill for your needs.
  3. Heroku does not meet your hardware/software specifications or it does not give you the necessary control that you require over operating systems, databases, middleware, etc., and you want to manage all of these items through one service provider.
  4. You don’t want to build a web application, but instead want to use an existing tool or service.
  5. You want to learn about and become familiar with other service providers and/or the underlying components required to support an application.
  6. The cost for Heroku is too high or doesn’t make sense for your business model.
    • I personally think that the price is reasonable, especially considering that you can host an application for free while you are building it.
    • Other service providers, though, offer more granular control over and insight into costs because you determine what resources you use to support your application.
    • You may prefer a service provider with on-demand pricing options for an application, for example, where the number of requests to the application are highly variable.
  7. You just don’t want to use Heroku.

Heroku isn’t for everyone, but for people that want to quickly rock-and-roll with a popular web application framework, I think it is the ultimate choice!

Get Started with Heroku

If you are interested in trying Heroku and launching an app (whether you are an experienced dev pro or more of a novice), I highly recommend going through a Heroku Getting Started Guide. Pick the guide for the given language that you want to develop your app in.

I recommend starting from the beginning and going through each step carefully. If you do that, then you will have an app up and running! From there, you can customize your app entirely as you wish, and you can create your own git repository for it to keep it safe.

Going forward, I know that if I want to quickly build a web application, I simply need to

  1. Grab the appropriate Heroku Getting Started Guide for the language that I want to develop in.
  2. Go through the guide and clone the template app code locally (to my own computer).
  3. Associate my local code with my own remote Git repository so that I can make and save changes/versions at will.
  4. Deploy the app (following the guide) to Heroku.

From there, I would have my own application up and running on Heroku! I would be able to customize and iterate on the app to meet my needs and goals.

Key Resources

Thanks!

Thanks for reading. I’d love your feedback on this article – please leave a comment below.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.