With Cloud Computing, we often hear that “Scaling” is very easy. In most cases, it is actually like that! You can simply go and add new virtual machines/instances on demand, with only some seconds or minutes to be provisioned. However, there are some other factors that improove Scalability or limit scalability. The reason for that is simply: if your software is built a way that dissalows scaling, you can never use the benefits of the cloud. Just because you can scale your instances on demand, it might not mean that your software allows that!
Imagine the following scenario: your Web Application stores data like images in the File System. Suddenly, you have increased need for performance as your business grows. So what would you do? Exactly, simply add a new instance. After a while, your users and customers complain that they can’t find their images all the time. After a while, you figure out that the Load Balancer directs to either one of the virtual machines you are using. One machine contains images (stored on the file system), the other doesn’t (as it is the new one). If your software was built in a SoA Style, you might have used a Service instead of the File System. To really scale out your Software, you now need to invest a significant amount of time into re-engineering.
First of all, we have to get rid of some confusion: when talking about Scalability or Scaling, people often talk about “Elasticity” as well. But what is the difference between those two terms? Aren’t they the same at all? There is a significant difference between the term “Scalability” and “Elasticity”. When we talk about Scaling, we talk about the possibility to add new instances and remove instances. This is just the possibility itself. Elasticity means that we have exactly the power we need for our services. If we need, for instance, 4 virtual machines, we can scale them up or down, but we still have to do some work to achieve that (e.g. starting a new instance in the AWS Management Console). If we talk about elasticity, it means that we have exactly the power of 4 machines when they are necessary and we don’t even have to care about how they get provisioned – it is automated! The goal for your software should be to enable elasticity, not just scalability.
Whenever we talk about Scaling, we mainly talk about the factor “Hardware” but forget about other important things to scale out, such as:
–Websites
–Applications
–Teams
–Organisations

Scaling Software Teams

Scaling Software Teams


If you add more and more instances as your business grows, you might also add more features to your application. However, more features also means that there is more code to maintain, more bugs to eliminate and more updates to deliver. Therefore, you need to increase your team size, which isn’t easy at all. Just because you add 2 new developers to a team of 2 developers (double the number of Dev’s) you simply don’t double the performance. Most of the time, the performance is even below the original performance for the first weeks, until they become a “real team”. But in all cases, there is a significant overload on communication and organisation involved, which can’t be solved that easy. Before taking care of scaling your Software, you might consider how to scale your teams that are in charge of delivering your software.
In the next posts, we will go deeper into different technologies and architectural styles that enable your software to scale out, not just up.
The Image used as Header is licenced under the Creative Commons Attribution-Share Alike 3.0 Unported license by José Ramón Polo López.
0 replies

Leave a Reply

Want to join the discussion?
Feel free to contribute!

Leave a Reply