Home > Cloud Computing, Software Development > Top 10 Best Practices Architecting Applications for VMware Cloud (part 3)

Top 10 Best Practices Architecting Applications for VMware Cloud (part 3)

March 19th, 2010 Leave a comment Go to comments

This 3rd part contains best practice No.4 ~ 6. To be notified for the rest, feel free to subscribe to this feed, and follow me at Twitter.

#4 Scale Applications as Needed

Time to learn how to "Google" and manage your VMware and clouds in a fast and secure


Most time, people think scalability is to handle more workload when needed. This is true, but not enough. A truly scalable system should scale back. This is how you will save money. This is equally important as the first case where you get more revenue by serving more traffic.

There are different ways to scale:

  • Up and down. This is unique in virtualized environment in which you adjust the memory or CPU allocation and use more or less of them instantly.
  • Out & in. This means you include more machines either physical or virtual into your application.

You have to think over several architecture decision points:

  • Multi-tiered topology. It’s a general good practice to divide your application into web tier, application tier and database tier in a large web based application. These tiers are not equal to the virtual machines. Initially you can just run all of them on a single machine, and then transition to multiple machine instances as the demand rises.
  • Distributed caching. For most distributed system, the bottleneck resides mostly with the database where read and write are expensive compared with memory operations. Having a caching system in the middle can boost system performance dramatically. This may increase your investment and system complexity, and you want to have this option open but not necessarily implement in the first place.
  • Directory services. When many instances of components are involved, you would want to have a directory service so that they know where to ask for information. It can reduce your effort to manage the information by your application itself.
  • Messaging service. This can help to decouple your application to the extent that each component doesn’t need to know each other but still work together seamlessly. This become even more important for inter application communications which you may not have control over for example what applications are currently running. Messaging services can save the messages and deliver them when the target applications come up running.
  • Data services. You can have many choices for data services, for example SQL database and these new non-SQL storage systems that become popular in web applications. Many cloud service provider provides data services which you don’t need to know details but the APIs to interact with them. Inside the enterprise, you have to think about your own data service model if you want to take similar approach. Using traditional SQL databases like MySQL could be a good choice depending your requirements and expertise.

There aren’t clear cuts on these decision points. You want to do your own homework on both the technologies and your projects to see where and how they can meet together to solve problems.

#5 Design With Failure In Mind

Applications fail anyway regardless it’s virtualized or not. This is the norm of application lifecycle. Two possible causes are the underlying infrastructure and the application itself.

The underlying infrastructure includes the physical hardware including the peripherals, the hypervisor including the software drivers, the operating system, and any middleware that is below the application. Any single point in this chain can fail the application. Yet another reason you want a real “giant shoulder.”

To guard against the infrastructure level of failure, you can have the following alternatives:

  • HA. This is a cluster in which any member hypervisor fails, it powers on all the VM on the failed hypervisor on other hypervisors. There is a period of downtime (approximately the time to detect the failure plus the time to power on the VMs) and state of the previous VM cannot move over to the newly started VMs. To use these for protection, you want your application stateless.
    Due to the downtime, this is not for mission critical applications.
  • FT. This is two-machine cluster in which every instruction executed on one virtual machine is passed to the shadow VM that is always ready to back up any time. This is 100% protection against the underlying hypervisor or hardware failure.
  • SRM. This is used to back up system for unexpected disasters that could ruin the whole data centers away. The remote secondary data center can take over upon manual interaction.
    Given the effort, the scope of backup sometime are restricted to mission critical system and data.

Now if you have your infrastructure protected, will you still have failures?

The answer is sadly yes. Your OS, middleware and application can fail too. In the FT case, if your application fails in one VM, it will fail on the shadow VM, guaranteed! Otherwise, it’s not FT.

So from your applications, you must have designs in place to protect against failures in your applications.

Here are several things you want to follow:

  • No single point of failure in your application. If any components fail, others can still back it up. To achieve this, you need to examine through your system on both data flow and control flow. For some applications, it may be OK to have certain transactions fail, but you must not have the whole tier fail. In a shopping web site, it may be OK, not ideal of course, a customer’s session get lost somewhere, but the whole database tier cannot be down that brings down the whole site.
  • Resilient to rebooting or re-launch. It’s best if your application is stateless and ready to serve upon rebooting. If there are certain things it must perform, it’s better to have a start-up script doing all these automatically.
  • Persists as it goes. You should not keep mission critical data in the memory only. You can cache them some way for better performance but it must be persisted in either database, data services, or even file system like journal file system.
  • Periodical backup. The targets for backups include virtual machines, applications, and data. If you have stateless VM, you less likely need to back up the virtual machine. If you have your application installed from formal release, it’s unlikely that you need to back it up unless you have made significant changes which I don’t recommend. The last item should be back up for sure – this is mostly the only thing you need to back up from a well architected system.

Again, you can avoid application failure but you minimize the potential damage. This has to start from architecture design.

#6 Secure Your Applications

Security has been a concern from the day one of computer history. It gets more attention when the networking and Internet became popular. This concern will be there forever.

In cloud computing, we definitely have new challenges here. When thinking about cloud computing, one may be wondering,

“Where is my VM running?”

“Has my VM been copied by anyone?”

“Have the messages to the VM intercepted?”

There are many possible solutions, very similar to what you can think of a well designed distributed system.

  • Distribute the data. This is as simple as the old saying, “Don’t put all your eggs in one basket!” Easier said than done in reality. You have think to think how to divide the data so that single piece of them cannot render the whole picture. For example, if you distribute half of the credit card numbers in one database while the other half in another, it works but is not a good solution. Anyone steals the half can still use them maliciously.
    But if you put first 8 digits of the card numbers in one database and the rest 8 digits in another. If someone gets one database, it’s not that useful.
  • Encrypt critical data transparently. It takes much more time than using clear data depending on the encryption method and length of the key used. Given the performance impact, you don’t want to use too much, but the critical data that you cannot afford any leakage.
    You still want the clear data support because it’s very helpful in the development time. Ideally you should have a way to plug either of the clear data and encryption data without much effort.
  • Secure VM templates. You want to close all un-necessary services and ports from the very begging in the template. When new VMs are cloned from them, they are secure.
    In general, you want to play a little conservatively. When in doubt whether a service should be open or not, choose not. You can always open it when needed. But if you open it in the first place, most people will just forget about it’s actually open.
  • Secure communications. At the network level, you should use vLAN feature that isolate the network to limited parties involved in an application. At the VM level, you should turn off the promiscuous in the virtual NIC so that the virtual machine cannot overhear conversation not targeted to it.
    At the application level, you can use secure socket layer (SSL) for your communications among the components or with external applications. High level protocols like HTTPS are recommended due to its simplicity. HTTPS is also inter-changeable with HTTP which you use at development time.
  • Secure the virtual environment. You can put on strict authentication and authorization with vCenter so that only authorized persons can access the related virtual machines and applications running there.
    For the super security system, you can also disable vMotion so that it won’t move away from certain hypervisor. But it’s not recommended.

Security is a big concern and continues to be forever. While trying hard to make your applications secure, you don’t want to overdo it because of the complexity and efforts.

  1. No comments yet.
  1. No trackbacks yet.