Hi,

Any thoughts or news from the LLBLGen team on future support for SQL Services in the Azure platform? Would we be able to migrate from .net 3.5/asp.net/llblgen->sql2005 to Azure do you think?

Ries

V3 will support the entity framework as well, so you'd have support for azure right away. For the rest, I haven't payed that much attention to Azure other than that it looks like ms wants a piece of the bubble.

To me, it looked as if Azure was more like a set of services than a low-level DB with a query api, am I correct?

Good to know that the Entity framework will be supported. From what I have read and seen so far, Sql data services has an API that is quite similar.

Azure is actually a full native Windows OS as a service. The current CTP only supports .NET 3.5 though.

The Sql Data Services are a fully featured database-in-the-cloud with a public API (S-LINQ over Rest) that is running on Azure. See http://www.microsoft.com/azure/datafeatures.mspx

I think potentially there is a lot of feature in it, because it will relieve us (Amsterdam Software) from a lot of 24x7 datacenter/hosting support responsibilities. Our app is hosted and accessed by our clients globally, so having a 'cloud' to deploy it to, will relieve us from virtually all backup, scaling and geo-graphically dispersed connectivity/latency issues. If they do it right, that is.

Is your client willing to store their sensitive data in a database far away managed by MS? I wouldn't.

Of course, with outsourced server hosting, you also don't know who visits the server, but at least you can try to guard it (with cameras for example, cages etc. which is done at Red bus and telecity). With an outsourced cloud db, you never know who makes a copy.

Otis wrote:

Is your client willing to store their sensitive data in a database far away managed by MS? I wouldn't.

Of course, with outsourced server hosting, you also don't know who visits the server, but at least you can try to guard it (with cameras for example, cages etc. which is done at Red bus and telecity). With an outsourced cloud db, you never know who makes a copy.

IMO many of the concerns with a DB living far away can be dealt with using compliance and SLA contracts and these days, many companies dont house thier data onsite anyway. Having secure, on-demand scale out and scale up databases, which are managed by a provider will be much less expensive than trying to build a SOX404 or PCI Compliant data center.

I went to an Azure / Cloud Services event @ Microsoft before Azure was announced at PDC. I spoke with the SQL Data Services product manager and expressed concerns regarding security and SOX404 and PCI compliance. They assured me that there would be protocol in place for cloud databases so that they could meet regulatory requirements. Then, I almost fell out of my seat when they said that we would need to basically rewrite our database and our data access technology. The out of the box SQL Services will be very limited. The fact that the data is accessed over rest scares me the most. Other advanced things wont be there OOB, like triggers. Indexing and relationships should be there.

That being said, I think SQL in the cloud still outweighs managing a traditional RDBMS. I also beleive that the people who cut the checks will see it the same way as well. Its kind of like "Buzz word Bingo!".

In any case, I was poking around in the forums to see where LLBLGen will end up because one of my applications uses LLBLGen and my boss has asked me to start prototyping getting the app prepared for Azure.

With regards to the Adapter model, it seems like it would be fairly straight forward to create a new set of templates to output an adapter that would make calls in a SqlDataServices specific way. The trick would be generating the entity classes from the schema. I havent played with my Cloud Services account yet, but I suspect that I will be getting much more involved in the next 3 months.

At the end of the day, no matter what happens with LLBLGen, we can always colocate a traditional SQL database in the MS DataCenter or offsite, and have our cloud application talking to the traditional DB.

Devildog74 wrote:

Otis wrote:

Is your client willing to store their sensitive data in a database far away managed by MS? I wouldn't.

Of course, with outsourced server hosting, you also don't know who visits the server, but at least you can try to guard it (with cameras for example, cages etc. which is done at Red bus and telecity). With an outsourced cloud db, you never know who makes a copy.

IMO many of the concerns with a DB living far away can be dealt with using compliance and SLA contracts and these days, many companies dont house thier data onsite anyway. Having secure, on-demand scale out and scale up databases, which are managed by a provider will be much less expensive than trying to build a SOX404 or PCI Compliant data center.

I went to an Azure / Cloud Services event @ Microsoft before Azure was announced at PDC. I spoke with the SQL Data Services product manager and expressed concerns regarding security and SOX404 and PCI compliance. They assured me that there would be protocol in place for cloud databases so that they could meet regulatory requirements. Then, I almost fell out of my seat when they said that we would need to basically rewrite our database and our data access technology. The out of the box SQL Services will be very limited. The fact that the data is accessed over rest scares me the most. Other advanced things wont be there OOB, like triggers. Indexing and relationships should be there.

That being said, I think SQL in the cloud still outweighs managing a traditional RDBMS. I also beleive that the people who cut the checks will see it the same way as well. Its kind of like "Buzz word Bingo!".

heh

Data and information is the biggest asset in many companies and outsourcing that isn't something one will do often. Sure, they outsourced the maintenance and what not, but the databases are hosted in-house. At least as far as I know, it might be different in the US, not sure.

As you said, the service will be limited compared to a normal DB, so why bother? With the current crisis going on, companies have to be very careful what they spend their money on. And the past 5-10 years has learned that outsourcing isn't always good / cost-effective.

In any case, I was poking around in the forums to see where LLBLGen will end up because one of my applications uses LLBLGen and my boss has asked me to start prototyping getting the app prepared for Azure.

Did s/he say why Azure was required?

With regards to the Adapter model, it seems like it would be fairly straight forward to create a new set of templates to output an adapter that would make calls in a SqlDataServices specific way. The trick would be generating the entity classes from the schema. I havent played with my Cloud Services account yet, but I suspect that I will be getting much more involved in the next 3 months.

For v2, obtaining meta-data is crucial. For v3, model-first mapping could work, but it still would require a different runtime, as no SQL is executed over an ADO.NET connection, but rest-calls.

I can't help it but wonder why on earth anyone would ever want to query a big database over REST, unless the queries are not run frequently. (and with big databases, queries are ran frequently). I mean: it's overhead on top of overhead.

Data and information is the biggest asset in many companies and outsourcing that isn't something one will do often.

Salesforce is a good example of the contrary. ISP's can even add and sell their own applications, independent of the salesforce.com application, but based on the 'force.com' development platform. See http://www.salesforce.com/appexchange/

Ries wrote:

Data and information is the biggest asset in many companies and outsourcing that isn't something one will do often.

Salesforce is a good example of the contrary. ISP's can even add and sell their own applications, independent of the salesforce.com application, but based on the 'force.com' development platform. See http://www.salesforce.com/appexchange/

I'm sure some companies will do so, but do you see for example a big shift towards online document storage with google and MS compared to in-house file servers? no. For email? nope.

There are thousands of companies who do so, but many more who don't. For example, would you store your sourcecode on an online sourcecontrol service you pay X per month? If you would, don't you consider the risk of someone over at the service provider making a copy of your code ? It's the same with other info.

You asked why Azure. 1. we are a MS partner, so its a strategic advantage for us. 2. our app is .NET / SQL, so we are in the same technology stack so it makes sense. 3. Azure is the first "platform" in the cloud. Sure, Amazon has S3, RackSpace has Cloud Server, etc, but its not a 1 stop shop, pay per use, pay per cycle, scale up / out on demand in realtime.

As for Cloud File Systems and Cloud Email servers, many companies are leveraging these services. gmail has corporate mail solutions that are secure and offer more individual user storage that any individual IT should could afford for a fraction of the IT spend.

Yes, I do see companies choosing to reduce their IT spend. They always do.

If there was TFS in the cloud, I guarantee that my company would be using it cause we just dropped a fortune to implement it.

Yes, data is a security concern, I guess I am one of those people that beleive that if MS says that there will be compliance agreements in place then they will be liable. The same goes with version control, etc. They also say, that Azure services will be affordable to the startup and the exxon mobiles of the world.

On the other hand, it could simply be a strategy for MS to freeze the market. Who knows and I am sure that time will tell.

To me this is why a platform in the sky is win-win. Imagine that you design an application, and you need to get it into production. You will need atleast hardware, software, and IT people for operations.

Now you must decide "do i buy, lease, or use a platform in the cloud."

Scenario 1 - If you buy and the product flops, you have just spent a lot of someones money and when the project is cut because it didnt return a dime, there goes your job.

Scenario 2 - You could lease, and you would only be out the amount of the lease if the project flopped.

Scenario 3 - Lets say that your business owner hits a homerun with his idea and your widgets are selling like hotcakes. Now the servers you own or lease are taxed because the people cutting the checks for infrastructure went the cheap route and didnt buy enough server. Now, 3 months after release, youre loosing customers due to outages or poor performance. You are now faced with yet another decision - you have to lease or buy new hardware, have down time to bring the new hardware online, etc., to handle the new load.

My point - Scenarios 1 -3 are just a huge pain in the AXX.

Utopian Scenario - Consider, that you have a platform in the cloud -- that is secure -- is reasonably performant (even though its rest) -- handles whatever load you throw at it -- AND - youre only charged for what you use.

Its win win, because you havent invested a huge amount to get out the door and if you hit a home run, youre covered because someone else handles the scaling. Oh and now since business is booming, you want a data center to service the US west coast, Asia / Pacific, and Europe. You call your rep and a few days later, your app is migrated to the proper datacenters around the world.

It sounds great on paper, but it could happen.

Devildog74 wrote:

You asked why Azure. 1. we are a MS partner, so its a strategic advantage for us. 2. our app is .NET / SQL, so we are in the same technology stack so it makes sense. 3. Azure is the first "platform" in the cloud. Sure, Amazon has S3, RackSpace has Cloud Server, etc, but its not a 1 stop shop, pay per use, pay per cycle, scale up / out on demand in realtime.

As for Cloud File Systems and Cloud Email servers, many companies are leveraging these services. gmail has corporate mail solutions that are secure and offer more individual user storage that any individual IT should could afford for a fraction of the IT spend.

Yes, I do see companies choosing to reduce their IT spend. They always do.

If there was TFS in the cloud, I guarantee that my company would be using it cause we just dropped a fortune to implement it.

Yes, data is a security concern, I guess I am one of those people that beleive that if MS says that there will be compliance agreements in place then they will be liable. The same goes with version control, etc. They also say, that Azure services will be affordable to the startup and the exxon mobiles of the world.

They also said that about their healthcare site, which was breached not long ago.

It depends on what you think is a risk, I guess. Personally, I find the risk too high to have our sourcecode stolen, it's the one true asset we have. For other companies, vital information is perhaps essential for continuing the company and I can't imagine people sharing that information on an online storage.

On the other hand, it could simply be a strategy for MS to freeze the market. Who knows and I am sure that time will tell.

To me this is why a platform in the sky is win-win. Imagine that you design an application, and you need to get it into production. You will need atleast hardware, software, and IT people for operations.

Now you must decide "do i buy, lease, or use a platform in the cloud."

Scenario 1 - If you buy and the product flops, you have just spent a lot of someones money and when the project is cut because it didnt return a dime, there goes your job.

Scenario 2 - You could lease, and you would only be out the amount of the lease if the project flopped.

Scenario 3 - Lets say that your business owner hits a homerun with his idea and your widgets are selling like hotcakes. Now the servers you own or lease are taxed because the people cutting the checks for infrastructure went the cheap route and didnt buy enough server. Now, 3 months after release, youre loosing customers due to outages or poor performance. You are now faced with yet another decision - you have to lease or buy new hardware, have down time to bring the new hardware online, etc., to handle the new load.

My point - Scenarios 1 -3 are just a huge pain in the AXX.

I see your point, we moved our websites also to a virtual machine hosting environment recently, so we don't have the risk of waiting for Dell to bring the parts. So it has advantages, but not for every situation, IMHO.

Utopian Scenario - Consider, that you have a platform in the cloud -- that is secure -- is reasonably performant (even though its rest) -- handles whatever load you throw at it -- AND - youre only charged for what you use.

Its win win, because you havent invested a huge amount to get out the door and if you hit a home run, youre covered because someone else handles the scaling. Oh and now since business is booming, you want a data center to service the US west coast, Asia / Pacific, and Europe. You call your rep and a few days later, your app is migrated to the proper datacenters around the world.

It sounds great on paper, but it could happen.

Well, there's always a catch, just do good risk analysis of the downsides of outsourcing. And these downsides are always there, don't believe the hype.

So, I attended another SDR for Cloud Services last month. Its still looking pretty hot. Consequently, I thought I would dig up this thread. LLBLGen is still my favorite ORM tool and I would like to see you win in this department.

Given this statement below, do you think you may consider taking a closer look at supporting SDS?

Most importantly for developers, this means symmetric SQL Server functionality and behavior combined with compatibility with the existing tools you are familiar with.

            Tables?...Check

            Stored Procedures?...Check

            Triggers?...Check

            Views?...Check

            Indexes?...Check

            Visual Studio Compatibility?...Check

            ADO.Net Compatibility?...Check

            ODBC Compatibility?...Check

To be clear, the above is not a complete list of supported features. However, given the feature set we are planning to support in SDS v1, a majority of database applications will “just work”, allowing developers to target on and off-premises deployments with essentially the same code base.

Read the full announcement here: http://blogs.msdn.com/ssds/archive/2009/03/10/9469228.aspx

It might be a thing we'll support in the future, yes. Especially considering that v3 will have forward modeling/mapping so it's not totally dependent on the fact that it has to obtain meta-data to be functional.

Though it won't be in the v3.0 release box, though we planned more smaller releases after that (so no longer 8-10 months release cycles after v3.0) so if everything fits, we might support SDS in the future.