On October 5, 2010 the Wall Street Technology Association (WSTA) held a seminar in the Boston Financial District on the topic of Cloud Computing. In 2010, the topics of interest among vendors included differentiation between delivery models, metrics, availability, costing, scalability management applications and success criteria.
One year later, at this year’s WSTA Cloud Computing seminar, the “cloud” discussion was remarkably different; it had matured. The attributes mentioned above are all still important factors, but they have been mostly commoditized in the market. In 2011, although there are several major areas where cloud computing has matured, some issues remain and new ones have arisen.
Whereas in 2010, each vendor, enterprise and analyst had their own lingo for the cloud and its various delivery models, 2011 ushered in two specific maturations:
1. Although NIST has published several specifications on cloud computing, they all tie back to a common definition of what “cloud” technology is (see NIST SP800-145 “A NIST Definition of Cloud Computing”). This has leveled the playing field between organizations and vendors as they both now have a common reference point for discussions.
2. The disparate terminology between delivery models, from public (e.g., public-shared, community, etc.) to private (e.g., on-premise, local, etc.) and all those confusing iterations between have been more-or-less removed.
2010 saw a plethora of business drivers for moving solutions into the cloud – costs savings, scalability, time to market and others. In reality, there were not many cost savings, scalability only went in one direction (customers never considered plans for server deflation), and time to market decreases did not translate into scalable solutions.
Cloud customers have matured in their thinking. It is no longer about the specific attributes of the cloud technology and/or vendor; it is about the business value-add. Customers are asking vendors for a two-pronged solution set:
1. What business benefits can be achieved by moving their project to the cloud?
2. How can the vendor’s technology/solution measurably achieve these benefits?
Customers are viewing the traditional build-versus-buy exercise with a new set of spectacles – shaped not only by the historical missteps in early cloud adoption, but also by the maturing of cloud concepts and the sophistication of the vendors’ offerings.
With the normalization of the cloud delivery semantics – public, private, hybrid, etc. – cloud vendors do not focus on the specific delivery models. Discussions between vendors and customers revolve around the classification/definition of processes and data and the appropriate deployment mechanism for each piece of a solution; entire solutions are no longer tied to a single delivery model. Most implementations are some form of hybrid deployment: clients can use public cloud instances for the mundane (and innocuous) processes while keeping proprietary information and processes in their private cloud. There are little or no differences in the deployment interfaces and communication protocols between cloud instances; and as such, management becomes a much simpler task for clients.
Scalability is no longer skin deep. Experience shows that simply cloning servers does not achieve true scalability and in some cases acts as a detriment to processing. Real benefits in cloud scalability comes from a service-oriented architecture (SOA) designed for multi-point receptors and executors. If an existing project does not already use this approach, then moving to the cloud may not achieve the anticipated scalability.
In designing (or redesigning) applications for the cloud, while agile software development lifecycle has become the norm, application design processes have also matured. Clients are combining agile SDLC with tried-and-true design techniques, such as Yourdon’s methodology for component design and other fractal design principles
In addition, data storage on the cloud can still be a single point of failure if improperly designed. Placing data in the cloud does not automatically make data redundant. And given the newest licensing models for the popular databases, it is tempting for companies to deploy only a single instance of the database engine.
Tightly coupled with application architecture are the development skills needed to properly achieve the architected design. Developers need to know such rudimentary concepts as state machines, mutexes and memory management, which are no longer widely taught. Congruent to supporting the appropriate application architecture, developers need to be seasoned in parallel computing, as well as high availability programming techniques.
In cloud security, there is the adage “the cloud is no more secure than your organization.” While this point is still very relevant, contractual language by cloud vendors is better at clarifying the responsibilities of information security by the customer.
However, clients should remember that they need to ensure information security for data “in-transit” as well as “at-rest.” Compliance is solely the responsibility of the customer. Data security on the cloud is still an open book; and one would not expect to see any standardization in this area.
The best approach is to use application-level security – incorporate authentication, authorization, encryption and detection into the application. Then create a layered security model – i.e. circles of protection – around smart log management and auditing.
The strategy known as “Avoid, Trap, Mitigate,” which was first defined by the FAA in their Cockpit Resource Management guidelines, adopted by NIMS ICS for use by emergency first responders, and is utilized in the defensive strategy for almost every team sport. This strategy can be effectively applied to enterprise security and extended to cloud security.
Even as the cloud adoption enters this next phase, some persistent issues still exist. Organizations are still:
1. Struggling to define relevant and optimized management applications for their needs, as well as to define success in deployments.
2. Stumbling in the beginning of the contract process:
a. Expectations of both the vendors and the organization’s internal groups,
b. Wide variety of cloud contracts,
c. Understanding accountability and ownership of data, and
d. Recognizing security responsibilities of vendors.
And with adolescence a host of new (or unforeseen) issues is being brought to the forefront:
1. Software licensing models: Cloud vendors are quick to point out that clients are responsible for all licenses. This is a moving target, as VMWare changes its licensing model to be limited by RAM, Oracle redefines its licensing terms to be per core rather than per CPU, and concurrent licensing and seat licensing are moving towards usage-based models.
2. Ambiguity in terms: While all parties have normalized the terminology used, there is still ambiguity between the interpretation of terms by technology groups and business groups. For example, does “availability” mean the state of the server hardware, the VM, the platform or the application?
3. Smart provisioning: Vendors are beginning to provide more sophisticated tools to build custom templates, with platforms and middleware already in place. However, most client deployments are not built with intelligent provisioning utilities, so although one can spawn a new server in “seconds”, it may take “hours” to get it configured properly.
4. Scalability in both directions: Vendors will readily give a client tools to build up a server farm but are reluctant to handhold a client in determining its teardown criteria.
From 2011 through 2012, consider “Cloud” to be in its adolescence – a dichotomy of promoting its virtues yet still trying to solidify its identity in the marketplace. As many disparate issues in the cloud (vendors like to call them “differentiators”) have been commoditized; new more advanced issues arise. This does not make cloud computing a “bad bet”; on the contrary, the fact that it continues to evolve is testament to its success.
John C. Checco is currently employed in the Governance, Risk and Compliance space. He is founder of Checco Services Inc., an information security consulting firm that markets the award-winning bioChec™ keystroke biometric technology. John currently holds CCSK, CISSP and CSSLP certifications, is a member of the Advisory & Content Committee of the WSTA, a board member for InfraGard’s NY Metro Chapter, and has active memberships in ASIS, ISSA and OWASP. He may be reached via email at John.Checco@CheccoServices.com.
Reach Wall Street's leading technology products and services in the financial industry.
TICKER Editorial Calendar Deadlines, Themes & Suggested Content