Digital Walkabout

Evolution of the Google File System

http://queue.acm.org/detail.cfm?id=1594206

"During the early stages of development at Google, the initial thinking did not include plans for building a new file system. While work was still being done on one of the earliest versions of the company's crawl and indexing system, however, it became quite clear to the core engineers that they really had no other choice, and GFS (Google File System) was born.

First, given that Google's goal was to build a vast storage network out of inexpensive commodity hardware, it had to be assumed that component failures would be the norm—meaning that constant monitoring, error detection, fault tolerance, and automatic recovery would have to be an integral part of the file system. Also, even by Google's earliest estimates, the system's throughput requirements were going to be daunting by anybody's standards—featuring multi-gigabyte files and data sets containing terabytes of information and millions of objects. Clearly, this meant traditional assumptions about I/O operations and block sizes would have to be revisited. There was also the matter of scalability. This was a file system that would surely need to scale like no other. Of course, back in those earliest days, no one could have possibly imagined just how much scalability would be required. They would learn about that soon enough.

Still, nearly a decade later, most of Google's mind-boggling store of data and its ever-growing array of applications continue to rely upon GFS. Many adjustments have been made to the file system along the way, and—together with a fair number of accommodations implemented within the applications that use GFS—they have made the journey possible.

To explore the reasoning behind a few of the more crucial initial design decisions as well as some of the incremental adaptations that have been made since then, ACM asked Sean Quinlan to pull back the covers on the changing file-system requirements and the evolving thinking at Google. Since Quinlan served as the GFS tech leader for a couple of years and continues now as a principal engineer at Google, he's in a good position to offer that perspective. As a grounding point beyond the Googleplex, ACM asked Kirk McKusick to lead the discussion. He is best known for his work on BSD (Berkeley Software Distribution) Unix, including the original design of the Berkeley FFS (Fast File System). "

The Amazon Virtual Private Cloud

Description from the official blog post,

Amazon Virtual Private Cloud (Amazon VPC) lets you create your own logically isolated set of Amazon EC2 instances and connect it to your existing network using an IPsec VPN connection. This new offering lets you take advantage of the low cost and flexibility of AWS while leveraging the investment you have already made in your IT infrastructure.

A few excerpted comments from Werner’s blog,

These CIOs know that what is sometimes dubbed "private cloud" does not meet their goal as it does not give them the benefits of the cloud: true elasticity and capex elimination.

..

To achieve true cloud-like elasticity in a private cloud, such that you can rapidly scale up and down in your own datacenter, will require you to allocate significant hardware capacity. While to your internal customers it may appear that they have increased efficiency, at the company level you still own all the capital expense of the IT infrastructure. Without the diversity and heterogeneity of the large number of AWS cloud customers to drive a high utilization level, it can never be a cost-effective solution.

..

Introducing Amazon Virtual Private Cloud

We have developed Amazon Virtual Private Cloud (Amazon VPC) to allow our customers to seamlessly extend their IT infrastructure into the cloud while maintaining the levels of isolation required for their enterprise management tools to do their work.

A graphic from the official blog post,

 

Intelligent energy algorithm could save data centres significantly on power consumption

"A collaboration between researchers at MIT, Carnegie Mellon Universitiy, and Akamai, is looking at a different kind of efficiency though. Rather than lowering the energy use of a data center they are instead looking at how to direct traffic to different data centers based on how cheap the electricity is to use at different times of day in different parts of the world."

More at http://www.technologyreview.com/business/23248/page1/  http://www.geek.com/articles/news/intelligent-energy-algorithm-could-save-data-centers-millions-20090819/

South by SouthWest’s Panel Panel Picker for 2010 was released recently and there are some great panels this year. Here are some to take a look at and hopefully take a moment to vote on. This year’s panel picker voting process is much easier consisting of a simple ‘yes’ (thumbs up) or ‘no’ (thumbs down) so voting should literally take a few seconds. 

I've submitted two panels which I am organising this year to SxSWi: 

Seeing Through the Clouds: CC Scenarios, Models, Architectures and More

Type: Panel

Description: This session provides an in-depth look at Cloud Computing (CC), its scenarios, models and architectures; platforms, technologies and tools; and convergence with fellow technologies as Virtualization. The focus is a practical one providing IT professionals of all levels with the guidance and tools to enable them to take informed business and technology decisions on how they can leverage CC to their advantage, today.

The Future of Cloud Computing
Type: Panel
Description: This panel will discuss the Future Direction of Cloud Computing

• Industry Trends in the evolution of the data-center – from Virtualization 2.0 to Cloud 
• The impact of Virtualization technologies and Cloud Computing technologies 
• The role of Clients in Cloud Computing 
• The impact of Data Center instrumentation in the Enterprise Cloud

Don't forget to vote! 

World's First Formally-Proven OS Kernel

http://tech.slashdot.org/story/09/08/13/0827231/Worlds-First-Formally-Proven-OS-Kernel

 

"Operating systems usually have bugs — the 'blue screen of death,' the Amiga Hand, and so forth are known by almost everyone. NICTA's team of researchers has managed to prove that a particular OS kernel is guaranteed to meet its specification. It is fully, formally verified, and as such it exceeds the Common Criteria's highest level of assurance. The researchers used an executable specification written in Haskell, C code that mapped to Haskell, and the Isabelle theorem prover to generate a machine-checked proof that the C code in the kernel matches the executable and the formal specification of the system." Does it run Linux? "We're pleased to say that it does. Presently, we have a para-virtualized version of Linux running on top of the (unverified) x86 port of seL4. There are plans to port Linux to the verified ARM version of seL4 as well." Further technical details are available from NICTA's website.

SpringSource is now a VMware company - a key acquisition

VMware's acquisition of SpringSource is a significant move, and not only for VMware's continued focus on a platform play - with SpringSource, VMware can emphasise enterprise software stacks, software development, scalable environments in the DC, and virtualisation for enabling adaptive and dynamic DC operations and management. 

SpringSource's Spring framework has become the de facto standard programming model for modern enterprise Java, rich web, and enterprise integration applications. Over the last couple of years, SpringSource has expanded their purview across an even broader range of offerings, employing the thought leaders within the Apache Tomcat, Apache HTTP Server, Hyperic, and Grails open source communities.

Whilst VMware has until now treated the applications and operating systems running within VMs as black boxes, the vendor has seen a greater demand to bring the application and infrastructure layers together, to address such issues as speed of deployment, application performance guarantees, and providing resiliency in the face of component outages. VMware has announced plans to achieve this through interfaces into vSphere that SpringSource offerings (and other application frameworks) can leverage, as well as extending their management and automation capabilities to be aware of these interactions. Examples include  indicating at deployment time how application code will interact and communicate with other hardware and software components, and having the virtualised infrastructure auto-provision the database and application server VMs required by the application, wire the VMs’ network connections together, and program  vShield Zones to open up only certain network ports between them.  At runtime  service bottlenecks can be determined, then addressed by altering configurations, cloning web server VM instances, interacting with DC load balancing.  

VMware has been squeezed by competition from open source and free, bundled virtualisation software offerings, particularly Xen and RedHat, and SpringSource can help the vendor compete directly in this space. Likewise it will blunt the edge of Sun's acquisition by Oracle. J2EE has only continued to grow through its abstraction by frameworks such as Spring and Flex. Those with any serious involvement in Java-based software development in the last 5-6 years have incorporated Spring into their environments. Acquiring Spring vis-a-vis Oracle/Sun is but another stark reminder that VMware is a serious player in the platform space, and a stick in the eye of those remaining, desperate few who still believe they can flog antiquated, non-scalable Web 1.0 architectures based on JSF and EJB. With the VMware acquisition of SpringSource, it is more than painfully obvious that there is no justifiable reason to pursue these Sun-sponsored models and architectures, which ran their course years ago. 

Meanwhile, whilst SpringSource has steadily focused on developers, they have moved their tools deeper into enterprise software stacks, evidenced by the Hyperic acquisition to provide open source monitoring and issue resolution.  With VMware's strength in virtualisation, SpringSource's strength in development tools, application servers, and now monitoring tools, VMware gets closer to the kind of end-to-end enterprise software stack solutions that Oracle. Sun and others have only dreamt of realising.  

Too much fluff

Given the "novelty" of cloud - principally as a concept rather than with any technology - I have found a strong need to level set whenever doing anything of consequence with it. Whilst this often is received gratefully, there are many times when level set is written off as "too much fluff" and unnecessary. Where concepts, models, architectures and technologies are well understood, level set is not as important or necessary. Yet with the nebulousness of the cloud - made apparent when it takes a year for the industry to agree to the otherwise self-evident definitions of SaaS, PaaS and IaaS - level set is critical to starting any endeavour, investigation, reporting of results, or other activity. A high degree of FUD still permeates cloud, and not clearing it away through a level set only leads to poor decisions. 

It is a common phenomenon in engineering to focus on detail to the exception of all else. This is a factor of decomposition, yet when details command most or all of the attention for solving a problem, the overall direction is lost. Sun Tzu's statement, "Strategy without tactics is the slowest route to victory; tactics without strategy is the noise before defeat" is just as applicable to engineering as to war. Without an understanding of the problem to be solved and the strategy to solve it, the details are only noise. One must understand both well to be an effective technical leader; one must understand what is the strategy and overall directon to be an effective engineer. 

Still have doubts? Let me tell you a story: A vendor of desktop software solutions not too long ago began to explore cloud as a high-level strategy to lower TCO for both themselves and their customers, largely as a reaction to pressure from Google. The vendor understood the benefits of developing cloud services for their product, but lacked a coherent understanding and strategy for making the transition. There was no level set, and as a result, all thinking delved directly into details - what technologies to use/build, what features were needed, how and where to deploy. The result was an exclusive focus on technology and loss of sight of the problem to be solved. The technology decision was made first, and all subsequent decisions had to fit that technology set. Time and resources were badly wasted trying make something that few users wanted to needed work with the chosen technology; the vendor ended up reinventing in poor form an number of technologies outside their core competencies; the pilot projects failed and were scrapped; and the vendor was set back by several years in their efforts to compete. At very least, the detritus was salvaged toward another, far more limited project which, with the expensive lessons of excessive detail and technology focus, has been able to enjoy a measure (albeit muted) degree of success. All this from "setting the cart before the horse."

The first lesson of the story is the danger of taking technology decisions outside any framework of the problem to be solved and a strategy to address it. When the vendor committed themselves to a particular technology choice outside of any problem/solution context, they limited every decision and direction they could subsequently take, and turned their focus to square pegging everything to that technology. If a particular feature set was not available for that technology, they built it themselves, rather than stray outside the technology base. This was justified with the argument that it would simply be "prohibitive" for their engineers to learn anything new and to not maximise existing experience, which is not unheard of in IT. Failure was guaranteed from the beginning. 

The second lesson is the danger of not level setting so as to ease the understanding of the problem to be solved and how to approach it. Nearly no one in the vendor's technical staff could agree on direction, measures of success, or even what was cloud. Technology focus was offered as comfort food, empty calories to provide a sense of direction where there was none. Since no one could agree on anything other than the technology being used and the issues inherent with that technology, it demanded all attention, and the elephant in the room was never acknowledged. 

It is far more dangerous to not level set than it is to face the slings and arrows of "too much fluff" from those who only want to hear about the details. My advice: Don't get caught up in the "too much fluff" argument. Level set first; permeate understanding of the problem to be solved, the strategy and direction which provide the framework within which to delve into the details. Without this, one is just showing off how well they understand technical details, and not seeking to solve any real, practical or even academic problems. If someone is saying there's "too much fluff" in your strategy, model or architecture proposal (that covers a new or nebulous concept like CC), more often than not, it is really a compliment - it means you're doing enough level setting. IMHO, for topics such as CC where there are few standards and little to no shared consensus, you really cannot do too much level setting. You need to "set the cart behind the horse, not before."

Additionally, with CC, the level of confusion and misinformation is to an extent where level setting is critical. One may think they "get it", but until CC is well defined and at least started on the path to standardisation, it is important to go over the basics so that everyone understands the context. Saying "I get it, let's just dive into the details" misses the chance to prevent major misunderstandings and context switches later on. When people claiming to be architects making statements as, "Cloud? SaaS? That's easy - all I need is J2EE - I can just make my EJBs into services" (which, to the uninitiated, makes as much sense as, "I can see Russia from my house"), it is obvious there is much to cut through to really know what one is talking about with CC. 

So, when talking CC, "too much fluff" feedback likely means you are providing just enough level setting. That's not to say that the same feedback for a well-defined, well-standardised topic should not be taken literally. ;)

Asankya's RAPIDnet, a Cloud Acceleration Network

Asankya has built RAPIDnet, a Cloud Acceleration Network (CAN), consisting of strategically located network nodes on several major Internet backbone providers, enabling applications to work around congestion and bottlenecks in the Internet. 

"As companies continue to move to richer, more collaborative applications for an increasingly geographically dispersed workforce, a major issue of using the Internet to deliver these applications is whether the bandwidth required for these real-time business processes can be handled without too heavy a strain on a shared, public connection," said Asankya Chairman of the Board, Patrick Harr. "By building a Cloud Acceleration Network that provides consistent, reliable, high-speed performance for Internet applications, Asankya has effectively removed the barriers of adoption for the cloud. Our RAPID algorithms are uniquely able to provide high performance while working with encrypted traffic and maintaining application independence, ensuring bandwidth is no longer an obstacle for cloud-based applications."

More details at http://news.prnewswire.com/DisplayReleaseContent.aspx?ACCT=104&STORY=/www/story/07-28-2009/0005067521&EDATE=

Microsoft Azure pricing strategy and the Dynamic Data Center Toolkit

Note that network bandwidth is made part of Azure’s metering and bandwidth solution. 
“The Windows Azure Platform Pricing and Licensing Overview <http://www.microsoft.com/azure/pricing.mspx> states:
· Messages = $0.15/100K message operations , including Service Bus messages and Access Control tokens
· Bandwidth = $0.10 in / $0.15 out / GB”

“Messages (Includes Access Control, Orchestration, and Reliable Queuing for message): .NET Services allow developers to easily connect their cloud applications and databases with existing software assets and users. This connection between cloud and on-premises assets is facilitated by the exchange of messages. The consumption-based pricing model means that customers will pay only for the number of message operations that their applications use. The definition of a "message operation" includes Service Bus messages and Access Control tokens. Messages are charged to the customer in discrete blocks of 100,000 ("100k") for each monthly billing period...”

More at http://news.cnet.com/8301-19413_3-10288185-240.html

Details on the Dynamic Data Center Toolkit:

http://www.microsoft.com/hosting/dynamicdatacenter/Home.html