Why Public Clouds are More Secure than Private Clouds

Document ID: | Document Type: ZapFlash
By: Jason Bloomberg | Posted: February 7, 2012

Conventional wisdom would have you believe that Public Clouds are inherently insecure, and that the only way to meet your organization’s stringent security requirements in the Cloud is to implement your own Private Cloud. Conventional wisdom, you say? Unfortunately, there is precious little wisdom available of any kind when it comes to Cloud Computing, let alone the conventional type!

In fact, large software and hardware vendors are largely responsible for the whole “Public Cloud is insecure” canard, introducing fear, uncertainty, and doubt (FUD) into the marketplace. After all, building a Private Cloud means buying a lot of new gear. The last thing the big vendors want is for their customers to move to Public Clouds—unless, of course, they belong to the vendor in question. Don’t be fooled. Public Clouds are typically more secure than Private Clouds, for a number of reasons. Here’s why.

Why Public Clouds are More Secure…

• Hardened thru continual hacking attempts – Public Cloud providers are a juicy target. Hackers know how to find them, realize there’s good stuff inside, and would be the envy of all their hacker pals if they were able to breach the Public Cloud’s defenses. As a result, h4x0r types have been hammering on Amazon Web Services, Microsoft Azure, and all the others. Thousands of them. For years now.

• Attract the best security people available – Public Cloud providers not only attract hackers, they attract talent. If you’re a top Cloud security expert, where would you rather work: Amazon? Or some big insurance company or manufacturer or government agency? I thought so.

• Get the latest security gear due to economies of scale – How many Cloud data centers do the big Public Cloud providers own? And how fast are they building new ones? You don’t need to know the specifics to realize the answers are boatloads and wicked fast. And they’re buying gear for them. New gear. Boatloads of it. Wicked fast.

Why Private Clouds are Less Secure…

• Suffer from “perimeter complacency” – it’s amazing how many enterprises think that their DMZs and firewalls give them adequate security. If it’s on the internal network, it must be secure! As though they completely missed the Internet. And email. Not to mention viruses. What about twenty-somethings downloading malware to the corporate network through their phones? Now the enterprise wants a Private Cloud, so they can put the whole kit and caboodle on their internal network for security purposes. Good luck with that.

• Unknown staff competence – sure, your organization has a lot of great security people. They all know their stuff. Try this: have a big party for them. Two hours in, take a look around the room. See that guy with the lampshade on his head? He’s responsible for Private Cloud security.

• Insufficient penetration testing – how do you test to make sure your Private Cloud is secure—or any other part of your IT infrastructure, for that matter? Simple: have your testers run a series of security tests. Or maybe hire a third party to run them for you. If all the tests pass, you’re secure, right? Maybe for like a minute, until the hackers figure out new attacks that didn’t make it into your security tests. Whoops.

• May have older gear in use – you spent hundreds of thousands of dollars on security hardware. In 2009. Now you’re putting the final touches on your Private Cloud. Try this: ask your CIO for hundreds of thousands of dollars more to replace that three-year-old gear. The response? Maybe next year. Try updating the patches. I’m sure you can make do with what we have. And maybe you can—but don’t expect it to compare with the brand new shiny stuff going into Public Cloud data centers every day.

Virtual Private Clouds to the Rescue?

With a Virtual Private Cloud (VPC), a Public Cloud provider gives you a dedicated, secure connection (usually via a VPN) to your Public Cloud instances. In some cases, those instances are physically separated from other customers, so that your stuff can’t end up on the same box as somebody else’s stuff.

VPCs may actually be the most secure option available today, as you have the best of both worlds. Furthermore, they may address specific regulatory or other governance issues that may prevent your organization from using a multitenant Public Cloud. If you read the first section of this ZapFlash and think that neither Public nor Private sounds secure enough, then a VPC may be the way to go.

However, VPCs aren’t for everyone. They may only be marginally more secure than Public Cloud, as Public Cloud providers have generally done a bang-up job securing their multitenant architectures. And keep in mind, a single-tenant VPC will typically be substantially more expensive than a regular Public Cloud equivalent. The bottom line: VPCs are more about peace of mind than actually increasing security.

The ZapThink Take

You’ll have to excuse me, I’m in a particularly snarky mood today. I must admit that the title of this ZapFlash is actually an overgeneralization. It’s certainly possible that your Private Cloud is more secure than some Public Clouds out there. The true message of this article is that building a truly secure Private Cloud is much harder than it sounds, and the extra work necessary has largely already been taken care of by the Public Cloud providers. And it should now be obvious that Private Clouds are by no means inherently more secure than Public ones.

But there’s a bigger lesson here. Security is all about risk mitigation, and it’s simply impossible to reduce your risk to zero. There’s no such thing as perfect security, which is another way of saying that perfect security is infinitely expensive. Risk mitigation involves weighing acceptable risks, given the nature of those risks and the cost involved in mitigating them. When you deliberate on the question of Public vs. Private Clouds, keep in mind that both approaches are inherently risky—but then again, choosing neither is also risky. Your job is to get the necessary facts in order to make the best decision you can about which risks you are willing to accept. Confuse FUD with facts at your peril.

Cloud Configuration Management: Where the Rubber Hits the Clouds

Document ID: | Document Type: ZapFlash
By: Jason Bloomberg | Posted: January 25, 2012

Your data center, sometime in the mid 1990’s: the server you ordered finally arrives. Could be Windows, Linux, some flavor of Unix, doesn’t matter. You unpack it. Boot it up. Patch the OS. Configure the OS. Install software off of CDs. Patch the software. Configure the software. Move data to the box. Test. Tweak. Test again. Finally, the box goes live.

Cut to 2012. You’re working in the Cloud now. You provision a virtual machine (VM) instance in the Cloud. Or three. Or maybe a few dozen. Only you’re not just provisioning VMs. You also provision some dynamic storage. Maybe some Cloud-based queues. You also want some SaaS-based services.

And your software release cycles? Weekly. No, daily. How about hourly?

Now what?

Clearly, it’s impractical to set up your Cloud instances manually, the way we used to set up servers in the good old days. So you go through the process once and create an image file that represents your Platonic ideal of what a fully configured VM instance should look like. Now, every time you need to provision a new VM instance, simply reconstitute the image. Right?

Not so fast! There are numerous gotchas to this scenario. Every time you need to patch anything, you would need to create a new image. If different VM instances are meant to differ in any way – say, contain different application data – you would need to configure those differences manually. But most significantly, there is far more to your Cloud environment than single VM instances. What about the storage? Databases? Network configuration? What about the architecture?

The Basics of Automated Provisioning

Remember, “automated” means “not manual,” in the sense that hands are not allowed. You want the ability to deploy, update, and repair your entire application infrastructure using nothing but pre-defined, automated procedures. Ideally, you want to automatically provision your entire environment from bare-metal (hardware with no operating systems – or anything else – installed on them) all the way up to running business services completely from a pre-defined specification, including the network configuration. Furthermore, there should be no direct management of individual boxes. You want to manage the entire Cloud deployment as a single unit.

Deploying sophisticated provisioning tools, of course, is a large part of the secret. And the more sophisticated the tools, the less skilled your staff has to be. Ideally, any people familiar with a few basic commands and appropriate permissions should be able to deploy any release to any integrated development, test, or production environment. They only require minimal domain specific knowledge. You don’t need a senior sysadmin. You don’t even need a systems developer. Any junior techie should be able to handle the task.

If something goes wrong, you should be able to revert to a “previously known good” state at any time. In a mature Cloud environment, it’s always easier to reprovision than it is to repair. Reprovisioning could mean an automated cycle of validating and regenerating application and system configurations, or even rerunning the full provisioning cycle from the base OS up to running business applications.

In many cases, of course, the previously known good state isn’t good enough, typically because there are live data in the real time state that would be lost with this kind of rollback. As a result, such rollbacks must be handled carefully, as they really aren’t rollbacks in the sense of a two-phase commit. Instead, with fully automated provisioning, the provisioning system should be able to “roll forward to a previous version,” where the provisioning tools will automatically return your applications to a functionally acceptable state, with all your data intact.

Automated provisioning depends upon the environment specification. This spec is essentially a declarative representation of how you want your entire deployment. Your provisioning tools will then essentially execute the spec, starting with bare metal and possibly stock virtual machine images, and then they will automatically deploy, configure, and start up the entire system or the application stack (or both), with no runtime decisions or tweaking by an operator. The spec should also contain sufficient detail to direct the appropriate tools to test whether the automation is implemented correctly, and if it isn’t, to take the appropriate action.

This specification can be as sophisticated as your tools and your architecture allow it to be. It may vary from release to release, and you should be able to break it down for specific tools that handle different parts of the configuration. The spec may also have conditional logic, and can also specify deployment or configuration changes over time, for example, the instruction to provision additional instances when traffic numbers cross a threshold.

You may also want to handle the automatic configuration of the application stack separately from the configuration of the system stack, as your applications may change more frequently than the systems. The goal is to make the spec sufficiently sophisticated so that the automation itself doesn’t vary from release to release. It will only require updates when your requirements call for a significant architectural change.

The View from Above and Below the Clouds

There are fundamentally two sides to this story: the view from the perspective of the Cloud service provider (including the internal providers of private Clouds), vs. the view from the consumer of Cloud-based resources. Clearly, Amazon, Microsoft, and the other public Cloud providers have figured out how to automate the configuration of their public Cloud environments. For organizations building their own private Clouds, the challenge is to take a page out of the public service providers’ playbooks on how to run a Cloud environment. Bottom line: if you don’t get automated configuration management down pat, you’re not running a private Cloud at all. You simply have a traditional data center with some Cloud-like features – and furthermore, you have a data center that is more expensive to run than necessary.

If you’re in a position to consume Cloud resources, regardless of the Cloud deployment model, then automated provisioning is every bit as important as it is for Cloud service providers, only now it impacts your existing IT processes and policies. As organizations adopt the Cloud, they increasingly transform the role of operations. No longer does your ops team actually take care of servers, networks, and applications. Instead, you’re automating that work, shifting the expertise required to the development team who must now create and manage the automation scripts that form the specification. Or perhaps the ops team moves their cubicles to the dev area, working hand-in-hand with developers to handle those scripts. Either way, Cloud changes everything in the IT department.

The Realization of the DevOps Vision

Reworking the relationship between dev and ops, or DevOps, is nothing new, of course. According to Wikipedia, “DevOps is an emerging set of principles, methods and practices for communication, collaboration and integration between software development (application/software engineering) and IT operations (systems administration/infrastructure) professionals. It has developed in response to the emerging understanding of the interdependence and importance of both the development and operations disciplines in meeting an organization’s goal of rapidly producing software products and services.” While ZapThink hasn’t discussed DevOps by name up to this point, we have been calling for iterative, full-lifecycle governance for several years now – an essential enabler of success with SOA in particular and agile architectures in general.

With the rise of Cloud Computing, DevOps is entering what might be its “golden age.” As Cloud provisioning specifications become more sophisticated, creating them becomes more of a development task than an operational one. Ops doesn’t go away, of course, but it moves to the other side of the Cloud: supporting Cloud data centers. In other words, if you have a private Cloud, your ops team is responsible for managing the private Cloud infrastructure. And yes, if you use a public Cloud, well, you have the luxury of outsourcing operations to your Cloud provider. Good sysadmins need not worry, of course. If anything, demand for your skills is only increasing with the move to the Cloud.

The ZapThink Take

First there was software development. Write a bunch of code and run it on a computer – “the computer is the computer.”

Then there was systems development. Write a bunch of code and put it on a bunch of computers, and have them serve up bits of it to many more computers – “the network is the computer.”

Now we’re at the dawn of Cloud development: create sophisticated Cloud provisioning/deployment/management specifications, and run those in the Cloud. Yes, the Cloud itself becomes the computer. We’re not talking IaaS, PaaS, or SaaS here. Even those oh-so-2011 Cloud service models are only elements of the spec, for automated provisioning tools to provision and configure dynamically.

he API is Dead! Long Live the API!

Document ID: | Document Type: ZapFlash
By: Jason Bloomberg | Posted: January 10, 2012

A funny thing happened as I was noodling on this ZapFlash. I was all set to put the nail in the Application Programming Interface (API) coffin, continuing the discussion of just how awful Remote Procedure Call (RPC) interfaces are, and how we should avoid them at all costs. But then I ran across the “explosion of APIs” meme at ProgrammableWeb and elsewhere. After all, your head must be planted deeply in the sand not to notice the plethora of APIs at all our favorite Social Web sites like Twitter, Facebook, and hundreds of others. How can the API be dead when APIs are more important and plentiful than ever?

Maybe I’m just nitpicking. As APIs become less RPC-centric and more RESTful, the inflexible tight coupling of the past is giving way to a new golden age of API-ness, where anybody can connect any piece of software seamlessly and automatically to any Web site or app we might care to use. But upon closer reflection, my concern is not all nitpickiness. There are API best practices and API worst practices, just as there are good APIs and bad ones. Perhaps more to the point, most of the APIs out there, well, are among the bad ones. So, what makes for a good API today, with all the power and capabilities that modern technology approaches afford us? Why are so many people getting them wrong? And what can we do to steer everyone in the right direction?

Programmable Interfaces: The Never-ending Story

The real reason that APIs get under my skin is the “P” – “programmable,” as in programmatic. The core notion of an API, after all, is that you want one application to be programmable by something external to it, in the sense that you have an imperative control flow that goes from here to there and back to here.

The problem with such imperative programming in any distributed environment, of course, is that there is no end of problems that can arise between here and there. Network issues, incompatibilities, timing and sequence issues, the list goes on and on, leading computer scientists to the notion of functional programming. In the functional world, functions (which also go by the names procedures or methods) encapsulate the software at the remote location, forming black boxes with fixed inputs and outputs. Any local piece of software, therefore, can call a remote procedure and get the desired response, without having to worry about whether multiple calls to that procedure might interfere with each other or lead to other nasty surprises that a purely imperative approach might exhibit.

Here’s the rub: functional programming is nothing more than RPC, with all the tight coupling issues that come along for the ride. However, functional programming is also considered to be a type of declarative programming. Declarative programming has always been the ugly duckling of the programming language world, because with a declarative approach, you don’t specify the control flow. Instead, you describe the desired behavior you want the software to exhibit. And somehow, via some kind of behind-the-scenes hand waving, the software miraculously does what you want it to.

Functional programming is declarative in the sense that a remote procedure acts as a black box. Specify the operations, inputs, and outputs (its signature, in API-speak), and the inner workings of the procedure aren’t your problem. That is, unless you don’t understand what it’s supposed to do for you, or heaven forbid, its behavior changes.

REST to the Rescue?

Building abstracted interfaces that enable organizations to deal better with change is what SOA is all about, of course. Unfortunately, the tools we had at our disposal – namely, Web Services – didn’t go far enough. Yes, we moved from RPC-style Web Services to document-style, and that improved our loose coupling substantially. But even document-style Web Services still have operations, a holdout from the bad old functional programming days.

Enter REST. ZapThink has discussed the move away from RPC to RESTful interfaces before: in REST-Based SOA: an Iconoclastic Approach, but of course, we’ve been discussing the advantages of document style interfaces over RPC for several years now. But people still aren’t getting it. Not only are techies missing the point of REST, even when they build supposedly RESTful APIs, they’re failing to follow the REST constraints.

For example, many of these ostensible RESTful APIs don’t provide self-descriptive messages. With REST, every message from a resource should contain all the metadata necessary for any client to understand what it can do with representations of that resource. In the RPC days, procedural responses may have contained only data with no metadata. With Web Service interactions, Service responses contained some metadata in the form of the SOAP envelope, header, and the tagging structure in the body. But even with Web Services, the WSDL contract and policy metadata are external to the Service. You don’t expect to get the contract when you query a Service.

With a RESTful interaction, on the other hand, contract metadata may be returned in particular representations, whether it be media type metadata, schemas, or even less structured metadata. And of course, representations also include hyperlinks, which also provide contract metadata to the client.

Separation of resources from representations is another essential REST constraint – one that developers also frequently violate. If there are any instructions to the resource in a request other than one of the four operations of the uniform interface (GET, POST, PUT, and DELETE), then you are violating this constraint. For example, if your request is instructing a resource to update a record, you’re not being RESTful. It’s up to the resource to determine whether a POST or PUT should update a record, not the representation.

Finally, hypermedia as the engine of application state – the dreaded HATEOAS – is perhaps the most overlooked of the REST constraints, even though it’s the most important. The big picture of HATEOAS are the hypermedia applications that we’re trying to build, but even at the API level, HATEOAS is critical, in conjunction with the self-descriptive message constraint. In any truly RESTful interaction, the resource returns a representation that contains all necessary metadata, including hyperlinks that instruct the client what it can do next. Likewise, a RESTful client has no idea what a resource can do for it unless it follows such links.

“RESTful” Equals “Web-friendly”

What so many techies lose sight of is the fact that REST isn’t supposed to make the Web more like system integration; it’s meant to make system integration more like the Web. When you click a link in a Web page, you expect to go to another Web page, or perhaps a video or sound file or some other media representation. REST takes that simple interaction and abstracts it. Now you have an abstracted client (instead of a browser) supporting a request of a resource (the Web server capability, for example, the php script that generated the response) on an abstracted server (the Web server) that returns a representation (the resulting media file or Web page) as per the uniform interface (what the link you clicked was supposed to do). These abstractions let us apply simple Web behavior to all manner of system-to-system interactions. But never, ever lose sight of the fact that you want simple Web behavior from your application.

I’m sure many readers who made it this far are muttering to themselves that their RESTful APIs are truly RESTful. Well, maybe, but probably not, and here’s proof. Let’s take a popular, supposedly RESTful API as an example: the Yahoo! Maps PlaceFinder Geocoding API. You’ll notice on the documentation page a “BASE URI,” which it expresses as http://where.yahooapis.com/geocode?[parameters]. There are two problems with this expression. First, it’s not a hyperlink (it just looks like one). Second, the URL has the question mark in it, requiring the user to know what parameters might be valid.

Let’s say instead we turn this expression into a true hyperlink, leaving off the parameters since we don’t know what they are: http://where.yahooapis.com/geocode. Go ahead, click on that link, I dare ya. Sure enough, you get an error message. True, it’s XML formatted, but it’s missing something absolutely essential: a hyperlink.

In fact, Yahoo! made several serious mistakes: first, the base URI isn’t a hyperlink, violating HATEOAS. Second, the metadata that tell you how to use the interface are separate from the interface, rather than returned in the response from hyperlinking to the base URI, violating the self-descriptive messages constraint. Third, the URI requires parameters as part of the search query (the characters after the question mark), violating the separation of resource and representation. And finally, the error response it did return didn’t include a hyperlink, once again violating HATEOAS. Bottom line: there’s really very little that’s RESTful about this API.

While it may be amusing to pick on Yahoo!, it’s important to point out that they aren’t alone. In fact, they’re typical. It’s quite rare, in fact, for a supposed RESTful interface to be truly Web-friendly. After all, most techies don’t expect Web friendliness from APIs. APIs are, well, programming interfaces, while the Web consists of user interfaces. But in the REST world, programming interfaces are simply abstracted user interfaces. In other words, truly RESTful APIs aren’t really like the APIs we know and love, and have been working with for years. They’re fundamentally different.

The ZapThink Take

I know this ZapFlash is deeply iconoclastic, but that’s what you’ve come to expect from ZapThink, after all. However, the point of this article isn’t to scold everybody for doing REST wrong. The point is to help you think differently about what it means to program in a distributed environment. The point to the “programmable Web” isn’t to make the Web more programmable, it’s to make software more Web-like. If we can finally free ourselves from the last vestiges of imperative, RPC-style programming, even going so far as to steer clear of functional programming, and move to a fully declarative, document-centric paradigm, only then will we be able to achieve the resilience and power of the Web when we tackle system integration challenges.

This mind shift is at the core of REST. When Roy Fielding wrote his dissertation, he didn’t come up with REST and then build the Web following its constraints. On the contrary: he deeply understood what made the Web itself so special, and he sought to express that specialness as an architectural style. True, tackling system integration following true RESTful principles is difficult. But remember, building the Web was easy. Take TCP/IP, add a few simple standard protocols, code an HTML rendering app we called a browser, and the Web more or less took it from there. Almost twenty years later, the Web is unimaginably immense, and yet it still works just fine, thank you very much. Is it too much to ask for all of our IT systems to behave the same way?

Garbage in the Cloud

Document ID: | Document Type: ZapFlash
By: Jason Bloomberg | Posted: December 13, 2011

On two occasions I have been asked,—”Pray, Mr. Babbage, if you put into the machine wrong figures, will the right answers come out?” … I am not able rightly to apprehend the kind of confusion of ideas that could provoke such a question.

—Charles Babbage, 1864

The long-standing computer science principle of “garbage in, garbage out” (GIGO) is so fundamental to IT that it predates digital computing by almost a century. And yet here we are in the twenty-first century, moving to the Cloud, and Babbage’s exasperated response is no truer or more on point. For not only is the Cloud a magnet for all sorts of garbage, it is also generating new garbage at a brisk clip.

Uploading Garbage to the Cloud

In today’s frantic rush to “move to the Cloud,” too many organizations are failing to ask what they should move to the Cloud. Instead, they envision the Cloud as some kind of huge, nebulous server in the sky, a perfect receptacle for whatever they have on-premise. Got email? Put it in the Cloud! Got data? Put your data in the Cloud, the bigger the better! Running business processes on-premise? Move them to the Cloud!

Not so fast. Let’s slow down a bit and consider the ramifications of moving too quickly—and haphazardly—to the Cloud.

• Unclean data – This is the obvious example, pure GIGO. If your current on-premise data are unclean, say you have inconsistent customer demographic information, or obsolete product information, or any other data quality challenge, it goes without saying that moving such information to the Cloud won’t do your data, or your business, any good. Instead, think of moving your data to the Cloud as though you were moving your elderly parents to a condo. It’s a wonderful excuse to finally dig through the layers of detritus so that you only move data that are clean, accurate, and valuable to the business.

• Spaghetti code – you may be eyeing that old custom-coded legacy app as a prime Cloud candidate. It’s too slow, it doesn’t scale well, and it’s a bear to integrate now, so won’t the Cloud automatically make it fast, scalable, and easy to integrate? Sorry to burst your bubble. If you’re focusing on an IaaS approach, what you’ll find is that spaghetti code is every bit as intractable in the Cloud as it is on-premise. What about PaaS? Chances are that old code won’t run at all. Today’s PaaS environments expect and enforce a certain level of code quality.

• Obsolete and Cloud-unfriendly business processes – Does this sound familiar? The business asks IT to automate a set of processes, but states unequivocally that “the processes are fine the way they are. Automate them but don’t change them. After all, we’ve been doing things the same way for years. Why change now?” Yes, the business often says that, but seasoned IT veterans have long realized that the business never actually means it. When the business asks IT to touch a process, there is always at least an implied requirement to try to make it better: faster, more streamlined, better aligned with the underlying business need.

Moving business process implementations to the Cloud raises the stakes in this complex dance between business and technology, because the Cloud offers a wealth of new opportunities for improving processes. Furthermore, how users interact with Cloud-based assets is often fundamentally different from how users interact with traditional enterprise apps. Any organization that has moved from an older CRM app (or no CRM app at all) to Salesforce.com has learned this lesson first hand. But Salesforce is merely a harbinger of greater change to come. One of the main reasons Salesforce has been so successful is because they offer their clients new ways of conducting business—in other words, better processes. Any SaaS solution should build on their example.

Generating New Garbage in the Cloud

The garbage problem doesn’t end with garbage you might put in the Cloud. The Cloud also presents numerous opportunities to generate new kinds of garbage.

• Zombie instances – it’s so easy and cheap now for anyone in your organization to spawn their own Cloud instances, including virtual machines, storage instances, and more. Furthermore, such instances are elastic: need more of them? The Cloud is only too happy to oblige. But what happens when you’re done with them? You’re supposed to delete them. After all, elasticity works in both directions. All too often, however, instances that have served their purpose are left around like so much space junk. After a while, nobody remembers what they’re for or if they still have something important in them. The last thing you want to do is delete an instance with valuable data or code on it. So to play it safe, you leave it around. Forever. Your Cloud provider is only too happy to keep billing you for these Zombie instances.

• Data with no provenance – any Antiques Roadshow aficionado knows that antiques with provenance are more valuable than those without. The same goes for your data. Do you know if the data you’re working with are the latest version? Do you know they haven’t been tampered with? If not, then those data are worse than useless, since they may be incorrect, or even worse, keeping them around may violate any number of regulations. Here again the elasticity of the Cloud works against you.

• Manual or poorly abstracted configurations – Let’s say you’ve built a sophisticated Cloud app based on elastic VM instances. If you need more, simply provision more. But then let’s say some admin somewhere in your IT shop goes into one of these instances and changes a config file in order to get an app to run on that instance. Now you have no way to update your instances without breaking your app—and if that admin didn’t tell anybody about the reconfiguration, then tracking down the problem will present a time-consuming challenge.

Simply creating a static image file to generate new VM instances—and keeping rogue admins from monkeying with them—won’t solve the problem, because there is more to your app than the instances. Instead, you need a next generation configuration management approach that automates configuration for the Cloud. See Chef or Puppet for an indication where this market is going. (You can expect a ZapFlash on Cloud configuration management in the near future.)

• Cloud-unfriendly architecture choices – We covered one example of this problem in our ZapFlash The Secret to a RESTful Cloud: stateful Cloud instances. Essentially, inappropriate state information is just more garbage in the Cloud. Another example would be inappropriate transactionality in the Cloud. Cloud Computing lends itself to particular ways of architecting applications, and attempting to shoehorn the wrong architectural approach into the Cloud is about as effective as Cinderella’s stepsisters’ efforts with the glass slipper.

The ZapThink Take

How do you avoid garbage in the Cloud? Architecture is a large part of the answer, of course, but governance is equally important. Organizations should establish and enforce Cloud-centric policies as well as extending current IT governance to the Cloud. With great power comes great responsibility, and the Cloud offers enormous new power to many different roles within the IT organization. The Cloud is fraught with pitfalls. Without sufficient governance, you’re bound to fall in one.

It is also important to note that the issues in this ZapFlash apply equally to private as well as public Clouds. Organizations generally realize that public Clouds present numerous governance challenges, and look to private Clouds because they are ostensibly less risky. But such a stance offers little more than a false sense of security—one that may backfire, if organizations assume that in the absence of proper architecture and governance, a private Cloud is the better choice. Don’t wait to implement adequate Cloud governance until after you’ve run into these problems. Governance should be an integral part of any Cloud strategy, before you move to the Cloud.

2011 Retrospective and ZapThink’s Predictions for 2012

Document ID: | Document Type: ZapFlash
By: Jason Bloomberg | Posted: December 28, 2011

The presents are unwrapped, family has headed home, and the leftovers are almost gone. Once again, it’s time for ZapThink’s annual retrospective and predictions for the coming year. While it’s true that many pundits and prognosticators churn out their guesses for the year to come around this time, ZapThink takes the practice one step further: we actually review the previous year’s predictions and score ourselves on how well we did. Here then are our results from last year and our predictions for the year to come.

2011 Predictions: 2 ½ out of 3

I’m proudest of how well we did on our first prediction: one spectacular Cloud flameout. We so nailed this one, with Amazon Web Services well-publicized crash in April. I can’t help but say we told you so. We even went so far as to say “if you believe your Cloud provider is invulnerable, you’re fooling yourself.” Bottom line: expect for and plan for failure, especially in the Cloud.

We did well on our second prediction as well: that we’d run out of IPv4 addresses in 2011, and that the resulting shortage would lead to the growth of a secondary market in IP addresses. In fact, a black market for IP addresses has sprung up, in addition to the more above-board purchases, like the addresses Nortel sold to Microsoft. If the IPv4 shortage hasn’t impacted your organization yet, then 2012 might be the year you feel the pinch.

Our third prediction, however, is more of a work in progress. We predicted an “Enterprise Architecture is dead” story that would parallel the “SOA is dead” meme from 2009, as organizations move away from checklist architectures to more agile approaches that show better results. We’re giving ourselves 50% on this one, as no “EA is dead” meme has cropped up, or at least, no more in 2011 than in years previous. But speaking from personal experience, an increasing number of organizations are looking to move toward more agile, cost-effective architectural approaches, notably in the US Government with CIO Steven VanRoekel’s “Future First” initiative. As checklist architectures were endemic across the government, this shift is a good sign that our tax dollars are finally being spent wisely on architecture, at least here in the US.

Before we move on to our predictions for 2012, there’s one more prognostication to mention, from ZapThink’s predictions for 2008. We predicted that ZapThink would be acquired that year. We were off by three years, but we’re now a happy part of Dovèl Technologies!

Predictions for 2012

Future First steals thunder from the Cloud – Our first prediction centers on the US Government, who is moving headlong into the Cloud. Dozens of agencies are taking the Cloud First initiative to heart, moving email, content management, and other key capabilities to the Cloud. Now, with FedRAMP ready to take off, agencies will be able to reduce the cost and complexity of moving to the Cloud.

But perhaps, not so much in 2012. We do predict FedRAMP will save billions of dollars of IT costs eventually, but there is simply too much politics involved to expect it to pay off substantially this coming year. In fact, we expect government adoption of the Cloud in 2012 to be more about politics than achieving real value. Instead, it will be a year of expanding the focus to Future First, as various federal departments and agencies, in conjunction with industry and academia, flesh out the combination of Agile, Lean, open source, and Cloud that VanRoekel has in mind. Cloud won’t go away, of course, as Cloud is an integral part of Future First. But the focus will gradually shift to Future First.

HTML 5 becomes the glue of the ZapThink 2020 vision – As the next major version of the Web’s central markup language, HTML 5 has been a long time in coming. In 2012, we predict it will hit a critical tipping point, as the next generation of Web markup, the replacement for Adobe Flash, and the common technology framework for Mobile app development. In addition, HTML 5’s Web Sockets technology that allows for full duplex tunneling via HTTP will open up new approaches for integrating capabilities in the context of rich, cross-platform user interface experiences.

As a result, HTML 5 will provide technology underpinnings, not only for mobile computing, but for ongoing improvements in technology across the board. After all, the user interface is where the value of technology manifests itself. We predict, therefore, that HTML 5 will impact multiple facets of enterprise IT, well beyond the user interface. Stay tuned for more thought leadership from ZapThink on this topic.

The rise of RESTful BPM – Just as SOA was misconstrued as an ESB-centric technology approach, people have confused REST with a way to construct APIs. However, that’s not what REST is about. REST is an architectural style for building hypermedia applications. And while you can think of a hypermedia application as a glorified Web site, it’s actually more than that: it’s a runtime workflow.

The idea of RESTful applications as runtime workflows is both simple and deeply powerful, as it entirely changes the way we might look at Business Process Management (BPM) tools. Traditional BPM tools are heavyweight, integration-centric tools that typically rely upon layers of infrastructure. Even lightweight BPM tools still rely upon centralized state engines. With REST, however, hypermedia become the engine of application state, freeing us from relying upon centralized state engines, instead allowing us to take full advantage of Cloud elasticity, as well as the inherent simplicity of REST.

Will people understand this shift in BPM approaches in 2012? Largely, no. But what will happen is that RESTful BPM will at least appear on the radar of organizations looking to approach process automation and optimization that leverages the Cloud without falling into the big vendor trap. What we do predict is more buzz about RESTful BPM, and at least one vendor bold enough to offer a truly RESTful BPM tool, instead of the non-RESTful attempts that we currently see from the vendors today. Are you a vendor who believes you offer a RESTful BPM tool that actually follows the REST constraints? We want to hear from you.

The ZapThink Take

ZapThink is pleased with the progress enterprise IT is making toward our ZapThink 2020 vision. The point to this vision was that individual trends in IT interrelate, and thus you shouldn’t separate any of them from the broader context of change within the organization. Whether it be SOA, Cloud Computing, mobile computing, or any of the five Supertrends, the only way to understand the message of ZapThink 2020 is to take them all together.

Our predictions for 2012 follow this pattern. The point to Future First is that it brings together Agile approaches with the Cloud and more. Our expectations for HTML 5 focus not on the user interface, but on how this standard will facilitate the ZapThink 2020 vision across enterprise IT. Likewise, RESTful BPM turns traditional integration—and even traditional SOA—on their heads, circling back to the World Wide Web as the central organizer for business at large.

Our predictions, therefore, are somewhat convoluted, not by accident, but by necessity. Pulling single strands out of the complex knot we call enterprise IT wouldn’t tell a useful story. Only by leaving the strands together and exploring how they interrelate can we gather useful insight into the change that faces us every day.