How do you navigate creating an app as an entrepreneur with little experience in tech? Regardless of your software experience, here are five basic knowledge areas to light your path through the tech world.
What is “Software Architecture?”
The term “software architecture” refers to the structure of systems and how they relate to, or work with, each other. Try thinking about apps like cars. In a car, you have several different parts like the engine, fueling system, and electrical system each performing a specific function that helps the car run as a whole.
Every app has a few basic parts: a front-end, a back-end, and a database. In the software world, we don’t call them parts; instead we call them components.
Software Architecture Layers
Front-end components are what the users are going to see, touch, and experience. What you see on phones, for example, is the front-end code for the visual interface that you and others interact with. This does not apply strictly to apps, you can also have a web front-end to be used on a web browser, where they load from a server and run in your browser on your computer.
Back-end components include all the services that run on a server somewhere else, out of sight, and out of mind from the users. For apps to do what they do and function the way you want them to, it relies on the logic and code of the back-end layer. It is not something that you are able to see or touch, but it is code that runs on a server in a data center.
The database layer is where the actual data from the app is stored. This may include personal data, payment card data, social media post history, transaction data, any sort of data that is saved, or “put in the cloud,” actually lives in a database. The back-end services read and write to and from the database.
Monolith vs. Microservices
Your back-end is basically a bunch of code that runs on a server somewhere in a data center. At the risk of oversimplifying, your back-end code can be built in one of two ways: You can have a monolithic architecture or a microservice architecture. Monolithic means that all your back-end code is in one big code base. If you update one thing, if you make a single change, you update the whole chunk of code. That usually means you also have to retest all of it every time you make a change. It can also be harder to migrate or move to a new server. It also means that if the server goes down, none of your apps works. There are still reasons to have a monolithic back-end. It’s less expensive, so it can be a good choice for building a low-cost MVP or proof of concept.
Microservice architecture means taking the same back-end functions and breaking them down into smaller code bases. You can update the code for a single back-end function without touching the code for all the others. This type of architecture is typically more complicated and expensive, but it isolates the services from each other, so if one goes down, the rest still stay up and running. That could mean that your users might see one part of your app stop working, but the rest of your app is fine.
There’s also a concept called “serverless architecture.” In the monolithic and microservices scenarios, the server is always on, running in the data center. Typically, you pay for all the time the server runs. The problem is that if you load the server to capacity, you have to expand and pay for more servers. Then your load decreases, you’re not using all your server capacity, but you’re still paying for them because they’re still running.
In serverless architecture, you’re not paying for the server to run all the time. When a user’s front-end calls your back-end, it spins up a server, runs the command, and then shuts it back down again. You don’t pay for a server to keep running. You just pay for the computing power to run that command. It’s a way of keeping your variable costs more tightly aligned with your actual usage.
Integrating the Front and Back-ends
Going back to the car analogy, if the back-end is like an engine, then the front-end would be like a steering wheel with the dashboard and gear shifter. They are working together to help the user accomplish a purpose, to get something done. When you open up a social media profile on your phone, you don’t save it on your actual device. A small portion of it may be “cached” or stored temporarily, but all the different elements work together to serve up the content you want you see. The front-end requests the profile from the back-end. The back-end retrieves it from the database, and serves it back up to the front-end. Then you see and interact with it.
To get to this point where all the layers are working together, you’ll need to go through a process called “integration.” During integration, the mechanics of the front-end are then connected to the back-end. Side note: “Integration” can also refer to the connection between two different back-end systems, for example, integrating your shopping cart with Stripe payment processing. It can be a little confusing, but know that integration is all about bringing two systems to work together as smoothly as possible.
Development vs. Operations/Infrastructure
Now as we look at the code, it needs to live somewhere so it can run property and perform its functions. The front-end code lives on your phone and uses your phone’s resources, like memory and storage. But what about the back-end? The back-end runs on a server. In some cases it may be a real, “bare metal” server (in other words, a server computer that sits in a datacenter somewhere connected to the internet). It could also be on a “virtual machine” where an actual “bare metal” server is running something almost like a simulator to pretend like it’s a separate “virtual machine” running on it. The same thing goes for databases. They can run on real servers or virtual ones. In any case, they use up computing power, memory, and storage somewhere.
The hardware used to run these elements of your architecture is called “infrastructure.” Once the code is developed, it is deployed to a server where it runs. The code is developed by a developer, and is traditionally operated and monitored by a system administrator. Note the distinction between development, the process of writing code, and operations, the process of running code. While the code and software is operating on the server, it is called “uptime,” and that’s good. The goal is to be as close to 100% uptime as possible. When the system goes down it’s called “downtime,” and that’s not good. It refers to a disruption of your service when a product has an outage. If you have an outage, your users can’t access your back-end systems and the front-end systems will only show them an error (which frustrates the users).
DevOps and Continuous Delivery
In recent years, the concepts of development and operations have merged together into something called “DevOps.” What this means is that you no longer have a developer throw code over the wall at a bewildered system administrator and say, “Here. Run this.” Instead, the developers themselves not only write code, but also add to it automated deployment and configuration scripts, including automated test cases. The developers can check on their own whether the code will run on the server correctly.
This empowers the team to deploy smaller, more frequent updates without waiting for a release. This is possible because the deployments and tests are automated and go through multiple rounds of deployment and testing, called a “pipeline.” The practice of deploying code bundled with automated scripts and tests and ultimately releasing smaller updates to users more frequently is called “continuous delivery.”
It is possible to build an MVP without using continuous delivery. We have done it a lot in the past. But it means that every time you release it, you’ll basically have to retest everything by hand. All of it. Again. You make changes to your app, you break something, you have to retest… over time it gets expensive. To save you from the pain and headache, you might as well implement continuous delivery from the beginning. Otherwise, you won’t be able to release updates as easily and your new features will be held hostage by manual processes.
SQL database vs noSQL database
Looking at databases, there are two main types. There are relational databases and non-relational databases. A relational database has tables with rows and columns. MySQL is a good example of a relational database. An SQL database requires that every row has a value for every column. It looks like this:
| Record ID | First Name | Last Name | Phone Number |
| 001 | Jane | Doe | 801-555-1234 |
| 002 | Adam | Smith | 246-801-3579 |
Non-relational or noSQL databases are structured not as tables, but as documents. MongoDB is a good example of a noSQL database. NoSQL databases can offer more flexibility in describing stuff without requiring that every row has a value for every column. It looks like this:
<document>
<recordID=”29548”>
<firstName>Jane</firstName>
<lastName>Doe</lastName>
<phoneNumber>801-555-1234</phoneNumber>
<favoriteDessert>Strawberry Cheesecake</favoriteDessert>
</document>
<document>
<recordID=”29549”>
<firstName>Adam</firstName>
<lastName>Smith</lastName>
<phoneNumber>246-801-3579</phoneNumber>
<favoriteMovie>Mission Impossible</favoriteMovie>
<favoriteCity>London</favoriteCity>
</document>
See how in the SQL example, all the fields are the same: record ID, first name, last name, phone number. But in the noSQL example, there’s a line that describes Jane’s favorite dessert and Adam’s favorite movie and city. The different lines don’t have to be the same from record to record, making it more flexible. It lets us store a wider variety of information without making the database huge.
There are many moving pieces when it comes to developing an app, and it can be overwhelming and confusing when you start to learn about it. But as we start exploring the world of technology and app development, things begin to change and become more clear, or at the very least, less mystic than it was before. Hopefully now you are ready to begin your journey into software development, and so go and “Build your app. Change the world.”
If you’d like to learn more about software development, check out these two articles, App Development: How Much Does it Cost? and The Entrepreneur’s Guide to Software Testing.
0 Comments