A microservice, or better yet, a microservice style of architecture is the current darling of the software development world. The basic idea behind a micro-service style of architecture is that you break apart your system into multiple code bases that can be worked on and deployed independently. The services usually communicate between themselves by calling each other over HTTP (Remote Procedure Call) or through a message and queuing mechanism (Pub/Sub).
The value of this style of architecture, if designed effectively, is that a service can evolve without any related services needing to change as well. The only time a service would need to change, because of a related service changing, is if the interface used for communication between the two services endures a breaking change. This is why it is important to encapsulate all implementation and policy logic within the boundary of the service and not allow it to leak to consuming services.
So how do you decide what belongs in Service “A” vs Service “B” or even that a Service “B” is needed? The key is to focus on what requirements are likely to change over time and/or across Customers. If you split your system into 3 services and every time you encounter a new Customer requirement you need to make code changes to every service you have not effectively decomposed your system into microservices.
The Java and .NET engines are not necessarily microservices in the normally accepted definition of a microservice because there is no way to communicate with them over HTTP or Pub/Sub. You can however wrap the Java or .NET engine code so that this communication is possible.
The RESTful engine, on the other hand, does fit the accepted definition of a microservice because it can be communicated with over HTTP. The RESTful engine is simply a .NET engine wrapped in a web service with RESTful style endpoints.
The Windward processing engines, whether .NET, JAVA, or RESTful, are basically platforms for the processing of encapsulated business logic responsible for the production of a specific Document or Report. Changes in one Template do not affect any other Template. Templates are created as independent code bases and the deployment of one Template is not dependent on any other Template. Because the requirements for Documents and Reports change frequently, it is important for your agility that you view the code that defines a Document or Report as a service…and possibly even a “nanoservice”.
More and more microservice style architectures are deployed in the Cloud in various managed deployment scenarios: Virtual Machine (VM), Container and Serverless Function (e.g. AWS Lambda, Azure Function). Linux VMs are used the most because of cost savings and the newest version of Azure Functions will only work with .NET Core. In 2020, Windward is developing a .Net Core compatible engine in order to meet the many different cloud deployment scenarios.