Cloud computing already has a comparatively chequered history. We have moved from public cloud to now also understand how clouds can be built to deliver private, hybrid, multi and (just occasionally) poly-cloud instances, the latter being a separating-out of different parts of an application or data service workload across different cloud service providers.
But despite its rapid growth and current diversity of shapes and sizes - and despite the drive to adopt more virtualised work tools and platforms during the Covid-19 (Coronavirus) pandemic - the widespread proliferation of cloud-native technologies are still somewhat stifled.
From FOMO to FOCN
It’s not so much a case of FOMO (fear of missing out), it’s more of a case of FOCN (fear of cloud-native). Most companies are cloud-adoptive rather than cloud-native. A Rackspace survey carried out in 2020 suggested that while 9 in 10 businesses described themselves as cloud-native, they couldn’t quite agree on what the term meant.
This is the view of Pini Reznik in his role as co-founder and chief revenue officer at Container Solutions, an Amsterdam headquartered company known for its cloud-native software engineering work. Reznik suggests that the fear of cloud-native adoption may be a factor of firms perceiving that this is the sole preserve of bigger blue-chip companies.
The fear factors here may be down to worries related to spiralling costs. After all, for cloud to live up to its infinite scale-out and scale-up breadth, budgets will need to exhibit an equally limitless scope. Other fears may be down to complexity and lack of expertise. After all, cloud engineering necessitates that firms employ cloud engineers, or at least software developers and data scientists with an appropriate sophisticated level of knowledge and competency.
“The truth is, much of the technology around cloud-native has now been heavily democratized [and simplified through abstraction layers] to the point it’s now available to just about any businesses, large or small. That’s even more true when you consider that cloud-native itself isn’t just about technology - it’s a philosophy in its own right.” said Reznik.
It could even be argued that smaller businesses and start-ups are likely to find it easier to embrace a cloud-native culture because they’re more malleable and less set in their ways than large, corporate entities. If we accept this proposition, then what core competencies should firms look to understanding as they develop their cloud-native philosophy?
The five pillars of cloud-native
For Reznik, the collective experiences of the Container Solutions team come down to five core pillars of technology that firms need to understand and appreciate, develop skillsets in, or at least get to some level of awareness and cognisance of in order to be able to move to put parts of their IT stack into cloud-native orbit effectively. In short, it’s a question of containerisation, dynamic management, microservices, automation and orchestration.
“In terms of containerisation, an organisation should think of this a method of ‘packaging’ or encapsulating an application in its own virtual runtime environment, complete with all the dependencies it needs to function, making it easy to test, move and deploy independently. This makes businesses far more agile as they scale up and add in new functionality,” said Reznik.
Also key is dynamic management, although the term taken out of context sounds like it means very little and could be the sort of padding used by management consultants.
What we mean in this case is an ability to manage cloud resources in a dynamic way that moves with the size and shape of the cloud estate owned at any given time. This means that new cloud instances can be provision on-demand, custom-built cloud services can be optimised in different ways (for extra memory, analytics, storage, Input/Output and so on) and cloud resources no longer needed can be retired safely, efficiently and above all cost-effectively.
Microservices matter, massively
“Our central pillar here would be microservices. This really goes hand in hand with containerisation and involves designing applications as a collection of small, independent components that are decoupled from business-wide dependencies. These microservices can be deployed, upgraded, scaled and restarted completely independent of other services - making businesses more resilient in the face of change,” said Reznik.
Pillar four of cloud-native is automation, in all its forms. Automating actions that happen inside software systems that are increasingly self-managing and autonomous is a core functionality that is evidenced through modern computing stacks. Reznik and team talk of replacing manual tasks (such as maintenance, updates, patching and other core administrative functions) with scripts or code. By doing so, organisations are able to establish systems that work independently and reliably.
“Often, businesses rely on third-party partners for their automation needs but there’s very little reason this can’t be done in-house as part of a broader container orchestration strategy,” he said.
Finally then (although this is a list that should remain inherently dynamic given the always shifting nature of the subject matter it applies to) we come to orchestration. Reznik contends that the orchestration function is ‘where the magic happens’ in real world cloud systems. An orchestration tool like Kubernetes can tie all of our previous pillars and principles together by automating the deployment, scaling and management of containerized applications.
“The key thing about the above five principles or technologies is that they’re readily available and relatively inexpensive. Businesses need to develop a strategy and culture where this level of composability and ephemeral IT is the norm, not shy away from it,” enthused Reznik, who wonders if the challenge lies in exactly how businesses should persuade their strategic partners to adopt and integrate their own composable assets.
This whole topic may come down to the essentially ephemeral nature of the technologies being used.
Some data and application elements will still be ‘persistent’ for reasons related to security, backup or other. Some data and application elements will be on-premises where needed, for reasons related to legislative or regulatory compliance. But some data and application elements can be more cost-effectively and more automatically managed if they are moved to a cloud-native existence. Appropriately provisioned for safety and security, there should be no reason why not.
One day, perhaps soon, IT stack cloud-native ephemerality will be a commonality, a practicality and perhaps even a formality... until then let’s make it a logicality until it becomes an eventuality.