• 11Feb

    I knew I was missing something when I was listing out some hosting providers for developer-focused cloud app hosting, so here goes:

    Morph AppSpace is a paid hosting service with some cloudlike features – you can pay by the ‘cube’ or hosting unit – kinda like an Amazon EC2 Compute Unit – and it’s free to get started, which is nice for startups. They support Ruby, Rails, PHP, and Java (although I don’t know what kind of java hosting they provide, I’d assume it’s Tomcat-centric) and through the Java support, Grails if you’re into that kind of thing.

    The cloudlike features are the ability to scale by adding new ‘cubes’ and the built-in monitoring that allow you make informed decisions on how much more money to spend on your scaling. It doesn’t dynamically scale, but it gives you the ability to add more resources to your app as you need them.

    Like Google AppEngine (although, again, on Google’s side this is changing), you can’t run scheduled tasks, so you’ll have to work around this if you’re planning on hosting with Morph.

    So there you go, one more tool for your belt.

  • 03Feb

    There are two types of cloud infrastructure offerings that are important for small business and startups: developer-centric hosting services, which take care of a lot of the day-to-day system tasks for you, or the infrastructure-focused options, which give you flexibility at the cost of having to do a lot of custom configuration. There are also service-tier systems that support the more flexible options, but I’m going to focus on an overview of the major cloud-based easy-to-get-into services that I know of.

    All of these options require you to build your app with the platform in mind. Some knowledge of the limitations and capabilities of the systems will go a long way in smoothing the deployment of your new app. Building to these environments requires a certain amount of trust, however, and porting your app to a different platform once you’re up and running may be a chore if you don’t take steps early on.

    Google AppEngine

    Google has App Engine, a python-centric platform with a rich API that allows developers to build fairly robust applications quickly, deploy them, and just let them run. There’s no system administration involved whatsoever, which allows very small teams to build robust tools quickly without worrying about scaling, configuring servers, single points of failure or any of that rigamarole.

    What you don’t get is some of the standard tools that most web developers take for granted: instead of a SQL-compliant database, you get BigTable. It’s capable, but different. Scheduled tasks currently don’t work, either. You can build an api-based, authenticated action and trigger it remotely to work around that, but watch for fault tolerance if you go that route. The biggest drawback is that the offering is free, but capped. Meaning, if you consume your allotted resources for the month, you’re done until the calendar ticks by. Google hasn’t yet opened payments for AppEngine, but it looks like the payment system is just around the corner.


    Mosso’s CloudSites product is more flexible: you get your choice of Windows or Linux, and you deploy your app or web site onto their servers. You get a full hosting environment, witn no shell access – all control is done through their web panel. It’s a big benefit if you’re not command-line centric. On the Linux side, you get PHP, Perl, Python, MySQL; Windows users can choose from different versions of the .NET framework, and use IIS and SQL Server. So you can build your application using your favorite framework that fits within those parameters, just remember that you have very little system control. If you’re using CPAN modules, you’ll have to use what they have available or build them into your app directly. You can’t install anything else. However, they offer 500GB of bandwidth out of the gate, with a slightly expensive $.25/GB once you go over. At $100, it’s not a bad option. Check their Does It Fit? page to see if what you’re building fits in their parameters.

    EngineYard Solo

    EngineYard is a fairly new player in the cloud game. They got started in 2006 as a Ruby on Rails hosting company, and had some really bad hiccups geting started (sorry guys, but I was a customer then and remember the whole cluster taking over an hour to reboot). They are, however, really damn smart, and determined to live on the bleeding edge. They use a custom-build, highly tuned Gentoo Linux server image that’s optimized to host Rails apps, and they do it very well. They’re driving a lot of thought and development in the systems administration world.

    Recently, they just opened up Solo, in partnership with Amazon. They’re hosting and provisioning server instances using their custom stack on EC2, and make it pretty easy to get a Rails app off the ground. They charge a premium: $125/month, as opposed to a raw EC2 box at $70 or so, but what you get is a prebuilt box with a lot of good, smart defaults in the setup that’s built to reliably host a Rails app. If you’re not a sysadmin, or can’t affor the time or cash to get that work done for you, this looks to be a good route to go.

  • 03Feb

    “What is The Cloud?”

    Mighty big question, let me tell you. Cloud computing is the biggest buzzword to hit the IT industry since Local-Area-Networking. I’m serious. And it’s got the potential to be as big of a deal. A cloud-managed infrastructure is what every major IT installation will be based on by 2015. There will be legacy boxes floating around, but when  you can suck up your legacy box into a cloud infrastructure, liberating it from the iron it’s running on, why wouldn’t you?

    Let’s get back on topic: what is The Cloud? And why is everyone calling it “The Cloud?” As in, “Let’s run that in The Cloud.” Or, “We’re hosting it in The Cloud.” As if there’s only one. Seriously, there’s more than one. And that’s a good thing. Every pundit and talking head in the tech industry is talking about it, but I honestly think that maybe 30% of them know what they’re talking about – and even they can’t agree.

    Here’s the simple, real-deal definition:

    The Cloud (n): A marketing buzzword that is essentially meaningless, tagging some service or offering to a nebulous idea of Resource-Based Computing.

    Remember old-school network diagrams? When you connect your network to an outside source, the traditional symbol is a cloud. Meaning, ‘some network or bunch of stuff out there, but we don’t know and don’t care for the scope of this diagram.’ So you wave your hands and draw a cloud. More recently, that cloud on your network diagram means The Internet. This is where the cloud term came from, folks. Some cloudy thing beyond the scope of the document. That’s what marketers are using when they say “The Cloud.”

    That Resource-Based Computing term I just used is closer to what people really mean when they talk about The Cloud. Every major IT broker and their brother offer their own cloud-like solution. Microsoft is getting closer to Azure. Amazon has EC2 (which I’ll be blogging about extensively). Sun is probably going to be bought by someone, but they’ve got the Grid Engine. Google has AppEngine. And they’re all different. They all work differently. So what draws them together?

    Resource-Based Computing. It’s the idea that computing is a resource that you can bill for, rather than buy outright. It’s rooted in modern operating systems, with the ultimate hardware abstraction layer – the whole damn computer. You build your app to fit the resource you want to tap, depending on your level of skill or commitment to the nuts and bolts of the machine. The more abstract, the less control you have over your environment, but the less you have to manage day-to-day. Like everything else, it’s a tradeoff.

    Over the next week, I’m going to look deeper at the different cloud computing options, and where they fit on a strategic level. As we go, and as I experiment, I’ll post technical nitty-gritty details where I can.


Recent Comments

  • Hi, please let me know the process to be followed for win...
  • Thanks, Rob. As I get deeper into this blog, I'd like to go ...
  • Thanks for the overviews. I just want to make it clear that...