If what they have doesn't meet requirements, it's their fault if it's slow. If they fuck it up themselves, it's billable hours if easy or wipe, reinstall, import last known good DB if not easy.
My intent was to say that whatever methods you do to manage your existing infrastructure can just as easily manage hundreds of on-prem installations. That's the power of orchestration. What's underneath doesn't really matter, it just does it. They install whatever the blest OS is with appropriate options (or you have an OVA\ISO\etc. that gets them to the right spot) and forward the correct ports. Load the SSH keys and your orchestration tools connect to that SSH port and begin the "new environment" task. Once your beta tests are done, you build whatever task you need to accomplish those updates and it connects to every machine and does it, regardless of that machine's location. The same processes would be used whether in-house or on-premises. They're just IPs, ports, credentials and roles. It's not a technical issue. It isn't even that it's technically difficult as you're likely already doing this. You just don't want to. ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP ----- Original Message ----- From: "Simon Westlake" <simon@sonar.software> To: af@afmug.com Sent: Tuesday, October 17, 2017 6:20:55 PM Subject: Re: [AFMUG] Sonar There's no reason it can't technically, but think about what you just said, and then managing that for hundreds of customers that don't have that level of understanding. And then we have to deal with ongoing deployment, updates, etc. Reality is, it ain't gonna happen :) On Oct 17, 2017 6:15 PM, "Mike Hammett" < af...@ics-il.net > wrote: A VM on Digital Ocean isn't significantly different than a VM on my infrastructure. Need two VMs? Ten? Have IOPS requirements? IO latency requirements? RAM requirements? There's no reason it can't be a local install, assuming Sonar already has partitions between customers. Whatever you do to spin up an instance now can be done on my vSphere or my Proxmox or my Hyper-V (not that I have Hyper-V) just as easily. Scripts are scripts and Git or whatever the flavor of the day for code updates are the same whether the IP is 1.1.1.1 or 2.2.2.2. How do you manage things now? I assuming Puppet, Ansible, Chef, etc. to orchestrate the same OS updates and changes across the whole infrastructure you have. No different if it is here or there. ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP From: "Simon Westlake" <simon@sonar.software> To: af@afmug.com Sent: Tuesday, October 17, 2017 6:03:37 PM Subject: Re: [AFMUG] Sonar Sure, if you don't want to be able to provide that level of service. There comes a point where you can't deliver a product of high complexity at a high level of scaling when everything runs on one VM. We're already there with a lot of our customers - we have clusters of dedicated servers doing nothing but parsing Netflow data, for example. It's not the right approach for everything, but it's one of the major reasons we don't do a local install for Sonar. It's just not technically feasible, and there's an inverse demand for it. The bigger customers we deal with don't want it, because they don't have the infrastructure and they don't want to manage it. Smaller customers sometimes want it, but they don't have the financial resources to provide what we'd need to deploy, and there's not enough revenue there for us to build some separate locally installable platform that all gets dumped together into one VM. Can't speak for everyone, but that's the deal for us. The goal for Sonar is that we can spin up service for an ISP with 250,000 subscribers as easily as we can for one with 250, and it's not an achievable goal when you're trying to manage installations in hundreds of different places, and maintain all these different deployment methods. On 10/17/2017 5:58 PM, Mike Hammett wrote: <blockquote> So don't do that? :-p ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP From: "Simon Westlake" <simon@sonar.software> To: af@afmug.com Sent: Tuesday, October 17, 2017 5:55:30 PM Subject: Re: [AFMUG] Sonar It makes a big difference when it doesn't run on a server, but a cluster of auto-scaling VMs. I would agree that in a simple deployment methodology, it becomes fairly irrelevant, but if you are running across something like Azure or AWS, it is far from a one to one mapping to just drop it on someone's server. On 10/17/2017 5:43 PM, Mike Hammett wrote: <blockquote> I think the point is that if it runs on your server or runs on my server doesn't make much difference from the software management perspective, but it plays a big part of business continuity. I'd imagine most people on a MRC-based billing\OSS platform would migrate to a new one, but doing it over a few months because you can vs. tomorrow because you have to makes a big difference. ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP From: "Simon Westlake" <simon@sonar.software> To: af@afmug.com Sent: Tuesday, October 17, 2017 5:39:43 PM Subject: Re: [AFMUG] Sonar And I would be amazed if a major vendor went out of business in this industry and all the competitors didn't scramble to build tools to create a seamless transition. We already have one click tools for most of our competitors to import their data into Sonar, and we're working on the rest. The challenging thing is that a lot of systems don't enforce good data consistency, so there is junk to clean up. But if push comes to shove and you're willing to clean up what you got, it can be done very quickly. I think you also have to weigh up these worst case scenarios against reality. There has yet to be a billing vendor in this industry that has stopped operating in the 7 years I've been part of it, let alone close up shop in a 24 hour period and leave everyone in the cold. Is it worth using old software that doesn't have the features you need because it offers some modicum of protection against an unlikely event? That is up to you to balance, but these doomsday scenarios are pretty unlikely, and if it's costing you a lot of efficiency and potential revenue, then my personal feeling would be that it doesn't outweigh the consequences. But everyone has to make their own risk assessment. I think you will just see acquisitions occur if a vendor gets to the point that they are struggling to operate. It would be silly for them to just disappear into the night. On 10/17/2017 4:15 PM, ch...@wbmfg.com wrote: <blockquote> Been through this many times in my life. Done it both ways. Several times. Prefer the new vendor to do onboarding for me. You get what you pay for. From: Nathan Anderson Sent: Tuesday, October 17, 2017 3:11 PM To: af@afmug.com Subject: Re: [AFMUG] Sonar Not true. It doesn't matter what the file format of the export is: you still have to take the time to figure out how to shoehorn data from one schema into another. As talked about earlier, maybe you'll get support from your new vendor with that, maybe not. There will be mistakes made during that process, and some of it will have to be re-done. You also have to hook the new product into all of your authentication systems and then test that to make sure it works and doesn't suddenly break people's connections. Then there will be the mistakes that come from actually using the new software that you are unfamiliar with, and/or cajoling it to do what you need it to do and which you already knew how to do with the old software. People will get billed wrong for a while and then you'll have to sort out that mess as your customers bring the billing mistakes to your attention. Some people that need to get billed won't be...others will get double-billed. Pro-rates will get miscalculated. The system will on-hold somebody by mistake that shouldn't have been. And on and on. If the software is locally hosted, you can learn a new system and transition over to it on your own schedule, instead of being pushed into the deep end of the pool on day 1. -- Nathan From: Af [ mailto:af-boun...@afmug.com ] On Behalf Of ch...@wbmfg.com Sent: Tuesday, October 17, 2017 2:04 PM To: af@afmug.com Subject: Re: [AFMUG] Sonar Export backups as CSV and you can re-import it into any database. You will only be screwed for a very short time. From: Nathan Anderson Sent: Tuesday, October 17, 2017 2:13 PM To: af@afmug.com Subject: Re: [AFMUG] Sonar I have to say that I'm partially with Matt on this one. It's really not about access to your own data, although that can certainly be a component depending on how things are designed. It sounds like perhaps Sonar has no problem giving you reasonable access to exports of your data for you to backup yourself, and for the moment, I'm going to give them the benefit of the doubt on this. I don't think I have to convince anyone how critical billing software is to an organization. If it screws up or stops working, you are losing money, and fast. The SaaS model has some clear benefits to both parties (developer and user), but it has an equal number of new downsides as well. One big-E-on-the-eyechart one is what happens if the product is discontinued, either because the parent company/developers go out of business or for some other reason. In the traditional software licensing and hosting model, where you use your own computing resources to execute the code, if the development company goes out of business one day, the software that you still possess a copy of does not suddenly become less useful to you. Sure, you won't get future upgrades and fixes to the product from the vendor, but at least you have some time to figure out what your options are and how you want to proceed, and you can migrate to a new platform on YOUR OWN timetable, not someone else's. And in the meantime, your business operations are not negatively impacted. In the SaaS model, it doesn't matter if you have a complete, unabridged, and up-to-date export of the data: when the product is discontinued without warning, and the company shuts down the software servers, YOU ARE SO SCREWED. That data export does you zero good if you don't have product to process and interpret and act on it. In the case of billing software, this means you are not collecting payments for service from your customers, which is a big problem. Even if you could find a suitable replacement for the software the next day, you still have to figure out how to massage the data export you do have so that the new software can import it, work through the inevitable imperfections of that import (certain fields from the export that don't map cleanly to fields in the new product), learn a new piece of software from scratch, and figure out how to get by or work around issues resulting from "feature X" that you depended heavily on in the old software but which no longer exists in any form in the new one. Things WILL be complete chaos for a while; there's no way around this. We are actively looking for a new billing platform, and in the meantime we have been running a piece of software that we bought and implemented back when it was in active development but which has now been discontinued for years. The reason that this is even possible is because it is self-hosted. Back when this product was being developed, it was very popular and sold very well. Nothing is "too big to fail"... nothing . Heck, Google has shitcanned their fair share of services over the years after deeming them inviable, leaving devoted users of them high-and-dry. That we have personally experienced having a billing software vendor go belly-up gives us great pause when it comes to evaluating our options in the hosted/cloud space. This is not to say that we would never consider billing-in-the-cloud, but it would have to be awfully compelling, and I think it would greatly help if there were certain guarantees in place. One example would be if the developer held the source code of the software in escrow, to be automatically released if a "dead man's switch" were tripped. I suspect this is what Matt has in mind when he talks about "contracts" -- they are not just about protecting the seller, but about protecting both parties. -- Nathan From: Af [ mailto:af-boun...@afmug.com ] On Behalf Of Matt Hoppes Sent: Tuesday, October 17, 2017 11:37 AM To: af@afmug.com Subject: Re: [AFMUG] Sonar Local install. On Oct 17, 2017, at 13:32, Josh Reynolds < j...@kyneticwifi.com > wrote: <blockquote> Good luck with that. Any company could close up shop today, and if they are bankrupt, they are bankrupt. On Oct 17, 2017 12:27 PM, "Matt Hoppes" < mattli...@rivervalleyinternet.net > wrote: It also means at any point they can just close up shop leaving my data and my customer information high and dry with no recourse. On Oct 17, 2017, at 13:24, Josh Reynolds < j...@kyneticwifi.com > wrote: <blockquote> They provide enough value to avoid locking you in a contract that would otherwise retain your business when they don't continuously earn it. Others are NOT the same. On Oct 17, 2017 12:22 PM, "Matt Hoppes" < mattli...@rivervalleyinternet.net > wrote: <blockquote> No contract? That's frankly beyond scary. On Oct 17, 2017, at 13:06, Adam Moffett < dmmoff...@gmail.com > wrote: <blockquote> Sonar is strictly per user with no contract, so if you haven't migrated any users in yet then you pay the minimum.....which I think is $100/month. ------ Original Message ------ From: "Matt Hoppes" < mattli...@rivervalleyinternet.net > To: af@afmug.com Sent: 10/17/2017 9:16:46 AM Subject: Re: [AFMUG] Sonar <blockquote> Fail. On Oct 17, 2017, at 08:54, Lewis Bergman < lewis.berg...@gmail.com > wrote: <blockquote> Many of them start charging you regardless if you are on their system yet. Once you sign the contract, you start paying. On Mon, Oct 16, 2017 at 6:00 PM Nathan Anderson < nath...@fsr.com > wrote: <blockquote> I can understand this if the product in question is purchased/licensed for a one-time upfront fee. However, if you have a SaaS model with recurring revenues, it seems like it would be in your best interest to help the customer move existing data over to your product cost-free, and thus get them to be a paying customer ASAP. -- Nathan From: Af < af-boun...@afmug.com > on behalf of Lewis Bergman < lewis.berg...@gmail.com > Sent: Monday, October 16, 2017 3:36 PM To: af@afmug.com Subject: Re: [AFMUG] Sonar Yea, this seems to be a common practice in the software industry. What they all should really say is that they help you convert. I am going through this with ECi at the moment. We paid several thousand for them to convert our database. What it really was was a half hearted gesture at putting the DB into an excel spreadsheet that they spent zero time checking for sanity. They expect us to do all that. It seems that most software companies expect their customers to have a whole team of people doing what seems to be the software companies job. Not saying Sonar fits the description, just that that seems to be the rule not the exception. On Mon, Oct 16, 2017 at 5:24 PM Sterling Jacobson < sterl...@avative.net > wrote: <blockquote> Taking forever to migrate from Platypus to Sonar. I was told conversion was free, but they didn't tell me I had to do all my own conversion from Plat to Sonar, so in my mind that's not free. I paid Spender Lambert to move some initial data to their format, but I've been on a hold with Sonar since last month. Super excited to get going with a 'modern' billing system, but so far the process has been a total snoozer. </blockquote> </blockquote> </blockquote> </blockquote> </blockquote> </blockquote> </blockquote> </blockquote> </blockquote> </blockquote> ... </blockquote>
