Architecture

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.

A brief at the top of the page says where things stand: your architecture (or, before you choose, the one Sapilon suggests), what it costs each month, and whether an architect needs to review it. Under the brief are three tabs: Options, the options side by side, where the page opens; Customize, your own mix; and Cloud services, how your app runs.

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 like a pricing page, with your choice or the suggested one highlighted:

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, 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 price under each option is what it costs to run on AWS each month at the traffic a new app starts with, from AWS list prices of the date shown and in your organization’s currency. No free tier is counted. When an option has a Rehearsal Server, the Live and Rehearsal parts are shown separately. What’s in this price breaks the figure down into what it pays for: running your app, your data, delivering pages, the firewall, and so on. What you actually pay 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.

Each change is checked and priced 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, priced and 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, switching to another option is a real change to running infrastructure, so it works differently:

1. Pressing Switch to, or Apply, shows the steps the change involves in a panel beside the page, and Show on the diagram draws where it leads. Nothing happens yet.
2. Start the change runs those steps, with their progress on the page.
3. 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