Some further thoughts about application oriented infrastructures

This morning I shared a post written by my esteemed colleague Eric Groot about the move towards an application oriented infrastructure. The day before I had an interesting conversation with him during lunch time about, among other cloud related subjects, this topic. The move towards an application oriented infrastructure poses some interesting challenges, not unlike the ones we face today regarding physical infrastructure.

E.G. what storage shall you use? Local, SAN based? Where do you want and or need your IOPS in a cloud infrastructure? Close to the workloads or centralized? In an application oriented infrastructure you want performance where you need it, as close to the virtual machine as possible. That is why solutions like vSAN, Nutanix and EVO: Rail are rapidly growing and becoming more and more popular. For more traditional environments (but not only) PernixData FVP bridges the gap and brings IO close to the VM (and off course FVP does much more than that). Challenges, challenges, crying for founded solutions. It is not as simple as a plain good or bad.

Off course people tend to stick to what they are used to, like a SAN admin might not be very eager to implement or advise a PernixData based solution, or a data base administrator will probably advise you to move all or at least all important data bases to a cluster (be it Oracle or MS SQL) and that is a proper valid solution in its own right, isn’t it?

In my opinion application oriented infrastructures need their components as close together as possible. So no more centralizing of databases on a SQL cluster, but a dedicated database VM for only a specific (multi tiered) application. All tiers of the application can then be wrapped up in a container, like a vApp, so that multi-tiered applications can be managed as if it were a single VM.

Towards an application oriented infrastructure

Posted on 30 July 2015 by Eric Groot http://infrastudio.nl

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.

Infrastudio – On IT Infrastructure design and implementation: The inhibitory factor for cloud adoption

I want to take some time and ask your attention for a blog written by one of my colleagues, Eric Groot. He writes a great blog on infrastudio.nl and with his permission I share his latest post here.

The inhibitory factor for cloud adoption

Posted on 11 July 2015 by Eric Groot

Educate engineers and administrators to organize and manage cloud environments. If you do not, this will become the inhibitory factor for cloud adoption programs. The promises of the cloud sometimes give the false impression that IT departments can be closed down. But this is still far from reality.

I guide my organization into a cloud-only infrastructure. This cloud-based solution makes the administrators work easier and outsources basic services. However, the cloud customer will remain responsible for many aspects of engineering and management. This applies to the (guest) operating system, to the support services, middleware, applications, security systems and the availability of data. Coordination is needed between cloud client and supplier, especially in the area of networking, security and for all things that are not standard.

For developers, this applies to a much lesser extent. The commissioning of development and test environments is fairly simple. Isolation of these environments make experimentation possible and consequences of mistakes limited. A wide range of IT support services is not necessary. Much can be controlled by the developers themselves. However, it is a mistake to think that this is also true for production environments.

To make applications run and useable for end users and other applications in a medium sized environment, about 150 infrastructure, middleware, security, management and presentation services are required. These are generally invisible to the end user. A part of these are outsourced to the cloud provider. But many of these remain the responsibility of the cloud consumer.

Cloud (software) vendors are working hard on automating application supporting services, such as software defined networking, policy-based security, orchestration and self-controlling scalability. These are beautiful techniques, but also often vendor-specific, creating a new kind of vendor lock-in. Moving a workload to a different cloud environment is only possible at the high cost of re-engineering, for example because the application security is lost entirely. Architects therefore consider strategy, functional analysis, technical analysis, choices and guidelines so that cloud services are used in a financially and technically sound fashion. Because this is not business as usual anymore, it is important to involve engineers and administration early on in cloud adoption programs.

So why are they conspicuous by their absence at cloud provider summits? Or in other words, why are there no cloud summits organized for technical engineers? Fortunately, there are programs, certifications are many online programs available. And yet it is my observation that engineers are just waiting for what is to come and that they are barely involved in these important developments. This will be an inhibiting factor for successful deployment of cloud services.