Top 10 Best Practices Using VMware VI and vSphere SDK (part 2)
#6 Consider Views in Your GUI Application
Most developers don’t know much about the View and related managed objects. The reason for that is that they were mainly designed for VI/vSphere Client in the first place. But nothing stops you from using it to your advantages.
Time to learn how to "Google" and manage your VMware and clouds in a fast and secureHTML5 App
As you can imagine, you can use the View and its subtypes InventoryView, ListView, and ContainerView to monitor changes on the server side. It provides an efficient way to monitor for changes with only these visible in your GUI and nothing more. You can use ViewManager to create views according to your specific needs.
Note: There is a confusion with the views in the VI Perl. The View in the SDK itself is a managed object type that only exits on the server side; while the view in VI Perl is a mirrored copy of a managed object on the client side. They are two different things and used for different purposes. If you have used VI Perl before, pay extra attention here.
#7 Secure Your Applications
In general, you should use HTTPS over HTTP even if you work inside your enterprise network. HTTP traffic can be easily monitored by any network sniffers. Also, you should set up privileges, roles, and permissions to manage the access of the login user using your application. It’s partially administrator’s work, but you have to keep that in mind.
When it comes to a server application, the problem could become complicated. On one hand, you don’t want to create a session for each active user and leverage the built-in security management by vCenter or ESX/ESXi; on the other hand, you don’t want to grant everyone root or administrator privileges. You have to work out a mechanism to manage these in your application.
If your applications focus on very limited aspects of the system, you can actually create a new account just for the server application with only required privileges. For example, a performance analysis application that only need to read performance data. You can create a special account and grant only these privileges for reading performance data. If for whatever reason, the account info is leaked out, the impact is limited.
#8 Code With Performance In Mind
There are two things in scope. One is the performance of your own applications. You want snappy responses for sure. The other is the impact of your application on the server side.
Getting performance data can cause performance problem at the server side. You should limit the scope to the really necessary metrics on smallest set of managed objects with smallest time period you care about, and the coarsest grain you can accept. Format wise, you should use CSV format over normally array. Why? XML serialization and de-serialization are not efficient, and using CSV can avoid a little work there.
Another rule of thumb is you don’t fetch the same data from the server twice when performance becomes an issue. You should then consider creating a local cache. It can be error prone of course, so do it only when you have to. If you use VI Java API, you can leverage its caching framework which has been used in commercial products.
#9 Manage Your Sessions Carefully
Session management could be tricky in some circumstances. The rule of thumb is to keep as few concurrent sessions as possible. Some server applications can easily get into performance problem by creating a new session for each user as described in this blog.
Even if you don’t develop a server application that serves many users, you can still get this problem. For example, you may forget to logout a session in your code and run your application many times for testing. If you don’t explicitly close a session, it times out and disconnected by the server in 30 minutes. When you do many tests in short periods of times or you have created many sessions in a row programatically, you may accumulate too many. Remember, your application may not be the only client to the server — others may run vSphere Client or other applications against the same server. So log out your session when you don’t need it.
#10 Use APIs/Toolkits For Higher Productivity
The basic Web Service APIs are not developer friendly. By its nature, the Web Services is procedural, therefore you cannot leverage the benefits of Object Oriented programming even if you are using Java. Also, the original PropertyCollector is super powerful but pretty hard to use.
To get around these problems, you want to build your application on a higher level APIs instead of the basic Web Services. There are several choices:
- Open source VI Java API (Disclosure: I am the creator of this API)
- VI Perl
- VI C# API (an open source project by Andrew Kutz)
Note: a lot people know PowerCLI, but not the underlying .NET binding. I may talk about it later.
Now, I’ve gone through these best practices. How many of them do you follow in your applications? It’s time to check it out. Remember, every application is different and you got to decide what’s the best for your project.
More details can be found in my book published by Prentice Hall.
BTW, I just got a twitter from Luc Dekens (@LucD22) who just posted a follow up blog: PowerCLI and the SDK – part 3 – Steve Jin’s best practices. Thanks Luc!