Lesson 5.1: Cloud, private cloud and on-premises
Where software runs decides how you build and ship it. Learn the deployment targets, who is responsible for what, and how to design for the environment.
By the end of this lesson you will be able to explain the main places a customer's software can run (public cloud, private cloud, on the customer's own servers and mixes of these), say who is responsible for what in each, ask the ten questions that reveal a customer's environment and design software that can move between them. You will see how the answer changes what you can build, how long a first deployment takes and what you must prepare in advance. You will study three deployments, one of them in a hospital with no internet access, and use a simulator to estimate the time before your first release can run. This lesson opens Module 5, on deploying and operating. It follows Module 4, where you built something worth deploying, and it covers the question that comes next: where does it run? You do not need to be a systems expert. The ideas are explained from the start.
Many engineers meet this question late and by surprise. They build a system on their own laptop or in their company's cloud account, show it to the customer and are told: "It must run in our own data centre, with no connection to the internet." Weeks of work can be affected, because a hundred small choices assumed an internet connection, a cloud service or a tool that the customer's environment does not allow. Asking early where the software must run is one of the highest-value questions in the role, and the answer shapes almost everything that follows.
Why the place matters
For a customer, the place where software runs is rarely a technical preference. It is shaped by rules, risks and history.
Regulation and policy. Many banks, insurers, hospitals and government bodies must keep certain data in specific places, such as inside the country, or on systems they control. Their regulators may require approval before data moves to a provider.
Security posture. Some organisations do not allow outside systems to reach their data at all, or allow it only through carefully controlled paths.
Existing investment. A customer that has spent years building its own data centre, or negotiated a large contract with one cloud provider, will want to use it.
Skills. The customer's team can only run what it knows how to run.
Latency and connectivity. A factory floor or a remote clinic may have poor or no network connection to the outside world.
Cost and control. Some customers prefer predictable fixed costs and full control, and others prefer paying for what they use.
For you, the place decides what tools you may use, how you reach the machines, how you install things, how you see what is happening and how you update the software. The same application might take two days to deploy in one environment and two months in another, and most of the difference has nothing to do with the code.
The main places software can run
The words used here are common, and people sometimes use them loosely. The definitions below follow widely used ones, including those of the US standards body NIST, whose description of cloud computing is a common reference.
Public cloud. A provider such as one of the large cloud companies offers computing, storage and other services, over the internet, to many customers sharing the same pool of resources. You can create a server in minutes, pay for what you use and scale up or down quickly. The customer might have their own account within the provider, with their own isolated networks, which is the usual setup for business customers.
Private cloud. Cloud-style infrastructure, with the same kind of self-service and flexibility, but used by a single organisation. It might run in the customer's own data centre or be hosted for them by a provider. The word private refers to who uses it, not to how secure it is.
On-premises. Servers that the customer owns and runs in its own buildings or rented space. The customer's team installs, patches and maintains them. Getting a new server may take weeks, and connections to the internet are often restricted.
Hybrid. A mix: some parts in a public cloud, some on the customer's own systems, connected together. Hybrid setups are common in practice, since few large organisations move everything at once.
Air-gapped. A system with no connection to the outside internet at all, found in some defence, health and industrial settings. Anything you need must be carried in, checked and installed by hand.
A related set of words describes how much the provider manages for you. In infrastructure as a service, the provider supplies basic computing, storage and networks, and you manage the rest, including the operating system. In platform as a service, the provider also manages the operating system and the runtime, and you supply the application. In software as a service, the provider supplies the whole application, and you configure and use it. The more the provider manages, the less you control and the less you must maintain.
Who is responsible for what
An idea that appears in every cloud arrangement is that responsibility is shared. The large providers describe it in a shared responsibility model. The provider secures the underlying infrastructure: the buildings, the hardware, the core software and the networks. The customer secures what it builds and stores on top: its data, who may access it, how it is encrypted and its own application software. Where the line falls depends on the service. If you rent a basic virtual server, you are responsible for its operating system and its updates. If you use a managed storage service, the provider runs the operating system and platform, and you focus on the data and its permissions.
The practical lesson is that moving to the cloud does not remove responsibility. It moves the line. In the same way, on-premises systems put almost everything on the customer's team, and private clouds sit in between. Before you design anything, find out where the line is in this customer's environment, because it tells you what you may rely on and what you must provide.
· Public cloud · Private cloud · On-premisesWho owns the hardware · The provider · The customer or a host · The customer
How fast to get a server · Minutes to hours · Hours to days · Days to weeks, sometimes months
Who patches the operating system · You, or the provider, depending on the service · The customer's platform team · The customer's team
Internet access from servers · Usually yes · Often restricted · Often restricted or none
Typical constraints · Cost, shared responsibility, data location · Approved images, internal processes · Hardware lead times, change windows
Typical reason to choose it · Speed and flexibility · Control with cloud-style tools · Regulation, existing assets, no outside connection
## Ten questions to ask in the first week
The surest way to avoid a late surprise is to ask about the environment at the start. These ten questions cover most of what matters. Ask them of the customer's technology or platform team, and write the answers in the one-page plan.
1. Where will this run? Which cloud account, data centre or location, and who owns it?
2. How do I get in? Remote access, a VPN, a jump server, a virtual desktop or only on site? Does my access come from a named account?
3. Can servers reach the internet? Directly, through a proxy, to an approved list of addresses or not at all?
4. How do I install software? Can servers download packages and container images, or must everything come from an internal mirror or a media drop?
5. How are secrets stored? Is there a secret manager, and how do programs get their credentials?
6. How are changes approved? Is there a change board, a ticket process, a release window? How long does it usually take?
7. How long to get a server or an environment? Days or months? What approvals does it need?
8. What monitoring and logging exist? Where do logs go, and what must my software send there?
9. How are backups and recovery handled? By the platform, or must I provide them?
10. What rules apply to the data? Where may it live, how must it be protected and who has approved this use?
Question four is often the most revealing. A customer who says "servers cannot reach the internet" has told you that anything your application downloads while running, and anything it calls outside, will not work.
Predict first: a customer tells you the system must run on its own servers, with no internet access. Your design calls an outside web service for one of its steps, and the build process downloads libraries from public sources. What is the first thing you would find out, and what are two things you might have to change? Decide before reading on.
The first thing to find out is exactly what "no internet" means: completely closed, or a controlled path through a proxy to a short approved list. The answer decides how much changes. If it is completely closed, the outside web service will not be reachable, so you would need to replace it with something that runs inside, or drop that step. And the build process cannot download anything at install time, so you would need to prepare a complete bundle of the software and every library it uses, carried in and installed from an internal source. Both changes are easier to make in week one than in week ten.
Designing for any environment
You cannot control where a customer will run your software, so a good engineer designs it to run almost anywhere. A few habits make that possible.
Package it so it runs the same everywhere. A container is a standard way to bundle an application with everything it needs, so that it runs the same on a laptop, in a cloud or on a customer's server. Lesson 5.2 covers packaging in depth. The idea for now is to avoid depending on what happens to be installed on a particular machine.
Keep settings outside the code. Addresses, credentials, file paths and limits should be configuration, supplied when the program starts, not typed into the code. Then the same build can run in the customer's test and live environments with different settings.
Avoid unnecessary lock-in. A feature unique to one cloud provider is convenient and makes the software hard to move. Where a customer might later change provider or run on-premises, prefer standard, widely available building blocks, such as an ordinary database and a standard queue, and keep provider-specific parts behind a thin layer you can replace.
List every dependency. Know exactly which libraries, services and tools your system needs, with versions. This list is essential for an air-gapped install, for a security review and for fixing problems later.
Do not assume the internet. Design the application so that it can run, or degrade gracefully, if an outside service is unreachable. Where an outside service is essential, say so early.
Describe the environment as code. Write the setup of servers, networks and settings in files that can be reviewed and rerun, so that a new environment can be created reliably and the difference between test and live is visible. This is often called infrastructure as code. It makes the work repeatable and lets the customer's team audit what you did.
Plan for the least capable environment. If the system can run in the most restricted target, it will run in the others. The reverse is rarely true.
Worked example 1: inside the lender's own cloud account
The lender runs on a public cloud, in its own account, with a private network that is closed to the outside except through a managed gateway. The security team's rule, set out in Lesson 3.4, is that customer data must stay in this account.
The engineer's plan follows the rule. The reminder system's components run inside the lender's account, in the lender's private network. The only outbound connection is to the messaging provider, through the gateway, to an address on the approved list. The software is packaged as a container, so the lender's platform team can deploy it with its usual tools. Secrets are held in the account's secret manager.
The timeline is the real cost. The lender's change process requires a review of the network design, which takes about two weeks, and a request for the account permissions, about one week. The engineer starts both in the first week, in parallel, as Lesson 2.2 advised, so that the first deployment lands in week four, not week eight. The code did not change at all between the engineer's own test account and the lender's. What changed was waiting for permission, and that is the usual shape of a deployment into a customer's cloud.
Worked example 2: the hospital with no internet
The hospital group's largest hospital runs its systems on its own servers in a basement data room, with no connection to the internet and a change window on the first Sunday of each month. The bed screen must run there.
The engineer's first design assumed a web-based reporting tool that downloads some components when it starts. That does not work. The new plan prepares everything in advance: a single bundle containing the application, every library and the database software, tested by installing it on a clean machine with the network disconnected. The bundle is delivered on an approved storage device, scanned by the hospital's security team and installed on the first Sunday window. Updates will use the same route, monthly, so the engineer plans releases around the calendar.
The first server takes six weeks to arrive, because it must be ordered and installed by the hospital's infrastructure team. The engineer builds on the group's other hospitals first, which have network access, and treats the basement install as the final step. Two lessons stand out. Plan the longest-lead item, the server, in the first week. And test the install on a disconnected machine before the date, because the day of the window is not the time to discover a missing library.
Worked example 3: a mix at the retailer
The retailer runs its point-of-sale system in a hosted service, its ordering system on its own servers and its forecasting in a public cloud account. The engineer's job is to connect them.
The connection is the interesting part. The ordering system sits behind a firewall that allows only outbound connections, so the forecast cannot be pushed in. Instead, a small agent on the retailer's own server pulls the forecast from the cloud on a schedule and delivers it to the ordering system. The agent stores its credentials in the retailer's secret store, logs every transfer and sends an alert if a file does not arrive by 7 a.m.
A mixed environment turns every design into a question of which side can reach which. Draw the picture early: boxes for each system, arrows for each connection, and a label on each arrow saying who may open it. It often shows that a connection you assumed is impossible, and suggests the small agent or relay that makes it work.
The three deployments show the same lesson from different sides. The lender gained four weeks by starting the approvals early, and the hospital's schedule was set by the slowest item, the server.
Estimating the lead time
Because lead time is mostly waiting, you can estimate it with some simple arithmetic and plan the schedule around it. Several approvals are usually needed before a first deploy: access to the environment, a network opening, a security review of the design and a change approval. Each takes some days. Some can run in parallel, and some must follow one another. On top of that comes the time to get a server or an environment, and a margin for the surprises that always appear.
The simulator below turns this into numbers. Set the number of approval steps, the average days each takes, the share of that waiting that can run in parallel, the days to provision the environment and a buffer for surprises. It shows the estimated lead time in weeks, compared with doing everything in sequence, and plots how the lead time grows with the number of approval steps.
The inputs are your estimates, and the model is crude, since real approvals depend on each other in more complicated ways. But it shows why starting the approvals in week one, in parallel, matters so much, and why a customer with many approval steps needs a longer plan.
Try three experiments. First, keep the defaults and read the lead time. Second, set the parallel share to zero, and see how much of the lead time you save by running approvals together. Third, set the provisioning time to 40 days, which describes a customer who orders physical servers, and see how it dominates.
At the defaults, four approvals of seven days with 30 per cent running in parallel, ten days to provision and a 25 per cent buffer come to about 37 days, or 5.3 weeks. Run in sequence they would take 6.8 weeks, so the overlap saves about a week and a half. Notice how the provisioning and the approvals together dwarf any plausible build time for a small pilot, which is why asking the ten questions in the first week is so valuable.
Common mistakes
Assuming your own environment is the customer's. Ask where it will run before you design.
Assuming internet access. Find out exactly what is allowed, and design for the least capable environment.
Hard-coding settings. Put addresses and credentials in configuration so the same build runs everywhere.
Provider lock-in by accident. Keep provider-specific features behind a thin layer you can replace.
Forgetting the dependency list. You need every library and version for an offline install and a security review.
Starting approvals late. Lead time is mostly waiting. Begin in week one and run steps in parallel.
Testing the install on the day. Rehearse on a clean, disconnected machine before the window.
Ignoring the shared responsibility line. Work out who patches, who backs up and who monitors, and write it down.
Using the biggest environment for a pilot. A lighter environment, where one exists, can let a pilot start weeks sooner.
Key takeaways
Where software runs is shaped by regulation, security, existing investments, skills and connectivity, and it decides how you build, install, observe and update.
The main places are public cloud, private cloud, on-premises, hybrid and air-gapped. They differ in who owns the hardware, how fast you get a server and what access you have.
Responsibility is shared. Moving to the cloud moves the line between provider and customer, and does not remove it.
Ask ten questions in the first week, especially about internet access and how software gets installed.
Design to run anywhere: package it, keep settings outside the code, list every dependency, describe the environment as code and plan for the least capable target.
Lead time is mostly waiting for approvals and servers. Start the approvals in week one, in parallel, and rehearse the install.
Check yourself
1. Name the main places software can run, and one thing that distinguishes private cloud from on-premises.
Public cloud, private cloud, on-premises, hybrid and air-gapped. A private cloud has cloud-style self-service used by one organisation, and may be hosted by a provider. On-premises means servers the customer owns and runs itself.
2. What does the shared responsibility model say?
The provider secures the underlying infrastructure, and the customer secures what it builds and stores on top, such as data, access and its own software. The line depends on the service.
3. A customer says servers cannot reach the internet. Name two things that may have to change in your plan.
Calls to outside services must be replaced or dropped, and libraries must be delivered as an offline bundle installed from an internal source.
4. With 5 approval steps of 5 days, 40 per cent of the waiting in parallel, 14 days to provision and a 20 per cent buffer, what is the lead time?
(14 + 5 × 5 × 0.6) × 1.2 = (14 + 15) × 1.2 = 34.8 days, about 5 weeks.
5. Why design for the least capable environment?
Software that runs in the most restricted target will almost always run in the others, and the reverse is rarely true.
Try this
This exercise takes about forty minutes and produces an environment profile. Use a customer you know, a company you work for, or an imagined one such as a regional bank.
1. Write down where the system is likely to run, and who owns that place.
2. Answer the ten questions as best you can. For each you cannot answer, write who you would ask.
3. Draw a simple picture of the systems involved, with an arrow for every connection and a label on each saying who may open it.
4. List every outside service and download your design relies on. Mark any that would fail with no internet.
5. Write the dependency list for a small application you know: its libraries and services with versions, or as many as you can find.
6. List the approvals you would need before a first deploy, and who owns each. Use the simulator to estimate the lead time.
7. Write the single longest-lead item and the date by which you would start it.
A good result is a one-page environment profile with the ten answers, a connection picture, a list of risky dependencies, a lead-time estimate and the first thing you would request. It is the environment section of your plan, and it saves the surprise of discovering in week eight that your design assumed a connection that was never there.
Sources
[Computer security resource centre: SP 800-145, the NIST definition of cloud computing](https://csrc.nist.gov/pubs/sp/800/145/final), US National Institute of Standards and Technology. The landing page confirms the standard's framing of cloud computing as on-demand access to a shared pool of resources, with essential characteristics, service models and deployment models. I could not read the definitions from the page itself, so the descriptions of public, private and hybrid clouds and of the service models are standard usage explained in my own words, and the full document should be read for the exact wording.
[AWS shared responsibility model](https://aws.amazon.com/compliance/shared-responsibility-model/), Amazon Web Services. Used for the description that the provider secures the underlying infrastructure and the customer secures what it builds and stores on top, with the line depending on the service. It describes one provider's model, and other providers use similar ideas.
The three deployments, the lead times and the simulator's figures are the author's illustrations for teaching, not data from real companies.
Tags: Forward Deployed Engineer Cloud On-premises Deployment Infrastructure