There were a variety of developer-related announcements at yesterday’s TechEd in Bangalore – signs of an “extended and deeper commitment to the developer community” on the part of SAP. Such announcements are part of a broader trend in enterprise software which is evident in the marketing efforts of many companies ranging from small smart-ups to traditional vendors. This tendency is especially true regarding Cloud platforms where the main focus is usually making developers’ lives easier. This is a laudable goal and critical to achieve a critical mass necessary for adoption of such platforms.
There are, however, other participants in the gladiatorial enterprise software arena whose interests are not always best served by such endeavors.
There are many PaaS products currently on the market. What interested me about Apcera were two things:
- A realization of the importance of the requirements of Corporate IT in Cloud platforms
- An implementation that allows Corporate IT to meet these requirements in an innovative fashion
I’d like to examine Apcera’s solution in some detail though the selective use of quotes followed by an analysis to shed light on how SAP’s Cloud offerings might benefit from this approach.
What problem is Apcera trying to solve?
Derek Collison, founder and CEO of Apcera, provided this explanation concerning his motivation for creating this new product:
During my time at TIBCO, Google, and VMware, I saw that despite massive innovations in technology, IT repeatedly faced the same forced choice: Go fast and risk policy violation, or slow down to meet compliance. We’ve optimized for time in many ways, mostly shortening code and provision time, but time to deploy, and in a compliant manner, is still high. The increasing delta between Dev and Ops makes IT resort to shortcuts, which only work until they don’t. [SOURCE]
What I like in this description is the fact that IT is implicitly included in the equation as well as the realization that DEV, OPS and Corporate IT don’t always have the same interests.
What sort of Corporate IT requirements must be met in such situations?
The idea being that it’s easy to build applications on existing platforms, but it’s hard to track compliance with regulatory or financial mandates. And it may not even be something as lofty as HIPAA or Sarbanes-Oxely, but might instead be trying to understand how business units are accessing and releasing information through their applications. [SOURCE]
How does Apcera meet IT’s requirements?
In a recent blog about Cloud environments, Sina Moatamed depicts the perspective of Corporate IT on such scenarios and introduces the idea of a policy / governance engines as a mechanism to meet these resulting demands.
For those concerned about compliance or cost, having a policy engine that can decide where a blueprint should reside (private, virtual private or public cloud) is essential. It may be a requirement to keep certain IT services within your private network. A policy engine serves as a compliance tool, to be assured that the blueprint will be deployed based on that kind of rule. ….
Governance is about who has authority to request services. It also can be used in conjunction with the policy engine to determine which instance of a service someone can request. ……
Apcera implements a policy engine which appears to meet Sina’s requirements as well as being central to the entire platform – stretching across all layers (Saas-PaaS-IaaS).
Here is a broad description of this functionality:
Apcera is an autonomous system that understands the notion of who you want to talk to and how it talks to you. This is not meant literally but rather in the sense that, for example, the technology knows the semantics of a database and can associate it with a policy. It knows its physical location, where in the system it is located and is semantically aware of what it is. All of the descriptions are enforced and auditable, bound by a universal policy, which is built into the service. So an app can be deployed but the governance and regulatory requirements go with it and can be edited or changed when needed. [SOURCE]
What does Apcera’s technical implementation look like?
There aren’t a lot of technical details revealing how Apcera’s achieves its policy plane (I have no idea what the internal architecture) but it uses the programming language Go extensively in the platform.
Furthermore, it appears, that semantic analysis is somehow involved.
As low as policy is, we dive even deeper to achieve semantic awareness. This means we not only control and have visibility into which apps talk to which services, but also what goes on in the connections themselves. It’s not about the data, but total monitoring of the wire even after the app is connected to the service, all done transparently. The combination of policy and semantic awareness underpins an incredibly powerful platform. [SOURCE]
Note: When I first read about Apcera, I immediately tried to figure out ways to integrate it into existing SAP Cloud offerings such HANA Cloud Platform. Unfortunately, it probably wouldn’t be easy. HCP is based on JVM s and it doesn’t look like applications developed with Go can be converted to JVM-readable byte code.
Although I find Apcera’s implementation intriguing – there are still a variety of questions that are still unanswered:
- How do these policies fit into the broader enterprise environment?
- How can you create the policies used in Apcera? Is there an interface between Apcera and existing GRC tools that already create policies in corporate environments?
- How are Apcera policy violations registered / monitored? Are there interfaces to existing security violation tracking environments?
Relevance of Apcera’s approach
Before we examine Apcera in comparison to SAP’s Cloud offerings, I’d like to emphasize that I’m not suggesting that SAP’s Cloud solutions have no awareness of the importance of supporting Corporate IT requirements. Yet, much of the existing support in this area is based on those measures / policies originating in the traditional hosting business.
The HANA Enterprise Cloud (HEC) provides audit reports and other measures to support such needs (such as policies restricting access to certain virtual machines). Yet such measures have a different quality than those provided by Continuum – the HEC’s policy focus is more on infrastructure issues whereas as Apcera focuses more on application-related policies. Apcera’s policy engine is interesting, primarily for its ubiquitous character – it is present everywhere.
It might be more useful to compare Apcera to the HANA Cloud Platform (HCP). The current focus in the HCP is on acquiring a critical mass of developers who are using the platform. Although understandable, this focus (of resources, etc) may occur at the expense of meeting the needs of Corporate IT in an innovative manner. Functionality relevant for Corporate IT is present to some degree (zero downtime maintenance (ZDM), SAML Integration to permit Single Sign On with enterprise authentication environments, the Cloud Connector to permit secure access to back-end environments, etc) but the policy/governance engines as described by Sina are currently not in place in the HCP.
As Project Ganges clearly demonstrates, SAP’s Cloud-related activities are evolving beyond the traditional IT audience – yet, the core market of SAP’s cloud activities is currently its existing customer base (especially in larger companies) where Corporate IT usually plays a critical role. It is important that the needs of Corporate IT aren’t forgotten. The goal should be providing innovative features that meet such requirements without restricting the flexibility / openness that the majority of developers demand.