PE2-6.3 Cloud Architecture & Service Models

What this is and why it exists

Two classifications are used constantly in this subject and conflating them is the standard confusion.

The service models answer how much you manage. The deployment models answer who else is on the hardware. They are separate axes, and any combination of the two is possible.

The vocabulary

• Monolith — an application deployed as one unit.
• Microservices — an application split into many small services deployed separately.
• SaaS — software as a service. You use an application someone else runs.
• PaaS — platform as a service. You deploy code onto a platform someone else runs.
• IaaS — infrastructure as a service. You are given machines and networks.
• Public cloud — infrastructure shared with anyone who pays.
• Private cloud — infrastructure dedicated to one organisation.
• Community cloud — infrastructure shared between organisations with common requirements.
• Hybrid cloud — a deployment spanning more than one of the above.

The mental model

Take the service models first, and remember them by where your responsibility ends.

With infrastructure as a service you are given machines, storage and networks. You install the operating system, the runtime, the application and everything above. You have the most control and the most work, and almost anything can be built.

With platform as a service you are given somewhere to deploy code. The operating system and the runtime are somebody else's problem. You have less work and less freedom, because you can only build what the platform supports.

With software as a service you are given a finished application. You configure it and you use it. There is no operating work at all, and no ability to change how it behaves beyond what its settings allow.

That is one ladder, and where the boundary of your responsibility falls is the only thing to memorise. Everything else about each model follows: what you can change, what you must maintain, and where the shared responsibility line for security sits.

The deployment models ask a completely different question. Who else is on this hardware?

A public cloud shares infrastructure with anyone who pays. A private cloud is dedicated to one organisation, whether it runs it or a provider does. A community cloud is shared between organisations with common requirements, such as several hospitals or several agencies. A hybrid deployment spans more than one.

Which one you choose is usually driven by regulation rather than technology. Data that must not leave a country, or must not share hardware with other tenants, decides the answer before any engineering discussion. Most large organisations end up hybrid, because their older systems cannot move and their new ones do not need to stay.

The architectural choice is separate again, and it affects operation more than anything else.

A monolith is one deployable unit. It is simpler to develop, simpler to test and simpler to deploy, because there is one thing. It is scaled as a whole, so a heavily used part forces you to scale everything, and one fault can take the whole application down.

Microservices split the application into many small services, each deployed and scaled on its own. The busy part can be scaled without the rest, and one service failing need not stop the others. That is the promise.

The honest reading is that it trades deployment simplicity for operational complexity. What was a function call becomes a network request, so it can now be slow, fail, or arrive twice. Debugging spans several services. Deployment is many pipelines instead of one. Neither is right in general, and knowing why is the content of the item.

What you should now be able to explain or do

Separate the two classifications and say what question each answers. Place the three service models on the responsibility ladder. Say what decides a deployment model, and why most large organisations are hybrid. State what microservices buy and what they cost. Say why a monolith is simpler to operate and where it fails.

Check yourself