Blog Spain

Omni Cloud capability with Ontologies and Open Source

Fernando Pereiro, Head of Devops and Corporate Platforms

There has been much talk about Multi-Cloud and Hybrid Cloud strategies, architectures and processes in recent years; these concepts provide organisations with a greater number of opportunities as they have access to a wider range of services, and all of this is in addition to the significant advantage of not having to depend on one single provider or environment.

So why don’t we move away from vendor-based strategies to give organisations the ability to be where they want, when they want? Why not let choosing a supplier be a tactical rather than a strategic issue? We call this Omni Cloud capability, the ability to be where you want, when you want, always prioritising business continuity.

But… how do we do this?

The first thing is to try and move towards the utopia of systems based entirely on Open Source, and I say move towards because it needs to be an Open Source First vision and not an Open Source Always vision, since aspects such as operational efficiency, ease of use and a need for customisation all need to be taken into account when evaluating the use of Open Source. That being said, it is still true that Open Source tools are a point of union and, therefore, a jumping off point between the different Cloud providers.

Like everything in life, the secret is balance; in this case, the balance between Open Source and the managed services of a Cloud provider (among which we can highlight those “Serverless” As such, it is technically important to validate the inclusion of market standards, but also to use higher priority services when it makes sense to do so. Everything has its place and its use case.

On the other hand, it is also important to analyse our own systems, our own architecture and our own assets to know how they would do in different Cloud providers.

This may seem very abstract, so the way to make it more concrete is to use Ontologies: an ontology is a formal definition of categories, properties, and relations between entities that essentially or actually exist for a particular domain of discourse.

But there is also another definition that I like better: a shared understanding of a particular domain of interest, which can be used as a unified framework for solving problems such as interoperability, conceptual and terminological confusion, etc.

The concept behind an Ontology is very simple and powerful, since it is entirely based on the cataloguing and labelling of different entities and the relationship between them; our domain of interest is the Omni Cloud capability, so through the Ontologies we must seek to obtain a framework by following these steps:

1. Make a graphic representation, a diagram of our software assets with their existing or potential relationship with various Cloud providers and the services they offer. The following chart (a very basic example) could represent the current state of an architecture based on Amazon Web Services and Google Cloud Platform, or that of an organisation using just one of these providers, with a view to using the other at some point.

1. The graph will need to become more complex so we can fully understand everything it is meant to represent: adding attributes to each entity (tags, customisation, etc.) and each relationship (protocol, networks, ports and even deployment flows).
2. Transform the graphic into a migration or operation script that tells us where everything needs to go, but above all, how we will get it there. It’s important to remember that, when it comes to the Cloud, the how is more important than the where.
3. Once we have an accurate and detailed graphic and a clear script, we can extract a deployment flow that is based on a DevOps ecosystem, translating each entity and relationship into a part of that flow to then end up with an assembly line, because we would know exactly what types of services we need from each provider, what steps we need to take and what technology we need in each case.

Conclusión

Are we sure that, even with broad Multi Cloud strategies, we will not need to change it in the future? Well, obviously nobody can predict the future, but I would say that, whatever your strategy and whatever your level of Cloud maturity, there will still be other large-scale migrations to come.

Omni Cloud is the ultimate expression of Multi Cloud strategy. It represents the total abstraction between software and infrastructure, providing the ability to run anything (any workload) anywhere (at any service provider). For this reason, it is very important to first understand our systems and determine how they may perform in the various different Cloud environments offered by the market, to then use Open Source tools, as long as it makes sense to do so, as they are currently a jumping-off point between different providers and services.