IaaS and PaaS: Mature Enough for Financial Services Firms?
RFG Perspective: Since 2008 financial services firms have been under constant pressure to grow revenues and contain costs, which is driving IT executives to invest in cloud computing. Business executives do not value infrastructure per se; consequently, there is a push towards cloud computing to drive down costs as well as to enhance agility. Moreover, IT executives want to be able to implement Infrastructure-as-a-Service (IaaS) and Platform-as-a-Service (PaaS) cloud solutions that are vendor independent and first-of-a-kind implementations that provide portability. These solutions must also satisfy regulators, which, when it comes to compliance and security, is no simple task. However, since cloud computing standards are still nascent, with many conflicting APIs and standards in the works, IT executives must deal with an opportunity/cost challenge: wait for the technology to mature or implement cloud solutions now and risk the need for change.
Business Imperatives:
- IaaS APIs, solutions and standards are still immature and in a state of flux. Even OpenStack, which claims to offer a robust infrastructure solution, is still initiating new projects (e.g., Murano and Solum) to address additional infrastructure requirements. Unfortunately, each IaaS software methodology is different, causing user software to become solution dependent and hinders elasticity and freedom of movement. Amazon AWS currently provides the best offering but gaps remain. IT executives must develop common standards, taxonomy, and use cases that can be used to push vendors into delivering solutions that meet industry requirements.
- Which PaaS offering – and whether or not to use it – is heavily dependent upon application characteristics, workload portability, compliance, disaster recovery, and security requirements. The migration to PaaS means IT executives need to address DevOps and lifecycle management, which are not just technology challenges but also culture, people and process paradigm shifts. IT executives must re-evaluate their development lifecycle based on the new PaaS technologies, including defining their baseline requirements and policies for automation, continuous build, and version control.
- Compliance and security are not the same thing but are frequently intermixed when discussed. Much has been done to address security but compliance gaps exist that must be addressed and the methodologies standardized so that buy-in across the industry can be obtained from the regulators. IT executives must work on a common set of standards that regulators will sign off on and vendors can agree to support.
RFG has held a number of cloud forums for IT executives and senior architects of the major financial institutions over the past few months in New York City and London. This research note summarizes the discussions, findings, and desired actions required for cloud computing to become an operating standard and penetrate the financial firms in a cohesive, coordinated way.
CTO Panels
CEOs, CTOs and other IaaS top vendor executives from Canonical, CloudScaling, IBM/SoftLayer, SolidFire, SunGard Availability Services, and SwiftStack provided their views on the status and trends for IaaS. They all agreed there is a lot of work to be done before there are common APIs and standards that users could use that would allow portability and facilitate agility and scalability. One vendor executive postulated that in five years it may be possible for hybrid clouds to reach the point where cloud environments can be seamless with common APIs and security policies. One challenge for user executives is that some applications are infrastructure-aware while others are not. For true independence and flexibility, this awareness must be eliminated or be resolvable through dependency or policy mappings.
Development teams, especially DevOps staff, should not need to know infrastructure, just be able to address orchestration and policies. In response to the question on compliance and security, it was agreed that the responsibility for policy enforcement, security and governance belongs in each component of the stack. A need for software-defined compliance was also addressed, with the consensus that it needs to be built in at the start, not after the fact. IT executives were advised to contemplate two kinds of clouds: a virtualization cloud for legacy applications with the aim of improving cost efficiencies; and an innovation cloud designed to help developers get new applications to market faster. Cloud architects must be able to stitch these clouds together.
A second panel consisting of CEOs, CTOs and other PaaS vendor executives from ActiveState, Citrix, GigaSpaces, Mirantis, and MuleSoft offered their opinions on PaaS status and trends. All agreed that PaaS and IaaS layers are not blurring but the application and platform layers are and it will get even more blurred as vendors add more layers and build more higher order services. Nonetheless, all PaaS frameworks should run on any IaaS layer. The issue of DevOps arose again with executives pointing out that DevOps is not just a technology issue; it must also address policies (like security), processes, and cultural change. Developers need to rethink their roles and focus more on orchestration of services than on purely writing code.
Vendors conceded IaaS and PaaS solutions are still immature and suggested IT executives view the use of clouds as an opportunity/cost analysis problem. IT executives and their firms can wait until the technology matures or can invest now, shoot for first mover advantage, and risk the need for change when standards emerge that are not consistent with their implementations. The rewrite risk was postulated to be less expensive than the risk from market losses to competitors.
The panel discussed the requirement for common APIs and workload affinity and portability. While there was agreement on the need for common APIs, there was disagreement on the right level of abstraction for the APIs. All agreed workload affinity will apply to PaaS platforms, which means IT executives will need to determine which workloads apply to what PaaS offerings before attempting to migrate workloads. Successful PaaS solutions will allow for application portability on- or off-premise. The movement towards use of composable elements will enable this capability. The challenge will be the mapping of application services across divisions or organizations, as even file movements look different across organizations. The panel voiced support for software defined solutions, including software defined operators.
IaaS
In the IaaS track IT executives and architects expressed that there is no winning solution out there yet. Amazon AWS, Docker, KVM, OpenStack, Rackspace, Ubuntu, VMware, and Xen are amongst the cloud solutions in use. An AWS architect voiced the opinion that more banks use AWS than other solutions because the company works more closely with customers to meet their unique banking requirements than the others. For example, users expressed Amazon got it right when it bolted down certain components, like the hypervisor, while showing more flexibility elsewhere. However, it was clear from forum discussions that AWS's early dominance is no guarantee that it will remain the 800 pound cloud gorilla.
One IT executive expressed use of IaaS could solve the hygiene and maintenance issues while simultaneously driving down the cost of infrastructure maintenance and support. IT executives could view IaaS solutions as disposable – i.e., bugs are not fixed and upgrades not applied but platforms are discarded and new ones provisioned. Smartphones use this concept today and it could be a transformative approach to keeping infrastructure software current.
Operations movement to the cloud represents a paradigm shift for the development cycle and developers. Business executives are not enthused with paying for infrastructure costs, as it impairs margins and does not drive revenue. Thus, it behooves organizations to standardize on cloud platforms that can provide agility, portability, scalability, security and cost containment rather than have each application locked into its own infrastructure. This is a 180 degree shift in how the process is done today. IT operations executives need to convince senior management and development executives to change the development culture. However, all agree that this is most likely an 80/20 rule – 80 percent of the time a few IaaS platforms apply and 20 percent of the time uniquely modified platforms may be needed for the enterprise to differentiate itself to have a competitive advantage and make money.
Lastly, there was consensus amongst users and vendors that there is a need for, at minimum, de facto standards and a common taxonomy. The areas to cover are those currently found in the AWS implementation plus audit, federation, orchestration, and software distribution. The group wants to move forward with a focus on the areas of audit and compliance first, using use cases as the baseline for developing requirements.
PaaS
It became clear early on in the information exchange that PaaS means different things to different people – even within a company. There are PaaS offerings for analytics, databases, and disaster recovery as well as online transaction processing, for example, which can be self-service, pay-as-you-go, and on demand. The platforms may have different requirements for availability, compliance, orchestration, scalability, security, and support. Some PaaS solutions are designed for DevOps while others are architected for legacy processes and applications.
The executives chose to focus on business- and mission-critical applications and the solutions employed, such as AWS Cloud Formation, Pivotal Software's Cloud Foundry, GitHub, Heat, Jenkins, Murano, OpenShift, Puppet, Solum, and Trove. As can be noted, the discussion went beyond just the PaaS platform to application life cycle management. One conclusion was that IT operations executives should keep in mind that when talking to their development counterparts, the development requirements lists are more flexible than most claim or developers would not be able to use AWS. This bodes well for moving to standardized cloud platforms and away from development defining systems rather than requirements. However, in the near term, application dependencies will be a major problem that users and vendors will have to solve.
One of the executives warned that PaaS has a long way to mature and that one component not currently present but desirable will be graphics/visualization. He expects visualization tools to simplify the creation of workflow diagrams and the underlying processes. Since this parallels what has occurred in other areas of process automation, RFG believes it is highly likely that these types of tools will materialize over the long term.
When it became apparent that PaaS is more about the application life cycle than the platform itself, DevOps and life cycle management became the prime topic of discussion. Executives envisioned a PaaS solution that supported the development process from the PC development platform to production to future releases. However, implementation of standardized platforms and DevOps implies a transformational change in the development process. This does not imply eliminating choice; but choices should be limited without stifling innovation. Developers will need to be taught how to rapidly move applications through the development cycle through the use of automated tools. There are platform tools that can watch a repository, see a commit, check it out, run Jenkins on it, go through the quality assurance cycle and go live after it gets a "green light." This automated process can shrink the development time from months to minutes.
There was a consensus for a need to re-define the development lifecycle based on the new PaaS technologies, including delineating the baseline requirements and policies for automation, continuous build, and version control.
Compliance and Security
Initially attendees did not think there was much value in discussing compliance and security for cloud computing. But comments from an IBM security CTO got them rethinking their positions. She stated IBM is completely rewriting its internal security policies to accommodate cloud computing. Everyone needs to start over and rethink security architecture and controls, especially secondary and tertiary levels. The risks have changed and are changing more rapidly as time goes on. Therefore, auditable controls and security must be built in upfront not as an afterthought. This needs to be done on a global basis to contain costs. All units in an enterprise need to be on the same page at each point in time and maintain the trajectory of heading in the same direction for it to be successful.
Compliance is a different matter. While everyone is addressing security in some measure, compliance lacks common global standards for infrastructure, platforms and applications. FFIEC rules and ISO 22002 standards must be met along with NIST, FedRAMP, and non-U.S. standards in the countries in which the financial institutions operate. It is possible that there is 80 percent overlap but the standards must be mapped and addressed. One of the financial services firms has already mapped the FFIEC rules back to ISO 22002 but the rest has not been addressed. Once the appropriate compliance requirements are mapped, commonalities determined and gaps addressed, users can go to the regulators to request approval and can ask cloud providers to include the de facto standards in their offerings. The group agreed that a working group should consolidate current standards and guidelines, creating a document that can be agreed upon and taken to regulators for acceptance.
Additionally, IT executives need to ensure cloud service provider (CSP) contracts have provisions for certification and/or responsibility for controls. CSPs must take responsibility from a regulatory view, if they expect financial firms to be comfortable using their services. The contracts must also clearly call out the roles and responsibilities of both parties and the process for hand offs.
Common Architecture
The purpose of a common architecture is to enable application portability across platforms within an enterprise as well as for bursting out to private or public clouds to handle peak loads. This is not to suggest all cloud platforms support all applications. But for those platforms where there is workload affinity for a certain application set, the ability to move from one instance to another should be a simple task. The goal should be "one click" portability that gives almost instantaneous movement to another instance anywhere in the cloud or expansion that adds instances and allows for hybrid cloud environments.
The IT executives and architects concurred that the common architecture vision is a concept that may become a reality in the long-term but will require mature standards first. A discussion arose on the topic of whether Amazon AWS APIs and standards could be used as a baseline. However, Amazon pointed out that the APIs are copyrighted and approval would be required first. Amazon will look into the possibility of getting approval. In the meantime, the users agreed that the financial services firms will not wait for the availability of a common architecture but invest now to meet their business needs. As a next step, the group agreed to start developing the commonalities for the architecture.
Summary
The IaaS and security groups agreed to a joint effort to review the many overlapping Compliance standards for commonalities and reduce that list to a bare-essential set of requirements. Essential security elements will be added to the list. The PaaS group wants to use a declarative approach to indicating all the resources, and policies amongst the resources and for the PaaS platform. From a developer life cycle perspective, the group wants to include, in a declarative template, the various components of the application development life cycle. Amongst the items to address are the release levels including continuous builds and testing.
IT executives suggested including the OCC in the next session to provide regulators with guidance on financial institutions' direction for APIs, de facto standards, reference architectures and frameworks, and to perhaps influence the regulators' direction accordingly. Users also asked for the adoption of a mechanism for keeping track of workgroup progress and communicating that to other Forum members. Suggestions include tools used by other standards organizations and working groups.
In sum, the comments and conclusions of the IT executives and architects in the cloud forums are indicative of the challenges, requirements and directions of the top U.S. and global financial institutions. But the executives believe the time and resources spent in the development of requirements and standards will be worth it.
RFG POV: Financial Services firms are committed to moving to cloud platforms, both on-premise and in private and public clouds. Since they will not be waiting for the IaaS and PaaS offerings to mature, there is a strong commitment to work together to create baseline APIs, requirements and standards that can be frameworks for the financial institutions, regulatory agencies, and cloud vendors. These frameworks should enable the firms to reduce costs, drive cost efficiencies, achieve a level of vendor independence, and simplify compliance with regulatory requirements. Moreover, the frameworks should be applicable to other industries and enable any large enterprise to more easily and rapidly take advantage of cloud computing. IT executives should approach their move to the cloud strategically by defining their policies, frameworks, guidelines, requirements and standards, and performing opportunity/cost analyses first before committing to one or more target cloud architectures and implementations.