Alternatives to AppHarbor logo
Heroku, Google App Engine, AWS Elastic Beanstalk, Apollo, and OpenShift are the most popular alternatives and competitors to AppHarbor.
11
13
+ 1
28

What is AppHarbor?

AppHarbor is a fully hosted .NET Platform as a Service. AppHarbor can deploy and scale any standard .NET application to the cloud.
AppHarbor is a tool in the Platform as a Service category of a tech stack.

AppHarbor alternatives & related posts

Heroku logo

Heroku

7.5K
5.2K
3.1K
7.5K
5.2K
+ 1
3.1K
Build, deliver, monitor and scale web apps and APIs with a trail blazing developer experience.
Heroku logo
VS
AppHarbor logo
Compare Heroku vs AppHarbor
Heroku logo
Heroku
VS
AppHarbor logo
AppHarbor

related Heroku posts

Tim Nolet
Tim Nolet
Founder, Engineer & Dishwasher at Checkly · | 17 upvotes · 119.9K views
atChecklyHQChecklyHQ
vuex
vuex
Knex.js
Knex.js
PostgreSQL
PostgreSQL
Amazon S3
Amazon S3
AWS Lambda
AWS Lambda
Vue.js
Vue.js
hapi
hapi
Node.js
Node.js
GitHub
GitHub
Docker
Docker
Heroku
Heroku

Heroku Docker GitHub Node.js hapi Vue.js AWS Lambda Amazon S3 PostgreSQL Knex.js Checkly is a fairly young company and we're still working hard to find the correct mix of product features, price and audience.

We are focussed on tech B2B, but I always wanted to serve solo developers too. So I decided to make a $7 plan.

Why $7? Simply put, it seems to be a sweet spot for tech companies: Heroku, Docker, Github, Appoptics (Librato) all offer $7 plans. They must have done a ton of research into this, so why not piggy back that and try it out.

Enough biz talk, onto tech. The challenges were:

  • Slice of a portion of the functionality so a $7 plan is still profitable. We call this the "plan limits"
  • Update API and back end services to handle and enforce plan limits.
  • Update the UI to kindly state plan limits are in effect on some part of the UI.
  • Update the pricing page to reflect all changes.
  • Keep the actual processing backend, storage and API's as untouched as possible.

In essence, we went from strictly volume based pricing to value based pricing. Here come the technical steps & decisions we made to get there.

  1. We updated our PostgreSQL schema so plans now have an array of "features". These are string constants that represent feature toggles.
  2. The Vue.js frontend reads these from the vuex store on login.
  3. Based on these values, the UI has simple v-if statements to either just show the feature or show a friendly "please upgrade" button.
  4. The hapi API has a hook on each relevant API endpoint that checks whether a user's plan has the feature enabled, or not.

Side note: We offer 10 SMS messages per month on the developer plan. However, we were not actually counting how many people were sending. We had to update our alerting daemon (that runs on Heroku and triggers SMS messages via AWS SNS) to actually bump a counter.

What we build is basically feature-toggling based on plan features. It is very extensible for future additions. Our scheduling and storage backend that actually runs users' monitoring requests (AWS Lambda) and stores the results (S3 and Postgres) has no knowledge of all of this and remained unchanged.

Hope this helps anyone building out their SaaS and is in a similar situation.

See more
Ganesa Vijayakumar
Ganesa Vijayakumar
Full Stack Coder | Module Lead · | 15 upvotes · 200.9K views
SonarQube
SonarQube
Codacy
Codacy
Docker
Docker
Git
Git
Apache Maven
Apache Maven
Amazon EC2 Container Service
Amazon EC2 Container Service
Microsoft Azure
Microsoft Azure
Amazon Route 53
Amazon Route 53
Elasticsearch
Elasticsearch
Solr
Solr
Amazon RDS
Amazon RDS
Amazon S3
Amazon S3
Heroku
Heroku
Hibernate
Hibernate
MySQL
MySQL
Node.js
Node.js
Java
Java
Bootstrap
Bootstrap
jQuery Mobile
jQuery Mobile
jQuery UI
jQuery UI
jQuery
jQuery
JavaScript
JavaScript
React Native
React Native
React Router
React Router
React
React

I'm planning to create a web application and also a mobile application to provide a very good shopping experience to the end customers. Shortly, my application will be aggregate the product details from difference sources and giving a clear picture to the user that when and where to buy that product with best in Quality and cost.

I have planned to develop this in many milestones for adding N number of features and I have picked my first part to complete the core part (aggregate the product details from different sources).

As per my work experience and knowledge, I have chosen the followings stacks to this mission.

UI: I would like to develop this application using React, React Router and React Native since I'm a little bit familiar on this and also most importantly these will help on developing both web and mobile apps. In addition, I'm gonna use the stacks JavaScript, jQuery, jQuery UI, jQuery Mobile, Bootstrap wherever required.

Service: I have planned to use Java as the main business layer language as I have 7+ years of experience on this I believe I can do better work using Java than other languages. In addition, I'm thinking to use the stacks Node.js.

Database and ORM: I'm gonna pick MySQL as DB and Hibernate as ORM since I have a piece of good knowledge and also work experience on this combination.

Search Engine: I need to deal with a large amount of product data and it's in-detailed info to provide enough details to end user at the same time I need to focus on the performance area too. so I have decided to use Solr as a search engine for product search and suggestions. In addition, I'm thinking to replace Solr by Elasticsearch once explored/reviewed enough about Elasticsearch.

Host: As of now, my plan to complete the application with decent features first and deploy it in a free hosting environment like Docker and Heroku and then once it is stable then I have planned to use the AWS products Amazon S3, EC2, Amazon RDS and Amazon Route 53. I'm not sure about Microsoft Azure that what is the specialty in it than Heroku and Amazon EC2 Container Service. Anyhow, I will do explore these once again and pick the best suite one for my requirement once I reached this level.

Build and Repositories: I have decided to choose Apache Maven and Git as these are my favorites and also so popular on respectively build and repositories.

Additional Utilities :) - I would like to choose Codacy for code review as their Startup plan will be very helpful to this application. I'm already experienced with Google CheckStyle and SonarQube even I'm looking something on Codacy.

Happy Coding! Suggestions are welcome! :)

Thanks, Ganesa

See more

related Google App Engine posts

Nick Rockwell
Nick Rockwell
CTO at NY Times · | 9 upvotes · 9.7K views
atThe New York TimesThe New York Times
Kubernetes
Kubernetes
Google Kubernetes Engine
Google Kubernetes Engine
Google App Engine
Google App Engine
Amazon EC2
Amazon EC2
#Migration
#Cloudmigration
#AWStoGCPmigration
#GCP
#AWS

So, the shift from Amazon EC2 to Google App Engine and generally #AWS to #GCP was a long decision and in the end, it's one that we've taken with eyes open and that we reserve the right to modify at any time. And to be clear, we continue to do a lot of stuff with AWS. But, by default, the content of the decision was, for our consumer-facing products, we're going to use GCP first. And if there's some reason why we don't think that's going to work out great, then we'll happily use AWS. In practice, that hasn't really happened. We've been able to meet almost 100% of our needs in GCP.

So it's basically mostly Google Kubernetes Engine , we're mostly running stuff on Kubernetes right now.

#AWStoGCPmigration #cloudmigration #migration

See more

related AWS Elastic Beanstalk posts

Julien DeFrance
Julien DeFrance
Full Stack Engineering Manager at ValiMail · | 16 upvotes · 181.2K views
atSmartZipSmartZip
Amazon DynamoDB
Amazon DynamoDB
Ruby
Ruby
Node.js
Node.js
AWS Lambda
AWS Lambda
New Relic
New Relic
Amazon Elasticsearch Service
Amazon Elasticsearch Service
Elasticsearch
Elasticsearch
Superset
Superset
Amazon Quicksight
Amazon Quicksight
Amazon Redshift
Amazon Redshift
Zapier
Zapier
Segment
Segment
Amazon CloudFront
Amazon CloudFront
Memcached
Memcached
Amazon ElastiCache
Amazon ElastiCache
Amazon RDS for Aurora
Amazon RDS for Aurora
MySQL
MySQL
Amazon RDS
Amazon RDS
Amazon S3
Amazon S3
Docker
Docker
Capistrano
Capistrano
AWS Elastic Beanstalk
AWS Elastic Beanstalk
Rails API
Rails API
Rails
Rails
Algolia
Algolia

Back in 2014, I was given an opportunity to re-architect SmartZip Analytics platform, and flagship product: SmartTargeting. This is a SaaS software helping real estate professionals keeping up with their prospects and leads in a given neighborhood/territory, finding out (thanks to predictive analytics) who's the most likely to list/sell their home, and running cross-channel marketing automation against them: direct mail, online ads, email... The company also does provide Data APIs to Enterprise customers.

I had inherited years and years of technical debt and I knew things had to change radically. The first enabler to this was to make use of the cloud and go with AWS, so we would stop re-inventing the wheel, and build around managed/scalable services.

For the SaaS product, we kept on working with Rails as this was what my team had the most knowledge in. We've however broken up the monolith and decoupled the front-end application from the backend thanks to the use of Rails API so we'd get independently scalable micro-services from now on.

Our various applications could now be deployed using AWS Elastic Beanstalk so we wouldn't waste any more efforts writing time-consuming Capistrano deployment scripts for instance. Combined with Docker so our application would run within its own container, independently from the underlying host configuration.

Storage-wise, we went with Amazon S3 and ditched any pre-existing local or network storage people used to deal with in our legacy systems. On the database side: Amazon RDS / MySQL initially. Ultimately migrated to Amazon RDS for Aurora / MySQL when it got released. Once again, here you need a managed service your cloud provider handles for you.

Future improvements / technology decisions included:

Caching: Amazon ElastiCache / Memcached CDN: Amazon CloudFront Systems Integration: Segment / Zapier Data-warehousing: Amazon Redshift BI: Amazon Quicksight / Superset Search: Elasticsearch / Amazon Elasticsearch Service / Algolia Monitoring: New Relic

As our usage grows, patterns changed, and/or our business needs evolved, my role as Engineering Manager then Director of Engineering was also to ensure my team kept on learning and innovating, while delivering on business value.

One of these innovations was to get ourselves into Serverless : Adopting AWS Lambda was a big step forward. At the time, only available for Node.js (Not Ruby ) but a great way to handle cost efficiency, unpredictable traffic, sudden bursts of traffic... Ultimately you want the whole chain of services involved in a call to be serverless, and that's when we've started leveraging Amazon DynamoDB on these projects so they'd be fully scalable.

See more
Amazon ElastiCache
Amazon ElastiCache
Amazon Elasticsearch Service
Amazon Elasticsearch Service
AWS Elastic Load Balancing (ELB)
AWS Elastic Load Balancing (ELB)
Memcached
Memcached
Redis
Redis
Python
Python
AWS Lambda
AWS Lambda
Amazon RDS
Amazon RDS
Microsoft SQL Server
Microsoft SQL Server
MariaDB
MariaDB
Amazon RDS for PostgreSQL
Amazon RDS for PostgreSQL
Rails
Rails
Ruby
Ruby
Heroku
Heroku
AWS Elastic Beanstalk
AWS Elastic Beanstalk

We initially started out with Heroku as our PaaS provider due to a desire to use it by our original developer for our Ruby on Rails application/website at the time. We were finding response times slow, it was painfully slow, sometimes taking 10 seconds to start loading the main page. Moving up to the next "compute" level was going to be very expensive.

We moved our site over to AWS Elastic Beanstalk , not only did response times on the site practically become instant, our cloud bill for the application was cut in half.

In database world we are currently using Amazon RDS for PostgreSQL also, we have both MariaDB and Microsoft SQL Server both hosted on Amazon RDS. The plan is to migrate to AWS Aurora Serverless for all 3 of those database systems.

Additional services we use for our public applications: AWS Lambda, Python, Redis, Memcached, AWS Elastic Load Balancing (ELB), Amazon Elasticsearch Service, Amazon ElastiCache

See more
Apollo logo

Apollo

750
531
9
750
531
+ 1
9
GraphQL server for Express, Connect, Hapi, Koa and more
Apollo logo
VS
AppHarbor logo
Compare Apollo vs AppHarbor
Apollo logo
Apollo
VS
AppHarbor logo
AppHarbor

related Apollo posts

Adam Neary
Adam Neary
Engineer at Airbnb · | 26 upvotes · 231.6K views
atAirbnbAirbnb
Apollo
Apollo
GraphQL Playground
GraphQL Playground
GraphQL
GraphQL
#Prisma
#BackendDrivenUI

At Airbnb we use GraphQL Unions for a "Backend-Driven UI." We have built a system where a very dynamic page is constructed based on a query that will return an array of some set of possible “sections.” These sections are responsive and define the UI completely.

The central file that manages this would be a generated file. Since the list of possible sections is quite large (~50 sections today for Search), it also presumes we have a sane mechanism for lazy-loading components with server rendering, which is a topic for another post. Suffice it to say, we do not need to package all possible sections in a massive bundle to account for everything up front.

Each section component defines its own query fragment, colocated with the section’s component code. This is the general idea of Backend-Driven UI at Airbnb. It’s used in a number of places, including Search, Trip Planner, Host tools, and various landing pages. We use this as our starting point, and then in the demo show how to (1) make and update to an existing section, and (2) add a new section.

While building your product, you want to be able to explore your schema, discovering field names and testing out potential queries on live development data. We achieve that today with GraphQL Playground, the work of our friends at #Prisma. The tools come standard with Apollo Server.

#BackendDrivenUI

See more
Nick Rockwell
Nick Rockwell
CTO at NY Times · | 26 upvotes · 202.3K views
atThe New York TimesThe New York Times
Apache HTTP Server
Apache HTTP Server
Kafka
Kafka
Node.js
Node.js
GraphQL
GraphQL
Apollo
Apollo
React
React
PHP
PHP
MySQL
MySQL

When I joined NYT there was already broad dissatisfaction with the LAMP (Linux Apache HTTP Server MySQL PHP) Stack and the front end framework, in particular. So, I wasn't passing judgment on it. I mean, LAMP's fine, you can do good work in LAMP. It's a little dated at this point, but it's not ... I didn't want to rip it out for its own sake, but everyone else was like, "We don't like this, it's really inflexible." And I remember from being outside the company when that was called MIT FIVE when it had launched. And been observing it from the outside, and I was like, you guys took so long to do that and you did it so carefully, and yet you're not happy with your decisions. Why is that? That was more the impetus. If we're going to do this again, how are we going to do it in a way that we're gonna get a better result?

So we're moving quickly away from LAMP, I would say. So, right now, the new front end is React based and using Apollo. And we've been in a long, protracted, gradual rollout of the core experiences.

React is now talking to GraphQL as a primary API. There's a Node.js back end, to the front end, which is mainly for server-side rendering, as well.

Behind there, the main repository for the GraphQL server is a big table repository, that we call Bodega because it's a convenience store. And that reads off of a Kafka pipeline.

See more

related OpenShift posts

Conor Myhrvold
Conor Myhrvold
Tech Brand Mgr, Office of CTO at Uber · | 11 upvotes · 509K views
atUber TechnologiesUber Technologies
Apache Spark
Apache Spark
C#
C#
OpenShift
OpenShift
JavaScript
JavaScript
Kubernetes
Kubernetes
C++
C++
Go
Go
Node.js
Node.js
Java
Java
Python
Python
Jaeger
Jaeger

How Uber developed the open source, end-to-end distributed tracing Jaeger , now a CNCF project:

Distributed tracing is quickly becoming a must-have component in the tools that organizations use to monitor their complex, microservice-based architectures. At Uber, our open source distributed tracing system Jaeger saw large-scale internal adoption throughout 2016, integrated into hundreds of microservices and now recording thousands of traces every second.

Here is the story of how we got here, from investigating off-the-shelf solutions like Zipkin, to why we switched from pull to push architecture, and how distributed tracing will continue to evolve:

https://eng.uber.com/distributed-tracing/

(GitHub Pages : https://www.jaegertracing.io/, GitHub: https://github.com/jaegertracing/jaeger)

Bindings/Operator: Python Java Node.js Go C++ Kubernetes JavaScript OpenShift C# Apache Spark

See more
Michael Ionita
Michael Ionita
CTO at Walls.io GmbH · | 6 upvotes · 4.7K views
atWalls.ioWalls.io
OpenShift
OpenShift
Kubernetes
Kubernetes

We use Kubernetes because we decided to migrate to a hosted cluster (not AWS) and still be able to scale our clusters up and down depending on load. By wrapping it with OpenShift we are now able to easily adapt to demand but also able to separate concerns into separate Pods depending on use-cases we have.

See more
Azure Websites logo

Azure Websites

287
220
21
287
220
+ 1
21
Deploy and scale modern websites and web apps in seconds
Azure Websites logo
VS
AppHarbor logo
Compare Azure Websites vs AppHarbor
Azure Websites logo
Azure Websites
VS
AppHarbor logo
AppHarbor
Dokku logo

Dokku

96
83
58
96
83
+ 1
58
Docker powered mini-Heroku in around 100 lines of Bash
Dokku logo
VS
AppHarbor logo
Compare Dokku vs AppHarbor
Dokku logo
Dokku
VS
AppHarbor logo
AppHarbor
MongoDB Stitch logo

MongoDB Stitch

81
98
3
81
98
+ 1
3
Backend as a Service for web and mobile applications
MongoDB Stitch logo
VS
AppHarbor logo
Compare MongoDB Stitch vs AppHarbor
MongoDB Stitch logo
MongoDB Stitch
VS
AppHarbor logo
AppHarbor

related MongoDB Stitch posts

Jeyabalaji Subramanian
Jeyabalaji Subramanian
CTO at FundsCorner · | 23 upvotes · 143.8K views
atFundsCornerFundsCorner
Zappa
Zappa
AWS Lambda
AWS Lambda
SQLAlchemy
SQLAlchemy
Python
Python
Amazon SQS
Amazon SQS
Node.js
Node.js
MongoDB Stitch
MongoDB Stitch
PostgreSQL
PostgreSQL
MongoDB
MongoDB

Recently we were looking at a few robust and cost-effective ways of replicating the data that resides in our production MongoDB to a PostgreSQL database for data warehousing and business intelligence.

We set ourselves the following criteria for the optimal tool that would do this job: - The data replication must be near real-time, yet it should NOT impact the production database - The data replication must be horizontally scalable (based on the load), asynchronous & crash-resilient

Based on the above criteria, we selected the following tools to perform the end to end data replication:

We chose MongoDB Stitch for picking up the changes in the source database. It is the serverless platform from MongoDB. One of the services offered by MongoDB Stitch is Stitch Triggers. Using stitch triggers, you can execute a serverless function (in Node.js) in real time in response to changes in the database. When there are a lot of database changes, Stitch automatically "feeds forward" these changes through an asynchronous queue.

We chose Amazon SQS as the pipe / message backbone for communicating the changes from MongoDB to our own replication service. Interestingly enough, MongoDB stitch offers integration with AWS services.

In the Node.js function, we wrote minimal functionality to communicate the database changes (insert / update / delete / replace) to Amazon SQS.

Next we wrote a minimal micro-service in Python to listen to the message events on SQS, pickup the data payload & mirror the DB changes on to the target Data warehouse. We implemented source data to target data translation by modelling target table structures through SQLAlchemy . We deployed this micro-service as AWS Lambda with Zappa. With Zappa, deploying your services as event-driven & horizontally scalable Lambda service is dumb-easy.

In the end, we got to implement a highly scalable near realtime Change Data Replication service that "works" and deployed to production in a matter of few days!

See more
Cloud Foundry logo

Cloud Foundry

79
102
4
79
102
+ 1
4
Deploy and scale applications in seconds on your choice of private or public cloud
Cloud Foundry logo
VS
AppHarbor logo
Compare Cloud Foundry vs AppHarbor
Cloud Foundry logo
Cloud Foundry
VS
AppHarbor logo
AppHarbor
Apache Camel logo

Apache Camel

55
18
2
55
18
+ 1
2
A versatile open source integration framework
Apache Camel logo
VS
AppHarbor logo
Compare Apache Camel vs AppHarbor
Apache Camel logo
Apache Camel
VS
AppHarbor logo
AppHarbor
jFrog logo

jFrog

49
7
0
49
7
+ 1
0
Universal Artifact Management
    Be the first to leave a pro
    jFrog logo
    VS
    AppHarbor logo
    Compare jFrog vs AppHarbor
    jFrog logo
    jFrog
    VS
    AppHarbor logo
    AppHarbor
    PythonAnywhere logo

    PythonAnywhere

    43
    61
    19
    43
    61
    + 1
    19
    Micro PaaS for Python web apps. Develop and host Python from your browser
    PythonAnywhere logo
    VS
    AppHarbor logo
    Compare PythonAnywhere vs AppHarbor
    PythonAnywhere logo
    PythonAnywhere
    VS
    AppHarbor logo
    AppHarbor
    Envoyer logo

    Envoyer

    37
    23
    2
    37
    23
    + 1
    2
    A brand new way to deploy PHP and Laravel applications with zero downtime
    Envoyer logo
    VS
    AppHarbor logo
    Compare Envoyer vs AppHarbor
    Envoyer logo
    Envoyer
    VS
    AppHarbor logo
    AppHarbor
    Azure App Service logo

    Azure App Service

    35
    12
    0
    35
    12
    + 1
    0
    Build, deploy, and scale web apps on a fully managed platform
      Be the first to leave a pro
      Azure App Service logo
      VS
      AppHarbor logo
      Compare Azure App Service vs AppHarbor
      Azure App Service logo
      Azure App Service
      VS
      AppHarbor logo
      AppHarbor
      Convox logo

      Convox

      31
      36
      34
      31
      36
      + 1
      34
      Launch a Private Cloud in Minutes. The simplicity of Heroku. The power of AWS.
      Convox logo
      VS
      AppHarbor logo
      Compare Convox vs AppHarbor
      Convox logo
      Convox
      VS
      AppHarbor logo
      AppHarbor
      Hasura logo

      Hasura

      30
      44
      1
      30
      44
      + 1
      1
      An open source GraphQL engine that deploys instant, realtime GraphQL APIs on any Postgres database.
      Hasura logo
      VS
      AppHarbor logo
      Compare Hasura vs AppHarbor
      Hasura logo
      Hasura
      VS
      AppHarbor logo
      AppHarbor
      Deis logo

      Deis

      26
      36
      53
      26
      36
      + 1
      53
      Open Source PaaS that builds upon Docker and CoreOS to provide a lightweight PaaS with a Heroku-inspired workflow
      Deis logo
      VS
      AppHarbor logo
      Compare Deis vs AppHarbor
      Deis logo
      Deis
      VS
      AppHarbor logo
      AppHarbor
      Glitch logo

      Glitch

      22
      47
      4
      22
      47
      + 1
      4
      The easiest way to build apps and bots
      Glitch logo
      VS
      AppHarbor logo
      Compare Glitch vs AppHarbor
      Glitch logo
      Glitch
      VS
      AppHarbor logo
      AppHarbor
      Modulus logo

      Modulus

      21
      17
      18
      21
      17
      + 1
      18
      Hosting, Scaling, and Data for Node.js applications
      Modulus logo
      VS
      AppHarbor logo
      Compare Modulus vs AppHarbor
      Modulus logo
      Modulus
      VS
      AppHarbor logo
      AppHarbor