Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!


Has anyone tried viaduct.io? A compelling Heroku alternative.
New on LowEndTalk? Please Register and read our Community Rules.

All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.

Has anyone tried viaduct.io? A compelling Heroku alternative.

smalletsmallet Member
edited October 2015 in General

https://viaduct.io

It has everything I feel Heroku lacks (which isn't much really). Selective Persistent storage, port forwarding and many more. Surprisingly, the web interface is much better than Heroku's.

Some base free resources provided:

  • 1 free 350MB process
  • 1GB of free storage - 10p/gb after
  • 10GB free bandwidth - 5p/gb after
  • 3 free persistent directories

Some cons:

  • Doesn't have any support for Java, Pyhton, Go

Seems like it was released in early 2014. I wonder why it hasn't gained more traction. Try deploying their prebuilt ghost app and test their stuff.

Thanked by 1YellowHummingbird

Comments

  • joepie91joepie91 Member, Patron Provider

    That bandwidth is fairly expensive.

    Anyhow, I don't like these kind of proprietary platforms. There's a reason they have a 'free' plan - it's a great way to rope you in, have you design your application for their platform, and thus making it hard and expensive to move away from them.

    From a quick read through the documentation, they don't seem to offer much in management either. Just the usual automated process restart stuff, which forever or pm2 can do on any standard VPS, and various other forms of automation that - again - aren't so much a service as a piece of software.

  • @joepie91 yes people need to realize that they can just get several dirt cheap VPS's for a year instead of this "hourly billed" stuff.

  • joepie91joepie91 Member, Patron Provider

    @4n0nx said:
    joepie91 yes people need to realize that they can just get several dirt cheap VPS's for a year instead of this "hourly billed" stuff.

    Hourly-billed isn't even necessarily the problem (see eg. hourly-billed VPS services). It's the unnecessary vendor lock-in.

    Thanked by 14n0nx
  • smalletsmallet Member
    edited October 2015

    I don't see where the vendor lock-in is, really. Any "incompatible code" is in the form of some procfile settings and environment variables. Everything else would be settings up the proxy, dbs, etc - all of which you have to set up all over either way.

    I would really like to know what kind of vendor-specific code I would be introducing?

    Where I did experience horrible vendor-lockin? Google AppEngine. Though it was the horrible restrictions on the runtime environment that annoyed me. Heroku is pretty lenient with respect to that.

  • "Viaduct is a massive pile of awesome!"

    Hahaha - I thought it was going to say pile of shit and I was ready to lift the brow. :D

  • smalletsmallet Member
    edited October 2015

    @deadbeef said:
    "Viaduct is a massive pile of awesome!"

    Hahaha - I thought it was going to say pile of shit and I was ready to lift the brow. :D

    Lol. where does it say that? I can't find it saying massive pile of anything anywhere...

    Edit: oh, their testimonials.

  • I like their domain name.

  • raindog308raindog308 Administrator, Veteran

    First, @smallet thanks for sharing this. Not bashing viaduct.io at all - this is more a generic response.

    smallet said: Where I did experience horrible vendor-lockin? Google AppEngine

    Wait, I thought it was just profile settings and environment variables :-)

    What @joepie91 is referring to is the lock-in at the platform level. It's trivial to move my app from provider A to provider B if it's written on a generic VM. Less so if I've written it for Heroku, GAE, etc. The naive view is "it's in python/java and this other platform supports python/java so I just reconfigure a few things and away I go" but as you show with GAE, it's not that easy.

    It certainly could be worse - e.g., if you write something to run on Amazon SimpleDB, that's the only place on the planet it will run.

    My concern would also be viability. I might tolerate some vendor lock-in if it's backed by Google/Amazon - companies that have a reasonable chance of being around in three years.

    In general, I prefer either IaaS or SaaS solutions rather than PaaS primarily for reasons of flexibility and portability, but different people have different needs.

  • joepie91joepie91 Member, Patron Provider
    edited October 2015

    raindog308 said: What @joepie91 is referring to is the lock-in at the platform level. It's trivial to move my app from provider A to provider B if it's written on a generic VM. Less so if I've written it for Heroku, GAE, etc. The naive view is "it's in python/java and this other platform supports python/java so I just reconfigure a few things and away I go" but as you show with GAE, it's not that easy.

    Exactly this. You have very limited control over your environment, so it may be very hard (or even impossible!) to replicate it outside of that provider. And even if you can, it is usually more expensive than staying with the provider.

    That's how truly persistent vendor lock-in works - by making the price of moving away consistently higher than the price of just overpaying the current provider.

    EDIT: Not to mention that your development process and toolchain usually come to rely on the provider you are using, for PaaS providers. This is a hidden but often significant cost.

Sign In or Register to comment.