The other week a few of my fellow Tnooz Nodes and I were having a discussion about whether or not companies in the travel industry should care about the software architecture that their software vendors employ.
Primarily the discussion revolved around the importance of Cloud Computing, Software-as-a-Service and multi-tenancy… and a little confusion about what each of these terms mean.
Some argued that the customer shouldn’t care, as long as the software works as advertised. But in my view that’s too loose of a definition and short-sells some of the operational and reliability implications that may result from certain architectural approaches.
Given this issue was a recent (and ongoing) debate amongst leading analysts and technologists on the Enterprise Irregulars blog, it made me doubly confident that this was an important issue that should be discussed and debated in travel industry circles.
And while I recognize that a significant portion of the travel industry isn’t particularly technology savvy (eg. tour and activity operators, bed and breakfast and small inn owners), the choices they make regarding reservation systems, accounting and operations software is vitally important to becoming a profitable operation.
So no matter what size and organization you are or whether you’re a buyer or supplier of travel technology, keep reading.
Now in case you’re not yet sure where I come out in the argument, I think architecture matters…a lot. Why?
- If you’re a buyer of travel technology, the technology choices of your supplier goes directly to the sustainability of your vendor, their ability to deliver their solution at the right cost and the performance and functionality you require – now and into the future.
- If you’re a provider of travel technology, it’s a question of whether you’re positioning yourself appropriately to meet the future needs of your customers. Especially given the pervasive use of legacy technology in the industry.
Let’s begin with a few definitions that will be helpful in providing context (sorry if this becomes too rudimentary for some, but I want to ensure everyone has a common understanding before continuing):
Cloud Computing
This is maybe one of the more misunderstood and (sometimes intentionally) mis-used technology-related terms today. Many companies may try to cast their applications as Cloud Computing to cash in on all the hype and confusion. This attempt at mis-direction is called “cloudwashing”.
Cloud Computing is the aggregation of leverages a shared Internet-based infrastructure (Infrastructure-as-a-Service or IaaS) with an integrated integration, middleware and development environment (Platform-as-a-Service or PaaS), with the application layer residing on top (Software-as-a-Service or SaaS) represented by the graphic here (source: Christopher Hoff).
Cloud Computing, as defined by the National Institute for Science and Technology, is:
On-demand self-service
- Automated Self provisioning
Broad network access
- Available over the network and accessed through standard mechanisms (e.g. mobile phones, laptops)
Resource pooling
- Multi-tenant model
- Physical and virtual resources dynamically assigned and reassigned according to demand.
- The customer generally has no control or knowledge over the exact location of the resources
Rapid elasticity
- Rapid and elastic provisioning
- Resource provisioning often appear to be unlimited and can be purchased in any quantity at any time.
Measured Service
- Metered billing
- Resource usage can be monitored, controlled, and reported providing transparency
Some of the key benefits of Cloud Computing include:
- Convert CapEx to OpEx: Typical on premise infrastructure requires a company to continually invest in servers, storage and related hardware and software to operate their software using capital dollars. These purchases need to be made to both replace aging equipment, but also to add capacity as required by the needs of the business. In the public Cloud model, these investments are borne by the IaaS provider and the company only pays for the compute resources they consume using operating budget dollars.
- Dynamic Scalability: The needs of a business are not static. Naturally, many companies have peak load requirements that often spike for short durations. The Cloud Computing model allows a company to dynamically bring computing resources online to meet those needs, but then wind them down when no longer required. This is particularly valuable when unforeseen spikes occur and you don’t have the ability to wait the 2 weeks (or months) for the standard hardware procurement cycle…which could result in lost sales. And in the travel industry where much of the inventory is perishable, that’s often revenue you can’t get back.
- Enhanced Computing Efficiency: Many companies have highly under-utilized computing resources (often < 40% utilization). Cloud computing relies heavily on virtualization technologies which enable a much more efficient environment. Many companies also use virtualization in their own infrastructure, but are still somewhat limited in the levels they can achieve because they are only dealing with their own applications, while a Cloud provider can aggregate the needs of many customers to drive utilization higher and costs per computing resource down.
- Metered Billing: When you combine the benefits of the first three bullets, you need a metered billing mechanism to pass those benefits on to the consumers of the service. Metered billing allows the Cloud provider to charge based on computing resources consumed enabling companies to turn indirect costs into variable costs, so that they match more closely to the growth of the business and optimize margins, which are already thin enough in the travel industry.
- Automated Provisioning: is what makes the Cloud paradigm work. Rather than requiring the intervention of IT staff to bring new resources online, Cloud infrastructure can spin up new resources in minutes rather than hours or sometimes days.
While originally envisioned using a common infrastructure over the public Internet, another variation has emerged called “Private Cloud” promulgated by hardware vendors and traditional hosting providers which leverages a dedicated infrastructure that is either hosted remotely or on servers within an individual company’s premises.
Private Cloud however loses some of the key benefits of the Cloud paradigm, mainly scalability on demand and the ability to eliminate the need for capital expenditures. There may also be negative impacts on disaster recovery and continuity of operations as well. And there is a whole conversation to be had about Public v. Private v. Hybrid Clouds and how they differ from traditional hosted infrastructure, but that’s a whole ‘nother post.
Software-as-a-Service (SaaS)
SaaS denotes a computing environment where multiple customers access the software application over the Internet.
Often times it is delivered using a shared infrastructure, a single-code base, classically using a Multi-Tenant architecture where all customers share a common application instance and database -- at least from an architectural ‘canon’ perspective, this is the best way to approach it.
A key element is also the automatic provisioning of new clients – where they can basically get started right away without manual intervention.
This is similar to automated provisioning in Cloud Computing except we’re dealing with on-boarding customers, not spinning up new hardware to dynamically meet the infrastructure demands that the new customers may require.
SaaS also employs a consumption-based model for billing, either via a monthly subscription or a fee-per-transaction model as opposed to the typical software license plus maintenance.
This differs from the Application Service Provider (ASP) model which provides a hosted single-instance of the application and database for each customer.
Some say that Saas and Cloud based are somewhat akin to next gen ASP, but to me that’s like saying Neanderthals are somewhat akin to homo sapiens. The differences are large and important.
NB: In part two we provide the top ten reasons why you care about your tech provider's architecture.