Most of the concepts that we have been talking about in our iPhora Journey are neither new nor revolutionary. Collectively, they merely represent the current state of the art in designing web applications.
In other (i.e., non-Domino) platforms, you would need an array of services each running on a separate server, and you would have to build the integration between the different components and maintain security between all of those components. With virtualization and containers all of the necessary services can now bundled into a single installation, which is helpful, but the integration of those components can still be fraught with issues, especially compatibility between different versions of those services.
With Domino all of this is taken care for you: authentication, directory services, security, web services, and database services are all tightly integrated in a single server, which is an advantage that no other technology offers. While Domino has its quirks and does not support many of the latest features, hopefully HCL will be addressing those in the near future. Even as it stands right now, the simple addition of nginx as a proxy to Domino addresses most of the deficiencies.
The iPhora platform is built on Domino, and in doing that we take advantage of the inherent integration of the Domino services. But we also incorporate design methodologies that are usually associated wit non-Domino applications. With this approach, iPhora has the capabilities and features of a modern web application, but all it needs to run is a single server with the most minimal of hardware requirements. We challenge any vendor to be able to do everything that iPhora does on a single box as small as this.
Creating a modern application is not solely about using latest technology to build the application. Well-supported technologies with a long term commitment to maintenance are always preferable to the latest design fad. The important question is what you do with that technology?
The iPhora concept evolved over the span of 15 years, as we developed applications for organizations, both large and small, and gained experience with how companies handled their internal business processes. Step by step, we abandoned the more monolithic approach normally used when creating Domino applications, for a more fluid and plug and play architecture. Eventually, we wound up with a service based and loosely coupled architecture, a microservice architecture. It should be noted that this applies to the iPhora components that we developed, not to the underlying Domino services.
Wikipedia defines microservice as:
"A microservice architecture – a variant of the SOA (service-oriented architecture) structural style – arranges an application as a collection of loosely-coupled services. In a microservice architecture, services are fine-grained and the protocols are lightweight. The goal is that teams can bring their services to life independent of others. Loose coupling reduces all types of dependencies and the complexities around it, as service developers do not need to care about the users of the service, they do not force their changes onto users of the service. Therefore it allows organizations developing software to grow fast and big, as well as use off-the-shelf services more easily. Communication requirements are reduced. These benefits come at a cost to maintaining the decoupling. Interfaces need to be designed carefully and treated as a public API."
Using the programming tools available in Domino, we were able to build a microservice architecture that passes data in and out using a common bus and transport schema. Each microservice is an isolated black box with only input and output.
Remember that in a previous blog I mentioned the importance of the JSON format and the ability to quickly process JSON. The reason is that the data transport layer between microservices is all JSON. By having all input and output defined as JSON objects, we achieve a standardized and easily extensible communication layer. This allows microservices to be independent and reusable by multiple services and processes. A typical process can chain together a series of microservices to accomplish a specific and highly complex task, as opposed to writing a custom services to accomplish the same thing.
But how do you connect these different microservices together to create your application? This leads to our next discussion next time, flow-based programming.
Comments