Hybrid/multi-cloud transformation strategy and the role of Workload Portability as an enabler for Agility
Infrastructure should be an integral element of Sustainable Software Transformations, and that is especially considering the level and depth of innovation that has happened in that space.
Agility, A Driver for Cloud?
Agility has always been one of the main drivers for Cloud adoption, however, with the increasing level of complexity of having to deal with hybrid or multi-Cloud environments with hundreds of Cloud providers out there, and considering the risk of being locked into any one of them for a large institution, it doesn’t seem like our Agility targets are easily achievable without injecting a fair bit of sophistication into our systems. Additionally, complex requirements in certain industries like finance sector such as regulatory, scalability and availability constraints for different environments that need a complex level of automation, deployment mechanisms, security and encryption with different deployment patterns such as primary/secondary, makes it even more challenging to adopt Cloud strategically for a large financial institution.
It is probably worth painting a good picture of what the future of Cloud would look like for a large organisation based on some principles and considering all the above elements, before we dig deeper into the Cloud journey, by simply starting with the end in mind.
The true Agility comes when we are able to manage our workload across many Cloud providers and keep the flexibility of moving the workload between multiple Clouds, regardless of who those Cloud providers are, and where they are, be it public or private. It also helps companies negotiate their price point with their providers, when there are multiple providers involved.
Why Still Private Clouds?
Certain industries, such as finance, and aviation need to have access to private Clouds, either because they are highly regulated, or because they need to have fast access to a mountain of data to process it internally. At the same time, they still need to stay competitive besides respecting the regulations, by relying on services that public clouds are offerings at lower price points.
As you can see so far, we need both public and private clouds for our organisations at the very least for the near future. Historically the aim has been to push all organisations to public clouds, which seems unlikely to happen in the immediate future considering everything we discussed, and now you can see public cloud providers trying to run their services under a cohesive umbrella for the private clouds as well.
Typically organisations go through rounds and rounds of vendor selection processes, to assess the suitability of these Cloud providers against their requirements, which lead to long spreadsheets containing the needs of their many internal teams which at the very end becomes very complex and convoluted.
Workload Portability
However, we perhaps need to shift our view from being forced to choosing specific providers, to a model in which we promote workload portability. Regardless of how many providers are involved in our model, and the architecture, be it hybrid, or multi, or hybrid multi-Cloud, we need to be able to move our workload from one environment to the other, without major architectural or operation change and impact to the organisation.
At the end of the day, these providers should be looked at as execution environments that might very well change in the near future, and it shouldn’t matter which one we choose as long as we can move our workload between them to achieve the true Agility we were after. And if you add the power of the open-source, then you will be avoiding the vendor lock-in at the code level as well as the infrastructure level, which gives you even more and more Agility.
The other reason for portability is the rate of change and movement from one environment or data centre to the other due to the organisational shifts, change in senior leadership, and evolution of priorities, regulations, and customer needs.
The Role of Containers
Cloud-native micro-services packaged in containers which can run in any execution environment sound like the fundamental building blocks to achieve workload portability, however, we then need one more building block, an essential one, which is a unified orchestrator on top of all these environments (clouds) to manage our workloads, secrets, configurations, automation and deployments.
Orchestrators
We need to keep in mind if we want to manage all these environments separately, considering all the permutations and complexities involved, we will end up with a lot of technical debt, and unmanageable complexity in our systems. Google Anthos, Amazon Outposts, Azure Stack, and IBM MultiCloud management console are some of the implementations which help us with that unified orchestration across all our environments.
Any chosen orchestrator should be able to tackle challenges across visibility of the applications, governance and security, application management and automation across all these Clouds while keeping the complexity at a reasonably low level when hundreds of container clusters are going to be managed across the board.
It is also understandable that organisations might be in the state of transition, and the overall strategy, be it multi-cloud, hybrid cloud or multi-hybrid cloud and the deployment and availability patterns such as Primary/Secondary, not being crystal clear yet. But one thing that perhaps should be done regardless of the overall Cloud strategy is to create portable cloud-native apps and pipelines, and once the strategy was decided, you already would be on your path of achieving an end to end portability even at the infrastructure level across different Clouds.
You could argue that elevating application portability using containerisation also needs a shift in infrastructure strategy, but the point is you don’t need the entire infrastructure and hybrid-multi cloud strategy mapped out, to start deploying containers on one cluster using a specific Cloud provider. Once done, the orchestrator can manage that workload across multiple clouds with the desired architecture aligned with target state strategy, as you are relying on containers as the unit of scale and portability.
Pellerex Foundation: For Your Next Enterprise Software
How are you building your current software today? Build everything from scratch or use a foundation to save on development time, budget and resources? For an enterprise software MVP, which might take 8–12 months with a small team, you might indeed spend 6 months on your foundation. Things like Identity, Payment, Infrastructure, DevOps, etc. they all take time, while contributing not much to your actual product. These features are needed, but they are not your differentiators.
Pellerex does just that. It provides a foundation that save you a lot development time and effort at a fraction of the cost. It gives you source-included Identity, Payment, Infrastructure, and DevOps to build Web, Api and Mobile apps all-integrated and ready-to-go on day 1.
Check out Pellerex and talk to our team today to start building your next enterprise software fast.
Photo by Philipp Birmes from Pexels
