eCommerce in the Cloud (2014)

Part III. To the Cloud!

Chapter 12. Exclusively Using a Public Cloud

Deploying your entire ecommerce platform to a cloud, or as much as possible, is the future of ecommerce. We’re rapidly moving away from an era where software is deployed in-house on dedicated hardware that you or someone else manages. Cloud computing is revolutionary to business because it commoditizes computing power in much the same way that public utilities have commoditized power and water. Tapping computing power allows you to focus on your core competency of, say, selling apparel, rather than building and maintaining infrastructure. The overall lower costs and shift from capital to operational expenditures is equally transformational.

In Chapter 3, we discussed the various service models (Infrastructure-as-a-Service, Platform-as-a-Service, and Software-as-a-Service) and deployment models (public, hybrid, and private). This chapter focuses on public deployment models, with either IaaS or PaaS being the service model. Let’s review why you would want to deploy your entire platform to a cloud.

Why Full Cloud?

Business Reasons

Full cloud, whereby your entire platform is deployed in a cloud, is more revolutionary to your business than it is from a purely technology standpoint. The more you use a cloud, the more benefits you realize. Even using it for just preproduction will yield substantial benefits.

The first and most salient argument for a full cloud solution is that it frees you up to focus on your core competency. Building and maintaining infrastructure is incredibly distracting from your core business. You have to hire the right people, select software/hardware/hosting vendors, set up the hardware and software, keep the systems patched, deal with failures, and so on. The challenges only multiply when you build your own Platform-as-a-Service and Software-as-a-Service offerings. You should focus your limited resources on where you can add value—for example, by offering the most comprehensive ratings and reviews system. You will never gain a competitive advantage by applying a patch or tuning a Linux kernel. Let the cloud vendors handle this for you and focus on where you can add value.

The second argument for a full cloud solution is that you can drive as much traffic to the platform as you want, provided you have a full auto-scaling solution, as discussed in Chapter 4. A valid concern with traditional and hybrid platforms has always been the fear that an unanticipated spike in traffic will bring down the whole platform. If part of your environment is statically provisioned, there will always be the possibility of it being fully utilized. In the Internet age, a promotion can quickly travel around the Internet, driving potentially millions of customers to your platform. With a fully cloud-based solution, there is no such thing as not having enough capacity when you can spin up thousands of servers in minutes. In addition to preventing outages, your technical administrators no longer need to monitor and curtail what business users are doing. When outages due to overcapacity were a concern, business users were always handcuffed as to what they could do. Now they’re free to do pretty much whatever they want on their own.

The third argument for a full cloud is that you can save money and potentially use the savings to fund initiatives that grow your revenue. The elasticity and metering offered by cloud computing allows you to pay for what you use as you realize value. No longer do you have to buy hundreds or even thousands of servers only to have them sit underutilized. Cloud vendors themselves add value by handling the routine setup and ongoing maintenance for you. You just pay for infrastructure, platform, and/or software, and the vendor does the rest.

While these three business-level arguments are compelling, the technical arguments for a full cloud solution are even more compelling.

Technical Reasons

While the cloud is revolutionary to business, it is more evolutionary from a technology standpoint. The concept of another vendor offering infrastructure, platform, or software as a service is not new. What is new is the packaging and mainstream adoption of these principles. Again, the more cloud you use, the more value you see.

Cloud vendors offer superior availability, security, and functionality by being able to specialize on their core competency, which in their case is offering infrastructure, platform, and/or software as a service. They can hire the best people in the world and pay them exorbitantly to ensure their offerings are of the highest quality. Your business is ecommerce. You can’t and shouldn’t focus on any of the lower-value activities that the cloud vendors do so well. For example, some cloud vendors offer an advanced virtualization technique that’s known as single-root I/O virtualization (SR-IOV). This technology allows you to bypass the hypervisor for any network-related communication. The business value is that it can substantially improve the performance of your platform. The downside has always been the cost and complexity required to implement, as implementation involves changes to numerous layers from the operating system on down. It would take weeks for you to implement this on your own, if you could even do it.

Why Not Full Cloud?

Deploying your entire platform to a public cloud may not be fully realizable or even advisable, depending on your circumstances. A hybrid approach shouldn’t be seen as a lesser solution, but as different while still providing many advantages. As with all decisions, don’t let idealism influence your decision making (too much).

Here are four technical reasons you wouldn’t be able to adopt a full cloud solution:

§ Your software won’t operate from a cloud. For example, some software cannot support virtualization or tolerate any network latency.

§ You need custom hardware, and your cloud doesn’t support hosting custom hardware. For example, you may use hardware-based encryption for your database.

§ Your software may not be formally certified on the exact software and hardware stacks offered by your vendor. For example, some legacy software may require a legacy version of Windows or an esoteric distribution of Unix.

§ Some software, like databases, have unique requirements around storage that requires a more customized solution. For example, your database may require Fibre Channel, which requires special-purpose cabling.

While there may be some valid technical reasons for not adopting a full cloud-based solution, the issues you’re likely to encounter are probably of the nontechnical variety:

§ Not enough organizational competence to make such a big change.

§ An organization that has entrenched interests that oppose a cloud. For example, you’re likely to face stiff opposition from a team that currently manages its environment. It’s only natural to be threatened by changes that could put you out of a job.

§ Concerns about security. While security should be better in a cloud, not everybody will see it that way. Not everybody understands how secure a cloud can be. It’s often easier to just say “no,” especially for those who don’t benefit from moving to a cloud.

§ Licensing of commercial products may not support a cloud. Unless you have a license that allows unlimited use of software, you’ll have to license for your peak usage, which negates many of the benefits of a cloud. You’ll also have to be able to demonstrate exactly how many cores your software is running on, which may be difficult when you’re rapidly scaling up and down.

§ Not enough capital to fund the cutover. It costs a lot to reorient an organization around a cloud. Costs include everything from re-architecture to training courses offered by your cloud vendor. Cloud computing is an example of a disruptive technology. Disruptive technologies are expensive to implement.

TIP

While these nontechnical challenges may be difficult to overcome, complacency is harder.

Your legacy deployment model, as inefficient and costly as it may be, is fully understood and likely to be trusted by executive management. Given the rapid growth of ecommerce, throwing money at a problem may just be easier and perceived as safer. The longer this move is postponed, the harder it’s going to be in the future.

While there are benefits to adopting a full cloud-based solution, a hybrid approach is often the most pragmatic. There are just so many barriers to adopting a full cloud-based solution that it’s often not practical yet. Hybrid works best when you have a direct connection from your cloud to a colo facility that’s physically near your cloud. When you have just a millisecond or two connecting your cloud to your colo, it’s as good as if they’re colocated in the same data center. With a hybrid approach, you can deploy each hardware and software component where it makes the most sense. Table 12-1 shows the differences between public and private, with hybrid being somewhere in the middle.

Table 12-1. Public versus private cloud characteristics

In reality, you’ll probably deploy your database and other one-off bits of hardware and software in a colo, with as much as possible in a full cloud. A hybrid cloud can still give you many of the advantages of a full cloud, while negating some of the disadvantages.

Path to the Cloud

When you decide to fully adopt the cloud for ecommerce, you’ll find it’s a mostly sequential process that takes time and competency to implement fully. Before you can get to the point where all of your software is running in a cloud, if you can ever get to that point, you have to start from the bottom of the pyramid in Figure 12-1 and work your way up to the top. This is where having a solid architecture and a high ability to execute matters.

Figure 12-1. Cloud competency pyramid

Let’s discuss each of these further:

Security

Proper security must be established before any ecommerce may occur. That’s just a prerequisite that neither vendors nor customers are willing to sacrifice. Proper security entails the use of security-related technology (firewalls of different kinds, distributed denial-of-service attack mitigation, reverse proxies) and the use of process-related best practices (proper change control, auditing, strong information protection policies). You can move on to availability only after security is properly established.

Availability

In today’s omnichannel world, an outage increasingly has the effect of shutting down every single channel you have for generating revenue. It used to be that a website failure would be unpleasant, but it was isolated to that channel. Now, many point-of-sale systems, kiosks, and mobile applications use the same underlying platform. Outages today tend to be platform-wide and thus affect all channels.

Performance

Availability is important, but if your customers and store associates can’t transact in a reasonable amount of time, it’s just as useless as the platform being down. Performance is very important not only to successfully transact, but also to compete. Milliseconds of response time matter.

Automation

Once you’ve mastered security, availability, and performance, you can move on to automation. Automation, as we discussed in Chapter 4, is key to reducing configuration errors while improving efficiency. Automation is required for cloud computing because you need to rapidly build up servers after you’ve provisioned them.

Elasticity

Being able to elastically scale up and down is the true defining characteristic of the cloud. This is the end goal.

Elasticity, the primary focus of this book and the defining feature of cloud computing, can be broken up further, as shown in Figure 12-2.

Figure 12-2. The elasticity part of the cloud competency pyramid

As in the previous hierarchy, you have to start at the bottom and work your way up:

Serving static pages directly from a CDN

When you use a CDN as a reverse proxy, you can serve entire static pages. As we discussed in Chapters 7 and 11, it’s easy to offload the delivery of the majority of your page views and all of the HTTP requests you would normally receive for static content. By offloading a majority of your traffic, you’ve substantially reduced the scope of your platform while serving pages directly from the edge to individual customers.

Deploying to multiple data centers

Unless you jump straight to the top of the pyramid, you will be operating from two or more data centers concurrently for a period of time. Most systems are architected to be served out of a single data center. This was discussed in Chapter 10.

Client-side dynamic overlay

This refers to being able to retrieve a static page from a CDN or other intermediary and to overlay dynamic content on it on the client side. This is how most native mobile applications work today, and it’s an easy way of dramatically increasing the number of page views that can be offloaded. The requests to retrieve content are typically some form of AJAX. This was discussed in Chapter 11.

Server-side dynamic overlay

Rather than deliver a static page to the client and then race back to the origin to overlay dynamic content, you can stitch together the dynamic and static page fragments in an intermediary, like a CDN or reverse proxy that you manage. With this approach, you can scale out your frontend delivery using a cloud while your less-used backend can remain on dedicated systems. It’s a great option for many and the highest in the pyramid that most will reach. This was discussed in Chapter 11.

Full serving from the cloud

This is the most beneficial form of cloud computing, whereby your entire platform is hosted in a cloud. This is a fully elastic solution that offers the most benefits while also being the most challenging to implement. We’ll discuss this shortly.

Again, it’s important to gradually work your way up these pyramids as you gain competency. The more of these prerequisites you have in place, the easier it’ll be to move your entire platform to the cloud.

Architecture for Full Cloud

Review of Key Principles

To begin, we must define what cloud computing actually is (Chapter 3), since the definition tends to vary from person to person. The three characteristics that best define the cloud are elasticity, on demand, and metered. Then there are service models (e.g., IaaS, PaaS, SaaS) and deployment models (public, hybrid, private). The characteristics of elasticity, on demand, and metered are best facilitated by public IaaS or PaaS, followed by hybrid IaaS or PaaS. By being able to specialize, cloud vendors almost always offer better availability, performance, security, and functionality at a lower cost than if you built a comparable solution. Always choose the service and deployment models highest up in the value chain for each function.

Next, once you’ve selected your flavor of cloud, you have to enable the elasticity, on demand, and metered parts of the cloud by implementing an auto-scaling solution (Chapter 4). An auto-scaling solution allows you to precisely match the amount of hardware you’re using with the real-time traffic you’re seeing. This allows you to pay for exactly the amount of hardware you need. The further down the value chain you move (toward IaaS), the more of this work you have to do yourself. That’s why IaaS is generally less expensive than PaaS. Avoid provisioning ahead of anticipated load and instead provision in reaction to changing load. Purchase an auto-scaling solution if it meets your needs but be prepared to build one on your own.

Auto-scaling requires the ability to quickly and automatically install software on newly provisioned hardware (Chapter 5). If human intervention is required to add capacity, it’s not cloud computing. You can install software by deploying a whole machine image, an archive (e.g., .zip or .tar), or by building from source. The approach doesn’t matter, so long as it is fast and doesn’t require human intervention.

Next, you have to select virtualization technology (Chapter 6). Cloud vendors often offer more than one, ranging from full hardware-level virtualization to paravirtualization to OS-level virtualization. Virtualization is a key enabler of the cloud but it is not the cloud itself. Depending on the flavor of virtualization you choose, you may be able to simply install an OS-level image rather than install all of the software from source. Choose lighter forms of virtualization where possible.

Once you have a solid foundation on which to deploy your platform, you then have to turn your attention outside of your cloud, between your end customers and your platform served in a cloud. CDNs (Chapter 7) are the silent enabler of ecommerce, providing reverse proxies, serving static content, hosting DNS, and optimizing performance, among many other functions. CDNs improve performance and reduce the amount of traffic hitting your platform by one or two orders of magnitude.

Next, we look inward to focus on building platforms natively for the cloud (Chapter 8). We must start by understanding what scalability is and isn’t, followed by how to achieve it. The goals of building platforms natively for the cloud and achieving high scalability can be accomplished by adopting standard best practices—decoupling through the use of service-oriented architecture, asynchronous execution, reducing state, and storing it appropriately. Platforms that don’t run well in a cloud generally don’t run well outside of a cloud and vice versa. Since application architecture stems from the people you hire, you must hire a few top-quality architects as opposed to a large group. With hiring, it’s quality over quantity.

Before discussing various approaches for a hybrid and using the full cloud, the topic of security (Chapter 9) must be addressed. While the cloud offers less-direct ownership, it provides more control, which is the key to remaining secure. The first step to security is defining an information security management system (ISMS) and then adhering to it. An ISMS defines the policies and procedures required for security along with provisions for self or third-party audits. Having an ISMS and following it is the single surest way to be secure, more than any specific technology or deployment architecture. Next to adopting and using an ISMS, the best technical recommendation is to minimize your attack profile by turning off unnecessary services, liberally using firewalls, and by using an identity and access management system to reduce the number of systems and functions your employees have access to.

Next, you must determine if you will deploy your platform across multiple data centers (Chapter 10). Availability has largely been the driving force of ecommerce architecture. Deploying the same application out of two or more geographically distant data centers helps to ensure even higher availability. The central problem with operating from multiple data centers is that you can have multiple customers logging in using the same account (e.g., username/password combination) from different data centers. If two customers update the same data at the same time from two different locations, one customer’s action is going to succeed and the other is going to fail, possibly corrupting data along the way. You cannot resolve bidirectional replication conflicts. Instead, you must entirely eliminate the possibility of them occurring by ensuring that all updates terminate at the same database.

Short of adopting a full cloud-based architecture, you can adopt a hybrid cloud (Chapter 11) and get many of the benefits of a full cloud. To fully use a hybrid approach, you have to break apart your frontend from your backend. This splitting is a natural outcome of adopting an omnichannel-based architecture. Another approach is to use a colo facility that is physically near your cloud data center and has a direct connection to your cloud. Inserting HTML into a cached page does provide benefits, but more-comprehensive benefits come from pulling raw, structured data in the form of XML or JSON and then building a page in a cloud based on that data.

We covered a lot of ground in these chapters. If you haven’t read them, please go back and review before proceeding.

Architecture for Omnichannel

As we’ve previously discussed, omnichannel has been the dominant force driving platform architecture over the past few years. Adopting an omnichannel-based architecture allows your customers to transact with your backend across multiple frontends and have a consistent customer experience. The improved customer experience increases revenue.

An omnichannel architecture is not technically required for cloud computing, but it makes it a lot easier to adopt because of that natural split between your frontend and backend. But if everything is in a cloud, you could technically leave your frontend and backend merged, as many are today. You will eventually have to adopt a true omnichannel-based architecture because of pressure from your customers, but at least your deployment model won’t be forcing you to make that change.

When you deploy both your frontend and your backend to a cloud, you should deploy them in pairs to the same data center, but with Global Server Load Balancing employed in the event of a failover, as shown in Figure 12-3.

Figure 12-3. Frontends and backends both in the cloud

Most often, your frontend should be communicating with a backend that’s local.

Larger Trends Influencing eCommerce Architecture

Outside of ecommerce, the architecture principles behind all software architecture and development has radically changed over the past decade. The technology of the early Web and its guiding architecture principles no longer work in today’s world.

Table 12-2 shows the differences between the old and new approaches to software development and deployment.

Table 12-2. New versus old approaches to software development and deployment

Your existing platform, people, and processes can be reoriented to take advantage of these new principles, but it takes time and a lot of effort. People become entrenched in the ways of the past and are often compensated for maintaining the status quo. Designate or hire and then empower a change agent to oversee the transformation. The shift to the cloud is about far more than technology. Only after you’ve built a capable organization, changed your processes, and updated your technology should you attempt cloud computing. Adopting the cloud without making those lower-level changes is unlikely to work.

How to Select a Cloud Vendor

A large-scale ecommerce platform requires dozens, if not hundreds, of vendors, from a qualified security assessor for PCI audits to a database vendor. While all vendors must be carefully selected, no vendor is more important than your cloud vendor that will be providing you with Infrastructure-as-a-Service or Platform-as-a-Service. You’re trusting your entire business and your job to this vendor.

What you’re looking for in a primary cloud vendor is as follows:

Breadth and depth of offerings

What does it come with versus what will you have to build on top? For example, is their auto-scaling solution (Chapter 4) good enough to use, or will you have to build one?

Maturity of offerings

Is what the vendor offers stable? Does it actually work?

Connectivity options

What VPN connectivity options are offered? Does the vendor run lines to colos?

Service-level agreements

What does the vendor offer in terms of uptime guarantees? Will you always be able to provision hardware?

Ability to colocate custom hardware

Can you put your custom hardware-based VPNs, authentication devices, and other appliances in a cloud’s data center?

Different vendors excel in different aspects, but you have to pick one vendor. It’s possible to go with a multivendor solution, but that introduces an enormous amount of complexity without providing much benefit, given how rarely clouds suffer outages. Outages across a single vendor’s fault domains is even more rare. Since outages are typically caused by your own misconfiguration, you double the number of misconfigurations you can make by deploying across two clouds.

Technology analysts such as Gartner and Forrester regularly produce reports on cloud computing and can help you select a vendor.

While the move to adopt the cloud may be partially fueled by price, price by itself shouldn’t be a deciding factor. The elasticity provided by any vendor will save you more than enough money for you to care about the small differences in prices among cloud vendors.

Clouds appear to be entirely self-service with preset prices and credit cards as the only form of payment. But if you’re going to make a substantial investment in a vendor, everything is up for negotiation. You can negotiate for better prices, price holds, additional levels of support, consulting support, and anything else of value. You’re investing in a vendor, and that vendor is investing in you. As with any major vendor, you’ll want to establish good relationships throughout your organization. Those back channels can mean the difference between your platform staying up or going down. Relationships matter.

Summary

Both cloud and omnichannel retailing are fundamentally changing ecommerce for the better. The application and deployment architectures that have helped to make ecommerce mainstream over the past 20 years have outlived their usefulness. To succeed over the next 20 years and beyond, substantial changes are required. Adopting cloud and omnichannel principles is a multiyear journey that changes the way you do business.

The combination of cloud computing and ecommerce just makes so much sense, and the contents of this book should give you enough confidence to proceed. Good luck!