I might advise one sober assumption in requirements: your system will only grow. It will not shrink. That’s perhaps a reasonable line of thinking, for one business owner.
Now, you are not the Mr Business Owner. You are an IT Architect or perhaps a CTO in a smaller company, tasked to deliver small to medium size web application. From the ground up. From the front to the end. From the browser all the way to the database in the back. And crucially including the hardware necessary to support it.
What can possibly go wrong?
The primary kind of system this architecture needs to support will be used to act as an internal company-wide Web Application. Starting in Q3 2020, it is hard not to do it that way.
Medium size company. Let’s say up to 5 thousand desktops. Which in turn means it is very unlikely all 5 thousand of them will try to login to this system at the same time. Ever. Web App can and will grow. It will take at least 6 months (optimistically) to the first pilot release.
A number of developers and testers will be involved. And yes, it has to be secure, resilient, and fast. And fully compliant.
Here you can see a mandatory diagram from Mr. Architect who had a “Vision”. That would be me. Full KISS. Keep It Simple Stupid. Always works. Nothing earth-shattering here.
The feasible, simple, and resilient “unit of computing”. You can install this locally or on the Cloud of your choice. Just remember: no VM’s, please. These are physical machines. And that is the secret sauce.
Keep them all on one physical machine
All what? Web Server, Application Logic modules in the middle, RDBMS in the back. Just install them all on the physical machines. With two load balancers in the front. They are not shown, because they are part of the security perimeter. Locally or on the cloud.
If you are not getting the required performance readings something is not installed right on your kit. Or you need to go beyond this simple Technical Architecture. And meet (very) different kind of budget to support it, too.
Ditto, above you can see the base unit. This is where you need to take out all the breaks while tuning the performance. And doing exactly that will never yield any serious performance gains while running on VM’s. Hence no VM’s.
It is crucial all the software modules ( aka the Application) here are stateless. Why? So that we can multiply them over two or more machines. Why do we need to multiply them? We need to multiply them to increase the capacity of the installation. In case we have left with no performance tweaks we can do on a single pair.
We simply ad one more pair. Then measure. Then if needed we add one more pair. No, it is not a guessing game. I am offering you the experience of many good architects, doing this before you.
A single unit (two web/app physical servers connected as above) can serve an amazing number of users. And extremely fast too. Four? A lot of users. With very high speed. Simply, modern hardware (and network) is so fast and capable on its own. Without fancy and expensive “solutions”.
It depends on the exact architecture of this web app but a safe assumption is one can not add more than 3, maybe 4 pairs in the front. It depends on the database usage intensity primarily. The database will become the bottleneck first.
Of course, this is not an “Elastic Cloud” architecture. But, it is simple and resilient. And that is by far the most important good thing.
This is one-way elasticity: up. For anything but www facing web sites, this is more than good enough.
Even if your business shrinks this installation can shrink. Not “at the press of a button” but it definitely can.
One note: when I say “more than good enough”, I mean feasible. Not increased costs to cover corner cases, or to cover difficult loads happening rarely. That is the balance one needs to understand and implement, in order to achieve the feasibility.
Costs so far
Above, base unit, is going to work quite nicely with adding only three new HP servers to the company fleet. 15K x 3 = 45K USD max. Circa Q3 2020.
Software licenses are expensive. A ballpark figure is 2 x hardware costs. 45 + 90 = 135K USD. I would be very surprised if it is more than that. And I will not be surprised if for important HP/MSFT customers it is half of that.
Ah, and by the way. This is way cheaper than a multi-server solution with a Database cluster in the back. Running on VM’s. Administered by your favourite Cloud provider.
So far we have been talking “Production Stage”. where the final product is delivered and running. But this has to be developed somewhere. Definitely not on the production stage machines.
For the Development stage, I recommend building the same Base Unit. This time with VM’s. That kit should be able to serve easily, several teams. With the arrangement of Virtual Servers used by them.
Above is architected with modern Web App in mind, to be delivered on that infrastructure. To read more please follow the link.
The software development is the riskiest part of it all
Now, the key to our Feasibility mantra is how to manage the development of the systems running as the Web App. My (very) friendly advice is to start with these three things:
- React of course
- To enter through the proper door, start here. And revisit often.
- Polymer App Toolbox
- With Preact as a “runtime” library
End-to-end Development Feasibility is essential.
And you can not get anywhere near that elusive goal with the volatile mixture of tools. technologies and SME’s using them. And that is the key reason companies develop on Node.JS.
Beware. Even the most advanced, web app “lightweight” frameworks can easily create bloated, unusable apps. No matter how much or how little you have paid for them. And yes, do not forget the testing costs, too.
For a “step zero”, not mentioned above, I might recommend PWA Builder. For the pilot project perhaps.
User Acceptance Testing
Depending on the organization, the UAT team will get its’ own deployment on Virtual Servers.
If the project is a larger one, UAT Stage Base Unit can be set up and used. Again it depends. Usually, teams are starting all on one vase unit with VM’s. If that becomes too crowded separate UAT stage is formed. With the hardware, the same as already discusses “Base Unit”.
That arrangement certainly gives a very close picture to the future production stage under for example heavy workload.
I assume you are by now properly manipulated with all the marketing terminology one can be manipulated with by now: Kubernetes, Containers, CI, CD .. you name it. Instead of the fancy deployment “solutions”, use whatever your admin is most comfortable with from the standard offerings she/he is used too in the decades past. And yes, by no means, let him/her/them be part of the hardware specification stage.
Just ignore the VM brigade (Gasp!). Specify physical boxes with a max amount of RAM and DAS. As we have shown at the production stage install two of these, with a safe couple of fast load balancers in the front. Connect them servers, to the third one: DataBase configuration in the back. Off you go.
Since 2007, I/we do always use HP. And for this kind of architecture and implementation, it is always DL 360.
Remember. Our installation can and will serve hundreds of simultaneous users. With very high speed. And with minimum fuss, usually generated by VM installations. Simple and therefore resilient. Fully owned by you. Sit back, relax, enjoy life.
But. You have questions. And we have answers. For full staged delivery solutions please do mail us by no means. Then we will talk about how do you actually use this architecture to build a real-life expandable server farm in your situation. Feasibly.