This blog and website is for the BitMasons LLC analyst firm and Gordon Haff. The focus is on technology matters but we'll post on other things that catch our eye as well. And just have some fun too.
From John Markoff at The New York Times:
For the past four years, Google has been working on self-driving cars with a mechanism to return control of the steering wheel to the driver in case of emergency. But Google’s brightest minds now say they can’t make that handoff work anytime soon.
Their answer? Take the driver completely out of the driving.
I really want to give Google the benefit of the doubt here and assume that their engineers are smart enough not to have thought it was realistic for this sort of automated system to have a realtime manual backup. As I discussed a couple weeks back, "the handoff between manual (even if assisted) and autonomous needs to be clearly defined. Once you hand off control, you had better trust the autonomous system to do the right thing (within whatever margin of error you deem acceptable). You can’t wrest back control on the fly; it’s probably too late."
I learned a new buzzword at yesterday’s MIT Sloan CIO Symposium: "The Fog”—sort of Cloud + Internet of Things. Mercifully, that notwithstanding, the event was per usual an in-depth snapshot of not only up-and-coming technology trends (as one would expect at MIT) but also many of the related cultural and organizational issues. You can think of the event as being about the technological possibilities—but also about the constraints on those possibilities imposed by culture and other factors.
The MIT Academic Panel is a good jumping off point. Moderated by Erik Brynjolfsson (co-author with Andrew McAfee of The Second Machine Age), it examined the idea that we are “now beginning to have technologies that augment the control system” (i.e. the human brain) in addition to the "physical power system" (i.e. human muscles). Brynjolfsson went on to state that “We are at the cusp on a 10 year period where we go from machines not really understanding us to being able to."
One example discussed by the panel was self-driving cars. John Leonard from MIT CSAIL and the Department of Mechanical Engineering said that he was “amazed by the progress of what’s happening out there,” likening autonomous driving systems to search for the physical world. At the same time—and here’s where the constraints come in—he also said that he had the “sense that we’re not quite there yet,” for example, to determine what might happen in a tricky driving situation. What’s “not quite there”? No real predictions. Leonard did say however that he only saw a 1 in 10 chance of a "really big [employment] transformation” which I took to mean a 1 in 10 chance of a what I like to call a robo-Uber (i.e. truly autonomous cars) in any near-term time horizon. Sloan prof Thomas Malone added that he would “be surprised to see general intelligence computers relative to people” in 30 to 40 years.
In other words, strong AI—as opposed to things like IBM Watson that just appear intelligent—remains elusive. And it’s also unclear what limits that constraint puts in place.
The MIT Media Lab’s Sandy Pentland—decked out in vintage wearables—offered some other potential limits when he noted that the “rate of innovation in technology is much greater than the rate of change in government is much greater than the rate of change in culture. The NSA was a pretty well-governed organization—for the technology of the 1960s.” But, now, he went on to say “Everything is becoming data-fied.” And, while there’s always been a lot of slop in laws and how they’re enforced, that becomes more difficult when there’s potential telemetry and data everywhere. Automatic traffic tickets anyone?
As for passwords? They’re “useless” says Patrick Gilmore of the Markley Group. “If you’re not already using 2-factor authentication, you’re behind.” Nor was he a fan of password managers. Mind you, this is a somewhat enterprise-centric view of security. Tim Bray has argued for federated identity in a broader context. Which requires trusting someone and people generally aren’t very trusting these days. But it’s probably better than the password status quo in a lot of situations. Risk management and security—and their intersection with ever-increasing quantities of data—were also big topics throughout the day. Forrester Research’s Peter Burris, moderating a Leading the Digital Enterprise panel, opined that instead of saying we can protect everything we have, we have to think about what we can do about it afterwards—in addition to continue trying to stop attacks. Equinix’s Brian Lillie agreed, saying “You’re not going to stop everything; it’s a cornerstone of risk management.” And Raytheon’s Rebecca Rhoads spoke about the need to have sophisticated compartmentalization of information, driven by regulations and other factors.
Gilmore also suggested that people coming to his company—Markley’s a colocation provider—“mostly aren’t asking the right questions.” When dealing with cloud and other infrastructure providers, he argued that you should be looking in more depth than most people do. How long do you keep backups? How many versions? What type of physical security do you have? Do you degauss your hard drives when you retire them?
Mark Morrison of State Street also noted that you can’t outsource all of your security and have to think about how all of your security fits together—including all your point security products, your operational processes, and your external providers—and constantly evaluate. He also noted that there’s a “conundrum between privacy and information security—the level of monitoring and sophistication that lets you institute countermeasures."
Security and privacy aren’t the only things that play into data though. There’s also the pesky matter of physics. Lillie discussed hybrid cloud models in this context because “if you have enormous data sets, data gravity is happening. You need to find ways to connect clouds to private enterprises."
If I had to sum up my main takeaways from the day, they’d be something like the following. There’s the potential for many big changes related to computing power, to data, to computing ubiquity. We’re already starting to see some of the results. But some technological distances that seem small aren’t. (Think reliable speech recognition.) And, even more importantly, culture, laws, ethics, and economics all matter. Which is one reasons that CIOs increasingly have to work closely with business owners to deliver on technology promises rather than focusing on the technology alone.
This is from a presentation/discussion from Boston ProductCamp in May 2014. Here's the abstract: We've all made rational decisions and forecasts based on individually analyzing the best available data. But there are many other aspects of decision making. This session will examine some of those. When can groups of non-expert individuals beat some of the best experts? What are some of the common biases that cause ordinary people to make decisions differently from those that they "should" make. Can you take advantage of the ways other makes decisions or is this unwarranted manipulation?
I’ve been thinking and reading about autonomous systems of late—both autonomous IT systems and autonomous systems of other types such as vehicles. I also read a lot of misconceptions about automation—whether it’s in the arguments against or in misunderstanding what automation really means. I’ll be writing further on the topic but here are five points to get started. Comments welcome.
Computers are good at things that can be automated
Back in my earlier life at Data General, we were selling some of the earlier symmetrical multiprocessor (SMP) servers to large enterprises, including Wall Street. SMP introduced a new wrinkle. Where to place individual processes so that the system as a whole, with its multiple processors, ran most efficiently. One approach was to manually place them—which is precisely what a number of our big customers wanted to do; we even wrote and sold them class software to help them do so. But know what? The operating system scheduler could actually do this job pretty well in the aggregate, as all these customers eventually recognized.
There are legitimate questions about what tasks can be readily handled by computers and which can’t. With respect to self-driving cars specifically, computer AI interacts with the physical world much differently from a human. It’s fair to say that computers will be able to do many things much better than can even a good driver while handling other situations will prove very difficult to solve. With datacenter computing though, it’s clear than many tasks have to be eventually automated and exceptions should be relatively rare.
Assistance can precede automation
Yet, even when complete automation isn’t (yet) achievable, it can still be used to significantly offload how many activitie people need to do. We’re already seeing this in automobiles with technologies like adaptive cruise control, which can adjust a car’s speed to maintain a safe distance from any vehicles ahead. Such systems are mostly in luxury cars today but I expect they’ll become both more widespread and more sophisticated. And judiciously applied assistive systems can be rolled out far more incrementally than anything taking over full control.
The same is true with cloud computing. One example that I like to use is around the idea of cloudbursting—typically used to mean the dynamic movement of workloads from private to public clouds in response to an increase in demand. As I’ve written previously, this strong form of cloudbursting—much less the idea of workload movement in response to changes in public cloud spot pricing—gets into a lot of complications. However, hybrid cloud management software and operating systems that can run in different environments make it possible to move applications around as needed (e.g. to switch cloud vendors) even if the process isn’t necessarily completely autonomous and hands-off.
Automation isn’t all or nothing
Even when hands-off automation works well and is appropriate for some tasks, it may not be used—or may be used under a more rigorous set of controls—elsewhere. With respect to self-driving cars, I can easily imagine an interim stage where they can drive autonomously on designated sections of limited access highways—and not elsewhere. For anyone who commutes on the highway or does long Interstate drives, this should be an obvious win even if its not the nirvana of a robo-Uber.
Similarly, while “automate more” should be IT’s mantra, most companies aren’t starting from scratch. It won’t always make as much sense to aggressively automate stable legacy systems as it will to automate through a new OpenStack infrastructure that’s running primarily new cloud-enabled workloads. Standardizing and automating are effective at cutting costs and reducing errors just about everywhere—but the bang for the buck will be bigger in some places than others.
But autonomy requires a defined control handoff
The above said, the handoff between manual (even if assisted) and autonomous needs to be clearly defined. Once you hand off control, you had better trust the autonomous system to do the right thing (within whatever margin of error you deem acceptable). You can’t wrest back control on the fly; it’s probably too late.
In so many autonomous car discussions, I hear statements to the effect of: “If there’s an emergency, the driver can just take over.” Well, actually he can’t. He’s playing a game on his iPad and he probably needs a good 30 seconds to evaluate the situation and take any corrective action. OK for some situations, not for others. If the car’s in control, it has to deal with things itself—at least anything urgent.
With complex distributed IT systems, as increasingly characterize cloud environments, it’s certainly important to understand what’s going on. But events happen and cascade at incredibly short time scales by human standards. Check out this presentation by Adrian Cockroft of Battery Ventures in which he talks about some of the challenges associated with monitoring of large-scale architectures.
Autonomy can require new approaches/workflows
Finally, the best way to automate is likely not to just automate the old thing, certainly not if the old thing is a mess. A clean sheet approach may be constrained by coexisting with what’s already in place to be sure. The infrastructure that we’d build for 100% self-driving cars is much different than what we would build (and have built) for a 100% human one. However, even given a mixed environment, I suspect that over time we’ll add some infrastructure to help autonomous cars do things that they’d have trouble doing otherwise.
In the case of IT, we’re seeing new classes of tools oriented to large-scale cloud workloads and DevOps processes. One big thing about these tools from those of the past is that they’re mostly open source. Donnie Berkholz of RedMonk discusses some of them in OpenDevOps: Transparency and open source in the modern era. These include configuration management like Puppet and Chef as well as monitoring and analysis tools like Nagios and Splunk. DevOps itself, whatever your precise definition, is very much tied into the idea that much of the manual, routine ops work of the traditional system admin is increasingly automated. This is the only thing enabling a developer to take over so many ops tasks.
Automation done right is a huge positive. But we need to understand what it is, how to use it, and how to interact with it.
[Photo credit: BMW. BMW Spartansburg SC assembly plant.]
As many of my readers probably know, last week was Red Hat Summit in San Francisco. The big #10, the largest crowd ever, and the first time outside of Boston since it was a much smaller event. This was (I think) my sixth Summit—four since joining Red Hat and two prior and my only regret is that there weren’t two or three of me in attendance. Between my own sessions, an afternoon spent with industry analysts, and various other meetings, I only made one breakout plus about half the keynotes. And, while I had a chance to chat with a variety of fellow Red Hatters, I didn’t get to spend sufficient time with nearly enough.
Check out the main Summit link for lots of material from both the keynotes and many of the breakouts. Lots of good work there by the video and other content teams. Thanks to their efforts, I can share some of the specific sessions I was involved with throughout Summit.
After signing some books on Tuesday, I had the pleasure of hosting Michael Coté of 451 Research who talked about why mobile, DevOps, and cloud trends matter. I’ve known Coté from back when he was an analyst with RedMonk and he recently came back to the analyst side after a stint at Dell. I did a full write-up on his talk, but some of the most interesting tidbits for me came out of recent 451 research on “mainstream” DevOps—i.e. organizations that don’t look like the usual DevOps exemplars like Netflix or Etsy. According to Coté:
These mainstream DevOps companies are mostly using testing, performance monitoring and log management, release management, and configuration management tooling. You’re still not seeing a lot of the new “utopic” startup toolchains that are most associated with DevOps. And only about 16 percent are using automation tools compared to using “older ways” of doing builds such as customer-written build tools and golden images. (Among those using automation, continuous integration tools such as Jenkins and Bamboo are the most common but there’s a lot of DIY tools out there too.)
The bottom line? “There’s strong business demand, work to be done as far as the eye can see, and lots of maturing ahead of us.”
I found this a useful sanity check about the state of DevOps outside of a relative handful of especially forward-looking technology forms.
For my next session, I did a “fireside chat” with David Linthicum of Cloud Technology Partners on best practices for PaaS, OpenStack, and cloud adoption. I’ve had the opportunity to participate with David on a series of GigaOm webinars over the past year. We wanted to try a format for Summit that recreated the interactivity and spontaneity of the webinars rather than taking up the full slot with a presentation. The audience certainly seemed to like it based on the number of questions and topics that they threw out.
Linthicum doesn’t mince words. One of his best practices is:
Go hire someone with a brain. “You need someone who can make the appropriate calls so that you’re marching in the right direction,” said Linthicum.
Most cloud-based systems are lacking architecture, and what’s more, solutions architects can get too narrowly focused on their own areas. “Typically, people aren’t going to have a range of skills that lets them be agnostic architects to make the right decision from all available choices,” Linthicum said. Hence, the need for open minds and sharp brains.
If any of this whets your appetitive, check out the embedded video and/or the blog post.
Finally, I co-presented with my colleague Jane Circle about using Red Hat products in public clouds. I focused on some of the general considerations associated with running workloads on public clouds such as how the applications scales, selecting public cloud instance types, and dealing with data governance. Jane then went into the specifics of consuming Red Hat products from both a business and technical perspective on Red Hat Certified Cloud Providers. These were our overall takeaways:
If you didn’t make it to Summit this time, there’s always next year! Thanks to everyone who came and especially to anyone who attended one of my sessions.
I gave this presentation at the Linux Collaboration Summit in Napa last month. It brings together various thoughts for a couple of earlier blog posts of mine. When I have time, I'll put up an annotated version.
OpenStack is paralleling and will likely continue to parallel the adoption of another open source project that has become enormously popular and successful—namely Linux. The parallels are educational and useful in that they lend insight into the rate at which adoption takes place and what we might expect successful adoption to look like. At the same time, this session will provide appropriate caveats about assuming that OpenStack can be viewed as just a latter-day Linux. By applying this sort of historical perspective, we can better understand what might be the most effective approaches to collaboration, community-building, and cooperation moving forward.
Over at CIO, Stephanie Overby presents a GE Capital case study in which
The team was given some quick training in automation and given three tasks: develop the application quickly, figure out how to automate the infrastructure, and figure out how to automate more of the application deployment and testing in order to marry DevOps with continuous application delivery.
DevOps is often thought of as the breaking down of walls between operations and development. As such, it’s the IT equivalent of other types of integrated teams—an organizational style that goes in and out of fashion but is more in that out at the moment.
Looking at DevOps this way is… well, not wrong exactly but it misses important points. It’s worth stipulating here that there’s not yet a broad industry consensus around what DevOps. Nonetheless, it’s broadly recognized that historical boundaries between developers and operators and—as important—between the tooling that they use are rapidly breaking down.
Let me lead into my point with another quote from the article.
The project not only proceeded quickly -- the application was delivered within several months -- it established some new IT processes. They increased the amount of automation possible not only at the infrastructure level, but within the application layer at well.
Note the repeated use of the word automation.
A naive view of DevOps (which corresponds to how it was often discussed a few years back) was that DevOps was about the merging of developer and operator roles into one. The developer grabbed the production SQL database root password and the operator started churning out PHP. But that’s not really the DevOps story.
Much remains to be written and discovered on this topic. (By myself and others.) But one way that I increasingly think about DevOps is that the architects and operators build the infrastructure, setup developer self-service, automate scaling and deployments and then get out of the way.
For example, here’s how Paypal’s Ryan Granard described their approach with Red Hat’s OpenShift PaaS at GigaOm Structure last June:
Our concept is you walk up to a portal, you pick the product that you want to work on. You're not asking VMs and RAM. You just say, I want to work on Wallet. In minutes, we have you up and running in a fully connected container and you're developing. That's the key. That's a real benefit to just the speed of innovation and ultimately not having developers or testers or any of these folks do anything that's not part of what their role fundamentally is.
Viewed through this lens, DevOps can be seen as not necessarily about developers becoming amateur DBAs or operations folks slinging a lot of code. It’s true that some of the newer management and operational tooling—think Puppet, Chef, Foreman, and so forth—is lighter weight and perhaps more suited to a degree of joint dev and ops use. However, it’s also clear that DevOps is about automating the relevant subset of operations for developers and providing easy-to-use instrumentation and controls that let them make effective us of that underlying infrastructure.
photo: CC/flickr by M Ray http://www.flickr.com/photos/mray/7249435726/
