A migration to an “infrastructure as a service” cloud service differs from migrations we have executed in the past. Instead of centralizing infrastructure services, security, middleware and data management solutions, we have to centralize the applications themselves and arrange the necessary services around it.
This means a change of perspective for infrastructure architects. The past 10 years we have standardized and rationalized services, for instance based on Gartners IT (Infrastructures and Operations) Maturity Model. We chose a standard database platform and established database clusters on which we hosted many databases. We chose a central storage solution and centrally managed security solutions. We standardized in configuration- and operations management solutions, and so on. By physically centralizing services, we could virtualize operating systems efficiently, which saved on hardware-investments, plus it caused faster IT delivery, higher availability and larger flexibility. The step towards a private cloud environment was a natural continuation of this development.
Because of this, a migration to a public IaaS cloud is a small step in the eyes of many infrastructure architects, especially if a hybrid construction emerges in which applications and services work partly on their own datacenters and are partly in the cloud.
But the step might not be as small as one would think. We have very little experience in certain aspects. For example, for 2- and 3-tier applications, we must take into account inter-service calls, file transfers, messaging and the like. One also has to account for traffic to and from the supporting infrastructure services, like authentication services. If this traffic travels large distances, latency and jitter plays a role as well as the required bandwidth. Lack of performance in the on premise datacenter was easily solved by enhancing the overall bandwidth, throughput and speed for network and storage traffic. It was a reactive yet effective method. But performance degradations due to long distances is not as easily solved.
The questions that arise in hybrid cloud constructions involve a relatively unknown terrain for many infrastructure architects. In practice, we rarely know what applications really need in terms of response time of database servers, file servers and authentication servers. The suppliers of applications rarely clarify this as well. The experience we have with mutual service traffic over distances is rarely positive.
Besides the need for more insight and experience, we need to quit thinking that a hybrid cloud means that we can host data services, business logic services and presentation services across distances: for instance the data services in the private on premise datacenter and the presentation services hosted at the cloud provider datacenter. It’s an idea that will not last, apart from few exceptions. Application-ecosystems will have to move entirely and have parts replaced by the services provided by the cloud provider. What seems to be more beneficial is to take a database as a service from a cloud provider, rather than holding on to centralized database-hosting in your own environment. It might be a better idea to keep the authentication, data management, file-sharing, middleware and other supporting services, close to the application.
As infrastructure architects we need to gain experience in shifting our orientation from a centralized and rationalized oriented services approach to a distributed and application-oriented infrastructure approach. Analyzing infrastructure services and application patterns properly might help this process.
The Open Infrastructure Architecture repository (OIAr), see: https://www.infra-repository.org/oiar/index.php/Main_Page, offers a nice starting point for this. They have been using the Open Infrastructure Architecture method (OIAm) for years to define patterns, functions and services (see:https://en.wikipedia.org/wiki/Open_Infrastructure_Architecture_method).
In creating the distributed environments, the added value of the cloud architect will consist of guaranteeing portability, maintainability, reliability and manageability of these new ecosystems. And this is necessary, because the chance that new, intractable and uncontrollable constructions will emerge is undeniable.