Architecting a Multi-Tiered Stack
Create a simple architecture of your stack
This is a great time to sketch out your stack in a diagram. You'll be looking at the high-level interactions between components, and how each piece of your stack will interact with other parts of the system. Think about what needs to be shared across all layers, and what needs to be separated.
A good way to do this is by creating an architecture diagram using a tool like Lucidchart or Visio.
Analyze your needs and access to resources
When you're architecting a multi-tiered stack, it's important to understand the needs of your application. The first step is to ask yourself: what do I need from this system? What does it need to do for me? Next, consider where the system will live. What systems will be used in order to build the product? If your team already has access to these tools and services, great! If not, how would you acquire them (and what costs will there be)?
Finally, think about how parts of your application might need access to resources that are currently shared among multiple people or applications. For example, if several developers on different teams all use one remote server as their primary database host but they don't want everyone else messing with each other's data at once, should they consider setting up some type of authentication system like LDAP so only users within a given group can write/read from the same database server?
Sketch out how each piece of your stack will interact
You should begin by sketching out your application stack, starting with the most outermost layer and working inwards. For example:
Cloud provider (Google App Engine, AWS, etc.)
Hosting provider (Heroku, Digital Ocean)
Database (Postgres or MongoDB)
Application layer (web app framework like Django CMS or CMS-less like Jekyll)
Middleware like authentication systems and caching layers
Decide what needs to be shared across all layers.
Now that you know what you have, the next step is to decide what needs to be shared across all layers. This is a good time to think about how your application will scale out and up in terms of hardware capabilities, as well as its capacity for more users. With this information in mind, look at any shared resources like databases or files that might not need to be replicated across all layers. If these resources are needed by multiple applications or tiers—for example, an accounting system may require access from both mobile and web apps—they should be placed on a separate instance from other applications on each tier. This way if one instance goes down, another can take over and keep running smoothly without affecting the performance of other services that depend on it (like billing).
What needs to be separated.
The first step in architecting a multi-tiered stack is to identify what needs to be separated. Identifying the right boundaries will help you avoid future scaling issues and increase your ability to maintain the system.
For example, if you want to separate functionality that requires different security and access control, then it makes sense to isolate those components from each other using firewalls or network layers. If you want to separate functionality that requires different deployment strategies (e.g., deployments at a large scale), then it may make sense for these components to run on different physical machines or clusters of machines with their own networks so they can be scaled independently of one another as they grow in popularity or size.
In general, when designing distributed systems we look at three main concerns: performance, reliability/availability (also known as high availability or HA), and elasticity—the ability of an application or service provider's resources (hardware) being used efficiently while remaining responsive under high loads at all times despite any failures occurring within its infrastructure."
Make sure your app can scale up and out at a moment's notice.
The ability to scale up and out means being able to scale your application in two dimensions, horizontally by adding more servers (scale in) and vertically by increasing the number of resources on each server (scale out).
The ability to also scale down is a good thing because it allows you to reduce costs if necessary, but it's often difficult to do so when you're under stress because scaling down can cause instability or performance degradation in your application.
Using automation to create your Stack
The benefits of automation throughout the whole application lifecycle's components from build to security can be proved from the many pages of this blog. In an effort to DevOps this all and stop repeatedly writing the same code again and again I have been working on a few projects to create reusable code:
Network Layer
Using Terraform we can create reusable chunks of code to abstract certain parts of our network build, one such example with AWS Network elements can be found here, which is a group of Network Resources that can be chopped and changed from very little variables, with sane defaults to use in it's most popular form, the 3X3, Network and AZ formation.
Application Layers
On top of the above I wrote another module that breaks out in to other modules to handle the essence of most configurations, continually adding more and more as time goes on. The benefit of this is that from a tiny module I create on the fly, I can call this module, which calls the Network module and gives me a service catalog of design patterns to instantly spin up from very little code.
Future works!
No one knows what the future holds, in my current role I will be looking to expand these to the other cloud providers and even grow the paradigms, there is so much to code and only a few hours in the day.
Wrap Up!
A well architected stack can make or break a company!
A good way to think about architecture is that it’s the foundation on which everything else sits. It provides a solid base for scaling and maintaining your system, as well as adding security, monitoring and new features. If you build an un-scalable foundation, then no matter how much money you pour into engineering resources it will eventually fall over under its own weight.
The key here is that each layer of your stack needs to be designed with all of these objectives in mind so that they will scale comfortably for many years into the future without having to be rebuilt from scratch at some point down the line (which often gets expensive).
