Pinderkent

Anand Iyer recently wrote an article that transcribes a portion of a video in which Joel Spolsky is discussing the hardware and software that is backing the very useful and increasingly-popular Stack Overflow Web site. It's mentioned that there is one Web server and one database server, both running on "eight core Xeons" and serving "16 million" pages a month. At first, that sounds impressive. But thinking about it more, I'm not so sure it really is.

First, we should convert that value of 16 million pageviews into something we can comprehend better. Assuming a month of just 30 days, a quick bit of math shows that to be 2,592,000 seconds. Sixteen million pages over that number of seconds ends up being a mere 6.2 pages per second. Now, that's probably not a totally accurate picture. There are no doubt times when the traffic is much higher than that, and other times when it's lower. But even if their overall pageview traffic were to triple or quadruple, we're still not seeing huge numbers of simultaneous page requests.

I don't think people today truly realize the power of today's hardware. Even the low-cost, consumer-grade PCs you can buy for a few hundred dollars are significantly more powerful than the servers of just a few years ago. So I don't think we should get too excited about Stack Overflow being able to serve 6 or 7 pages per second, if not many times that during periods of heavy load, over what's essentially 16 very powerful CPUs.

Thinking back to some of the database-backed intranet Web sites I've worked on in the past, we were able to reasonably handle sustained traffic of 30+ pages per second at times on far inferior hardware. This was even when we still used CGI scripts written in Perl, which have not only the overhead of starting up the interpreter process with each request, but also the overhead of the program interpretation itself.

I recall one job in particular because of how rushed it was. The company had several call centers located throughout the world, and was moving towards a custom Web-based solution for the call center operators to use. Expecting up to 30 simultaneous users per second at peak hours, they had placed an order for some significantly powerful hardware at that time. The order was delayed for some reason, but management wanted the site to go live. So the decision was made to temporarily use some older, unused Sun workstations as servers. I recall spending a night getting two workstations set up as Web servers, and one as a database server, so the system could go live the following morning. It went live, and everyone was very surprised to find that even under higher than expected load, running on older Sun workstation hardware and using Perl CGI scripts, the responsiveness of the Web site was quite acceptable.

Now, I don't expect that to be the case all of the time. Like Joel points out in his talk, there are many sites even today that use significantly more hardware than they probably should. But with some sensible caching policies and a small degree of care while programming, it really wasn't overly difficult to get high-traffic sites running on a small amount of lower-end hardware. Even in Stack Overflow's case, it sounds like they could get by very easily with a small fraction of their current infrastructure. However, it is good to have room to grow, as the traffic to that site likely will.

Computer hardware today is extremely powerful. For most Web sites, even those getting millions upon millions of pageviews per month, scalability just shouldn't be an issue. If it is, it's likely that there have been some pretty significant programming mistakes made when developing the software powering the Web site. And with low-end servers today typically coming with eight or more logical processors and many gigabytes of memory, servicing hundreds of requests per second from a single system should be considered routine.

There have been reports recently suggesting that IBM may soon acquire Sun Microsystems. For those of us in IT, acquisitions of these types are always a big deal. While Sun's server hardware is widely deployed and of great importance to many, my interest is mainly in software, so that's the area I'll focus on in this article.

In the software world, Sun is most well known for Java and Solaris. I suspect that we'll see two very different outcomes for these technologies if an acquisition does occur. It's difficult to say what will happen for some of the smaller or more obscure software products and projects that Sun was involved with, such as OpenOffice.org and NetBeans.

In terms of Java, I don't think we'd see much, if any, negative change. IBM has embraced Java, and understands its use, at least for business users. For some time now they've provided their own JDKs for a number of platforms. Java also plays a significant role in their prominent WebSphere Application Server. They're actively involved with developing new Java-based technologies. And their involvement and contributions to Eclipse have had a huge impact within the development community.

In some respects, such an acquisition may be quite good for Java. Although known for generally being more conservative, IBM does have the resources needed to make the changes to the Java language and platform that are necessary for it to compete better with Microsoft's .NET platform. We need to see half-baked technologies like JavaFX and JavaFX Script discarded. But we also need to see functional or object-functional languages like Clojure and Scala perhaps brought in as core components of the platform.

If IBM put their weight behind such technologies, we very well may see more developers be willing to adopt them. As we move into a world with massively multi-core CPUs, we will need to make use of functional programming techniques to write scalable software that effectively uses such hardware. Given IBM's (and Sun's) emphasis on high-end server hardware, a willingness to adopt and support Scala and Clojure could really put them in the lead in this area.

Things don't look as good in terms of operating systems. As basically everyone in the industry knows, Sun has offered Solaris for years, while IBM has offered AIX. While both high-end UNIX-based operating systems, I'm not certain if they could be successfully integrated. At a technical level, I suspect they are just too different.

If an acquisition were to take place, I imagine that Solaris would be supported for some time, but eventually deprecated in favor of AIX. This would be similar to what happened to Tru64 UNIX when HP and Compaq merged. If I recall correctly, HP originally planned to transition Tru64's more advanced features to HP-UX, but this didn't end up happening, for the most part. Now Tru64 is essentially on its last legs.

Given that Sun has released much of the Solaris source code over the past few years in the form of the OpenSolaris project, it seems likely that it will live on in at least some form. A truly self-sustaining community, akin to the Ubuntu project for Linux never seemed to develop, however. So it's difficult to say how much, if any, innovation we'd see out of the OpenSolaris project were Sun no longer supporting it.

Another interesting area to consider is that of the MySQL-related technologies and business that fell into Sun's fold with their acquisition of MySQL AB at the beginning of 2008. Given IBM's pivotal role in the development of relational databases, and their offering of the very solid and professional DB2 family of database products, MySQL's future in such an organization seems quite limited. Even within the open source community, MySQL is generally considered an inferior RDBMS. I really can't see it having much of a future, especially with Marten Mickos and Monty Widenius out of the picture.

We'll just have to wait and see what comes out of these rumors. But in terms of the software world, such an acquisition could have some significant impacts. They'd mainly be felt by those working with and developing enterprise systems, but may still be noticed by others, including, for example, OpenOffice.org users. So I see such an acquisition as potentially being good for Java, but less so for the Solaris, and potentially disastrous for MySQL.

I read an article today suggesting that functional programming hasn't caught on widely because most developers today haven't been convinced that it is necessary. I'm not sure that's completely correct. Those who are truly "in the know" will have been at least investigating functional programming for some time now. The rest can merely be considered stragglers, who don't yet realize that they currently do have, or will have, a need for functional programming in the near future.

Although it was clear several years ago, we can now say with almost complete certainty now that we will soon be seeing consumer-grade PCs with 32 or more logical processors. Intel's Core i7 has recently brought us part of the way there. At the higher end, Sun's UltraSPARC T2, for instance, offers 8 cores for 64 threads of execution. The trend is obviously towards processors offering multiple cores, each of which may offer multiple threads of execution. And today's mainstream programming languages just don't take advantage of such environments too well.

Some industries have dealt with these issues already. That's why Erlang has been around for over 20 years now. Anyone who has worked on telecom systems or even just worked with Erlang knows the benefits that its concurrency model brings. These days, with the advent of consumer-grade multicore CPUs, such benefits are applicable even when using the low-end systems. In fact, to make the most of today's and tomorrow's CPUs, we will need to develop our software to be more concurrent.

To do this effectively, we likely will need to make use of at least some of the techniques pioneered by the functional programming community. Immutability is perhaps the most important and useful technique when writing concurrent software. Strong, static typing as offered by languages like Haskell and Standard ML is also very useful. Well-integrated support for writing concurrent applications, such as that offered by Erlang, is another major benefit.

However, we likely won't see the development community at large using Haskell, ML or Erlang any time soon. What we'll probably see first is a move towards hybrid or multi-paradigm languages. Clojure and Scala are two of the most familiar at this point. Both target the Java platform, which makes them appealing to existing Java users.

Somewhat surprisingly, Microsoft may very well be the ones who bring functional programming to the mainstream, through their F# language that is to be included as part of Visual Studio 2010. Functional programming will quickly be made easily accessible to a large number of application developers, at a critical time when many will likely be looking for ways to better leverage systems with many logical processors.

Unfortunately, Sun seems content with spinning their wheels with Java and worse, JavaFX Script. Given Sun's long history providing back-end hardware and software, especially hardware that offers many threads of execution, it's sort of surprising that they aren't giving more support to languages like Clojure and Scala. These are the sort of languages that give current JVM users the boost they need to remain or even become competitive.

We're starting to see a variety of factors come together now that will make functional programming techniques far more useful to the mainstream software developer. Multicore CPUs are now readily available, including in low-end consumer-grade desktops and laptops. This will start increasing the demand for efficient, scalable and practical methods of making use of these resources. A variety of open source functional languages, like Haskell, Erlang, Scala and Clojure, have shown that they're willing to help meet these demands. Microsoft is going with F#. The need to use functional techniques combined with readily-available language implementations will allow for this flourishing to occur.

Today I perused an article suggesting that Microsoft is a "dying giant". While that article is correct to point out that we are seeing things change for Microsoft, I don't think the article's interpretation was correct. They're adapting to changing circumstances, and are doing a better job than many of their competitors.

Yes, they have or will be making some significant layoffs. That's often necessary during a time of change. Efficiency and productivity has become a necessity, and those who don't offer one or both must go.

But unlike many of their competitors, especially Sun, Microsoft has potential. They're going in the right direction where it matters. One such example is F#. With virtually every PC sold these days having CPUs with two or more cores, software will need to start making better use of such resources. One of the most effective ways of doing this is through the techniques of functional programming. With the release of Visual Studio 2010, which will include support for F#, Microsoft will bring functional programming to the masses.

Sun has failed miserably in this respect. Considering the hardware they offer, they should have been at the forefront of delivering what it takes to write effective software that runs on systems with 32 or more processing units. After all, that is what we'll see in typical desktops in a few years, if not sooner.

Java has stagnated, and in many ways is becoming irrelevant in the coming software development world. While Java did help bring multithreaded programming to a wider audience, its techniques are no longer suitable. We, as developers, need functional programming. So Sun should probably have put much more emphasis on programming languages that target the JVM like Scala and Clojure, rather than Java. They do offer the functional programming capabilities that we're really beginning to need these days, and that we'll find crucial in the very near future.

Although I have used Sun's hardware and software for years, and have very much enjoyed using them, I see Microsoft as bringing more innovation and practicality to developers than Sun is these days. So although Microsoft is falling on some troubling times these days, as most companies and individuals are, they have a better future ahead of them. They're adapting during these crucial times, and will be much better prepared to face the computers we will be using shortly.