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. >> >> ... > > >
