Running a secure hybrid cloud with an on-premises 100% virtualized environment does not make one ready for web scale. Nor does using a hyperconverged infrastructure (HCI). Even if the hybrid cloud is IaaS, we are still talking about something that needs to scale to billions of transactions per day. Web scale, to me, is billions of queries and transactions. That scale is not seen by many applications. Nearly every cloud service is web scale, as cloud services do hit those numbers; however, individual tenants may not be.

And that is really the crux of the matter: scale. So what is web scale?:

  • Cloud management portals for IaaS (AWS, SoftLayer, iLand, etc.)
  • Cloud SaaS environments that are big enough (Salesforce, WP Engine, Dropbox, etc.)
  • IoT environments (ADT, Ford, GE, etc.)
  • Large-scale consumer applications (Netflix, Google, Yahoo, USPS, etc.)
  • Edge security for clouds (Imperva, Zscaler, Blue Coat, etc.)

I am sure I missed a few things, but these are the general environments I would classify as web scale. If your product fits into one of these categories, then it could be web scale. But you also have to look at the numbers. If you have a consumer application that does 100,000 transactions in a month, is it web scale? If you have 2,000 or even 20,0000 consumer applications running within a cloud at 100,000 transactions in a month: would that be web scale?
Now, just a bit of history on why these questions:

We started down the path for this site of using an on-premises version of CMS plus database, on one node. This handled the initial load quite well. As load increased, we moved to an IaaS cloud service, where we ran multiple nodes (for the database and for the front-end CMS). After a while, this installation started to have issues with memory and the constraints of the underlying hypervisor, so we moved once more, this time to WP Engine. The last move was quite recent. This chain got me thinking about how web scale works and whether or not the skills to utilize it are available to many.

Now, on top of all this, I do some work for a company that has roughly three billion queries per day, which to me is really web scale. The company uses load balancers, proxies, caching, etc. It uses the works to achieve these numbers. The CMS I am running is minuscule in comparison, but it is still a growing entity.

What I learned by seeing both sides of the coin, so to speak, is vast. Some of the things I wish to share are the following. To do web scale well:

  • You absolutely need to understand every aspect of your application.
  • You absolutely need to be able to measure the performance of any change, its impact, and how to recover from that impact.
  • Requires the proper use of proxies, load balancers, or application gateways.
  • Requires knowledge of the ecosystem in which your application will be running. One example is the CMS based on WordPress. You need to know the WordPress plugin ecosystem well enough to understand which plugins are bad for performance and which are good.
  • Requires knowledge of other systems to use for management, monitoring, and security.

In essence, web scale requires a well thought out architecture and approach. It is very hard to do web scale in a slapdash fashion, as you will be rewriting and rearchitecting at every growth spurt.
For example, in our environment, we discovered once we moved to WP Engine that we were using plugins that were not safe to use from a performance perspective. We would become noisy neighbors, so those plugins were banned. This helped us to fine tune our environment and allowed us to outsource WordPress-specific knowledge to those more knowledgeable than us. As an engineer, this can be a very hard task. But if you concentrate on the business, it makes sense to use all available sources of knowledge.
Security knowledge was also outsourced, to Imperva and WP Engine. We use both. This allows us to have web-scale security measures while maintaining a smaller environment that performs better, with a back-end set of people to help handle the knowledge components of security and our chosen CMS. This is the advantage of SaaS models for security and applications. How does this scale to the larger customer? Three to four billion queries a day is quite a few!
It is very hard to do per-system firewalls, or even single or clustered firewalls, due to the incoming load. Actually, until last year, there was not a single firewall that could handle the incoming new sessions per second required by the site. Juniper has an SRX that can handle that workload; however, it was far easier to outsource such requirements to an existing SaaS, so that the company can focus on the business while leveraging knowledge and tools available to it (yes, for a fee, but still available). So, web-scale architectures are roughly the same.

There is some sort of front end that acts as a proxy/load balancer, a distributed application behind that, and highly available databases and storage. Security fits in at all these levels depending on skills, number of systems, etc.

The description is oversimplified, and missing quite a few details but nonetheless is quite correct at a high level. The idea to build web scale is to have a mindset of distributed disaggregated applications. Most consider this to be the service model for developing applications: a service for that, and a service for this. However, the model is based on a distributed system.
At the same time, it is a distributed system where some services already exist, and we either use their APIs, or use them as components of the application within the cloud by using SaaS solutions to meet those needs. SaaS solutions for security, services, and knowledge will help many companies now and into the future. The architectures work for on-premises solutions, but also for in-the-cloud solutions. However, once you start down this path, you have entered the realm of the hybrid cloud.
While your application may not be web scale, the SaaS you use needs to be web scale to handle the performance requirements not only for your application but also for others within the SaaS.
Do you use a SaaS to outsource security, services, knowledge, or as a platform on which to build?