What should be considered when deciding whether to replicate or distribute to maintain scalability?
When writing an application to support scalability, how can I decide whether to support it with technologies such as EJB and distribute the application across multiple machines, or write software without using such technologies and just copy it across multiple machines?
Are there any good resources (books / articles) that explain this?
source to share
Scalability means more architecture capabilities. Technology and tools are simply making this possible.
If you define your scalable architecture, then you can modify any technologies to support the architecture. You can find examples that scale very well to a large user base in almost all technology packages (be it PHP, .NET, Java, COBOL, RoR, etc.).
It's cheap and easy to deploy in the cloud these days, design your architecture with Share Nothing architecture in mind . You can easily scale on demand to any large user base.
Getting started with the particular technology you mentioned, EJB is a middleware technology and it comes with the baggage - Java EE Application Server (or Tomcat with some plumbing). The point is that EJB solutions are not lightweight and are recommended for specific use cases: remoteness, transactions, etc. In addition, the costs of developing standards-based solutions are slightly higher than using the open source stack.
In terms of scalability, standards-based solutions, i.e. EJB, JPA, etc., are also cloud-enabled and support Cloud scalability, i.e. replication and sharing. Check the link.
With or without standards, what will be the architecture of the application that can scale.
source to share
I believe your question is about vertical versus horizontal scalability.
Ideally, you should strive to achieve horizontal scalability, which is not easy.
Horizontal scalability affects the architecture of your application when vertical scalability requires you to increase horse power. We are currently in a position where we can easily scale vertically, but not horizontally. In the coming months, our platform will simply be at its maximum and we need to make changes to the platform architecture.
I don't think it has anything to do with any particular technology. You can use EJB and you still cannot scale horizontally. It is not so easy. There is a good book by Cal Henderson, Building Scalable Websites. Maybe a good read to start with.
Scalability is a broad term, usually technological.
If at the design stage you decide, I know this application will support 100k users, but I would like to be able to support up to 1 million users without the need for refactoring, then you usually want to approach this kind of scaling IMHO through a "hardware" approach ... If you know that your design can handle 100k users on two servers in a cluster, reaching 1 million can be achieved by increasing hardware, SOFTWARE solution ensuring that a 100k base is not badly designed.
Distributed technologies are fun and enjoyable, but they have overheads and problems that come with them. It doesn't really matter when you only have two nodes in your cluster and you want an object from another node, you know where the node is and you can ask for it .. and it comes with a cost, but its usually not something outrageous. but when you scale that up to say that your cluster now has 25 or 50 servers, getting that object even if you have a good container playing cop can be a completely different ball game.
Also, unfortunately, in the real world, management decision makers are often technology ignorant and tend to gravitate toward 9 women forcing a baby in a month mentality. It's much easier for you to fight, and it's honest for them to understand, if you want a lot more features we need more hardware .. not good, it will need a complete refactoring which can take 4-6 months.
With a hardware approach, although being knowledgeable, it is not infinite, there is an overhead with every server you add to the cluster and you end up reaching laws of diminishing returns.
My basic rule is, as "pure" as it wants to use all these fashionable models that you read, think long and hard to make sure they are the right solution, its very very easy to overarchitect the solution.
source to share