Architecture – Micro vs Monolithic Server Architecture

Architectureserver

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:

    response-id: 123
    success: true
    response-text: DataSets

  • 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 Parser process
  • The Parser parses the string, identifies the task and directs the Executioner process to execute the tasks.
  • The Executioner then passes the data to Fomatter process 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 Parser, Executioner and 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.

Question(s)
– 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?

Similar/Related questions

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 PUSH services by the server may be 'highly' desired if the product clicks!

Best Answer

Economics sometimes govern much more critical answer than the core theory behind choices. The most important thing is that if you are looking at something 'vast' in your case, where you application needs genuinely tough deployment - the lesser the number of wheels you invent yourself, the better it is. If it works, i won't care if it is monolithic or micro; if it doesn't i won't care it either!

It may be true that very conventional Webpage based apps might not be for you - but you need to take a little broader look and see you can use things ready to go and later evolve your way out to see if you can replace that element by something better. That way, not only you will save time for the first thing - but you will also improve your understanding on what really matters in real life. Here are some pointers you might consider.

  1. If you really need very high scalability, consider how your servers will divide the task rather than churn numbers as fast as they can. Eventually, you will have a load that one server cannot really take up even if intel makes fastest processor on earth and customer is ready to pay! So request routing and load balancing is more important than the efficiency of the protocol itself.

  2. HTTP is still best -if you need to scale up. (You can also get easy to buy load balancers if you use it). Custom protocol requires custom arrangements.

  3. HTTP doesn't mean you need to throw around HTML, java script at all. Doesn't even mean you need to have regular apache server and web browser. You can use HTTP between two custom clients and elements like AOL server or lighthttpd that can be used as a library if communication is not a huge data transfers. You can also use SOAP on both sides with tool kits like gSOAP.

  4. Even if HTTP definitely doesn't fit the bill, consider something like BEEP, that helps you make things more efficient. Alternatively there are many proven RPC, RMI mechanisms that exists.

  5. Try to see that you can do maximal work more by doing parallel processing in the back-end and servers are only queried when work is done. If this works -there are frameworks like MPI, or there are many other distributed computing tool kits that can be of help.

  6. Finally, while i may not be in a position to know exact needs, but you may either need to distribute a lot of data or do a lot of computation, if you need both - there is still some core architectural inefficiencies.

To me, creating a new Protocol, and than creating a new server framework is a double experiment that you shouldn't do together. If your stakes are so high, first you should actually try to experiment with existing tools to see the limits of what is been done so far - only then you will know the real challenges.

Lot more has been accomplished in the research of distributed systems than just web apps. So you should research that.

Dipan.

Related Topic