A New Chapter, Nimbula Joins OpenStack

At Nimbula, we’ve been focused on bringing our customers the best possible cloud infrastructure. Nimbula Director delivers all the elasticity and self-service of modern cloud but with all the security, and operational readiness expected of enterprise software. In the last year and a half, we’ve released Nimbula Director 1.0, 1.5, and 2.0. We’ve been deployed all over the world to help with development and test, SaaS hosting, and batch processing. Our customers are in enterprise, internet, and government. Now, we are proud to announce the next step in our journey. As of today, Nimbula joins the OpenStack Foundation and the Openstack development community.

Why is Nimbula making this move?
Over the last year, a number of our customers and prospects have been asking us if we can provide them our enterprise ready cloud platform on top of an open core model and we are responding to that demand. The requirement for an open core model comes down to the following four value propositions.

  • Open source: An open source base guarantees no vendor with a great idea is prevented from quickly getting started and competing on level footing.
  • Community: The community model and massive vendor and developer participation guarantee fast introduction of new functionality.
  • Extensibility: API-driven extensibility guarantees that the cloud can be extended to any network or storage system and can be well managed by any external software. A customer’s cloud will not stall waiting on one vendor to release a particular feature or integration.
  • Choice: Most importantly, the proliferation of compliant distributions gives the customers what they most need, choice of the right provider with the future ability to replace that provider at any time – delivering them the right infrastructure at the right price over the long term.

With multiple open source cloud offerings, we chose OpenStack because we have been very impressed with the continued rate of growth of the project and community. The developer base, vendor commitment, product features, and most importantly customer traction have grown remarkably well in only a short time. Furthermore, as we have spoken with key OpenStack participants in the last few months, we have found significant mutual interest. While we are looking to meet the open core demand, many in the OpenStack community has shown interest in our capabilities and differentiators and have wanted to see that technology work to advance OpenStack.

Product Strategy
Nimbula’s product strategy is four-fold

  • Nimbula Director becomes an OpenStack cloud: Nimbula will continue to build, deliver, and support Nimbula Director as a complete packaged cloud platform solution. In the short term, we will be adding OpenStack APIs over Nimbula Director so that we meet the customer demand of OpenStack compatibility and so that our customers can leverage the OpenStack solutions ecosystem. While there are a growing number of OpenStack distributions, Nimbula Director will continue to distinguish itself in scale, reliability, operational excellence, a modern cloud networking model, and an authorization system that models real business practices.
  • Contribute: Nimbula has strong IP developed over the past few years that can be of use by the OpenStack project. We will start working right away with the OpenStack development community to identify and contribute code to improve OpenStack’s scalability, reliability, and security.
  • Merge: Over time, Nimbula Director will move from just having OpenStack APIs to ultimately sharing much of the core code. This will prevent duplication of efforts and will ensure quicker pickup of new OpenStack functionality into Nimbula Director as it releases.
  • Componentize: To the extent that Nimbula has functionality that we and the community decide is not part of the core of the cloud, Nimbula will separate out that functionality into modules for delivery both as part of Nimbula Director, but also as stand alone software that can work with other OpenStack distributions.

Customer Impact
While Nimbula will work as aggressively as possible to be a part of  OpenStack, our strongest commitment is to our existing customers. There will at no point be a regression in functionality or a let down on producing an enterprise ready cloud product. Nimbula Director continues to be Nimbula’s only product and we will make sure that the introduction of OpenStack APIs, functionality, and eventually code is non-disruptive and dealt with as just a part of the product upgrade process.

Closing
In closing, we at Nimbula would like to thank our customers for getting us where we are today and the OpenStack community for their warm and gracious welcome. We are proud to have had the support we’ve had from individuals, vendors, and the OpenStack Foundation itself. We are extremely excited about this new chapter and look forward to being a major contributor to OpenStack and its continued technology growth and market success.

Hybrid Cloud With Nimbula and Amazon Web Services

 

Executive Summary

Hybrid cloud and federation to Amazon’s AWS has long been a feature of Nimbula Director and a core part of Nimbula’s strategy.  Nimbula Director specifically provides a single interface for self-service access to public and private resources that unifies workflows, permissions, audit, all the while protecting corporate assets residing in public cloud from misuse by those who no longer require access to them.  The recent news and discussion on API compatibility is interesting to be sure, but practically speaking, is much less important than the actual hybrid cloud functionality provided by IaaS platforms.

Introduction

The recent announcement between Eucalyptus and Amazon about their API compatibility has confirmed the adoption of hybrid clouds. But does API compatibility really provide enterprise ready hybrid cloud on its own?

Having a single API is helpful to anyone integrating software on top of private and public cloud – although supporting a few REST APIs in a modular fashion is not terribly challenging for most programmers.  But what does API compatibility do in terms of helping enterprises manage multiple clouds end to end – the authorization model, audit capabilities, credential management, etc…?

This post describes Nimbula’s view on what is required for enterprise hybrid cloud and how we meet these needs with Nimbula Director and have been doing so since we released version 1.0 in March of 2011.

What Is Needed In A Cloud API For The Enterprise

An obvious question is why does Nimbula have a different API from AWS in the first place?   Isn’t AWS the de facto standard in IaaS APIs?  The answer is that Nimbula chooses to not constrain its capabilities based on the feature set of a single cloud provider.  Nimbula’s API exposes our differentiated functionality – functionality that we believe is required for adoption of cloud throughout an enterprise. Some of this functionality includes:

  • An enterprise identity and authorization system
    Nimbula Director offers a multi-tenancy model where each tenant has an administrator that can manage the tenant’s users and groups.   Groups are hierarchical collections of users defined so that permissions need not be assigned on a user by user basis.  Each action on each object can be delegated or not to any user or group inside or outside the tenant as collaboration requires.  Furthermore, the system is flexible enough to allow multiple layers of delegation (e.g. from cloud admin to tenant admin to team lead to end user). This provides security and flexibility in a way that closely matches enterprise needs.
  • Quality of service tagging of equipment and workloads
    Nimbula Director allows tagging of compute and storage equipment based on its capabilities.  For example, cloud administrators can tag some servers as “>2GHz CPU” or some storage as “DR protected”.  These tags can then be made accessible to various tenants, users, and groups via the permissions system.   In this way, tenants of the cloud can decide who can use what type of equipment based on the known needs and value of the work of the end users.   This keeps down costs as less critical work can be pushed to less capable equipment without sacrificing performance for critical work which can be directed to more capable equipment.
  • Quotas & accounting
    Users and groups can be given permission to charge their work against one or more accounts and draw against tenant, personal, or project quotas depending on what they are working on with each provisioning activity.  The separation of permissions, billing, and budgeting and the management of all three at a fine grained level allows for real enterprise management of cloud activity and resources.  It is also crucial for making self-service IT work within the bounds of enterprise accounting practices.
  • Flexible networking model
    While Nimbula Director offers a flat layer 3 network option with an extremely robust set of network services like self-service firewall, NAT, and DNS, enterprise and government customers sometimes need layer 2 networking as well.  Nimbula Director allows the allocation and deallocation of layer 2 networks to tenants via the permissions system.  End users can use one or more of these layer 2 networks with their instances as needed.
  • Cross-cloud orchestration
    Nimbula Director offers the ability to define, launch, monitor, and heal an application that spans multiple sites and clouds.  This includes management of instances, storage volumes, persistent IP’s, and network security rules between the various locations.

Hybrid cloud requirements

Given a private cloud with one API and one set of capabilities and a public cloud with another, how do customers rationalize the two to get a seamless experience across both while getting the proper benefits from each?  At Nimbula, we believe there are four key requirements, all of which are implemented by Nimbula Director.

The basic implementation mechanism for all four requirements is the layering of our enterprise cloud API and our authorization and permission system over the public cloud API and proxying commands from our API to our federation engine, to the public cloud.

Keeping public cloud credentials from end users

The end users of an enterprise hybrid cloud should never have access to the credentials of the public cloud.  When an end user leaves their employer, or simply switches to a team that is not authorized for public cloud, they should no longer be able to access the enterprises’ public cloud resources.

Nimbula Director manages this by giving the enterprise cloud admin the ability to setup the credentials to the public cloud and determine which tenants, users, and groups are allowed to indirectly leverage those credentials.  When end users use the public cloud, they do so by proxying all requests through the Nimbula Director API and federation engine.  In this way, they do not own the public cloud resources, the enterprise does.  The end users use only the resources allowed to them by Nimbula Director’s enterprise grade permissions system and only for as long as the business allows.

Single security model

In an enterprise hybrid cloud model, there is a need to restrict which cloud users can use the public cloud and which cannot.  The cloud and tenant administrators need to be able to restrict access to specific users and groups, adding them when they are on projects requiring public resources and removing them when that access is no longer required.  This security model must be unified across public and private resources to keep the process simple and secure.

Nimbula Director’s authorization system overlays on top of public cloud sites and objects so that end users are granted access to public and private resources in exactly the same way.  Administrators can use Nimbula Director’s permissions system to achieve the benefits of its granularity, flexibility, and selective collaboration for public and private cloud resources.

Single audit trail

In enterprise hybrid cloud, there should be one way across public and private sites to see who has permissions on what and who granted those permissions, who has provisioned which resources, and what calls have been made with what results.

Nimbula Director, by virtue of proxying all public and private commands through its API is able to provide this single point of audit to enterprise customers.

Single set of end user workflows

End users should have a single way to access cloud resources, be they public or private.  They should be able to use the same workflows for maintaining and managing images, launching and deprovisioning instances, and managing public IPs and storage resources across providers.

Nimbula Director, by virtue of proxying all public and private commands through its API is able to provide this single set of workflows to enterprise end users.  It is only a matter of changing a single flag in a command to direct the work to a different site or provider.

Conclusion

Nimbula believes that we provide the most complete hybrid cloud story of any IaaS platform provider.   Our more enterprise focused functionality and API along with our ability to proxy those capabilities over public clouds like AWS make for a complete enterprise hybrid cloud story that can be taken advantage of today.  API compatibility is nice and makes for great press releases, but it’s all about the functionality and whether your cloud has it or not – APIs can be rationalized with simple shims, but platform functionality does not materialize without support from the underlying platform.  When mapping out your hybrid cloud strategy, make sure to look for what will support your enterprise business needs in the long term rather than focusing on short term convenience.

Implementation Matters

At the recent Cloud Connect event in Santa Clara, a new theme for debate emerged: Open. From the tone of the conversations, it feels that “Cloud” has been talked about enough and the new buzzword for conversations is “Open”. While it is certainly a good point to discuss, I want to reflect on what seems to matter most to our customers: software that works out of the box as advertised, implementation and delivery of the promised features! We want to provide our customers with an Amazon EC2-like infrastructure cloud and believe we are delivering on it!

We have worked with a number of customers over the past few months and as they have purchased and deployed our software, here are the points they mentioned as important to them.

  • Easy infrastructure cloud deployment: visit the nimbula.com website, download software, load it and it works! No need to speak with someone in sales or go through a gatekeeper. Some of our customers came out to us when they were ready to place their order and only had a few questions left. They ran the evaluation and bake-off against other platforms on their own, referring to our extensive technical documentation! Who else gives you such an easy and direct access with a complete high quality set of documentation?
  • Complete end-to-end automation, right from installation to deployment: Nimbula Director’s API has enabled our customers to automate a great number of things and gain precious time. We decided early on to put more effort in a complete API than a shiny UI. Our customers have valued that choice and it has been great hearing from them: one of them, using their Nimbula Director private cloud for development and testing of new applications claims close to 90% time savings for one test suite alone.
  • Solid security model: Nimbula Director delivers a security model that allows for very secure collaboration between tenants. A recent project in the Government space with a very security conscious customer helped us validate our model and demonstrate our claims.
  • No hardware shopping list: Nimbula Director works on commodity hardware and you do not need to purchase specific equipment to get a good experience and be able to deploy it. We harden the operating system and hypervisor (shipped as part of our software) to bring out the best possible performance and security on any hardware platform. As a matter of fact, one of our customers shared the hardware they had bought and I could not recognize any of the names: pure commodity white box vendors.

Now back to the debate: Open is clearly important and I believe that means more than just Open Source. Open is also about platforms which have openness to extensibility and manageability. It is about giving a choice to the customer: use our software as long as we provide you with a great product and customer service. If you are unsatisfied or think another platform is better, you should be free to migrate and not be locked into our software. I do not think the debate is about open source or not. It is about value to customers in the long run.

But let’s not dwell on it because while debates are good and generate noise and buzz, there is much work to do. We want to keep our head down and focus on what we do best: innovate and deliver a great software experience that works out of the box. We are focused on strong core guiding principles for our development, our co-founder speaks best of them.

So don’t take my word on our software quality, give it a spin!

Cloud Computing: Challenges and possible solutions for digital forensics

One of the inherent benefits of cloud computing is to have efficient and optimal utilization of resources for applications. The pay-as-you-go model that cloud computing provides requires elasticity of these resources. Cloud computing provides a self-serve model with an ability to scale resources up or down depending upon the needs of the customers. NIST’s definition of elasticity is as follows: “Capabilities can be rapidly and elastically provisioned, in some cases automatically, to quickly scale out and rapidly released to quickly scale in. To the consumer, the capabilities available for provisioning often appear to be unlimited and can be purchased in any quantity at any time.” Enabling elasticity in the cloud strongly implies the use of virtualization of these resources. In Cloud Computing, elasticity of these resources poses a significant challenge with regards to the mobility of these resources across physical boundaries i.e. servers, switches and possibly data centers. 

The elasticity and mobility of resources coupled with the huge amount of data flowing in, out and within a cloud pose a significant challenge for digital forensics. Digital forensics  was originally used as a synonym for computer forensics but has expanded to cover investigation systems capable of storing digital data, which now includes the cloud. The cloud in particular poses some specific challenges for digital forensics. Waldo Delport and MS Olivier in their paper present the process for conducting digital forensics. A presentation based on their paper is available online. An instance or a group of instances would need to analyzed for a particular investigation. The process of analyzing these “crime” domains presents challenges some of which are listed below:

  • Identification of the location of a instance or a group of instances
  • Blocking and isolating traffic for a particular instance before the start of the investigation process
  • Guaranteeing non-contamination of the instance
  • Separation, i.e. data unrelated to the incident is not part of the isolation. 

Isolation of these resources during operations and during the forensics process in the event of a investigation is important. This isolation is necessitated due to the inherent multi-tenant and sharing of resources available in the cloud. It is required to maintain a successful isolation of a instance and to provide Confidentiality, Integrity and Availability (CIA) of the resources at all times. The data collected from the instances for forensics is not part of this blog post though Nimbula Director provides all the necessary data from the infrastructure for analysis.

Nimbula Director provides the following mechanisms to aid digital forensics: 

It provides a scalable and unique identification mechanisms for instances from the nodes across the clouds.

  • It provides the security mechanisms to blocking and isolating traffic. Nimbula Director has a highly scalable and distributed role based network policy mechanism. Security policies are defined and access between VMs is defined in terms of these policies, called security lists. In a cloud environment, where dynamic resource provisioning can see instances launched or terminated frequently, assigning an instance to one or more security lists enables cloud administrators or auditors to isolate instances at the behest of a API.
  • The role based and resource based object permissions systems unique to Nimbula Director enables cloud administrators to manage ownership of the instances and guarantee isolation in cases of audits
  • To extend the isolation of an instance or set of instances, Nimbula Director supports the ability to snapshot instances and tag nodes. A particular set of instances which are under the investigation can be isolated by moving instances under investigation to isolated areas or by moving other instances to other nodes.
  • All critical events and configuration changes are logged to enable postmortem of specific instances.

Nimbula Director supports these advanced mechanisms using RESTful APIs which makes it easier for cloud administrators or cloud auditors to develop digital forensics auditing and data collection mechanisms in a programmatic way and enable automation for digital forensics.