Smart cities come in all shapes and sizes. There is not one definition of smart. Think about the terms “street smart” and “book smart.” When I think about the initiatives or reforms that we’re seeing across cities, I’ve started categorizing them along these lines. New initiatives like sensor-based parking and traffic optimization fall into street smart, while streamlining of back office processes and applications tend to be more book smart. And as we know, it takes all kinds.
The hype of smart cities, however, has focused on the sexy new kid on the block. Everything sensor-based and “intelligent” has gotten top billing from vendors. However, many cities need to start cracking the books first.
Here are a few ways to start:
Rationalization of back office applications. Sprawling or at least siloed IT infrastructure and business apps can be upgraded and consolidated. Several CIOs I’ve spoken with have mentioned that this is a big challenge. Department heads don’t want to give up control over their domain, as they see it. Big cities find themselves with multiple enterprise resource planning (ERP) systems running across different departments in a city: Parks and Recreation licenses ERP from one vendor; Public Works subscribes to ERP services from another; Transportation manages their fleet with yet another.
We have been repeatedly reminded that the requirements of hyper-scale cloud properties are different from those of the mainstream enterprise, but I am now beginning to suspect that the top strata of the traditional enterprise may be leaning in the same direction. This suspicion has been triggered by the combination of a recent day in NY visiting I&O groups in a handful of very large companies and a number of unrelated client interactions.
The pattern that I see developing is one of “haves” versus “have nots” in terms of their ability to execute on their technology vision with internal resources. The “haves” are the traditional large sophisticated corporations, with a high concentration in financial services. They have sophisticated IT groups, are capable fo writing extremely complex systems management and operations software, and typically own and manage 10,000 servers or more. The have nots are the ones with more modest skills and abilities, who may own 1000s of servers, but tend to be less advanced than the core FSI companies in terms of their ability to integrate and optimize their infrastructure.
The divergence in requirements comes from what they expect and want from their primary system vendors. The have nots are companies who understand their limitations and are looking for help form their vendors in the form of converged infrastructures, new virtualization management tools, and deeper integration of management software to automate operational tasks, These are people who buy HP c-Class, Cisco UCS, for example, and then add vendor-supplied and ISV management and automation tools on top of them in an attempt to control complexity and costs. They are willing to accept deeper vendor lock-in in exchange for the benefits of the advanced capabilities.
I recently had an opportunity to spend some time with SUSE management, including President and General Manager Nils Brauckmann, and came away with what I think is a reasonably clear picture of The Attachmate Group’s (TAG) intentions and of SUSE’s overall condition these days. Overall, impressions were positive, with some key takeaways:
TAG has clarified its intentions regarding SUSE. TAG has organized its computer holdings as four independent business units, Novell, NetIQ, Attachmate and SUSE, each one with its own independent sales, development, marketing, etc. resources. The advantages and disadvantages of this approach are pretty straightforward, with the lack of opportunity to share resources aiming the business units for R&D and marketing/sales being balanced off by crystal clear accountability and the attendant focus it brings. SUSE management agrees that it has undercommunicated in the past, and says that now that the corporate structure has been nailed down it will be very aggressive in communicating its new structure and goals.
SUSE’s market presence has shifted to a more balanced posture. Over the last several years SUSE has shifted to a somewhat less European-centric focus, with 50% of revenues coming from North America, less than 50% from EMEA, and claims to be the No. 1 Linux vendor in China, where it has expanded its development staffing. SUSE claims to have gained market share overall, laying claim to approximately 30% of WW Linux market share by revenue.
Focus on enterprise and cloud. Given its modest revenues of under $200 million, SUSE realizes that it cannot be all things to all people, and states that it will be focusing heavily on enterprise business servers and cloud technology, with less emphasis on desktops and projects that do not have strong financial returns, such as its investment in Mono, which it has partnered with Xamarin to continue development,.
I don’t understand why firms spend millions of dollars on Java application servers like Oracle Weblogic or IBM WebSphere Application Server. I get why firms spend money on Red Hat JBoss -- they want to spend less on application servers. But, why spend anything at all? Apache Tomcat will satisfy the deployment requirements of most Java web applications.
Your Java Web Applications Need A Safe, Fast Place To Run
Most Java applications don’t need a fancy container that has umpteen features. Do you want to pay for a car that has windshield wipers on the headlights? (I wish I could afford it.) Most Java applications do not need these luxuriant features or can be designed not to need them. Many firms do, in fact, deploy enterprise-class Java web applications on Apache Tomcat. It works. It is cheap. It can save tons of dough.
Expensive Java Application Servers Sometimes Add Value
There is a need for luxury. But, you probably don’t need it to provide reliable, performant, and scalable Java web applications. Application server vendors will argue that:
You need an application container that supports EJBs. EJB3 fixed the original EJB debacle, but why bother? Use Spring, and you don’t need an EJB-compliant container. Many applications don’t even need Spring. EJBs are not needed to create scalable or reliable applications.
Not to be left out of the announcement fever that has gripped vendors recently, Cisco today announced several updates to their UCS product line aimed at easing potential system bottlenecks by improving the whole I/O chain between the network and the servers, and improving management, including:
Improved Fabric Interconnect (FI) – The FI is the top of the UCS hardware hierarchy, a thinly disguised Nexus 5xxx series switch that connects the UCS hierarchy to the enterprise network and runs the UCS Manager (UCSM) software. Previously the highest end FI had 40 ports, each of which had to be specifically configured as Ethernet, FCoE, or FC. The new FI, the model 6248UP has 48 ports, each one of which can be flexibly assigned as up toa 10G port for any of the supported protocols. In addition to modestly raising the bandwidth, the 6248UP brings increased flexibility and a claimed 40% reduction in latency.
New Fabric Extender (FEX) – The FEXC connects the individual UCS chassis with the FI. With the new 2208 FEX, Cisco doubles the bandwidth between the chassis and the FI.
VIC1280 Virtual Interface Card (VIC) – At the bottom of the management hierarchy the new VIC1280 quadruples the bandwidth to each individual server to a total of 80 GB. The 80 GB can be presented as up to 8 10 GB physical NICs or teamed into a pair fo 40 Gb NICS, with up to 256 virtual devices (vNIC, vHBA, etc presented to the software running on the servers.
HP this week really stirred up the Converged Infrastructure world by introducing three new solution offerings, one an incremental evolution of an existing offering and the other two representing new options which will put increased pressure on competitors. The trio includes:
HP VirtualSystem - HP’s answer to vStart, Flex Pod and vBlocks, VirtualSystem is a pre-integrated stack of servers (blade and racked options), HP network switches and HP Converged Storage (3Par and Left Hand Networks iSCSI) along with software, including the relevant OS and virtualization software. Clients can choose from four scalable deployment options that support up to 750, 2500 or 6000 virtual servers or up to 3000 virtual clients. It supports Microsoft and Linux along with VMware and Citrix. Since this product is new, announced within weeks of the publication of this document, we have had limited exposure it, but HP claims that they have added significant value in terms of optimized infrastructure, automation of VM deployment, management and security. In addition, HP will be offering a variety of services and hosting options along with VirtualSystem. Forrester expects that VirtualSystem will change the existing competitive dynamics and will result in a general uptick of interest it similar solutions. HP is positioning VirtualSystem as a growth path to CloudSystem, with what they describe as a “streamlined” upgrade path to a hybrid cloud environment.
When Cisco began shipping UCS slightly over two years ago, competitor reaction ranged the gamut from concerned to gleefully dismissive of their chances at success in the server market. The reasons given for their guaranteed lack of success were a combination of technical (the product won’t really work), the economics (Cisco can’t live on server margins) to cultural (Cisco doesn’t know servers and can’t succeed in a market where they are not the quasi-monopolistic dominating player). Some ignored them, and some attempted to preemptively introduce products that delivered similar functionality, and in the two years following introduction, competitive reaction was very similar – yes they are selling, but we don’t think they are a significant threat.
Any lingering doubt about whether Cisco can become a credible supplier has been laid to rest with Cisco’s recent quarterly financial disclosures and IDC’s revelation that Cisco is now the No. 3 worldwide blade vendor, with slightly over 10% of worldwide (and close to 20% in North America) blade server shipments. In their quarterly call, Cisco revealed Q1 revenues of $171 million, for a $684 million revenue run rate, and claimed a booking run rate of $900 million annually. In addition, they placed their total customer count at 5,400. While actual customer count is hard to verify, Cisco has been reporting a steady and impressive growth in customers since initial shipment, and Forrester’s anecdotal data confirms both the significant interest and installed UCS systems among Forrester’s clients.
Entering into a new competitive segment, especially one dominated by major players with well-staked out turf, requires a level of hyperbole, dramatic positioning and a differentiable product. Cisco has certainly achieved all this and more in the first two years of shipment of its UCS product, and shows no signs of fatigue to date.
However, Cisco’s announcement this week that it is now part of Microsoft’s Fast Track Data Warehouse and Fast Track OLTP program is a sign that UCS is also entering the mainstream of enterprise technology. The Microsoft Fast Track program, offering a set of reference architectures, system specification and sizing guides for both common usage scenarios for Microsoft SQL Server, is not new, nor is it in any way unique to Cisco. Fast Track includes Dell, HP, IBM, and Bull. The fact that Cisco will now get equal billing from Microsoft in this program is significant – it is the beginning of the transition from emerging fringe to mainstream , and an endorsement to anyone in the infrastructure business that Cisco is now appearing on the same stage as the major incumbents.
Will this represent a breakthrough revenue opportunity for Cisco? Probably not, since Microsoft will be careful not to play favorites and will certainly not risk alienating its major systems partners, but Cisco’s inclusion on this list is another incremental step in becoming a mainstream server supplier. Like the chicken soup that my grandmother used to offer, it can’t hurt.
Since Oracle dropped their bombshell on HP and Itanium, I have fielded multiple emails and about a dozen inquiries from HP and Oracle customers wanting to discuss their options and plans. So far, there has been no general sense of panic, and the scenarios seem to be falling into several buckets:
The majority of Oracle DB/HP customers are not at the latest revision of Oracle, so they have a window within which to make any decisions, bounded on the high end by the time it will take them to make a required upgrade of their application plus DB stack past the current 11.2 supported Itanium release. For those customers still on Oracle release 9, this can be many years, while for those currently on 11.2, the next upgrade cycle will cause a dislocation. The most common application that has come up in inquiries is SAP, with Oracle’s own apps second.
Customers with other Oracle software, such as Hyperion, Peoplesoft, Oracle’s eBusiness Suite, etc., and other ISV software are often facing complicated constraints on their upgrades. In some cases decisions by the ISVs will drive the users toward upgrades they do not want to make. Several clients told me they will defer ISV upgrades to avoid being pushed into an unsupported version of the DB.
A lot has been written about potential threats to Intel’s low-power server hegemony, including discussions of threats from not only its perennial minority rival AMD but also from emerging non-x86 technologies such as ARM servers. While these are real threats, with potential for disrupting Intel’s position in the low power and small form factor server segment if left unanswered, Intel’s management has not been asleep at the wheel. As part of the rollout of the new Sandy Bridge architecture, Intel recently disclosed their platform strategy for what they are defining as “Micro Servers,” small single-socket servers with shared power and cooling to improve density beyond the generally accepted dividing line of one server per RU that separates “standard density” from “high density.” While I think that Intel’s definition is a bit myopic, mostly serving to attach a label to a well established category, it is a useful tool for segmenting low-end servers and talking about the relevant workloads.
Intel’s strategy revolves around introducing successive generations of its Sandy Bridge and future architectures embodied as Low Power (LP) and Ultra Low Power (ULP) products with promises of up to 2.2X performance per watt and 30% less actual power compared to previous generation equivalent x86 servers, as outlined in the following chart from Intel:
So what does this mean for Infrastructure & Operations professionals interested in serving the target loads for micro servers, such as: