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 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.

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é

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.

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

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é

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.

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! :)

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.

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.