Dilemma for Enterprises in cloud adoption : Native or Portable

Cloud adoption is part of every enterprises IT strategy, but they are faced with many challenges in defining the strategy. One of the significant challenge emerging now is on the decision to utilize native capabilities of the cloud service provider(CSP) like #AWS, #azure, #GCP, #IBMBlueMix.

The ever increasing native feature set of the cloud service providers can help enterprises dramatically simplify the timelines to adopt cloud and develop cloud native applications. But there is an associated cost to it - the cost of exit/ maintain independence or run on multi clouds (portable).

To ensure that cloud adoption now is rapid, thereby providing the ability for the business to meet the current business challenges, and expand in the future. But the enterprise should not become highly dependent on one CSP and lose out innovations or on commercial terms later. The enterprises to have critically evaluate their portability needs across various components while defining their cloud strategy.

1. Application - High
2. Middleware Platform Management - Medium
3. Infrastructure - High
4. Management Tools - Medium
5. Development Tools - High Medium
6. Security - Medium

The decision to use native features or to remain portable has to be taken considering

1. Cost of development of portable solution
2. Cost of moving out of a CSP when native features are used.

 In the implementation if architecture, design can be retained can be retained across CSPs while only the actual implementation changes based on the CSP, it would be easier to port.

 Application

It is absolutely essential that the application is retained portable, as the cost of refactoring/ reengineering the application for a new CSP is high (alignment with business, development & retuning timeline, re-testing timelines). The decision to move to another CSP may be IT related considerations and involvement of business and disruption to them should be kept to as minimal as possible.

 In the new development of cloud native applications with 12 factor application principles, container based application packaging is emerging as the most preferred approach which bundles the application, platform and the required OS which makes the application inherently portable.

 Decision : Adopt light weight application middleware and use containers.

 Middleware Platform Management

With container based application deployment strategy, the middleware platform management is largely around container orchestration solution, apart from application services for persistent layer.

 There are 3 options available for container management

1. Manage on your own with Docker Swarm or KuberNetes or Mesos platform
2. Rely on container as a service from AWS, Azure, GCP, BlueMix, OpenStack
3. Deploy Platform as a service based on CloudFoundry or OpenShift

 Option (a) - Needs lot of technical skills and constant updating of the platform to leverage new features

Option (b) - Similar feature set is available across CSPs when adopting KuberNetes as the container management solution. The architecture and design of the middleware management platform can be retained with only implementation changes changing based on CSP. The portability of the middleware management platform is better with minimal testing and literally no change to the applications. (The innovation is continuously being brought in by the CSPs)

Option (c) - Needs heavy investment in setting up the platform and maintaining it, also the lead time to get started is high.

 Decision: Rely on Container as a service from CSP

 Infrastructure

With quite mature feature set for IaaS across CSP and private cloud, the technical portability across these providers is straightforward. In many cases, the choice of the provider is not technical but more on compliance and commercial considerations. All CSPs are trying to differentiate in the IaaS space with different licensing models, but the feature set remains the same and does not significantly affect the application deployment architecture.

 Decision: CSP has not impact.

 Management Tools

When developing applications in cloud native way, the management of the infrastructure should not be viewed in the traditional way like Server CPU/ memory/ disk utilization, availability monitoring, etc. The infrastructure is managed seamlessly by the container orchestration solution, so essentially the enterprises should focus on business service monitoring like processing time, response time, backlog on queues, etc. They should also look at deploying a cloud orchestration platform for provisioning and governance which is CSP agnostic to utilization of the resources.

 For the services used from the CSP, leverage the native monitoring and management tools for rich feature set, ease of use, and reduced implementation cost. These monitoring elements are implementation dependent and would necessarily change from CSP to CSP.

 Decision: Deploy CSP agnostic cloud orchestration tool and business service monitoring platform incorporating feeds for CSP native tools

 Development Tools

Cloud native application development necessarily include CI/CD tools which completely automates version control, to build, to packaging, to testing and deployment. With container as the application packaging strategy, the changes to the CI/CD pipeline is very minimal and it is restricted to the deployment part alone. With popular Ci/CD tools like Jenkins or GoCD, adopters for deployment on various container management solution are readily available. So the portable can be achieved with minimal effort.

 Decision: Implement CI/CD automation tools

 Security

The security in any IT stack is implemented across all layers namely infrastructure (compute, network, storage), platform, application and data.

1.  Data - Encryption (at rest, in motion), tokenization - The architecture & design of data encryption can be retained like data encryption with keys in object storage or TDE in databases, but the implementation approach of key management would change across CSP.
2. Application - The identity and access management is application level implementation and is portable across CSP
3. Platform - Service identity is essential and it is best handled by native CSP Identity and authorization solution, with the native CSP identity seamlessly integrated with corporate identity store like AD.
4. Infrastructure - Don't try to replicate the on premise models. Define a cloud native model maximizing the cloud native features like network access groups, while considering portable security appliances if needed for specific needs. Leverage cloud native storage encryption & security solutions, apart from data encryption solutions at application layer. With container based packaging which is extremely lightweight with striped down features, host protection solutions may not be required at container level. 

 Decision: Tailor the security solution based on CSP at infrastructure layer, while application and data layer should implement a portable security solution.

With proper analysis across the six dimensions, the usage of cloud native features can be maximized while retaining portability or at least reduce the cost and timelines to move out/ adopt multiple.