Platforms beat products. 10 years ago, that might have not been the popular thinking. However, the latest cloud platforms are beating product. Over at CIO.com today, Bryan Kirschner posted an interesting piece on how platform economics work – and why a product strategy will always lose.
As he puts it: “a successful platform strategy requires upending product strategy assumptions. Products win on features. Platforms win with communities. Value creation must shift from internal optimization to external servicing. Behavior must shift from command-and-control to openness by default.”
He goes on to highlight the three key pillars of a presentation from Cloud Foundry’s CEO, Sam Ramji:
1.

Cloud Controller is the primary API through which third parties interact with Runtime; it encapsulates the myriad internal services that take a user from ‘cf push’ to a running application. Both the Pivotal Developer Console (the web application that ships with Pivotal CF and backs console.run.pivotal.io) and the CloudFoundry CLI interact directly with the Cloud Controller API. The two applications were originally written in Ruby and shared a common Ruby code base for talking to Cloud Controller called CFoundry.
CFoundry provides a friendly interface to the Cloud Controller API.

As an active committer on Spring Security OAuth and the Cloud Foundry UAA, one of the questions I get asked the most is: “When and why would I use OAuth2?”
The answer, as often with such questions, is “it depends.” However, I must admit, there are some features of OAuth2 that make it compelling in a wide variety of situations, especially in systems composed of many lightweight web services. This article guides you through updating a system to be secured with OAuth2 and the decision points for choosing to build such a system.
There is a strong trend at the moment towards distributed systems with lightweight architectures based on plain text web services (usually JSON).

The User Account and Authentication Service (UAA) in Cloud Foundry is responsible for securing the platform services and providing a single sign on for web applications. A previous article introduced the UAA and placed it in the context of the platform, and here we go into a bit more detail and describe the features of the UAA individually:

Centralized Identity Management
Single Sign On
Delegating Access to Services
User Account Management
Client Application Registration
Other UAA Resources

Centralized Identity Management
Applications that want to act on behalf of a User, for instance to view or push apps to the users Cloud Foundry account, need to authenticate the User against the platform.

Cloud Foundry is a distributed system with many components front and back end. If you are familiar with the Cloud Foundry architecture you have probably noticed that the Cloud Controller exposes its functionality via lightweight HTTP APIs. The internal components also use the same approach to communicate with each other. Up until recently this was done using a custom authentication mechanism which had some drawbacks. This blog post will walk you through the changes that we are making in this area.
We created a new component to handle all external user-facing security concerns named the User Account and Authentication Service or UAA for short. It has been live in cloudfoundry.