Worker productivity is tied to mission-critical applications in a vertical sense. In a vertical stack, end users access an account, relieve inventory and run a report. These tasks move a request through a stack of functionality that almost always ends up in a database. But moving large enterprise databases with sensitive data to the cloud is difficult and keeps the vertical notion of mission-critical apps in a data center. To gain cloud benefits, enterprise IT needs to harness that vertical nature.
Transactional applications follow a fairly predictable format: The user asks for information, performs an update and then views a result. This breaks applications into three logical pieces -- the GUI, application process and database services.
Admins can move the GUI, and even some application processes, to the cloud, often at a lower cost and higher performance than on-premises applications. A new approach to cloud, which splits apps into cloud-friendly and data center-based pieces, is an effective way to "hybridize" mission-critical applications. The trick is to approach it correctly.
Slicing up an app into vertical pieces
The first step in hybridizing mission-critical apps into neat vertical components is to make the GUI a Web service hosted in the cloud. Most modern applications are designed with a Web front-end process that uses a browser or a series of RESTful APIs to present information to users and obtain updates. This model makes it easier to accommodate changes in mobile devices or changes to the language.
If an application doesn't have a Web front end, it's still easy to follow the flow of information through the application and identify the point where formatting meets information processing. This is the logical GUI/application service boundary. The goal is to identify the specific software component at this boundary point and use its interfaces and APIs to connect a Web front end.
Next, review the software component at the GUI/application boundary. The best cloud application design exploits the cloud's ability to replicate components to respond to changes in traffic, and replace failed elements with a new copy. View the front-end portion as a variable pool of cloud-hosted Web servers that pass transactions to the application's on-ramp component, or software component. But the component has to be ready.
It's essential to ensure that the application on-ramp can handle the variable number of Web servers that provide the GUI with acceptable performance, or that you can scale the application on-ramp in and out in response to load. You need load balancing between the user and Web server GUIs to select a server to host a given user. This can also occur in front of the application on-ramp to deploy multiple copies of that component, if needed.
Another consideration at this Web server application on-ramp boundary is the transaction state and integrity. Stateful application components expect a multistep dialog with the user -- read, update and write. Using stateful firewall logic guarantees an end user's transaction is processed from read through write by the same copy of the on-ramp component.
Stateless applications treat reads, updates and writes as separate transactions. In this case, it's possible to use simple load-balancing techniques. There are also differences in transaction backout and integrity processes for these two conditions, so be aware of application structures when planning this out.
Choosing hybrid cloud applications
In some cases, hosting the applications' front-end processes in the cloud justifies a hybrid cloud. If an enterprise needs to see more benefits, the next step is to move elements of the application logic into the cloud -- starting with that application on-ramp component. Think of each app component as a "black box" that forms part of the transaction workflow. Generally, you don't want work transferring in and out of the cloud, so move a set of components from the on-ramp side of the workflow into the cloud. To decide where to stop, look at what each component does, particularly for database services.
If an application component processes information, then it has passed by another component rather than performing a database query itself. Therefore, it's fairly easy to move it into the cloud.
The process will be the same for a GUI or Web server front end. Any component with little or no database access is fit to move to the cloud. When there is significant database access, hybridization changes from the GUI-oriented model to a query-server model.
The query-server model of application tuning for hybrid cloud deployment eliminates the need to move mission-critical databases into the cloud, because components that access them have been moved. If a cloud component reads a database to perform a query to locate a record, much of the database access traffic flows in and out of the cloud. This affects price and performance.
Security risks increase for databases hosted in the cloud. The query-server model allows cloud components to send database requests to a data center database server -- and it returns only the specific data needed. That reduces traffic, delay and cost.
Many cloud planners look at hybrid cloud for mission-critical applications solely as failover or cloud bursting opportunities. A vertical view of applications creates new possibilities for cloud applications and can improve the price and performance of failover and cloudburst applications. Ultimately, that will increase cloud effectiveness and speed adoption.
About the author:
Tom Nolle is president of CIMI Corp., a strategic consulting firm specializing in telecommunications and data communications since 1982.
Keep mission-critical apps in check with monitoring
Four keys to public cloud app success in hybrid cloud