Nirvana – Implementing the Principles of Anywhere/Any Premise Platform

Integration Services in the Enterprise – Implementing the Principles of Anywhere/Any Premise Platform

Where is Nirvana?

Why have we not seen more blurring of lines between the cloud and on premise environments? I humbly suggest that these two environments are indeed one and the same phenomenon. I will dive a little deeper later in this essay, so bear with me first while I define the what I see as the core issue -  which is one of a disconnect in understanding and perspectives (people) rather than technology or process

The Core Issue is a lack of understanding on both sides of the same coin

These days, there is a lot buzz about terms like Cloud, On Premise, and Hybrid platforms. Also, there is a lot of buzz about platforms like platform as a service (PaaS), infrastructure as a service (IaaS) , and software as a service (SaaS). Digging a little deeper, I find it difficult to really tell the difference between external implementations “cloud” and internal implementations data centers; especially in large organizations.

What I have observed is that there is a lack of understanding on the both sides of the field. The cloud focused community has limited understanding on the setup and apparatus in the enterprise, and oftentimes are befuddled whether to look at expanding into the data center (enterprise) space or how to effectively execute in this space? On the other side, the enterprise on premise community, does not really have a clear understanding on what the whole “cloud” thing is about and appear to be dazzled at the rate of change in this space. They would love to embrace this technology and harvest all the benefits but are really not sure how to lay out a strategy and execute it. Herein lies the dilemma that both communities face.

The Lines are Blurring

In my simple mind, I tried to dig a little deeper to see what the differences are, and hopefully the impedance, between both environments and struggled to really see one. Here is how I looked at it using the analogy of 2 similar companies that are competitors:

·      Company Alpha and Delta have both decided to stand up an Integration Services platform using a modern forward looking product from say MuleSoft’s AnyPoint Platform (APP).

·      Alpha Co, decides to engage one of the cloud services providers like say AWS, while Delta Co, decided to stand up its APP platform in its own Data Center.

·      From a procurement standpoint, both infrastructure teams procure the same gear – routers, switches, storage, compute, memory, etc.

·      Their engineering and infrastructure teams both build the same stacks using the same components including containers, ESX host, VMS, JVMs, etc.

·      They both Install and setup the same applications on both platforms, I mentioned using MuleSoft Integration platform (APP) in both implementations, as a example

·      They plan to build and deploy identical REST & SOAP services to run on both platforms

·      At the end of the build and deployment process, both platforms are exactly identical, besides the fact that one lives in a traditional data center, while the other is hosted by a cloud service provider

·      Customers are the same as well both companies are competitors. Let’s assume that they are both going after mortgage customers and are offering and end to end solution to their customers. One stop shop so to speak

·      From a change and deployment perspective both companies have embraced CI/CD and SDM and current and forward looking methodologies for managing change

·      Both use Agile Methodology for the SDLC and release routines

So what is the Difference, I ask?

Given the bullets items listed above, many colleagues and subject matter experts that I have asked and discussed this phenomenon with have either agreed that there is essentially no difference or that if any, it will be in the management of the platform rather than the technology stack or operational process, that we will see the difference.

They tell me that most on premise management teams are just not able to move as fast as the change rates required in the cloud or are not comfortable moving that fast for fear of “breaking” something. If indeed this is case, and both platforms are identical end-to-end, why then will this be a concern to the on premise community? Could it possibly be because they are not as familiar with this process and do not really have an understanding that is why they are hesitant?

In cases, where the velocity and frequency of change is much higher than in traditional in on premise environments, I can see the case of an initial concern from the On-Premise community. If this the case, then it appears to me that is a people problem, that can be addressed and does not change the fact that both platforms and how should be run are essentially the same.

The Difference

·      On Premise – the difference to me is really not a physical (technology) issue, nor is it a process issue since they both are agile with the software tooling and methodologies for SDLC, I see it as a people and culture issue. The On-Premise folks worry about security, opening the networks, data breaches, changing true, tried, and tested processes, fear of the unknown, possible regulatory implications, etc.

·      In the Cloud – the difference to me is really not a technology or process issues, it is also a people and culture issue, where there is a doubt that the On-Premise community will allow all the tooling, practices including connectivity and security to happen On Premise. The cloud community worries that it will lose control if its precious tools are brought on premise. “Oh, no there goes Git Hub and all the open source things we did to get street cred and be considered legit. After all no one thought we could do this”. Skepticism about the unknown

·      All said and done, they are really two sides of the same argument.

So how do we reconcile this?

·      Tech Companies – I believe that want to compete in the both the cloud and the enterprise must have a mindset that their products are agnostic to the platform/environment therefore can be deployed anywhere. Hence the term Anywhere/Any Premise. Their tooling and management components have to be built and deployed in such a way that they should not care where they live. Their products should have identical functionality no matter where its deployed. In the case of MuleSoft, I see a lot of promise and expect them to be the one of the early if not the first one to accomplish this feat.

·      On the Premise side - Tech team and their management must be willing to bend and change some. They have to understand that the modus operandi and the goals are the same as their cloud colleagues. Activities like regularly scheduled patching may have to speed up on the application side. They have to embrace concepts like automation and self-service. I often have to remind them that planes fly via radar especially at night and have done so for a long time. I remind them today we are at the advent of driverless cars. With these constructs in place today, software change management (frequency, velocity, automation, self-service, etc.) can change too, if you get my drift.

·      I must state that the worry about security is valid and should never be underestimated, but it should never impede change.

·      The worry about corporate data leaving the data center is another valid concern but it should not impede change.

In summary

I see a convergence of both platforms in terms of people, better understanding of what each does, the realization that they both really have common goals and are beginning to have common change management practices is promising. As they meld, the Nirvana of Anywhere/Any Premise will become a reality. Those forward looking companies like MuleSoft that understand this and act on it will experience a strong growth and reap the financial benefits in the very near future. If anything, the blurring of lines are an indication that the time is nigh.