#7 Levarage vApp
Lost VMs or Containers? Too Many Consoles? Too Slow GUI? Time to learn how to "Google" and manage your VMware and clouds in a fast and secure HTML5 App.
vApp is a new addition to vSphere. It’s essentially a group of VMs that work together as a solution. You can manage them as a basic unit like a VM. It provides you higher level granularity for resource allocation and management.
This is an ideal container for your application if you have multiple virtual machines involved. They may or may not form a cluster, but are bundled together for a same goal.
The vApps are not only easily managed by the vSphere, but also imported and export as a bundle. Therefore you can easily move it without worrying what should be included while copying it.
VMware provides tools like VMware Studio using which you can create and configure vApps easily. The VMware Studio has Web based console, customization and build engine, build process automation with CLI (command line interface).
Other alternatives include:
- CohensiveFT. http://www.cohesiveft.com/vmwareready
- JumpBox. http://www.jumpbox.com/poweredby
- rPath. http://www.rpath.com/corp/products/rbuilder
- SUSE Studio. http://www.susestudio.com/
- VirtualAppliances.Net. http://VirtualAppliances.net
If your delivery is a product, I highly recommend you to list it at VMware Virtual Appliance Marketplace. More information can be found here.
Virtual appliance and vApps are not VMware proprietary technology. The DMTF (http://www.dmtf.org) has standardized it with OVF (Open Virtualization Format). OVF is not about virtual machines but the metadata that are used to specify the spec of virtual machines or vApps.
With OVF, customers can specify virtual machines from different vendors like VMware, Microsoft, XenSource with same XML metadata. It’s supported by all the major vendors today. Note: OVF does not however cover the disk format, therefore you need disk conversation tool to import different VMs to your platform.
You can find the full spec here. It’s at version 1.1.0 as of this writing, and keeps evolving.
＃8 Streamline the Packaging and Deployment Cycle
Traditionally applications can be packaged as executable files, *.rpm, *.zip, *.jar, etc. You can simply unpack them and start to use.
Some applications like these on Windows platform, application installation could be painful due to the use of Windows Registry. Therefore a new category of software came in to help, like InstallShield, Microsoft Installer, etc. You have to follow certain steps, and sometime writing scripts, to package your applications into an installer.
With virtualization, you have at least three more choices:
- Application virtualization. You can package your applications using VMware ThinApp, and you don’t need to install them anymore. Other vendors like Microsoft provide similar technologies as well.
- Virtual machine. You can pack everything together and work as it’s once it’s uploaded to the hypervisor. You may need to answer several questions like your new password, hostname, IP address, etc. The interaction is really minimal.
- vApp. As mentioned earlier, it’s really a group of virtual machines. They can be bundled together and shipped as a single unit.
“What should I use? “ You ask.
It really depends. You have to decide a solution best for your architecture, and design installer accordingly if needed.
One thing is particularly important here. No matter what approach you use, you must test the products from that approach. For example, if you decide to ship a virtual machine, you must test the virtual machine. You can simply assume the application because it works after you unpacking it from the build system. It also means your build system should be implement the automatic build to create the virtual machine, not just the application jar files for example which could be an intermediate product during the overall build process.
In general, you should loop in your build team and QA team as early as possible. You can avoid many pitfalls before it’s too late in the development cycle.
#9 Manage Your Applications
When your applications go beyond one machine in the cloud, the manageability becomes important. For one thing, you want to monitor how your application is doing.
In particular, you want to know:
- Are the application instances still up running? If not, you want to restart them as needed.
- How does it perform? Is it under provisioned or over provisioned? You then need to scale up/down or out/in accordingly.
Beyond these, you may also want to run your applications based on certain rules or policies. For example, if the charge rate is lower, you can submit the batch processing tasks at night instead of day time. There are many other rules that you may want your applications to follow.
In general, there are two approaches: external and internal.
The external approach relies on the other management solutions from VMware or other third parties. Some of the examples are:
- CapacityIQ. It helps to monitor the resource usage of the system, and forecast the future demand on the physical infrastructure like storage.
- AppSpeed. It monitors the performance of the applications based on the network traffic. It’s not intrusive as other solutions which inject code for monitoring.
- Hyperic. This monitors and manages the system as if they were running in physical machines. It pushes in agents for reporting stats back to the central management server.
The internal approach is to have a mini management server built in your application. Deployment wise, this mini server does not necessarily reside together with your main application. This of course means more efforts. But your application can make sense the most of the data it collects. The application can then decide when and how to scale, whether it should reboot certain virtual machines.
With vSphere APIs, your application can also get stats from the underlying infrastructure perspective. Combined together with the data from the application itself, your application can make better decisions.
It’s important that your management component should not be mixed with your core application. In case the management piece fails, it won’t affect the operation of your application except that you may not be able to monitor or provision new instances for scaling, etc.
The other alternative API is the vCloud APIs, which is regarded as “driver seat” APIs versus vSphere API as “under the hook” API. You can get most of the tasks done as application developers, but avert from the complexity of hypervisor level details.
#10 Keep It Simple
Architecture design is mainly for planning the system, not the building of the system. A good architect must keep this in mind. She should also have hands on experience that have gone through whole development cycles at least once before. Without this experience, it’s hard to understand what architecture means for the project.
One big rule, although coming last, is to keep the design simple. It means you should start from small and grow organically, not the other way around. In my 15 years experience of software development and architecture, I have seen many projects failed because the teams over-architected the system to the extent that there are too many layers, too many abstractions for most team members to fully understand and implement. Grabbing individual design ideas out of the project, they are all good. Putting together, they are really bad as a whole.
Every abstraction, layer, or architecture flexibility has its own price on complexity and performance. It leads to more development efforts, steeper learning curve. At certain point, the project just loses control.
The rule of thumb is to add more only when it really buys you even more. It’s always hard to decide whether it really buys you more in real projects given that many people have different backgrounds and different levels of expertise.
When in doubt, the wisest thing you can do is to postpone it.
Architecture matters and even more for AFCs. A well designed architecture guides the project team in a right direction that results in solid deliveries in the end. I couldn’t emphasize the importance of architecture work more.
I have gone through 10 design best practices for architecting your applications for the cloud environment. They cover basic aspects of architecting. I hope they provide you the thought food for your future projects.
Before applying these principles in real projects, remember that NOTHING IS ABSOLUTE. You have to use your own judgment in reality. That is why experience and expertise come to play, and still highly valued in our industry.
I would like to thank my colleagues Manish Bhuptani, David Deeths, and Charles Lee for providing feedbacks on my presentation on a similar topic at VMware PartnerExchange 2010. The feedbacks are inherited in this article. Any errors are my own however.