Nearly every business function now has a ‘stack,’ a group of tools used to achieve that function. It’s true for productivity, communication, marketing, development and more. But what makes this group of tools a ‘stack,’ and how should you understand, plan, and optimize yours?
In this post, we’ll use development stacks as an example and discuss how a stack gets built, what can go wrong, and what to do about it.
Let’s start with the 101: when we say ‘tech stack,’ what do we actually mean?
Tech stack 101: what are we talking about?
A tech stack is the total of the technological solutions your company uses to do what it does. For example, there’s a well-known and commonly-used back end website development tech stack, LAMP. That’s an acronym referring to four tools, each with its own place in the website development flow:
At each stage, one of these tools could be swapped out for another. And this isn’t the whole web development stack. There’s front end development to account for too.
But they are stages. First, you build your server architecture. Without it, you can’t do much. But with it by itself, you still can’t do a lot. So you also need to build a database, an application layer, and server software; at each step you need a new tool.
There’s another way to approach this same problem, software development, with a different stack: MEAN.
MEAN has similarities with LAMP: there’s still an application layer on the client side, still a database, and still a front end development language and an underlying substrate to run it all on. But while LAMP lets you manage large structured databases with a high degree of robustness and versatility, MEAN lets you rely on flexibility and an OS-agnostic JavaScript runtime environment instead. They have components with similar functions but they are not the same. The question ‘which is better’ is like asking who makes the best vehicles, John Deere or Ferrari. It depends what you want to achieve.
In MEAN, you can replace AngularJS with other popular front end tools like Vue or React. (Then you’d have MERN or MEVN, recognized stacks in their own right.) Why would you do that? To match functionality between components and whole stacks, and the goals you want to achieve — both now, and in the future.
Other popular software development stacks include:
- RoR (Ruby on Rails)
- Serverless (for development on Infrastructure-as-a-Service substrates like Azure or Amazon Web Services)
- Meteor.js (for accelerated cross-platform JavaScript development)
- Flutter (open-source software development program used to develop OS-agnostic cross-platform applications from a single codebase)
Here’s where we get into contested territory: all these tools, environments and groups of tools do something similar to LAMP and MEAN: they let you develop applications for the web. But are they truly ‘stacks’? Some developers think so, others argue that a tool like Ruby-on-Rails and Flutter is an application framework, not a stack as such. Across tech it’s common to find tools that can replace or replicate multiple stack elements, or let you achieve a similar outcome in a totally different way.
And these are just the most popular stacks, in an area where stacks are relatively simple and with relatively clear-cut roles. Consider the massive proliferation of business intelligence or marketing technology tools and the complex, multilayered stacks that are common in those spaces!
Why is it a stack?
It’s a stack because each additional service or tool builds on the work and results of the one below it.
Imagine building a house. You have to lay foundations, because without them there’s nothing to build on. But you can’t live in foundations. You need walls and a roof. So you need a backhoe, but you also need a mortaring trowel and a saw. You need a stack of tools and skills, where each new specialism builds — in this case, literally — on the work already done by previous layers. We’ve used web development as an example, but actually any kind of project requires a stack of technologies to achieve its aims. It’s especially true of projects that involve IT or software.
Understanding how tech stacks work
So far, we’ve used a fairy simplistic analogy to understand how modern tech stacks work. That was good enough to get us here, but it’s time to drop it, look under the hood and get to grips with how a modern tech stack actually works. This is an example of a software development stack but the stacks used by IoT, martech, and other companies work in similar ways.
With SaaS ubiquitous and everything connected to everything, everywhere, it’s safe to assume a front end and a connection, with the majority of heavy-duty computation and data storage happening on the server side.
On the front end there’s an app or website, which has to remain functional across a range of device screens, sizes and operating systems. For instance, if it’s a web app, it needs to work in Chrome on a Chromebook, but also on Edge on a Windows desktop. If it’s a mobile app it needs to work on Android and iOS, at least, and this usually means building an app for each platform and having them connect to a single application layer and database setup. Thus, front end considerations have implications for back end decisions and vice versa.
Operating systems and application layers
When a user clicks something on the site or selects something on the app, that input goes through to the back end to be processed. Here, where the end user never sees, all the data and the majority of application code lives. (Some apps and websites use an unusual amount of client-side code, for various reasons including speed; the vast majority pipe requests back to the server, handle the computing and data management at the server, then pipe the answer back to the user in their browser or app.
Thus, it’s on the server side that you’ll find complex operating systems, split between Windows and Linux and with the remainder mostly Unix. You’ll also find the majority of the application layer here, usually built using OS-agnostic multipurpose programming languages like Java and PHP. In the case of mobile apps, this application layer may be built using multipurpose languages like Java, or it may be written in OS-specific languages like Swift (iOS) or Kotlin (Android).
Servers and load balancing
Then, there’s servers and load balancing, Content Distribution Networks (CDNs), routing and caching services — everything to let applications send and receive requests, make optimal use of resources, run smoothly and scale stably. Some businesses build their own; others buy them from major suppliers like Google or Amazon as a service. Both approaches have benefits to recommend them. If you buy them, you don’t have to fix them, but if you make them, you can tailor them to your requirements and you own them. Popular solutions here include AWS, Google Cloud, Azure, Apache, Nginx, CloudFlare, and Fastly.
Data infrastructure
Data storage and querying includes data storage and management, which can be done using relational and non-relational databases and data warehouses. These components are crucial for storing and accessing the data that your application delivers to end users, whether that’s stock for an ecommerce site, or information on leads for a business intelligence solution. As your app is used, you can also develop databases of user data that can be used to improve your product, optimize your marketing and grow your business. Common tools include MySQL, Azure Synapse Analytics, MongoDB, Redshift, PostgresSQL, Snowflake and Talend.
In addition, there’s a parallel stack of business intelligence, monitoring, and performance tools, augmented by APIs that let you plug your product into other companies’ stacks and their products into yours.
Building, optimizing and maintaining a tech stack
Tech stacks should be selected based on business need, then built backwards from there — in a similar way that if you’re planning a road trip you ‘start’ with the destination, then plan a route with rest stops, meal breaks and alternate routes in case something goes wrong. Let’s talk about some important considerations that are less directly technical.
Updates
When any part of your stack is updated, it can cause a cascade of required updates all across the tech you use. If it causes a mission-critical stack component to become incompatible with APIs or other stack elements it can break your stack — and hence your business. Be prepared by structuring your stack with this in mind, seeking to both reduce the number of elements where possible, and the potential for unexpected updates that are out of your control.
Stack overload
In many industries, the options proliferate — the number of martech tools on the market quadrupled between 2015 and 2020 — and the tendency is to adopt an increasing number of tools whose functions somewhat overlap. Businesses should look for opportunities to reduce the number of tools they use and make each one earn its place. In particular they should seek to prevent ‘ghostware’ — subscription tools that remain connected to their system though nobody now uses them — and multiplication of similar tools, such as for project management or communication.
Sources of truth
When you need to check something, where do you look? The ultimate repository of accurate information to which everything else refers is often referred to as a ‘source of truth,’ and received wisdom indicates that a single source of truth is a good thing; however, even extremely reliable and prestigious tools can sometimes break, so a single source of truth can be a single point of failure too. Risk assessment and stack design can mitigate this to some extent.
Custom elements
You can buy a lot of functionality off the peg now. But SaaS costs can quickly mount, especially with a large number of seats or when your mission-critical features are part of the Premium package. Many businesses find themselves stacking multiple tools that substantially do the same thing, for access to one specific feature of each. A better solution can be to have these critical functions built to your specifications rather than paying over the odds for redundancy or off-labeling off-the-peg tools.
What stacks do we use?
Early on in this post, we introduced some common stacks for development work — LAMP, MEAN, and so on. However, we rarely use these at AndPlus. We typically use MERN rather than MEAN — that’s:
This is essentially the same stack as MEAN, but replaces Angular JS with React JS. At first glance, that looks like a swap of very similar components — why bother? Who cares? In fact, it makes several significant differences. React lets us re-use components, which cuts down on development time considerably, and it lets us do isolated debugging so we can develop more stable applications quicker.
More importantly, a view of a stack laid out this way doesn’t tell you everything you need to know. Stacks are more than the sum of their parts. Using MERN lets us develop ended-to-end in JSON and Java, cover the front and back end in a single coding script, and do real-time testing with tools that are built into the stack. You can’t do that with MEAN, so even though it’s a catchier acronym, it’s not as good for what we want: stable, rapid, transparent application development.
When we don’t use MERN we usually use .NET or Java stacks. Our .NET stacks look like this:
For Java we use:
These stacks are carefully selected tool by tool to give our clients systems that get to market quickly and work effectively once there.
Which Tech Stack is the Best?
This is the question that many are dying to know. And as you've probably guessed, the answer to this question comes down to developer preference, technology familiarity, and software / application requirements. One of the best ways to choose a stack is to have a discussion with your team on what they prefer to use, what possible limitations certain stacks may have, and really do your due diligence and uncover all the details associated with each technology up for consideration. You can also ask AndPlus for help with this decision.
How AndPlus can help
We help businesses design stacks for the business they’re going to have in five years or ten years, not the business they had yesterday. We can help you select appropriate solutions that match your business needs, ‘play well’ with one another, and give you access to the right markets or third-party systems. Equally important, we can advise you on what not to buy. If custom development is indicated, AndPlus has over a decade of multiplatform development experience, building front and back end tools for apps, IoT businesses, financial tools and many more.
Takeaways
- A stack is a group of tools that you use to deliver your service. It’s a ‘stack’ because each layer depends on the one beneath it.
- Almost every business now has several stacks for different functionality and the concept is so useful its applied to nearly everything — ‘productivity stack,’ ‘marketing stack,’ ‘sales stack,’ and more. (We use a development stack).
- Stack design and selection is critical to business success, but many businesses lack the in-house skills to do this effectively.
