www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Need some vibe.d hosting advice

reply aberba <karabutaworld gmail.com> writes:
So I'm into this platform with a vibe.d api server + back-end and 
I'm confused/curious to know the hosting package to use. I will 
have a lot of images uploaded by users.

1. For sometime, I've been looking at heroku which is fine with 
its load balancer, easily scaling etc. But the hosting cost for a 
startup is high and (most importantly) requires an external 
storage either s3 or cloudinary which no lib in D currently exist 
for them (stable).

2. Get an EC2 instance from Amazon or Vultr and install 
everything yourself and save images on disc (potentially 
problematic). This can not be scaled easily

3. use a self-hosted PaaS like Flynn (aka self hosted heroku) 
...but you still have to store images in an object storage and a 
D api is needed for this. Which links back to point 1 but less 
costly and more control.


How would you do it if you were using vibe.d?

(With node.js, all these are solved).
Aug 11
next sibling parent Mengu <mengukagan gmail.com> writes:
On Friday, 11 August 2017 at 13:06:54 UTC, aberba wrote:
 So I'm into this platform with a vibe.d api server + back-end 
 and I'm confused/curious to know the hosting package to use. I 
 will have a lot of images uploaded by users.

 1. For sometime, I've been looking at heroku which is fine with 
 its load balancer, easily scaling etc. But the hosting cost for 
 a startup is high and (most importantly) requires an external 
 storage either s3 or cloudinary which no lib in D currently 
 exist for them (stable).

 2. Get an EC2 instance from Amazon or Vultr and install 
 everything yourself and save images on disc (potentially 
 problematic). This can not be scaled easily

 3. use a self-hosted PaaS like Flynn (aka self hosted heroku) 
 ...but you still have to store images in an object storage and 
 a D api is needed for this. Which links back to point 1 but 
 less costly and more control.


 How would you do it if you were using vibe.d?

 (With node.js, all these are solved).
heroku is a bit more expensive. for starters, you could have a vps on digitalocean and let your application run on there. google cloud is an excellent platform that i run my company on. it is a lot cheaper than aws.
Aug 11
prev sibling next sibling parent Andre Pany <andre s-e-a-p.de> writes:
On Friday, 11 August 2017 at 13:06:54 UTC, aberba wrote:
 So I'm into this platform with a vibe.d api server + back-end 
 and I'm confused/curious to know the hosting package to use. I 
 will have a lot of images uploaded by users.

 1. For sometime, I've been looking at heroku which is fine with 
 its load balancer, easily scaling etc. But the hosting cost for 
 a startup is high and (most importantly) requires an external 
 storage either s3 or cloudinary which no lib in D currently 
 exist for them (stable).

 2. Get an EC2 instance from Amazon or Vultr and install 
 everything yourself and save images on disc (potentially 
 problematic). This can not be scaled easily

 3. use a self-hosted PaaS like Flynn (aka self hosted heroku) 
 ...but you still have to store images in an object storage and 
 a D api is needed for this. Which links back to point 1 but 
 less costly and more control.


 How would you do it if you were using vibe.d?

 (With node.js, all these are solved).
On cloud foundry you have the possibility to push a pre compiled binary and use the binary buildpack or to use a D buildpack and push the D source code. There is an issue with vibe.d if your CF ram is limited to 1024 MB. This is not enough to compile vibe.d. You have to change the compilation mode to single file. On Aws you can also use Lambda (nodejs), as Nodejs is able to start your D binary. Someone has written a D blog about this topic. I think it was about Amazon Alexa. There are obvious costs and also hidden costs on Aws. You have to run your scenario for an month and then check the actual costs... Kind regards André
Aug 11
prev sibling next sibling parent crimaniak <crimaniak gmail.com> writes:
On Friday, 11 August 2017 at 13:06:54 UTC, aberba wrote:
 So I'm into this platform with a vibe.d api server + back-end 
 and I'm confused/curious to know the hosting package to use. I 
 will have a lot of images uploaded by users.
 2. Get an EC2 instance from Amazon or Vultr and install 
 everything yourself and save images on disc (potentially 
 problematic). This can not be scaled easily
Why do you think it can't be scaled? We have vibe.d on EC2 hosting. Common advice: get the same distribution as on the working machine where you are producing binaries to avoid problems with .so. First, we get default centos-based VM, and after some wasted time, it was easier to change it to Ubuntu VM to run the application, compiled on my working Ubuntu machine.
Aug 11
prev sibling next sibling parent reply Paolo Invernizzi <paolo.invernizzi gmail.com> writes:
On Friday, 11 August 2017 at 13:06:54 UTC, aberba wrote:
 So I'm into this platform with a vibe.d api server + back-end 
 and I'm confused/curious to know the hosting package to use. I 
 will have a lot of images uploaded by users.

 [...]
We are using dockerized vibe.d containers in a docker swarm hosted on DigitalOcean. /Paolo
Aug 12
next sibling parent reply Andre Pany <andre s-e-a-p.de> writes:
On Saturday, 12 August 2017 at 08:49:44 UTC, Paolo Invernizzi 
wrote:
 On Friday, 11 August 2017 at 13:06:54 UTC, aberba wrote:
 So I'm into this platform with a vibe.d api server + back-end 
 and I'm confused/curious to know the hosting package to use. I 
 will have a lot of images uploaded by users.

 [...]
We are using dockerized vibe.d containers in a docker swarm hosted on DigitalOcean. /Paolo
Your scenario sounds like a very interesting and helpful D blog;) Kind regards André
Aug 12
parent Faux Amis <faux amis.com> writes:
On 2017-08-12 12:46, Andre Pany wrote:
 On Saturday, 12 August 2017 at 08:49:44 UTC, Paolo Invernizzi wrote:
 On Friday, 11 August 2017 at 13:06:54 UTC, aberba wrote:
 So I'm into this platform with a vibe.d api server + back-end and I'm 
 confused/curious to know the hosting package to use. I will have a 
 lot of images uploaded by users.

 [...]
We are using dockerized vibe.d containers in a docker swarm hosted on DigitalOcean. /Paolo
Your scenario sounds like a very interesting and helpful D blog;) Kind regards André
I second that! :)
Aug 12
prev sibling parent reply aberba <karabutaworld gmail.com> writes:
On Saturday, 12 August 2017 at 08:49:44 UTC, Paolo Invernizzi 
wrote:
 On Friday, 11 August 2017 at 13:06:54 UTC, aberba wrote:
 [...]
We are using dockerized vibe.d containers in a docker swarm hosted on DigitalOcean. /Paolo
Breaking the app into microservices and in a managed environment since we don't have devOps. Among the container hosting options, I'm seeing Google's App Engine Flex which supports running docker containers and Google cloud for object storage (their api is much easy to use). And their SQL service too. Everything managed under one dashboard
Aug 15
parent aberba <karabutaworld gmail.com> writes:
On Tuesday, 15 August 2017 at 10:28:04 UTC, aberba wrote:
 On Saturday, 12 August 2017 at 08:49:44 UTC, Paolo Invernizzi 
 wrote:
 On Friday, 11 August 2017 at 13:06:54 UTC, aberba wrote:
 [...]
We are using dockerized vibe.d containers in a docker swarm hosted on DigitalOcean. /Paolo
Breaking the app into microservices and in a managed environment since we don't have devOps.
 Everything managed under one dashboard
On this, i just took a close look a Deis.com Workfkow which is exactly heroku but uses kubenetes and docker under the hood. A true self hosted Heroku. The beautiful thing is any docker image can be used (no need for build packs)
Aug 17
prev sibling next sibling parent Sebastiaan Koppe <mail skoppe.eu> writes:
On Friday, 11 August 2017 at 13:06:54 UTC, aberba wrote:
 So I'm into this platform with a vibe.d api server + back-end 
 and I'm confused/curious to know the hosting package to use. I 
 will have a lot of images uploaded by users.
I would definitely outsource the storage. AzureBlob, S3, Wasabi, it doesn't matter. Which means you would have to use/write an api lib. There is no way around it. Another option would be to use something like DigitalOceans/hyper.sh volumes, but I don't see how that will give you high-availability/auto-scalability out-of-the-box.
Aug 12
prev sibling parent reply sarn <sarn theartofmachinery.com> writes:
On Friday, 11 August 2017 at 13:06:54 UTC, aberba wrote:
 How would you do it if you were using vibe.d?
Depends on who wants it built. I do consulting, so let me answer that way. "I don't want to think about ops and scalability and availability at all!" Then you'll have to pay a premium for someone else (like Heroku) to do that for you. It may or may not be worth it for you, but you can't have it both ways. "Okay, I've thought about it bit. I can use a shell, 100k non-asset requests per day sounds like a lot, and I guess a few minutes of downtime isn't so bad if it's occasional and I can schedule it to outside hours." Sounds like you can just host it on a VPS with all the important data on managed (backed-up) storage (like RDS or S3 in AWS) and possibly with a CDN in front. "I don't think either of those options fit my needs." Okay, let's talk about what your needs are. About S3, there's not a lot you'd need to do with S3, right? I'd just write the library or wrap the command line client.
Aug 12
parent aberba <karabutaworld gmail.com> writes:
On Sunday, 13 August 2017 at 00:23:31 UTC, sarn wrote:
 On Friday, 11 August 2017 at 13:06:54 UTC, aberba wrote:
 [...]
Depends on who wants it built. I do consulting, so let me answer that way. [...]
Thanks. Some things to think about.
Aug 14