OpenStack 101: Are You Ready to Build Your Own Cloud?
From cloud service models to private cloud, and from there to the open-source world’s most established cloud platform.
When we talk about cloud computing, our minds jump straight to the giants: AWS, Azure, GCP. But what if I told you that you could run the very services those giants offer inside your own data center, entirely under your own control?
In this article we’ll take a journey that starts with cloud service models, moves through the concept of private cloud, and lands on OpenStack — one of the most mature open-source cloud platforms out there. Together we’ll map out a wide territory: from core services to optional ones, from storage architecture to real-world usage examples.
And there’s pizza involved. 🍕
The Tastiest Way to Understand Cloud Service Models: Pizza as a Service
Perhaps the most memorable way to explain cloud service models is the famous “Pizza as a Service” analogy. The scenario is simple: you’re craving pizza, and there are four different ways to make that happen
1. Do It All Yourself (On-Premise)
You could call this the “cook it yourself, eat it yourself” approach. You go to the store, buy the ingredients, methodically work through flour, water and yeast, knead and stretch the dough, set the oven temperature, lay the table — and at the end of it all, you wash the dishes too. End-to-end responsibility is yours. The IT equivalent: building and operating your own data center from scratch.
2. Frozen Pizza (IaaS — Infrastructure as a Service)
You buy a ready-made frozen pizza from the store and throw it in the oven. You don’t deal with dough or toppings; only baking and setting the table are on you. The infrastructure is handed to you ready to use, and what you put on top of it is your call.
3. Delivery (PaaS — Platform as a Service)
You order from the pizzeria and the pizza arrives at your door already cooked. You don’t even deal with the baking; you set the table and enjoy. Platforms like Heroku, or cloud providers offering Kubernetes as a managed service, are good examples of this model.
4. Dining Out (SaaS — Software as a Service)
You have no responsibility at all — you simply use the product. Gmail, Dropbox, Google Drive… You have no connection to the infrastructure whatsoever; you just enjoy the service.
From server to software: four steps in which infrastructure responsibility shifts from you to the provider.
Private Cloud or Public Cloud?
If time-to-market is critical — meaning you need to ship quickly and can’t afford to lose time building infrastructure — public cloud has the advantage. But if you’re thinking long-term, and you want the infrastructure you build to start paying for itself over time, private cloud can be a very strong choice.
It’s also perfectly possible to run a hybrid model, or to start on public and migrate to private later. This is entirely a decision shaped by the requirements of the company and the product.
Key advantages of private cloud
- Cost control: Above a certain scale, owning rather than renting becomes significantly more economical.
- Data sovereignty and compliance: You decide where your data physically lives. For regulated industries this isn’t a luxury — it’s a requirement.
- Freedom to customize: You can shape every layer, from hardware to network topology, according to your needs.
- Escaping vendor lock-in: On an open-source platform, you’re not at the mercy of a provider’s pricing policy or roadmap.
So What Exactly Is OpenStack?
OpenStack is an open-source IaaS platform that pools the compute, storage and network resources in your data center and turns them into rentable cloud resources exposed through an API.
OpenStack isn’t a single program; it’s a modular system made up of services that each do one job and work together. Nova manages virtual machines, Neutron the network, Cinder block storage, Glance images, and Keystone identity — while Horizon gathers all of them into a single web interface.
The services talk to each other over REST APIs, and the user reaches those same APIs through a CLI, an SDK, or the UI. In short: it does the job that AWS, Azure or GCP does. The difference is that it’s fully open source and it runs on your hardware.
A Short History
The OpenStack story goes back to 2010. NASA was working on a cloud infrastructure it called Nebula, while hosting giant Rackspace was developing its own object storage solution. The two sides joined forces and released the project to the world as open source.
Today the project moves forward under the OpenInfra Foundation umbrella, with contributions from thousands of developers around the globe and a regular release cycle. So OpenStack is neither a startup experiment nor a short-lived hype: it’s a mature ecosystem with 16 years of history behind it.
OpenStack Architecture
1. A Modular System — Every Component Does One Job
This is OpenStack’s most fundamental design decision. Instead of one giant application, there are independent services, each with its own code repository, its own database and its own API. Nova deals with virtual machines and knows nothing about networking — when it needs something, it asks Neutron.
What this means in practice: You don’t install a service you don’t need. If you’re not going to use object storage, you simply never include Swift. When a service goes down, you don’t lose the entire cloud — only that capability. And each service is developed on its own release cycle; an improvement in Neutron doesn’t wait for Nova.
The price: Nine services means nine databases and nine sets of configuration files. The bill for modularity is operational complexity — which is precisely why tools like Kolla-Ansible exist.
2. Deployment Order Matters
The services are independent, but they depend on each other. You can’t install them in an arbitrary order:
Infrastructure (MariaDB, RabbitMQ, Memcached)
↓
Keystone → without identity, no service can register itself
↓
Glance → Nova needs images
↓
Placement → Nova scheduler needs a resource inventory
↓
Nova → a VM can't boot without networking
↓
Neutron
↓
Cinder, Horizon, and the restHere’s the reason: as each service is installed, it registers itself in Keystone’s service catalog and defines an endpoint. Without Keystone, no registration can happen. In the same way, when Nova boots a VM it must pull the image from Glance — if Glance isn’t up, the instance gets stuck in BUILD state.
That’s why installation documents follow a strict order, and why Kolla-Ansible playbooks encode this dependency graph.
3. Every Service Authenticates Through Keystone
A centralized identity model. The flow works like this:
- The user sends credentials to Keystone
- Keystone returns a token (time-limited, scoped)
- The user sends the request to the target service with that token (
X-Auth-Tokenheader) - The service validates the token against Keystone
- If it’s valid, the request is processed
The critical point: this doesn’t only apply between user and service — it works service-to-service as well. When Nova requests a port from Neutron, it uses its own service token. So Keystone isn’t just the front door; it’s the chain of trust for the entire ecosystem.
The consequence: Keystone is a single point of failure. If it goes down, existing VMs keep running (the data plane stays up), but no new operation can be performed — the control plane locks up. In production, Keystone is always run across multiple controllers behind a load balancer.
4. Services Expose REST APIs
Every service has its own HTTP endpoint: Keystone on 5000, Glance on 9292, Nova on 8774, Neutron on 9696, Cinder on 8776.
The real message here is that Horizon and the CLI are nothing more than clients. When you create a network from the web interface, when you type openstack network create, and when you call POST /v2.0/networks directly — all three hit the same endpoint and run the same code. Everything you can do in the UI can be done through the API; the reverse isn't always true (the API often exposes capabilities before Horizon does).
What this gives you: the Terraform OpenStack provider, Ansible modules, the Python SDK, the automation scripts you write yourself — all of them work over these APIs. This is what turns the cloud from “a panel you manage by clicking” into programmable infrastructure.
5. Commodity Hardware + a Linux Hypervisor
OpenStack doesn’t require special hardware; it runs on ordinary x86 servers. And it doesn’t do the virtualization itself — this distinction is worth emphasizing.
The real work is done by KVM (the hypervisor built into the Linux kernel), hardware emulation is handled by QEMU, and libvirt provides the management interface for both. Nova sits at the top of this chain and tells libvirt, “boot a VM with this image, in this flavor.”
Nova Compute → libvirt → QEMU/KVM → physical CPU (VT-x / AMD-V)This is why hardware virtualization support is mandatory on compute nodes. If you’re building a lab and plan to run VMs inside a VM, you need to enable nested virtualization — otherwise instances either won’t boot at all or will run unacceptably slowly.
Nova is hypervisor-agnostic: instead of KVM you can use Xen, VMware ESXi or Hyper-V. But in the open-source world, KVM is what people actually choose in practice.
6. Multi-Tenancy
OpenStack was designed from day one to host multiple customers on the same infrastructure in an isolated way. Isolation is enforced at several layers:
Layer How isolation works Identity Domain → Project (tenant) → User → Role hierarchy Network A separate L2 segment per tenant via VLAN / VXLAN / GRE Traffic Security groups (a firewall attached to the VM’s NIC) Resources Quotas — per-project limits on vCPU, RAM, volumes, floating IPs Storage Volumes and objects are owned by a project
The result: a user in Project A cannot see Project B’s VMs, cannot reach its network, and cannot consume its resources — even if they’re running on the same physical server.
Get Özcan Kara’s stories in your inbox
Join Medium for free to get updates from this writer.
This is the feature that makes OpenStack a fit for telcos, universities and enterprise internal clouds. If you’re only serving a single team it may look like over-engineering — but when you later need department-level separation, you won’t have to rebuild the infrastructure.
Pulling the Architecture Together
These six points feed into each other: modularity makes the services independent, independence makes REST APIs mandatory, keeping those APIs secure puts Keystone at the center, Keystone’s centrality dictates the installation order, multi-tenancy is built on top of that identity model — and all of it runs on commodity hardware.
Who Uses OpenStack?
OpenStack’s strongest references come from places where scale is the requirement:
- CERN — processes the enormous scientific data load coming out of its particle accelerator on OpenStack.
- Walmart — the retail giant uses it for its high-traffic e-commerce infrastructure.
- China Mobile — the NFV infrastructure of one of the largest operators in telecom runs on OpenStack.
- Trendyol — operates Turkey’s largest OpenStack deployment (more on this below).
- Turkcell — the second strongest reference. It runs a telco cloud on Red Hat OpenStack: more than 12,000 virtual machines, roughly 20 TB per second of virtual network capacity, and over 30 core network services running on OpenStack. For its 5G environment, they’ve layered OpenShift on top. Turkcell is also known to use Swift, OpenStack’s object storage solution, in its storage infrastructure.
In Turkey, several large e-commerce and telecom companies run infrastructures made up of thousands of physical servers and tens of thousands of virtual machines on OpenStack. Deployments at this scale generally operate on a self-service cloud model: instead of filling out a request form and waiting for days, developers allocate the resources they need themselves, in seconds.
While preparing this article, I drew on the OpenStack presentations shared on Trendyol Tech’s YouTube channel as a Turkish-language source: https://youtu.be/F1FyUxoH73w?si=2b30JyW1gmnZEa0C
Turkey’s Largest OpenStack Infrastructure: Trendyol
Trendyol operates the largest OpenStack infrastructure in Turkey:
- More than 7,000 physical servers
- More than 80,000 virtual machines
- A core count approaching 1 million
To make that concrete: picture 125,000 powerful 8-core laptops all running at the same time. All of it managed by OpenStack.
What’s more, this infrastructure runs on a self-service cloud model: through developer-experience-focused tooling, developers can carve out and start using the resources they need themselves.
Trendyol’s e-commerce platform, Trendyol GO, Express… a large part of these platforms you use every day run on OpenStack, at high performance. And the infrastructure keeps growing fast: crossing 1 million cores and reaching 100,000 virtual machines is expected in the near future.
OpenStack’s Core Services
OpenStack isn’t a single piece of software; it’s a collection of services that talk to each other over APIs, each taking on a specific responsibility. You don’t need all of them to build a cloud — but it’s hard to make progress without knowing this core cast.
Keystone — Identity and Authorization
The gateway to the entire ecosystem. Users, projects (tenants), roles and service catalogs are all defined here. Every other service validates incoming requests by asking Keystone whether they’re legitimate. If Keystone goes down, the cloud effectively locks up — which is why it’s always deployed highly available.
Nova — Compute
Where virtual machines are born. It abstracts the hypervisor layer (usually KVM) and manages VM creation, start, stop, resize and migration. When you say “give me an instance with 8 vCPUs and 32 GB of RAM,” Nova is the service that gets it done.
Glance — Image Service
The repository of the templates from which VMs are born. Ubuntu, CentOS, or the golden images you’ve built yourself are stored and versioned here. When Nova creates a VM, it pulls the image from Glance.
Neutron — Networking
One of the most complex but most critical parts of the cloud. Virtual networks, subnets, routers, floating IPs, security groups — all of it is Neutron’s responsibility. This is the service that brought Software Defined Networking into the OpenStack world.
Cinder — Block Storage
Provides persistent disk volumes that can be attached to VMs. Even if an instance is deleted, the Cinder volume survives; you can attach it to another VM. Snapshot and backup capabilities come from here as well.
Swift — Object Storage
A storage service that keeps files as objects and scales almost infinitely horizontally. Think of it as the OpenStack world’s answer to S3. It’s designed around redundancy and durability.
Placement — Resource Inventory
Tracks how much of the cluster’s resources (CPU, RAM, disk) is consumed and by whom, and guides the scheduler on the question of “where should this instance land.” A service that works behind the curtain but is absolutely indispensable.
Horizon — Web Interface
The web-based management panel that sits on top of all these services. The CLI and API are always more powerful, but Horizon is very useful for introducing the cloud to a team and for quick operations.
Optional Services: Growing Your Cloud
You can build a working IaaS with the core services alone. But OpenStack’s real power shows up in the services you can add to the ecosystem as your needs grow.
- Heat — Orchestration. Define your infrastructure as a template and bring it up with a single command. This is OpenStack’s Infrastructure as Code layer.
- Magnum — Container orchestration. Offers Kubernetes clusters as a service on top of OpenStack.
- Octavia — Load Balancer as a Service. Puts managed load balancers in front of your applications.
- Barbican — Secret management. A central, secure vault for keys, certificates and passwords.
- Designate — DNS as a Service. Automatic DNS record management inside the cloud.
- Manila — Shared file system. Offers NFS/CIFS-style shared file systems as a service.
- Ironic — Bare metal provisioning. You provision physical servers directly rather than virtual machines — critical for workloads that demand high performance.
- Trove — Database as a Service. Managed database instances.
- Ceilometer — Telemetry. Metric collection, monitoring and billing data generation. Together with Gnocchi (storage) and Aodh (alarming), it forms the telemetry stack.
Storage: The Cloud Layer Most Often Designed Wrong
Getting compute up and running is relatively easy. Things get messy at the storage layer — because the decisions you make here are the most expensive ones to reverse.
Ephemeral vs. Persistent
Ephemeral storage is tied to the instance’s lifecycle. If the VM is deleted, the data goes with it. It’s fast and cheap, but only suitable for temporary data and stateless workloads.
Persistent storage lives independently of the instance. Even if you delete the VM, the data stays where it is. Databases, file stores, log archives — anything that demands durability belongs here.
A common mistake: taking a service that runs on ephemeral storage in the development environment and moving it to production with the same template.
The Three Fundamental Storage Types
Block Storage (Cinder) — Attached to a VM as a raw disk, on top of which you install whatever file system you want. The right choice for databases that need low latency and high IOPS. Typically attached to a single instance at a time.
Object Storage (Swift or Ceph RGW) — Stores data as objects rather than in a file hierarchy, accessed over an HTTP API. Ideal for backups, media files, static content and data lake layers. Scales almost infinitely horizontally, but isn’t a fit for latency-sensitive workloads.
File Storage (Manila) — A shared file system that multiple instances can read from and write to simultaneously. A lifesaver for legacy applications and shared content directories.
Ceph: OpenStack’s Storage Backbone
In practice, the majority of serious-scale OpenStack deployments run Ceph underneath. With a single distributed storage cluster you can cover three needs at once:
- RBD → block storage for Cinder
- RGW → S3-compatible object storage
- CephFS → shared file system for Manila
On the Ceph side, the most critical decision is replication or erasure coding. Replication (three copies, for example) is fast and recovery times are short, but it makes only a third of your raw capacity usable. Erasure coding is far more efficient, but the CPU cost and rebuild times are high. Keeping hot data on replication and cold archives on erasure coding is a common and healthy balance.
And Don’t Forget: A Snapshot Is Not a Backup
A snapshot sits on the same cluster. If you lose the cluster, you lose the snapshot with it. A real backup strategy requires keeping a second copy of the data on a different system — ideally in a different location. And a backup whose restore has never been tested doesn’t count as a backup.
Where Should You Start?
Trying to build a production cluster from scratch is the hardest way to learn. A smarter sequence:
- Bring up a development environment on a single machine with DevStack. The goal isn’t production — it’s to poke at the services by hand.
- Use the CLI and the API instead of Horizon. You’ll learn how the cloud actually works at the command line.
Closing
OpenStack is an open-source cloud operating system with 16 years of history behind it, combining the comfort of public cloud with the control, security and cost advantages of private cloud. It was born out of NASA’s need, it carries CERN’s scientific workloads, and it shoulders Trendyol’s enormous e-commerce traffic.
The question is no longer whether you can build your own cloud. It’s whether you’re ready to start.
If you found this useful, feel free to share it — and let me know in the comments which OpenStack service you’d like a deep dive on next.
