What guides us when we build Nimbula Director?

When we set out to build Nimbula Director we did so with a vision that continues to guide our product development.  We wanted to build software that would allow our customers to build the largest private or public clouds in the world, and to put their workloads on there, no matter what those are.  This overall vision translates into a number of guiding principles in our engineering efforts: We need to engineer for large scale and maximum uptime; we need to ensure true multi-tenancy with self-service by, and collaboration between tenants; we should realize that these tenants will have workloads in many clouds and so we need to provide federation to allow them to view the panoply of clouds as one cloud; we should support whatever applications they wish to put on the cloud; and we should allow customers and third parties to extend the capabilities of the cloud in a way that is secure and seamless.

These are all tough things to tackle, and we consciously set the bar high, but we believe we have made great progress in all of these areas, and if you pull back the covers on Nimbula Director, there are features and capabilities that can be traced back directly to these principles.  Let’s take a look at some of them.

Building for scale and reliability requires both an architecture that is designed from the ground up to achieve this – neither can be retro-fitted to a system that does not have the inherent capability to scale.  Nimbula has built a self-healing distributed control plane that can scale with the size of the cloud, and which automatically recovers from failure, with no operator intervention.

Multi-tenancy is not just about ensuring that different users can launch virtual machines.  It is about ensuring that the right individuals in different organizations have the correct rights to access and share appropriate objects in the cloud, and it is about ensuring that dynamic networks can be created that protect different users’ traffic from one another.  Nimbula Director offers a very rich, innovative and scalable permissions system that allows user admins to control user actions, and object owners to manage object access.  We also allow virtual machine images to be versioned with a mechanism we call image lists so that when executable images are shared the underlying detail of versioning and bug fixes can be hidden from virtual machine users.

Our network security infrastructure allows virtual machines to dynamically join or leave layer 3 network security domains – which we call security lists – in a manner that is completely independent of the topology of the underlying network.  This is critical in large cloud deployments where logical, and not physical network architecture matters.

All of this, the management of permissions, the establishment of network security domains, the association of virtual machines to image lists – in fact every feature in Nimbula Director – is accessible through our API.  The entire system is built to allow self-service.

As mentioned, we also recognize that customers will want to place workloads in many different clouds.  Nimbula Director provides a number of capabilities to allow customers to forget about the seams between these clouds – the ultimate goal is a world that looks like one cloud.  Today we provide identity that spans multiple Nimbula Director installations, and the ability to launch workloads across those, whilst preserving customer permissions and access control to objects.  We also extend this to the placement of workloads in non-Nimbula infrastructure – currently we extend the identity and permissions mechanism to allow control over workloads in Amazon’s EC2.

Customers will deploy many different types of applications on the clouds that they use.  These applications may be the Web 2.0 scale-out fault-tolerant type of applications that are perfectly suited to the cloud, or they may be more traditional enterprise applications that have been around for many years.  They may also be applications that were developed on a platform for the cloud, like CloudFoundry.  As we expand the capabilities of Nimbula Director we are continually making sure that we address the needs of a growing range of application types.  Web 2.0 type applications need the core services only: secure networks, scale, self-service and so on.  More traditional applications require further support, particularly when the application’s executable code and data are intertwined.  In this case the capability to boot images from persistent storage, and to snapshot them, become critical.  In addition, the ability for the cloud infrastructure to monitor and restart applications for high availability also becomes desirable, which we support through an innovative new construct called orchestrations that allow complete applications to be specified, launched and managed by the system throughout their lifecycle.

Of course, we realize we cannot build all of the features necessary to address all of the applications in the world, so it is important to ensure that capabilities exist for other developers to add this seamlessly to the system, whether it is database services, messaging services, big data processing or others.  To this end we have built a Service VM infrastructure which allows virtual machines that provide these services to be launched and managed securely in the cloud, whilst having their APIs integrated to the Nimbula Director API in a way that makes it seamless for users to integrate with both the cloud and services built for it.  This is ground-breaking, in that it allows an ecosystem of developers to enhance the services that applications can access in the cloud in a way that is completely integrated with the cloud itself.

As we continue to build out Nimbula Director we will continue to use the guiding principles to help us innovate in ways that serve our customers and allow them to build large, scalable, secure and reliable clouds.