I don't understand how this could be flagged as a dupe. I agree both articles cover Portainer.
But one goes deep into how to set it up with deep integration on Docker Machine and DigitalOcean on a more expert level.
While the other provides a very simple beginner level Play with Docker setup and then goes on how to install an entire application stack, with frontends, databases and workers.
Yeah, the gist of the article was just to show some of the capabilities. In essence, Portainer is just a wrapper around the Docker API. So I wouldn't use it as a management tool, much rather as a quick and dirty checkup tool.
I only read TC when their linkbait titles end up on the frontpage of HN.
Stopped following their feed, once I came to the same conclusion as the OP: being overly funded is (almost) the only way to go get featured on TC, these days. The times of roaming the edges of startup-land and posting about the nitty gritty startup struggles are long forgotten.
There are 2 options which I use(d) when developing/deploying DynamoDB:
- Have a separate (sub)account for dev/test/... in which you create your tables. Since one of the latest changes to their policy you are now able to configure the lowest read/write capacity possible: 1/1
- Join everything under one account but prefix your tables with dev_, test_, prod_*
I prefer the former as it enables me to have the dev/test env as similar as possible to the prod environment: same naming, and both env's are separated, when one gets compromised at least the other one doesn't suffer. Security rules are also easier as you don't have to create per-table rules, when you want to lock out some team-members from production tables, but not dev/test tables.
Digging further in 3), if your app is proven to be in the 'good' quadrant, have you ever considered contacting Twitter directly and requesting a higher API limit rate.
I can imagine they are ok with that if your app provides value to their ecosystem.
well i constantly mention the issue through their bug reports and discussions, they acknowledge it and promised to talk to the team about re-evaluating the way things are handled now, but I'd assume this means it's not a priority.
i tried signing up through one of their partner thing forms but as expected, no response.
Couldn't have said it any better. Being TC'ed is cool to put on your websites homepage (I know, we did ;)), but appart from having a huge spike in your Google Analytics dashboard, the direct results/conversions are minimal(especially for B2B products).
On the other end, it might get you a little extra cred to prove your rising traction.
Better to go for more specialized blogs, they are better for overall conversion.
As a current customer of Recurly, I am very dissapointed in the way they communicate. I know it's all hands on deck now to fix this problem, but putting communication aside is not the way to go.
For us this is also a very stressful situation, because if the worst case scenario becomes a reality...
"Some customers will be required to reach out to (some or all) of their customers to have them re-enter billing information."
... we can spend days contacting clients to get the payment credit card (which in some cases they should go to their boss for), and go through the billing process again, only to hope to get the list as near to a 100% recovered as possible.
This is nothing new. In higher risk industries, spreading risk over multiple billing providers is a fact of life. Like any system, if you rely on a single point of failure, then you are electing to take that risk. It's part of the price you pay for not having to deal with all the various requirements of PCI Compliance, as well as actually managing all the billing. The freedom to move from one biller to another biller seamlessly comes at a cost.
It's not an easy problem to solve, regardless. Not from a technical standpoint, mind you.
How do you spread billing across multiple providers if you don't yourself have PCI compliance to retain billing information? I guess you could seed it to multiple systems when the customer first provides it, but that's tricky without momentarily holding the billing information yourself, too. (I mean, you can cheat...) You can't really do paypal + google checkout + a real payment option all transparently to the user, though; you have to give them a way to pick and they may need to re-enter details.
The only way I've seen this done was segmenting by cohort or product -- i.e. recurring billing on one platform and one off billing on another.
I have seem multiple payment providers where you capture billing information each time, or where you are PCI compliant and keep the billing information yourself.
> How do you spread billing across multiple providers if you don't yourself have PCI compliance to retain billing information?
You become PCI compliant! That's the price you pay. Or you ignore PCI compliance and risk it. You probably wouldn't be surprised to learn that this is far more common then people will admit (and I'm not even talking about people in high-risk industries).
Anyways, there are a few ways you can do this without having to deal with PCI compliance, though it doesn't solve the problem as well.
First, you set up multiple merchant accounts. That way, for a normal transaction, you might send person A to provider A, and then person B to provider B, and then person C to provider A, so on and so forth. The goal here is to spread the threat over more than one provider. You don't just allow PayPal, and if PayPal starts receiving too many transactions, you remove it as an option for a while.
If you are limited as you mention to PayPal, Google, and a real payment system, the best way there is to offer encouragement to use one system over another. Which ever system you want to encourage use of.
You can also find a PCI compliant provider who you can then attach merchant accounts to. They handle the PCI compliance, you provide the merchant accounts.
Of course, none of these solutions are really as easy as just using PayPal. But then you start to see why PayPal is so popular. It's downright easy.
Kristi answers you below (No, it's not a problem, at least, one I never experienced with any banks I ever dealt with). I will, however, say this: each bank is different. Trust contracts to define. Beyond that, get second opinions on everything. And then get contracts to back it up. You are dealing with money. Probably a lot of money. Spend the time to understand exactly what you are told. What you assume Braintree said may not be what they mean. And always get a contract.
Kristi from Braintree here. From a technical perspective, having multiple simultaneous merchant accounts shouldn't be a problem. If you'd like, shoot us some details, and we can see how we can help - support@braintreepayments.com
