SQL Server Data Services (SSDS) is a nascent and very important, although inchoate Microsoft offering that combines LINQ with a remote managed persistence service built on SQL Server. This effectively places it in the vanguard of a new era of commoditisation for remote managed persistence services. This era has become feasible because of advances in internet networking and security. Unfortunately and obviously, it also adds several possible points of failure, some not under the direct control of Microsoft or its customers, challenging any claim that it is more reliable than an in-house solution. This will take time to be proven a trivial concern, especially for mission critical systems, but internet networking will become demonstrably increasingly reliable. The biggest potential customers, for whom downtime is a very undesirable cost, should be difficult to convince. They can afford their own substantial systems including redundancy, load distribution and failover features. They should also be able to get quite competitive hardware costs, although obviously not as good as a dedicated persistence services provider. Remote persistence services also introduces security and performance concerns. The former because your information is sitting on some hardware not under your control and to which you do not know who has access and shared usage of and that your information has to pass over a public network. The latter will never be overcome; performance can always be better with locally managed persistence services. How much Microsoft can narrow that gap to an insignificant amount for a given cost depends upon how efficient they can make their operations. However, critically and in the longer run, that is not their only selling point. When they have a lot of information belonging to many companies and individuals they can start to offer integration services and so competitive advantage that will be hard to ignore. This will give us the ‘information services’ companies that I think will come to dominate the information landscape of the future. They will be the ultimate power to which all must yield. It seems like the ministry of information is finally on the way and as Francis Bacon once said “knowledge is power”.
This is the start of a trend that will make the SSD affordable to the mainstream because of higher manufacturing volumes. SSDs significantly reduce the non-volatile storage IO bottleneck, filling a hole in the range of storage solutions. The important characteristic of SSD storage is that it is both non-volatile and provides random IO, unlike the HD which is non-volatile but serialises access along two dimensions.
The current high random IOPS of SSD and expected near future high total throughput will act as a catalyst for new programming solutions to problems. The storage spectrum now ranges through CPU cache providing small and expensive but very fast random IO volatile storage, RAM providing affordable volume fast random IO volatile storage, SSD providing expensive but random IO non-volatile storage, HD providing low cost volume non-volatile serialised storage.
I have not had chance to look at more than the demos on their site but I will be trying it out.
Winforms elements and so much more should be embedded in Silverlight™, not left to a third party to do it first. Come on MS, you know you can if you want to.
I have waited so long for Microsoft to get around to a CLR browser extension.
This is important to the overall trajectory of my development work and I think architecturally significant generally. In fact it is the most important architectural artefact I have seen in ages, or at least it has the promise to be.
On a macro scale this has the potential to rationalise the explosion in languages, development tools and runtime environments. So more effort may be put into developing useful functionality, rather than frittering it away on this or that new thing. It can also become a container for a range of more radical network enabled functionality that can evolve in the main independently from and therefore more quickly than the underlying OS.
When I switched my project from Java to C# around the start of 2005, one of the factors in my decision was an indication that a CLR would become available for the browser and that it would run MSIL download over the internet. This is important for two reasons: Firstly, it simplifies system load distribution, and could eventually simplify dynamic load distribution and balancing, because the same functionality can run on client or server hosts. Currently functionality development has to be fractured early in the lifecycle into multiple languages targeting different runtime environments and using multiple development tools. Secondly, the choice of development languages becomes independent of how system functionality is initiated and where it is executed. If I want to execute functionality on a client initiated using a browser, or using a smart client and use services running remotely, then I can do it all in any language I choose, so long as it can be compiled into MSIL for the CLR.
Gary E Byatt