[Mono-dev] Cloud Based Solution

Rafael Teixeira monoman at gmail.com
Thu Apr 2 11:52:28 EDT 2009


Well done so far Keerthi.

see inline

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
> files)


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
> possible?
>

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,
> Keerthi
>
> 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
>> redundancy.
>>
>> 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.
>>
>> Enjoy,
>>
>>
>>
>> On Wed, Apr 1, 2009 at 12:03 PM, Keerthi Bharath <
>> keerthibharath at gmail.com> wrote:
>>
>>> Rafael,
>>>
>>> Thanks for your input. Actually I was thinking of doing it as part of
>>> GSoc.
>>> 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
>>> implementation.
>>> 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.
>>>
>>> Thanks,
>>> Keerthi
>>>
>>>
>>> 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
>>>> project.
>>>>
>>>> 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
>>>> help.
>>>>
>>>> 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
>>>>> apis.
>>>>> 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.
>>>>> -Keerthi
>>>>> _______________________________________________
>>>>> Mono-devel-list mailing list
>>>>> Mono-devel-list at lists.ximian.com
>>>>> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>>>>>
>>>>>
Miguel, or someone else in the list can give some feedback on this, or even
step in.

Thanks,


-- 
Rafael "Monoman" Teixeira
---------------------------------------
"I myself am made entirely of flaws, stitched together with good
intentions."
Augusten Burroughs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20090402/38c8b5b7/attachment.html 


More information about the Mono-devel-list mailing list