By Vinay Joosery on May 19, 2008
We (in the Telecom team at MySQL) have been debating whether we should call this blog 'MySQL in Telco' or 'MySQL in Communications'. Naming discussions tend to take long time, and this one was no exception.
From a US perspective, it appears that Telecom is an outdated term. Wireless carriers and cable television companies do not consider themselves as Telecom companies. Maybe for this reason, large US-headquartered vendors including Sun, HP, IBM and Oracle all have a 'Communications & Media' practice.
From a European perspective, Telecom is used for equipment vendors and service providers. Companies like Logica, Cap Gemini, Atos Origin and TietoEnator refer to the vertical as 'Telecom & Media'.
Of the global SI's in India, Wipro and TCS refer to Telecom while Infosys talk about Communications.
As a working title we at one time used 'MySQL blablabla' blog, and funnily enough, there was a compromise suggestion to really use that for the name, since 'blablabla' is a term that incorporates something fundamental about 'Communication'.
So, after an interesting debate, we finally concluded that maybe it does not matter, and settled on 'MySQL in Communications'. However, telco and communications can be used interchangeably.
Coming back to the real business, MySQL has been making some solid progress in the telco space over the past few years. It started with the acquisition of the NDB Cluster database from Ericsson in September 2003. What a culture clash! Open source vs. proprietary software development. Having 2 masters to please, customers AND community. Rather than taking several hours, installation should take 15 minutes in order to satisfy impatient community users. Early releases would be made available to everybody, rather than a few selected friendly customers.
The integration took longer than what everybody had expected. It took over a year to have a first release of MySQL Cluster. Not the best release, but the technology was complex. Shared nothing database clustering! How do you make 10 machines act as one database cluster, accessed as one single database? How do you handle failures? How do you reintroduce a database node into a cluster running non-stop 20,000 tps and maintain data integrity? How do you provide mainframe reliability on commodity hardware? Quite a few challenges to address, but it did make a lot of sense to address these. The world is now building infrastructure using scale-out architectures to address massive online communities of millions of users, while the majority of database products on the market were designed in the 70's or 80's for more modest use cases.
Today, MySQL has a pretty healthy business in the area of subscriber data management for telecom networks, and global telecom vendors as well as small telecom startups build carrier grade, database driven infrastructure on top of the carrier product line.
In this blog we (the MySQL Telecom team) intend to write about some of the database trends that we see in the converging telecom and internet markets, and what we are doing in that area.