Architecture
In short
Architecture is where you decide how your app runs for real people. Answer how bad a day of downtime would be and what sensitive information it holds, and Sapilon suggests one of three options (Essential, Balanced or Dedicated), side by side. Once one is chosen, the page opens on it, with Change architecture to pick another. Choosing is free until the project moves to Rehearsal. After that, a change shows what would change and its steps before anything starts.
Before real people use your app, someone has to decide how it runs for them: one server or two, how quickly it answers after a quiet spell, and where its data lives. The Architecture page is where that decision is made, in terms of what each option means for the app rather than the infrastructure behind it.
Once an architecture is chosen, the page opens on it: its name, each of its details with a line on what it means, whether an architect has checked it, and the Cloud services it runs on. Change architecture is the one way on from there.
Before you choose, and after pressing Change architecture, the page shows three tabs: Options, the options side by side, where it opens; Customize, your own mix; and Cloud services, how your app would run. While you are changing it, a bar at the top says so, with Keep current architecture to go back without changing anything.
It appears in your project, under How It Works, from the Build stage.
Two questions
You don’t configure anything. You answer two questions at the top of Options, and Sapilon suggests the option that fits your answers:
- If the app were down for a whole day, would that be annoying, costly, or existential?
- Will the app hold any of these? Health or medical information, payments or financial details, information about children.
Sapilon also counts the personal details your app’s data already holds, such as email addresses, so you don’t need to declare those. Once an option is chosen, your answers are read back in one line with Change answers beside them.
Three options, side by side
Under your answers, the three options are laid out side by side, with your choice or the suggested one highlighted:
| Option | In short | Suggested when |
|---|---|---|
| Essential | One server for everything | A day of downtime would be annoying, and nothing sensitive is held |
| Balanced | A Rehearsal Server when you need one | Downtime would be costly, or the app holds personal details |
| Dedicated | Everything of its own | Downtime would be existential, or the app holds health, payment or children’s information |
Each option is compared on the same rows, named as Customize names them: Servers, Rehearsal (whether there is a Rehearsal Server, and when it runs), Rehearsal data (made-up sample data, or a copy of your real data with the private details hidden), Compute (on demand, or always on, which decides how fast the first visit is after a quiet spell), Database, Firewall, and Hosting, where the app and its data live. Each value has a line under it on what it means. With Essential there is no separate Rehearsal Server: the Live Server serves Rehearsal too, and going Live switches it over.
Every option runs on AWS infrastructure that Sapilon sets up and runs for you. With Essential and Balanced, your app and its data live on the Sapilon platform. Dedicated puts them in an AWS dedicated account, kept apart from every other project.
What each option costs
The page doesn’t show prices. What each option costs to run a month is on the hosting prices page, split into the servers your app runs on, its database, and everything else. What your project actually spends is on Spending › Costs, and draws from your wallet as the servers run; see costs and usage.
Options you can’t choose
An option that doesn’t fit your answers stays visible, greyed out, with the reason. The rules behind those reasons are few:
- If a day of downtime would be costly or existential, the app needs a Rehearsal Server before it goes live.
- If it would be existential, Rehearsal and Live must be separate servers.
- Personal information is never rehearsed against a raw copy. Health information must live on a database of its own, and any Rehearsal Server must use a masked copy of the real data.
When part of an option isn’t available yet, the option uses the nearest setup Sapilon can build and says so in a note underneath. If that substitute would break one of the rules, the option says it can’t be set up yet instead.
Customize
Customize lets you mix and match instead of taking an option as it is: one or two servers, when the Rehearsal Server runs, what data it uses, whether the app is always on or starts on demand, and what kind of database it has. Rehearsal data only appears when there is a Rehearsal Server to use it.
The database can be:
- Sapilon managed: your app’s own private database, run and looked after by Sapilon. This is the usual choice, and the cheapest.
- Dedicated instance: a database server of its own, for apps that need one. An app in an AWS dedicated account always uses one, because its data stays inside that account too.
- Serverless: a database that grows with use and idles when it is quiet.
Firewall puts a web application firewall in front of each web app, screening every visit for attacks and bots before it reaches the app. It is on by default in an AWS dedicated account (Dedicated) and off on the Sapilon platform, where the built-in DDoS protection every app gets covers typical traffic. Turning it on or off for a deployed app needs no downtime.
There is one firewall per AWS account, and every web app there with the firewall on goes through it: Live and Rehearsal alike. On the Sapilon platform it is shared with the other projects there, with the same standard rules for all, and your app carries only a small share of its cost. In an AWS dedicated account the firewall is your app’s alone. You pay for it once, whatever number of web apps and servers it protects, and it can be customized for your app: rules added, an allow-list for your own offices or partners, or limits on how often one visitor can call it. Ask for a customized firewall through Get help.
Each change is checked before Apply becomes available, so you see what it means and anything standing in its way first.
The Cloud services tab draws what you are trying out. What you set stays while you look at the other tabs, and the tab reads Changed until you use the details or press Start over.
When your details aren’t one of the three options as they are, Options shows them as a fourth column, Custom, in a colour of its own, compared on the same rows. While you customize, Custom is marked Selected, and the option you have now is marked Current, with Keep to drop your changes and go back to it. Apply makes your details your architecture, and Custom then reads Your choice.
When an architect checks the choice
High stakes in your answers, and departing from what Sapilon suggests, both add to how closely a choice is checked. Past a certain point an architect, one of Sapilon’s experts, reviews it. An option may read This needs an architect’s review before it can be chosen, and the brief at the top of the page shows the review as Needed, meaning an architect reviews the choice before the app goes live. Once the review is done, it reads Checked.
Choosing before and after deployment
Until the project moves to Rehearsal, choosing an option only records it, and you can switch as often as you like. Choosing is one of the steps before moving to Rehearsal, because that move is when these servers are set up.
Once the project is deployed, changing the architecture is a real change to running infrastructure, so it works differently:
- Press Change architecture, then Switch to an option, or Apply your own details. A panel beside the page shows What changes: each detail that would change, from what it is now to what it would be. Under it, What happens lists the steps the change runs, and Show on the diagram draws where it leads. Nothing happens yet.
- Start the change runs those steps, with their progress on the page. Your app keeps running on the current architecture until the switch.
- Your architecture only changes when the last step finishes. If the change stops partway, the page says why and your architecture is unchanged.
Moving a deployed app’s data to a different kind of database is not available yet, so a switch that changes the database is refused before anything starts. Choose the database you want before the move to Rehearsal.
Some switches need nothing moved at all; they apply on the next deploy. A change you made that hasn’t been applied yet is flagged at the top of the page, with Apply it.
Cloud services
The Cloud services tab draws a diagram of how your app runs: the services involved and how requests and data flow between them. It is generated from your choice and your project’s apps, never drawn by hand, so it changes when either does. This is the one place the page uses the real AWS names; select a service to read in one sentence what it does, and scroll or pinch to zoom.
It draws the architecture named in the brief: your choice, or, before you have chosen, the option Sapilon recommends. While you customize the details, or look at a switch before starting it, the diagram draws that instead, marked Preview in its corner, and nothing changes until you use it.
Next: Rehearsal · The servers · Promoting between stages