Cloud Adaption Models
Cloud Adoption is a strategic move by organizations to reduce cost, mitigate risk and achieve scalability of computing capabilities. In fact, the depth of adoption yields insight into the overall maturity of best practices, enterprise-ready cloud services availability. Below are typical adoption models.
What is Cloud Native?
Cloud Native applications are the modern, modular approach to building applications that focus on web-scale, mobile-first and real-time data.
Cloud native is a term used to describe container-based environments. These technologies are used to develop applications built with services packaged in containers, deployed as micro services and managed on elastic infrastructure through agile DevOps processes and continuous delivery workflows. Cloud-native application platform software uses containers to isolate running code, but they differentiate on image runtime and format as well as their approach to exposing the container image life cycle to developers.
The Cloud Native Computing Foundation defines “cloud-native” as follows,
- Each part (applications, processes, etc.) is packaged in its own container. This facilitates reproducibility, transparency and resource isolation
- Dynamically orchestrated. Containers are actively scheduled and managed to optimize resource utilization
- Micro-services-oriented. Applications are segmented into micro-services, which significantly increases the overall agility and maintainability of applications
VMware created Cloud Foundry and Red Hat created Open Shift. Both of these platforms were created using open source software and support multiple languages and frameworks (“polyglot”). Cloud Foundry evolved into the Cloud Foundry Foundation, which has attracted over 40 contributing members (Pivotal, IBM, VMware, etc.)
The goals of any cloud native development are,
- Reduce the developer learning curve
- Build applications that are well suited for deployment on cloud platforms
- Maximize agility through continuous deployment
- Enable applications to scale up without requiring significant changes
Choice
Most of the cloud adopters think that cloud portability is important, but only a subset actually need it, and few actually move apps from one platform to another. This has to be considered carefully whether there is the need for a cloud-native platform at all. If there is no problem with having resources in with a single cloud provider, or portability between infrastructures is not a priority, then it does not make it easy to self-manage an optional software layer for a cloud-native platform on the cloud provider. So, managing cloud-native platform on a public cloud means doubling up on things like security policies, security models, etc. It is better to go with native Platform-as-a-Service or Container-as-a-Service instead. On AWS, for example, combine Amazon Elastic Compute Cloud (EC2) with AWS Cloud Formation, AWS Elastic Beanstalk, AWS Lambda and Amazon Elastic Container Service. On Azure, combine Azure Container Service and App Service with Azure VMs, API Management and other services. On Google, combine App Engine and Container Engine with Firebase and other GCP services.
Conclusion
To conclude, choosing and deploying platform software are the easy parts of creating a cloud-native PaaS. Training teams in cloud-native architecture, agile and DevOps processes are more critical success factors and often more challenging.
