Reasons to address the design and building of a proprietary cloud architecture

In Blogfest-en, Uncategorized by BaufestLeave a Comment

We are still in an era of fascination about cloud services, which offer clear advantages as regards prices, scalability and data management.

Wednesday 23 - October - 2019
Baufest
Razones para encarar el diseño y contruccion de una arquitectura cloud

Among others, these services provide the possibility to focus on the company’s own business and improve the customer experience, leaving IT infrastructure in good hands and with reasonable costs, not to mention the clear benefits that cloud storage represents. However, some doubts start to appear concerning some important disadvantages that this model represents, basically linked to the possibility of remaining hostage to the big market players (AWS, Azure, Google, IBM, etc.). Therefore, we must highlight how convenient it is to design a cloud architecture of one’s own, independent of the big cloud technical solutions providers.

Proprietary cloud architecture

Let’s revise briefly the benefits of designing a corporate cloud architecture with an imprint of its own.

√ Independence: the design and building of a proprietary corporate cloud architecture enables the future migration of a provider’s in the cloud to another without major setbacks.

√ It protects vendor lock-in: that is, it avoids being in a situation from which it is impossible (or really difficult) to move to alternative providers. The idea is to have cloud design, software development and corporate architecture which are independent of infrastructure and technological solutions offered by different cloud providers.

√ Adaptability: it makes it easier to adapt to providers’ geographical distribution (for example, if they open a data center in a more accessible or closer location), improving latency periods for both, final user experience and the integration with other systems and platforms on premises or stores.

√ Lower costs: it optimizes hiring costs (for example, if a cloud provider offers lower prices for the services we are using).

√ Multi-cloud: it enables us to deploy our distributed applications solution to different providers. This concept is known as multi-cloud architecture design, and it allows us to implement components in different cloud providers, and even in data centers which belong to the company.

√ Resilience: it improves our applications’ level of resilience, diversifying risk, especially in case of disaster recovery due to a fault in one of the cloud providers. If we keep a replication scheme, or a cloud architecture design agnostic to vendor, in the event of a shutdown of a provider it is easier to relaunch the application in other provider’s servers and continue in contingency mode until the previous one is operative again.

Not a private cloud

This does not mean designing a private cloud -despite its many advantages as regards data protection-, but having a cloud architecture that allows to keep control regardless of the cloud provider in which it is implemented. Apart from designing a multi-cloud architecture independent of vendor, software development must meet certain rules so as not to bind the technological solution to a static design, and promote the building of a scalable solution, adaptable to migrations among providers, and it should also have a development and deployment pipeline as automated and validated as possible.

Thinking, designing and building a proprietary cloud architecture of such an abstraction that allows applications to be as independent as possible of a specific cloud provider, prevents the company from being bound to one in particular. For that, it is necessary at least to design an architecture that contemplates low attachment to specific cloud services -building a layer that works as a wrapper between the application and the available services, case by case-.

Have you had any experience that justifies this proposal to design a cloud architecture that is proprietary and independent of vendors? We invite you to share it here!

Comments