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.
Frontend
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.
Website
A website is built using HTML, CSS, and Javascript. Unlike most other components in the stack, there aren’t really a lot of choices here. HTML is absolutely required, and most websites with any sort of sophistication will use CSS and Javascript as well. The reason there aren’t other options is because users access websites through web browsers, and this trifecta of technologies is what Chrome, Safari, Internet Explorer, etc. all know how to display. The web has a storied past of other technologies that run in web browsers (Flash, Shockwave, Silverlight), but only HTML, CSS, Javascript were ubiquitous across all major browsers, so those were the ones that stuck.
Over time, frontend libraries were developed to ease development and to deal with differences across browsers. This is where your engineers start having choices. jQuery is as popular javascript library that makes development more standardized and easy to use. Bootstrap is a CSS and Javascript library that primarily deals with layout, and is especially useful for creating responsive websites (sites that adapt gracefully to small or large screens).
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.
Mobile Application
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.
Much to the consternation of engineers and resource managers, the two major mobile operating systems have completely different development environments. Native iPhone apps use Apple’s Objective C or Swift as their programming language, whereas native Android apps use Java. Unlike modern web browsers, which can all display pretty much any website because they all eventually agreed on HTML/CSS/Javascript, native iPhone and Android apps are not compatible at all and have to be developed separately from scratch. If Apple and Google could just get along, you’d need half the mobile engineers you have today to accomplish the same amount of work.
There have been a few attempts to bridge this wide chasm. PhoneGap and its siblings Cordova and Ionic were the first. These are web applications – using good ‘ol HTMl/CSS/Javascript – wrapped in an mobile app. While this accomplished the goal of creating one app that worked on iOS and Android, and sometimes even the web, it had limitations primarily in the form of performance. PhoneGap apps are noticeably slower than native apps written in Java or Objective C. This might be ok for prototypes or very simple apps, but not a great basis for your company’s core product.
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.
Backend
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.
Backend Application
This is where your backend engineers spend most of their time. A backend application is code running on one of your servers that talks to your website or app. When someone goes to http://www.yourawesomeapp.com, the user’s browser asks your backend to send it the HTML, CSS, and Javascript frontend code that it will run on the user’s device. Sometimes the backend just sends HTML, CSS, and Javascript files that are saved on its hard drive and that’s that. It gets more interesting when the backend generates custom HTML/CSS/Javascript on the fly. For example when going to www.facebook.com, there’s no HTML file on Facebook’s servers that contains your latest news feed. Instead, their backend code generates the feed on the fly, and returns some combination of HTML, CSS, and Javascript that produces the unique news feed that you see in your browser.
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.
Since backend code only has to run in one place – your server – backend engineers have a lot more options than frontend engineers about programming language and framework. They don’t have to worry about the code running correctly in Chrome, Internet Explorer, and mobile Safari; it just has to run on the servers that they themselves set up. Some popular languages and frameworks are Python/Django, Ruby/Rails, Javascript/Node.js, Java (no relation to Javascript), and PHP. Which one (or ones) your engineers pick the day they start coding your app defines everything about the future of your engineering team, their day to day workload, which tools and resources they have access to, and who you might hire in the future. Switching programming languages essentially means starting over.
Database
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.
Cache
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.
CDN
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.
Most websites and apps include a lot of images. These images are typically orders of magnitude larger than the HTML/CSS/Javascript files the backend sends, so they would consume a lot of resources to send to clients. Your backend server can certainly do it, but it’s not the most efficient way and consumes unnecessary resources. It’s like bringing a gun to a knife fight. Using a CDN is easy, fast, and cheap. The images will load faster on average because CDNs are geographically distributed around the world, so chances are there’s one physically close to the end user. Popular CDNs include Amazon CloudFront (which integrates with Amazon’s S3), Cloudflare, and Akamai.
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.
WTF Is My Engineer Talking About 
Thanks Adam! Super helpful breakdown. I’m a data scientist with a background in statistics (more so than CS) so this was really enlightening to read 🙂
Also, your picture of the grandma and the computer is absolutely priceless. If you haven’t already, you’ve gotta purchase the rights to that — it fits your brand perfectly! Cheers, AJ
LikeLike
Glad you like the article and the picture!
LikeLike
This is an amazing article. Gives us so much information. Thanks for your amazing work 🙂
LikeLike
Glad it was helpful!
LikeLiked by 1 person
I’m so glad that I came across your blog!!! Amazingly helpful for this non-tech person 🙂 And thank you for being so inclusive and thoughtful by using the “she” pronoun when referring to an engineer – I loved that touch.
LikeLike
Glad it was helpful!
LikeLike