Why Are Many OpenStack Deployments Really Small or Really Big?

DZone 's Guide to

Why Are Many OpenStack Deployments Really Small or Really Big?

People tend to dabble and test with OpenStack before fully diving in. This overview of the benefits and challenges of OpenStack will help you be ready to scale.

· Cloud Zone ·
Free Resource

It’s very interesting to see how the real-world implementations of a product or platform happen. One of the more hotly debated IaaS environments around the size and success as an effective solution is OpenStack. As a huge advocate for the open cloud platform, OpenStack is something that I’ve spent a lot of time working on from the community side, and with my day-to-day work.

5 or 500: The Edges of the OpenStack Deployment Spectrum

Many of the implementations that I’ve been a part of or a witness to tend to be what I call either 5 or 500.  This is because we tend to start by dabbling with the infrastructure in a sandbox environment. These are the 5 host environments that are the starting point which gets the first test pool up and running for a proof of concept.

Production deployments at the small range tend to mirror the test environment, so we will also tend to see 5-10 hosts running as a single region implementation in a site or across a couple of sites in a metropolitan network. Making the jump from production to the growth stage is where we stop hearing about the stories. This is also where the struggles tend to happen as we start to discover the next big step.

This is what we call Day 2.

How to Scale is a Day 2 Challenge

This is why we talk about the Day 2 challenge of any infrastructure platform. Day 0 is where we investigate and plan, followed by Day 1 which is the initial setup. Day 1 can last for a long time.  Many organizations stay in Day 1 deployments for far longer than they should. This is the Day 2 challenge.

Day 2 is comprised of a few things including:

  • Scaling strategies and associated processes

  • Maintenance plans and processes

  • Patching and security processes

  • Upgrade processes

When it comes to an OpenStack deployment, some of the greatest challenges center on the upgrade processes. This has led many to run their OpenStack in pods, which they use as a way to upgrade using net-new hardware. The new hosts are added to the environment which allows the administrators to do cold migrations of the workloads across to the new hosts. This is far from ideal when you compare it to environments which allow for in-place upgrades and maintenance of hosts without decommissioning them to do so.

OpenStack upgrades are available for in-place procedures. This is something that has become much better in recent releases and has also become a strong focus of the overall OpenStack ecosystem.

The reality is that there are many mid-sized implementations. The trick is that we don’t always get to hear about them. That is really the reason that we are seeing the spectrum. I call this the two stages of OpenStack deployment success:

  1. Holy moly, it’s up and working!
  2. Holy moly, it’s up and scaling!

If you watch the videos from the various OpenStack Summits, we celebrate these two stages the most. It’s the first discovery of getting your environment working and then the break point where all the scaling and automation for deployments are in place and wide adoption occurs. These are the two chasm points that create great stories.

The next OpenStack Summit is coming soon and we can look forward to many more of these stories. If you have a story to share there, please bring it! There are also lots of OpenStack meetups and OpenStack User Group events that are always a great place to talk with others who are in the trenches.

I know that I look forward to sharing some stories at many events in the future as I keep rolling on the OpenStack ecosystem and do everything that I can to help bolster the already powerful community wrapped around it.

cloud, cloud deployment, openstack, scalability

Published at DZone with permission of Eric Wright , DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}