LET’S UNDERSTAND HEROKU
MY TAKE:
#TLDR
As a developer, I like to focus on development and Heroku lets me do that. I can write code & push it out without worrying about infrastructure, scaling, setting up configurations. That’s all Heroku’s job. It’s fantastic — a true time saver and super easy to get started.
WHAT
Heroku is a Platform-as-a-Service (PaaS). It allows you to build a custom application and deploy it to their servers without any code changes. Heroku will then manage all the complexity of hosting and running the application.
WHY
The value in using a service like Heroku is in the development workflow. You can build an application on your local computer just like you normally would. Then use common Git commands to deploy your application. It makes the processes of deploying, configuring, scaling, tuning, and managing apps as simple and straightforward as possible, so developers can focus on what’s most important: building great apps that delight and engage customers. The idea is have a place where devs in a company can deploy their apps that can truly run and expand in cloud rather than having some dev run a script on their laptop that the company relies on.
It’s extremely easy to start and you don’t need to deal with the infrastructure. For startups that don’t want to spend time and money on setting up their configurations it’s fantastic — a true time saver.
HOW
It’s extremely easy to get started with Heroku. Onboarding is real quick and easy. We don’t need to deal with the infrastructure. It really just works. For startups that don’t want to spend time and money on setting up their configurations it’s fantastic — a true time saver. These are following must-to-know commands in Heroku to get started. All one has to do is to run these commands and Heroku would be up & running:
- Download
- Login
- Prepare the app
- Clone the Heroku demo app
- Create using your app
4. Deploy the app
- Create
- Push
- URL generated, open in browser
UX FLOWS
- COMMAND LINE
The heroku command-line tool is an interface to the Heroku Platform API and includes support for things like creating/renaming apps, running one-off dynos, taking backups, configuring add-ons and managing your app’s state.
2. GIT WORKFLOW
Heroku uses the Git workflow. You just need to do a ‘git push heroku master’ to push out to Heroku and they will take care of the rest for you (restarting, installing gems, updating files and starting the app again). If you are already using Git for your version control system then this will feel very natural to you.
3. HEROKU DASHBOARD + METRICS
Dashboard is where you manage all of your apps and organizations, scale your deployments up or down, and manage databases and add-ons. The new Heroku Dashboard makes all of this much easier and more intuitive, with thoughtfully designed workflows and UI.
- Heroku Metrics — a feature within Dashboard available to apps running more than one dyno, gives you powerful insights on the runtime characteristics of your applications, allowing you to seamlessly monitor and fine tune performance within your regular workflow. You have direct visibility into your app’s throughput, response time, errors, memory, and CPU load data, all delivered in an intuitive display designed to help you spot and resolve problems. (https://www.heroku.com/dx)
4. HEROKU FLOWS
Heroku Flow is a flexible way to structure, support, and visualize Continuous Delivery for Heroku apps from development to production. It makes CD visual, easy to manage, and accessible to all team members from design, to engineering, to product management, to QA and testers. It does this with the support of three features and integrations:
- Pipelines: a clear and structured workflow for a group of apps that share the same codebase. Apps can be “promoted” to the next stage in the Pipeline with a click in the web interface, or by using the CLI. In either case, the relationship between the stages of your apps in the Pipeline is always clearly diagrammed live on the Pipelines page.
The Pipelines interface facilitates and visualizes the best practices in CD that we all know and love: frequent iteration, test, deployment to staging, and promotion to production. The “Pipeline,” strictly speaking, is a clear and structured workflow for a group of apps that share the same codebase. Initially there are four stages: “review” (read on), “development,” “staging,” and “production.”
2. Guthub Sync: automatic or manual deployment of Pull Requests (PRs) on branches to staging apps
3. Review apps: automatic creation of a disposable “Review App” for each new GitHub PR. Review Apps provide easier and better testing for features and fixes in isolation, and Pipelines provides better structure for testing and deploying the resulting app. It’s all part of Heroku Flow: better structure for teams to iterate, test, deploy, and run software
You can read more about it from here: (http://blog.heroku.com/archives/2015/9/3/heroku_flow_pipelines_review_apps_and_github_sync)
- HEROKU BUTTON
It is a simple HTML or Markdown snippet that can be added to READMEs, blog posts and other places where code lives. Clicking a Heroku Button will take you through a guided process to configure and deploy an app running the source code referenced by the button.
- DYNOS
I like this one. A single thing to scale up and down.
A dyno is a lightweight Linux container that runs a single user-specified command. A dyno can run any command available in its default environment (what we supply in the Cedar stack) or in your app’s slug (a compressed and pre-packaged copy of your application and its dependencies).
Adding more web dynos allows you to handle more concurrent HTTP requests, and therefore higher volumes of traffic.Heroku runs dynos in three different ways:
- Web Dynos: Web dynos are dynos of the “web” process type that is defined in your Procfile. Only web dynos receive HTTP traffic from Heroku’s routers.
- Worker Dynos: Worker dynos can be of any process type declared in your Procfile, other than “web”. Worker dynos are typically used for background jobs, queueing systems, and timed jobs. You can have multiple kinds of worker dynos in your application. For example, one for urgent jobs and another for long-running jobs. For more information, see Worker Dynos, Background Jobs and Queueing.
- One-off Dynos: One-off dynos are temporary dynos that can run detached, or with their input/output attached to your local terminal. They’re loaded with your latest release. They can be used to handle administrative tasks, such as database migrations and console sessions. They can also be used to run occasional background work, as with Heroku Scheduler. For more information, see One-Off Dynos
- ORGANIZATION ACCOUNTS
Organization accounts help you manage Heroku applications as a business or other kind of group.With an organization account you can:
- Treat your apps as a shared collection
- Give a group of developers selective access to each app in the collection
- Monitor resource usage across the entire organization
- Seamlessly add new members and remove departing members, ensuring the right people have the right level of access to each app at all times.
- ORGANIZATION USERS AND APPLICATION ACCESS
An organization can have any number of each role, but must have at least one admin user. In addition to their member role in the organization, members can be assigned app privileges on specific apps owned by the organization.
Users can be managed from the Access page of an app in the Org Dashboard
Two-factor authentication is a Heroku platform security feature. When an user enables 2FA on their account, they are required to log on with a verification code in addition to their username and password, for additional security.
- OAUTH
OAuth provides a way to authorize and revoke access to your account to yourself and third parties. Third parties can use this to provide services, such as monitoring and scaling your applications. You can also use these tokens obtained with OAuth to grant access for your own scripts on your machine or to other applications.
- Web application authorization allows third parties to ask for and gain access to the resources of a Heroku user, which they can then use to provide services and features on top of the Heroku platform.
- Heroku API (https://devcenter.heroku.com/articles/oauth#scopes)
THINGS TO CONSIDER
- ADVANTAGES
- No Ops (Almost) — Developers can focus on product development rather on managing infrastructure — this is especially relevant for small start-up’s who need to roll their code quickly into production and focus on new features, not Ops.
- Easy setup — as a PaaS you don’t need to know how to install and configure Apache, nginx, unicorn, passenger, MySQL, Postgres etc
- Easier to scale initially — spin up more dynos, size up DBs etc.
- Great plugin support for third party apps
- Disadvantages
- You cannot control the exact configuration of your application with Heroku, in terms of hardware, OS, firewall, versions etc. You have to use their standards (for me it was non-issue so far).
- For high volume applications, they charge premium. Meaning you might end up paying for them more than you would have paid for comparable capacity in EC2.
- Lock-In — since you aren’t managing your infrastructure you can’t move it to take advantage of savings
- Performance — Not surprisingly , multiple Heroku Dyno’s are running on same EC2 instances under separate namespaces (containers); on large scale infrastructures ,with serious traffic this can cause a serious performance problem, which eventually can impact your business.
- Dyno is a “Black Box” ; you cannot SSH to your Dyno and debug a memory/cpu/disk io/network bottleneck.
COMPETITORS
- Cloud Foundry
- Open Shift
- Google App Engine
- Engineyard
- Appfog
- App42Paas
CONCLUDE
If I have to pick, Heroku Dynos, Heroku Button and Heroku flows are my top picks if I want to use Heroku.
