I have to provide a response to why we are continuing to run our stack as an IAAS vs the new OneCloud Ready Now. Does anyone have any experience with the new SAAS platform and what the limitations are for it vs. running the stack in our own environment? I know the SAAS is brand new and you can't use your 3rd party apps, such as voicemail and others. Looking for any other key items why an enterprise level company wouldn't use the new SAAS offering.
Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations TouchToneTommy on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
SAAS vs IAAS
- Thread starter trilogy8
- Start date
There's a bunch of differences...
I'd say that OneCloud is "dialtone as a service". It's the same software, but packaged in a way that it's a managed service. You trade flexibility for standard management. Everybody uses ServiceNow, there's change management when they patch stuff, etc.
It's basically their managed services layer wrapped around hosting and a reference implementation of their stuff. It's great until you absolutely need to deviate.
To be fair, the technology stack is getting more and more complicated. 10 years ago I got away with a CM terminal and hadn't really heard of SM/SMGR yet. It ain't that way anymore. So, if you want to consume the new stuff in line with a reference implementation no fuss no muss, great. But you better fit the mold. Nothing stops you from getting a very custom solution - in anybody's cloud - designed, installed, maintained, etc by Avaya according to the same managed service metrics as OneCloud ReadyNow. Getting it quick and easy is the "Ready Now" part.
I'd say that OneCloud is "dialtone as a service". It's the same software, but packaged in a way that it's a managed service. You trade flexibility for standard management. Everybody uses ServiceNow, there's change management when they patch stuff, etc.
It's basically their managed services layer wrapped around hosting and a reference implementation of their stuff. It's great until you absolutely need to deviate.
To be fair, the technology stack is getting more and more complicated. 10 years ago I got away with a CM terminal and hadn't really heard of SM/SMGR yet. It ain't that way anymore. So, if you want to consume the new stuff in line with a reference implementation no fuss no muss, great. But you better fit the mold. Nothing stops you from getting a very custom solution - in anybody's cloud - designed, installed, maintained, etc by Avaya according to the same managed service metrics as OneCloud ReadyNow. Getting it quick and easy is the "Ready Now" part.
- Thread starter
- #3
My understanding was you as the customer lose all controls and are bound to their change cycles and any updates they push out. You also lose flexibility with any 3rd party integrations and are holed into specific technologies they provide,, voicemail for one. As you said, anything you’d want to deviate from would be impossible. Also, while I see they are in a lot of countries, it’s still developing. As far as an enterprise level customer I would also think they’d not want to be on this type of platform since it was just released. Our appetite for disruptions or lack of being able to provide our user base immediate support would be a problem.
It still comes with SLA guarantees. You can still pick when you want to schedule the patches/upgrades.
That, and they don't want to provide your user base support either. They want to support their cloud. So, provided you can negotiate read-only in SMGR or otherwise be able to trace a station and confirm configurations, then it's not so bad.
It's still the same software but packaged and delivered in a different way. If you haven't standardized a bunch of stuff like station templates and feature key mapping across the enterprise already, then it can be a bigger uplift for the end users.
The architecture is all SIP, all SBC. One SBC for sets, another for trunks. From a technology perspective, nothing stops you from having SM decide the voicemail number goes across the trunk SBC to your private network to your voicemail. Then you're adhering to their standard architecture. You're still getting an Officelinx in the deal either way.
Any enterprise customer is custom to some degree. It's just that the less you need to fit Ready Now, the better a candidate you are from a technology point of view.
No doubt, there's less for the customer to do. It just depends if the management challenge you're trying to address is more around keeping up with the technology or keeping up with how your organization wants to use it. How much can your square peg be worked into a round one?
That, and they don't want to provide your user base support either. They want to support their cloud. So, provided you can negotiate read-only in SMGR or otherwise be able to trace a station and confirm configurations, then it's not so bad.
It's still the same software but packaged and delivered in a different way. If you haven't standardized a bunch of stuff like station templates and feature key mapping across the enterprise already, then it can be a bigger uplift for the end users.
The architecture is all SIP, all SBC. One SBC for sets, another for trunks. From a technology perspective, nothing stops you from having SM decide the voicemail number goes across the trunk SBC to your private network to your voicemail. Then you're adhering to their standard architecture. You're still getting an Officelinx in the deal either way.
Any enterprise customer is custom to some degree. It's just that the less you need to fit Ready Now, the better a candidate you are from a technology point of view.
No doubt, there's less for the customer to do. It just depends if the management challenge you're trying to address is more around keeping up with the technology or keeping up with how your organization wants to use it. How much can your square peg be worked into a round one?
- Status