Objective-C in The Cloud
objective-cloud.com
objective-cloud.com
We used an HTTP server[1] around it, exposing an RPC style interface. Our app exports metrics with a StatsD client[2] we wrote.
[1]: https://github.com/mattstevens/RoutingHTTPServer
[2]: https://github.com/newspaperclub/statsd-cocoa
The good news is, it's just what hoped it would be. The app performs incredibly well, and having access to the APIs like GCD and so on is great. The downside is that it's a pain putting the application into production. Being forced to use Mac hardware is incredibly annoying. (We knew this would be the trade off.)
All our dedicated Mac Minis came with 10.7 on them from the hosting company. Upgrading to 10.8 required someone to be present, or attached to the KVM just press next on an iCloud wizard before it boots back in, and I'm always worried that a point release might do something odd.
VMWare ESXi 5.1 supports running OS X 10.8 on top of Mac hardware (legally), so we're leaning towards using that to make the managing the machines slightly easier - being able to snapshot and rollback if an upgrade does something odd or drop into the console if we lose remote access.
Peachpit press has some books to get you started, and you could look into http://www.deploystudio.com/Home.html
-- frogor@Freenode
I say this because your landing page makes it very difficult for anyone but a semi-expert to understand the benefits of this. I'd advise you that your target buyer may not be as intelligent as you -- dumb it down for them.
The long opening paragraph has a lot of nuggets in it. I'd recommend you boil it down to this:
- We help you scale your (distribution/development) - We save you from (cost/failure) - You'll gain (efficiency/ease of mind)
I do miss EOF.
Avoid GNUstepWeb unless you want to feel some pain. Instead you should take a look at WebAppKit[1] as it looks more promising.
The biggest problem selling to developers is going to be developers telling you how they would make it better. My advice is listen, but prioritize by following your instincts and the paying customers!
I hope to see more complete and detailed answers for common questions like those.
I think there is a demand for people who need close to C performance without the need of messing with pointer explicitly and with sane OOP support as default. Your user base is large due to the number of existing iOS developers, and able to interop with C libraries is also an advantage.
The problem is, if Python is a language with batteries included, then on non-Apple platforms Objective-C only comes in kit form -- with certain critical components you have to supply yourself. To wit: due to changes made in the Objective-C runtime made by Apple and backported to the GNU runtime (which, mirabile dictu, is now MUCH more API-compatible with Apple's stuff), the Object class is now only the barest skeleton of a thing, and no longer has +alloc, -init and -free methods in its own right. To get even constructors and destructors without the Cocoa framework, you will have to implement them yourself. Not that hard to do, actually; there are API calls for that. But the average developer is going to wonder what sort of bush league he's operating in where the language runtime doesn't even provide constructors and destructors.
As a rule if you are going to use Objective-C, you are committed to Apple.
If all you're looking for is constructors and destructors, consider ObjFW. https://github.com/Midar/objfw/
ObjFW is much more lightweight, although it does have its own set of conventions. Fortunately, +alloc, -init, +new and -dealloc are all present and accounted for.
What I like about Objective-Cloud (apart from the name!), is that it allows you to go to a hosted solution quickly, and then when there is a further scaling requirement you can decide wether doing a port is justified to lower costs.
I also really like your succinct summation of Objective-C benefits: close to C performance [..] with sane OOP as default (not sure about the pointers...)
I've blogged a bit about Objective-C web performance, for example compared to Ruby and Node.js here:
http://blog.metaobject.com/2011/01/nodejs-performance-httpd-... http://blog.metaobject.com/2011/12/ruby-and-rails-scalabilit... http://blog.metaobject.com/2012/03/30k-requests-aka-wrk-is-f...
Quite neat to use Obj-C and all the great frameworks on the web as well.
The big problem with using Objective-C for stuff like this is that you almost have to host it on Apple Hardware, which is quite expensive and hard to do by your self in a cloud-like fashion. With the Objective-C in the cloud service you move the hosting to them of course, but it is still a problem lurking when (and if) they are going to scale it really big.
…you are granted a limited, non-transferable, non-exclusive license:… (iii) to install, use and run up to two (2) additional copies or instances of the Apple Software within virtual operating system environments on each Mac Computer you own or control that is already running the Apple Software, for purposes of: (a) software development; (b) testing during software development; (c) using OS X Server; or (d) personal, non-commercial use.
So development, testing, running OS X Server, and non-commercial are the legal uses.
The Mac OS Server license is more restrictive, a single copy on Apple branded hardware.
EOM
In fact, one of my recent gigs was moving an Objective-C code-base from GNUStep/Linux to Mac OS X (and then with Cocotron back to Linux).
Objective-Cloud seems to be a perfect bridge between those worlds. After all: worry about scaling problems once you scale, because chances are you won't ;-)
And if you do scale up so amazingly that you outgrow Objective-Cloud or hosting your own, I am pretty certain that the transition will be less involved/painful/drawn-out than, let's say, Twitters move from Rails to Java. :)
*edit - my bad, it looks like that's not the primary use.
You can use Smalltalk-style messaging that C++ and C alone wouldn't give you. So you can query objects for methods, variables, and other things that they may or may not have without causing your entire app to crash.
You wouldn't have to wait at runtime for a VM to startup, since Objective-C has no VM. :)
Just a few things.
So you still have a hardware roadblock.
I generally find the hardware cost is not dominant with respect to bandwidth and physical placement costs. So even if you pay almost twice as much per compute cycle[1] it is still buried in the other deployment costs.
The bit that keeps me from using Mac Minis (and I have a huge software reason to do it) on my server end is that I don't trust that I can manage them remotely. If I can't get to a console and reboot with remote media I'm not willing to commit to it in production. If you are big enough to have 24x7 staff colocated with your hardware then things are a little different. Then they'll just cuss at you for making them drive a little cart with a monitor and keyboard around the place.
EOM
[1] It isn't that high for one unit, compared to reasonable quality commodity gear, but when you look to comparing, say 16 Core i5 processors of power there are some nice commodity solutions that are much cheaper than 16 minis.
Great idea you have!
Apple's apps are at a real unfair advantage, here.
Depending on how you're isolating instances I could see how that might open up a huge can of worms from a security perspective.
I can think of a couple of ways we could work together. Are the founders on HN ? Drop me a line.
While CocoaHTTP isn't bad, I've got my own lib that is not only around 3 times faster (request/response), but also has other benefits I'd like to keep.