Find the thread

On Friday I had the chance to sit down with Alf, of Alf’s Zoo fame. We had a great chat about automation, cloud and… cheese? You’ll just have to watch the show!

If you’re wondering about the art behind me, here are the two prints: Ski Pluto and Visit Mars. Both are by Steve Thomas. I had seen them linked ages ago and filed the bookmark, and when I was furnishing my home office in the new house I finally had somewhere to put them.

On a related note, every time I try to do something with Google Hangouts, I gain a better understanding of why WebEx has been so successful. Recording a ten-minute show took half an hour of futzing around. It’s one thing to do this if guest and host know each other already, but this would make a terrible first impression.

People keep talking about cloud as being, or needing to become, like a utility. The analogy is that users don't want to own a power station, they want to close a switch and have the light come on.

I love analogies, and I especially love following them to their logical conclusions - so that's what I'm going to do.

Let's look at an existing utility like electricity. At least in developed countries, it's true that users don't spend a lot of time worrying about the generation and transmission of electricity; they just turn on the light.

Businesses, however, can't afford to do that. The potential consequences of anything happening to disrupt the electricity supply are just too drastic, so businesses mitigate that risk with batteries and generators. Serious businesses test their equipment regularly to make sure their IT can keep operating for a while and shutdown gracefully if the electricity supply is ever interrupted.

The fact you have a contract for electricity to be delivered over the grid doesn't mean you don't need UPS and gensets on site, and Schneider Electric, Rolls-Royce, and many others are doing very well selling that sort of kit despite the fact that the electricity grid has been a reliable reality for decades now.

The same applies to cloud: even if you have a public cloud that is as reliable as the electricity grid - a high bar indeed! - you will still need some amount of private cloud for the services that absolutely cannot go down or be disrupted in any way.

Yesterday I wrote about how the value of private cloud is enabled by past inefficiencies: Hunting the Elusive Private Cloud. There is another side to that coin that's worth looking at. Vendors - especially, but not only, hardware vendors - made handsome profits catering to that inefficiency. If your datacenter utilisation rate is below 10%, then 90%+ of your hardware spending is… well, not quite wasted, but there are possible improvements there.

A decade or so ago, all the buzz was about virtualisation. Instead of running one physical server with low utilisation, we would put a number of virtual servers on the same bit of physical kit, and save money! Of course that’s not how it worked out, because the ease of creating new virtual servers meant that the things started multiplying like bunnies, and the poor sysadmins found themselves worse off, with even more servers to manage instead of fewer!

Now the promise of private cloud is that all the spare capacity can finally be put to good use. But what does this mean for the vendors who were relying on pushing all that extra tin?

Well, we don’t know yet. Most private cloud projects are, frankly, still at a very low level of maturity, so the impact on hardware sales is limited so far. One interesting indicator, though, is what happens as public cloud adoption ramps up.

Michael Coté, of 451 Research, flagged this (emphasis mine):

Buried in this piece on Cisco doing some public cloud stuff is this little description about how the shift to public cloud creates a strategic threat to incumbent vendors:

Cloud computing represented an interesting opportunity to equipment companies like Cisco, as it aggregated the market down to fewer buyers. There are approximately 1,500 to 2,000 infrastructure providers worldwide verses millions of businesses; reducing the buyers to a handful would lower the cost of sales. And, as cloud sales picked up, reducing on-premises equipment spending, those providers would represent an increasing share of sales and revenue.

The problem with this strategy, as companies like Cisco Systems and Juniper Networks discovered, is the exchange of on-premises buyers to cloud buyers is not one to one. Cloud providers can scale investments further than any individual enterprise or business buyer, resulting in a lower need for continually adding equipment. This phenomenon is seen in server sales, which saw unit shipments fall 6 percent last year and value fall nearly twice as fast.

Even if we assume that a company offloading some servers to the public cloud instead of buying or replacing them in its own datacenter is doing so on a 1:1 basis - one in-house physical server replaced by one virtual server in the public cloud - the economics mean that the replacement will be less profitable for the equipment vendor. The public cloud provider will be able to negotiate a much better price per server because of their extremely high purchasing volume - and this doesn’t even consider the mega-players in cloud, who build their own kit from scratch.

Since I mentioned Cisco, though, I should point out that they seem to be weathering the transition better than most. According to Forrester’s Richard Fichera, Cisco UCS at five years is doing just fine:

HP is still number one in blade server units and revenue, but Cisco appears to be now number two in blades, and closing in on number three world-wide in server sales as well. The numbers are impressive:

• 32,000 net new customers in five years, with 14,000 repeat customers

• Claimed $2 Billion+ annual run-rate

• Order growth rate claimed in "mid-30s" range, probably about three times the growth rate of any competing product line.

To me, it looks like the UCS server approach of very high memory density works very well for customers who aren’t at the level of rolling their own servers, but have outgrown traditional architectures. Let’s see what the next five years bring.

While I work for a cloud management vendor, the following represents my personal opinion - which is why it’s published here and not at my work blog.

It seems that in IT we spend a lot of time re-fighting the same battles. The current example is "private cloud is not a cloud".

Some might expect me to disagree, but in fact I think there’s more than a grain of truth in that assertion. The problem is in the definition of what is a cloud in the first place.

If I may quote the NIST definition yet again: (revs up motorcycle, lines up on shark tank)

On-demand self-service. A consumer can unilaterally provision computing capabilities, such as server time and network storage, as needed automatically without requiring human interaction with each service provider.
Broad network access. Capabilities are available over the network and accessed through standard mechanisms that promote use by heterogeneous thin or thick client platforms (e.g., mobile phones, tablets, laptops, and workstations).

Resource pooling. The provider’s computing resources are pooled to serve multiple consumers using a multi-tenant model, with different physical and virtual resources dynamically assigned and reassigned according to consumer demand. There is a sense of location independence in that the customer generally has no control or knowledge over the exact location of the provided resources but may be able to specify location at a higher level of abstraction (e.g., country, state, or datacenter). Examples of resources include storage, processing, memory, and network bandwidth.

Rapid elasticity. Capabilities can be elastically provisioned and released, in some cases automatically, to scale rapidly outward and inward commensurate with demand. To the consumer, the capabilities available for provisioning often appear to be unlimited and can be appropriated in any quantity at any time.

Measured service. Cloud systems automatically control and optimize resource use by leveraging a metering capability at some level of abstraction appropriate to the type of service (e.g., storage, processing, bandwidth, and active user accounts). Resource usage can be monitored, controlled, and reported, providing transparency for both the provider and consumer of the utilized service.

The item most people point to when making the claim that "private cloud is not a cloud" is the fourth in that list: elasticity. Public clouds have effectively infinite elasticity for any single tenant: even Amazon itself cannot saturate AWS. By definition, private cloud does not have infinite elasticity, being constrained to whatever the capacity of the existing datacenter is.

So it’s proved then? Private cloud is indeed not a cloud?

Not so fast. There are two very different types of cloud user. If you and your buddies founded a startup last week, and your entire IT estate is made up bestickered MacBooks, there is very little point in looking at building a private cloud from scratch. At least while you are getting started and figuring out your usage patterns, public cloud is perfect.

However, what if you are, say, a big bank, with half a century’s worth of legacy IT sitting around? It’s all very well to say "shut down your data centre, move it all to the cloud", but these customers still have mainframes. They’re not shuttering their data centres any time soon, even if all the compliance questions can be answered.

The reason this type of organisation might want to look at private cloud is that there’s a good chance that a substantial proportion of that legacy infrastructure is under- or even entirely un-used. Some studies I’ve seen even show average utilisation below 10%! This is where they get their elasticity: between the measured service and the resource pooling, they get a much better handle on what that infrastructure is currently used for. Over time, private cloud users can then bring their average utilisation way up, while also increasing customer satisfaction.

Each organisation will have its own utilisation target, although 100% utilisation is unlikely for a number of reasons. In the same way, each organisation will have its own answer as to what to do next: whether to invest in additional data centre capacity for their private cloud, or to add public cloud resources to the mix in a hybrid model.

The point remains though that private cloud is unquestionably "real" and a viable option for these types of customers. Having holy wars about it among the clouderati is entertaining, but ultimately unhelpful.

No, it’s not what you think… Here "unicorns" are guru-level sysadmins, difficult to find in the wild when you really need them.¹

The Register says:

The rise of the cloud is wiping out the next generation of valuable sysadmins as startups never learn about how to manage data-center gear properly

The thesis goes like this: in the old, pre-AWS days (can you believe that’s only eight years ago?) you and your friends would start a company and code up a demo on your be-stickered MacBooks at the local independent coffee shop. Once you had your demo, you would take it to VCs in order to get funding to buy some servers, host them in a data center somewhere, and start building your infrastructure. This would require professional sysadmins who would gain experience taking a tool to production scale, and so there was good availability of sysadmins who had that experience.

Nowadays, those be-stickered MacBooks might represent the entire IT estate of a startup. Everything else runs in the cloud somewhere - probably in AWS. Now this is great from some points of view: by definition, startups don’t know what their adoption rate is going to be, so having AWS’ effectively infinite pool of capacity to fall back on is very useful in case they get Slashdotted² one day. Vice versa, they don’t get stuck paying the bills for an oversized data center if take-off turns out to require a bit more time than they had initially hoped.

So far, so good. The problem is when that startup’s business has more or less stabilised, and they would like to move the more predictable parts of their infrastructure from expensive AWS³ to more traditional infrastructure. They do not have the skills in-house to do this because they have never needed to develop them, so they need to hire sysadmins in a hurry.

This pattern has played out at numerous startups, including ephemeral messaging service Snapchat which started life on Google App Engine and then hired away senior Google cloud employee Peter Magnusson to help it figure out how to move bits of its workload off the cloud.

Similarly, backend-as-a-service company Firebase started out life on a major public cloud but had to shift to bare-metal servers after it ran into performance issues.

Now, if you’re in the position to hire senior Google employees in a hurry, then your startup is doing well and I congratulate you. However, what about all the other startups without the sort of public profile that Snapchat enjoys?

Draining the sysadmin talent pool is a real problem because there is no straight career path to get there. Sysadmins have be talented generalists, able to work at different levels of abstractions, pivot rapidly in response to changing technological realities, and react quickly to tactical requests while working towards strategic objectives. You can’t get a degree in any of that, you need to learn by doing. I know, I’ve been there, done that, got the T-shirt⁴. I caused my mentors a certain number of headaches during the learning process, but I came out of it with valuable experience. Ultimately my poor timing meant that the bubble burst, sysadmins jobs were in short supply, and I had to take my career in different directions, although a certain generalist/tinkerer aspect has been a constant.

Also, sysadmin knowledge is pretty specific. Even if you are able to find a Linux guru who has done it all, partied with Linus and argued ESR to a standstill, it will still take some time to get them hired and up to speed in your environment. Congratulations: now your inability to hire and onboard sysadmins more rapidly is a bottleneck on your business growth. A slowdown in growth is NOT what you want in a startup. You want a nice steep growth curve, with no interruptions or even temporary flattenings.

I suspect many business models include an unspoken assumption of "and then we’ll open our own datacenter". Not many people appear to be thinking about the business risk involved in that step, especially the human factors.

Note: I am absolutely not advocating staying away from the public cloud! If a workload is bursty and unpredictable, as most startups are by definition, the public cloud is a very good fit. The same applies to traditional enterprises operating services with those characteristics - even if they have some cultural obstacles to adopting the cloud. On the other hand, a static repository of large binaries, say, or a service with extensive compliance requirements, may well be better off on more traditional infrastructure.

If the premise of the article is true, and traditional sysadmins skills are becoming more rare, it may be tougher than expected to transition to a traditional on-premise or managed-hosting model. Business plans and product roadmaps will need to allow for both the technical aspects and the business risk aspects.

If you are lucky enough to have generalists around, don’t try to pigeonhole them. Look after your sysadmins, and they’ll look after you.

In one of those displays of serendipity, I just finished reading this article over my lunch break. It seems the problem is not limited to IT, but is generalised throughout the economy.

A generalised problem would seem to be harder to solve, but in IT we pride ourselves on being able to break these sorts of deadlocks. What is the solution that combines short-term benefits with long-term ones to the detriment of neither?

Cross-posted to my work blog and to Linkedin

If there has been one overarching theme of the last few years in IT, it has been the changing relationship between enterprise IT departments and the users that they support.

Users have always wanted more IT faster, and this has always driven advances in the field. Minicomputers were the shadow IT of their day, democratising access to computing that had previously been locked up in mainframes. (By the way, did you know that the mainframe is fifty years young and still going strong?)

Departments would purchase their own minicomputers to avoid having to share time on the big corporate machines with others. This new breed of machine introduced application compatibility for the first time. In other words, it was no longer necessary to program for a specific machine. Higher-level languages also made that task of programming much easier.

Microcomputers and personal desktop computers were the next step in that evolution. At this stage it became feasible for people to have their own personal machine and run their own tasks in their own time, and for a while IT departments lost much of their control. The arrival of computer networks swung the balance the other way, until the widespread adoption of mobile devices started the swing back again.

Seen in this way, cloud computing is just the latest move in a long dance. The tempo is increasing, however, and it becomes more critical to make the right moves.

One make-or-break move is the very first public one, when a company decides to shift at least some of its workloads to the public cloud. It’s important to remember that Amazon was not designed to be traditional IT and trying to treat it that way is a route to failure.

To get an idea of the sort of problems we want to avoid, here’s an example from a completely different domain. If you have ever furnished a house or a flat, the odds are good that you have wandered around IKEA, feeling lost and disoriented, and possibly having a furious argument with your significant other as well.

Assuming the shopping trip didn’t end in mayhem and disaster - and personally I always count it as a success when I get out of IKEA without either of those - you may well have bought an Expedit shelving unit. The things are ubiquitous, together with their cousins, the Billy shelving units. I should know, I own both.

The bad news is, IKEA is discontinuing the Expedit and replacing it with a slightly different unit, the Kallax. This has infuriated customers who liked being able to replace or extend their existing furniture with additional bits.

What has this got to do with IT? What IKEA has done is break backwards compatibility in their products: you can no longer just get "more of the same", and unless you are furnishing an entire new home, you will probably have to deal with both the old and the new model at the same time.

Enterprise IT departments are facing the same problem with cloud computing. They want to take advantage of the fantastic capabilities of this new model, but they need to do it without breaking the things that are working for their users today. They don’t have the luxury that startups do of engineering their entire operation from the ground up for cloud. They have a history, and all sorts of things that are built on top of that history.

On the other hand, they can’t just treat a virtual server in the public cloud as being the same as the physical blade server humming away in their datacenter. For a start, much of the advantage of the public cloud is based around a fundamentally different operating model. It has been said that servers used to be pets, given individual names, pampered and hand-reared, while in the cloud we treat them like cattle, giving them numbers and putting them down as soon as it’s convenient.

The public cloud is great, but it works best for certain workloads. On the other hand, there are plenty of workloads that are still better off running on-premises, or even (gasp!) directly on physical hardware. The trick is knowing the difference, and managing your entire IT estate that way.

This is part and parcel of BMC’s New IT: make it easy for users to get what they need, when they need it. To find out more about what BMC can do to make your cloud initiative successful, please visit www.bmc.com/cloud.

Cross-posted to my work blog

There's an old joke that in China, it's just food. The main thing that will happen in 2014 is that it will be just computing.

Cloud has gone mainstream. Nobody, whether start-up or enterprise, can afford to ignore cloud-based delivery options. In fact, in many places it's now the default, which can lead to its own problems.

The biggest change in 2014 is the way in which IT is being turned inside out. Whereas before the rhythm of IT was set by operations teams, now the tempo comes from users, developers, and even outside customers. IT operations teams had always relied on being able to set their own agenda, making changes in their own time and drawing their own map of what is inside or outside the perimeter.

The new world of IT doesn't work like that. It's a bit like when modern cities burst their medieval walls, spreading into what had been fields under the walls. The old model of patrolling the walls, keeping the moat filled and closing the gates at night was no longer much use to defend the newly sprawling city.

New strategies were required to manage and defend this new sort of city, and new approaches are required for IT as well.

One of my first customer meetings of 2014 brought a new term: "polyglot management". This is what we used to call heterogeneous management, but I think calling it polyglot may be more descriptive. Each part of the managed infrastructure speaks its own language, and the management layer is able to speak each of those languages to communicate with the infrastructure.

That same customer meeting confirmed to me that the polyglot cloud is here to stay. The meeting was with a customer of many years's standing, a bank with a large mainframe footprint as well as distributed systems. The bank's IT team had always tried to consolidate and rationalise their infrastructure, limiting vendors and platforms, ideally to a single choice. Their initial approaches to cloud computing were based on this same model: pick one option and roll it out everywhere.

Over time and after discussions with both existing suppliers and potential new ones, the CTO realised that this approach would not work. The bank would still try to limit the number of platforms, but now they are thinking in terms of two to three core platforms, with the potential for short-term use of other platforms on a project basis.

When a team so committed to consolidation adopts the heterogeneous, polyglot vision, I think it's safe to say that it's a reality. They have come down from their walls and are moving around, talking to citizens/users and building a more flexible structure that can take them all into the future.

This is what is happening in 2014. Cloud is fading into the background because it’s everywhere. It's just... computing.

Image by Kelly Sikkema via Unsplash

Cloud computing is getting to be pretty universal, but there is still an assumption in certain quarters that it’s only for startups, especially public cloud. As the market matures, however, that position gets less and less tenable. If the CIA can work things out to run (some of) their applications on Amazon, despite IBM’s best efforts, surely most companies should be able to take advantage of the cloud, right?

Well, apparently b
anks should never use the cloud, according to ComputerWorld. The post includes this quote, admittedly not from the author but "

an unnamed source within banking IT":

I would not bank with a firm using the cloud to operate my account or hold my details.

In one of those moments of serendipity, the last customer I spoke to was in fact a bank¹, and they wanted to discuss not only how they could move to private cloud, but how they could run some services in the public cloud and even become a cloud provider themselves for some of their customers.

This bank has been a customer for a very long time, with a large mainframe footprint and a good amount of distributed systems as well. In what is a fairly typical story, their IT environment is quite balkanised, which makes it hard for them to get a good view of what is going on, let alone enforce and document standards and best practices in a uniform manner.

Obviously introducing cloud into this mix would just risk creating yet another silo; it’s silos all the way down. What the bank is after is unified management, that will span across all their diverse technologies and let them deliver a high level of IT service to their users.

A key part of managing this sort of heterogeneous environment is knowing what goes where. The example ComputerWorld’s unnamed source uses of cash machines running in the public cloud or something is a perfect counter-example. The idea is to run payment systems and such on extremely reliable systems, almost certainly in-house. However, that sort of infrastructure gets expensive, not to mention the time taken to harden it, audit it regularly, and keep it secure over time. So why use the exact same standard for a marketing web site? Stick that in the public cloud! Put internal development systems on a free hypervisor to save license costs, and so on.

At AWS re:Invent we had two customers¹ from the banking industry in the booth with us. Remember, that’s banks who are not just using private cloud internally, but actually deploying services to AWS. The reason they were there is to explain how they were not deploying anything willy-nilly to AWS, but setting and enforcing policies.

The cloud is a tool. All you need to do is use it right.

Image by Martin Wessely via Unsplash

Working in cloud computing is extremely frustrating. Nobody outside the field understands what you do no matter how much you try to explain, and everybody in it thinks they already do before you get a chance to explain.

One of my favourite metaphors to try to break this impasse is to talk about fleets of aircraft. The Bad Old Way of doing things in IT is a bit like a company operating a huge fleet of private jets, one for each employee that ever needs to travel anywhere. Obviously extravagant and impractical, right? The planes are idle for much of the time while the people are doing whatever they travelled to do, and you can't easily make them bigger if you need to transport a larger team somewhere. The thing is, that's pretty much how we all approached IT until not so long ago: each workload got its own dedicated infrastructure, which was idle much of the time and very difficult to resize or reassign in response to changing requirements. Virtualization didn't really help, except as a band-aid over the problem.

Cloud computing is more like having lots of different commercial carriers, each with different classes of service, routes, amenities and other offerings, with passengers (workloads) choosing supplier and service based on their requirements of the moment.

As much as it is about anything, cloud computing is about impermanence. When you buy physical hardware, you own it, it's right there. The canonical definition of hardware is "the part that you can kick". (Software, then, is the part that makes you want to kick the hardware.) These days, people who like their IT to be tangible are disparaged as "server huggers". The whole point of cloud computing is that if something breaks you don't worry about trying to fix it, you just get a new one, which will be the same as the original. Randy Bias coined the phrase "cattle, not pets": you don't give the servers names and pamper them as individuals, you give them numbers and put them down as soon as it's convenient.

The dark side of this impermanence, though, is: what happens to the data in this new world of transience? When your cloud provider shuts down, what happens to everything that you entrusted them with over the years? What happens when data disappears?

It’s a nightmare for libraries. What do you do if you’re given a chunk of priceless digital manuscripts - stored on totally obsolete media? The trove might include video games by Timothy Leary and digital drawings by Keith Haring, or versions of famous Broadway shows, or, well, anything really.

On the other hand, the cloud can also be the solution. If you need to read a document created on some obsolete system that you no longer own or can even buy, perhaps you can emulate it in the cloud. JSMESS is a project to port the MESS emulator to Javascript so that it will run in a browser. Right now it will emulate thirty-year-old kit with middling results, but as is the way of things, I have little doubt that before too long it will be able to emulate Windows 95 running Word Whatever.

Why do you care? We are now living through what will doubtlessly be known as a Dark Age to future historians. A relative of mine wrote a book about his experiences in South Africa around the turn of the Twentieth Century. I doubt there are many copies around, but the family has one, and so I was able to read about how my relative was there for the founding of some of the institutions of modern South Africa, and his efforts to make it a better place.

It is very hard to imagine that happening today. Nobody keeps a physical written diary that could be found in an attic, we write about our daily experiences on Facebook. Even when we do have local documents, they are saved in particular formats that will be very difficult or impossible to read a handful of years from now, never mind a century on. Version requirements, compatibility and dependencies, not to mention digital rights management, will see to that.

Imagine though if you come across a trove of Grandpa's ancient backups, and you could boot something up right in your browser to read them. You might solve that inheritance dispute, or smile at his old love letters to Grandma.

Imagine if you're in charge of a business and you suddenly realise you can't access your documents that are more than a few years old. What does that do to your billing, your credibility, not to mention your legal liability? Sure, you can print everything off and ship it to Iron Mountain or wherever, but the latency on accessing data held in that kind of facility would give your average Millenial conniptions.

If you're a developer or a provider building something for the cloud - which these days means all providers and developers who plan to be around more than a couple of years from now - take this into account. How do users get at their stuff tomorrow, even if you're not around? Sure, you're busy building something cool, but this is foundational. If you build it right, ensuring accessibility in the future should be easy. If it looks too hard, you're probably doing something else wrong.

If you're a user of cloud services - and once again, that pretty much means "a user" - try to take a moment to look into getting your data back. If I store my photos here, how can I download them? If I create a blog there, how can I save my posts? If my business relies on a certain service, what is my emergency spare backup plan if that service goes away or simply changes in a way that breaks it for me?

You can't rely on the Archive Team to do it for you. If you want permanence, it takes a moment of effort.

Image by Joeri Romer via Unsplash

One of the questions raised as a part of the PRISM discussion has been the impact on the internet and specifically cloud computing industries. For instance, Julie Craig of EMA wrote a post titled "PRISM: The End of the Cloud?"

I think these fears are a bit overblown. While there will probably be some blowback, most of the people who care about this sort of thing were already worried enough about the Patriot Act without needing to know more about PRISM. I think the number of people who will start to care about privacy and data protection as a result of PRISM will be fairly small. All Things D's Joy of Tech cartoonnailed it, as usual.

The same kind of thing applies in business. Many companies don't really care very much either way about the government reading their files. They might get more exercised about their competitors having access, but apart from perhaps some financial information, the government is low down the list of potential threats.

Of course, most analysis focuses on the question of US citizens and corporations using US services. What happens in the case of foreign users, whether private or corporate, using US services? There has been some overheated rhetoric on this point as well, but I don't think it's a huge factor. Much like Americans, people in the rest of the world already knew about the Patriot act, and most of them voted with their feet, showing that they did not care. As for corporations, most countries have their own restrictions on what data can be stored, processed or accessed across borders, quite possibly to make it easier to run their own versions of PRISM, so companies are already pretty constrained in terms of what they could even put into these US services.

For companies already using the public cloud or looking into doing so, this is a timely reminder that not all resources are created equal, and that there are factors beyond the purely technical and financial ones that need to be considered. The PRISM story might provide a boost for service providers outside the US, who can carve out a niche for themselves as giving the advantages of public cloud, but in a local or known jurisdiction. This could mean within a specific country, within a wider region such as the EU, or completely offshore. Sealand may have been ahead of its time, but soon enough there must emerge a "Switzerland of the cloud". The argument that only unsavoury types would use such a service doesn't really hold water, given that criminals already have the Russian Business Network and its ilk.

Bottom line, PRISM is nothing new, and it doesn't really bring any new facts. Given the Patriot Act, the sensible assumption had to be that the US government was doing something like this - and so were other technologically sophisticated governments around the world. The only impact it might have is in perception, if it blows up into a big enough story and stays around for long enough. In terms of actual rational grounds for decision-making, my personal expectation is for impact to be extremely limited.