Chuck Hollis wrote a blog post earlier this week,titled "Once Upon a Time". I thought it was an excellent post, telling about the transition EMC made a decade ago starting when Joe Tucci replaced Mike Ruettgers. FWIW, I think the diversification that Tucci accomplished at EMC has made all the difference there - especially the acquisition of VMware. You might call it lucky (as I tend to do), but the fact was they were looking to diversify their business took them on a journey that has buoyed their company far beyond the capabilities that their storage products by themselves would have supported.
At the end, he asks the question if history was bound to repeat itself again - which appeared to be a nudge towards some of the other companies in the industry. I didn't think this was such an affront - Chuck has been known to tweak competitors from time to time, but for the last 6 months or so, he's restrained himself from doing so.
So I was surprised this morning when I saw some tweets that had me look at the post again. And sure enough there was a blow up there involving a cadre of Netapp people that over-reacted to Chuck's post.
One of the consequences of this over reaction was that a benign blog post about EMC history became a referendum on Netapp's Secure Multi-Tenancy (SMT). It wasn't what Chuck was driving at in his original post, but the comments from Netapp folks steered the discussion that direction.
Chuck's main argument is that SMT isn't very secure if your service provider can gain access to a tenant's data. I'd add to that and say, it's not very secure if your service provider can delete volumes and destroy data too. Inadvertent destruction of data by administrators is a larger threat than somebody pulling "an inside job".
But it doesn't just effect service provider scenarios. The issue of multi-tenancy also applies to private data center operations. There have been suggestions that the word "tenant" refer to the legal owner of the data, but the word "legal" is unnecessary and obscures the common understanding that a tenant is the application owner that uses a shared a resource, whether it is a physical server or storage array.
A good example of multi-tenancy within the confines of a private data center is a corporate database that is managed by a DBA that doesn't want anything else to impact their performance and stability. When that database is moved to a virtual environment, the DBA expects to have multi-tenant protection that ensures nothing changes except a decrease in operating costs. The same applies to any application owner who would like, but can't afford the luxuries of dedicated resources.
Role-based administration combined with resource virtualization makes multi-tenant environments safe from administrator errors. Limiting the scope of what an admin can see as well as what actions they can take eliminates the possibility of them making a simple mistake with major consequences. Using the DBA example, if the DBA alone controls their own storage resources, there is no opportunity for a co-worker to screw things up for them.
3PAR's Virtual Domain software (available since 2008) provides a role-based, restricted access system for managing storage resources. This certainly doesn't solve all the security problems for multi-tenant environments, but it's an excellent way to eliminate the most common concerns of application owners.
The technology can be extended to public cloud infrastructures as well if a service provider chooses to make it available. A customer can be given Virtual Domain private control of their storage resources - without the ability to see any other customers' resources - to manage and provision as they see fit. In the service provider model, 3PAR provides the technology to its service provider partners who provide Virtual Domain-based services to their customers. 3PAR Cloud Agile partners who offer these services today are:
I just read an article about how the concept of infrastructure blocks is playing out on the SearchDataCenter site. The article presents several perspectives, but it's a bit confused. The concept is referred to as three different terms (pods, blocks and cells) and the comparison between a making your own and buying one are not clearly juxtaposed. Regardless, its a thought provoking article.
But is does raise the point what should we call these things? I think a better generic word for them is iBlock, short for infrastructure block.
I've been speaking to customers about this sort of thing lately and a number of them have expressed the opinion that rolling out their own iBlock would be a lot cheaper, more flexible and more scalable than anything they could buy from a vendor. I'm a big believer in the power of integration, but it's possible to get too far ahead of the curve.
3PAR customers have already been implementing iBlocks for several years using the 3CV design discussed in this ESG Labs report. That's one
approach. The question is, if you were going to build an iBlock, how would you do it - and why?
I caught up with Mark Cravotta from Datapipe recently at a 3PAR event in Las Vegas. He's a high energy person who is having a lot of fun growing Datapipe's hosting and cloud computing services as well as helping to manage its expansion around the globe.
Datapipe is a 3PAR Cloud Agile partner and customer who uses our products throughout their line for primary multi-tenant storage, data snapshots, remote replication and all aspects of disaster recovery.
In addition to being customer-driven, Datapipe is also committed to being a leader in green utility computing by reducing the carbon footprint of it's data centers through power purchases from green power producer, Constellation NewEnergy.
EMC offers a 20% capacity guarantee, as opposed to 50% from 3PAR's Get Thin Guarantee program. (FWIW, other vendors have also made 50% guarantees) I guess EMC must be concerned they won't really be able to do it. Also, 3PAR's capacity guarantee applies to EMC customers, but EMC's program does not apply to 3PAR customers. What does that say?
(Video note: For readers unfamiliar with #storagebeers, it was an event that started in the UK, by the blogger Storagebod and it has become a meme in the online storage community.)
London-based Ultraspeed has succeeded in the managed hosting business 13 years by being smart, opportunistic and service-oriented. A lot has changed during that time, especially customer expectations for uptime and how much customers rely on their hosting providers to respond quickly when needed. Web sites that are lucky enough to "go viral" can be a disaster if the hosting company's infrastructure is unable to adjust rapidly enough to meet demand.
In March, Ultraspeed opened their second data center in Amsterdam implementing a modular infrastructure design including multi-tenant 3PAR storage, VMware, Extreme Networks switches and customized servers. The highlight of their Amsterdam site is the ability to offer bi-directional DR services between London and Amsterdam using 3PAR's Remote Copy software. Ultraspeed is a member of 3PAR's Cloud-Agile program.
In this interview, conducted in February 2010, Jordon Gross, CEO of Ultraspeed and Michael Shanks, CTO joined us for coffee near their offices and talked about their company's history, it's technology, the challenges they face and how they expect things to shape up in the years to come.
Here is a video demo prepared by Maneesh Jain, one of 3PAR's Solutions Architects, of 3PAR's Plug-in for VMware vCenter and 3PAR's VMware Site Recovery Manager. The Recovery Manager demo shows not only how to recover a VM, but also individual files within a VM. Enjoy!
OK, Monday's post lacked the punch that people have come to expect from me where EMC announcements are concerned. Thanks to my readers who were disappointed and told me so. This post is for you.
VPLEX (announced Monday with all the hype that EMC could muster) is the result of EMC trying to become something more than a storage company. They put a systems professional in charge of developing storage products and produced a science project that looks very attractive as a technology but relegates storage to a secondary role and questions EMC's commitment to solving storage problems. In fact, VPLEX probably creates more storage problems than it solves. More on that later.
The concept of teleportation for virtual machines resonates with childhood space fantasies. I remember summer afternoons from my childhood going out to a nearby field with my brother and his model rocket club. My brother built some stunningly cool looking model rockets, and the amazing thing was that they all went where he intended them to - up. Just as amazing was the fact that the engine always ejected the nose cone and parachutes to bring his creations back to earth gently. It was a riot running across that field trying to catch them in our bare hands as they descended. A few years later those rocket designs turned into a set of World Book Encyclopedias that he won at a big science fair in Michigan. I was prouder of him than any kid brother could be, even though I was just the rocket runner.
However, his rocket club also had a couple of less-talented rocketeers who also launched their contraptions with great fanfare and, quite often, spectacular disappointments. Engines became separated from the rockets holding them, shooting around at random on the ground - and then there was the memorable starship design that took a 90% turn after exiting the launch wire and proceeded to fly parallel to the ground at height of 4 to 5 feet, sending parents, siblings and friends scrambling for cover behind a shrub, pet or each other.
It's good to believe in some things and to be wary of others.
So what is VPLEX anyway?
For starters, VPLEX is a virtualization appliance - a bump-in-the-wire product. EMC says it will take the technology at some point in the future and build it into their arrays, but like a lot of things, its much easier to talk about it than to actually do it.
The irony of the situation is that it VPLEX fills a storage virtualization role that is similar to IBM's SVC - a product that EMC bloggers eagerly lampoon. EMC is downplaying the similarity to SVC and are spinning VPLEX as a teleportation device for your virtual machines. Of course, the image of teleportation they want you to think of comes from Star Trek, but sci-fi fans are familiar with the risks of teleportation too - just for fun, recall the problems Jeff Goldblum had with it in The Fly.
The point is, VPLEX is an appliance and therefore it is another thing to manage and pay for. In fact it is at least 4 more things to manage (two here and two there) and can be as much as 16 additional things to manage. Just in case that point was not clear, VPLEX is new stuff to manage in between your servers and your storage. Like the Wizard of Oz, EMC would like customers to "Pay no attention to those things in front of your storage, - they are virtual and therefore invisible." In fact, it's so invisible that EMC claims you can use it with any vendor's storage, which means there is minimal integration with storage functions. EMC is calling VPLEX Storage Federation, and yet it doesn't integrate with storage on any meaningful level. That's not federation, it's virtualization.
Suddenly, the virtualization of all your storage through an appliance is a trivial matter. But of course it adds considerable complexity to an environment that is already complex enough. To put a finer point on it, EMC customers are familiar with the down and dirty disappointing reality of working with Virtual Provisioning, SRDF and change management. They should expect to pay for additional professional services to figure out how to do these things with VPLEX inserted.
And then there is the matter of managing mixed workloads in virtual environments, something that is a problem for a lot of customers. EMC's technique of isolating workloads on certain disk and cache resources doesn't work for highly leveraged VMFS's where there are many VMs running concurrently. When the workloads are all mixed together, there is no way to isolate them. VPLEX appears to be an answer to that problem by allowing
customers to move VMs elsewhere - presumably where there are more
resources available. In reality, those VMs are going to be moved to
another environment with the same storage limitations as where they
came from. Do you really think putting a distributed write cache
between servers and storage is going to solve workload balancing
problems? If so, the fix will only be temporary before the same
problems are repeated. And that is the problem with VPLEX - it doesn't
solve anything by itself, it only allows a problem to be moved
elsewhere - presumably someplace where there is more headroom that is not being as heavily utilized.
Storage systems that were designed for utility computing and assuming there would be mixed workloads to deal with, such as 3PARs InServ storage systems, are much more effective at maintaining performance levels for virtual machines and allow customers to operate at much higher system and storage consolidation ratios.
EMC wants you to imagine all the things you might be able to do with VM teleportation. I'd say, imagine how much fun its going to be doing the capacity planning for a VPLEX installation. How much storage do you need in location A and location B to support two way VPLEX functionality for a collection of 80 VMs? As it is with most things, it depends on a number of variables including whether or not VPLEX is being used to facilitate disaster recovery. It would not surprise me if VPLEX ends up effectively capping storage utilization at 50% for customers that employ it. If the maximum utilization is 50%, what will your actual utilization levels be? Something far less than that.
Reducing consolidation ratios
In a nutshell, all systems that are fronted by VPLEX will have the same write cache data so that a read from those systems will be serviced from the write cache, if the data has been recently written. However, if a read request is made from a VM for data that is not in VPLEX's write cache, the data will be read from either a local or remote storage array. That's why there are distance limitations to VPLEX today - the time it takes to cross-ship data from a remote location can't be too obnoxious.
It's also why EMC's Virtual Geek spent time talking about using applications that have a single writer - such as v-Motion. A VM with an application that attempts to write to the same block from two different locations is apparently problematic. My guess is that applications with long sequential reads might not be so great either.
That implies a couple things: You should expect to find out there are limitations as to what applications can be running with VPLEX. Maybe identifying VPLEX friendly applications will be easy, but perhaps this task will be harder than assumed. If so, the best answer may be to engage EMC's pricey professional services organization. The details, the details.
The other implication is that VPLEX will limit the number of VMs that can be running on a single vSphere server. After all, you wouldn't want to have any congestion problems forwarding write cache data through the VPLEX network. The higher your server consolidation ratio is, the more likely it is that you could run into bottlenecks of varying types. Expect to see best practices for VPLEX that scale back your server consolidation ratios.
Just because you can do something, doesn't mean it's a smart thing to do.
What would my friends at EMC do without my parody of their announcement?
On the day a product is announced its pretty hard to make a serious analysis - that usually takes more time, but in the case of EMC, there are usually a couple things you can bank on.
New levels of complexity to manage
Eye popping professional services costs
The second is an obvious consequence of the first.
Otherwise, I think Storage Federation is a very big deal for our industry and it's great that EMC is bringing attention to it. People interested in reading more about this might want to check out Stuiesav's blog: and the article in The Register.
Our belief at 3PAR is that Storage Federation only makes sense if your storage is already autonomic (self-managing) and efficient. Otherwise, the costs will continue to exceed expectations. It's one thing to introduce technology for technology's sake - it's something else completely to put technology together in a way that reduces complexity. The proof will be in the professional services bills that customers will pay to install and maintain VPLEX environments.
One of the things that came up during the call was a discussion of Storage Federation. Here is what our CEO David Scott said were the three main points to understand about it:
It’s different from virtualization. It allows separate peer, self-governing systems to act as a global whole (versus a hierarchical approach).
Automomic storage will be a critical enabler to federation as stuff gets moved around the virtualized network.
Storage federation is following a natural evolution from data center–>metro–>globally shared storage
Storage Federation is a new concept that has been getting a lot of attention from storage bloggers all of a sudden. People interested in following these discussions can start on Stuiesav's blog and follow the links in his posting.
A team of storage systems
A good analogy for Storage Federation is that storage systems work together in a team. Each member of the team has the ability to manage it's own resources and can make the information about its resources available to the team so that they can act together according to internal algorithms and policies.
Autonomic management is scoped from the individual storage system to the Storage Federation. The same types of algorithms and policies that relocate volumes within an individual array are used to relocate volumes within the Federation. For instance, the autonomic management technology used in 3PAR's volume and sub-volume relocation software, Dynamic Optimization and Adaptive Optimization, could be adapted for use in 3PAR's Storage Federation.
The graphic below illustrates the two levels of autonomic storage management. On the bottom, three storage systems manage their own resources and share resource information to the Federation where they can be accessed and managed by Federal algorithms and policies. If you click the graphic, you will see a slightly larger version that is easier to see.
Some of the thorniest storage ownership problems can be addressed by Storage Federation, including load balancing, firmware upgrades, system maintenance and data migrations.
A few weeks ago I posted an opinion here that Private Cloud was essentially a euphemism for making incremental improvements in corporate information infrastructures.
I go a little crazy sometimes over the definitions of terms we use in storage - mostly because they get spread so broadly and shot full of holes that ambiguity and confusion are guaranteed. That's why the public dialogue about Storage Federation, a term that could become the next meaningless buzzword, is so interesting to me. Many others have spent some time discussing this and if you are interested in it, follow the previous link to a Wikibon article or this link to an excellent post on Stuiesav's blog. But i digress.
"Cloud" has been widely thrashed as meaning anything to anyone, but it still has a thread of integrity based on the economic model of buying services, as opposed to products. There is something real about following the money trail that helps bring a cloud conversation back from the reduced oxygen zone to reality. My problem with Private Cloud is that it hasn't had the same economic reality check. Frustration be damned! and I've continued to look for a solution that will help me hear and speak the words Private Cloud without grimacing.
Recently I heard a definition of Private Cloud that really grabbed me because it has an economic rationality that is forceful and compelling.
A Private Cloud is the infrastructure that IT organizations create to compete with (Public) Cloud services.
I'm not crazy about the term Public Cloud either because it is redundant. The only reason to use public with cloud is to distinguish it from Private Cloud. But if Private Cloud is defined in the context of Public Cloud competition, there is not much use for the word Public. Nonetheless, I can live with that conundrum and be happy.
Can your team compete?
We are entering a new era where information processing can be accomplished internally, externally or both. The proliferation of competition for IT services is going to bring enormous changes to our industry. While we are used to thinking that competition is good, many IT organizations have been virtually protected from competitors for many years and the access that business unit managers now have to competitive services is going to be very hard on IT organizations that don't have the resources, talent and skills to keep up.
One thing is for certain, nobody will have much time to manage systems and storage anymore. Autonomic storage that effectively manages many of the things administrators do today is making a huge difference today for our customers.
We have all sizes of customers, some are very large corporations with many thousands of IT employees and the skills to implement almost anything they want to. These types of organizations are already well underway building large, flexible Private Cloud infrastructures. Some of our other customers are among the largest utility service providers in the world that have built their infrastructures on top of 3PAR storage. Other customers are much smaller, in both traditional IT and utility service provider environments.
One thing they have in common is spending the least amount of time (and money) possible managing storage. That helps them do whatever else needs to be done for their business. Does your storage do that for you?
A couple weeks ago, one of the major storage vendors had two major problems to resolve after one of their arrays suffered a firmware bug-induced failure at one of their cloud (email) service provider customers. They had to:
Help the customer get back to normal service levels after they had become unacceptable.
Confront a public relations problem after it was exposed by a leading storage publisher.
Meanwhile, their service provider customer had four major problems to resolve:
Get service levels back to acceptable levels.
Communicate to their customers what the problem was and how it was being addressed.
Re-engineer a solution to avoid the same happening again.
Credit customers for not delivering against SLA terms.
A vendor employee tried to address their public relations problem this way in his blog:
"OK, I'll take the blame for this -- sort of. We pride ourselves in putting a lot of thought into our customer designs. I'd argue that we're really, really good at it as well.
But not everyone is 100% sure of how their application will grow over time -- unfortunately, we're not psychics. And, let's be honest, not everyone necessarily wants to pay for redundancy we like to put into our designs.
We don't always get to directly engage all the time, either -- with products such as the (blanked out), most of this stuff moves through the channel. Somebody calls up one of our partners, says that they want to buy one of our products, and one gets sold -- and a lot of product gets sold that way."
I understand the desire to explain how messes become messy, but I'm not sure why he felt the need to speculate that his company's business partners or that their customer's budget were key elements of the problem. That is tantamount to saying, "All of our (blanked out) customers could have the same thing happen to them too." Anybody who has ever been close to one of these melt-downs knows there are many variables involved - including vendors underbidding each other and shaving elements from their bid in order to win the business.
From a distance, it looks like the vendor's response to the customer was good, although there apparently were some issues with failure notification from the array when the event occurred. I wouldn't call these sorts of things "Perfect Storms", but there are unfortunate scenarios where multiple things go awry. All vendors have these sorts of bad days, which serve as painful learning experiences. Unfortunately for customers, it's one of the ways vendors improve their customer support processes.
The customer also wrote in his blog, explaining the situation to their customers:
"Our SAN vendor analyzed the system logs for the event and determined that the service processor failure occurred due to a unique bug in the specific version of firmware on the system. Our vendor performed an emergency upgrade. The newer version of firmware includes a fix for the bug. We are taking additional corrective actions to make certain that there is enough spare capacity on the SAN. This will assure it performs without performance degradation in the event of a single hardware failure."
The reparation sounds reasonable, but it's not what I would call best of breed either. I'll explain why in the remainder of this post.
The old trusted dual controller just can't keep up
The explanation the service provider gave to their customers was only half correct. Yes, the failure in one controller was due to a firmware bug -and yes, all vendors find out about some of them at customer sites - but the inability of the surviving controller to handle the workload was another matter altogether.
The major defect of all dual controller designs for service provider applications is the uselessness of write cache when operating in degraded mode on a single controller.
When a dual controller array has a controller failure, all traffic is failed over to the surviving controller. However, this controller can't afford to place writes in cache because if this controller also fails any un-flushed writes in cache would be lost- making the recovery process all the more painful. As a result, the throughput of the controller degrades significantly because writes now take several orders of magnitude longer to process as each write must be completed at the physical disk level, instead of in fast cache memory. When you consider the sort of read/write ratios involved with an email application (heavy writes), it's not surprising to hear that it took 32 hours for the system to get caught up. I suspect that if the surviving controller had been able to use write cache, the customer might have experienced some amount of service level problems, but not nearly as bad as they suffered.
Write performance during array component failures is an important point that many customers give insufficient weight to when making their purchases. Public service providers certainly need to understand this. The exact same scenario - controller failure and subsequent drop in service levels - could certainly happen to a traditional data center customer, but the ramifications of this scenario are not as ugly as they are for a multi-tenant public service provider.
This case is a perfect example of how an older architecture is incapable of meeting the requirements of the new cloud service business model. If you are a cloud service provider reading this and wondering if you might have a similar exposure to a controller failure (including 3PAR customers with dual -controller arrays), my advice is to review what you have and start thinking about what you should expect if you have a controller failure and how you might want to deal with it on both a short-term and long-term basis. Best of breed cloud storage should not include dual controller arrays.
Their solution is to buy more and utilize it less
One of the identified corrective actions is having "enough spare capacity on the SAN", which in this case involves installing a second array. Without knowing the inside scoop, it looks like the idea is to split the workload across the two arrays so that if a controller failure occurs in either array, the performance drop won't be as noticeable. The array that doesn't suffer the failure will keep working as expected and the array that has the failure will only have half the load to deal with.
There are two primary problems with this "fix"
Performance will still suffer on the array with the controller failure
The I/O load will continue to increase over time
You are always going to have performance degradation of some sort when you can't use write caching, unless you are only reading data - which isn't the case here. It is flat out wrong to assume that a performance problem will not occur. Regardless, with the new two-array SAN, whichever system has the controller failure should be able to get caught up much faster than the 32 hours this customer had to wait. Of course, the customer's capacity and I/O load will almost certainly increase over time, and as that happens, the strategy of splitting the load between two arrays loses its effectiveness.
Along with adding the controllers, they are also certainly adding disk drives, and some notion of what "reasonable" utilization limits should be for them. The problem with limiting utilization as a best practice is that it puts the stamp of approval on inefficiency - not only for capacity utilization abut also for the power and cooling required to support all those underutilized drives. Most legacy arrays have built-in inefficiencies in the way data is laid out on disks, making it virtually impossible to achieve uniform utilization across all disk resources. The result is uneven consumption of disk capacity, as well as uneven I/O service levels among different disk groups, which is another variable in how much performance degrades following a controller failure in a dual controller array.
Finally, the customer now has two arrays to manage, including multipath connections, SAN zones, and all other aspects of the configuration, which all contribute down the road to change management complexities. The result is a net drag on administrator effort and an increased TCO.
How many do you need?
A true best of breed solution would address the root-cause deficiency in the array's design, without creating additional management and cost burdens to the customer. Obviously, more than two controllers are needed. But how many controllers does a cloud service provider need in an array? The answer is at least three. Why? Because when a single controller fails, there can still be two surviving controllers working together, mirroring their cache contents, and performing fast writes to cache memory. That said, controllers are usually packaged in pairs for redundancy purposes, which means that the most likely configurations will have four controllers.
If you compare a single quad controller array with two dual controller arrays there are some key advantages that immediately jump out:
No or limited loss of performance after a controller failure
All drives and cache can be used to service all workloads
Managing a single array significantly reduces cost and complexity
A better recipe for maintaining performance levels
The next question is; "Is there a suitable quad controller array that the customer could have used instead of the two dual controller arrays they have?" Yes, 3PAR's F400 or T400 arrays are both quad controller arrays. The disk drives in these arrays can be either SATA or FC, or a mix of both types if the customer wanted to implement tiering. Product information of the F400 can be found here, and the T400 here.
However, simply putting four controllers in an array does not necessarily guarantee that they will be able to sustain write caching if one of them fails. The array must have the ability to remap and re-mirror the write cache contents of all four controllers to the surviving controllers following the loss of a controller. It's an interesting geometric sort of problem: There are four controllers, each with their own cache and cache that is mirrored from the other controllers in the array. All cache contents, including mirrors, need to be distributed evenly across all controllers to avoid congestion and load imbalances. All cache content, including mirrors needs to be accounted for within the array so that if a controller fails, the other controllers will be able to identify all the surviving original and mirrored copies of data. For cache data that has lost either a primary or mirrored copy, a second (new) copy needs to be made. Finally, the amount of data in cache may need to be re-leveled (decreased) to fit into the degraded cache capacity (3 controllers instead of 4).
The software for doing this in a 3PAR array is Persistent Cache. Product information on Persistent Cache is here (PDF)
I made a 9 minute last year video describing how Persistent Cache works. Here it is again. Thanks for watching.
My wife brought home an iPad from the high school where she works this weekend because the school is trying to assess the iPad's usefulness as an educational tool. My son spent the most time with it and he likes listening to music and watching videos. He loves the thing. Honestly, I don't know why we didn't have one already, as I've been threatening to go buy one for several weeks now. I think it is an amazing concept - and still do, but I'm less crazy about the implementation after having spent a few hours with it. Here's why:
The first thing I wanted to do was check email on a Google Apps account I have. After opening the Safari browser, I went to login to my account and that's when my iPad experience started to sour. When you position the cursor to enter text on the iPad, a pop up keyboard appears on the bottom of the screen, but it doesn't have any numbers on the keyboard. There's a key that switches to a numbers view, but that version doesn't have any alpha keys. It's not that hard switching back and forth between the two, but typing a password that passes even minimal security standards becomes more convoluted than it ought to be. Yes, Mac fans, I know there are real accessory keyboards you can get for it, but you have to admit, the pop up keyboard is sort of a kludge. There is PLENTY of room there to do better and this is only going to encourage people to use flimsy passwords. Yes, I've seen the online videos showing clever iPad keyboard tricks, but none of them address this shortcoming.
Another thing that bothers me about the iPad pop up keyboard is that it displays password text in the clear before changing them to black dots. What's THAT about Apple? My guess is that they were concerned that people would not have confidence with their typing and so they decided to briefly display password characters as they are being entered. Are they trying to protect customers from the frustration of having virtual fat fingers by displaying what should otherwise be secure information? Hmmm, at this point I'm starting to think that security was given the lowest priority on the iPad. Not that I'm a big security guy, but the digital world is fraught with far too many threats to be so non-chalant about it.
That said, Windows Vista drove everybody crazy by going overboard on security, and it's not hard to see why Apple might have chosen to avoid similar "features", but the keyboard actually is very easy to type on and the keys seem oversized, if anything. There should be some way to show numbers and letters together, allowing people to easily create whatever passwords they desire and it shouldn't show secure information in the clear, even if it is for a brief moment.
Anyway, Safari on the iPad doesn't work with Google Apps, (and email accessed through it) something that took me some time to figure out. It apparently has something to do with the fact that the Safari browser used on the iPad is the same mobile version as on the iPhone, having certain functional reductions. I wasn't surprised to to find compatibility problems between Apple and Google and I assume this sort of thing will continue to be an annoying contest for years to come. I started using Google Apps years ago and the iPad doesn't get me there. That's a problem.
I was able to access my Google Apps email account using the integrated email app and selecting Gmail. This worked pretty well, the setup was straightforward and figuring out how to use Gmail on the iPad was a snap. Again, the thing I didn't like was that I was not able to access my Google Docs from this app. I tried a number of ways and finally gave up after diving into the forums and finding there would be no happy ending today.
So I decided to find another app, maybe something more fun. But first, I went to log out of Gmail and couldn't find the secret decoder ring. I figured this had to be pilot error - how can you not have a logout function for email? As much as I tried I couldn't find my way out of Gmail. Good lord! So I hit the forums again and found out, sure enough, there is no way to log out of Gmail on an iPhone- and by extension - an iPad. If you want to shut down access to Gmail after having set it up, you have to delete the account from the email application using the "settings" application. Seems a bit extreme if all you want to do is make sure people can't peek at your email.
Now, its important to lay blame at the right party here, which is Google in this case. And although I'm tempted to say this is probably some treachery waged against Apple by Google, the main issue is that Gmail on the iPad is just the iPhone version running on it's younger and larger sibling. A lot of people choose to keep their email access open all the time on their smartphones so they can stay on top of messages without having to constantly log in to see them. But there are also times when people just want to lock down their information so others can't see it. The iPad is a tablet and not a smartphone, and whereas smartphones are personal devices that you can hide in your pocket, the iPad - simply by virtue of it's size is more exposed to mischief. Not only that, but its also something that people seem to like sharing an awful lot. If we had one at home, I'm sure there would be some contention about who gets to use it.
Anyway, the point is, not allowing somebody to log out of an account where there is sensitive, private information from family members, co-workers, financial accounts and other important sources is simply ridiculous. Not only can your personal, private information be compromised, but there is also the risk that somebody else can access your account and send fake emails on your behalf - without you knowing about it.
When I explored apps at Apple's online store, I definitely got the feeling that a lot of them were designed for the iPhone and didn't really translate all that well to the iPad. Opera's Mini Browser was a good example. The functionality it had was decent, but the scaling of it on the screen was far less than perfect.
On the positive side, I really liked the book reader, which I thought was stellar and might be the ultimate app for the iPad. But if all I want is a book reader, I'd probably prefer a Kindle, with its included wifi service. In short, the iPad is new - and I think it shows. I'm still interested in getting one sometime, but I have to figure out if I want it to be more like a PC than a smartphone. Today, I'm inclined to look for a tablet that is less of a computing toy than the iPad is.
