I have been involved in some discussion around software as a service lately.  While the general consensus is that this is going to grow into the mainstream method of software delivery, right now there are a number of challenges that need to be addressed before this will happen.

We provide RockSolid in both SAAS form and a traditional installed onsite model, the product functionality is exactly the same, the difference is how you install it and how you pay for it.  SAAS requires minimal infrastructure onsite and is paid for as a monthly fee, the installed onsite mode requires suitable server infrastructure to house RockSolid and is paid for as a one off perpetual license cost.

We have a mix of SAAS and installed-on-site customers, while many of the challenges faced that are being debated are technical, the following are the issues we face positioning SAAS in order of occurrence:

• CAPEX vs OPEX. The primary issue we encounter when positioning SAAS is an organisations budgeting process hadn’t planned for a SAAS offering. Many customers get a CAPEX budget approved in advance, then evaluate tools and on making their selection they need to spend the budgeted CAPEX. An OPEX based SAAS offering may be a good fit for them, but the requirement to go back and redo budgeting is so undesirable that almost always in this situation the customer will elect the CAPEX option.
• Security of Information. Quite rightly so, the second most common issue faced is dealing with internal security concerns/requirements. Now RockSolid is a management infrastructure, it is not working directly with business data, only the operational meta-data that surrounds it. Yet the security concerns are very much there. Some organisations have blanket “no data outside the enterprise” policies, others and more willing to investigate the security implications and make an informed decision. (fyi, RockSolid’s security has been reviewed hundreds of times and always found to be very complete and comprehensive).
• Unfamiliarity with SAAS. The final common issue faced with SAAS is just unfamiliarity with the model. Some organisations have hundreds, or thousands, of applications that are installed on PC’s or Servers, that is what they know and they have no desire to change the model. Overtime as more applications go down this path this will start to change, but for now the level of practical enterprise SAAS applications is so low that a revolution isn’t on the card for some time.

The interesting thing is these issues are faced in positioning a management infrastructure, with companies such as Microsoft, Google, Amazon launching their “Database in the Cloud” offerings, a whole bunch more issues are added which makes entry into the enterprise of such services very difficult at the present time.  I am preparing a post on this.

I agree whole heartily with this post and have posted similar comments in response to a post around how Google is dealing with their “brains” leaving and setting up their own start ups.  I believe the successful execution of an innovation is just as important as the innovation itself. 

Small “start ups” do well at getting ideas off the ground, proven and to market.  A small group of highly motivate people whose very survival depends on the successful development of their idea has a natural advantage, it’s do or die.  And while sheer grit and determination are great for getting the product into existence, if they are traditional (enterprise) applications the struggle is the “execution” of the go to market strategy, that is the pavement pounding, product support, sales, marketing, pre sales, account management, relationship building.   You might have these requirements nailed for customers in your immediate vicinity, but grit and determination aren’t going to get you a worldwide sales, implementation and support teams anytime soon.  Trying to build this organically will take years and will cause much distraction to the core competency, the innovation itself.

Larger, especially public companies, have a responsibility to be risk adverse.  They need to protect their market position, their shareholder value and can’t be continually “betting” this by undertaking high level of risk through the developments of new and unproven innovations.  But why would you?  If you have the cash flow, the market position, the distribution channels, global sales and marketing capabilities, why undertake lengthy and risky new innovation development, when instead you could be rapidly acquiring and fully commercializing proven innovations.  Does it matter that you may pay more than if you developed it yourself?  If the numbers are still in it, then isn’t the premium a reasonable cost for time to market and a level of risk reduction?  Doesn’t it serve you better to maintain a strong product strategy, maintain development teams for existing product development (which may include integrating acquired innovations), building and maintaining the customer relationship and running a successful model for filling the gaps in your product strategy through acquisition?

This is largely happening now as most of the big software companies are working hard to protect their positions while continuing to remain competitive and increase their customer base.  But as I found out in a meeting with one of the worlds largest software companies some time back, it isn’t necessary a talked about or accepted strategy (the opening of one meeting went along the lines of “Well obviously we could have developed this ourselves…..” in my head my response was “you could of, but you didn’t and you probably shouldn’t have anyway”).  Maybe the aversion to acknowledging this as a valid business model is fear of external perception of the company (they have 10,000 employees but they buy all their ideas…) or a fear of upsetting their existing development employees, I am not completely sure.

Anyway, what I do know is that many great innovations (in traditional applications) will continue to happen in start ups, the only way they will become successful is through acquisition by a partner with a global reach and over time the best people in those organisations will typically move on to pursue their own ideas in start up form.

There are some revived talks about in memory databases, partly due to IBM’s release of SolidDB for DB2 (and Oracles of TimesTen).  This is an area that I spend a bit of time working in so let me share a few thoughts. 

Initially in memory databases sounds like a good idea.  Existing databases are disk based, disk is slow, memory is fast, in memory databases will offer huge performance improvements right?  Well like everything, sometimes.  You see while existing database severs (SQL Server, Oracle, DB2 etc) persist data on permanent storage media, usually disk, any database server worth its salt fully utilizes available memory as cache of disk data.  And usually there is a lot of smarts around how this cache is managed, if physical RAM is less than the total size of the database, then the cache (or buffer pool) is managed to ensure what is in that cache is the most useful, most actively used portion of the database.  To improve your caching capabilities, you increase the amount of memory available.

So normal, On Disk databases are actually doing a lot of work in memory.  Many transactional databases actually achieve “cache hit ratio’s” in the range of 98%+ which means that they are only actually going to disk for <2% of the requested data.  However because of the multi layered approach, pure In Memory databases can reduce the level of complexity, potentially leading to performance improvements.

Advantages of In Memory Databases
Because the buffer pool can be used to store any bit of disk data in cache temporarily, when you are accessing a particular piece of data, a mapping and lookup process has to occur to find out where in the buffer pool that particular piece of information is currently located, or if it is in the buffer pool at all.

A pure In Memory databases on the other hand, usually loads the entire database into memory on startup, and references all the database data using known memory addresses, thereby greatly reducing the amount of mapping/locating overhead that occurs on every request.  This can have significant performance improvements, however of course the entire database has to be able to fit into memory.

Disadvantages of In Memory Databases
Commonly, core enterprise databases are in 100-500GB size range (many are much larger than this) while a server with a “large” amount of RAM today would be in the 32-64GB range.  Obviously this fast discrepancy between data volumes make In Memory databases impractical for most mission critical databases of a larger size (or have the potential to grow larger than memory limits).

Additionally memory is not persisted, which means if a failure occurs on the server running the In Memory database, changes that have occurred in memory will be lost.  To compensate this, most In Memory databases have the ability to log transactions to a disk to ensure recoverability.  Of course this goes a long way to undoing the benefits of the In Memory solution (depending on the type of Workload) so many In Memory database offer options to allow risk/performance to be balanced by reducing the frequency that logging occurs (which increases amount of data changes that could be lost if failure occurs).  Again this only suits certain types of workloads, many workloads a small window of loss is acceptable and many workloads any form of transaction loss is unacceptable.

Suitable Uses of In Memory Databases
So it is clear that In Memory databases do not replace existing, more traditional database server technologies, instead they complement them and offer the ability to improve workloads with pretty specific characteristics.

Ideal workloads for In Memory databases include:

• Read Only datasets – Data is read under high volume but changes are very infrequent / non-existent from the application clients (e.g. product web content, product catalogs). Updates may still occur, but if these are managed update the cache contents can also be managed.
• High volume data with accepted margins of error. Many datasets do not need to be 100% accurate all day every day. For example, collecting web site stats, you might accept a risk for losing some data occasionally as a trade off for performance improvements of being able to process a higher transaction rate.

Hybrids
More commonly, In Memory databases are being used in conjunction with traditional On Disk databases to provide caching for a nominate set of tables.  These tables are cached from the On Disk database, the application connects to the In Memory database but all requests that are made of tables not memory are transparently passed through to the On Disk database.  This allows the cached tables to be accessed quickly, but allows highly transaction tables to be passed through and avoid the limitations of the in memory database.

Hybrid Limitations
The real problem with the hybrid model is that the tables most suitable for caching are not usually the tables that are contributing to the bulk of the performance overhead.  The tables causing the bulk of performance overhead are typically the large and highly transactional tables that do not lend themselves to an In Memory model due to their data volatility and strict persistence requirements.  While the smaller, and less transactional tables can be cached, often queries issued against the “database” involve both sets of tables (reference data, transactional data) meaning the overhead is still occurring on the On Disk database.

While RAM sizes are growing, database sizes are growing just as fast, if not faster, therefore it is unlikely we will reach a stage where RAM sizes will be adequate to cache all mainstream databases anytime soon. 

For In Memory to be truly universal what is needed is a solution that moves beyond caching raw data, and focuses on caching data from a different perspective, further down the processing path.  This solves a bunch of issues, but also introduces a whole new bunch! 

Stay tuned as I start to share about innovations being made in this area.

I have the opportunity to discuss server partitioning once with Jim Gray, a brilliant man and a tragic loss.  I couldn’t make the event but the void he left is still apparent over 1 year on.

Update

Proceedings of Tribute to Honor Jim Gray (June 2008 issue of SIGMOD Record) is published online at www.sigmod.org/record/jimgray.

While I have an active interest in Web 2.0 and new media, I still maintain a strong passion for innovation in core business and infrastructure technology, I like, for lack of better acronyms, to ensure the bread and butter doesn’t stray too far behind the jam.  RockSolid is one such infrastructure innovations that I have had a hand in bring to life, and the purpose of this entry is to remind all the innovation is still very much alive and well in infrastructure and non consumer focused technology.

RockSolid is an advanced SQL Server management platform for enterprise customers.  As expected, when the sales team first speaks to potential customers about RockSolid one of the first questions that comes up is how RockSolid differs from existing management tools, such as those offer by Microsoft in Systems Center.  To answer that we could do a feature by feature comparison and talk about the hundreds of different individual features, but in fact the differences are much more fundamental that this.  Let me talk about three Levels of systems management which will clearly highlight the core and fundamental differences:

Level I – Manual

• Monitoring of a system is manual
• Issue recognition is manual
• Issue resolution is manual

This traditional DBA management environment in which the DBA manually, checks, resolves and manages a system.  Despite tools being available for years many sites still manage SQL Server a this Level.

Limitations of Level I
The issue with this type of management level are obvious.  Issue identification and therefore resolution is subjective, delayed and purely reactive.  Human error and skills gaps can mean issues are not identified until after they have had a negative impact.

Level II – Automated Monitoring

• Monitoring of a system is automated
• Issue recognition is automated
• Issue resolution is manual

This is where the majority of SQL Server management tools sit today.  This is a huge improvement on Level I.  Issue recognition means that critical impending issues can be resolved by the DBA before they cause major negative impact.

Limitations of Level II
Ok I will spend more time here as this is really key.  The limitations of Level II while not as obvious as Level I, do still exist and have just as much impact as those as Level I.

Monitoring of purely reactive factors produce a set of reactive issues which the DBA team can reactively respond to and recover from whatever impact was encountered.  But if you want to increase the depth of your analysis and start being more proactive, then this has the inverse affect of increasing the number of issues that are raised.  While this could be considered a good thing, unless you increase the DBA team capacity required to resolve the resulting issues, what actually happens is due to your limit in capacity only the most critical issues are resolved and the remainder of the less “not critical right now” issues ignored, i.e. the benefits of increase analysis and being truly proactive are negated.  Speaking to many customers with existing Level II SQL Server management tools, many have switched off most of the issues analysis functions due to a limited capability to deal with the vast quantities of issues raised.

Ok a change in scenario, how about we don’t increase the depth of our analysis as above, instead we simply increase the scale of our analysis. SQL Server is implemented in vast quantities in enterprise customers, 100+ production systems is not at all uncommon.  So let’s take the analysis we have and add several hundred instances to the analysis pool.  Without any increase in depth over purely reactive issue analysis, due to the increase in scale alone, the number of issues that are being generated as a result is much higher.  Again to deal with this vast surge in the number of issues we need to increase our DBA team resource (costs), or actually reduce the level of resolution (quality) as our scale increases.

Level III – Automated Management

• Monitoring of a system is automated
• Issue recognition is automated
• Issue resolution is automated

This is where RockSolid sits.  Not only does RockSolid analyze monitoring data and raise issues in real time, the automated issue resolution agent takes on those issues and carries them through the resolution process (of course this all happens as directed and controlled by the DBA team, automated does not mean without visibility and control).  In addition all proactive management and preventative maintenance is automatically implemented and maintained in accordance to the site standards defined by the DBA team.

What this approach means is that

1) We can increase the depth of our analysis and not only deal with issues that have a critical impact, we can deal with all issues of all severities from critical down to organizational best practice.  All issues can be resolved regardless of our DBA team capacity because the issues themselves follow the resolution paths established by the DBA team.

2) We can vastly increase the scale of analysis (the number of instances monitored and managed) without decreasing the level of management quality and without vastly increasing our DBA team resources (increasing costs).

The RockSolid SQL Server Management platform is proving to be a new breed of systems management application, and is quickly making an impact in the customers where it has been deployed.  RockSolid is now managing over 10,000 production databases and we are seeing both the promised drop in operational costs and the increase in service levels being achieved.

Microsoft has announced that if will acquire Pro-Clarity.  This is an important move by MS, to date the client facing toolset of SQL Server Analysis Services has been very poor with many organizations struggling with Excel pivot tables. 

In case you haven’t already heard, SQL Server 2005 RTM has shipped.  MSDN subcribers can download the developer edition from the subcriber downloads section.

With over 5 years between releases, this is certainly an exciting release from Microsoft.  And the good news is that it appears pretty stable, many of our customers have being ruuning SQL Server 2005 in some form or another in production since BETA 2.

From IDM.NET.AU

Has Microsoft’s SQL Server missed the boat?
Nov 17, 2005: With five years between updates Microsoft SQL Server 2005 is out, but can it deliver in the face of energetic open source competition?

What this article fails to mention however, is that I haven’t really seen any wide spread critical demand for SQL Server 2005 from existing SQL Server 2000 customers.  There are two key drivers for upgrades, new applications and problems with existing platform.  The existing SQL Server 2000 platform, for the majority of users that I know, had very few issues and weren’t really too concerned about when the upgrade was going to become available.  In fact a few years of platform stability has been a welcome luxury.  Now that it’s released, many organizations plan to start looking at it with a view to implement mid 2006. 

New applications one the other hand is the current driver, but the development of these tend to align with the product release cycle.  Sure we have rolled out a number of Analysis Services 2005, Integration Services 2005 and Reporting Services 2005 applications but only because this line up with the release schedule provided by Microsoft.  Don’t get me wrong, there are many great benefits in 2005, but I see these being mainly for new apps.

Some of the more major “left field” features introduced in SQL Server 2005, .NET integration, XML data types, Service Broker, are not yet even fully understood by many and I only see pockets of demand today for such features.  But again, I expect this to change rapidly mid 2006 as the business benefits start to become apparent, and best practices are developed through others successes and failures.

From ExtremeTech:

Intel shifted the majority of its Pentium 4 processors to 64-bit capability over the weekend…

 

For those who are not up to play on 64 bit in the Wintel space, the general message is:

• x86 32bit – is to become legacy


• x86 64bit – is to become the new mainstream


• Itanium II – Is to retain it’s position of high end

Microsoft has announced the week of the 7th of November as the release date of the next version of SQL Server, which is shaping up to be as significant release as SQL Server 7.0.  The credibility and industry confidence in SQL Server 2000 is massive, so there is lot on stake.

http://www.microsoft.com/presspass/misc/06-07flessner-teched05.mspx