Table of Contents
What about scaling and resiliency? To scale, you’ll need to make a lot of choices along the way that will impact what you can support. Your tech stack, the services you use, the type of teams that you employ, will all be significant inputs into how well you can scale. Next, you’ll need to develop a performance testing and management plan. Think you’re going to set it to “auto scale” and forget it? It’s surely possible, but are you scaling the right tiers in your application? Are you scaling for performance for the customer, or performance of your operational costs? Are they same thing in your architecture or are they different?
Concerned about resiliency? Do you want to do chaos engineering and testing to see if your application can survive various service outages? Before you even engage with a chaos toolkit, you should have an idea about what you’re going to do and what the system looks like. Stackitecture can give you that overall map of the system that will enable you to think about the possible weaknesses and failures that you may incur.
Are you building the entire app by yourself or with one internal team? Are you integrating with external teams? Do you have you have service level availability (SLA) or service level objectives (SLO) that you want to support or need to support from a contractual perspective? Do you need to bring in an external team (in your company or from an consulting group)? Again, if you’re bringing in external folks to add capacity to your development effort, you’re increasing your burn rate and the quicker their able to accomplish their mission, the better for you and your firm. Having an architectural picture built in Stackitecture enables faster onboarding, which means less money spent for onboarding.
To get there you have to know where you’re going.
For a cloud deployment of a container architecture, creating a diagram in Stackitecture is even more useful. While the Kubernetes community has some standard patterns, there’s a variety of ways that they can be implemented both with a on premise, a cloud native, and a hybrid cloud architecture. As you tie your cloud architecture into a hybrid architecture, with existing data centers that are hard to move, a cloud architecture diagram will save even more time reducing miscommunication.
Serverless architectures tend to have even more components than a “standard” serverful architecture. It’s typical to see each individual function represented with corresponding API, queue, or datastore integrations. Those diagrams can quickly explode to have dozens of function and integration interactions, and while each is simple to understand, the total picture is easier to understand with an overall architecture diagram, built in Stackitecture.
Every development team runs on hiring the best talent, and once you have those folks hired, you’ll want them to be as effective as possible in the least amount of time. Onboarding new developers with a map of the system is more effective than a whiteboard session (in the best case) or nothing (the more typical case). The amount of money you can save on onboarding alone can make Stackitecture an extremely cost effective purchase for your development team.
For some industries, external teams will need to be contacted for their input. For example, a Security team might be involved to determine vulnerability, encryption, and privacy concerns. It may be necessary to show them that the logs are access controlled and least privilege is setup such that not everyone can access production data.
In the healthcare space, an audit may need to be done to make sure that the services that are being used are covered under a Business Associates Agreement (BAA) and that the architecture supports HIPAA regulations.
From an operation perspective, the system that is being built will need logging, monitoring, alerting, and observability integrations and diagnostics to enable real-time monitoring for site relativity teams and production support.
For marketing, it is important to callout integrations with external services that might be used for customer engagement and analytics.
For data science, it’s important to know how the system is setup and how data flows through the system, possibly into a data lake, so that analytics can be setup so that application measurement and customer analytics can be done.
For customer engagement and success teams, it’s important to have a high level view of the system so that they can talk about it with their customers and be high value liason between the customers and the development teams.
For testers, it’s important to have an overall view of the system to understand what’s being tested, what needs to be tested, and what a test environment setup whould be to replicate the system.
For diasaster recovery, it’s easier to setup either a cold standby, a pilot light system (warm standby), or an active-active system to minimize the amount of downtime an application may have during an outage.
For incident management, an overall view of the system will help the incident response teams as they “fight” the incident and work to get the system back online as fast as possible, reducing the mean-time-to-rcover (MTRR).
All of the above is relatively table stakes for a small to medium size software development team in this day and age. The era of startups just throwing up a site and hoping it stays up is less acceptable with the ready and easily available amount of tooling and services that Amazon Web Services provides. Think that your analytics or legal team doesn’t need to know the system architecture? Do you operate in Europe and need to accommodate GDPR regulations? Do you think it’s going to be easier to explain to your lawyer with a map of the system or do you think they’ll be able to follow along on the whiteboard?