This is part II of the series I began with this post. In this review, we'll look at the drivers of the character of Gordon Gekko. While I am not in complete agreement with Daniel from crookedtimber.org regarding Gekko being a sympathetic character, he does point out several things about Gekko which clearly played a role in his development. He does have some admirable and sympathetic qualities, which I think will become clearer as you read this (if you disagree initially). All I ask is that you keep an open mind.
There seems to be a bit of controversy around Oliver Stone creating films in which the protagonist is torn between different "fathers". He mentions this in the director's commentary in the 20th anniversary edition DVD. In "Wall Street", those fathers are Bud's biological father Carl (played by Martin Sheen, Charlie Sheen's biological father) and Gordon Gekko, who takes young Fox under his wing. However, this father theme extends even further into the film, and is critical to understanding Gordon Gekko as a person.
In the scene "Business Philosophy" (20th anniversary edition DVD), Gekko says the following to Bud while they ride in the back of Gekko's limo:
"My father, he worked like an elephant pushing electrical supplies til he dropped dead at 49 with a heart attack and tax bills."
Now, why is this important? Well, we don't know how old Gekko was when this happened, but presumably it was when he was quite young, possibly less than 10 years old.
As it so happens, there was a profile of Sir James Dyson, inventor of the Dyson bagless vacuum cleaner, in the Telegraph UK in August 2008. In that profile, Dyson mentions the impact of his father dying when he was young. He also notes that 75% of British Prime Ministers lost their fathers before age 10. This loss, Dyson reckons, instills within the sons a feeling of individualism, of being alone in the world, and thus being forced to succeed because they know there is no one else out there to help them. (Never mind other family such as siblings or a surviving mother.)
Now, if we compare the descriptions of these men whose fathers died before their 10th birthdays, we see a lot of traits that map back to Gordon Gekko. Individualism, even arrogantly so. A selfishness and self-centered orientation personality, derived from the feeling (whether accurate or inaccurate) that Gekko was left alone to figure out the world after his father's death. Focus and determinism. This is evidenced by his rise within the financial world even as a "City College boy".
The other thing you'll notice, if you look past the coarse tone of voice he uses while saying it, is Gekko's disappointment at his father's death from overwork. He clearly believes that his father worked hard and never truly benefited from his labor, so he sees no need to do hard work if another (easier) avenue to his goal exists.
The other major sympathetic moment we have with Gekko, and one I think was majorly overlooked by most, occurs in the scene "A Safe Distance". This is the scene where Bud is at Gekko's beach house signing power of attorney forms to distance himself from Gekko. Now, this whole process inherently violates the notion of Gekko being victimized by Bud. The whole explanation of the process by is clearly saying that you (Bud) will be performing actions which expose Gekko to legal risks he does not want to assume. Thus, this is another point of disagreement for me with crookedtimber.org's analysis; why would Gekko go through this legal maneuvering if he didn't at least believe there was a risk exposure? Gekko, like all great investors, has to understand the idea of risk management. Legally distancing himself from Bud is such a tactic.
Getting back to my original point, the key to this scene is when Gekko's son Rudy is brought poolside by his nanny (au pair?). As soon as Gekko sees his son, he turns into a typical blubbering parent, runs to meet his son, and picks him up. While holding him, he has his son say "hello" to Bud in french. Gekko then takes his seat back at the table, while still holding his son and gloating about how Rudy had "the highest score on his I.Q. test". Looking through the absurdity (an I.Q. test for a 3 year old) and arrogance in that statement, Gekko can be seen as a loving father boasting about his son's achievements. Later, after handing Rudy a raspberry which he immediately pelts across the table, Gekko licks Rudy's fingers clean.
Adding all of this up, we are presented with the picture of Gekko as a doting father who is able and more than willing to give his son all the things his father was unable to give him (Gekko) due to his untimely death.
Returning to the father theme, and the humanity of Gordon Gekko for a last time, we see it on display in the next to last scene on the 20th anniversary edition DVD. In "The Abyss", Bud faces Gordon in Central Park while wearing a wire, unbeknown to Gekko. After using Bud as a punching bag while reciting another great soliloquy, Gekko says these words to the bleeding Fox: "You could have been one of the great ones, Buddy. I look at you, and I see myself. Why?" Gordon, for all of his exploitation of Bud, has developed a true affinity for the younger man and here it is on fully display. After the 2 part, and Bud begins walking toward Tavern on the Green, we're left to linger on Gordon as he walks in the opposite direction. If you watch closely, you'll see in Gordon's eyes the hurt that he feels at the betrayal by someone he allowed to get closer than any other. He carries a somewhat dazed look, as well as the hint of wanting to cry. While his anger is real, Gordon's anger is also a mask (as anger usually is), a cover for the feeling of hurt, loss and disappointment. Anyone who has ever truly and deeply felt those feelings has had a look on their face much like Gordon's at some point, even if they didn't know it.
Personally, I believe these largely overlooked aspects of Michael Douglas' performance were the biggest contributors to his winning the Oscar for Best Actor in 1988. It is easy to overlook the softer side of the character. Oliver Stone intentionally wants us to dislike Gordon for his role in Bud's downfall, and generally how he uses people. However, Gordon is not without emotions. He's human, even if he doesn't want to appear to be.
Should Gordon Gekko be idolized? That is debatable. However, I do think he has as many "good" qualities as "bad" ones, and that needs to be recognized and accepted. We don't have to like the person to see them as they truly are, not as their ego thinks they are or wants them to be. You don't have to like the person, or the person's actions, to transcend your own personal biases and realize that, at our cores, we are all, in some way, just hurt, afraid, scared and vulnerable 8 year olds who have never EVER truly grown up. Even Gordon Gekko.
Thursday, December 01, 2011
Friday, November 25, 2011
Probabilities
That's what risk management comes down to. Probabilties.
The CEO of Wegelin & Co. clearly understands this. In this article, I think he makes the best quote I've heard in a while on the topic of managing risk.
It's conceptually simple, yet difficult in practice. You have to constantly calculate and re-calculate the probability of a favorable outcome, and when you have the advantage, press it HARD. When you've lost the advantage, then you don't bet. You will not always win using this system, but you'll win significantly more than you lose (based on outcome). That's what is doing here. They've lost the advantage, so they refuse to make the bet.
Will this affect some of their customers? Of course. However, they are clearly on the side of bank secrecy and that's fine. They are forward and upfront about that. The risk of having to expose their customers with US holdings is now greater than it had previously been. As Mr. Hummler noted, "My responsibility toward clients has to include any kind of probability, and if I see a real threat then we have to act." This is the kind of thinking we should all get from our fiduciaries! The risk may be small, but it is non-zero. The penalties are very real, and the overall exposure is incalculable, as well as the increased reputational risk of giving up your customers like UBS. I'd say the advantage has been, or will be, lost!!
Something to think about. Until next time...
The CEO of Wegelin & Co. clearly understands this. In this article, I think he makes the best quote I've heard in a while on the topic of managing risk.
It's conceptually simple, yet difficult in practice. You have to constantly calculate and re-calculate the probability of a favorable outcome, and when you have the advantage, press it HARD. When you've lost the advantage, then you don't bet. You will not always win using this system, but you'll win significantly more than you lose (based on outcome). That's what is doing here. They've lost the advantage, so they refuse to make the bet.
Will this affect some of their customers? Of course. However, they are clearly on the side of bank secrecy and that's fine. They are forward and upfront about that. The risk of having to expose their customers with US holdings is now greater than it had previously been. As Mr. Hummler noted, "My responsibility toward clients has to include any kind of probability, and if I see a real threat then we have to act." This is the kind of thinking we should all get from our fiduciaries! The risk may be small, but it is non-zero. The penalties are very real, and the overall exposure is incalculable, as well as the increased reputational risk of giving up your customers like UBS. I'd say the advantage has been, or will be, lost!!
Something to think about. Until next time...
Monday, November 21, 2011
Investing in Cloud Computing and Automated Infrastructure
Welcome to part two of what started out as a simple exposition about cloud computing and has turned into...this. I apologize for the delay in getting this out, but life caught up with me. Plus, I had a lot I wanted to say and organizing my thoughts took a bit of time.
If you read part one, then you have some context for the remainder of this discussion. I plan to cover cloud providers, some thoughts on what may or may not be competitive advantages of various providers (or maybe an ideal provider), and what some of the investing implications may be in this space. This should ALL be considered a giant thought experiment. It sure as hell is not investment advice. If you even conceive of investing based on anything said here, you're an idiot, and as Gordon Gekko once said, "A fool and his money are lucky enough to get together in the first place". You might as well send me that money (or you could commission me to do a research report for you, to make it feel like less of a waste).
In my last post, I discussed the idea of automated infrastructure. The basic idea is that you can scale your infrastructure, systems and network, dynamically and programmatically based upon capacity planning rules you define for your architecture. That whole sentence sounds pretty high level, but I'm not sure how to break it down further right now. Follow the links above for an example of how SmugMug achieves these outcomes.
That said, a lot of the effort that goes into creating systems that can automatically scale themselves up AND down is in building the tools. THAT effort is what is slowed down by the lack of programmability of network elements such as switches, routers, firewalls and others. Making these devices programmable would allow the creation of tools which can scale based on input from monitoring systems (again, following predetermined rules and at predetermined thresholds). Scaling could occur with less latency, increasing responsiveness in both directions. Sysadmins could spend their time building these tools, developing the rules driving them, and managing the metrics which are fed as input to the tools (among other, higher level tasks). This is the ideal. While this is achievable now, it is not easy, which is why it is so rare to find it. It also takes a lot of time and infrastructure and software development investment to make this reality given the inherent inaccessibility of these devices.
Creating an API is like creating a software development kit (SDK). It provides a means for customers to control their products, and make them work the way they need them to. If I run an in-house application development group and want to add some HA functionality to the application, then Veritas (Symantec) provides an SDK for enabling my application to work with Veritas Cluster Server. Not only does this lock me into the Veritas HA solution, but it gives me control and flexibility to really manage MY application the way I want/need to, if I'm willing to invest in the time and resources. If I'm not willing to make that investment, then provided the proper security precautions have been taken when the device ships from the vendor, there is no downside to the API being made available.
As for investing, I'm not sure what the best route is. Who knows if a company like Joyent will ever go public? I doubt it, as it seems the team over there is building a long term business. I'm sure Jason et. al have a price though. I'm sure there will be cloud providers who do decide, eventually, to enter the public markets. Some will be snapped up by HP, IBM or other providers of technology services. AWS makes up a growing part of Amazon's business and revenue mix, and it wouldn't surprise me to see it spun off eventually (in say 3 or more years). Of course, Jeff Bezos isn't the type of founder to let go of such a growth engine, so maybe Amazon is the easiest play on cloud computing after all. If I recall correctly, AWS may actually be as large as the retail business now, and it is definitely growing faster.
What IS clear is that automated infrastructure and system/network operations is truly becoming a competitive advantage and force multiplier for many companies. This is not just the case for online companies such as Google, Yahoo!, Microsoft, Amazon, Apple or many of the cloud providers that I mentioned. This will more and more become the case for anyone of any reasonable size, whether they are online or not. And let's face it, anyone of any reasonable size (1000+ employees) will be online in SOME fashion, either selling products and services directly, or supporting their customers with online knowledge bases, documentation archives, software downloads and updates, customer relationship management (CRM) and technical support/trouble ticketing, mobile device (e.g. cell phone) services, etc.
Investing in Amazon or Google is A way to play public automated infrastructure. IBM doesn't seem to make a good bet, as they suffer from the conglomerate problem -- they do everything, so anything they do may have a lot of growth potential but it will not be substantially accretive to the bottom line. (In fact, expect for most large companies that automated infrastructure and systems/network operations products and services may be loss leading for a while, if not permanently.) Rackspace could be interesting from the cloud service provider angle, given that they are small compared to most of their competitors and publicly traded. However, there have been some other rumblings in certain forums I follow, so that one definitely requires some in-depth homework. If you're looking to invest in providers, RAX is public, well known and (generally) well regarded even though they've had some hiccups in the recent past. (But who hasn't? This whole space is all new.) The biggest problem with RAX may be the commodity hardware business they are attached to. Definitely proceed with caution, but if you like the Joyent angle, the best currently available investment in that space is Rackspace. They are direct competitors.
I definitely think that network equipment vendors adding APIs to their devices is powerful. This is the "picks and shovels" way of thinking about this space. I'm not sure how well Juniper has done with this, but they need to be promoting it HARD HARD HARD!!! JunOS is known, or at least marketed, as being scalable across the entire line of Juniper products so there's only one software release to manage. That in itself is a win, but if I can now program my routers (and switches! Please Juniper!) to adjust to inputs from my monitoring system or as part of the process of spinning up overload servers/infrastructure, that becomes extremely useful for the cloud services providers. Again, many already do this but it's not easy, it's not built into the fabric, it's subject to subtle changes in the vendor software, user management issues (password changes, account deletion, etc.) and a raft of other problems. Of course, if Cisco did this, it would be HUGE but it wouldn't lead to much product uptake, I don't think. It would be more of a lock-in move for CSCO.
Smaller vendors such as Vyatta, Extreme Networks, Force 10 and others might stand to benefit from providing programmatic access to their networking software, however. Arista Networks is another obvious name for this too, and they have the technology chops to do it easily PLUS they target this high density server space as their core market. Programmatic infrastructure would appear to be a natural direction for Arista, but of course, they're still private.
The best way to invest in some of these companies and the future of automated infrastructure and cloud computing is probably to USE them. Any benefit that accrues to the providers is gravy, but if you can use these products, and it fits your product or service offering from a value perspective, then by all means do it! The problem with trying to invest in this space is that you want to prefer the smaller vendors who have little to nothing to lose. That counts some of the smaller hardware vendors like Extreme Networks and Force 10 Networks, but it also includes companies that are not yet public. The large, incumbent vendors aren't going to see enough of a move from investing in programmability, which is exactly why they will be slow to do it and the smaller vendors should embrace it completely. The field is so wide open it's sick. I didn't even mention other infrastructure that needs to be automated, like storage systems and storage networking. What the hell is Brocade doing in this space to compete with Cisco? Think about it. Programmable storage infrastructure will be next in line.
Programmability is a key enabler to the operations secret sauce, and will have to become important as operations grows in importance. It will be interesting to watch, and even more interesting to participate. Yaaay!
Until next time...
If you read part one, then you have some context for the remainder of this discussion. I plan to cover cloud providers, some thoughts on what may or may not be competitive advantages of various providers (or maybe an ideal provider), and what some of the investing implications may be in this space. This should ALL be considered a giant thought experiment. It sure as hell is not investment advice. If you even conceive of investing based on anything said here, you're an idiot, and as Gordon Gekko once said, "A fool and his money are lucky enough to get together in the first place". You might as well send me that money (or you could commission me to do a research report for you, to make it feel like less of a waste).
In my last post, I discussed the idea of automated infrastructure. The basic idea is that you can scale your infrastructure, systems and network, dynamically and programmatically based upon capacity planning rules you define for your architecture. That whole sentence sounds pretty high level, but I'm not sure how to break it down further right now. Follow the links above for an example of how SmugMug achieves these outcomes.
That said, a lot of the effort that goes into creating systems that can automatically scale themselves up AND down is in building the tools. THAT effort is what is slowed down by the lack of programmability of network elements such as switches, routers, firewalls and others. Making these devices programmable would allow the creation of tools which can scale based on input from monitoring systems (again, following predetermined rules and at predetermined thresholds). Scaling could occur with less latency, increasing responsiveness in both directions. Sysadmins could spend their time building these tools, developing the rules driving them, and managing the metrics which are fed as input to the tools (among other, higher level tasks). This is the ideal. While this is achievable now, it is not easy, which is why it is so rare to find it. It also takes a lot of time and infrastructure and software development investment to make this reality given the inherent inaccessibility of these devices.
Creating an API is like creating a software development kit (SDK). It provides a means for customers to control their products, and make them work the way they need them to. If I run an in-house application development group and want to add some HA functionality to the application, then Veritas (Symantec) provides an SDK for enabling my application to work with Veritas Cluster Server. Not only does this lock me into the Veritas HA solution, but it gives me control and flexibility to really manage MY application the way I want/need to, if I'm willing to invest in the time and resources. If I'm not willing to make that investment, then provided the proper security precautions have been taken when the device ships from the vendor, there is no downside to the API being made available.
As for investing, I'm not sure what the best route is. Who knows if a company like Joyent will ever go public? I doubt it, as it seems the team over there is building a long term business. I'm sure Jason et. al have a price though. I'm sure there will be cloud providers who do decide, eventually, to enter the public markets. Some will be snapped up by HP, IBM or other providers of technology services. AWS makes up a growing part of Amazon's business and revenue mix, and it wouldn't surprise me to see it spun off eventually (in say 3 or more years). Of course, Jeff Bezos isn't the type of founder to let go of such a growth engine, so maybe Amazon is the easiest play on cloud computing after all. If I recall correctly, AWS may actually be as large as the retail business now, and it is definitely growing faster.
What IS clear is that automated infrastructure and system/network operations is truly becoming a competitive advantage and force multiplier for many companies. This is not just the case for online companies such as Google, Yahoo!, Microsoft, Amazon, Apple or many of the cloud providers that I mentioned. This will more and more become the case for anyone of any reasonable size, whether they are online or not. And let's face it, anyone of any reasonable size (1000+ employees) will be online in SOME fashion, either selling products and services directly, or supporting their customers with online knowledge bases, documentation archives, software downloads and updates, customer relationship management (CRM) and technical support/trouble ticketing, mobile device (e.g. cell phone) services, etc.
Investing in Amazon or Google is A way to play public automated infrastructure. IBM doesn't seem to make a good bet, as they suffer from the conglomerate problem -- they do everything, so anything they do may have a lot of growth potential but it will not be substantially accretive to the bottom line. (In fact, expect for most large companies that automated infrastructure and systems/network operations products and services may be loss leading for a while, if not permanently.) Rackspace could be interesting from the cloud service provider angle, given that they are small compared to most of their competitors and publicly traded. However, there have been some other rumblings in certain forums I follow, so that one definitely requires some in-depth homework. If you're looking to invest in providers, RAX is public, well known and (generally) well regarded even though they've had some hiccups in the recent past. (But who hasn't? This whole space is all new.) The biggest problem with RAX may be the commodity hardware business they are attached to. Definitely proceed with caution, but if you like the Joyent angle, the best currently available investment in that space is Rackspace. They are direct competitors.
I definitely think that network equipment vendors adding APIs to their devices is powerful. This is the "picks and shovels" way of thinking about this space. I'm not sure how well Juniper has done with this, but they need to be promoting it HARD HARD HARD!!! JunOS is known, or at least marketed, as being scalable across the entire line of Juniper products so there's only one software release to manage. That in itself is a win, but if I can now program my routers (and switches! Please Juniper!) to adjust to inputs from my monitoring system or as part of the process of spinning up overload servers/infrastructure, that becomes extremely useful for the cloud services providers. Again, many already do this but it's not easy, it's not built into the fabric, it's subject to subtle changes in the vendor software, user management issues (password changes, account deletion, etc.) and a raft of other problems. Of course, if Cisco did this, it would be HUGE but it wouldn't lead to much product uptake, I don't think. It would be more of a lock-in move for CSCO.
Smaller vendors such as Vyatta, Extreme Networks, Force 10 and others might stand to benefit from providing programmatic access to their networking software, however. Arista Networks is another obvious name for this too, and they have the technology chops to do it easily PLUS they target this high density server space as their core market. Programmatic infrastructure would appear to be a natural direction for Arista, but of course, they're still private.
The best way to invest in some of these companies and the future of automated infrastructure and cloud computing is probably to USE them. Any benefit that accrues to the providers is gravy, but if you can use these products, and it fits your product or service offering from a value perspective, then by all means do it! The problem with trying to invest in this space is that you want to prefer the smaller vendors who have little to nothing to lose. That counts some of the smaller hardware vendors like Extreme Networks and Force 10 Networks, but it also includes companies that are not yet public. The large, incumbent vendors aren't going to see enough of a move from investing in programmability, which is exactly why they will be slow to do it and the smaller vendors should embrace it completely. The field is so wide open it's sick. I didn't even mention other infrastructure that needs to be automated, like storage systems and storage networking. What the hell is Brocade doing in this space to compete with Cisco? Think about it. Programmable storage infrastructure will be next in line.
Programmability is a key enabler to the operations secret sauce, and will have to become important as operations grows in importance. It will be interesting to watch, and even more interesting to participate. Yaaay!
Until next time...
Friday, November 18, 2011
Cloud Computing and Programmable Infrastructure (Part I)
This post will be a bit different, but if you bear with me, I plan to relate it back to investing. This will be part I of a series (as I found out earlier today).
A few weeks ago, I attended the Structure 09 Conference put on by GigaOm Media in San Francisco, CA. Not a bad little conference. While I'm glad I attended, and I had a great time in the later sessions and the "meet and greet" held by Canaan Partners after, it wasn't quite as technical as I was hoping. Either that, or I missed the best parts. (I arrived about 3 hours late since I was driving through rush hour traffic on the 101 from "Man" Jose.) I did get more technical meat from O'Reilly Media's Velocity 2009 conference the previous 3 days, so it was all good. Besides, I met Paul Kedrosky of Infectious Greed fame and had a nice, though brief, conversation with Jonathan Heiliger, who was my personal hero for a great many years at the start of my career.
During the conference, I shot off this tweet about cloud computing. (Much of Structure seemed to revolve around this topic.) It seemed such a simple thing to say, and so disgustingly obvious that it wasn't even worth saying, but apparently it struck a chord with some folks. So I want to expand on this idea.
For ages, the supremely competent engineers and sysadmins out there have been developing custom tools to allow them to manage their systems and networks. Most of these tools have probably revolved around some combination of expect/TCL, Perl, and shell. The reason is simple - most device operating systems were not accessible programmatically, e.g. via an API. Most still are not. I attribute this to vendor lock-in. If the only way to interface with the device is by the vendor's prescribed methods (web based, software application, or command line), then you are forced to learn the vendor's products. As you become accustomed to how a given vendor's products work, you're going to be reluctant to invest the time and energy to learn a competing vendor's products. Voila! This is the biggest reason that so many networking products have command line interface syntaxes similar to Cisco's IOS and CatOS. This has been a huge contributor to Cisco's financial success over the past 20 years. Cisco's command line syntax has become de facto standard in the networking world.
Vendors would probably say there are other reasons for not exposing their devices to be inspected or controlled programmatically. One would be security. Most network devices are pretty insecure, in terms of default passwords and configuration settings (although this has been changing SLOOOOWLY over time). I imagine a great many customers didn't particularly care to create tools and programs to manage network devices, servers, and other systems. They just wanted to configure the device and go on with their lives. Only in the last decade has it become apparent to people that Sun was right and "the network IS the computer". The network infrastructure has taken on a level of criticality that was reserved only for servers for a long time.
Finally, the rise of cloud computing and the idea of automated infrastructure has changed people's thinking about the flexibility of their systems. On-demand computing can now be realistically accomplished with commodity hardware and open systems, provided the infrastructure supports it. Many companies have been born to make this flexibility and elasticity a reality for the masses who would rather not deal with the intricacies of building their own. Amazon Web Services, Joyent, RightScale, Mosso a.k.a. The Rackspace Cloud, Enomaly, and countless others come to my mind immediately. They've taken on the challenge of providing this infrastructure for regular people. Not everyone is Google, Amazon, Yahoo! or Microsoft, with both the resources to devote to building these tools from scratch, never mind the inclination or need.
There's also a certain level of difficulty in implementing APIs correctly and efficiently that vendors were probably unwilling or unable to address. Market dynamics being what they are, the demand probably wasn't there for APIs as much as for new features, better performance, and lower costs. Even security was a higher priority! Finally (and this is largely related to the concept of lock-in), vendors probably didn't want to expose their devices to hacking and other tampering, or reverse engineering (via black box testing, etc.) by their competitors. If you're forced to deal with a command line, software application GUI (Java or Windows-based, many times these days) or web GUI, you were inherently limited in how much information about the internal workings of the device you could derive/describe.
However, with the exception of Juniper Networks, most systems and network devices still do not offer the programmatic option for people who are willing to build their own. Thus we have the menagerie of scripts and other homegrown tools which have to make do with clunky workarounds, scraping output from text commands or collecting SNMP data. Yes, it works, but it can hardly be considered optimal. These tools become somewhat second class citizens from a performance perspective, only able to issue so many commands in a given time quantum, and limited by the range of functionality exposed. Most of these scripts don't run with the highest levels of privilege, again for security reasons. (That is, a configuration management script for a Cisco Catalyst switch may run as a regular user as opposed to having "enable" privileges, and cannot change configuration settings on the switch, but I'm sure this varies too.)
However, I see this changing. I don't know if a company like Vyatta will lead the charge, but there's no reason for them not to. The question will be who follows (or leads, if not Vyatta)? Again, Juniper has already allowed a certain amount of access, which is a good start. However, I don't think the dominoes have really fallen as yet. In time, I believe more vendors will offer programmatic access to their devices through custom APIs. The ones who start this trend will do it as a differentiator, the way most innovation shows up commercially. Eventually, more vendors will offer this ability, at least for network devices (routers, switches, firewalls, IDS/IPS devices, etc.). Servers may not need programmatic access as much, although it would not surprise me to see a vendor, possibly an open source vendor, come up with a cross platform management layer that exposed a single, consistent API for multiple operating systems. Again, maybe this already exists but I can't think of who offers it.
What does all of this mean? It means, simply, that the ability to program your network will be within the reach of the average "man" and "woman" (or rather, system administrator and network engineer). This won't remove the business case for the cloud providers named previously, such as AWS or Joyent, but it will enable automated infrastructure for the masses. This will be a good thing, I believe.
Whew! That ended up being a lot longer than I thought it would, so I'm going to pause right here. In part 2 of this series, I'll go a bit deeper the investing implications of automated infrastructure and cloud computing, as I see them. Hopefully I haven't bored anyone to tears, but if I have, I apologize. I think a bit of context is required for this discussion, and there were some things that I wanted to make sure were said.
Until next time, gentle readers...
A few weeks ago, I attended the Structure 09 Conference put on by GigaOm Media in San Francisco, CA. Not a bad little conference. While I'm glad I attended, and I had a great time in the later sessions and the "meet and greet" held by Canaan Partners after, it wasn't quite as technical as I was hoping. Either that, or I missed the best parts. (I arrived about 3 hours late since I was driving through rush hour traffic on the 101 from "Man" Jose.) I did get more technical meat from O'Reilly Media's Velocity 2009 conference the previous 3 days, so it was all good. Besides, I met Paul Kedrosky of Infectious Greed fame and had a nice, though brief, conversation with Jonathan Heiliger, who was my personal hero for a great many years at the start of my career.
During the conference, I shot off this tweet about cloud computing. (Much of Structure seemed to revolve around this topic.) It seemed such a simple thing to say, and so disgustingly obvious that it wasn't even worth saying, but apparently it struck a chord with some folks. So I want to expand on this idea.
For ages, the supremely competent engineers and sysadmins out there have been developing custom tools to allow them to manage their systems and networks. Most of these tools have probably revolved around some combination of expect/TCL, Perl, and shell. The reason is simple - most device operating systems were not accessible programmatically, e.g. via an API. Most still are not. I attribute this to vendor lock-in. If the only way to interface with the device is by the vendor's prescribed methods (web based, software application, or command line), then you are forced to learn the vendor's products. As you become accustomed to how a given vendor's products work, you're going to be reluctant to invest the time and energy to learn a competing vendor's products. Voila! This is the biggest reason that so many networking products have command line interface syntaxes similar to Cisco's IOS and CatOS. This has been a huge contributor to Cisco's financial success over the past 20 years. Cisco's command line syntax has become de facto standard in the networking world.
Vendors would probably say there are other reasons for not exposing their devices to be inspected or controlled programmatically. One would be security. Most network devices are pretty insecure, in terms of default passwords and configuration settings (although this has been changing SLOOOOWLY over time). I imagine a great many customers didn't particularly care to create tools and programs to manage network devices, servers, and other systems. They just wanted to configure the device and go on with their lives. Only in the last decade has it become apparent to people that Sun was right and "the network IS the computer". The network infrastructure has taken on a level of criticality that was reserved only for servers for a long time.
Finally, the rise of cloud computing and the idea of automated infrastructure has changed people's thinking about the flexibility of their systems. On-demand computing can now be realistically accomplished with commodity hardware and open systems, provided the infrastructure supports it. Many companies have been born to make this flexibility and elasticity a reality for the masses who would rather not deal with the intricacies of building their own. Amazon Web Services, Joyent, RightScale, Mosso a.k.a. The Rackspace Cloud, Enomaly, and countless others come to my mind immediately. They've taken on the challenge of providing this infrastructure for regular people. Not everyone is Google, Amazon, Yahoo! or Microsoft, with both the resources to devote to building these tools from scratch, never mind the inclination or need.
There's also a certain level of difficulty in implementing APIs correctly and efficiently that vendors were probably unwilling or unable to address. Market dynamics being what they are, the demand probably wasn't there for APIs as much as for new features, better performance, and lower costs. Even security was a higher priority! Finally (and this is largely related to the concept of lock-in), vendors probably didn't want to expose their devices to hacking and other tampering, or reverse engineering (via black box testing, etc.) by their competitors. If you're forced to deal with a command line, software application GUI (Java or Windows-based, many times these days) or web GUI, you were inherently limited in how much information about the internal workings of the device you could derive/describe.
However, with the exception of Juniper Networks, most systems and network devices still do not offer the programmatic option for people who are willing to build their own. Thus we have the menagerie of scripts and other homegrown tools which have to make do with clunky workarounds, scraping output from text commands or collecting SNMP data. Yes, it works, but it can hardly be considered optimal. These tools become somewhat second class citizens from a performance perspective, only able to issue so many commands in a given time quantum, and limited by the range of functionality exposed. Most of these scripts don't run with the highest levels of privilege, again for security reasons. (That is, a configuration management script for a Cisco Catalyst switch may run as a regular user as opposed to having "enable" privileges, and cannot change configuration settings on the switch, but I'm sure this varies too.)
However, I see this changing. I don't know if a company like Vyatta will lead the charge, but there's no reason for them not to. The question will be who follows (or leads, if not Vyatta)? Again, Juniper has already allowed a certain amount of access, which is a good start. However, I don't think the dominoes have really fallen as yet. In time, I believe more vendors will offer programmatic access to their devices through custom APIs. The ones who start this trend will do it as a differentiator, the way most innovation shows up commercially. Eventually, more vendors will offer this ability, at least for network devices (routers, switches, firewalls, IDS/IPS devices, etc.). Servers may not need programmatic access as much, although it would not surprise me to see a vendor, possibly an open source vendor, come up with a cross platform management layer that exposed a single, consistent API for multiple operating systems. Again, maybe this already exists but I can't think of who offers it.
What does all of this mean? It means, simply, that the ability to program your network will be within the reach of the average "man" and "woman" (or rather, system administrator and network engineer). This won't remove the business case for the cloud providers named previously, such as AWS or Joyent, but it will enable automated infrastructure for the masses. This will be a good thing, I believe.
Whew! That ended up being a lot longer than I thought it would, so I'm going to pause right here. In part 2 of this series, I'll go a bit deeper the investing implications of automated infrastructure and cloud computing, as I see them. Hopefully I haven't bored anyone to tears, but if I have, I apologize. I think a bit of context is required for this discussion, and there were some things that I wanted to make sure were said.
Until next time, gentle readers...
Tuesday, November 15, 2011
The Future of US Innovation
In my last post, I wanted to make a point about this, but I think I went in a slightly different direction and forgot to come back. However, I think you'll see these 2 issues as being directly related.
As I said previously, the US will actually have to re-learn how to produce things - actual, physical products - that people want to buy because those products add value to their lives. Intellectual property - designs, plans, business models, brands - and software are all good and fine, and we need to continue producing those things. However, real physical, manufactured items will employee way more people at levels of income that support a "living wage". A service economy cannot provide jobs required to rebuild the middle class as most politicians seem intent on doing (or at least say they are intent on doing).
A big part of this issue is innovation, the process of building upon existing tools, processes, products, designs, software, etc. to create new products. I fully believe that invention -- the absolute creation of new products where none existed previously -- is crucial, but innovation creates a base from which new industries are launched. Once the fundamental pieces have been invented, there is an iterative process of innovation which must occur on top of those components (building blocks, if you will) to advance an industry. Out of that process, new companies will be formed and grow. New products, hopefully offering value to customers, both domestic and foreign, will be created and launched. Invention, and most critically, innovation, are requirements of a strong economy. These 2 processes have to be RUTHLESSLY SUPPORTED by the US, at all levels of investment -- educational, financial, sociological, economic -- in order for this to work. Without these processes, there will be no new products, serving the needs of customers worldwide, being created by American workers.
Now, I don't get why this realization seems to escape so many people, but it's a simple logical extension. The bankrupt retail and service based model has proven to be empty (and it didn't help that it was built on a mountain of debt). This nation needs to to create new stuff that is useful and valuable to people around the world, not just marketing and selling vapid, useless, unimportant, trite services, brands and ideas. The willingness of the citizenry of this nation to attack this will determine the economic future of the US more than anything else. I'm cautiously pessimistic.
*sigh*
Maybe it's time for a drink now. Until next time...
As I said previously, the US will actually have to re-learn how to produce things - actual, physical products - that people want to buy because those products add value to their lives. Intellectual property - designs, plans, business models, brands - and software are all good and fine, and we need to continue producing those things. However, real physical, manufactured items will employee way more people at levels of income that support a "living wage". A service economy cannot provide jobs required to rebuild the middle class as most politicians seem intent on doing (or at least say they are intent on doing).
A big part of this issue is innovation, the process of building upon existing tools, processes, products, designs, software, etc. to create new products. I fully believe that invention -- the absolute creation of new products where none existed previously -- is crucial, but innovation creates a base from which new industries are launched. Once the fundamental pieces have been invented, there is an iterative process of innovation which must occur on top of those components (building blocks, if you will) to advance an industry. Out of that process, new companies will be formed and grow. New products, hopefully offering value to customers, both domestic and foreign, will be created and launched. Invention, and most critically, innovation, are requirements of a strong economy. These 2 processes have to be RUTHLESSLY SUPPORTED by the US, at all levels of investment -- educational, financial, sociological, economic -- in order for this to work. Without these processes, there will be no new products, serving the needs of customers worldwide, being created by American workers.
Now, I don't get why this realization seems to escape so many people, but it's a simple logical extension. The bankrupt retail and service based model has proven to be empty (and it didn't help that it was built on a mountain of debt). This nation needs to to create new stuff that is useful and valuable to people around the world, not just marketing and selling vapid, useless, unimportant, trite services, brands and ideas. The willingness of the citizenry of this nation to attack this will determine the economic future of the US more than anything else. I'm cautiously pessimistic.
*sigh*
Maybe it's time for a drink now. Until next time...
Friday, November 11, 2011
The Future of US Employment
While reading this at the San Francisco Fed web site, a few things struck me that I wanted to share. I've thought about these issues before, but never in such a comprehensive manner.
The first consideration is that, for the US economy to have the kind of hiring that is required to rebuild (recreate?) the middle class, American companies are going to have to produce GOOD, if not AMAZING, products. Products that sell not only in the US but also to foreigners. In fact, I'd venture to say that foreign buyers will be more important to an economic recovery in the US than American buyers. A service based economy, serving only a domestic market at that, cannot support the level of GDP that will be required to employ as many people as required to resurrect the "middle class". Americans will have to make stuff - not just design stuff, not just create marketing and ideas, but actually implement and build physical products. Even if the products that US companies start producing are virtual goods - intellectual property, designs, etc. - the buyers will have to be overseas. That means whatever the products of the future are, they will need to be mindblowingly amazing! "Insanely great!" as Steve Jobs of Apple once said. They will have to solve real world problems at a huge level of value add/creation.
Second, for Americans to be employed by these companies in the numbers required by the population level, Americans will have to get used to higher prices. Why? Because if products are to be sold to American consumers, the prices will have to be high enough to allow people to make a so-called "living wage". Now, I personally have no problem paying more for a product if it provides value for me. (See Myth #5 here, this and this. Thanks Ramit!) However, as mentioned above, American products will need to be excellent values. Price is a lesser factor in considering the value that a product offers you, but the simple fact is that overall, Americans cannot be employed if they can't make enough to support themselves and their families.
For the last 2 decades, the emphasis has been on acquiring more stuff. That stuff became easier to acquire because manufacturing moved overseas, to Mexico, Central America, China, Vietnam or wherever. Now that conspicuous consumption is on life support, Americans will have to go back to living within their means, which is largely determined by income. So at both ends, the issue will need to be addressed. Consumers will need to save more and spend less overall, which they have started doing (but whether this will be permanent is to be determined). However, incomes have to be able to support a certain standard of living as well. For now, in the deflationary economic environment we have, that standard of living WILL decrease. Whether it stays that way over time will depend on whether American consumers have the intestinal fortitude to spend more on American made products to employ other Americans (that - *gasp* - they don't already know!).
Not all products consumed by Americans will need to be made by Americans. However, I contend that a hell of a lot more products than are currently purchased by American consumers will have to be American in origin. If the value vs. cost comparison favors an imported product, so be it. This is NOT about dogma, protectionism and nationalism but it is simple truth.
For those products where American companies and workers can create huge amounts of VALUE, then American consumers owe it to themselves to pay the higher price (in exchange for that value). This is what will lead to rising incomes, rebuilding the hollowed out middle class, and along with other political and economic efforts, prevent the US from becoming the UK.
That's just a thought. Let me know what you think. For now, I'm going to bed.
Until next time...
The first consideration is that, for the US economy to have the kind of hiring that is required to rebuild (recreate?) the middle class, American companies are going to have to produce GOOD, if not AMAZING, products. Products that sell not only in the US but also to foreigners. In fact, I'd venture to say that foreign buyers will be more important to an economic recovery in the US than American buyers. A service based economy, serving only a domestic market at that, cannot support the level of GDP that will be required to employ as many people as required to resurrect the "middle class". Americans will have to make stuff - not just design stuff, not just create marketing and ideas, but actually implement and build physical products. Even if the products that US companies start producing are virtual goods - intellectual property, designs, etc. - the buyers will have to be overseas. That means whatever the products of the future are, they will need to be mindblowingly amazing! "Insanely great!" as Steve Jobs of Apple once said. They will have to solve real world problems at a huge level of value add/creation.
Second, for Americans to be employed by these companies in the numbers required by the population level, Americans will have to get used to higher prices. Why? Because if products are to be sold to American consumers, the prices will have to be high enough to allow people to make a so-called "living wage". Now, I personally have no problem paying more for a product if it provides value for me. (See Myth #5 here, this and this. Thanks Ramit!) However, as mentioned above, American products will need to be excellent values. Price is a lesser factor in considering the value that a product offers you, but the simple fact is that overall, Americans cannot be employed if they can't make enough to support themselves and their families.
For the last 2 decades, the emphasis has been on acquiring more stuff. That stuff became easier to acquire because manufacturing moved overseas, to Mexico, Central America, China, Vietnam or wherever. Now that conspicuous consumption is on life support, Americans will have to go back to living within their means, which is largely determined by income. So at both ends, the issue will need to be addressed. Consumers will need to save more and spend less overall, which they have started doing (but whether this will be permanent is to be determined). However, incomes have to be able to support a certain standard of living as well. For now, in the deflationary economic environment we have, that standard of living WILL decrease. Whether it stays that way over time will depend on whether American consumers have the intestinal fortitude to spend more on American made products to employ other Americans (that - *gasp* - they don't already know!).
Not all products consumed by Americans will need to be made by Americans. However, I contend that a hell of a lot more products than are currently purchased by American consumers will have to be American in origin. If the value vs. cost comparison favors an imported product, so be it. This is NOT about dogma, protectionism and nationalism but it is simple truth.
For those products where American companies and workers can create huge amounts of VALUE, then American consumers owe it to themselves to pay the higher price (in exchange for that value). This is what will lead to rising incomes, rebuilding the hollowed out middle class, and along with other political and economic efforts, prevent the US from becoming the UK.
That's just a thought. Let me know what you think. For now, I'm going to bed.
Until next time...
Subscribe to:
Posts (Atom)