Here’s a great interview with Microsoft Technical Fellow and author of the CLR garbage collector, Patrick Dussud.
How does GC, work, generally? Why is it important? The GC inside of the CLR is of a specfic type – ephemeral, concurrent (the server version has always been concuurent and now with Background GC on the client in CLR 4, GC is concurrent on the client as well, but there are differences…)
The SDTimes has an article up about a new operating system Microsoft is working on called “Midori”. It is based on their “Singularity” OS, with everything being written in managed code then natively compiled. Rumor has it that this is the follow-on to the Windows platform… we’ll see if it ever materializes commercially. SDTimes bases the article on some internal documents they got access to, which may be why we haven’t seen this level of detail before (see the entry in Wikipedia). From the article:
According to the documentation, Midori will be built with an asynchronous-only architecture that is built for task concurrency and parallel use of local and distributed resources, with a distributed component-based and data-driven application model, and dynamic management of power and other resources.
The Midori documents foresee applications running across a multitude of topologies, ranging from client-server and multi-tier deployments to peer-to-peer at the edge, and in the cloud data center. Those topologies form a heterogeneous mesh where capabilities can exist at separate places.
In order to efficiently distribute applications across nodes, Midori will introduce a higher-level application model that abstracts the details of physical machines and processors. The model will be consistent for both the distributed and local concurrency layers, and it is internally known as Asynchronous Promise Architecture.
…operating system services, such as storage, would either be provided to the applications by the OS or be discovered across a trusted distributed environment.
High Scalability has a great link to a video TechTalk with Cuong Do, YouTube’s engineering manager. He talks about the challenges YouTube faces (past and present) to meet it’s skyrocketing user demand, as well as the infrastructure that allows them to scale. I enjoyed the anecdotes: especially the frantic email sent at 2am alerting the dev team that they only had 3 days of storage left… I always thought Google/YouTube would be immune to emergencies like that… ignorance on my part
I found this information interesting:
- The application code is written mostly in Python (the web app is not the bottleneck… the database RPC is)
- They use Apache for page content and lighttpd for serving video
- Thumbnails are now served by Google’s BigTable
- They’re running SuSE Linux with MySQL
- HW RAID-10 across multiple disks was too slow. HW RAID-1 with SW RAID-0 was faster because the Linux I/O scheduler could see the multiple volumes and would therefore schedule more I/O
You can read a good summary of the talk HERE from the High Scalability website.
CIO has a good interview with Rob Reeg, president of Mastercard’s Global Technology and Operations. He discusses their infrastructure and processing architecture. Definitely worth looking at if you’re interested in how credit card transactions are processed.
Interviewer: How big of an infrastructure do you have to support and maintain? It must be huge.
Reeg: Actually from a pure server footprint standpoint… we probably have fewer actual footprint servers because of techniques like virtualization that help us leverage one box to do multiple things.
Where it gets interesting is philosophically: We try to put [transaction] processing as close to our customers, the banks, as possible. When we talk about the global network, we have small servers that sit with the bank customers that connect to our network. What it does is it gives us intelligence there at the end of the network. So as a transaction comes through, we can take a look at that transaction and decide how do we best process that transaction for the benefit of all those four parties in the model.
As to processing, the majority of transactions we’re looking at relate to how do we process them as fast as possible in the most accurate way. The way to do that is by peer to peer: If you’re using your card in Europe, in London, say, and you swipe your card as you check out of hotel, we can route that transaction to the hotel’s acquiring bank in London directly to your issuing bank and get that message back for approval without ever going through St. Louis or some big data center in the middle of all that.
You can read the full article HERE.
Systems Management News has up an interview with Ron Gorodetzky, enterprise architect for Digg. It’s an interesting look at the challenges Digg faced scaling to meet it success (over 26 million unique visitors a month). They’re using a LAMP stack (Linux, Apache, MySQL, PHP), with MogileFS as their backend distributed file system. To help manage their infrastructure, Digg uses Puppet.
Ron highlights a commom problem all architects face when they try to scale their software: the database.
“The first pain point we hit was just database stuff. The first thing you’ll notice is when you start to grow these queries, the database can’t commit as much time to committing a certain query as it used to,” said Gorodetzky. “You’ll find the normal things that work, suddenly don’t. You’ll find that, one day, you’ll see a spike in your graphs telling you that something’s going slower. Once you do that, you get to the point where the database part is as fast as it can be, you cache things.
You can read the full article HERE.
InfoQ has a great article up from Randy Shoup, a senior architect at eBay. He discusses the philosophies and practices employed by eBay to ensure their software scales to the demands of the site. I like articles like this because the techniques used by large systems (eBay, Google, Amazon, etc) tend to also apply to smaller systems. These larger systems help flush out the problems that a smaller system may not run into until it is too late.
From the article:
At eBay, one of the primary architectural forces we contend with every day is scalability. It colors and drives every architectural and design decision we make. With hundreds of millions of users worldwide, over two billion page views a day, and petabytes of data in our systems, this is not a choice – it is a necessity.
Click HERE to watch the video presentation and corresponding slides.