Re: [firebird-support] Sizing conversion project
On 20-1-2012 23:23, Rick Debay wrote: > > > We are using Firebird and I've been tasked with determining the costs > for migrating to MS SQL Server. The last time I used the latter was ten > years ago, and in the role of a Java programmer. > Does anyone have any suggestions for how to come up with rough time and > cost estimates? > > Also, I'd like pointers to FB vs. SQL Server comparisons, so I add those > to the analysis. Obviously if the benefits don't exceed the costs of > the migration, it won't make sense. > > Last, I'd like to exceed the requirements and throw in DB2 and Oracle. > If we're forced to migrate, it doesn't make any sense to only consider > one database. > Why not throw in PostgreSQL while you're at it? I'm wondering about the reasons for the move: is it the number of experienced Firebird developers, Db appeal/populularity, size constraints etc? >From my (perhaps naive) point of view, going to DB2/Oracle/PostgreSQL smacks of possibly moving "up" as far as processing power is concerned, while moving to MS SQL Server smacks of going sideways or down... Some perhaps obvious points: - Knowledge gained through experience with Firebird will have to be replaced with knowledge of new db, which takes time & money (includes adapting for loss of FB functionality as Sean Leyne indicated) - Migration effort also depends on the programming language involved and support of that on the new db - Depending on your users, they might be more likely to fiddle with an MS SQL instance than a Firebird server, thereby breaking things. This may or may not influence support costs. - There is a MS SQL to Firebird migration guide that might give some pointers for the reverse direction, while a bit dated. - Migrating to MSSQL will tie you down to one server platform. Migrating to one of the others will allow you to run the server on Windows and various combinations of Linux/Unix. This can be a hidden cost in flexibility. - Firebird also provides for embedded deployment. For SQL Server you would use SQL Server Embedded (or some such) which is not the same as MSSQL Server (regular or Express Edition). You lose flexibility there, too. - Obviously MSSQL server can cost you licensing depending on which version you have to use for your product - If migrating anyway, why not go for some ORM or database independent driver solution (Hibernate, NHibernate, AnyDac) if the flexibility improvements outweigh increased development complexity, added support complexity and probable performance decrease Sorry, I haven't been involved in migrations and don't know if there is some formal method to perform these estimates. I'd be interested in hearing about those. Regards, Reinier
Re: [firebird-support] Sizing conversion project
Hello, Let me share some thoughts which are not related with email below, but inspired by it (as a consequence of long time thoughts and overview of our experience) First, I need to say that many IT managers and developers suffer from the "try to use a bigger gun" inferiority complex (for those who don't remember/don't know - in old Quake/Unreal when your player was killed by bot (computer), it gave sarcastic advice: "Try to use a bigger gun"). In our current world, when we decide what to choose it usually means "what to buy", and there is pretty stable dependency between price and quality - choosing more expensive car will give you more horse power and luxury options, for example. From this point of view even the first look at MSSQL total cost of ownership (licenses, hardware requirement, personnel costs) promises huge advantage over free Firebird. To give the idea for those who is not aware - end-user cost will be increased by MSSQL license (+Windows Server license), which is ~$7000 USD/processor for MSSQL Standard and ~26000/CPU for Enterprise. Is this not a bigger gun? :) Second, level of many developers is not sufficient to build efficient applications at Firebird, though their ego is big enough to claim Firebird "slow". Yesterday I spent 2 hour optimizing close-sourced application which was very slow with 1.5Gb database... simply because developers did not create several indices and also massively used SELECT DISTINCT to extract dictionaries (Zip codes) from the main table (1.5Mln records) instead of using separate tables. Luckily we have FBScanner to audit their ugly queries... though many things cannot be fixed. Bad developers (or, optionally, inexperienced guys) are always in place, and since there is no developers certification (as well as massive training courses), we will always see those who barely have read several chapters from Quick Start guide and shifted responsibility to Firebird. Third, there is "career" problem for IT managers. At the conference in Luxembourg I heard a story which illustrates the problem: one Firebird-company has won a tender over SAP and, after some time, successfully deployed Firebird-based system at customer's site, and it was a small party to celebrate its launch. After drinking some beers customer's CIO told that this deployment ruined his career: "If we would have a SAP, I can put in my CV line "Successful SAP deployment" and my next job would be some bank or Fortune-2000, and what I will write now? Firebird-based system?". This is a great temptation for IT managers with significant IT budget to spend it to high-priced products in order to enter club of "big guys" with (probably) better career opportunities , instead of following common sense and choose most efficient solution. In fact, migration to MSSQL (or Oracle, etc) is 100% mandatory/recommended only if database size is bigger than 1Tb or number users are more than 500. This situation can be changed with continued price decreasing for RAM, SSDs and other hardware. Right now I have draft case study from Australian company with 700Gb database (which is growing by 5-6 Gb per month) with hundred of users. Hopefully it will help (with others case studies http://www.firebirdsql.org/en/case-studies/) IT managers and developers to make right decisions. Regards, Alexey Kovyazin IBSurgeon (www.ib-aid.com) Firebird Project (www.firebirdsql.org) > We are using Firebird and I've been tasked with determining the costs > for migrating to MS SQL Server. The last time I used the latter was ten > years ago, and in the role of a Java programmer. > Does anyone have any suggestions for how to come up with rough time and > cost estimates? > > Also, I'd like pointers to FB vs. SQL Server comparisons, so I add those > to the analysis. Obviously if the benefits don't exceed the costs of > the migration, it won't make sense. > > Last, I'd like to exceed the requirements and throw in DB2 and Oracle. > If we're forced to migrate, it doesn't make any sense to only consider > one database. > > Thanks, Rick DeBay > > Disclaimer: This message (including attachments) is confidential and > may be privileged. If you have received it by mistake please notify > the sender by return e-mail and delete this message from your system. > Any unauthorized use or dissemination of this message in whole or in > part is strictly prohibited. Please note that e-mails are susceptible > to change. RxStrategies, Inc. shall not be liable for the improper or > incomplete transmission of the information contained in this > communication or for any delay in its receipt or damage to your > system. RxStrategies, Inc. does not guarantee that the integrity of > this communication has been maintained nor that this communication is > free from viruses, interceptions or interference. > > [Non-text portions of this message have been removed]
Re: [firebird-support] Sizing conversion project
Hello, > Let me share some thoughts which are not related with email below, but > inspired by it (as a consequence of long time thoughts and overview of > our experience) > > First, I need to say that many IT managers and developers suffer from > the "try to use a bigger gun" inferiority complex (for those who don't > remember/don't know - in old Quake/Unreal when your player was killed by > bot (computer), it gave sarcastic advice: "Try to use a bigger gun"). > In our current world, when we decide what to choose it usually means > "what to buy", and there is pretty stable dependency between price and > quality - choosing more expensive car will give you more horse power and > luxury options, for example. > From this point of view even the first look at MSSQL total cost of > ownership (licenses, hardware requirement, personnel costs) promises > huge advantage over free Firebird. > To give the idea for those who is not aware - end-user cost will be > increased by MSSQL license (+Windows Server license), which is ~$7000 > USD/processor for MSSQL Standard and ~26000/CPU for Enterprise. Is this > not a bigger gun? :) I fully agree, but what we saw when talking to companies, mainly in DWH projects, that the entire tool stack of SQL Server, even with the Standard Edition, is very attractive for the price compared to other commercial products or even with a combination of open source RDBMS and some independent DWH/BI product like Pentaho, Jasper etc. I would use Firebird as a relational backend whenever I can, but as an entire tool stack, SQL Server is very competitive to open source products. In another project I have been involved was to reduce licensing cost of their Oracle environment, as from history, they had quite a number of Enterprise Edition running and Oracle is famous to change license agreements. Sure, also open source RDBMS was a topic, but finally, as they are running a VERY critical business with a loss in the millions USD for an outage for a few hours, they simply need a solution where they can put pressure on it, if something fails from a DBMS POV, including support at their site within hours etc. IMHO Firebird is doing very well for deployments where people have no ideas about a DBMS or where people aren't using another RDBMS in their company yet. It's usually hard to convince people if they have an IT apartment, hosting already SQL Server, having knowledge for the product etc. > Second, level of many developers is not sufficient to build efficient > applications at Firebird, though their ego is big enough to claim > Firebird "slow". Yesterday I spent 2 hour optimizing close-sourced > application which was very slow with 1.5Gb database... simply because > developers did not create several indices and also massively used SELECT > DISTINCT to extract dictionaries (Zip codes) from the main table (1.5Mln > records) instead of using separate tables. Luckily we have FBScanner to > audit their ugly queries... though many things cannot be fixed. > Bad developers (or, optionally, inexperienced guys) are always in place, > and since there is no developers certification (as well as massive > training courses), we will always see those who barely have read > several chapters from Quick Start guide and shifted responsibility to > Firebird. I fully agree. The last few consulting stuff was mainly about performance issues with Firebird, which basically resulted in: - No tuning of the Firebird server in respect to RAM usage, header page settings, etc. at all - The developer had no idea what he was actually doing although not with FBScanner but with another product *g*. TABLE STABILITY isolation level, commit retaining behind the scence, read committed with no record version etc. A lot of weird things. That stuff would have bring SQL Server down as well, especially when it comes to concurrency control, because SQL Server doesn't have MVCC enabled per default. Giving them a basic class in 2 days about writing Firebird client applications sorted things out pretty quickly and are happy campers for a few weeks now. > Third, there is "career" problem for IT managers. At the conference in > Luxembourg I heard a story which illustrates the problem: one > Firebird-company has won a tender over SAP and, after some time, > successfully deployed Firebird-based system at customer's site, and it > was a small party to celebrate its launch. After drinking some beers > customer's CIO told that this deployment ruined his career: "If we would > have a SAP, I can put in my CV line "Successful SAP deployment" and my > next job would be some bank or Fortune-2000, and what I will write now? > Firebird-based system?". > This is a great temptation for IT managers with significant IT budget to > spend it to high-priced products in order to enter club of "big guys" > with (probably) better career opportunities , instead of following > common sense and choose most efficient solution. If IT managers
Re: [firebird-support] Sizing conversion project
Hello Thomas, Thanks for comments! > If IT managers have been money, they will spend it, usually to bring > them out in respect to liability. They simply want to call Microsoft, > Oracle if something bad happens with their DBMS. ;-) I used to sit near technical support team in Microsoft, including MSSQL, Exchange, etc. Without support contract they will do nothing (except point you to MSDN search). With support contract they can give you advice and answer some questions, but nobody will repair database or deep dive into issues, like connecting to your server by remote desktop, reviewing configuration and environment. There are few exceptions for Gold (Advanced) level partners, but "normal" customers are not treated like kings. Approach for disaster recovery, as an example - make backups (if you don't, you are not serious enterprise, and we don't work with not serious companies - 100% true!). Approach for high performance - suggest to hire/train stuff with MS certificates. > > > In fact, migration to MSSQL (or Oracle, etc) is 100% > > mandatory/recommended only if database size is bigger than 1Tb or number > > users are more than 500. This situation can be changed with continued > > price decreasing for RAM, SSDs and other hardware. > > Right now I have draft case study from Australian company with 700Gb > > database (which is growing by 5-6 Gb per month) with hundred of users. > > Hopefully it will help (with others case studies > > http://www.firebirdsql.org/en/case-studies/) IT managers and developers > > to make right decisions. > > Is the case study of the Australian company already available? No published yet. I'm waiting for approval of almost final version. Regards, Alexey Kovyazin
Re: [firebird-support] Sizing conversion project
Rick Debay wrote: > We are using Firebird and I've been tasked with determining the costs > for migrating to MS SQL Server. The last time I used the latter was ten > years ago, and in the role of a Java programmer. > Does anyone have any suggestions for how to come up with rough time and > cost estimates? You mean "beside licensing cost"? That depends largely on your applications and databases, so we would need more details: Do you use some Firebird specific features like Events? What programming language/libraries are used? It's easier to make a switch if you use Java application than if you use IBPP C++ library for example. Java might require a simple reconfiguration, while C++ would require rewrite of database access layer. If code is not properly decoupled from database access it can mean rewrite of large portions of the codebase. > Also, I'd like pointers to FB vs. SQL Server comparisons, so I add those > to the analysis. Obviously if the benefits don't exceed the costs of > the migration, it won't make sense. As someone who migrated from MSSQL to FB, I'd like you to first tell us why are you even considering going from rock-solid robust open source database to a closed one which has similar performance and feature set? -- Milan Babuskov == The easiest way to import XML, CSV and textual files into Firebird: http://www.guacosoft.com/xmlwizard ==
Re: [firebird-support] Sizing conversion project
On 21-1-2012 15:46, Milan Babuskov wrote: > What programming language/libraries are used? It's easier to make a > switch if you use Java application than if you use IBPP C++ library for > example. Java might require a simple reconfiguration, while C++ would > require rewrite of database access layer. If code is not properly > decoupled from database access it can mean rewrite of large portions of > the codebase. Although switching between JDBC drivers and databases is relatively easy, if you don't use an ORM or JPA-implementation like Hibernate or EclipseLink, you will probably need to rewrite (some of) your queries. And even if you use a JPA-implementation (or another ORM) you will need to make some changes to account for differences in feature support. Mark -- Mark Rotteveel
