Every business develops and runs a fair bit of custom code applications to automate value chain delivery to customers, partners, employees, and even supplier interactions. Highly progressive businesses are driven by data which means these businesses continuously build, integrate, stage and deploy custom code to improve a range of outcomes namely process automation, user experience, operational visibility, compliance, and governance at dizzying speed.
Cloud services both IaaS and PaaS are natural choices today for development teams when it comes to realising business services internal and external. In fact, Rightscale recently cited in their ‘State of the Cloud Report’, that in average 48% of SMB workloads run on public clouds.
While healthy public cloud adoption is projected to continue among SMBs at slightly higher pace than enterprises, there is no denying that decision loops concerning the tools and cloud services selected are primarily dependent on the development models (continuous integration / continuous delivery) in practice and often comes with some degree of compromise made between available budget, source code control, speed of development, application portability and interoperability in the future.
Requirements and priorities change
Business priorities change as product or service adoption increases, market factors open new opportunities, competitive landscape tightens or new innovations enter the playing field, all of which involves scaling at a pace never imagined in the pre-internet era. Public clouds large and small, without a doubt power millions of businesses to build solutions quickly and cost effectively with a lot less overhead to meet growth objectives. However, a judiciously selected cloud partner today may cease to be relevant in a future point.
Over time, businesses may need to reassess relationship with existing cloud providers for various reasons ranging from cost optimisation, security, governance, vendor lock-in, overall performance, cloud bursting to new technology requirement for AI, IOT, VR/AR/MR, 3D and mobile, making application portability a key concern for businesses wishing to switch cloud providers.
Switching public cloud providers in alignment with business goals
Many ISVs for instance may have chosen to develop and deploy new age applications such as IOT for instance, on a certain PaaS service to reduce cost of building the infrastructure and platform themselves. As business grows, the once economically viable solution begins to blow out of proportion financially as usage base explodes. In this case the business is left with two scenarios; one they could look for another provider with similar or equivalent PaaS services at better price points; the second is to choose a IaaS provider and construct their own PaaS layer for more control over application dependencies (e.g. data services, runtime, OS, networking, encryption, and virtualisation).
Application re-platforming processes and routines differs cloud to cloud
The cloud platform on which an application runs and DevOp environment determine how tools (e.g. Ansible, Chef, Puppet and etc.), automation and standardisations are applied in simplifying deployment when migrating applications from one cloud provider to another.
While a standard process perhaps can be established to automate packaging, conduct optimisation, generate VM or container images and orchestrate deployment artefacts, the knowledge sets or expertise involved varies from one cloud platform to another. Though, there are several steps and best practices that can be adopted by DevOp to ensure portability of applications and data today.
Choose cloud providers that support Open Virtualisation Format
Chose to work with cloud service providers that support widely accepted application packaging formats such as the ‘Open Virtualisation Format (OVF)’, formulated and recommended by the Distributed Management Task Force (DMTF). This method standardises packaging of virtual machine based software regardless of cloud platforms which means migrating to a new environment or multiple clouds is swift and resource efficient.
Containerise applications
Another best practice that is gaining momentum recently, is to re-platform applications running on virtual machine instances to a container based platform such as Docker. Containerisation packs application code and all dependencies in a container image that is a repeatable artefact and multiple containers can be deployed on a single VM sharing the same resources. Aside, from the obvious administrative efficiencies and cost savings, this method is ideal to support microservices development architecture (or polyglot architecture) and distributed applications on serverless cloud instances and virtual machines.
Container orchestration and cluster management solutions such as Kubernetes and Docker Swarm facilitates orchestration, clustering, scheduling and integration of large number of container images and typically is sufficient to scale applications as needed. Consider both tools and a proof of concept with each technology, using real-world workloads.
Open standard interfaces and APIs
Open APIs and vendor specific APIs (extensions of SOA architectures) allow users to move data and expose services between clouds while masking complexities behind any one interface (e.g. functional, admin, business). In a real world situation the use of vendor specific APIs are unavoidable even in a ‘open standards friendly’ DevOp environment, especially when the business footprint in a particular cloud is significant.
API management is mandatory in maintaining balance and isolating refitting work when necessary. Security concerns should be maintained throughout the linkages by deploying third party access rights management and other tools, as data securely travels between clouds.
Adopt multi-cloud management platform
Another method to facilitate cloud migration is to implement a suitable multi-cloud management platform that integrates multiple public cloud environments (e.g. AWS, GCP, Azure, Digital Ocean and etc.) including private clouds. This creates an overlay that masks underlying platform differences that allows for easier movement of applications, workflows, and data.
Build own PaaS
Vendor lock-in and portability issues are higher in PaaS services than in IaaS. One option to reduce such reliance is to build an in-house PaaS with tools such as Dokku and Flynn, an open source platform solution for everything that is needed for running applications in production.
Conclusion
Portability and interoperability between clouds is a journey that begins from the point a business on-boards its first cloud service.
Containerising applications, automating deployment processes across multiple clouds, building tools, creating a controllable PaaS layer or at least selecting one that has an equivalent alternative, leveraging open technologies wherever possible, using standard APIs and abstracting integration layers are some of the best practices that can be adopted throughout a cloud lifecycle to ensure smooth exit when need arises. These same best practices reduces vendor lock-in, unexpected cost spirals, time and material needed to move workloads across public clouds.
Applications and systems with below average portability scores simply don't make the cut as a good migration target to other clouds. In some cases, it might be even easier to just recreate them on a new platform.
Migration processes too must be planned and executed in systematic manner with necessary tooling and automations in place to create a repetitive migration asset that includes the learnings that can be shared with the entire team.
Last but not the least, when porting over to the new cloud, systems must be fully tested and stabilised prior to terminating the old environment in ensuring business continuity.
Cloud services both IaaS and PaaS are natural choices today for development teams when it comes to realising business services internal and external. In fact, Rightscale recently cited in their ‘State of the Cloud Report’, that in average 48% of SMB workloads run on public clouds.
While healthy public cloud adoption is projected to continue among SMBs at slightly higher pace than enterprises, there is no denying that decision loops concerning the tools and cloud services selected are primarily dependent on the development models (continuous integration / continuous delivery) in practice and often comes with some degree of compromise made between available budget, source code control, speed of development, application portability and interoperability in the future.
Requirements and priorities change
Business priorities change as product or service adoption increases, market factors open new opportunities, competitive landscape tightens or new innovations enter the playing field, all of which involves scaling at a pace never imagined in the pre-internet era. Public clouds large and small, without a doubt power millions of businesses to build solutions quickly and cost effectively with a lot less overhead to meet growth objectives. However, a judiciously selected cloud partner today may cease to be relevant in a future point.
Over time, businesses may need to reassess relationship with existing cloud providers for various reasons ranging from cost optimisation, security, governance, vendor lock-in, overall performance, cloud bursting to new technology requirement for AI, IOT, VR/AR/MR, 3D and mobile, making application portability a key concern for businesses wishing to switch cloud providers.
Switching public cloud providers in alignment with business goals
Many ISVs for instance may have chosen to develop and deploy new age applications such as IOT for instance, on a certain PaaS service to reduce cost of building the infrastructure and platform themselves. As business grows, the once economically viable solution begins to blow out of proportion financially as usage base explodes. In this case the business is left with two scenarios; one they could look for another provider with similar or equivalent PaaS services at better price points; the second is to choose a IaaS provider and construct their own PaaS layer for more control over application dependencies (e.g. data services, runtime, OS, networking, encryption, and virtualisation).
Application re-platforming processes and routines differs cloud to cloud
The cloud platform on which an application runs and DevOp environment determine how tools (e.g. Ansible, Chef, Puppet and etc.), automation and standardisations are applied in simplifying deployment when migrating applications from one cloud provider to another.
While a standard process perhaps can be established to automate packaging, conduct optimisation, generate VM or container images and orchestrate deployment artefacts, the knowledge sets or expertise involved varies from one cloud platform to another. Though, there are several steps and best practices that can be adopted by DevOp to ensure portability of applications and data today.
Choose cloud providers that support Open Virtualisation Format
Chose to work with cloud service providers that support widely accepted application packaging formats such as the ‘Open Virtualisation Format (OVF)’, formulated and recommended by the Distributed Management Task Force (DMTF). This method standardises packaging of virtual machine based software regardless of cloud platforms which means migrating to a new environment or multiple clouds is swift and resource efficient.
Containerise applications
Another best practice that is gaining momentum recently, is to re-platform applications running on virtual machine instances to a container based platform such as Docker. Containerisation packs application code and all dependencies in a container image that is a repeatable artefact and multiple containers can be deployed on a single VM sharing the same resources. Aside, from the obvious administrative efficiencies and cost savings, this method is ideal to support microservices development architecture (or polyglot architecture) and distributed applications on serverless cloud instances and virtual machines.
Container orchestration and cluster management solutions such as Kubernetes and Docker Swarm facilitates orchestration, clustering, scheduling and integration of large number of container images and typically is sufficient to scale applications as needed. Consider both tools and a proof of concept with each technology, using real-world workloads.
Open standard interfaces and APIs
Open APIs and vendor specific APIs (extensions of SOA architectures) allow users to move data and expose services between clouds while masking complexities behind any one interface (e.g. functional, admin, business). In a real world situation the use of vendor specific APIs are unavoidable even in a ‘open standards friendly’ DevOp environment, especially when the business footprint in a particular cloud is significant.
API management is mandatory in maintaining balance and isolating refitting work when necessary. Security concerns should be maintained throughout the linkages by deploying third party access rights management and other tools, as data securely travels between clouds.
Adopt multi-cloud management platform
Another method to facilitate cloud migration is to implement a suitable multi-cloud management platform that integrates multiple public cloud environments (e.g. AWS, GCP, Azure, Digital Ocean and etc.) including private clouds. This creates an overlay that masks underlying platform differences that allows for easier movement of applications, workflows, and data.
Build own PaaS
Vendor lock-in and portability issues are higher in PaaS services than in IaaS. One option to reduce such reliance is to build an in-house PaaS with tools such as Dokku and Flynn, an open source platform solution for everything that is needed for running applications in production.
Conclusion
Portability and interoperability between clouds is a journey that begins from the point a business on-boards its first cloud service.
Containerising applications, automating deployment processes across multiple clouds, building tools, creating a controllable PaaS layer or at least selecting one that has an equivalent alternative, leveraging open technologies wherever possible, using standard APIs and abstracting integration layers are some of the best practices that can be adopted throughout a cloud lifecycle to ensure smooth exit when need arises. These same best practices reduces vendor lock-in, unexpected cost spirals, time and material needed to move workloads across public clouds.
Applications and systems with below average portability scores simply don't make the cut as a good migration target to other clouds. In some cases, it might be even easier to just recreate them on a new platform.
Migration processes too must be planned and executed in systematic manner with necessary tooling and automations in place to create a repetitive migration asset that includes the learnings that can be shared with the entire team.
Last but not the least, when porting over to the new cloud, systems must be fully tested and stabilised prior to terminating the old environment in ensuring business continuity.
No comments:
Post a Comment