True Interoperability and the As a Service Model



When it comes to modern web technologies, interoperability is key. You choose your application framework, database, content management, hosting platform, identity provider, payment processor, and then simple plug in the pieces. As the years go by you may change any single piece without needing to change the others. If you out grow your hosting platform, you may switch to AWS and the rest of the architecture remains unchanged. Maybe you want to use a new fangled application framework, and so it gets swapped out but all the other pieces of the architecture did not need to change at all.

In recent years I have achieved this vision with OrisonJS, Netlify, Firestore, Stripe, and a host of other solutions that all work with flawless interoperability. This has been a tremendous improvement on the older style of development where you had to choose a single solution that attempted to solve every problem. Contentful has been my go to solution for content management and there is just one small problem. Contentful is a service. This sounds great, "as a service" is of course a very popular concept. However, for truly complete interoperability the content management application should be separate from the infrastructure that is hosting it. What happens if I want to keep my content management system but want to host it somewhere else? Well, I simply cannot.

This might not sound like a big issue, but consider this. Let's say that five years go by and a business' technological infrastructure has been reliable, interoperable, and as pieces become out dated or better options become available, they are updated independently of the rest of the infrastructure. Now consider that the business wants to move towards on premises hosting, or AWS hosting, Contentful goes out of business, or raises their prices. In any of these scenarios web authors may love the content management application that they are using, but for financial or technological reasons they must move away from it. In an ideal, interoperable world, you would simply host the content management application on new infrastructure. In a "as a service" world, this is simply impossible.

The service model is essentially just another way of saying that the application is integrally tied to the hosting of that application. Whether this is content management, a database, a payment processor, or any other service. You sign up, subscribe, and get access to an application that is hosted by that service provider. This, generally speaking, goes against interoperability, at least in terms of making applications and hosting solutions interoperable. For example, why should my React app care if it is served by AWS or Netlify? It shouldn't care, and likewise, my content management application should not care if it is hosted by Contentful's servers or my own EC2 instance.

Does this mean that the "as a service" model is no good? Of course not. First of all these companies have taken risks, spent money, and put in hard work to make these services available, and the service model is a great way to profit off of all that effort. Also, there are some problems that are best solved as a service. I have no intention of looking for self hosted payment processing, for example. However, we should, when possible, make the application independent of the infrastructure that is hosting it. This led me to investigate open source content management systems which you can read about in my next blog post.

Popular Posts