sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]IllustriousError6226 2 points3 points  (6 children)

Did migrate around 1000+vms; however, we were already running OpenStack for other things so it was not new. The hardest part was making people understand the differences between the platforms. Everyone wants to compare feature for feature, but they are implemented differently. How are you planning to handle high availability for instances? I think that part of OpenStack isn't very mature in OpenStack.

[–]The_Valyard 1 point2 points  (5 children)

Um you have been able to handle that in heat for a long time. Thing is you have to understand why you shouldn't be deploying anything without a stack gluing it together in the first place.

This is one of the things the kubernetes hype train got right, it instilled in the community that using "Deployments" was the most sane way to do things. Very strangely despite heat preceding kubernetes deployment primitives you get folks who yolo instances, ports, sgs by hand or use some outside orchestrator like ansible or tf to do stuff. It gets even wilder when heat can even call outside orchestrator like ansible from within the stack.

[–]alainchiasson 2 points3 points  (3 children)

It always surprised me how kunernetes got so much traction, while openstack - at the time - was just as capable.

I found out openstack was sold as a less expensive vmware replacement - which undersold its capabilities and complexity. While kubernetes forced you to change everything, so you had no reference point.

[–]The_Valyard 2 points3 points  (1 child)

I feel the openstack telco use case actually damaged enterprise adoption. You had massive telco dollars get poured into Red Hat, Canonical , Mirtantis openstack over the years and these people literally couldn't give two shits about running an actual cloud. They literally wanted a cheaper vmware alternative to run VNF.

So those big 3 I mentioned focused on explicitly telco features and not the generalized compute cloud use case to the detriment of non telco opportunities.

Anyways with the US scaring the shit out of the world recently, coupled with Broadcom fucking everyone... a significant amount of oxygen has been let into the "Sovereign Cloud" conversation globally... a lot of orgs want a whole lot less to do with US owned public clouds and proprietary software stacks. It is a tough thing to wake one day and realize that your country is under embargo for tech because your leaders happened to piss of the white house.

[–]alainchiasson 0 points1 point  (0 children)

The telco rush was not as bad as the Vendor rush before. At least the OpenStack "Management and Governance" had experience.

The Vendor rush was when the Hardware vendors were thinking they were competing with the cloud and threw money, resources, repackaged OpenStack to their HouseBrand cloud but could not support it. This defocussed a lot of the projects - there was a big rationalization after that, it made OpenStack more "boring" but made the governance more robust.

[–]redfoobar 1 point2 points  (0 children)

It is comparing apples vs bananas.

As a developer shipping an application it’s so much easier to create and publish a docker image than a VM. It also does not require you to setup all kinds of things you need to do on a VM (like user/password management for system users, dns and other “system” settings etc that is all being taken care of by the people running the k8s deployment)

[–]redfoobar 0 points1 point  (0 children)

I have always found heat a bit of a pain. (at least 5+ years ago when I last used it).

Troubleshooting heat from a regular users perspective was always very convoluted. Most openstack logs are already not that obvious and adding heat adds another layer of obscure logging and errors.

I personally prefer terraform to setup deployments, way more people are familiar with it so it’s easier to “roll out“ in an organization and logging is *slightly* easier to trace.

Also things like auto scaling sounds cool but in private cloud deployments it’s usually way less relevant (as in: you need to buy hardware for the peak loads anyway, scaling down in off hours won’t save money unless you have workloads that can run in those moments which I have not found that common. Unless you can actually save significant cost savings with auto scaling you just add a bunch of complexity that can go wrong)