History and vision of Nimbula Director

I decided to write about Nimbula, because it is practically the only Virtual Hosting provider that I closely worked with. As I was testing a solution that is based on Nimbula while working in EPAM, I currently have some thoughts to share about it. So, let's start with the overview of what it is.

Based on information from this page, Nimbula is a relative of Amazon Web Services. If we take a look back, we may find that Chris Pinkham, co-founder of Nimbula, was an Amazon engineer in early 2000s. And it was his idea to create an infrastructure layer for web-scaled Amazon platform, which later extended to public in 2006. The whole idea was to drop down costs and decentralize the infrastructure by providing services to development teams. By no means Pinkham thought it was only Amazon that he was developing and building the service for, he hoped it would expand to developer teams all over. So the first and basic virtual-hostingAmazon EC2 service was developed by Pinkham and other engineers, including Christopher Brown and Willem Van Biljon in a satellite office. Just as it was ready and started to be involved in real-life activity, hosting and development, they realized it can become a meaningful business. Further history of success for Amazonis pretty clear and can be found online, if needed. However a major point is the split of two company-level-headed directions, but not the cloud architecture ones. For whatever reason, Pinkham eventually leftAmazon for Nimbula, a service and company that practically brings AWS to private cloud.

Let's take a closer look at differences and similarities between those two:

Nimbula utilizes the same concept for launch plan as Amazon, which allows you to create multiple instances of same configuration and launch them simultaneously. By the way, it is interesting to mention here a small off-the-scope tool that takes utilization of launch plans even further. It allows you to run multiple instances with different configuration, shape and machine image and is being developed by EPAM Systems, Inc.. The name is Orchestrator. It gives you additional flexibility in one-click configuration of base environments where a combination of different machines is possible.

Next is using a set of preconfigured image lists to launch instances based on. Nimbula and Amazon have sets of different OS types which are being installed on previously launched instances, those like Linux or Windowsimages. Both allow for adding new custom machine images that might have unique configuration and were created by you.

Similarities also include security rules and lists regulating connection to your instances and communication between them. For example if you have a public IP assigned to your instance, which is another service fromNimbula and AWS, you can set rules for accessing this machine.

If you require a secure, reliable and persistent volume, attached to your instances, both companies provide that ability. The only difference you can find is naming for those services.

You can take a more detailed look at all Nimbula technical capabilities here.

On the other hand, Nimbula introduced user groups to make its services more valuable for private customers, which is pretty logical.

Over the time Nimbula has improved its services and reliability. They added comprehensive CLI tools, started to support NAT services since ver. 1.5 as well as features. Those interested can check out the full information on versioning and release history here.

By releasing ver.2.0, Nimbula has unified itself even more. Addition of VMware support as well as AWS API utilization stand for that point. However, there are valuable improvements and additions, worth looking at.

As you can see, Nimbula has many similarities to AWS, so if you are an Amazon customer and ever thought about moving your infrastructure to a private cloud, you might want to take a closer look at Nimbula as your application's architecture will not have to be changed dramatically due to many crosschecks in these two. In addition to that - some of Nimbula's "out of the box" services are charged for by Amazon. Simple virtualization is packed by additional storage volume and many other services. At the same time, the costs are sometimes even lower which is explainable due to private direction of Nimbula.

If we take a look at names and brands, which are already hosting their environments with Nimbula, we can find the US Government and a Russian company that operates on Internet market. From here we can understand that Nimbula is a serious player on the Cloud market. Surely, there are still problems to deal with. And head problem is that Nimbula is accessing the potential market too slow and too late. I mean, players like Amazon, Azure and VMware have already split the cake and each has its own set of clients. It's really hard to make it to the market and become a valuable player with competitors like that.

This is where Nimbula should become unique. It has to come up with a solution and quality of services that can beat and surpass those, offered by competitors. I mean, in your marketing and sales support you cannot always rely on a fact, that your product was developed by a former AWS big player. There has to be a feature or a set of them making Nimbula one of a kind valuable Cloud service, interesting for customers.

As a conclusion, I would say that looking back at history and understanding the role of Nimbula's founder in developing now successful Amazon EC2, you can be sure it is worth looking at. Technology, concept and services are basically the same, which makes back-n-forth migration possible. At the same time, Nimbula lacks something new and valuable to introduce. In my opinion, right now it is "just another" Cloud IaaS provider.

EXPLORING THE CLOUD USING ORCHESTRATOR

You might have read my post about setting up your own instance in Cloud using Amazon Web Services (AWS). Well, recently I started a little research project that required me to use 2 machines in Cloud. One with Windows Server and another with SQL. I need them to be fast, reliable and stable, as well as a possibility to run clones of this environment easily.

EPAM Cloud has caught my attention in scope of my goals. They say I can have access to my environment anywhere, login with PMC credentials to view current status, and start or stop instances even from my iPhone. Sounds pretty awesome!

There is a so called 'Four Buttons' activity introduced in scope of managing environment under EPAM Cloud. Actually, EPAM's Cloud solution is called EPAM Cloud Orchestration Framework or Orchestrator.

So anyway, Orchestrator was designed to accommodate every single thing you need to manage the Cloud. And manage it on your own, control it, monitor and support it on the go, without any additional skills or software needed.

It's a little different from Amazon Management Console, which is reasonable. The whole ideology of EPAM cloud is there are four main actions in managing your own environment - Activate, Setup, Start and Stop.

First of all you need to Activate your project, that's what they call it. In reality, you just fill in the so called 'Onboarding Activation Form', and send it to one of Consultants or Datacenter Admins. The form is simple, there is no need to provide an example here, all that is been asked are your contacts and a name for the future Cloud of yours. In a few hours they will provide you with link to the web site and credentials for access.

You log in and what you see? Really simple user interface. I like the colors, like the design, it looks fresh. It's always good to work with good-looking software, isn't it? Well, that is the case here. Back to the point however. In your initial email, with that Activation Form, you might have also stated the configuration you want, like OS type, Shape of instance and their quantity, etc. If so you'll be able to see it running by now. But that is not interesting, right? I want to do it on my own, want to change it the way I need to. That is the whole point!

So I start setting it up. To do it, just click the Setup button and a friendly wizard will pop-up. I have to say here, that Help materials on every wizard are really comprehensive and explanatory. Basically, right now you are creating a Template of Cloud Hosting Plan, which contains the info about your instances and services, monitoring policies, login credentials and storage sizes. This Template is saved so it can be re-used again if needed and I find it very handy. Who knows what can go wrong, right? And if something does go wrong, environment can be re-launched or cloned with one click.

I'm not going to guide you through the whole process of setting up the Template, why? I will just say that every step is dedicated to single selected service that you need to configure. It's all done with clicking on checkboxes to enable/disable something. Or adding rows with predefined Network Protocols to Security Lists for example. And sure selecting amount of storage you need as well as OS type. It is all very easy and no special skills required.

However, there is something important about Templates. On Step 1 you select it to be Static, Dynamic or Custom. Static means that you will set up the environment, run it and will NOT be able to scale it. If you need it scaled you going to have to build it from scratch again. Dynamic allows for scaling, adding and removing things, so if you need that in the future, choose this option. Custom is designed to give you more flexibility when you switch the ignition and power up, like entering Load Balancing IP or choosing additional storage size for every instance.

I actually like the whole idea with wizards, it gives you the same feeling as when you are new to some software that you want to use, still it has to be configured previously and you don't really know how it's done. But the wizard is there to help you. I feel more relaxed in these, because I know I cannot break something.

When you done and saw the Successful message, you can proceed to actual run of your environment. Just as it was with Setup, it's a Run Wizard. Depending on what Template you used, you will be asked for some additional configuration or just for a Stage name. Stage can be referred to an environment with multiple instances under it, like a QA Stage or DEV Stage. Sure, no one is restricting you with names, enter anything you want.

And there you have it! Running instances. Configured, monitored and shaped just as you want them to be. You can view their network and CPU load statistics on the Monitoring Tab from Orchestrator; you can access them with single click from Management Tab with Console button or report an incident if something's malfunctioning. Really easy, very user-friendly and smooth.

Want to perform instance change, like adding additional storage or changing its Internet IP? No problem, Change wizard is there to help you. Want your colleagues to have, let's say, restricted access to this console? You name it, Users wizard here. Even logs and events can be viewed from here. Trust me, it is awesome.

In comparing to using AWS and Orchestrator I liked the later better. I mean, come on, I don't always have my laptop or a 22-inch screen computer available for solving things with running environment, and that's where Amazon can't help me, its interface barely usable from any mobile device. Orchestrator on the other hand lets me utilize everything from iPhone in my pocket, anywhere, which is really cool! Also, AWS is too big, it's costly and enforces you to read a lot of guides and documentation. I don't really want to do that, don't want to remember all of specific terminology and Service Names. And that is where EPAM Orchestrator has a better approach with wizards and list of events. At the same time it's just as elastic, flexible, reliable and scalable as Amazon.

Finally - the Stop action. If you want your instances stopped, just choose its name from the Stop wizard drop-down menu and click the button.

Like I said, easy, good-looking, stable and safe. That's all about EPAM Cloud Orchestration Framework. I had great experience using it and will continue to do so. Thank you for reading!