As modern IT infrastructure becomes increasingly more complex, it is becoming quite common to represent and to document each element as part of a technology stack.
Technology stack, also called a solution stack, is a set of software components that compose a logically complete platform for running a service or supporting an application.
Operating system, all sorts of server software, small local services running on the OS along with any automation solutions – all of these can be part of a technology stack.
Technology stacks may be found virtually everywhere but in some cases the simplicity of final solution does not warrant the use of the “tech stack” definition. Perhaps a good practice is to use technology stacks terminology only when you’re dealing with three or more components on top of an OS?
Let’s look at a very simple example. Say, you decide to setup a self-hosted WordPress blog. Even the simplest of WordPress blogs would requite a number of infrastructure components for your blog to function properly:
Looking at the most common freely available software components, we will likely arrive at a common combination: a Linux OS (RedHat, Centos, Ubuntu, Debian or dozens of others), an Apache webserver with PHP built-in and a MySQL (or MariaDB) database server.
Such a particular combination of software components is extremely popular, in fact it has become known as a LAMP stack – Linux, Apache, MySQL and PHP.
Parts of our WordPress blog tech stack may change, but the end result – a running WordPress blog – will still be achieved. For instance, your OS doesn’t have to be a Linux flavour. And you can pick one of the many web servers capable of running PHP code. You could even pick a different database type but officially WordPress supports only MySQL.
Depending on how specific your infrastructure requirements are, a relatively simple tech stack of your WordPress blog can be greatly expanded to allow for extra flexibility and performance as needed.
Static content is easier to serve as it requires less compute power. It should therefore be possible to configure an extra layer of static content caching and proxying just in front of your PHP-enabled webserver. This layer will be another type of a webserver. Static content will be served by this lightweight webserver with minimal delay while PHP code will be proxied further to the Apache/PHP level.
Load Balancing may be used to direct incoming traffic to multiple servers. The idea is that instead of a single web server your visitors will hit one of the many web server nodes, each of which will be relatively idle so requests will get served quicker.
Such a relatively simple idea will require a significant rework of your original technology stack though, because you must scale multiple components at once. In order to build multiple load-balanced websevers, you must move your database onto a separate server. Each webserver will be connecting to that server, so very quickly you will probably need to horizontally scale the database layer and have multiple MySQL servers instead of just one.
Once web and DB layers are scaled up, you may want to put your PHP code processing onto separate servers altogether. So instead of having PHP as a built-in module in your webservers, you will have a number of application servers, ideally load balanced as well.
Documentation is rarely the most popular activity in most IT teams. Still, many IT professionals will gladly make an effort to capture vital elements of information if they see the benefits. A technology stack diagram is one of such benefits.
Knowing your technology stack and having it fully documented cab be useful in more than one way: