As a popular open-source choice for deployments, OpenStack does have some concerns for business leaders who are intending to scale a cloud project. Many of them have to do with the open-source nature of OpenStack, versus proprietary platforms.
One challenge is the “community support” or “crowdsourced” nature of OS as an open-source tool. Many CIOs and CTOs are going to want something more, some measure of pre-planning capability offered by vendor products that have more long-term forward planning.
In general, any project can be hard to scale regardless of the platform, but another concern for some leaders is the lack of in-place upgrade support in traditional OS environments. That has meant, in some cases, the need to perform cold migrations to get a project scaled.
Another concern is a lack of ready integration capability with some leading public cloud systems. OS can be hard to fit to some of these options, and may require more manual intervention. Again, this is in keeping with the philosophy of open-source products, which are often “less user friendly” than vendor products. In other words, the vendors invest in different kinds of user engineering or other concessions based on the revenues that they expect to get from sales.
Many experts refer to scaling as a key “flash point” with OpenStack. There’s the idea that creating and implementing the project is one stage, and that scaling is another entirely different stage. IT pros, in talking about the challenges of scaling, will imply that the success of the first implementation stage does not necessarily ensure or lead to the success of the second scaling stage, that there are specific obstacles in scaling that are not “automatically solved” by implementation or other preceding phases. That, compared with the open-source build of the system, create inherent challenges, including maintenance challenges, resource allocation challenges, and others that developers and project managers will not generally anticipate unless they put thought into the eventuality of trying to scale the system after the fact.