Making the public cloud your own

Making the public cloud your own

Summary: It makes no difference to security whether you deploy to public or private cloud. What matters is how you architect the infrastructure. Public cloud providers that offer sophisticated controls can even outperform many enterprise data centers.


In my last post, I talked about SaaS applications that are operated by enterprises for employees, partners or customers. Some of these instances operate in a mode that people have been describing as 'private SaaS', which means that the application is only visible to users who have logged onto a private network. While these applications may behave like SaaS, they lack an important dimension by not being exposed to the challenges and pressures of the public Internet. In other words, they are not built to perform at what I call cloud scale.

In many cases, though, enterprises are fooling themselves if they believe that these 'private SaaS' instances are safer than third-party public SaaS alternatives. If they're being delivered to laptop users logging in from public Wi-Fi hotspots and hotel LANs, or if there are mobile clients being used on smartphones, they're still exposed to numerous security threats. Customer-facing applications — especially if they're part of a customer acquisition strategy — are even more exposed, because they have to be open to the Internet to fulfil their mission.

The riposte I often hear in such circumstances is that, well, at least the infrastructure is behind our own firewalls, so we know the back-end is safe. But this is a somewhat naive point of view, as I recently discussed in a post [disclosure: sponsored by IBM] on the Future of Enterprise Computing site: In the Cloud, Governance Trumps Ownership. The truth is that our faith in the potency of direct ownership often masks a lack of proper processes:

"The real reason we like ownership is that, whenever we need to, we know we can just walk in and make a hands-on assessment of the situation on the ground. If we're honest with ourselves, that sense of direct, actionable accountability is probably covering a multitude of sins. We know there are times when our own people or our contractors, whether through lack of training, process flaws or sheer carelessness, get things wrong. We probably tolerate errors within our own organization that we would never accept from a third-party provider because we know we have the power to put things right to our own satisfaction if we ever need to."

I went on to argue that the quality of real-time instrumentation that's available today means that we no longer have to rely on walk-in inspections to enforce proper process. Instead, we can automate governance — and if we do that, we can have just as much confidence in a provider's infrastructure as in our own; perhaps more, because the provider can offer us an all-new, state-of-the-art implementation that would be beyond our own purchasing power.

Yesterday, cloud infrastructure provider OpSource announced a new offering that perfectly illustrates my point [disclosure: OpSource is a past client]. The attention-grabbing part of the announcement is free bundling of a virtual private network that secures the customer's cloud instances. By doing away with the 20c per hour charge for the VLAN (which provides firewalls, load balancing, VPN and other access controls), OpSource effectively cuts the price of a single server by almost two thirds. But of course the point is that most customers who are interested in the platform will end up with at least half-a-dozen servers, often many more, so by 'loss-leading' on the first server OpSource is onboarding customers that will become more profitable as they scale up to production levels.

What caught my interest was the infrastructure underlying this offering. It's an all-Cisco hardware platform, part of the vendor's Data Center Business Advantage architecture. So all the firewall, VPN and load balancing surrounding the customer's server instances, as well as the instances themselves, are running on the same, shared, physical internal bus. The principal advantage of this is that it removes the latency inherent in other cloud platforms where servers are connected at LAN or WAN speeds. "We offer sub-millisecond latency speeds," OpSource's CMO Keao Caindec told me in a briefing last week. Whether tying a cloud infrastructure to a specific hardware architecture is truly in the spirit of cloud computing is a discussion I'd like to defer to a separate blog post; there are a number of angles to consider, and it's not as clear-cut as it might seem. One argument in favor is the other advantage that OpSource exploits, which is the ability to offer customized configuration and governance of a customer's cloud instances within the shared infrastructure.

"In this case the customization of the environment from a security viewpoint is included in the cost and it scales economically," Caindec explained. "The customers gain the benefits of scale without having to pay additional fees for customization. That's right at the heart of why we're doing this. Right now, to customize the public cloud or to secure it costs you extra money."

OpSource provides various means of achieving the customization, including its own RESTful API, to the extent that an enterprise could implement a 'defense in depth' security model within OpSource's public cloud environment (see diagram).

"That is almost impossible to do in a normal public cloud," Caindec told me. "But because we've deployed actual networking gear that creates that same networking environment, it is exactly the same as what you would do in your own data center.

"There really is no difference between a public and a private cloud," he continued. "The level of security has more to do with the architecture than whether it's in a public cloud provider or a private customer data center."

This ability to privately "own" a slice of the public cloud is especially attractive to SaaS ISVs, who form an important segment of OpSource's customer base. Because, of course, a SaaS ISV is merely an enterprise whose business model is based on making customer-facing applications available on the public Web. Hosting their application on a virtual-private LAN within a public cloud provider's infrastructure gives them the right combination of internal control and outward-facing cloud scale, provisioned with cloud economics. Whether they then go on to architect the internals of their application to really exploit the cloud environment is another matter, but having a highly customizable, high-performance infrastructure that's tuned for cloud scale seems like a great starting point.

Topics: Data Centers, Cloud, Emerging Tech, Networking, Servers

Phil Wainewright

About Phil Wainewright

Since 1998, Phil Wainewright has been a thought leader in cloud computing as a blogger, analyst and consultant.

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.


Log in or register to join the discussion
  • Great Post! Just a little clarity though...

    Phil, great work (as usual). I think you make a significant number of valid points. I did want to clarify something in hopes of understanding your viewpoint a bit better. When we at Apprenda refer to "private SaaS," we typically refer to it from a visibility point of view, not from a "where it runs" point of view.

    Let's take a large fast food restaurant, for example, that has something like 30,000 locations worldwide and a need to write their own back-office software. There could be TREMENDOUS benefit to architecting the offering as SaaS (i.e. writing the applications such that it's "internals" are multi-tenant, scale-out capable, meta-provisionable). Do you agree that this is useful (given that you and I agree passionately on the economics of multi-tenancy and a true SaaS architecture)?

    This same fast food restaurant could choose to deploy the custom written app on something like EC2, or their own datacenter. Regardless, they're extracting most of the value of the SaaS offering from how it's architected and not where it's running (which is a secondary, less important value tier). Regardless of "where it runs", the offering is still 'private SaaS', given that it is available only to logical entities that belong to the fast food restaurant. Is there a reason why anchoring 'private' to where the application runs makes more sense?

    Our enterprise customers tend to care about SaaSGrid because they get the internals of a SaaS app out of the box, which is where they see most of the benefit coming from. We have enterprises that run the whole SaaSGrid+application stack in their datacenter, or on EC2. If in a cloud environment, SaaSGrid can exploit the presence of elasticity, etc. If not, no big deal, the app is still SaaS and can vicariously deliver SaaS benefits to those 30,000 locations. In these 'private SaaS' cases, enterprises are looking to advanced app architectures and delivery models (e.g. SaaS) to revolutionize internal delivery and consumption, and have a trivialized way of managing the application, so 'cloud scale' isn't really top on the priority list. Moving to a services model from a product model is where they extract orders of magnitude decreases in cost and increases in benefit.

    I think OpSource's offering helps flatten issues with "where an application" runs, but doesn't really play into 'private SaaS' at all.

    This comment ended up being much longer than anticipated - maybe I'll have to write a post instead! Take care Phil, and keep up the great work!
    Sinclair Schuller (Apprenda)
    • RE: Making the public cloud your own

      @Sinclair Schuller (Apprenda) amazing
    • RE: Making the public cloud your own

      amazing :)
  • One more thing!

    I didn't state it, but I do agree with your overall sentiment. Where possible, an enterprise should lean toward deploying to the public cloud. I think there is significant benefit when compared to private cloud, but I just wanted to make a point that 'private SaaS' need to be defined by what type of cloud the SaaS offering is deployed on, but instead defined by who its intended audience is.
    Sinclair Schuller (Apprenda)
    • Private clarity

      Thanks for the comment Sinclair. However I disagree, I think if the context of the conversation is private cloud, then the natural interpretation of private SaaS is that the back-end infrastructure is behind an enterprise firewall. The whole ethos of enterprise computing thinks that way and if you use the term 'private' the assumption is that you're talking about the back-end infrastructure as well as the front-end access.

      I suspect a better term for your example of restricted access to a specific user base would be 'community SaaS'.

      Yes, it is just semantics, but if you're trying to be clear about what you mean, semantics matter.

      • RE: Making the public cloud your own

        @philwainewright Semantics are absolutely important. I love thinking about this in the abstract and understanding what proper naming should be. The context we use at Apprenda is the same you articulated in your OEMing of SaaS post: three use cases that outline consumption models, and not hosting location. We're very careful not to confound these uses cases with "private Cloud", which is why we use customer oriented stories and believe in the three use cases you had articulated as well.

        I do agree that the context that you've defined is one of "private cloud", but as I stated, I do point out that in your prior article the focus and context was very much one motivated by who and how an offering is consumed in the non-COTS enterprise application space.

        Naming doesn't matter too much if we have a practical understanding of the discussion, and an agreement that multi-tenant SaaS architectures for custom enterprise applications is a powerful model. Should an enterprise choose to offer a service to internal or external customers, going public cloud for hosting is a huge win in my book as well.
        Sinclair Schuller (Apprenda)
  • RE: Making the public cloud your own

    Cloud Software is beyond question the state of tomorrow's computing. For a look behind the curtain at one company in the forefront check out SmartSuite Office (

    They offer tools that are superior to business tools many small business currently use at a fraction of the cost.
  • RE: Making the public cloud your own

    Phil - Aren't, Amazon, Google, Facebook and the rest behind an 'enterprise firewall'? The service and infrastructure is exposed to the public but its not like the infrastructure is sitting in a field outside of Topeka Kansas. The infrastructure is in highly secure, highly managed locations - enterprise data centres.

    Public/private to me boils down to one question:
    Can the infrastructure on which you operate your business, can be used as the infrastructure for a 3rd party to deliver a service for themselves or another business?

    If the answer is yes - public cloud; answer no - private cloud.

    Feel free to correct my logic.
    • RE: Making the public cloud your own

      @ringlis44 yes, precisely my point (or at least one of them) as I wrote in the article:

      "a SaaS ISV is merely an enterprise whose business model is based on making customer-facing applications available on the public Web"

      Once a SaaS provider gets to a certain size and scale, it will usually find greater economies of scale operating on its own private infrastructure than using a generic third-party cloud (though some applications may still benefit from bursting to public cloud infrastructure at times of peak load). The break point where that becomes economical probably rises when taking into account the availability of 'customizable' public cloud infrastructure such as OpSource's (if that's not a contradiction in terms, but as I said above, that's a discussion for a separate post).

      However I think we have to be more demanding of public cloud providers than simply defining them as being usable by a third party. That is why I make a big deal of 'cloud scale' along with other platform elements that distinguish serious public cloud players.
      • RE: Making the public cloud your own

        @philwainewright - so here's a question: when do large enterprises with excess computing capacity begin to 'lease' space to 3rd parties? If I'm a large enterprise with a clear cloud strategy, shouldn't I consider replicating the Amazon model? Why haven't other firms done so?
  • RE: Making the public cloud your own

    Great post! I think we will be considering Op Source in the future in addition to the EC2 hosting that we typically use for client cloud deployments.
  • RE: Making the public cloud your own

    Please ... "architect" is a noun, not a verb !