Let’s start at the very beginning with a primer on tech stacks. I’m going to have to take some real liberties here since this is such a broad topic and it varies widely depending on many factors, but it’s a good foundation for my future posts. I’m going to limit the scope of this post to a basic website or mobile app, since that’s what most software entrepreneurs are building these days and it’s what I’m familiar with.
So WTF is a tech stack? A tech stack is simply a description of the technologies that your company uses. A business plan might be a good non-technical analogy: a description of the core of what you do that you can condense into an elevator pitch if needed, but you could rattle off details for hours to anyone who will listen. Your engineer may have given you a list of buzzwords to tell new recruits or tech-savvy investors – eg. “We use a LAMP stack with a Redis caching layer on AWS” – but do you know what they mean? The options are limitless so I can’t describe every technology your company may be using, but I hope to give you a framework for how they fit together. You can then ask your engineer which specific technologies they use, and, if you have a few spare hours to kill, why she chose them.
Why the F do I care?
It should be helpful for anyone who communicates with engineers to have a 10,000 foot view understanding of the tech stack they are using. You’ll need to know this when recruiting engineers, talking to tech-savvy investors, and securing vendors. It will help you communicate intelligently about resourcing, so that when your engineer says you need to hire a front-end engineer, you’ll better understand why your lazy engineer can’t just do everything himself. Finally, it will help you understand the strengths, weaknesses, and limitations of your system, so that when your engineer says you they need to invest in infrastructure, you’ll better understand how to prioritize it against new feature development.
A Basic Tech Stack
Here’s a basic web stack, along with the reason that I’m an engineer and not a designer. There are infinite combinations and ways the components could interact, but I hope this will give you a good overview. In each component, the category is listed in bold and some example technologies are listed below in parentheses. I’ll try to be as unopinionated as possible and just describe the components and list some of the popular options. Apologies to the engineers who ignored my warning not to read my blog if your preferred technology is missing.
Let’s walk through this diagram from the top.
This is probably what you think about most when you think about your product. Everything that your users see is presented in the front end; typically either as a website or a mobile app. Frontend code runs on your users’ devices – their MacBook Pro, their Android phone, their Apple Watch, etc. The look and feel of your application is entirely encapsulated in this layer. Both mobile applications and websites are part of the frontend, although the term “frontend engineer” typically excludes mobile development since it requires a different skill set.
More recently, full fledged frameworks were developed that make building more sophisticated websites even easier. The most popular two right now are AngularJS, developed by Google, and React, developed by Facebook (yes, the tech giants compete even at this level). They are very different frameworks, so even though either may make use of jQuery or Bootstrap for some purposes, your frontend engineer will likely pick either Angular or React, not both, for a single website.
A mobile app is what your user downloads from an App Store. If you’re using a mobile browser, that’s a website, and it uses the technologies from the previous section.
The newcomer on the scene is React Native. Like PhoneGap, React Native allows you to develop one application that works on both Android and iOS. It is faster than PhoneGap, arguably almost as fast as native apps. React Native is the sister of the web framework ReactJS. React JS and React Native are not compatible – you have to develop a website separately – but the concepts are nearly identical similar, so it makes it much more feasible for the same developers to work on both. React Native is fairly new, released by Facebook in 2015, so the verdict is not in yet. Some people think it is the holy grail we’ve all been waiting for, whereas others think it is just another PhoneGap.
Websites and mobile applications run on the user’s device or web browser. For some simple applications, that’s all you need. Perhaps a simple calculator, shopping list app, or step counter that never shares information to or from the internet could get away with just a frontend. But as soon as you add user accounts, any social features, data updates that are not all included in the application that is downloaded once from the App Store, or analytics, you’re going to need some kind of backend.
A backend runs on your company’s servers, either in your own datacenter (computers you own or rent) or in a cloud provider like Amazon Web Services (AWS). The vast majority of startups choose the latter because there is zero up-front investment and you can scale up and down your server resources as your business changes. You can even scale up and down during the day, so that you have more servers running during the day than at night, to save costs. Using AWS or an another cloud provider like Heroku, Microsoft Azure, or Google Cloud, has become a no brainer for startups and even larger companies.
So a backend is just a bunch of computers somewhere that runs some code. Unlike frontend, all the code that backend engineers write runs on a shared set of servers. As your app’s usage grows, users start demanding more and more resources from these shared resources, so scaling efficiently is a big part of what backend engineers spend their time thinking about.
A mobile app works similarly, except it doesn’t need to start fresh each time the user opens it. When you open a new website, your browser doesn’t know anything about your application, so it’s all sent from the backend as soon as you load the webpage. An app already has some information – the code you downloaded from the app store – so the app can open immediately. But usually, it needs some information from your backend whenever you open the app – your account information, the local weather right now, the number of likes you got on that witty post of yours from last Thursday. It requests this information from an API (Application Programming Interface, but nobody says it like that), which is just the interface between your backend and your frontend. Your app requests information from the API, and the API returns information back to the app. The app may also post information to the API (a new tweet, a new favorite, new account information, etc.) for storage on your server.
A database stores information. Your backend application, for the most part, does not store any information; if your backend code went all Samsung on you and exploded, it would not be the end of the world – you’d just start some new servers running the same code. If your database exploded, then at best your site/app is down, and at worst, you’ve lost all of your company’s data – user accounts, payment transactions, any content produced by your users or your staff. So they’re kind of important.
Databases are Very Complex. They do a lot of things: they need to store lots of information, read and store data very quickly, scale to thousands, millions, or billions of transactions per second, never go down (“turn it off then on again” will mean, at best, your site/app is down for a few minutes or hours) and never once lose or corrupt any data. If any of that doesn’t go perfectly every second of every day, your company may very well be over.
Unless you work for a Google or an Amazon, your engineers didn’t create your database, they chose one that already existed and that has hopefully spent many years being battle tested by much more high volume use cases than your small startup. Choosing a database is another Big Decision that has huge implications on your business and is hard to change later. Popular databases include MySQL, Postgres, MongoDB, and Cassandra, and Oracle.
Databases are so complicated and so important that a whole professional field exists to maintain them: Database Administrators (DBA). At a small startup that doesn’t have the resources for a full time DBA, this function may be performed by a DevOps / Infrastructure / Systems Engineer or a backend engineer. They all certainly work closely together, but require different skill sets. You’re going to want someone who is an expert in the database your team has chosen as soon as you start getting any sort of traction.
Because a database is so important and a lot of demands are placed on it, most tech stacks quickly incorporate a cache, which is responsible for alleviating stress from the database and providing faster access to key data. A subset of the information that is stored on the database – typically, the most frequently accessed information – is copied to yuour cache so that the backend application doesn’t need to query the database as much. Your database may have terrabytes of information (that’s a lot), but 95% of the data that the application needs is restricted to 5% of the data.
For example, Facebook has years of data about all of us, but to render your newsfeed, it usually only needs to look at the data from the last few days. So Facebook might save certain posts from the last few days in a cache. If a user wants to see an old post that’s not in the cache, nbd, it’ll fall back to the database. But if it can find 19 of 20 of the posts in the cache and only has to query the database once, that’s a huge win: 95% fewer queries to your most precious resource. (I’ve never worked at Facebook and I’m sure this is an extreme oversimplification, but hopefully you get the idea.) Common cache technologies include Redis and Memcached.
A content delivery network (CDN) is another optional but common component of a tech stack that is responsible for storing images and other static assets. Much like a data cache protects a database, a CDN is a cache that protects the backend application.
Whew! That was a lot!
I know, sorry. Future blog posts will be shorter, but I wanted to provide broad overview first. Shoot me an email or comment if anything was unclear!
Hope you found this post useful! Don’t forget to follow this blog using the link on the left, Facebook, Twitter, or LinkedIn. And please send feedback and topic suggestions via e-mail.