How to Understand Heroku and PaaS Systems - Brightwork Research & Analysis

Table of Contents: Select a Link to be Taken to That Section

Executive Summary

Cloud service providers that are highly concentrated in IaaS tend to get most of the emphasis.
A purpose-built PaaS can be critical in getting the most from IaaS concentrated cloud services.

Introduction

Cloud services like AWS/GCP and Azure provide some PaaS options, but it is generally not their focus. Purpose built PaaS solutions tend to be less heralded in the marketplace. However, effective third party PaaS allows not only for better leveraging of IaaS service providers but also provides independence between the PaaS and the IaaS.

PaaS with Heroku

An important way of improving the management of microservices is through the use of a PaaS. This is covered in the following quotation from the PaaS provider Heroku.

“That said, microservices are not a free lunch. Each service has its own overhead, and though that cost is reduced by an order of magnitude by running in a PaaS environment, you still need to configure monitoring and alerting and similar services for each microservice. Microservices also make testing and releases easier for individual components, but incur a cost at the system integration level. Plan for how will your system behave if one of the services goes offline.”

AWS and Google Cloud are offering this not as virtualization have been attempted in the past on a limited number of servers but against an ocean of servers. Essentially, Oracle is arguing for bare metal or dedicated servers (as usually is the case with Oracle), but this will always have a price, and lacks the sophistication of cloud, as it puts one right back into hosting.

Oracle does not have the same ability to either have AWS’s cloud capacity, nor do they have AWS’s sophistication in containerization. Therefore they have to argue that dedicated servers are the way to go because this is what Oracle has to offer.

Maintaining Independence Between the PaaS, the Container Management Service, and the IaaS

The IT media generally presents SAP, Oracle, AWS, and Google Cloud as all offering PaaS. This is incorrect. SAP and Oracle would like to offer PaaS, but don’t yet offer much at all. Their “PaaS” allows a few items to be set up (very slowly and with great inefficiency). Still, they lack nearly all of the functionalities of a PaaS, that are readily observable in PaaS like Heroku. AWS and Google Cloud don’t appear that interested in offering PaaS of any real significance, preferring to focus on just IaaS.

Heroku is a pure PaaS. It configures the IaaS but offers far less choice than the IaaS. This is a great video on Heroku.

Things Heroku Does Well

Developers give Heroku high marks for keeping the things they don’t want to worry about, such as scaling, version and release management, DNS and SLL, and managing development boxes in the background and allowing them to focus on the code. Furthermore, the collaboration aspects are a strong motivator to use Heroku.

This is expressed in the following quotation from Heroku.

“The Heroku Platform is designed so you can focus on what matters the most: the app. Getting apps out in the wild, in front of real users, and then iterating fast, is what can make or break companies. Heroku lets companies of all sizes embrace the value of apps, not the hassle of hardware, nor the distraction of servers — virtual or otherwise. The Heroku Platform is great for the early part of the app lifecycle, but it really shines when you go into production. Heroku seamlessly supports every step of the app lifecycle — build, run, manage and scale. Heroku Postgres provides trusted database options at terabyte scale. Dyno choices to suit your needs, including performance dynos for your highest traffic apps — all scalable in an instant. Heroku keeps the kernel up-to-date with the latest security patches. All backed by the trust and reliability of Salesforce.”

We developed our application, Brightwork Explorer without Heroku, but the more we looked into it, the more we wished we have leveraged Heroku. PaaS solutions like Heroku allow companies to scale their development far more efficiently, as is covered in the following quotation.

“Fundamentally, a PaaS provides you with a container, an abstraction in which you house your software. All of the supporting technologies discussed above, from load balancing to independent scaling and process monitoring, are provided by the platform, outside of your container. Without such providers, deploying even a single monolithic app can take whole teams of IT operations specialists. However, with a PaaS, the range of people qualified to deploy applications grows to include generalists like application developers or even project managers, reducing deployment effort to near-zero. For instance some of our customers have no one devoted full-time to IT operations, and can deploy to countries all over the world made by any developer on the team. With the advent of PaaS, microservice deployment has become a reasonable endeavor.”

The PaaS Market

The overall PaaS market is a confusing mixture of development environments, which includes Heroku, Outsystems, Apprenda, and Engine Yard, with each having various pros and cons. The use of the right PaaS requires a deep understanding of the development requirements, and one of the issues with selecting a PaaS is that they usually have specific advantages for some programming languages versus others. For instance, Heroku started as a project for the Ruby language, but then added other languages later. In 2012 Gartner predicted that the PaaS market would become 2% of the overall revenues for the cloud market. The PaaS market seems quite “siloed,” and while IaaS has grown enormously and grabbed the headlines, the PaaS market appears to have stagnated.

Our interpretation is that AWS would rather farm that work out to partners as they grow Lambda. AWS sees the platform market as overhyped with low long-term value add. Eventually, everything will be a service invoked on one of the Functions as a Service (FaaS) frameworks. Moreover, there are now Azure Functions and Google Functions and others, but practically speaking, Lambda dominates this space. Google Cloud appears similarly unfocused about the PaaS market. The closest thing Google Cloud offers to a PaaS is their App Engine. However, this is also like Elastic Beanstalk more of a deployment tool than a PaaS. That is one interpretation; another is that IaaS providers are not particularly adept at creating PaaS environments.

If we looked at an outsider’s view of the PaaS offering, it might look something like the following table.

With cloud componentry, the devil is really in the details. The first problem with this table is that of the services offered by SAP, Oracle, AWS, or Google Cloud, only Google Cloud’s App Engine and Elastic Beanstalk can be considered to be a PaaS. Also, even there, we are shrinking the scope of PaaS from what we think is ideal or what we would recommend. Realistically, while it makes sense to use App Engine, it makes the most sense to use it more to simply setup components to be addressed by an outside PaaS than as a PaaS itself. Alternatively, to run functions against “serverless” services. The App Engine restricts the development in multiple ways to the Google Cloud.

Nevertheless, they are all commonly placed with the classification of PaaS providers.

There are plenty of books that explain how these different components can be used in conjunction with one another. Again, because of the ability to test, items can be selected to use based upon using them to try to get work done. Docker is quite popular, but there are other container management services as well, such as Cloud Foundry. Cloud Foundry also works well with either Docker or AWS EC2 Container Service or Google Cloud Kubernetes. Cloud Foundry emphasizes the exact issue of independence in the following quote.

“Cloud Foundry removes the complexities of developing applications by decoupling the application from its infrastructure, so that organizations can make a business decision on where to host workloads – on premise, in public clouds, or in managed infrastructures.”

A second important feature illustrated by this table is that is shows if one selects a true PaaS like Heroku allows IaaS independence. If one chooses to use AWS Elastic Beanstalk or Google Cloud App Engine, one not only loses out on PaaS functionality, but independence is also lost.

Using both an independent PaaS and container management system is an excellent way to maintain IaaS independence. As the costs of AWS and Google Cloud are incurred by usage, it is not a scenario where one must choose to use only one or the other. Doing so reduces flexibility and will potentially increase the costs of the overall solution. Furthermore, we only cover AWS and Google Cloud in this book. Still, there also may be other IaaS providers that have a beneficial service that is desirable to access, if only in a limited way. Docker has an enormous amount of support in the IaaS providers. This is generally referred to as the multicloud approach. This means not only running on multiple IaaSs but also in private, public, hybrid environments. Cloud Foundry proposes it can allow companies to move applications between environments in “90 seconds.”

The MultiCloud Approach and PaaS

Multicloud is the most common approach to using cloud services, as is covered in the following quotation from the Rightscale 2017 State of the Cloud Report.

“Companies that use public cloud are already running applications in an average of 1.8 public clouds and experimenting with another 1.8 public clouds. While fewer companies are using private clouds, those that do use more, running applications in an average of 2.3 private clouds and experimenting with an additional 2.1 private clouds.”

What is interesting is how much this increased in the same study the following year.

“Respondents are already running applications in 3.1 clouds and experimenting with 1.7 more for a total of 4.8 clouds.”

The Downside of PaaS Independence

However, maintaining PaaS and IaaS independence does have a downside. That downside is that any technical issues between the PaaS and the IaaS can often leave the customer in a no man’s land, where neither the PaaS provider nor the IaaS provider will take the support ticket.

Furthermore, using Docker combined with Heroku (or other independent PaaS) allows for both the PaaS and the container service to be independent of the IaaS. Moreover, the advantages of Heroku versus Google Cloud App Engine are highlighted in the following quote.

“In terms of databases, you have both relational and non-relational choices in PostgreSQL, MongoDB, Cloudant, and Redis. This highlights Heroku’s massive advantage over AppEngine – Heroku’s database-platform choices reflect a collection that is in widespread use already in the wider world. It’s relatively easy to port your DB from Oracle to PostgreSQL because they are both relational, for example, but good luck trying to move your relational DB to the non-relational BigTable. It can be done, but it’s an expensive (in terms of time) and painful exercise. Heroku’s infrastructure is hosted on Amazon’s EC2 could servers.

Overall though, the sentiment in the developer community (that’s the crowd that mainly uses PaaS’s) is that AppEngine is a missed opportunity by Google because of its closed-in, proprietary nature and lack of platform choices. Heroku offers few restrictions on what can and can’t be done in your hosted app, and you also have powerful access to the user space your application runs in.”

Dynos Manager

Now Heroku offers a proprietary container management solution called Dynos Manager. Still, for us, it makes more sense to use Docker, again keeping the PaaS and the container management solution independent.

This is key, because when a new development is begun, it may not be immediately apparent which IaaS it should access. With PaaS/Container Management System/IaaS independence, one can switch between IaaS providers when the opportunity presents itself. Secondly, a deep functionality PaaS like Heroku provides enormous collaborative development benefits.

This is an excellent time to point out that the term PaaS means different things to different people. This elasticity in the term only serves to increase the confusion around PaaS. We are using the term in its broader sense to describe solutions that we considered to support development fully. When others write on the subject of PaaS, they often include offerings that we would find too bare bones.

It should also be considered that using independent components in this way will typically reduce the direct costs paid for the various components (Heroku is a premium priced component, for instance), but may reduce the overall costs or the total costs. The total costs include the efficiency of developers and others involved in the process.

Even AWS, when compared to Google Cloud, does not have the same costs, with AWS being higher, but compensating with a broader offering. Of course, that by no means ends the discussion, as there all manner of other implication to using AWS versus Google Cloud – and one may want to use some AWS services with Google Cloud services. We, of course, have accounts with both. Moreover, an independent PaaS and container management systems allow you to connect to both.[i]

We, of course, can’t produce a cost breakdown in this book of all the components used together under every possible use case. We merely acknowledge that these decisions to impact both the immediate costs and the total costs.

If we think of SAP and Oracle, their entire orientation is to lock in customers to their “full cloud stack” even though SAP and Oracle lack a true cloud stack. Moreover, for instance, SAP connects to an IaaS, (as we illustrated earlier in the book) their pricing vis-à-vis AWS shows that they markup the IaaS cost enormously. It is essentially taxing customers at the highest possible margins to access a service that anyone can access from AWS (or Google Cloud or Azure) for one-tenth of the prices. These specifics should make it apparent why it is difficult to take anything that SAP or Oracle say about the cloud seriously.

The Future is PaaS, or Wait Maybe FaaS?

AWS describes Lambda, their “serverless” compute service as follows:

“Lambda can be described as a type of serverless Function-as-a-Service (FaaS). FaaS is one approach to building event-driven computing systems. It relies on functions as the unit of deployment and execution. Serverless FaaS is a type of FaaS where no virtual machines or containers are present in the programming model and where the vendor provides provision-free scalability and built-in reliability.”

Search Our Other PaaS Content

References

[i] https://cloud.google.com/files/esg-whitepaper.pdf