Disaster Recovery as a Service (DRaaS or RaaS) is big on the hype meter right now, and cloud computing providers are clamoring to find solutions to fill the gap. The biggest driver in DR in the Cloud is the utility-like aspect of purchasing infrastructure, because you only pay for what you use. Disaster Recovery lends itself well to the concept of cloud computing, because you want to keep that insurance premium as low as possible. Virtualization has enabled some pretty amazing things in regards to Disaster Recovery as well. Recovery time objectives (RTO) and recovery point objectives (RPO) have dropped significantly since virtualization became mainstream, without adding cost. 

On to the practical application: How on earth do I replicate my data to a public cloud provider?

Replication is essential to a low RPO. Doing full backups across a WAN link is going to result in a lot of data loss. There are methods to only replicated changed blocks, but even then you could have some pretty hefty loss.

Here are the 4 levels of replication currently out on the market:

Application

Replication at the Application level has been around for some time. Relational database servers such as Microsoft SQL are a good example. You can replicate database transactions to a remote server, and restore the database when disaster strikes.

Pros: Public Cloud-friendly, very low RTO and RPO, can be physical to virtual, or any combination of the two.

Cons: Target server must be running in the cloud. OS and application must be set up properly and maintained (patches, OS, etc).

Guest OS

Vision Solution's Double-Take product is a good example of this. The OS, application, and data can all be replicated on a block-level basis to a target machine. The OS files are "staged" on the target machine, and upon clicking the failover button, the target machine "becomes" the source machine. Pretty cool technology indeed.

Pros: Public cloud-friendly, Low RTO and RPO, physical to virtual, or any combination of the two. One click failover.

Cons: Agent overhead on source machine (CPU, Disk and Memory), license cost, target server must be running in the cloud.

VM/Hypervisor

There are two strategies at this level. The first is snapshot based replication. Veeam is a good example of snapshot-based replication. A virtual machine snapshot is taken, much like a normal VM backup is taken, and the changed blocks are replicated to the target VM.

Hypervisor-based replication is new to VMware vSphere 5. ESXi 5 now has a low level driver to capture VM disk data writes at the SCSI level. This is incredibly cool because it means I don't need to rely on snapshots. VMware SRM VR takes advantage of this, as does the ultra-cool Zerto.

As we move down the stack, this is the first replication level we have to think about VMware vCloud Director and it's meta-data. At the time of writing this blog post neither VMware's VR or Veeam replication have solutions for vCloud Director. Zerto supports vCloud Director in both private and public cloud scenarios.

The challenge for DR to public vCloud providers is direct access to the SAN. Most of the hypervisor level replication solutions have been built around the enterprise, not around a multi-tenant cloud. The public cloud is certainly NOT going to give you self-service, open access to the SAN.

Pros: Public vCloud friendly (Zerto), very low RTO and low RPO replicates entire servers, storage agnostic, target VMs powered off and not consuming resources.

Cons: NOT public vCloud friendly (VMware SRM, Veeam), Snapshot rollups can hurt performance (Veeam), virtual only, not hypervisor agnostic.

SAN/LUN

SAN-based replication is a great solution for Enterprises looking to back up all or part of their infrastructure. The source and target in this case is not a VM though. It's an entire LUN. Typically you have multiple VMs running on a single LUN, which is nice if the group of VMs require data/time consistency. VMware SRM uses SAN replication to achieve a fully orchestrated DR solution, and even physical servers with disks on the SAN can be replicated.

As stated previously, no public cloud provider is going to give you access to the SAN, which leaves you needing to buy another SAN of the same make and model, and slap it in a colocation rack.

But wait...SAN vendors also have virtual storage appliances (VSA), which DO run in the cloud. So if you run SANs such as EMC, Nexenta, or HP, there is a possibility you could at least get your data off-site. The only challenge there is you can't run the VMs in the cloud from the VSA. There would need to be a seperate script to migrate VMs from the VSA to the public vCloud provider through the vCloud API. It's not impossible, but it would certainly add some time onto the RTO. 

Pros: Public cloud friendly (maybe with a VSA), Low RTO and low RPO, replicates virtual and physical machines

Cons: NOT public cloud friendly (hardware SAN-to-SAN), NOT hardware, SAN, or hypervisor agnostic.

Don't forget Failback!

Just an additional note that you should always ask about how to failback once your primary site is healthy. You don't want to be stuck in DR mode forever, and most of the above mentioned solutions require full replication of the systems back to your datacenter. Make that a top ten question when looking for a DR solution. The Disaster Recovery is not complete until you are back in your production datacenter!

 

The Cloud Wars have already begun and as in all conflicts, the most unfortunate incidents are caused by friendly fire. From a cloud computing perspective, it occurs most often when people who want to try or have tried public or hybrid cloud are challenged by peers or counterparts in their own companies. 

I’ve been thinking a lot about the challenges my fellow technologists have experienced in trying to sell their public, private or hybrid cloud initiative inside an organization. I also realized that not only was this a difficult task for them during their initial project, but that they are compelled to continue to justify their cloud initiatives on an ongoing basis. I know that in most situations the team that needed to be convinced of moving forward with a cloud project was corporate IT. In some cases the "cloud champions" were trying to convince the CIO to try something new. In some cases a cloud committee or cloud strategy working group was already working on it and the project was a distraction to their process, or it ended up under a microscope as a learning opportunity instead of the business critical application that it was for the department. In other cases it was actually IT leadership trying to encourage their teams that the old world might be changing, just a little bit, but the going was pretty slow because no one was really sure what that meant.

In each case a lot of the core challenges were similar but there were also some differences.

Most of my fellow technologists were headed to or ended up in the cloud in the first place because they needed or place a high value on agility. I define agility as being able to:

• Act quickly
• Deal with the unknown
• Change your mind

And they generally felt like going outside of core IT made the most sense because:

• Cloud was less expensive because you only pay for what you use
• They perceived the service was better
• The response to issues would be faster
• Promises about service delivery and uptime were written with financial penalties for under-performance, typically in a Service Level Agreement (SLA ) document
• They or their team members could provision resources rapidly, and via self service
• There was transparency and true visibility on the cost of IT
• As a cloud customer, they were a priority and could vote with their dollars
• They felt wanted because multiple vendors were competing for their business
• It was a more cost effective and lower risk way to try newer technology or new idea

And though those things made a lot of sense, when they exposed their plans to the internal team or in some cases, when the internal team found out they were already using the cloud, the reaction was generally:

• We have capacity internally already, why can't you use that?
• Buy some servers and a SAN, we'll manage it for you.
• Cloud is more expensive.
• We do understand service, we can act fast, just submit a ticket.
• Our standard cloud offering is [fill in cloud vendor here], use them.
• Can you wait six months? We are implementing a private cloud.
• Security, security, security!
• They were in a busy with a big company-wide project and were unavailable for the meeting.

Those questions and challenges are legitimate and can be quite difficult hurdles to navigate especially if you are trying public cloud for the first time.

In my next post I’ll share some cloud adoption challenges in more detail as well as ways that I’ve seen people overcome them.

“To meet our clients’ business requirements, we need to be able to scale up and scale down very quickly with no disruptions. The only way we can do that is with the architecture we’ve built using VMware and F5 BIG-IP LTM.” - Pat O’Day, Chief Technical Officer, Bluelock

As a provider of Virtual Datacenters hosted in the public cloud, Bluelock needs to be able to seamlessly deliver traffic across servers for heightened performance and efficiencies. BIG-IP LTM provides intelligent traffic management that efficiently distributes traffic across virtual machines to optimize server utilization. By offloading SSL processing from the virtual servers, BIG-IP LTM also frees up server capacity to handle other processes.

Check out a recent case study video where O'Day talks about the benefits of F5 load balancers for cloud computing.

“BIG-IP LTM helps us maximize the efficiency of our virtual environment so we can pass those efficiencies along to our clients, all while ensuring the high performance and availability that our clients require,” says O’Day.

VMware’s July release of both a product upgrade and new software suite consolidates options for enterprise virtualization. The Palo Alto powerhouse in cloud computing technology announced its latest advance for the hypervisor program, vSphere®5, featuring significant capability improvements. Corresponding to the new version’s introduction was the innovative bundling of five supporting software programs, previously sold independently. As just under half of all server operations are currently performed virtually, this latest technology development is a bid to position VMware and its software provider companies in a strong position to capture future enterprise integration.

VSphere®5 noteworthy expanded capacity stats:

• 32 virtual CPUs
• 1 Terabytes (1,000 M) of memory
• 1 Million I/O operations per second

VSphere®5 Suite components:

Analogous to Microsoft’s bundling of personal computing software, VSphere®5 adds to its standard vCenter Operations three other programs previously sold independently as well as an optional fourth:

• vCloud Director – Allows the flexibility of having two virtual machines with similar tasks separate operations only after the tasks begin to differ, with the second virtual machine deployed to independently operate once the need arises.
• vShield Security – Recognizes and differentiates compliance and security certificates and separates critical data into the appropriate level of security.
• vCenter SRM – (Site Recovery Manager) Advanced disaster recovery capability, automated to reduce recovery time, ensure timely storage of critical information and maintains system reliability.
• VSphere storage option – Allows multiple small to mid-sized businesses to store information in dedicated storage space while ensuring that data is not compromised with other enterprises.

A glance into the (near) future of information management?

With estimates placing enterprise virtualization near the 50 percent level, pricing follows function for most of these product choices involving a hybrid of virtual and hardware processors. The new release comes with a reduced number of subscription options, allowing companies the scalability they need as they integrate into the cloud.

Existing VMware customers and potential enterprises looking to invest in the transition from computers dependent on hard operating systems, servers and storage to virtualization can adapt the innovations available with vSphere®5 to their own positioning strategies. By weighing ROI expectations and the flexibility of a platform that allows an “all in” approach to cloud computing, even companies just beginning to test the waters of a this revolutionary trend will be well-served.

SOURCES:

http://blogs.vmware.com/console/2011/07/vmware-unveils-vsphere-5-and-the-cloud-infrastructure-suite.html
http://bits.blogs.nytimes.com/2011/07/12/vmware-shows-its-cloud-strategy/
http://gigaom.com/cloud/vmware-exposes-its-plans-to-be-the-os-for-the-cloud/  http://www.theregister.co.uk/2011/07/12/vmware_cloud_infrastructure_announcment/  
http://www.eweek.com/c/a/Virtualization/VMware-vSphere-5-Delivers-AllinOne-Virtualization-Storage-Package-280187/

Join the Bluelock team and help us deliver the best in enterprise-class cloud computing and managed IT services. We’re looking for folks with a keen entrepreneurial spirit and are passionate about delivering client success. Individuals that pursue challenges and are committed to lifelong learning. Are you one of us? Bluelock’s dynamic environment caters to motivated leaders seeking a challenge. We cultivate a work space that enables personal and professional growth. Our talented and experienced staff is passionate about technology and helping others. Recognized locally and nationally for innovation and growth, our rapidly expanding business is always on the lookout for qualified, hardworking professionals.

Join the Bluelock team and accelerate your career. We offer competitive salaries, a pay-for-performance bonus structure and comprehensive benefits. With more than six positions currently available, a wide range of skillsets and credentials need apply. Check our Careers page to learn more about specific employment opportunities. As we continue to grow position availability is subject to change, so remember to check back often!

Top 3 Reasons To Work At Bluelock

Innovation
As one of only three North American VMware vCloud® Datacenter providers selected by VMware, Bluelock sets a new standard for cloud hosting. Bluelock’s co-founder and CTO Pat O’Day was first to define the term ‘Infrastructure-as-a-Service (IaaS) and the leadership team continues to push innovation in the cloud space to new heights. TechPoint also recognized Bluelock’s progressive approach to the cloud, awarding the team the 2010 TechPoint Mira Award for Excellence and Innovation in a company under 3 years of commercialization. Check out other reasons we've been recognized.

Culture
Bluelock embraces the entrepreneurial spirit and fosters personal development. Whether your interests lie in a technical field or you’re more of the business development type, our intimate and collaborative work environment will provide you with the variety of experiences you are looking for. Dynamic tasks and cross-departmental projects are commonplace – say goodbye to mundane daily duties!


Location
Bluelock is located in Indianapolis, home to an emerging and vibrant tech sector. Amidst the economic climate, Indianapolis continues to produce many of the large names in the tech space (e.g. ExactTarget and Aprimo). Organizations like TechPoint identify and empower high-growth Indiana technology companies. Venture funds and capital exchange confidence is at an all time high in the Midwest. The case for Indiana as a thought leader in the tech space grows. 

What are you waiting for? Jumpstart your career in the cloud!

BlueLock’s VMware vCloud Datacenter Service Sets Offering Apart from Others

(Indianapolis, Ind. – January 25, 2011) – BlueLock, an experienced provider of cloud hosting and managed IT services, today announces that the company has been named to HostReview’s 2010 Web Host Awards’ Best Cloud Computing Service list. HostReview’s annual Best Web Hosting Awards recognize innovators and market leaders, rewarding outstanding contributions within the web hosting industry.

The Best Web Hosting Awards are based on the overall product offering, value, customer service and users' reviews of the selected companies. Winners are at the forefront of technological innovation and deliver exemplary customer service. BlueLock was named to the Best Cloud Service list in part due to its VMware vCloud Datacenter Service, which provides the business agility and cost effectiveness of public clouds without compromising on portability, compatibility, security and control demanded by enterprise IT organizations. For the full HostReview Top 10 Web Host Awards list, please visit http://www.hostreview.com/awards/2010_annual_awards/cloud-service.

“We chose BlueLock as one of our 2010 Best Cloud Computing Services award winners because its cloud service continues to have a tremendous impact on the hosting industry,” said Darren Tabor, CEO, DevStart, network owner of HostReview. “A monthly winner of our Web Host Awards, BlueLock’s cloud computing service has proven to consistently provide outstanding performance and value, while enabling companies to more quickly get started on projects, grow and shrink their environments according to current needs and tap into the full benefits of hybrid cloud computing.”

“We are honored to be recognized by HostReview as one of the world’s best cloud computing service providers," said Christopher Clapp, CEO, BlueLock. “We believe our selection not only validates the dynamic combination of the industry-leading VMware platform and BlueLock’s secure and reliable cloud hosting and infrastructure expertise, but also our vast experience in enabling internal IT to quickly respond to heightened requests and demands while providing the ability to move computing workloads from internal virtualized infrastructure to an external cloud and back if needs change.”

As a VMware vCloud Datacenter Services provider, BlueLock’s public cloud is an enterprise-class service delivering consistent and auditable security and performance features including layer 2 isolation, role-based access control and LDAP integration in a SAS 70 type II certified data center. BlueLock’s use of the same VMware technology used by enterprise IT provides a common management and security model that enables application portability across internal data centers and all VMware vCloud Datacenter Services.

To learn more about BlueLock or its VMware vCloud Datacenter Service, please contact BlueLock at info@bluelock.com or visit www.bluelock.com.

About BlueLock
BlueLock, a certified VMware vCloud Datacenter Services provider, delivers enterprise-class cloud computing and managed IT services, offering the people, expertise and IT infrastructure in world-class, SAS-70 Type II certified data centers. By leveraging VMware technology, BlueLock is able to provide hosted virtual data centers to the enterprise that are fully compatible with their existing VMware investments, enabling their hybrid cloud strategy. This approach provides a common management and security model that enables complete workload portability between internal data centers and the BlueLock public cloud. Named Americas’ Service Provider Program Partner of the Year by VMware, BlueLock’s public, private and hybrid cloud computing solutions enable clients to utilize cloud resources based on their specific needs to optimize deployment, management, and investment. BlueLock, a Collina Ventures company, is privately-held. For more information, visit www.bluelock.com.

About HostReview
HostReview is a popular online destination for people who look for the best hosting deals. The site features a comprehensive article section, industry news, and one of the most complete directories of hosting service providers on the web. The site attracts a diverse and numerous audiences. For more information, visit www.hostreview.com.

VMware and VMware vCloud are registered trademarks and/or trademarks of VMware, Inc. in the United States and/or other jurisdictions. The use of the word “partner” or “partnership” does not imply a legal partnership relationship between VMware and any other company.

On-Demand business intelligence and management reporting organization to utilize BlueLock’s cloud computing services for Disaster Recovery

(Indianapolis, Indiana – January 19, 2011) – BlueLock, an experienced provider of cloud hosting and managed IT services, announces that iPartners, an on-demand business intelligence and management reporting company for the property and casualty insurance industry, has selected BlueLock as its cloud provider. With the announcement, iPartners will use BlueLock’s cloud-based disaster recovery services to back up their data and systems hosted in Atlanta, GA.

“After a lackluster experience with a different cloud provider, we knew we needed an organization with superior customer service and processes and procedures in place to ensure our data and systems are up and ready when we need them,” said David Zebrowitz, director of technology, iPartners. “We look forward to not only utilizing BlueLock’s highly available, scalable and secure platform for our disaster recovery needs, but also their vast cloud experience as we see them as a trusted and proven partner.”

“We are excited to work with iPartners and help them achieve their business goals cost-effectively and with the enterprise level of service they require,” said Brian Wolff, vice president of sales, BlueLock. “BlueLock’s cloud-based disaster recovery offers them the flexibility and scalability they will need as they continue to grow, with the performance, security and client services that is backed by our world-class BlueLock team.”

Delivering pre-configured, secure and resilient virtual IT environments which scale on-demand, BlueLock’s VMware-based cloud services offer enterprises world-class infrastructure-as-a-service solutions. BlueLock is a VMware vCloud Datacenter Services certified provider.

About iPartners
iPartners was founded in 2004 by a group of industry veterans with over 10 years of successful business intelligence and data warehousing consulting experience. iPartners, a software-as-a-service company, strives to change the way P&C companies collect the information they need to make decisions to make the entire process straightforward, reduce the investment of time and money and deliver a solution that adds value to the businesses they serve. Today the organization is leading the P&C industry with “on-demand” management information and analysis solutions, serving over 35 customers and processing over 15 million policies. The “on-demand” business model provides major advantages over traditional on-premise technology products. For more information, visit www.ipartners.net.

As 2010 came to a close, many people were asking me about how they could move third party applications into the cloud... I'm guessing everyone was exhausting their 2010 budgets and purchasing software for the coming year. At the beginning of 2011 I am now hearing more from in-house developers wanting to know how to move their own first-party applications into the cloud.

My first inclination was to post the "Top 5 Ways to Design a Scalable Cloud App," but after re-reading my previous "Top 5" post it has become evident that I can't count. This time I'll leave addition to the experts and just give out a simple overview of ways to design a business application that can scale in the cloud.

Hosting your application within an Infrastructure as a Service provider grants you the operational agility to scale your infrastructure very quickly, but your application needs to scale with your infrastructure. One of the benefits of cloud computing is that you can rapidly grow your infrastructure from 1 to 100 servers within a moment's notice, but applications must have some way of sharing work across these newly provisioned servers in order scale in any meaningful way.

From my experience here are some common ways applications can be designed so that they can scale horizontally:

Design Element #1: Shard, Segment and Spread Out
Making sure that you have a clearly defined separation of concerns between components can be crucial. A common example is the RDBMS and the re-occuring question: "where should I place this database?" Traditional thinking might be that a database server should be an immense chunk of metal - a 64-CPU box with 16TB of RAM. A single, mammoth database server that hosts everything may be less effective than several small database servers, each hosting a single schema. Six 2 CPU, 2 GB PostgreSQL servers may give you better performance than a single 16 CPU, 16 GB server. You also have a greater ability to scale each instance vertically; by putting each schema on its own server, we can add additional CPUs, RAM or even migrate to higher-performance storage just for that schema.

This doesn't just apply to in-house software development, either. If every department in your organization wants to have access to a Drupal portal, but each department maintains documents separately, why not have a stand-alone Drupal server for each department? Each instance can be managed identically, tie back to a central authentication server and be scaled independently.

Design Element #2 - Know Your Enterprise Integration Patterns
This design consideration should be of paramount concern when first architecting your applications to grow at a cloud scale. The Enterprise Integration Patterns first envisioned by Gregor Hohpe and Bobby Woolf have become increasingly relevant as enterprises build applications that need to scale on demand and integrate a myriad of third-party systems.

Enterprise Integration Patterns are to service oriented architectures as the GoF Design Patterns were to software engineering. Pattern-driven development allows architects and developers design applications that are easier to describe, communicate and maintain by building upon common, re-occuring elements.

Patterns become very evident in cloud applications, especially when it comes to message routing. Service-oriented applications have to implement the "Message Translator" pattern frequently - and it makes sense to develop them using a set of shared best practices.

Even better, projects like Apache Camel have been established that give you an Enterprise Integration framework out of the box. No need to write "glue code" - instead you can re-use Camel's integration patterns and stick to writing business logic!

Design Element #3 - Quality of Service Counts
It happens... a flood of traffic comes out of nowhere and your system simply can't handle the load. Perhaps a service has gone completely down and now a ton of messages are backed up and waiting to be processed. There are moments where the system simply has more inbound traffic than it can handle, and you simply can't respond to every inbound request.

There is an alternative to just shutting everything down. By enforcing a quality of service with your message production and consumption you can have diminished availability without becoming completely unavailable. Preventing services from being overwhelmed includes reducing the number of messages being handled, which can be done by defining a time-to-live on your messages. Older messages, ones that may not even be relevant anymore, are allowed to expire and are simply discarded. One can also limit the number of messages being interpreted at the same time by dialing down concurrent message consumption, perhaps limiting a service to only process 10 messages at a time.

Design Element #4 - Go Stateless
Maintaining the state is always the bane of a scalable application. Maintaining state often means persistence, persistence means storing your data in some central location, and a central data store is difficult to scale. Instead of having a large number of stateful or transactional endpoints a scalable application should have a RESTful nature (without being limited to HTTP).

If you can't avoid state... and you seldom can entirely avoid state in some shape or form... manage state using the power of Enterprise Integration Patterns. Consider using the Claim Check pattern along with a tuple space such as GigaSpaces, JavaSpaces, Blitz or SemiSpace. The checkin/checkout style of tuple spaces paired with the Claim Check pattern allows for the very large amount of concurrency needed for transaction-oriented systems.


If your enterprise application is engineered for scale to massive volumes a managed cloud hosting strategy can let your software (and your organization's cost) scale as well. With scalable design patterns, a cloud-ready app can bring in an increasing number of customers with a minimum of re-engingeering.

The great thing about meeting up with colleagues from previous jobs is that they are more than willing to keep you humble. Just recently, a few co-conspirators of mine grabbed a pint and discussed the merits of our application design choices, architecture patterns and just how gloriously over-engineered things used to be. Reflecting on things, I now realize I believed things had to be elaborate because the rest of the world appeared to be working on something complicated.

This train of thought falls in line with my previous post about managing cloud computing infrastructure - simpler remains better. In software engineering, just as in cloud computing infrastructure management, there are common misconceptions about developing distributed systems - and they have bitten me before.

Myth #1: XML is great for inter-process communication
XML is a great implementation-agnostic way of constructing documents and sharing them with unknown consumers. Think SOAP and ReST - XML works fantastic for this kind of service exposure since we may never know who is actually consuming them.

However, if you need to rapidly send messages between components then XML can absolutely kill message throughput. The effort of marshalling/unmarshalling documents not only eats CPU cycles, it also makes byte sizes of your messages much larger than they need to be. Switching from XML to a more streamlined (but still interoperable) format such as JSON can sometimes cut your bytes transferred by 50% while being faster for apps to parse.

Myth #2: If you need to speed up your application, just add more machines
There is a big difference between speed and throughput. Speed is how fast an operation can be executed, while throughput deals with how many operations you can perform in a given time.

If you have a stored procedure that takes 30 seconds, adding two servers won't change a thing. You can add RAM to prevent disk access, attempt to add cores and multi-thread the process or increase the speed of your storage tier, but unless you break the stored procedure into several smaller procs you cannot spread the workload effectively across a farm.

A great use case of horizontal scalability is raw HTTP traffic. When it comes down to the number of simultaneous worker threads that need to be available a sea of HTTP servers behind a nice, robust load balancer that performs MAC re-writing can make a huge difference.

Myth #3: You have to have a NoSQL solution in order to scale
The blog High Scalability recently posted "What the heck are you actually using NoSQL for?" which had a very appropriate truism:
NoSQL databases do a great job of spreading storage or search tasks (or both) across a cloud infrastructure, but they aren't a silver bullet. You don't necessarily need to sacrifice ACID compliance to scale - the logical partitioning of databases can sometimes do the job quite nicely.

Myth #4: Commodity pricing means pay for what your users consume
Several cloud computing companies have made pricing really tricky to calculate. When an IaaS provider accounts for cost by IOPS or bytes per second it can be very difficult to discern what your bill will look like at the end of the month.

As much as we might want billing to be based on how many transactions are flowing through the system, most anecdotal research has shown billing ends up allocation based. For example, here is my hazy analytic of an on-demand application I deployed within a cloud hosting provider:

First off: no, this was not drawn by a preschool class. Second: note that cost did not scale with usage. After scaling upwards we were reluctant to scale downwards since we couldn't accurately forecast how many users would be flowing through. A more predictable, allocation-based billing model would have been welcome in a world of uncertainty.

I would love to hear your myths or the debunking of my own. Feel free to leave a comment on the blog or tweet us up @BlueLock!

First off, I wanted to thank VMware for giving my blog post a home last week. I appreciate the feedback we recieved from the article - we're looking forward to working with VMware on a blog series coming up!

I focused a lot on the pragmatic last week; now my brain has bounced the other way and started to wonder about what managed cloud hosting will look like in the future. Today there is a huge amount of interest from enterprises in leveraging Infrastructure as a Service in order to have a more agile datacenter without the capital expense, but what will be the next big thing?

Currently bubbling up from the cloud crowd is a lot of interest in upcoming Platform as a Service offerings that are increasingly vendor-agnostic with a wide range of supported languages and frameworks. CloudBees RUN@cloud promises to be the PaaS to watch in 2011, especially considering how well the team has done in implementing continuous integration services with cloud technology. VMware's OpenPaaS initiative might be interesting as well, judging by their announcement at RubyConf. Still, I have to wonder if building PaaS as a layer on top of IaaS is the way to efficiently architect a Platform as a Service solution.

Bare-metal hypervisors, like VMware's ESXi, provide hardware and even processor architecture abstraction to the virtual machine it hosts. Traditionally a VMware BIOS bootstraps a guest operating system within a virtual machine, then we install a software stack into that guest operating system. For example, we may create a virtual machine within ESXi and install RedHat Enterprise Linux 6. After the machine is built we may install our runtime environment, maybe the frameworks and libraries to host a vFabric application. Then we install our own application running with tcServer, tweak configuration files and hook it up to our deployment scripts. True, we can do this setup once and then save this application as a vApp for future use, but we consume a lot of memory, compute and (especially) disk space for the guest OS, runtime environment and framework libraries.

What if we removed the guest OS setup, BIOS and runtime environment installation? What if we ran our runtime environment directly within the hypervisor, bypassing the OS and going straight to the cloud computing infrastructure itself? The Java runtime environment itself runs within a self-contained virtual machine of its own - does it need an OS to add another layer of abstraction?

Work already done by IBM, BEA and Sun have demonstrated a Java runtime that interacts directly with the hypervisor can yield significant gains. BEA (and now Oracle) provide a way for the JRocket JVM to skip the OS entirely by using LiquidVM and WebLogic Suite. IBM had a slightly different route with Libra, creating an isolated execution environment that could host a Java virtual machine. In my mind the ultimate solution was Sun's Project Guest VM, allowing the JVM to sit entirely on the hypervisor with no operating system at all... only a microkernel augments the Java virtual environment. The VM itself is entirely written in Java, allowing for a highly optimized Java runtime residing within a cloud computing infrastructure.

Imagine if you no longer deployed "Windows" or "Linux" virtual machines with our cloud technology - but could deploy "Windows," "Linux," "Java 6 EE," ".NET Runtime" or "Python" as stand-alone VMs. No OS tweaks, no hacking of open file handle limits, but instead a very thin virtual machine instance that is 100% dedicated to running your application. Managed cloud hosting providers could then augment this stack with their own specialized tools for automated deployment, monitoring and security policies.

The possibilities for such a cloud computing platform go beyond just making applications easier to deploy and more efficient to execute. We can move away from worrying about hardware drivers and chipsets... our hypervisor and the new virtual machines worry about that for us. Now that we've sufficiently abstracted away the underlying physical infrastructure we can change the hardware architecture completely. Why not ditch your conventional CPUs and now accelerate our code by adding hardware for more efficient vector processing? NVIDIA is already creating "GPU clusters" so that one can have their own cloud-based super computing instances, allowing for certain types of algorithms and applications to reach unthought levels of performance and power efficiency. Why not tune the Java or .NET runtime environment to take advantage of GPU clusters as well and allow cryptographic or streaming operations to run at insane speeds?

With this type of bare-metal PaaS you can save massive amounts of disk storage, since you no longer need the entire operating system just to host an application. VMs that once needed 8 GB disks could now live inside of 256 MB, possibly less if you leverage SAN de-duplication or virtual disk technologies like linked clones. Memory overhead would be reduced, since you only need enough memory to keep your application running. Compute could not only be augmented to crazy-fast levels, it could also run with much less power consumption. Application developers also have less infrastructure to deal with, allowing them to focus on their application rather than supporting the layers the application runs on top of.

If 2011 shapes up to be the year of the PaaS, I can only hope 2012 is the year we blur the lines between IaaS and PaaS. With bare-metal PaaS, cloud technology could give every hosted application their own supercomputer.

BlueLock announces today that Trabian, a web development and hosting form specializing in financial institutions, has selected BlueLock as its cloud hosting partner. With the announcement, Trabian will use BlueLock’s Virtual Cloud Professional to host custom websites and web applications for its client base.

“Security is a major pain point for our clients who are regulated by the financial industry and we needed a hosting solution that could answer to those regulations,” said Matt Dean, President and CEO, Trabian. “BlueLock has met all of our security requirements and has made security information readily available which allows us to better serve our own clients. We look forward to not only utilizing BlueLock’s highly available, scalable and secure platform with our computing environment, but also their vast cloud experience as we see them as a trusted and proven partner.”

 “We are excited to work with Trabian and help them provide an apt and secure environment for their clients,” said Matt Hunckler, Client Specialist, BlueLock. “BlueLock Virtual Cloud Professional offers them the flexibility and scalability they will need as they continue to grow, with the performance, security and client services that are supported by the BlueLock team.”

Delivering pre-configured, secure and resilient virtual IT environments which scale on-demand, BlueLock’s CloudSuite offers a selection of tailored IaaS environments to best configure users’ computing resources. With CloudSuite’s array of public and virtual private cloud computing solutions, clients have the ability to utilize cloud resources based on their specific needs to optimize deployment, management and investment. Recently named the 2009 Service Provider of the Year for the Americas by VMware, the global leader in virtualization technology solutions, BlueLock offers solutions for the developer to the Fortune 500 executive. BlueLock was also recently named one of three North American VMware vCloud Datacenter providers offering compatible, secure and hybrid cloud-ready VMware-based public cloud resources.

About Trabian
Trabian Technology is a web development firm with a focus on credit unions that builds advanced, browser-driven content management systems. Trabian focuses on delivering technology to all its clients via a Software as a Service model (SaaS) while maintaining a custom branch of the codebase for each client.

The beauty of cloud hosting is that you don't need to care about where your computing resources are physically located, they're just up there. Right? In the cloud? What about the beauty of geo hosting, which works from the concept that for the fastest connection to your server, you’ll want to minimize the distance your data has to travel.  But what if you have no idea where your data is located in the cloud? It's likely you may be paying a premium on the unit cost of data transfer, depending on your cloud provider.

According to Hosting Review, "a cloud host will have many servers, often located all over the globe. Using a technology called load balancing, the cloud host will allocate server resources to each customer as needed. Generally, you’ll pay a flat fee for cloud hosting, plus additional monthly fees based on time or resource usage. You’ll always have the bandwidth you need during peak traffic periods, but you won’t pay for unused resources during slow periods."

However, "if you’re on the West Coast of the United States, for example, and the load balancer moves your server from the West Coast to the East Coast, your server connection may be up to 23 times slower. " That's where geo-hosting comes in as a viable option. If connection time is a priority, you’ll want to think about geo hosting. You’ll need to find a host with a data center that’s located close to you and your customer base. Geo hosting is particularly well suited to small and medium-sized businesses that require the fastest possible website and email performance, as well as companies that seek predictable hosting costs.

So wouldn't one assume that combining the two, what I'll call "geo cloud hosting," would be the best bet? My guess is that for the mid-size enterprise it does make sense. Those organizations are likely big enough that the demands on IT are increasing, they need a public cloud to help distribute their resources effectively with the ability to serve their business units on demand, but at the same time the connection speeds of geo hosting are extremely appealing. Connection speed is a real issue, even in the cloud, so as the market continues down the "trough of disillusionment" they will become more and more reasonable about the true values of cloud and what makes sense for each business size and type.

I read with interest, Charles Babcock’s article about why Eli Lilly is engaging multiple cloud providers, not just because it included a reference to BlueLock, but because Charles demonstrated concrete evidence that this nebulous concept of cloud computing is beginning to mature in the enterprise and mid-size enterprise company psyche.  

It wasn’t too long ago (four years ago to be exact) that the concept of Infrastructure-as-a-Service didn’t exist.  How do I know that?  Pat O’Day, BlueLock’s CTO, wrote the first entry in Wikipedia for Infastructure as a Service (IaaS) not in 2006 when we launched the company, but nearly a year later in July 2007.  Fast-forward to VMware’s VMworld 2010 where 17,000 people converged on arguably the IT industry’s standard virtualization and cloud conference and as I walked the floor of the exhibit area – I couldn’t find a single company that didn’t have a cloud product or service. 

Now consider Lilly and Charles’ article – he explained that different companies are choosing to architect and offer clouds with differing SLA’s which means that companies will have an opportunity to choose the right cloud for the right workload.  In 2007, it was novel to even offer a cloud.  Today companies are going to market with their version of a cloud, shooting at a specific market.  Charles got it right when he characterized our IaaS cloud and our aim – we’re willing to step up, make real performance promises, and accept a portion of the risk for non-performance, betting that mid-size enterprise companies will trust BlueLock enough to send their non mission-critical production workloads. 

We don’t believe it’s realistic to think that enterprises are ready to send their mission-critical workloads yet; however, there is real evidence (read real paying customers) that are willing to send us workloads that are important to their business so they can focus their critical and scarce human and capital resources on other things.   So now, it’s not about getting everything into the cloud, but making a conscious decision about what workload should be kept in-house on a private cloud and which workload can be trusted to the right cloud company, thereby achieving a hybrid approach to cloud computing. 
The bottom line is that a one-size-fits-all approach to the cloud is not the trend.  The trend is to consciously choose the SLA and the performance necessary to deliver the desired user experience in the cloud and matching that with a cloud provider with the right promise, SLA, security and service model.  With the announcement at VMWorld 2010 of our certification as one of five global vCloud DataCenter partners, we’re in a better position than ever to help companies make those decisions and execute a hybrid cloud strategy making IT departments more flexible, efficient and responsive to the business challenges that they face.  If you’d like to learn more about how we’ve done that for our clients, send me a note (bwolff at bluelock.com) or give me a call (1-888-402-BLUE x102).

Bill had a great post on VMworld 2010 earlier this week and mentioned a very useful session on hosting Java applications within a virtualized environment. Justin Murray's whitepaper "Java in Virtual Machines on VMware ESX: Best Practices" was released a while ago, but the suggestions are so fundamental they apply today. The steps are very pragmatic and apply to nearly any hypervised environment, although it becomes an increasing focus when your cloud computing infrastructure starts to increase its density.

One best practice that Justin cites is a perfect example of how infrastructure architecture changes in a cloud hosting environment: run one (and only one) JVM inside of a virtual machine. When thinking about density in a physical server environment this makes data center architects sweat - one JVM per server can easily lead to under-utilization. For cloud computing infrastructure this makes total sense... you can size your VM wrap around your JVM precisely, so that you won't have any wasted resources. Say your JVM is set to have a maximum heap size of 768M and your fairly minimal JeOS only consumes 128M of memory - create a virtual machine with 1GB of RAM and you've got a server that is sized precisely for it's purpose. Say you need to expand your heap size? No problem... just expand your VM accordingly! Now that you don't have to worry about pulling pizza boxes out of a rack to upgrade them, adding and even subtracting server memory is easy.

Hypervisors think about memory in a much different way, and often use transparent page sharing to allow more efficient use of a host server's memory. For example, if you have 4096 kilobytes of nothing but 0's it doesn't make much sense to reserve all this physical memory for nothing more than a span of empty space. It would be more efficient to say "I have 0 stored 33.5 million times in a row." Same thing for patterns of memory - say the eight bit pattern 10101010. We could instead assert "the pattern 10 is repeated four times." Here the pattern 10 may be considered a "page" that is shared four times in a row. We can especially do this within a consolidated cloud computing infrastructure; every VM running the same OS kernel likely will have similar memory patterns. This is one of the advantages of virtualization: you achieve superior resource allocation by sharing the page containing the same Ubuntu kernel rather than repeating its place in memory over and over again.

One hallmark of the Java virtual machine has been garbage collection. The practice and grooming of garbage collection is best detailed elsewhere, however it is best summarized as a series of batched operations that clean up and defragment working heap memory. In physical servers this usually isn't a huge issue - memory is fast and usually idle. Since we have a hypervisor that is sharing memory pages, however, this does become an issue when memory rapidly changes in large swaths. The solution is to use larger memory pages to avoid continuous swapping of shared pages. You can force the JVM to use larger memory pages by adding the argument -XX:+UseLargePages to your Java runtime (or -Xlp in the IBM Java runtime), but you also need to enable large page support in your operating system of choice. See the VMware Performance Study "Large Page Performance" for details on how to tell your guest operating system that you wish to use large page sizes.

Another optimization highlight, and one that seems contrary at first, is that fewer CPUs often means greater performance during high load times. It is important to empasize this is during high CPU load because the issue centers around context switching - the effective hand-off between parallel threads. Java itself does context switching very efficiently, especially after Java 6 Update 10 (or so I've noticed at least). Yet when a storm of hardware interrupts and thread thrashing comes around due to high load sometimes just the effort of doling out workloads to processors can cause things to slow down. Ramesh Peddakotla from HP had some great empirical data to share, benchmarking workloads against ever increasing CPU counts. Performance gains topped off at 4 CPUs; 2 CPUs seemed like the sweet spot. At a certain point the cost of orchestrating multiple CPUs outweighs the throughput of parallel threads in the midst of high CPU load.

Linux machines have yet another tweak they can enjoy to reduce interrupts: lower the clock interrupt rate. VMware worked with kernel developers at SuSE Linux to reduce RTC polling intervals and the modification has since been adopted by Linux distributions at large. The most recent Linux distributions no longer require customization or kernel flags to set the appropriate clock behavior.

Ultimately Java running on a VMware cloud can be as fast as bare hardware. Thanks to the efficiencies you may gain from isolating one Java runtime environment within a single operating system, you may even find your Java apps running faster.

I have seen both sides of the virtualization discussion having spent most of my career at mid size private companies.  At one insurance company an ESX administrator would carve out websphere servers for us to use to build an external facing web application.  At the other I waited six weeks while hardware was sent from the Kansas City offices just to have a development environment that mirrored production.  Flash forward to 2010 and I find myself even closer to the virtual world; so much so that I can see the clouds swirling all around me. 

The 2010 VMworld was my first VMware conference.  I was amazed at the number of people in attendance, but it wasn't just the numbers it was the amount of excitement they had during the conference.  I spent most of my time in the TAP sessions, during which I got validation on the work I have done with the vCloud API the previous 2 months.  The TAP sessions demonstrated the various projects VMware as obtained to deliver a full stack solutions for the 2 million Java developers out there.  I learned about a new protocol used for sending messages between two processes (AMQP).  Rabbit MQ, a part of SpringSource, is the leading implementation of this wire-level protocol.  I also attended Chris Richardson's session Spring into the Cloud, which talked about the cloud and what it means to the enterprise Java developer.  Chris co-founded Cloud Foundary which became part of SpringSource and is now a division of VMware.  I have read Chris' book POJO in Action, and I saw him present at the 2006 JavaOne.  Attending this presentation, and knowing SpringSource is a part of VMware I can envision a deploy to vCloud menu option coming in future releases of the SpringSource Tool Suite (STS).  STS is an eclipse based IDE that makes working with the Spring framework even easier.  You can check it out at http://www.springsource.com/developer/sts.

I also attended a great panel discussion hosted by James Watters with jClouds, EngineYard, and Enstratus.  This was a great panel discussion which expanded my horizon of the vCloud API.  I already new about the jClouds project (http://code.google.com/p/jclouds/), which I had spent time reading through the code based while learning about the 0.8 version of the API, and now I have more context on the vCloud API and it's relation to the vSphere API thanks to the Dasein cloud project (http://dasein-cloud.sourceforge.net/).  Only skimming the surface with Ruby work, I didn't know much about Engine Yard (http://www.engineyard.com/).  It was exciting to learn about their integration with the vCloud API, and how they initially went down the path of writing their own integration with vCloud.

The last session I want to call out was Justin Murray's Java Applications on vSphere.  This was a great talk that covered six best practices for tuning your ESX hosts for virtualizing the JVM.  Since I come from the development side of the house were I spend time analyzing heap dumps worrying about the object graphs I have written; it was great to see the ESX tuning side to complete the picture.  These tips included adding the command line switch -XX:+UseLargePages to the JVM start up parameters.  This instructs the JVM to use larger page sizes for it's heap space which reduces the chances of it getting snagged by ESX hosts sharing pages of RAM.  Also, keeping 1 JVM per guest OS was suggested as well as not over committing your RAM in the ESX configuration.  One tool that Justin mentioned that was useful for plotting the performance data that ESX generates was vPivot (http://vpivot.com/).

In closing, I saw some pretty amazing, forward looking things about cloud computing and computing in general, including a cube being moved on the computer screen simply by the user thinking about it!  This conference made me feel good about choosing to be a software developer.  There is a critical mass of Enterprise Java developers and I think VmWare and their partners are the vehicle that is going to get that mass into the cloud.  Oh and if this survey http://www.readwriteweb.com/cloud/2010/09/weekly-poll-what-was-hot-at-vm.php has any indication of the importance of hybrid clouds then the cloud connector that BlueLock provides will be a nice tool to have in the enterprise tool belt.

There are very, very different ways of architecting cloud infrastructure so that it can scale. Prior to deciding on a cloud strategy you should ask one big question - why does your infrastructure need to scale?

About five or six years ago scalability migrated from an architectural property to a widely-discussed buzz word. I would occasionally be in a meeting where someone would ask if my application was "scalable." At times I was met with an incredulous stare when I asked to elaborate on what was meant by "scalable." It should just scale! Scales! Like... er... fish skin?

Scalability is a critical thing when designing your infrastructure and your applications, no doubt. What if I build an amazingly scalable Web application that can handle 10 million concurrent requests from users and could still double amount that in a blink of an eye... but my MySQL database quickly filled up with 1 billion user records? I may have amazing throughput and pass my JMeter load tests with flying colors, but if I don't prepare for the massive amounts of data my application might need to dig through in order to serve a query all the HTTP connections in the world will just serve to pour salt into the wound.

There are options for scaling your data layer and vastly reducing query time, as mentioned earlier in our discussions about non-relational databases in the Cloud. You can even expand to 10,000 node clusters like Google has done with Dremel. However, unless you are ready to build a league of data centers filling the Atlantic Ocean, you may want to consider what your upper limits of scaling really are. Don't automatically assume that a 10,000 node cluster of servers means more power, and definitely be careful of using technology that your application may have difficulty using properly. Non-relational databases won't fit well if your application already uses ORM tools for populating data, and sometimes you need to completely re-think how data is represented (as in Dremel) and move from simple rows of delimited data to nested columnar storage. It can make one's head explode. Mine already has twice this morning.

Cloud Computing infrastructure gives you a quintillion servers at your fingertips, but consider your diagonal scalability strategy first. Are we talking about syndicating or publishing content that is modified maybe 10-20 times a day but viewed thousands of times? Creating a series of read-only MySQL clones will work fabulously, even more so if your application caches data aggressively. Are you going to deal with a ton of transactions that need to be immediately written to your database? Architect your database layer using a sharding strategy that allows you to distribute the transactional load across multiple databases, even relational databases. Are you going to deal with massive amounts of data that will need immediate retrieval? Perhaps a non-relational database is a good idea, allowing you to distribute your data across multiple nodes and retrieve it by using a non-relational key. Need to perform full-text search? You may instead want to index your data in something like Lucene.

I can appreciate the need to standardize an organization's database tools, especially in an enterprise, but it is always good to be open to new solutions for unique problems. When it comes to scaling an application no single technology fits all situations... you need to predict why scaling might need to occur, then open up a path to remove potential bottlenecks before everything grinds to a halt.

I will admit that "Cloud Computing" terminology is becoming confused. People are mixing together the concepts of commodity hardware datacenters, the benefits of virtualization and massively parallel systems into a blender and calling it a "cloud." The truth is that these three concepts are very disparate practices that often do not entirely co-exist. Most service providers will pick one or two of the three for their managed cloud hosting.

For example: Amazon AWS is largely a traditional infrastructure provider that leverages a massive number of commodity hardware (well, not quite, but bear with me) to offer low-cost server hosting. This allows you to spin up elebenty kabillion instances on the cheap, but the price/performance ratio many times just isn't there. A great article was recently published showing how moving a conventional Drupal installation away from AWS provided much better performance, lowered response times and was much more cost effective, even when accounting for disaster recovery. This demonstrates not how physical hardware is more cost-effective, but instead shows how performance matters when calculating cost.

When architecting an application's infrastructure it pays to remember that performance does not increase by adding more servers into the mix. Diagonal scaling is the best way to handle increasing load on a cost-effective basis, as demonstrated by Flickr and Wikimedia. Increase your hardware until you become constrained by concurrency (such as context switching, thread contention or mutex waits) or I/O then consider scaling out horizontally. Unless you are talking about massively parallel algorithms you don't need to spin up an enormous number of machines; even if you do start talking about massively parallel computation, you cease talking about infrastructure as a service and virtualization and instead move towards deploying Hadoop clusters across many physical nodes.

I would agree that vertical scaling isn't a great strategy. I would also argue that horizontal scaling on its own isn't a great strategy either. Get your money's worth for each instance you start, then keep deploying as demand increases.

Server hardware manufacturers and software makers have always touted scalability as a feature.  For cloud hosting providers such as BlueLock, this feature moves to another level: elasticity.  Elasticity is loosely interepreted as implying the capability for services to ramp down as needed as well.  Since most administrator mindsets and tools are geared for provisioning and scaling up, organizations are sometimes concerned that there might be pitfalls they encounter when suddenly being given the ability to scale down at will or as necessary.

Within the BlueLock Infrastructure As A Service (IaaS) Cloud, compute clusters are carefully divided into building blocks called “cores” and these cores are assigned to customers – never assigning more “cores” to a computer cluster than are actually available.  This is the primary issue in the debate between dedicated versus shared cloud computing models – just throwing everyone in the compute pool without regard to expected performance isn’t a good idea.  It’s important to ensure that the capacity available to application(s) is both dedicated and somewhat dynamic.  At BlueLock, once one or more of these “cores” is assigned to a client they are combined together into a resource pool. 

This model of cores and dedicated resource pools, along with the abstraction of physical hardware from the resources assigned to a virtual machine, allows clients to provision (and pay for) only what they need.  As their needs change, additional cores can be added (or removed) to grow (or shrink) resource pools and add (or subtract) to their application’s overall computing capacity.  Since this happens at the virtualization layer, it’s entirely transparent to the underlying operating system and application.  It requires much less prior planning and architecting than building dynamically scalable applications and deploying them on a PaaS cloud.

Recently the swell folks at The Register commented on AWS' latest cluster computing initiative centered around High Performance Computing. In a nutshell this differs from other EC2 instances by providing dedicated servers with two 2.93 GHz, quad-core Xeon X5570s and 23 GB of memory attached to a 10Gb switching layer. Previously you didn't have dedicated hardware... you floated in a pool of resources, hoping that today would be a good day. While the resulting performance gains from dedicated hardware may be significant over the floating-in-the-sea approach, in the end you are just getting a higher performance infrastructure and not a high performance infrastructure.

The annoncements and analysis made me chuckle a bit. For BlueLock to drop another slew of 144 GB blades into a chassis is standard operating procedure. Does that make us HPC as well? For us private clouds and dedicated hardware has always been the order of the day. I find it very telling that the decisions BlueLock made years ago are just now emerging as popular trends for Infrastructure as a Service today.

When evaluating managed IT hosting or cloud hosting providers, it's always good to look at performance not just in terms of "small," "medium" or "large." It's not even how much compute or memory you throw at the problem. Network and filesystem I/O (especially for cloud computing) is a huge factor in overall cluster performance, and one really needs to be at peace with your physical hardware to truly take advantage of your virtual solutions.

Typical data center architectures are based around not just the functions that servers perform, but the capabilities of the hardware in performing it.  In a cloud computing scenario, supported by full-scale virtualization, the capabilities of the hardware change from constants to variables.  Sometimes this makes it more difficult for architects to transition larger-scale deployments, even of specific functions like applications hosting, from physical data centers to the cloud. 

To some extent, Infrastructure as a Service (IaaS) cloud computing (specifically virtualization as the enabling technology for cloud computing) does homogenize the capabilities of the underlying hardware being used.  This is mostly a benefit because it provides economies of scale and allows IaaS providers to maintain higher availability for servers hosted in a cloud.  It does make things like sizing or designing the deployment of applications a bit tougher because typically we deploy the different aspects of a multi-tier application on different types of platforms – i.e., small, scale-out environments for web servers and large, scale-up environments for back-end database servers.

One approach that can be taken is to build “clouds within clouds” each with different characteristics.  A second approach would be to carve things like compute capacity or storage capacity up  into “building blocks” so that when it’s time to deploy an application, an administrator can combine one or more of these “building blocks” to ensure that a specific part of the application is getting the performance it requires. 

BlueLock takes both approaches.  Within our IaaS cloud hosting offering, we have different tiers with different performance and availability characteristics – BlueLock vCloud Express, Virtual Cloud Professional and Virtual Cloud Enterprise.  On the one end, BlueLock vCloud Express is great for things like dev and test.  On the other end, Virtual Cloud Enterprise is a fully-managed IaaS cloud built for performance and availability and perfect for mission-critical or regulated applications.  We try to work closely with prospects to understand their needs and then match those up with the appropriate service.