Cloud architecture in the European Union

The cloud is servers, databases and other services rented from a provider and billed by usage. A region is the place where the provider's servers physically stand; choosing a region in the European Union determines where your data sits, and we record it for every service. An environment is a separate copy of the system with its own servers and data: for testing, for checking changes or for the departments' daily work.

From the provider's list of services we select those your system needs, and each choice comes with a reason: what the service does and what it means for the bill. The design is made for the provider you have chosen or that your contracts require. When the data or the contracts rule out the cloud, the system runs in your server room; that is a separate scope.

We separate the test environment from production, the environment the departments work in, and fill it with synthetic data or data stripped of personal information. We describe access as roles: who changes the test environment, who can get into the departments' data and to what extent. Backups come down to four questions: what is copied, how often, in which region the copy sits, and who checks that the system can be restored from it. Protecting the infrastructure against attack is a separate scope.

We estimate the monthly bill before launch, from the provider's price list and the assumptions written into the design: number of users, volume of data, number of environments and their hours of operation. Next to each assumption is a note of how changing it affects the bill: an additional environment, a copy in a second region, more traffic. The design assumes that the provider will change its prices or that you will change provider, so we record which services have equivalents elsewhere and which tie the system to this one provider. Moving the system to another environment or provider is a separate scope.

The result is an architecture description in two layers: one for the board and one for the IT department.

1. We write down the assumptions. We talk to the IT department and the system's users: what data, how many users, at what hours, which contracts and regulations determine where the data sits. Result: a list of assumptions for the design and the bill, approved by you.
2. We design the architecture. We select the provider's services, lay out the environments, roles and backups, and check the region of every service. Result: a draft architecture discussed with the IT department and a list of decisions for the board.
3. We calculate the bill and check the dependencies. We estimate the monthly cost, describe what changes it and identify the services that tie the system to the provider. Result: the architecture description in both layers and the bill model.
4. We hand over. We go through the design with the board and the IT department and record the decisions. Result: an approved description, ready to be implemented by your team, by us or by another contractor.

1. In which region does each of the system's services sit, and where are the backups?
2. What assumptions is the estimated bill based on, and which board decisions change it?
3. How many environments does the design include, which of them run around the clock, and what data goes into testing?
4. Who has access to the departments' data in the production environment, and who grants and revokes it?
5. Who checks that the system can be restored from a backup, and how often?
6. Which services tie the system to one provider, and what happens if that provider raises its prices?
7. Could another contractor implement this description without the author, and what would be missing for that?

The choice of services, the number of environments and the bill follow from how the company uses the system, so the first step is an analysis of that use, ending with a recommendation and a scope.