61–70 of 105 posts
With that said, there has been plenty of support to be handled, and we need to get better at doing multi-node deploys, but we're learning. :)
Earlier quoted context omitted.
Depends on the customer. Often, the motivations that push them to demand on-prem can be fulfilled just as well by a less-demanding single-tenant SaaS solution; you just have to convince the customer's IT department that such a thing exists. Sure, there are some (mostly in defense, finance, and a few other security-sensitive fields) where physical on-prem is non-negotiable, but in my experience customer demands for on…
If you're big, AWS is a huge waste of money.
CoreOS actually makes this significantly better with their Cloud Config capabilities. With CoreOS and Docker, we've successfully deployed this at a number of companies. With that said, there has been plenty of support to be handled, and we need to get better at doing multi-node deploys, but we're learning. :)
In one extreme case, we had to install on SLES 10 (in 2014), without root or sudo, and then hand over the machines, since we weren't allowed direct access to the production system. And maintenance involved sitting with one of their sysadmins and telling him what to do :)
Earlier quoted context omitted.
Depends on the customer. Often, the motivations that push them to demand on-prem can be fulfilled just as well by a less-demanding single-tenant SaaS solution; you just have to convince the customer's IT department that such a thing exists. Sure, there are some (mostly in defense, finance, and a few other security-sensitive fields) where physical on-prem is non-negotiable, but in my experience customer demands for on…
What you're describing is a private, separated installation on the Internet. In all cases "on-prem" is inside of a customer's datacenter/office.
The quality of this is tested once the customer wants to upgrade his system from version X to version Y.
Earlier quoted context omitted.
If you're big and are a typical company bad at IT, AWS is a massive cost savings. Most HN readers probably aren't very familiar with the costing and the line item levels of bureaucracy in Fortune 500 enterprise IT that makes AWS bills of $200k / mo for maybe 10 lightweight websites ( These companies want to buy software to throw over the fence to the same people and processes because they've invested decades in their…
I don't see how a company terrible at managing IT will magically improve with AWS. Maybe they won't get killed as badly by EMC and shift wastage to various AWS services. I'm not knocking Amazon -- just saying that you can deliver most enterprise workloads cheaper.
And that is the market they're going for - note that the free trial is 25 users. This is not a product for the small company that just doesn't have the capital to invest in their homegrown solution - that's Google Apps for Work.
As a consumer of a number of on-prem installs, I'd just like to add something positive in what will probably be a lot of negativity regarding selling your product on-prem. The on-prem situation is evolving just as the SaaS/cloud world is evolving as well. Selling an on-prem product can be very lucrative if done correctly, and that can mean intentionally not selling to customers who don't have their act together. As m…
It was, however, a long migration for both Atlassian and the add-on vendors. It was necessary because the market wants to try products withut installing them. Now Atlassian is able to make cloud-level changes to their software: They can use CD, live analytics, mutualized authentication for all tenants, etc.
However, their API for cloud addons is, and will be forever, completely different from the API for onpremise addons. It's a major difficulty for the ecosystem. Many vendors extract a .jar that they reuse in both onpremise and cloud addons, but the cloud runtime that connects this .jar to the cloud API is at least as big as the jar itself (because we don't benefit from the host's services such as user management, storage or logging).
OnPromise, which we started with, was however easier for us than Cloud. The customers, even enterprise ones (we have about 28 of them) are in charge of Ops, it cuts off half the work for us. And OnPromise is 3x more revenue for us per year, with the downside that it's a one-off, non-recurrent sale by default.
Earlier quoted context omitted.
I don't see how a company terrible at managing IT will magically improve with AWS. Maybe they won't get killed as badly by EMC and shift wastage to various AWS services. I'm not knocking Amazon -- just saying that you can deliver most enterprise workloads cheaper.
Because they will be outsourcing a big chunk of that work they do inefficiently (backups, monitoring, provisioning, etc.) to Amazon, which is much better at it. Hence the proliferation of things like hosted AWS Outlook system [1]. Anyone in our Bay Area bubble of efficient IT would say keeping that running for a 2,000-user business is probably... what, a half of a full-time-equivalent of workload, averaged over long…
And that's just pure cost. If you're in the Bay Area bubble, you probably have much more valuable things for your systems guys to work on.
Point being, even for a Bay Area company, even at twice the pure cost of personnel, this looks like a pretty good deal.