All good, just didn't want you overlooking that initial post.
Josh Luthman Office: 937-552-2340 Direct: 937-552-2343 1100 Wayne St Suite 1337 Troy, OH 45373 On Tue, Oct 17, 2017 at 9:09 PM, Simon Westlake <[email protected]> wrote: > Never ends up being that simple, but yes, we've made a business decision > not to. > > On Oct 17, 2017 6:33 PM, "Mike Hammett" <[email protected]> wrote: > >> 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 <http://www.ics-il.com/> >> <https://www.facebook.com/ICSIL> >> <https://plus.google.com/+IntelligentComputingSolutionsDeKalb> >> <https://www.linkedin.com/company/intelligent-computing-solutions> >> <https://twitter.com/ICSIL> >> Midwest Internet Exchange <http://www.midwest-ix.com/> >> <https://www.facebook.com/mdwestix> >> <https://www.linkedin.com/company/midwest-internet-exchange> >> <https://twitter.com/mdwestix> >> The Brothers WISP <http://www.thebrotherswisp.com/> >> <https://www.facebook.com/thebrotherswisp> >> >> >> <https://www.youtube.com/channel/UCXSdfxQv7SpoRQYNyLwntZg> >> ------------------------------ >> *From: *"Simon Westlake" <[email protected]> >> *To: *[email protected] >> *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" <[email protected]> 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 <http://www.ics-il.com/> >>> <https://www.facebook.com/ICSIL> >>> <https://plus.google.com/+IntelligentComputingSolutionsDeKalb> >>> <https://www.linkedin.com/company/intelligent-computing-solutions> >>> <https://twitter.com/ICSIL> >>> Midwest Internet Exchange <http://www.midwest-ix.com/> >>> <https://www.facebook.com/mdwestix> >>> <https://www.linkedin.com/company/midwest-internet-exchange> >>> <https://twitter.com/mdwestix> >>> The Brothers WISP <http://www.thebrotherswisp.com/> >>> <https://www.facebook.com/thebrotherswisp> >>> >>> >>> <https://www.youtube.com/channel/UCXSdfxQv7SpoRQYNyLwntZg> >>> ------------------------------ >>> *From: *"Simon Westlake" <[email protected]> >>> *To: *[email protected] >>> *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: >>> >>> So don't do that? :-p >>> >>> >>> >>> ----- >>> Mike Hammett >>> Intelligent Computing Solutions <http://www.ics-il.com/> >>> <https://www.facebook.com/ICSIL> >>> <https://plus.google.com/+IntelligentComputingSolutionsDeKalb> >>> <https://www.linkedin.com/company/intelligent-computing-solutions> >>> <https://twitter.com/ICSIL> >>> Midwest Internet Exchange <http://www.midwest-ix.com/> >>> <https://www.facebook.com/mdwestix> >>> <https://www.linkedin.com/company/midwest-internet-exchange> >>> <https://twitter.com/mdwestix> >>> The Brothers WISP <http://www.thebrotherswisp.com/> >>> <https://www.facebook.com/thebrotherswisp> >>> >>> >>> <https://www.youtube.com/channel/UCXSdfxQv7SpoRQYNyLwntZg> >>> ------------------------------ >>> *From: *"Simon Westlake" <[email protected]> <[email protected]> >>> *To: *[email protected] >>> *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: >>> >>> 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 <http://www.ics-il.com/> >>> <https://www.facebook.com/ICSIL> >>> <https://plus.google.com/+IntelligentComputingSolutionsDeKalb> >>> <https://www.linkedin.com/company/intelligent-computing-solutions> >>> <https://twitter.com/ICSIL> >>> Midwest Internet Exchange <http://www.midwest-ix.com/> >>> <https://www.facebook.com/mdwestix> >>> <https://www.linkedin.com/company/midwest-internet-exchange> >>> <https://twitter.com/mdwestix> >>> The Brothers WISP <http://www.thebrotherswisp.com/> >>> <https://www.facebook.com/thebrotherswisp> >>> >>> >>> <https://www.youtube.com/channel/UCXSdfxQv7SpoRQYNyLwntZg> >>> ------------------------------ >>> *From: *"Simon Westlake" <[email protected]> <[email protected]> >>> *To: *[email protected] >>> *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, [email protected] wrote: >>> >>> 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:* [email protected] >>> *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:[email protected] <[email protected]>] *On >>> Behalf Of *[email protected] >>> *Sent:* Tuesday, October 17, 2017 2:04 PM >>> *To:* [email protected] >>> *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:* [email protected] >>> >>> *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:[email protected]] *On Behalf Of *Matt Hoppes >>> *Sent:* Tuesday, October 17, 2017 11:37 AM >>> *To:* [email protected] >>> *Subject:* Re: [AFMUG] Sonar >>> >>> >>> >>> Local install. >>> >>> >>> On Oct 17, 2017, at 13:32, Josh Reynolds <[email protected]> wrote: >>> >>> 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" <mattlists@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 <[email protected]> wrote: >>> >>> 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" <mattlists@rivervalleyinternet >>> .net> wrote: >>> >>> No contract? That's frankly beyond scary. >>> >>> >>> On Oct 17, 2017, at 13:06, Adam Moffett <[email protected]> wrote: >>> >>> 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" <[email protected]> >>> >>> To: [email protected] >>> >>> Sent: 10/17/2017 9:16:46 AM >>> >>> Subject: Re: [AFMUG] Sonar >>> >>> >>> >>> Fail. >>> >>> >>> On Oct 17, 2017, at 08:54, Lewis Bergman <[email protected]> >>> wrote: >>> >>> 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 <[email protected]> wrote: >>> >>> 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 <[email protected]> on behalf of Lewis Bergman < >>> [email protected]> >>> *Sent:* Monday, October 16, 2017 3:36 PM >>> *To:* [email protected] >>> *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 <[email protected]> >>> wrote: >>> >>> 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. >>> >>> ... >> >> >>
