Moving your businesses' infrastructure, including the application layer and associated APIs, to the cloud, is a daunting task given today's plethora of digital tools available and heightened concerns of data protection, application performance and data integrity.

One of the most conveniently accessible options is Software-as-a-Service (SaaS) delivery via cloud computing, which offers businesses a reliable, cost-effective way to manage and track company IT consumption without the burden of managing physical servers. It is key to first scrutinize how best to optimize application delivery and accurately measure return-on-investment.

Enterprises are increasingly moving their consumer applications and services to a delivery model directly over the Internet, i.e. through a "public cloud" topology, due to massive computing infrastructures built by leading PaaS/IaaS providers such as Amazon, Microsoft and Google being readily available with attractive cost structures. But leveraging the public cloud introduces inherent challenges in terms of quality of application delivery and performance because a company's data now traverses through a series of externally maintained systems and security controls. Accordingly, enterprises looking to move to a SaaS app-delivery cloud model should consider the following:

1. Application design should be simple

Application design should be as simple as possible to support the principles of a cloud model. Some older application architectures still used in the typical mature enterprise data center consist of complex webs of explicit one-to-one relationships between front-end and middle-tier server instances. As a result, many steps of configuration are required when adding new instances to scale the environment, multiplying the chances of configuration mistakes. Additionally, the elastic scalability associated with cloud environments becomes more difficult to implement because of these static dependencies. The model used for the development of new applications should instead allow requests from front-end instances to be dynamically steered to any middle-tier instance based on the performance and activity of the entire application framework.

2. Applications should be stateless at the transport layer

This enables load sharing across as many front-end servers as possible as application needs grow without a contingency for particular servers to be responsible for particular user requests. Statelessness removes the need for special coding in the application to maintain state information about a stream of requests. Because of its lightweight nature, it's ideal for environments where application instances must respond to large numbers of small queries or where large numbers of users are involved. When stateless transport communication to the front-end application tier is not a viable option based on the inner plumbing of the application, a SaaS-model virtual load balancer/application controller (ADC) has the ability to ensure that client requests are directed back to the individual instance where client-specific session information is available.

3. Applications should be compatible with self-service

Applications should be architected with compatibility for self-service. To enable lines of business managers with agility and quick time-to-market advantages for their hosted business services, SaaS applications should be designed to be instantiated via a self-service provisioning "store" model available in private and public cloud frameworks. This provides the following benefits:

■ Simplifies provisioning for application administrators

■ Facilitates a forum for a holistic view of how application services are being consumed

■ Reduces provisioning time for business critical applications

■ Provides a framework for business unit chargeback

By taking the steps required to introduce this concept into an organization's private cloud, it also prepares the application infrastructure for adoption of other public cloud principles as the transition is made to an hybrid architecture.

4. Coupling between applications and databases

Application front-ends should have a loose coupling to backend databases. Similar to Microsoft's architecture for Lync 2013, the utilization of modern enhancements in database technology should be adopted so that there is a loose coupling between front-end/middle-tiers and backend databases. This allows the application to continue to function if database replication between locations fails or other unexpected disruption occurs.

In the past, database performance or availability issues would always result either in an immediate application outage or a slow degradation of functionality and performance with eventual culmination in a full service interruption. Taking advantage of the latest advancements in database technology and utilizing lazy writes and rehydration techniques, applications can be built so that they rely on the backend with less dependency and without the requirement for constant communication. Based on the fact that challenges still do exist with presentation of the correct iteration of database data in all possible locations across cloud boundaries at any given point in time, there is compelling reason to adopt this methodology when planning the architecture of new applications.

5. Address security challenges during design

Address security challenges during cloud application architecture design. As organizations look to adopt a hybrid cloud model with applications deployed across multiple infrastructures, security of data becomes even more pertinent. Concerns around cloud security include how to protect data in transit while migrating or moving from private cloud to public, protecting data at rest in a remote cloud infrastructure and enforcing governance and compliance standards across all environments. When planning to introduce public cloud into the mix, it's important to perform due diligence to confirm whether or not a given application would be compliant if activated outside of a private cloud or not in the first place.

For business-critical apps that may have PID (personally-identifiable data) or compliance concerns like PCI (Payment Card Industry) standards, public-private hybrid cloud models are gaining currency and are readily available in live-production, enterprise-class topologies. Having a true private cloud model already in place with applications utilizing cloud-ready principles provides the sound framework for moving to a SaaS model.

ABOUT Atchison Frazer

Atchison Frazer, CMO of KEMP Technologies, has over 20 years' experience in technology marketing for both global IT leaders like Cisco and HP, as well as disruptive market-maker start-ups like Gnodal (now part of Cray) and Fortinet. At Cisco, Frazer was responsible for marketing and communications, services strategy and sales enablement to support Cisco's global enterprise theatre and enterprise transformation market segments. Frazer also served as the enterprise marketing lead for network optimization, security services, professional advisory services, solutions architecture, emerging technologies, and acquisition integration

ABOUT Jason Dover

Jason Dover, Director of Technical Product Marketing for KEMP Technologies, is a subject matter expert on messaging technologies and application delivery with a background in the design and implementation of Enterprise Unified Communication and Directory solutions. Dover currently serves as part of the KEMP Technologies' Product Management team responsible for Product Marketing efforts across KEMP Technologies' product portfolio. Prior to joining KEMP Technologies, Dover worked in the finance industry and provided consultative Messaging and Directory transition and migration services to NYSE Euronext and Deutsche Bank as well as served as Technical Lead for the global Directory and Messaging Operations team at AllianceBernstein.