SugarCRM Diagram: Single Server Deployment

Technical concepts are often times easier to convey through images. One such concept that is more easily communicated in images relates to the idea of deployment topologies for SugarCRM.

Changes to the underlying server elements required for Sugar 7 have generated a number of questions in relation to Sugar deployments. This and other posts to follow will hopefully help answer some of these questions, as well as discuss some common pros and cons for each scenario.

For our first example, we will discuss the simplest deployment scenario, using a single server.

Sugar 7.x Single Server Deployment

In this diagram we see a single server being used to host the SugarCRM application. It is assumed that the hardware on that server would be adequate to support the load.

What are the pros and cons of such a deployment? Let us first take a look at the pros.

PROS:

Simplified installation. Installing all components on a single server generally means reduced complexity. For example, the need to configure network security to allow multiple servers to communicate with each other is eliminated.

Reduced costs. As a general rule of thumb, using a minimal number of servers usually translates to reduced costs. Its not different for a Sugar deployment.

Now it is time for the opposing view.

CONS:

Single point of failure. This is perhaps the biggest risk with this type of deployment. Should a failure occur at the server, such as the hard disk failing, it is likely to cause a complete outage. This in turn would prevent all users from accessing Sugar until the problem is corrected.

Limited scalability. The single server could be upgraded over time to handle larger user loads, but this growth is limited. Eventually you will hit a limit on the number of CPUs or amount of memory the server is capable of using at which point you would need additional servers or a new one with higher limits.

Security risks. Given that all the Sugar components are installed on the server that is in turn exposed to the internet, the risks to your data is greater. A malicious user that obtains access to your server could potentially have access to not only the Sugar files, but also your Sugar data.

Summary:

This type of deployment can be useful for rapid roll outs with low user counts. However, they bring with them important limitations and areas of concern, especially if Sugar will be accessed by users external to your network.