Micro vs Monolithic Server architecture

Question

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

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

Answer 1

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.

Answer 2

This seems very academic to me. And frankly, I find the second approach to be just as monolithic. This is as far as you should go:

1. Parse the request
2. Handle the request

The request handler chosen based on the request parameters should encapsulate all aspects of handling the request. Whether or not the handler actually performs queries on your data store and whether or not it uses standard formatting to return the data is irrelevant from the layer above. As a matter of fact, it probably will do just that, but there's no value in making assumptions about it.

Answer 3

1. Monolithic kernel is much older than Microkernel. It’s used in Unix . while Idea of microkernel appeared at the end of the 1980's.

2. the example of os having the Monolithic kernels are UNIX , LINUX while the os having Microkernel are QNX , L4 , HURD , initially Mach (not mac os x) later it will converted into hybrid kernel , even MINIX is not pure kernel because device driver are compiled as part of the kernel .

3. Monolithic kernel are faster than microkernel . while The first microkernel Mach is 50% slower than Monolithic kernel while later version like L4 only 2% or 4% slower than the Monolithic kernel .

4. Monolithic kernel generally are bulky . while Pure monolithic kernel has to be small in size even fit in s into processor first level cache (first generation microkernel).

5. in the Monolithic kernel device driver reside in the kernel space . while In the Microkernel device driver reside in the user space.

6. since the device driver reside in the kernel space it make monolithic kernel less secure than microkernel . (Failure in the driver may lead to crash) while Microkernels are more secure than the monolithic kernel hence used in some military devices.

7. Monolithic kernels use signals and sockets to ensure IPC while microkernel approach uses message queues . 1 gen of microkernel poorly implemented IPC so were slow on context switches.

8. adding new feature to a monolithic system means recompiling the whole kernel while You can add new feature or patches without recompiling.