1. No IP address persistence (they all function as DHCP clients and are assigned an IP). One has to use dynamic DNS services for a given domain.
2. No block storage persistence. When the instance is gone, the data is gone. Yes I know you can send this back regularly to S3, but isn’t that actually a ‘hack’?
3. No opportunity for hardware-based load balancing (which happens to be the key to scaling a process based framework like Rails and mentioned above).
4. No vertical scaling (you get a 1.7Ghz CPU and 1 GB of RAM, that’s it). So like the block storage problem, this hits databases, we run about 32GB of ours in memory.
5. Can’t run your own kernel or make kernel modifications so there’s no ability for kernel and OS optimizations, and no guarantee that they’ve been done.
6. Images have to be uploaded and then moved around their network to find a launching point. This can take several minutes, if not more. Move 100 GBs around a busy gigabit network sometime and see.

Some points have already been raised multiple times before, like no IP address persistence, no local storage persistence, etc. These are exactly the same points which I had raised back in August last year. As of kernel modification in point 5, this issue is certainly not Amazon EC2 specific, Most VPS hosts won’t let you run your own kernel anyway. I do not think moving around AMI is an issue either in point 6. I know an EC2 instance can take a few minutes to deploy, but it is still far faster than deploying a dedicated server.

Jason did bring up a very interesting point though on the inability to scale vertically. The common myth around web-based applications is — scaling horizontally is easy, and you can just throw in more hardware to make it run faster. Or at least the PHP, RoR or “share-nothing” folks would want you to believe that. This is simply NOT TRUE, and I have to keep on reminding the sales guys at work that we just cannot throw in more instances to fix the scalability issue.

The easiest way to scale a database system is still running it on a BIGGER hardware. More RAM so database pages can be cached. Faster disks so IO wait can be reduced. That is if you do not want to go down to the path of database partitioning (lots of domain specific tuning), or spending lots of $$$ on Oracle RAC or DB2 (which are usually beyond the budget of most Web 2.0 startups).

I guess you just cannot get anything one-size-fits-all in this world.

Even better — if you are an existing life-time plan holder, you get to pay only half the price ($399 for a small life-time Solaris container) AND keep your existing shared hosting with TextDrive as well! However, there will only be 200 slots available. My Solaris skill is pretty rusty (last used one — 2000), otherwise I will be very tempted.

Now, the mic is over to you, Mr. SliceMatt. What do you think? :)

160kbps MP3 for a podcast is a bit unnecessary, and I don’t really like their choice of music. However they scores in the category of geekiness. Stuff talked about in the first episode — virtualization, Oracle vs. Red Hat, Sun’s Blackbox, Ruby on Rails and Java — reflecting the expertise in Joyent as both a software developer and hosting company.

Some reflections:

1. How much did Jonathan Schwartz pay these fanboys? :)
2. Separation of application layers is not the reason why many people are getting VPS now. It’s not for scaling up, but for scaling down. If I need root access, but don’t need the power, where can I get a dedicated server with 256Mb RAM and 500Mhz Pentium 3? It’s more economical for hosts to provide that to developers in the form of VPS or containers.
3. Jython lost momentum because GvR the Benevolent Dictator is behind the CPython. However the future might be on PyPy. Maybe JVM powered Python can be resurrected as a form of PyPy?
4. I’ve never been troubled by space and indentation, being a Python developer for almost 6 years. Maybe I am just a neat person :)

Feed subscribed. Looking forward to the next episode.

Joyent’s new Bingo! on-line disk service gives you 100 gigabytes of disk storage on Sun’s amazing X4500 platform with 10 gigabytes of bandwidth per month over WebDAV for the super-low price of $199 a year! You get one user account and the ability to serve files from a public folder (for images, podcasts, whatever). On top of this, you get a complimentary 5-user subscription to Connector, Joyent’s amazing group collaboration product.

Pretty good price on a very good hardware let me say. I guess they must have sourced quite a few Sun Fire X4500 to make the price this competitive. At $16.60/month it makes a great online storage solution. However, monthly transfer has been limited to 10GB/month, so it would take almost a year to fill up your account without incurring extra costs.

Pricing is a bit funny though. First of all, isn’t it a direct competition with Joyent’s another service, Strongspace, which provides on-line backup via SFTP and Rsync? Sure, it gives you Rsync (instead of WebDAV), and there is no extra bandwidth charge, but at $8/month with only 4GB of storage, you can tell where the customers will go.

Moreover, Bingo! came with 5 user subscription to Joyent Connector, which itself costs $15/month, and comes with only 5GB of storage. I can see Bingo! is making the “Start” plan redundant.

Update: Take what David Young has said,

No, we’re not staring. We’re building. Bingo is a key foundation.

And what Brian Duffy has later commented,

Your pricing model is pretty cool… getting 100GB/mo with 10GB/mo transfer costs about the same as if you used Amazon S3.

I think I know what Joyent is building — an Amazon S3 killer. Note that Amazon S3 is not just an on-line storage with a cool API — it is going to be the foundation of other Amazon service products like EC2. Now Joyent has Bingo! backing Connector for storage, but I am sure there will be many others under their secret plans.

Moreover, the pricing is set to match with S3′s. Each gigabyte of storage comes down to 16.6 cent per month, plus included 10Gb per month transfer, and on top of that, the extra transfer is on par with S3.

API? Too bad Bingo doesn’t have a set of API like Amazon S3. When you have a well defined and implemented-to-death protocol like WebDAV, you don’t need an API :)

Well, that gets me excited.