smithj stated that my appliance update proposal rests on the assumption that configuration data can be easily separated from the operating system. This is true and I believe it is doable.
First, let me define what I mean by configuration. We do not have to treat all files in /etc as configuration data. For example, if my appliance ships with samba functionality, but it does not allow configuration of samba by the end user, then for all intents and purposes, from my appliance´s perspective, /etc/samba/smb.conf is not a configuration file. Configuration data corresponds only to settings that the ISV allows the end user to change. (This should be a very limited set by the way. If I had a hundred dials on my microwave oven, I´d never figure out how to use it. The same goes for TiVO--the limited number of user-configurable options works.)
The only configuration that an end user should be performing on an appliance is through the appliance web interface. Since the ISV has full control over all configuration data, it can choose to put it all in a database on a separate partition, which achieves the separation of configuration from the operating system.
smithj´s example of the end user needing to write a cron script is not realistic because most appliance users should not need to know what cron is. However, suppose that the ISV implemented scheduling capability based on cron and needed to configure cron dynamically. Then the ISV-provided program will need to store this configuration in its database for easy queryability, and then write a file out to /etc/cron.d/. These are things the program should do regardless. The only extra step that needs to be taken in the Amazon EC2 world is to redo the write out to /etc/cron.d/ on every reboot, which isn´t very hard. (Note that Amazon EC2´s root file system is not read-only, but you can think of it as a read-only operating system partition with a read-write tmpfs partition layered on top with UnionFS.)
In this world where the ISV manages all configurable data, why not maintain it in a separate location from the operating system and make upgrades as easy as swapping the OS image?
Two additional points to smithj:
- merges are nice in theory but bad in practice because in the event of a merge failure neither the end user nor the ISV has a tool to rectify it.
- you are not the target audience of an ISV. ;)
Montag, 19. Mai 2008
Microformats
Microformats are an easy way to integrate semantic meaning into web pages. It´s already being adopted by popular websites. Firefox has an add-on called Operator that can parse it automatically.
For example, here is the Digg profile page for jon1012.
Operator parsed the embedded hCard automatically and gave me the opportunity to export his contact information as a vCard.
The snippet of HTML looks like
Here´s an example with Google Maps.
and wikipedia
For example, here is the Digg profile page for jon1012.
Operator parsed the embedded hCard automatically and gave me the opportunity to export his contact information as a vCard.
The snippet of HTML looks like
<div class="vcard">
<div class="vcard-side">
<img class="photo" src="/users/jon1012/h.png"
alt="jon1012" width="120" height="120" alt="" />
</div>
<h2><span class="fn">jon1012</span></h2>
<div class="profile-location">A person from
<span class="adr"><span class="locality">Paris, France</span></span>
who joined Digg on December 7th, 2005
</div>
</div>
Here´s an example with Google Maps.
and wikipedia
Sonntag, 18. Mai 2008
Using Windows CardSpace
Windows CardSpace is a feature of the .NET framework that manages information cards.
One use-case is to associate a card with an online account so you can use this to log onto the site in the future.
When the website requests a card, CardSpace will first display information about the site.
On the first time through, you have no cards. You may create a personal card.
When done, send it to the relying party.
Unlike the personal card created above, Managed cards are issued by a separate identity provider. In that case, import the card.
When a relying party requests a managed card, your computer will in turn request validation from the identity provider. A resulting token with the blessing of the identity provider is sent to the relying party. This is a mechanism by which authentication and authorization can be off-loaded to a third-party.
Samstag, 17. Mai 2008
Amazon EC2 makes traditional updates obsolete for appliances
Linux distributions are obsessed with updates, and rightly so, given the frequent nature of security fixes that must be published. When Linux-based software appliances became popular in the last couple of years, the update paradigm was brought along for the ride. Package manager or system manager software runs on the appliance, and either automatically or at the user´s request updates the entire appliance to a version published by an ISV.
Package managers are big and complex beasts with not a small chance of failing in the middle of an update. Though unlikely, there is also a non-zero chance of such kind of failure being disasterous, rendering the appliance unbootable. Instead of dealing with the downtime and uncertainty associated with updates, the unique nature of the appliance model combined with the power of cloud computing offered by Amazon EC2 renders traditional updates via package managers obsolete.
Before delving into the future of appliance updates, consider how a typical home appliance such as a router or the TiV does updates. These hardware appliances contain special flash ROM that holds firmware. User configuration data is stored in a different location. When a manufacturer releases a firmware update, users download the entire firmware and replace it in one piece. This update mechanism is dead simple and fairly failsafe.
Applying this paradigm to the virtual appliance world, the firmware is the operating system. When deployed on Amazon EC2, the ISV may simply publish all of their appliance versions as templates. Their users associate their own data partition with the common operating system template such that the operating system (firmware) is read-only and all user-specific data is placed in the data partition. When the time comes to update it, the user may simply associate a newer operating system template with the same data partition. If a database schema needs to be migrated to work with the newer OS version, take a backup snapshot of the data partition and run an ISV-supplied migration script first. That was easy, wasn´t it?
R.I.P. traditional package managers. Virtualization ushers in a new way of updating appliances that offers shorter downtime and is less error-prone.
Package managers are big and complex beasts with not a small chance of failing in the middle of an update. Though unlikely, there is also a non-zero chance of such kind of failure being disasterous, rendering the appliance unbootable. Instead of dealing with the downtime and uncertainty associated with updates, the unique nature of the appliance model combined with the power of cloud computing offered by Amazon EC2 renders traditional updates via package managers obsolete.
Before delving into the future of appliance updates, consider how a typical home appliance such as a router or the TiV does updates. These hardware appliances contain special flash ROM that holds firmware. User configuration data is stored in a different location. When a manufacturer releases a firmware update, users download the entire firmware and replace it in one piece. This update mechanism is dead simple and fairly failsafe.
Applying this paradigm to the virtual appliance world, the firmware is the operating system. When deployed on Amazon EC2, the ISV may simply publish all of their appliance versions as templates. Their users associate their own data partition with the common operating system template such that the operating system (firmware) is read-only and all user-specific data is placed in the data partition. When the time comes to update it, the user may simply associate a newer operating system template with the same data partition. If a database schema needs to be migrated to work with the newer OS version, take a backup snapshot of the data partition and run an ISV-supplied migration script first. That was easy, wasn´t it?
R.I.P. traditional package managers. Virtualization ushers in a new way of updating appliances that offers shorter downtime and is less error-prone.
Ubuntu Live from HD
I followed the instruction at https://help.ubuntu.com/community/Installation/FromLinux to install from hard drive using the contents of a LiveCD image. Everything worked flawlessly.
Freitag, 16. Mai 2008
The future of desktop virtualization?
The newest VMware Workstation beta (6.5) contains a nice new feature called Unity.
It allows graphical applications from the host and the guest systems to run more seamlessly side-by-side.
To use it, make sure it is enabled in the virtual machine settings.
Then enable it in the view menu.
Here is a screenshot of it running.
With this technology, multiple desktops no longer need to be tolerated simply to run applications belonging to different operating systems.
It allows graphical applications from the host and the guest systems to run more seamlessly side-by-side.
To use it, make sure it is enabled in the virtual machine settings.
Then enable it in the view menu.
Here is a screenshot of it running.
With this technology, multiple desktops no longer need to be tolerated simply to run applications belonging to different operating systems.
Cloud computing: EC2 and App Engine
The cloud computing will be big; there are no doubts about that. Why deploy your own distributed and scalable infrastructure when someone else can do it for you for minimal cost? Cloud computing based on virtualization means that people can potentially have full control over the deployed machines without worrying about physical hardware maintenance.
There are currently two paradigms surrounding how to provide cloud computing capabilities, one championed by Amazon´s Electric Computing Cloud (EC2) and the other by Google´s still-in-beta App Engine.
EC2 was created around the concept of virtual appliances. Independent Software Vendors (ISVs) create XEN-based appliances that can be deployed to EC2. Virtual machines can be started and stopped on-demand, making this the first commercial service that offers computing resources as a utility where users pay for exactly what they use. EC2 is powerful--virtually any Linux-based application can be ported to this platform.
The appliance model is picking up a lot of steam. Almost all the major Linux vendors are already onboard. Red Hat has its upcoming Appliance Operating System; Novell has its own SUSE Appliance Program; Ubuntu has a special Server Edition JeOS; and not to forget little rPath, which has been pioneering the appliance model since 2006. All of these products will or already do produce virtual appliances to run on EC2. A lot of new applications will be deployed on EC2. We are only seeing the very beginning of this massive trend.
Google´s App Engine´s model works on a level above that of appliances. Instead of offering users the flexibility of running virtually anything they want through creation of custom appliances, App Engine gives users a fixed environment, where they can run Python applications. For convenience of creating web-based applications, the Django web application framework is also provided. The documentation also notes that other ¨programming languages and runtime environment configurations are being considered for future releases.¨
App Engine are making a bet here that most future applications will have fairly homogenous runtime requirements. Gone are the days where most applications need to care about the exact kernel version they run on top of and the precise version of the system libraries. One fixed set of these will do for the vast majority of new applications. The use of scripting languages (Python, Ruby) and ones with intermediate runtimes (Java, C#) are on the rise. Different versions of these interpreters and runtimes can also be installed side-by-side.
Taking this idea a bit further, imagine App Engine as a giant repository of software indexed by vendor name. Python versions could be placed in /app/python, and C# in /app/csharp. These directories would be further subdivided into /app/python/prod/2.5/ and /app/python/dev/4.0/ etc. I sign up as a vendor too and place all my software in /app/xiaowen/. I can customize my the runtime environment for my applications to use a certain version of python by pointing at the path exported by the Python development team in /app/python. The power of this architecture comes from the fact that everybody can share their applications for everybody else to use. No more deployment worries here because there is nothing to deploy. Simply point at a provider´s directory and go (though of course, some local configuration may still need to be done). Imagine one giant computer containing a mesh of interdependent software that the entire world collaborates on!
There are currently two paradigms surrounding how to provide cloud computing capabilities, one championed by Amazon´s Electric Computing Cloud (EC2) and the other by Google´s still-in-beta App Engine.
EC2 was created around the concept of virtual appliances. Independent Software Vendors (ISVs) create XEN-based appliances that can be deployed to EC2. Virtual machines can be started and stopped on-demand, making this the first commercial service that offers computing resources as a utility where users pay for exactly what they use. EC2 is powerful--virtually any Linux-based application can be ported to this platform.
The appliance model is picking up a lot of steam. Almost all the major Linux vendors are already onboard. Red Hat has its upcoming Appliance Operating System; Novell has its own SUSE Appliance Program; Ubuntu has a special Server Edition JeOS; and not to forget little rPath, which has been pioneering the appliance model since 2006. All of these products will or already do produce virtual appliances to run on EC2. A lot of new applications will be deployed on EC2. We are only seeing the very beginning of this massive trend.
Google´s App Engine´s model works on a level above that of appliances. Instead of offering users the flexibility of running virtually anything they want through creation of custom appliances, App Engine gives users a fixed environment, where they can run Python applications. For convenience of creating web-based applications, the Django web application framework is also provided. The documentation also notes that other ¨programming languages and runtime environment configurations are being considered for future releases.¨
App Engine are making a bet here that most future applications will have fairly homogenous runtime requirements. Gone are the days where most applications need to care about the exact kernel version they run on top of and the precise version of the system libraries. One fixed set of these will do for the vast majority of new applications. The use of scripting languages (Python, Ruby) and ones with intermediate runtimes (Java, C#) are on the rise. Different versions of these interpreters and runtimes can also be installed side-by-side.
Taking this idea a bit further, imagine App Engine as a giant repository of software indexed by vendor name. Python versions could be placed in /app/python, and C# in /app/csharp. These directories would be further subdivided into /app/python/prod/2.5/ and /app/python/dev/4.0/ etc. I sign up as a vendor too and place all my software in /app/xiaowen/. I can customize my the runtime environment for my applications to use a certain version of python by pointing at the path exported by the Python development team in /app/python. The power of this architecture comes from the fact that everybody can share their applications for everybody else to use. No more deployment worries here because there is nothing to deploy. Simply point at a provider´s directory and go (though of course, some local configuration may still need to be done). Imagine one giant computer containing a mesh of interdependent software that the entire world collaborates on!
Abonnieren
Posts (Atom)
