From time to time, we invite industry thought leaders to share their opinions and insights on current technology trends to the IBM Systems IT Infrastructure blog. The opinions in these blogs are their own, and do not necessarily reflect the views of IBM.
One of the common problems in current software development is how to scale, and how to do it efficiently. It’s important to examine some of the common pitfalls in different techniques for scaling, and understand how you can make this process more efficient and manageable.
There are two main ways to scale. In horizontal scaling you add more machines, and in vertical scaling you use a more powerful machine. The important thing to remember is that you have a choice.
The classic way to scale is by scaling the database and using as much cache as you can. If you decide to use a relational database, so business logic is inside the database handling data integrity and transactions, then you must sacrifice some of the scaling capabilities. If you decide to use a document-based database, then you can scale horizontally, but the application must take care of business logic, integrity, and in some cases the concurrency and synchronization.
No matter the approach you choose there is always one big issue: Network delays between different nodes. When you start to scale, if you add 10 more nodes, you are not getting 10 times more throughput.
A common technique for horizontal scaling is microservices. This is a popular approach for startups, because the architecture is easy to apply when you start from scratch, and most importantly it allows you to scale. The microservices approach is to split your system into small, self-contained units that you can develop independently, and scale only those parts that need to scale. However, these decisions must be made early in project development, and at that stage, not everything is clear. The risk: What if you have to scale really fast, but your code and infrastructure cannot handle it?
Let’s take a step back and ask a simple question – why do we need to scale? One physical machine has a limit to how much it can process, so we add one, two, or a thousand more, and we have to deal with all of the complexity.
Instead of adding more servers, what would happen if you could increase the capabilities of the current server in such a way that there is no overhead at all?
This is vertical scaling, and it combines powerful processors, the symmetric multiprocessing (SMP) of hundreds of processors, shared memory and wide data pipes.
The result is that you have the same monolithic application that is developed, supported and managed with the same efficiency, but you will be able to scale on demand.
At the beginning I mentioned that there is not a universal technique that will work for everyone, and you must choose the proper tools for the job. There are use cases where the monolithic approach with vertical scaling is best, and others where horizontal scaling is better – for example, if you already have a running system based on microservices. But what if you could do both on the same server?
Such a machine exists, and it is calledIBM LinuxONE.
Some of you may be thinking, “This is just a faster machine, at some point we will hit its limit and then we have to rewrite everything to handle future growth.” You would be correct, but you must understand the potential scale of this machine: 30 billion requests per day, 2 million Docker containers, and 17TB MongoDB instances.
You are likely asking yourself – aren’t all industries implementing this technology? This is a good question with a simple answer – it is an architecture that was originally sold only to big enterprises. Now IBM is making it accessible for everyone. And cloud service providers are offering LinuxONE as a service, so you can take a small part of it for a smaller price. Since this is Linux, you can run almost every tool, server, database and software that you want to use.
This is why Cognition Foundry recommended that Plastic Bank build their applications on IBM LinuxONE – so they can start small and scale rapidly, without needing to rewrite their applications.