I'm considering the different options for hosting a web application written in Haskell.
Heroku seems like an attractive alternative, and it supports Haskell. However, as described in the Heroku runtime principles it is quite likely that I will need to connect the web process with some background jobs (either via a message queue, or using platforms like Cloud Haskell). Also I will need a persistence layer, and I don't know how well this is supported in Heroku when using Haskell.
My question is then whether Heroku supports deploying a full blown Haskell application, or a running containers on a IaaS (such as AWS or Google Computing Engine) is a better option.
Related
I have build an chat application using nodejs with mysql database. I have developed on my windows system and it works fine.
Now I want to make it live on a server to check its real time performance, As a beginner I don't know which server hosting should I choose to develop nodejs application, so someone please suggest me a hosting for nodejs application?
If you want something relatively easy to test on, Heroku will provide you with a free instance.
I can also recommend Azure over Amazon for a simple nodejs based app. The main reason is that Azure has a very simplified interface for deploying node apps after a little bit of minor setup. Amazon offers similar capabilities, but the last time I looked at them they aren't quite as simple to get up and running. Again, they're competitive in cost and reliability, this is just a subjective opinion on what I think will be easier for a dev to get up and running without prior experience.
I use Dokku, an open source solution for a Heroku like PaaS. Either of those are great for doing git style deployments. Heroku has better documentation, and doesn't require your own server so I would start with them.
https://www.heroku.com
http://dokku.viewdocs.io/dokku
How are the different FaaS or Serverless Architecture offerings of the major cloud providers effectively implemented in terms of backend and infrastructure?
AWS Lambda: Java, Node.js, C#, Python, binaries
Azure Functions: JavaScript, C#, Python, PHP, Bash, Batch, PowerShell
Google Cloud Functions: JavaScript
Google Cloud Functions seems to be based on a managed Node.js environment according to here: https://cloud.google.com/functions/docs/concepts/overview which seems to be different and a limiting factor.
AWS and Azure support a multitude of different runtimes which may look like an ideal docker use case? At least the underlying logical core concept is very close to process isolation/containerization respectively scaling of these which would lead us to Kubernetes/Mesos? It wouldn't be very efficient to invent custom solutions nowadays, wouldn't it?
Does anyone know what is at work behind the scenes?
I had a discussion with an AWS Engineer a while back and he confirmed my suspicion that AWS Lambda is run's on top of docker. Can't comment on azure or google's infrastructure though...
I've been bitten by the test-driven infrastructure bug. My current project is using Azure, including SQL Azure, Azure tables, cloud services, and mobile services. Configuring an entire environment is somewhat complex. Now I'm looking for a testing framework that I can use to verify that the environment is configured correctly. Something like "Confirm that there's a mobile service endpoint named foo, that is has APNS and GCM endpoints, and that there is a Google API key and Apple push certificate associated." There is more, but that is complex enough that existing tools don't seem to cover it but simple enough to describe in a single sentence.
Because of the number of products, I have to use both the PowerShell module and the cross-platform CLI to script the setup. The cross-platform CLI looks like the easiest way to get data out (it uses Node and can easily dump JSON data), but I'm at a loss as to how to even start with testing JSON dumps from a Node module that was never really intended to be used as a module.
The PowerShell module is buggy and doesn't have any ability to read mobile services information.
There is a ruby gem for managing Azure, but it's very limited. So my hope of being able to work all in Ruby was dashed. There too, I'm not sure how one would use ServerSpec to test a remote node without actually running anything on the remote node.
I'd like to stay within the realm of something that would be understandable by another Azure developer (e.g. JavaScript, PowerShell, and potentially Ruby) and not have to start from scratch with something like Erlang or Brainf**k.
Corey - big area of ongoing build out on Azure right now which is why you are finding limited support. Resource Manager is aimed at driving programmable infrastructure (http://azure.microsoft.com/en-us/documentation/articles/xplat-cli-azure-resource-manager/) but doesn't yet encapsulate all Azure service offerings.
There is also the Management Libraries (for .Net) - http://www.bradygaster.com/post/getting-started-with-the-windows-azure-management-libraries or at the most basic of levels there is the pure REST API that you can code directly against if there are bits missing from the above (which is likely) - http://msdn.microsoft.com/en-us/library/azure/ee460799.aspx
We use a Rackspace cloud server (2nd generation) for one of ours SaaS applications. And we want to move one more SaaS app to Rackspace as well. Both applications don't have much traffic/load, but they grow up with time insignificantly.
I'm hesitant if to create one more cloud server and to place the second application there, or to install it as one more virtual host at the first server. My main concerns are:
I'm not sure if it'll be convenient to support both developing projects at one server (they're written using the same tools, so quite similar and need a similar environment)
I'm not sure if it's a good idea to set up one more cloud server with the same environment and to spend time on supporting the same servers in parallel (e.g. updates/packages installs). Maybe there're approaches I'm not aware of on how to maintain similar servers in parallel a simple way at Rackspace?
Thank you for your time.
I have never regretted using separate Rackspace Cloud Server instances for described case. It's very convenient to have decoupled application environments in a long time run.
For easier setup of similar environments it's possible to use templates of Rackspaces's Cloud Orchestration
I've been reading about azures storage system, and worker roles and web roles.
Do you HAVE to develop an application specifically for azure with this? It looks like you can remote desktop into azure and setup an application in IIS like you normally can on a windows server, right? I'm a little confused because they read like you need to develop an azure specific application.
Looking to move to the cloud, but I don't want to have to rework my application for it.
Thanks for any clarification.
Changes to the ASP.NET application are minimal (for the most part the web application will just work in Azure)
But you don't remote connect to deploy. You actually build a package (zip) with a manifest (xml) which has information about how to deploy your app, and you give it to Azure. In turn, Azure will take care of allocating servers and deploying your app.
There are several elements to think about here -
Code wise - to a large degree this is 'just' .net running on IIS and Windows, so everything is very familiar and all the past learnings, best-practices, etc. apply.
On top of that you may want to leverage some Azure specific capabilities - for example table storage, or queues, or interacting with your deployment - for which you might need to learn a few more APIs, but these aren't big, and are well thought of and kept quite simple, so there's not a bit learning curve. good architecture, of course, would look to abstract these away to prevent/reduce lock-in, but that's a design choice.
Outside the code, however, there's a bit more to think about -
You'd like to think about your deployment - because RDP-ing into a machine and making changes that way takes away many of the benefits of PaaS - namely the ability of the platform to 'self-heal' by automatically re-deploying your application should a server fail.
You would also like to think about monitoring - which would need to be done slightly differently.
Last - cloud enables different scenarios, and provides a scale-out model rather than a scale-up model, which you might want to take advantage of, but it might require doing things a little bit.
So - bottom line - yes - you could probably get an application in Azure very quickly, without really having learning much or anything, but to do things properly, and to really gain from the platform, you'd like to learn a bit more about it. good thing is - it's not much, and it all feels very familiar, just another 'framework' for .net (and Java, amongst others....)
You can just build a pretty vanilla web application with a SQL backend and get it to work on Azure with minimal Azure dependencies. This application will then be pretty portable to another server or cloud platform.
But like you have seen, there are a number of Azure specific features. But these are generally optional and you can do without them, although in building highly scalable sites they are useful.
Azure is a platform, so under normal circumstances you should not need to remote desktop in fiddle with stuff. RDP is really just for use in desperate debugging situations.