The Good, Bad and Ugly of Cloud Native (and Integrations)

In trendwatching in general, dare we say, IT in particular, there is a lot of jabberwocky around. There is pressure to keep up with the latest ‘hot trends’ and to appear knowledgeable and in the know.

Some terms are more susceptible than others as far as the jabberwocky effect goes. Mostly, these are broader terms that get thrown around a lot. Artificial intelligence, machine learning, blockchain and a lot of words that combine with cyber are some frequently heard examples.

In our world, the term Cloud Native is certainly part of this category. Included on Gartner's strategic priority list, it is certainly a hot topic. Depending on where you seek information on this term though, you might get a varying array of wooly, high level and conceptual answers. At the other end of the spectrum, there are also deeply technical blogs that describe certain (categories) of services and technical methods.

We are not to judge what the right approach is, but aim to clarify the concept of Cloud Native as to what we think it means, and how it relates to our core business of integrations.

The Cloud

It may be worth spending a few sentences on what the Cloud is. “The Cloud” has many layers. Aside from data, which most likely everyone knows, there are applications, middleware, operating systems, virtualisation layers and infrastructure layers in the Cloud. The Cloud revolves around the concept of sharing resources. Gone are the days where we had to invest in local hardware, and now everything else in the above list comes as a service too (with the exception of, maybe, data). Although... selling data & insights as a service is the core-business of Google, Facebook, etcetera. You probably understand where we are coming from.

In theory, the entire non-people IT budget of an organisation could consist of monthly subscription fees, assisting greatly with cost control. In a way, even IT-people could consist of monthly subscription fees: in off- & nearshoring scenarios.

Cloud Native

Then, onto Cloud Native. Contrary to popular belief, if an application runs on the Cloud, this doesn’t make it Cloud Native.

As alluded to above, there are conceptual blogs out there describe this trend in line with this quote:

“a faster time-to-market of new projects, and with an as-a-service mode, but they are also able to integrate applications more easily, both with each other and with third-party software and services.”*

Furthermore, these descriptions contain a lot of references to Lego, and being able to assemble applications quicker. Some other benefits of Cloud Native are the vertical and horizontal scaling of applications, an enhanced customer experience due to lower latency and cost savings due to limiting Cloud use to strictly that what the application needs.

On the flipside, Cloud Native does raise some questions regarding cyber security - as building applications gets more abstract, boundaries blur. More traditional approaches to cyber security leverage these boundaries, and therefore the prediction is that supply-chain cyber security approaches and tools will join the trend rankings very soon. There are some further sidenotes, refer to this blog for an overview.

According to other explanations, the concept of Cloud Native is somewhat of an aggregator for various other cloud trends. Such as serverless, multicloud / distributed cloud, the somewhat elusive ‘composable enterprise/ composable applications’ and of course low / no code. We will spare you the other “technical details” blogs.

This blog assists further by clarifying that Cloud Native refers more to infrastructure considerations, not necessarily where applications are deployed (which is a large difference between on premise and the Cloud), but more how we organise these applications. This means that Cloud Native also works in a Hybrid cloud infrastructure, where there is a mixture of on premise/private cloud and public cloud.

To us, the below quote clarified Cloud Native most of all:

“Cloud native is structuring teams, culture, and technology to utilize automation and architectures to manage complexity and unlock velocity.”

Joe Beda

Co-Founder, Kubernetes and Principal Engineer, VMware

Cloud Native and integrations

The internet is full of statements around how easy it is to integrate legacy IT stacks with modern microservices, via a Cloud Native approach.

Enriching an on premise IT stack (which companies mostly still use) with benefits of the Cloud - ‘connecting things at all levels of stack’ - seems to be most of what these trends have in common.

This is an example:

“The cloud-native strategy proposes a truly effective model to modernize IT and make business innovation through the native integration of applications with the features available in the cloud, for example, to analyze big data, artificial intelligence and machine learning (ML / AI), to interpret voice and images, for collaboration and so on.”

However, data still needs to flow seamlessly at the highest level of the on premise and Cloud stack, refer to above, Cloud Native or not.

In addition, there is an interesting contradiction in everything seemingly getting easier, however more service providers, Clouds and applications are involved than ever before.

Theoretically this holds up well, however practically we’ve seen it’s not so simple, and there can be a gap between the sales pitch, or how things should work at a theoretical level, and reality.

Should you opt to only use Cloud Native applications from one vendor, or only use Cloud Native services via one Cloud Service Provider, you might be able to natively integrate all dataflows.

This is seldom possible though, for an organisation’s entire IT stack. Furthermore, we believe, and we are in good company that it is in an organisation’s best interest that they opt for frameworks, languages, and really considerations at all layers of their IT stack, that are best of breed for what they intend to do. Choosing a single approach to all layers of the IT stack does not yield good results in the long run, although it might seem like an easy and efficient approach at first.

Conclusion

Cloud Native definitely assists with a more integrated approach to how applications can work together - but the question is how much of an organisation’s IT stack will be concentrated in Cloud Native, with the same vendor and Cloud Service Provider. We believe there will always be a need for integration technology, although we recognise it would likely be an updated version of our current Cloud platform.

For this reason, adopting Cloud Native services and building a version of our platform on these, is on our road map. We are keen to discuss your experiences with Cloud Native, or should you have a different definition of what it means and want to discuss - please reach out!

Photo by NOAA on Unsplash