I have an app running happily on Heroku, but it's registered as a 'development' app, and I can't for the life of me find any formal definition of what a 'production' app is, despite the apps dashboard and the status page making a very clear distinction between the two.
I have come across this explanation of the status of the two, which suggests that the difference is implicit (based on usage) rather than explicit (based on some configuration / setup):
Production issues are those that affect running, stable, production applications that have at least two web dynos and use a production-grade database (or no database at all). Includes dynos, database, HTTP caching, other platform components (DelayedJob workers, scheduler, etc.), and routing.
Development issues are those that affect the health of deployment workflow and tools. Includes deployment (git push, gem installation, slug compilation, etc.), general git activity, command line gem/API (scaling up/down, changing configuration, etc.), and related services (rake, console, db push/pull with TAPS, etc.). Development also includes issues specific to the operation of non-production applications such as unidling free 1-dyno apps and the operation of development databases.
Even these explanations reference a mysterious difference between development and production databases, although there is no corresponding explanation of the difference anywhere. Is the $9pcm 'Basic' Postgres plan a 'production' database?
[UPDATE]
There is now a 'Run Production Check' link on the app dashboard within your Heroku account that shows the steps to determine your app status. Screenshot attached:
I've been trying to find the same answer to your question.
So far from what I can glean Shared / Dev / Starter databases via Heroku Postgresql Database plans are not considered production and only Crane and higher are consider production grade database plans.
The Heroku Postgres production tier starts with Crane and extends through to the Mecha plan. Shared, Dev and Starter plans are not production databases.
https://devcenter.heroku.com/articles/maximizing-availability
In addition, it seems that Heroku has a plugin to check to see if your app meets their guidelines:
https://github.com/heroku/heroku-production-check
I'm not sure if you scale up and down web dynos from 2 (during the day) and 1 (at night) with a Crane database if that would be considered "production" in Heroku's eyes.
Hope that helps!
Related
I'm using Heroku's Pipeline feature to manage the stages of my application. I received an email about Heroku getting rid of their free plans, so I went ahead and upgraded my plan just now. Currently, I have one app with two database add-ons in Heroku. This is the first time that I've used their Pipeline feature—and I'm by no means a Heroku expert. I have two questions:
Do I need to purchase dynos for every new app that I use Heroku for? The plan that I ended up purchasing was the Production plan (since the app is for a client), and I also purchased two psql database add-ons which are attached to the app.
Since I'm using their pipeline for my one app, I have staging and prod versions of the app assigned to their appropriate branches in the repo. The prod app is where I upgraded to the paid plan. Do I need to purchase any dynos or add-ons for the staging app within the Pipeline? I was able to attach the databases with no issue, but I purchased a dyno for the staging app just to be safe.
Feel free to share any of your favorite Heroku alternatives as well—I'm only using Heroku because that's what I learned how to use in school.
Fellow Heroku user here!
Do I need to purchase dynos for every new app that I use Heroku for?
Yes. Heroku have basically said they’re getting rid of free plans for all applications due to wanting to make more money security reasons. So staging apps will also fall under this.
Basically, it sounds like there’s going to be no free tier dynos or first party add-ons from Heroku going forward. They do suggest for non-production apps (like testing and staging apps) to turn your dynos on when in use, and off when not in use, and you’ll only be billed for the time the dyno is on.
I‘m not sure which plan is the Production plan (I couldn’t see it on the pricing page) but maybe try out Hobby first. I have multiple apps running with paid Hobby-tier dynos and they have ran just fine without really spiking the CPU or memory available in those dynos. But I’m running PHP apps, so your milage may vary if you’re using another tech stack, or do get more load than my apps.
I understand how to create and deploy code to a staging environment on Heroku before deploying it to production. I understand that it is good to see if the code will "blow up" in a very similar environment than the one in production.
However, I can't figure out any tangible ways or mechanisms to determine if the application is broken on the staging environment.
In other words, I don't understand how having a running application on the staging environment is supposed to give me the confidence to deploy my application to production.
Hence my questions:
What additional steps are there to do on the staging environment on Heroku?
Are the integration tests supposed to be run on the staging environment?
If I note that the application is running on the staging environment, is it good enough?
A staging environment is intended just for that - to stage, or to "rehearse" an app version, before you promote it to production.
Heroku pipelines enable you to deploy a staging app in an environment as identical as possible to your production app, to reduce "but it worked in my dev environment" problems.
What you do with your app on the staging environment is up to you. You can consider using various simulation tools to simulate live users who would be accessing your production app. You might have migrations that you need to perform on your production app's data, so you could run them first in your staging app. You can have testers working with your staging app to verify everything works as intended before promoting to production.
Bottom line: Whatever you can do with your production app, you should be able to do with your staging app. Therefore, you should strive to achieve a deployment flow whereby BEFORE promoting a version to production, whatever scenarios may occur on production should first be tested on staging. How you achieve that is up to you.
What additional steps are there to do on the staging environment on Heroku?
Visually catch any broken CSS + HTML (which is a very difficult task with currently testing tools)
You might have other members in your team (SEO specialist, Marketing Manager, etc) which wants to inspect text, meta tags, etc. Having a staging environment will just make their life much easier as they can navigate and probe, propose improvements, etc
In your development machine you and other team members may have a different environment than you have running on production (different DB OS versions and third party services (.i.e Elasticsearch, Redis, etc) just to name a few.
You want to test deployment itself (you might have a series of tasks that are triggered during deployment)
The list of benefits and advantages of having a staging environment as close as possible as your production environment goes on...
Are the integration tests supposed to be run on the staging environment?
Normally you run your automated tests in a CI server (not on staging). Staging is just there to visually test and maybe to catch an error not covered yet by your test scenarios
If I note that the application is running on the staging environment, is it good enough?
Good enough is difficult to say (your staging environment may not be a perfect copy of your production environment), but if it is well tested, it should be very close to what you expect to see running in production
I am deploying a packaged liberty server into Bluemix that contains my application.
I want to update my application but before I do so, I'm wondering what's the best way to backup what I have currently up and running? If my update is bad, I would like to restore the previous version of my app.
In other words, what is the best practice or recommended way to update a web application running on a Liberty server in Bluemix. Do I simply keep a backup of the zip I pushed to Bluemix and restore it if something goes wrong? Or is there management capability provided by Bluemix for backup and restore?
It's understood that manual backup of the pushed zip is an acceptable strategy. Additionally, I found the Bluemix documentation Blue-green deployments to be a reasonable solution, as it's a deployment technique that utilizes continuous delivery and allows clients to rollback their app in the case of any issues.
The Cloud Foundry article Using Blue-Green Deployment to Reduce Downtime and Risk succinctly explains the deployment steps (since Bluemix is based on Cloud Foundry, the steps are similar to the Example: Using the cf map-route command steps in the previously cited Bluemix documentation).
I agree with Ryan's recommendation to use the blue/green approach, though the term may be unfamiliar to those new to cloud server deployments. Martin Fowler summarizes the problem it addresses in BlueGreenDeployment:
One of the challenges with automating deployment is the cut-over
itself, taking software from the final stage of testing to live
production. You usually need to do this quickly in order to minimize
downtime. The blue-green deployment approach does this by ensuring you
have two production environments, as identical as possible. At any
time one of them, let's say blue for the example, is live. As you
prepare a new release of your software you do your final stage of
testing in the green environment. Once the software is working in the
green environment, you switch the router so that all incoming requests
go to the green environment - the blue one is now idle.
Solving this problem is one of the main benefits of PaaS.
That said, for historical context, it's worth noting this blue/green strategy isn't new to cloud computing. Allow me to elaborate on one of the "old" ways of handling this problem:
Let's assume I have a website hosted on a dedicated server, myexample.com. My public-facing server's IP address ("blue") would be represented in the DNS "#" entry or as a CNAME alias; another server ("green") would host the newer version of the application. To test the new application in a public-facing manner without impacting the live production environment, I simply update /etc/hosts to map the top-level domain name to the green server's IP address. For example:
129.42.208.183 www.myexample.com myexample.com
Once I flush the local DNS entries and close all browsers, all requests will be directed to the green pre-production environment. Once I've confirmed all works as expected, I update the DNS entry for the live environment (myexample.com in this case). Assuming the DNS has a reasonably short TTL value like 300 seconds, I update the A record value if by IP or CNAME record value if by alias and the change will be propagated to DNS servers in minutes. To confirm the propagation of the new DNS values, I comment out the aforementioned /etc/hosts change, flush the local DNS entries, then run traceroute. Assuming it correctly resolves locally, I perform a final double-check all is well in the rest of the world with the free online DNS checker (e.g., whatsmydns.net).
The above assumes an update to the public-facing content server (e.g., an Apache server connecting to a database or application server); the switch over from pre-production to production is more involved if the update applies to a central database or similar transactional data server. If it's not too disruptive for site visitors, I disable login and drop all active sessions, effectively rendering the site read-only. Then I go about updating the backend server in much the same manner as previously described, i.e., switching a pre-production green front end to reference a replication in the pre-production green backend, test, then when everything checks out, switch the green front end to blue and re-enable login. Voila.
The good news is that with Bluemix, the same strategy above applies, but is simplified since there's no need to fuss with DNS entries or separate servers.
Instead, you create two applications, one that is live ("blue") and one that is pre-production ("green"). Instead of changing your site's DNS entries and waiting for the update to propagate around the world, you can update your pre-production application (cf push Green pushes the new code to your pre-production application), test it with its own URL (Green.ng.mybluemix.net), and once you're confident it's production-ready, add the application to the routing table (cf map-route Green ng.mybluemix.net -n Blue), at which point both applications "blue" and "green" will receive incoming requests. You can then take the previous application version offline by unmapping it (cf unmap-route Blue ng.mybluemix.net -n Blue).
Site visitors will experience no service disruption and unlike the "old" way I outlined previously, the deployment team (a) won't have to bite their nails waiting for DNS entries to propagate around the world before knowing if something doesn't work and (b) can immediately revert to the previous known working production version if a serious problem is discovered post-deployment.
You should be using some sort of source control, such as Git or SVN. Bluemix is nicely integrated with IBM DevOps Services (IDS) which can leverage git or an external Github repo to manage your project. When you open your app's dashboard, you should see a link in the upper right-hand corner that says "ADD GIT". That will automatically create a git repo for your project in IDS.
Using an SCM tool, you can manage versions of your code with relative ease. IDS provides you with an ability to deploy directly to Bluemix as part of your build pipeline.
After you have your code managed as above, then you can think about green/blue deployments, etc. as recommended above.
Apart from Technology support , what are all the business benefits for oracle web logic server. For example in area of security,support etc.
What are all the new features supported by weblogic ?
TL;DR:
Support is great when you open ticket with Oracle Support (Weblogic strictly).
Great admin/read-only user implementation. We authenticate to Windows Active Directory. Developers get read-only accounts, reduces churn for them to wait for ops to transfer logs and validate settings.
Dashboard useful out-of-box to do real-time monitoring without additional tools or installs. Easily accessed by any one who is authenticated to login. We could give it to our CIO if he wanted in about 3 minutes by adding him to the right authorized group in AD.
Easier to clone environments.
I haven't worked with OC4J but I believe Oracle's roadmap is picking Weblogic as their preferred Java application server. You can see it is the base technology for some of their other products, such as Oracle Service Bus, Oracle Enterprise Manager (OEM), and Oracle Line Planning.
I have opened 3 Oracle tickets in the past month. I was surprised at how fast they answered. For a Severity 3 ticket (medium), they usually have responded in 2-3 days. I can't say the same for their other services (over 2 weeks for a ticket on OEM).
Security is a pretty broad scope... so you'd have to be a little more specific on some of the topics of security.
One thing that is pretty awesome is the Dashboard. http://docs.oracle.com/cd/E14571_01/web.1111/e13714/dashboard.htm You can obviously add read-only monitor accounts so other users can get insight to the performance. We add developers to this so that they can validate any settings, or see performance whenever there is a production issue.
We used Microsoft Active Directory authentication in our Weblogic domains. People are not using the default weblogic administrator user so configuration changes are audited. When someone's account gets disabled when leaving the company, it disables their access to Weblogic similarly. You don't have to change the password.
Other useful settings I like in it is the ability to automatically archive config changes. Each time someone makes a config change, a backup is automatically created. This allows me to go fix something when developers break their environment without having to majorly reverse-engineer what they did.
I also like the fact that you can pack and unpack the domains. I've used it to move entire domains from staging to production with some minor changes... i.e. change all stg to prod variables. This should likewise make it easier to 'clone' environments when you want to build out a new one.
Although not related, I should mention Oracle Enterprise Manager. We are an Oracle shop because they seem to have given us a good deal on licencing. So we get to run Oracle Enterprise Manager, which is a tool slowly becoming more and more useful. The agent also reports how our RedHat Linux hosts are behaving, network input/output, CPU utilization, memory utilization, java heap stacks. We are going to move to defining groups within that has all the targets related to an application stack. This will give our operations team the insight to see where the bottleneck might be... the Oracle Weblogic web layer, network, Oracle Service Bus, or Oracle Database performance.
Supposedly, you can add jBoss, other JMX monitoring as well to OEM. It's on our to-do list for non-Weblogic instance. We're slowly rolling OEM out.
I just started learning Ruby on rails and I was wondering what Heroku really is? I know that its a cloud that helps us to avoid using servers? When do we actually use it?
Heroku is a cloud platform as a service. That means you do not have to worry about infrastructure; you just focus on your application.
In addition to what Jonny said, there are a few features of Heroku:
Instant Deployment with Git push - build of your application is performed by Heroku using your build scripts
Plenty of Add-on resources (applications, databases etc.)
Processes scaling - independent scaling for each component of your app without affecting functionality and performance
Isolation - each process (aka dyno) is completely isolated from each other
Full Logging and Visibility - easy access to all logging output from every component of your app and each process (dyno)
Heroku provides very well written tutorial which allows you to start in minutes. Also they provide first 750 computation hours free of charge which means you can have one processes (aka Dyno) at no cost. Also performance is very good e.g. simple web application written in node.js can handle around 60 - 70 requests per second.
Heroku competitors are:
OpenShift by Red Hat
Windows Azure
Amazon Web Services
Google App Engine
VMware
HP Cloud Services
Force.com
It's a cloud-based, scalable server solution that allows you to easily manage the deployment of your Rails (or other) applications provided you subscribe to a number of conventions (e.g. Postgres as the database, no writing to the filesystem).
Thus you can easily scale as your application grows by bettering your database and increasing the number of dynos (Rails instances) and workers.
It doesn't help you avoid using servers, you will need some understanding of server management to effectively debug problems with your platform/app combination. However, while it is comparatively expensive (i.e. per instance when compared to renting a slice on Slicehost or something), there is a free account and it's a rough trade off between whether it's more cost effective to pay someone to build your own solution or take the extra expense.
Heroku Basically provides with webspace to upload your app
If you are uploading a Rails app then you can follow this tutorial
https://github.com/mrkushjain/herokuapp
As I see it, it is a scalable administrated web hosting service, ready to grow in any sense so you don't have to worry about it.
It's not useful for a normal PHP web application, because there are plenty of web hosting services with ftp over there for a simple web without scalability needs, but if you need something bigger Heroku or something similar is what you need.
It is exposed as a service via a command line tool so you can write scripts to automate your deployments. Anyway it is pretty similar to other web hosting services with Git enabled, but Heroku makes it simpler.
That's its thing, to make the administration stuff simpler to you, so it saves you time. But I'm not sure, as I'm just starting with it!
A nice introduction of how it works in the official documentation is:
https://devcenter.heroku.com/articles/how-heroku-works
Per DZone: https://dzone.com/articles/heroku-or-amazon-web-services-which-is-best-for-your-startup
Heroku is a Platform as a Service (PaaS) product based on AWS, and is vastly different from Elastic Compute Cloud. It’s very important to differentiate ‘Infrastructure as a Service’ and ‘Platform as a Service’ solutions as we consider deploying and supporting our application using these two solutions.
Heroku is way simpler to use than AWS Elastic Compute Cloud. Perhaps it’s even too simple. But there’s a good reason for this simplicity. The Heroku platform equips us with a ready runtime environment and application servers. Plus, we benefit from seamless integration with various development instruments, a pre-installed operating system, and redundant servers.
Therefore, with Heroku, we don’t need to think about infrastructure management, unlike with AWS EC2. We only need to choose a subscription plan and change our plan when necessary.
That article does a good job explaining the differences between Heroku and AWS but it looks like you can choose other iaas (infrastructure) providers other than AWS. So ultimately Heroku seems to just simplify the process of using a cloud provider but at a cost.