We are currently working on our new product/project, it is a client-server application directed towards certain specific industrial/service enterprises. We are building a server (C Language and Linux Only) running a custom protocol on top of TCP with a Java front-end. We are about 20% into the coding work and are faced with a situation having to choose between Micro or Monolithic Kernel Architecture.
I am aware that Micro vs. Monolithic is usually in relation to kernel architecture, but we are specifically talking about servers.
Why a custom server and not something existing?
- Our UI needs are significant and very dynamic, thus Web/Web-browser based solutions were not appropriate.
- The statistical processing is significant at the client end and therefore, again, browsers were of little help. (Of course, we could do the processing at the server end and pass on the processed data to the client but that would imply lot of load on the server and wastage of client resources).
- Moreover, with atleast three technologies (JS/HTML/CSS) to manage even a single event makes the whole experience like sweeping the house in the midst of a desert storm - you sweep it n-times, the dust accumulates n+1 times.
What about Micro and Monolithic Server? What are you talking?
Consider the following (hypothetical) client request:
request-id: 123 request-service: HistoricDataSets request-message: Fetch all records upto the year 2010
On receving such request, a server, typically, does (we are ignoring concurrency techniques like thread and forks for simplicity):
- Parse the request string
- Identify the action (Fetch
HistoricDataSets LIMIT Year (2010)in our case)
- Interact with the persistance layer (Oracle, lets say, in our example) and fetch the data.
Format the data as per the protocol. Ex:
Respond to the client with the thus formatted data.
This is what we are calling a Monolithic Server (akin to a monolithic kernel where all OS workings are done in the kernel space).
Consider the same request again, on receipt, this time the server (we have assumed only shared memory as IPC, again for simplicity):
- Puts the request into the shared memory for the
Parserparses the string, identifies the task and directs the
Executionerprocess to execute the tasks.
Executionerthen passes the data to
Fomatterprocess which, after formatting the data into a protocol string, returns to the server.
- The server dispatches it to the client (response).
Of course, instead of
Formatter it could have been a single but separate process. This is what we are calling a Micro Server (akin to a micro kernel doing barely minimum that is required). The server effectively is only listening and responding whereas all steps are taken care of by different process(es).
Which one to pick? We are confused! While monolithic servers are tried and tested (most HTTP-Web Servers?) and easier to program and can handle concurrency quite well. Micro servers, prima facie, seem swift and in line with UNIX principle of one program to do one task, but are also complicated to develop, esp. keeping concurrency in mind.
- What are (possibly could be) the pros and cons of each approach?
- When to use which? (It could also be interpreted as a general question: When to use IPC?)
- If Micro kernel is chosen, then what functions need to be a part of core-server and what not?
- Dangers of huge monolithic application
- External Vs Embedded browser (Tangential)
- Advice for converting Monolithic app into multithreaded (Tangential)
Some information that may be helpful:
- Our prospective customers can be divided into two categories:
- Large: About 1,700 - 2,000 requests per minute
- Small: About 650 - 700 requests per minute
- Data volume per request cycle (request and the subsequent response) can be assumed to be normally distributed with mean ~ 1.20 MB and worse case about 250-300 MB.
- The product concept is relatively new but has the capability of impacting the core operations, therefore we expect the customer budgets to be flexible only post a certain lag (9-12 months) post deployment, this limits the amount of hardware the client will be willing to commit esp. the small ones.
- Each customer will have his own client-server stack. The server will be running on the customer's hardware managed by the customer's team, while clients will be deployed on the machines of the functional employees
- Remote updates for both client and server application is a must
- Real time
PUSHservices by the server may be 'highly' desired if the product clicks!