[Mono-dev] Cloud Based Solution
monoman at gmail.com
Thu Apr 2 11:52:28 EDT 2009
Well done so far Keerthi.
On Thu, Apr 2, 2009 at 7:48 AM, Keerthi Bharath <keerthibharath at gmail.com>wrote:
> Hello Rafael,
> Sorry for the late reply. It took me quite a day learning the inner details
> and workings of the entire azure framework.
> Well, I went through the actual process of developing an app and deploying
> in the cloud. Sorry for boring you with all this technical stuff. it works
> like this.
> In the cloud, they have this storage and processing. And in the documents,
> it says you can't have a debugger in the cloud. So development had to be in
> the desktop.
> And they have this simulated cloud environment for the desktop - which
> consists of the STORAGE(queue,blob,tables), SERVICES(starting and stopping
> and service related stuff), and couple of command line tools to move the
> developed soultion to the cloud.
> For the actual cloud they do have all these APIs for storage, and the ones
> you said web-facing synch process and background async process and all that.
> So to bring real value to the Mono and linux user, it makes sense to first
> simulate the cloud environment at the desktop. So if we are able to develop
> the application(simulate) at the desktop level using mono, the cloud bases
> apis which would be developed at the next stage and it would help the
> desktop application to move to the cloud. The moving to the cloud is all
> browser based and so intuitive - ie if we get the desktop app to work, you
> can easily port it to the cloud.
> So I think the best way for me is to start implementing the desktop based
> simulation of the cloud. So how to approach?
> i) Services part - The azure actually configures IIS 7.0 to emulate the
> cloud based envi at the desktop level. It need to have WCF Http activation
> and asp.net 2.0. So I have to work with Apache regarding this I guess and
> lot of coding
You can leverage mod_mono here, but as I said worker processes tend to need
an specialized container.
> ii) Storage part - They simulate the cloud based storage (blob,tables) at
> the desktop level using SQL server with limited functionality ie no https,
> not too much scale.Is it Mysql on our part? and intensive low level coding
Keep storage details abstract, for instance using NHibernate/ActiveRecord to
hide which database is being used. No need to restrict it to MySQL or
PostgreSQL, Even SQLite can be a viable alternative for this simulation.
> iii) And I have to look at the command line tools for porting the dsktop
> appln to the cloud( Still haven't figured out the inner details
That seem to be easy IF YOU HAVE THE CLOUD, or at least it's protocol specs.
> iv) And finally the UI part, showing the user the simulation like how many
> instances of an application are currenly running and if possible having the
> project as part of a template( like including the necessary config and xml
This may even be a separate project, as it can be complex.
I think that we would be better served to have the UI hosted as an addin in
Monodevelop as well as the services, to integrate with the debugger.
> These four features are the intial milestones of the big project I think
> and which I can specify in the proposal I guess.
> Please let me know, whether this is viable and could you be my mentor, if
It still looks like something a bit bigger than what GSOC time-slot would
accomodate, but it may be good to propose.
And, no I can't be your tutor, as I don't have the time and skills needed to
to play well that important role.
> Thanks for helping me out,
> On Wed, Apr 1, 2009 at 1:10 PM, Rafael Teixeira <monoman at gmail.com> wrote:
>> I've not experimented with the CTP (I am still bound to VS2005).
>> I've just read a bit about the architecture, and the developer experience
>> inside newer VSes.
>> Yes you can model part of the per-node runtime for the processes after
>> asp.net, but remember that typically they separate the processing in two
>> parts: the web-facing synchronous process (similar to ASP.NET) and the
>> background asynchronous process which needs a much simpler container.
>> Keep counting, two services/daemons until now, not accounting for needed
>> Also the queues, and blobs have to be managed in separate containers, and
>> also failure/performance monitoring and load balancing.
>> We are talking here of at least half-a-dozen services/deamons per node.
>> Each one with specific requirements, most of them not so similar to an
>> asp.net container (for that part you can take a look at our xsp/mod_mono
>> code, that have some startup code and then rely on a library that implements
>> most of the asp.net host logic).
>> Also you'll need to determine which protocol all those pieces will use to
>> interact with each other, as AFAIK those are blackboxed in Azzure. Remoting
>> is a possibility but it doesn't deal easily with dynamic redirection as
>> needed for the 'cloud', in that regard even WCF needs to be trubo-charged to
>> be able to be used in such scenario, and beware, mono still doesn't have a
>> full implementation of WCF.
>> But go ahead Keerthi, explore the issues a bit more, look at our code and
>> come back with more specific questions, we'l be glad to answer.
>> But I'm quite sure it is too big a project for GSOC, you'll need to find a
>> smaller part of it to propose and see if someone here can be your tutor.
>> On Wed, Apr 1, 2009 at 12:03 PM, Keerthi Bharath <
>> keerthibharath at gmail.com> wrote:
>>> Thanks for your input. Actually I was thinking of doing it as part of
>>> Actually the Azure is in CTP and the addin tool currently released,
>>> replicates what the application can do in the cloud instead of the actual
>>> Could you please give me some pointers on how to proceed with the Azure
>>> development runtime. I assume it is similar to Asp.net runtime.
>>> You could have run in to the same kind of problems and solutions while
>>> designing the runtime. It would help me a lot.
>>> On Wed, Apr 1, 2009 at 10:36 AM, Rafael Teixeira <monoman at gmail.com>wrote:
>>>> It seems to be a very complex project and encompasses things like
>>>> managing multiple servers, having backend storage with automatic
>>>> replication, performance monitoring, etc,, meaning possibly interacting with
>>>> many other (unmanaged) projects. It is probably a larger than mono itself
>>>> Not to fright you, but it seems like something that need a lot more
>>>> investment than volunteer effort.
>>>> Nevertheless, I can envision someone implementing something like the
>>>> Azzure development runtime, which is mainly implementing the APIs with no
>>>> "cloud" to back it, in just some months, or less if more people volunteer to
>>>> Make it expand to work in a reliable and manageable form in an actual
>>>> cloud of servers is what is really the hardest target.
>>>> Have fun,
>>>> 2009/3/31 Keerthi Bharath <keerthibharath at gmail.com>
>>>>> Hello Everyone,
>>>>> I want to know, whether we have already or in future have plans of
>>>>> implementing windows azure services( cloud based platform) as part of Mono.
>>>>> I developed an application with Azure( based on .net 3.5 sp1). It ran
>>>>> without any issues with MOMA. But when I tried it with Mono develop, it says
>>>>> the application is not supported. So I assume we have not developed the
>>>>> So I thought, it would help the mono and suse community immensely if I
>>>>> try implementing the APIs with regard to the azure services.
>>>>> The azure runtime environment seems similar to ASP.net( with the xml
>>>>> config files).
>>>>> It would be very helpful, if you could let me know whether this is a
>>>>> viable project to start working on and please let me know where I can start(
>>>>> probably some pointers from people who have implemented asp.net kind
>>>>> of func in to Mono)
>>>>> Thanks for helping me out.
>>>>> Mono-devel-list mailing list
>>>>> Mono-devel-list at lists.ximian.com
Miguel, or someone else in the list can give some feedback on this, or even
Rafael "Monoman" Teixeira
"I myself am made entirely of flaws, stitched together with good
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Mono-devel-list