An Application’s Journey to the Cloud – Part Three
In my first post in the series – An Application’s Journey to the Cloud – I explored how cloud computing solutions might fit into enterprises. The second post focused on the perceived benefits of cloud computing. Today, I’ll explore how an application’s architecture is a critical factor in deciding which type of cloud deployment model you should choose.
Organizations usually deploy applications on cloud services because of cost, metered usage, scalability, ease-of-use, time-to-delivery, or for any combination of those reasons. However, one of the more critical factors in selecting a cloud deployment model is the application’s architecture.
In application software engineering, multi-tier architectures—often called SOA/Web based N-tier architectures— are distributed, client-server based application architectures in which the presentation, application processing, and data management are logically separate processes. Additionally, applications use middleware to service data requests between users and databases employing multi-tier architectures. The most widespread use of multi-tier architectures refers to N-tier, SOA/Web architecture.
The three-tier architecture has the following tiers:
- Presentation Layer: This is the topmost level of the application. The presentation tier displays information related to such services as browsing merchandise, purchasing, and shopping cart contents. It communicates with other tiers by outputting results to the browser/client tier and all the other tiers in the network.
- Business/Application Layer: The logic tier is pulled out from the presentation tier and, as its own layer, it controls an application’s functionality. It’s the layer that can connect one application’s users and data with another application through the use of SOA-based APIs and/or middleware.
- Data Layer: This tier consists of database servers. Here, data is stored/retrieved and the activities of the presentation and application tier, related to data request, are recorded in the form of a database transaction. This tier keeps data neutral and independent from application servers or business logic. Giving data its own tier also improves scalability and performance.
Previous application architectures were typically done in two tiers (client-server) and/or were monolithic (single tier i.e. mainframe). Modern day SOA/Web based application architectures are highly mobile in that the presentation, application, and data tiers can be physically separated to run in one or more, private, public, or hybrid cloud deployment models. For example, in a SOA/Web based app, you can run the presentation services in a public cloud, while running the application and/or data tier in a another public or private cloud delivery model—called a hybrid cloud deployment model.
Most modern public cloud providers readily support N tier, SOA/Web application based architectures on common APIs (such as Rest, SOAP, SQL, MySQL, etc.), hypervisors, and operating systems. However, they’re challenged to support the older single-tier and two-tier applications because they can’t support the operating systems and/or APIs that the older single-tier and two-tier applications use. Additionally, most current SOA/Web based applications direct traffic flows (from the end user through the application and on to the data) in both east-west and north-south directions—or what we call the ‘ephemeral’ directions. Older applications have traffic flows in mainly north-south directions. In order to deliver data to an end user in single or two-tier applications, data commonly has to traverse the entire application stack, which contributes to excessive network and I/O payloads, much more so than SOA/Web based N-tier apps.
The choice of cloud delivery model for a given application also relates directly to usage charges. Most public cloud providers charge little or nothing for access to web services via the internet. Furthermore, SOA/Web based traffic that flows in-between application tiers can typically flow east-west again, at little or no charge. An older single or two-tier app may be extremely expensive to access in a public cloud delivery model because network and traffic flow (north-south data flow and network access fees).
A majority of public cloud providers tend to base their fees on some combination of both network and data access, and since older applications consume considerably more of these resources than SOA/Web apps, you may find the public cloud cost prohibitive for older applications, even though hosting fees are relatively similar to SOA/Web app costs. It’s like razors with disposable blades—how much you ultimately pay depends on the price of the blades and how many you use, even though the razor itself may be free.
In our next post in this series, I’ll discuss the importance of orchestration and how to choose the right tools for private and public cloud management.