Creating pages with Nesta on Heroku - ruby

I am looking to roll a simple CMS with Ruby and preferably Sinatra. www.nestacms.com looks like a terrific candidate.
Some key objectives:
Allow business users to add/edit/remove pages (not via git but via app functionality)
Deploy on Heroku
As I understand, Nesta pages are generated by static page files in your deployment. Which is fine if you add via git and push to Heroku.
But if you're wanting to create pages (files) in a Heroku web app, this isn't possible due to Heroku's read-only file system.
Looking for help around:
Achieving objectives with Nesta and Heroku
Alternative approaches

Github has an editor to manipulate files and buttons to create/merge branches in browser.
You may want store your content related media on a cloud storage services (such as dropbox, google drive, cloudflare etc.) You also can connect/mount these storages like drives via WebDAV or some other tools depending on your prefered service provider & OS.
snap-ci offers free and easy to use integration service for automated tests and/or deployment (heroku or your VPS/server). When master branch changed github webhook triggers snap-ci and your website will deploy in average 1 minute.

Related

Juristic background for heroku hosted repositories

Heroku provides a quite easy way to host simple websites (e.g. via Nodejs, Expressjs) by linking a (public) github reposiory. The result is available via the subdomain appname.herokuapp.com.
What is the juristic background for that (or are there any precedent cases), as for example in Germany every webpage needs to provide an imprint and a privacy statement which I assume not many repositories provide. I assume heroku is not responsible for the content of their domain, are they?

Whats difference between heroku and github

What does it mean production in rails , whats the difference between using github and heroku at the same time . I used github for like a backup / how all of us gonna use heroku . Is it necessary ??
First I need to explain GIT
Git is a distributed version control and source code management (SCM) system with an emphasis on speed. Initially designed and developed by Linus Torvalds for Linux kernel development in 2005. Every Git working directory is a full-fledged repository with complete history and full version tracking capabilities, not dependent on network access or a central server.
GitHub is a web-based hosting service for software development projects that use the Git revision control system. The site provides social networking functionality such as feeds, followers and the social network graph to display how developers work on their versions of a repository.
Heroku (pronounced her-OH-koo) is a web host that uses the Git revision control system. When you push your code to Heroku using git it then builds your server just like you do when you use locate host but for everyone to see.
Heroku is a cloud application platform – a new way of building and deploying web apps. The service lets app developers spend their time on their application code, not managing servers, deployment, ongoing operations, or scaling.
GitHub is a web-based hosting service for projects which uses Git version control system(VCS) It's a code repository where you can store code for better collaboration & contribution. Anybody can contribute to your open source code via cloning it & github will make a branch of code. You can also purchase $9/mth to create private repositories for private collaboration. You can deploy code with Git but you need your own server to host that code.
Visit https://github.com/about
heroku is a PaaS(Platform as a service) web apps hosting service where you can build & deploy web apps. Build great web apps, collaborate & deploy as well with heroku.
Visit https://www.heroku.com/about
Heroku comes with it's own server so you can purchase hosting plan & deploy you web apps easily. In case of Github you need to purchase a separate server to host your web apps.
Github is well known for contribution & collaboration & Heroku is for backend stack available for collaboration & deploying easily.

Share a folder between Heroku App

For my project, I would like to be able to setup multiple websites (App) and according to the requirements from a clients, I will activate and setup modules. Those modules could be a news module, images viewer module and so on.
My engine, which consist of scripts and libraries that manage a few things such as the WebApp routing, the modules, user rights for the CMS. I would like to get this code shared among all my App to avoid unseless duplication.
I would like to know what's the best way to do this on Heroku since I am totally new to this (Heroku) and I am not totally sure if that is feasable.
Also, am I wrong to believe that each websites is an App even if basically the only difference between them are the template and a single setup file?
Thank you
If you have no experience with git get familiar with it.
I would suggest to have one application with different branches in which you keep the configuration specific to the instance.
You create an app instance for each website.
You push the specific branch to the specific app, e.g.
git push git#heroku.com:.git :master

Migrate Azure Web Site to Azure Cloud Service

I have a project and I'm planning to start the web app as an Azure Web Site and then migrate it to an Azure Cloud Service (also called Hosted Service) if it is needed as a scale strategy.
The decision is because I read that Azure Web Sites are more simple and fast to develop with almost no Azure-specific configurations or code. So starting fast and simple is a good starting point for the project.
But, is that a good starting point for you?
Is migrating an Azure Web Site to an Azure Cloud Service the same as you were migrating a normal ASP.NET Website to an Azure Cloud Service?
Would you start with an Azure Cloud Service right from the beginning? If yes, why?
Thanks for your time.
There are benefits to both deployment models, it will eventually come down to what you are trying to achieve and ultimately the success of your application.
Below I've outlined the Pros and Cons of each of the models to ensure that you're making the right choice for your applications goals.
Windows Azure Web Sites
You have properly identified that Windows Azure Web Sites is a great starting point for an application, however you could also consider that Web Sites does offer enough scalability for many solutions.
Pros
10 Free sites during preview [Free for 12 months]
Easy Deployment (use Git, TFS, Web Deploy or FTP)
Quick Scalability (You can move to your own dedicated cluster [aka reserved standard])
Simple Development (Supports Classic ASP, ASP.NET, Node.js, Python & PHP)
Persistent Environment (most people are used to this)
Cons
No SSL Support on Custom Domains
in Preview (currently no SLA)
Windows Azure Cloud Services
Cloud Services (formerly known as Hosted Services) is definitely the vision for the future of Web Applications. It is built with resiliency in mind to keep the cost of applications affordable by scaling to meet demand, and dial back capacity when your traffic slows.
Pros
Increased control over the cost of your application (if architected correctly)
Flexibility (You have full control over the environment)
SSL Support
Language Agnostic
Web Server Agnostic (although IIS is available by default)
Auto Management of Servers
Cons
Architecture should be carefully considered
Deployment time is slower (Slows development cycle)
Things to consider for Portability
The items above might have given you enough to plan the immediate future of the application and it is very likely that you might want to consider Cloud Services in the future (it fits a number of application scenarios better in the long run).
Here is a list of things to help portability between Web Sites to Cloud Services:
Start thinking Stateless
Windows Azure Web Sites is nice as it is a persistent environment, which means you are able to store things like session state and assets to the disk.
Although this is a good feature, it's best to start planning towards a stateless application, if your end goal is to be in Cloud Services. Here are a few things you can do to start thinking stateless:
Don't rely on Session State
If you need it, come up with a strategy to make it scale (Caching Service, SQL, or Storage)
Use the Storage Service
Assets such as Static HTML, css, javascript and images are better placed in Storage
Avoids additional bandwidth on your Web Site (potentially stay shared longer for lower cost)
Can be CDN Enabled, provides a better experience for International markets
Easier to update web assets when application is migrated to Cloud Services
Storing User content
If your application already stores to the Storage Service, there is one less code modification in the future when moving to cloud services.
Make it easy to discover patterns in your Data
The benefit of Cloud Services is it enables you to reduce cost by only scaling what needs scaled. Starting the process of identifying your scale units i.e. How you partition your database or Tables in Storage.
I read all post and all of them are very helpful.
In addition to all post , I found an info on msdn : Windows Azure Websites, Cloud Services, and VMs: When to use which?
With Windows Azure Websites you can:
Build highly scalable web sites on Windows Azure.
Quickly and easily deploy sites to a highly scalable cloud environment that allows you to start small and scale as needed.
Use the languages and open source applications of your choice then deploy with FTP, Git or TFS, and easily integrate Windows Azure services like SQL Database, Caching, CDN and Storage.
With Cloud Services you can:
Build or extend your enterprise applications on Windows Azure.
Create highly-available, scalable applications and services using a rich PaaS environment. Support advanced multi-tier scenarios, automated deployments and elastic scale. Deliver great SaaS solutions to customers anywhere around the world.
And also there is summarizes the option on msdn :
And comparing some features Web Sites and Cloud Services on msdn:
Azure is a great place to have your app, but there are some considerations you need to know before start migrating it.
Azure Websites and Hosted Services are really trivial to deploy. With
Visual studio you generate the package and simply upload it. Then you
have a Development environment to check it. If it's ok for you, swap
ips. If it's not ok for you, upgrade again.
Your instances have some properties that could be annoying. For
example, you cannot be sure about your IP. Then if your app works
with some provider using IP restriction, you will need to figure out
how to proceed.
More considerations. Your "server" could be reimaged at any moment.
If you store something on the local disc, that file could go away at any moment.
Azure works very nice if you have at least 2 instances or more for
each website. Maybe your app is not prepared for that. The first step
will be managing the sessions with the appFabric. Is really
easy, just a change on your web config. Be careful because this
session state doesn't work exactly as the "old one". You cannot store
non-serializable objects (should be easy to adapt) or a very large objects (more than 8MB).
If you are going to develop something from zero, I suggest you to start into azure from the beginning. The reason is simple: it's really cheap to start and you will not pay serious money until the app have lot's of visits. It's also very cheap to setup a SQLAzure and a storage account. One you have all in place, it's easy to add more instances or scale up.
Example:
Imagine you have an idea and you wish to show up to some possible investors.
You start setting up a little SQLAzure database (1GB ), $9,99 monthly.
Then you build a site and you put 2 extra small instances, $18,72 monthly.
Let's say you need 100 GB of space (images, backups, ...), $12,50 monthly.
At his point, you have all in place to start your business paying less than $50 monthly.
If you site have exit and the visits starts to come, you change your instances for small instances (it's really dangerous to have production environment with extra small instances, because do not have cpu reservation). Then you change the extra small cost ($18,71) up to $57,60. Maybe you need more space to that SQL Azure? etc...
prices calculated from here: http://www.windowsazure.com/en-us/pricing/calculator/?scenario=web .
Those are few tips, there is a lot more. My advice is to start a trial account and play with it.
Final advice: Its very easy to solve everything just purchasing more resources. Sometimes you need to refactor and optimize your code. If you simply add more resources each time you have a problem, you could end with a huge bill and a very messy code.
Hope it helps!
Another advantage of Windows Azure Cloud Services over Web Sites is that a cloud service can be added to an Azure Virtual Network. This can give it access to on-premises resources like databases. So if your requirements are such that you need the scalability offered by Azure but need to keep your data on-premises due to security restrictions, cloud services is a better choice.
Azure web sites cannot be part of an Azure virtual network. To access on-premises resources mechanisms such as Azure Service Bus Relay must be configured.
We've had our web site running on PHP on some hosting and at some point decided to move it to Azure (where sits main part of our service). We've started with Azure Web Sites which was great from development point of view (mainly integration with git). But after about a week of testing (when we've decided to actually move the production web site) we've found that currently
No SSL for custom domains
Custom domains are available only for reserved instances (no shared infrastructure)
SLA
So we moved to Hosted Service. The main problem for us was lack of ability of simple deployment (need to build package and upload whole package of the web site), and found solution was to use dropbox - as a startup task for role, we're installing dropbox service on the machine, which takes all the web site from dropbox, which in turn have SVN checked out folder, so site updates became very easy.

How do you run utility services on Heroku?

Heroku is fantastic for prototyping ideas and running simple web services, I often use it to run Python web services like Flask and Django and try out ideas. However I've always struggled to understand how you can use the infrastricture to run those amazingly powerful support or utility services every startup needs in its stack. 4 exmaples of services I can't live without and would recommend to any startup.
Jenkins
Statsd
Graphite
Graylog
How would you run these on Heroku? Would it be best just getting dedicated boxes (Rackspace, e.t.c) with these support services installed.
Has anyone one run utility deamons (services) on Heroku?
There are two basic options. The first is to find or create a Heroku addon to accomplish the task. For example, there are many hosted logging solutions you can use instead of Graylog; Rails on Fire or Travis can be used instead of Jenkins. If an appropriate addon doesn't exist, you can effectively make your own by just running the service on an AWS EC2 instance.
The other alternative is to push the service into being a 12factor application so that it can run on Heroku as well. For example, you could stub out whisper's filesystem calls so that they store in a backing service instead. This is often pretty painful and brittle, though, unless you can get your changes accepted by the upstream maintainers.
you could also use another free service in conjunction with it. OpenShift has a lot of Java related build services and tools that can be added.
I am using a mix of heroku, openshift, mongolab and my own web hosting. Throw in dropbox and box for some space...

Resources