An Integrated Cloud Service Model
Cloud computing has proliferated every aspect of organizations in the public and private sectors. The attractiveness of these deployment models lies in their utilitarian concepts: they allow organizations to apply various cost models and therefore deliver a more agile response to the ever-increasing demand of competitiveness and high-level service offerings that organizations must provide.
Considering the NIST cloud reference architecture [1] and its deployment models, today’s organizations are confronted with various architectural combinations of service model implementations. The cloud portfolio can entail multiple SaaS deployments, multiple PaaS deployments, and multiple IaaS deployments. Adding to this the on-premise application landscape, the architectural complexity, standardization, and operational management of these scenarios become a huge challenge for any IT organization.
The primary reasons for this escalating complexity is that cloud solutions are evaluated and implement in silos with the effect of missing three major architectural considerations presented in the following diagram:
The first issue is that many organizations neglect to develop a thorough landscape architecture. In its basic form, landscape architecture and management deals with the architecture of providing development, quality assurance, and production instance. Establishing proper deployment processes is key so that a) new functionality can be implemented, b) change control and incidents can be addressed, and c) the principles of DEVOPS can be applied.
With numerous service and deployment models implemented, landscape management becomes exponentially complex since these cloud instances need to be synchronized not only on the process and configuration level but also on the data level. Therefore, if organizations do not pay attention to building a proper landscape architecture between their cloud service models and on-premise applications, they will encounter significant problems in delivering quality solutions to the business. A lack of landscape architecture will cause insufficient testing platforms, extensive data creation and refresh processes, lengthy testing cycles, and significant challenges in providing timely and qualitative operational support. The development of a landscape architecture should be one of the first initiatives undertaken when pursuing a corporate-wide cloud implementation strategy.
The second issue is a lack of an enterprise-wide integration architecture that will support message and data exchange between the various service models. Many of the standard enterprise integration patterns can be applied and should be used to connect cloud instances with each other. These integration patterns must consider rudimentary exchange methods from file transfer to more sophisticated approaches of SOAP and REST web services. In particular, the exchange between on-premise and cloud services provide challenges from a cyber security perspective. In many cases, the SaaS providers only have limited interface methods and therefore face challenges to deliver integration solutions that fulfill business requirements.
The third issue is the lack of a comprehensive cyber security strategy and architecture that goes beyond just single cloud service models to provide a corporate architectural approach to interconnect SaaS, PaaS, and IaaS. The question of two-factor authentication, SAML 2.0, and OAuth 2.0 are all part of defining a comprehensive access and control policies for the overall organizational cloud strategy.
These three areas are tightly interlinked and interdependent. If, for example, one cloud SaaS provider decides to upgrade TLS 1.1 to TLS 1.2 and suddenly encounters major issues (as experienced), the appropriate landscape management needs to be agile enough to quickly ramp up special instances to research and test the problem without affecting ongoing testing or production environments. From an integration perspective, SaaS vendors will provide standard WSDL contracts. In many cases, though, these contracts expose all data fields of an object which provides a significant security risk. Custom-developed web services will be a much better approach since they limit attribute exposure. However, this approach will impact project schedule and cost since these scenarios were not considered upon initial signup with the cloud provider.
(See supplemental post at: It's not easy to reach for the cloud ) The service delivery approach will therefore place a strong focus on these three areas, and will ensure that an organization-wide landscape, integration, and security architecture is developed that can support a complex cloud infrastructure with on-premise applications.