This is indeed a huge problem. In the current form, it quickly become unsustainable (in terms of both time and money) for customers to work with so many subscriptions. Maybe the end state is Netflix/Prime like platform for digital news wherein the platform can share the subscription revenue across all the participating media companies depending on the usage. The argument against that is - these platforms now control what is produced, their price and distribution. Such an arrangement will eventually subvert democracy.
Our team is working on creating a micro payments platform called ana.money.
We don't see this as micropayments vs subscriptions. But micropayments & subscriptions. Media outlets (text/audio/video) will benefit from offering both these forms of payments to let customers access their content.
Our goal is to build an infrastructure that supports this worldview. We will make it incredibly easy for publishers to sell both individual articles and subscriptions: taking care of user identity, invoicing, taxation, cross border/multi-currency, etc..
I think what would be much better is a redefinition of the publisher role: Most (big) news outlets already run a lot of their own infrastructure. Web servers, this whole paywall mess, etc etc.
What if they could just provide their articles through an API (which is also consumed by their own website) and aggregators can route these articles to their users. Aggregators would become publishers of sort.
Let me flesh it out a bit.
Scenario 1) I am a subscriber of news-site1.com. I have an account with their system. I can read all their articles on their website. At the same time I browse this news-aggregator1.com. They collect lots of links, and with the power of SSO/OAuth I can already read all news-site1.com articles directly on news-aggregator1.com (since they are consuming the API with my account). Additionally I have an account with news-aggregator1.com and pay them a fee, which allows me to read N articles from any outlet they have connected with.
Scenario 2) news-aggregator2.com does not offer a subscription base, but is connected to all the APIs of the news outlets. Their users can buy on an per-article bases from all connected news outlets and the articles are saved into the user's account.
Just two scenarios how this _could_ look like. The reasons I think this is not done is 1) you lose ad traffic, which is somewhat predictable, 2) you lose predictability/control in general 3) nobody has done something like that and made it work, so there is little confidence 4) they might just be right and it only appeals to a small audience
If I am not wrong, this is what both Facebook and Apple trying to do. Both these platforms can sell individual articles but they choose not to do so due to high overhead in the payments infrastructure.
The problem in such a model is that the negotiating power of the publishers is much lower. And hence, they are always at the mercy of these aggregators. And I believe that will be the natural tendency of the aggregators, since they control the distribution.
Platforms like Scroll & Magzter are still in early times while Facebook and Apple are way ahead. All of them will invest in algorithms to surface personalised recommendations for users. They can easily tweak the algorithms to lean the way they wish to & the motivations will not always be clear since customers don't have visibility into their recommendation algorithms. And this will have a great impact on the Publisher since their revenue depends greatly on these recommendations favouring their content.
Best wishes to Stripe. They deserve to succeed. I speculate that the biggest competition for Stripe is going to be Amazon which will use AWS to rollout payments API.
For small setups, it is better to stay away from Kubernetes until it reaches a good level of stability. We jumped early on in the K8S bandwagon (before AWS EKS) and paid a steep price for that. We continue to pay. Our AWS cost has doubled since the time we transitioned to K8S from AWS Elastic Beanstalk.
I really wish I could say what would be a good time to embrace K8S, but your mileage might vary. When we made the switch, our service was at about 80TPS during regular load and would go up to 300TPS during peak load.
Regarding `avoid side-effects`, the amount of side-effects that are required for a typical real problem solving code base is quite reasonably measurable. For example, the number of network calls, DB calls, FileSystem read/writes are are measurable. Have you been able to reduce the `side-effects` significantly or have just become more aware of it?
When we started using ExpressJS (coming away from Java), there was a tremendous change. As soon as you begin to code in Javascript (say from Java/Ruby/Python world), async hits you. There is no escaping it. And the programmer faces a tax (every time when implementing async/await or generators), his/her awareness about side-effects (deliberately generalizing IO as side-effects) and they tend to be more careful with it.
Avoiding side effects sounds like something someone new to Haskell would say. Haskell in no way avoids side effects. Actually I'd say it embraces them by introducing special semantics just for them! What it does do is encourage you to move side effects to the "edge" of your code base and produce a more clean separation between pure & non-pure code. This is incredibly valuable for testing and overall correctness.
Right, and this is what I actually meant. It's not that side-effects disappear, but rather that I try not to litter my code with them. I avoid them in the sense that I don't embrace a side-effect-heavy style of coding, as I did with my imperative code prior to learning Haskell.
Perhaps I could have worded that better. Sorry for the confusion.
> Have you been able to reduce the `side-effects` significantly or have just become more aware of it?
Yes, sorry, I think I didn't explain myself very well.
Prior to learning Haskell and embracing The Way, my code was fairly covered in side-effects. I was a relatively junior programmer at this point (many years of experience because I started young, but few years of real education). Side-effects were just, you know, a thing that happened because they were "the easy way".
After learning Haskell, I became much more conscious of side-effects. I realized that a lot of things I used to do could be done without side-effects, mostly by writing better functions and thinking more deliberately about how to eschew the side-effects.
That said, it's not like they're gone. It's just that I'm much more careful about them. I "avoid" them in that I do my best not to include them, but if there's a genuine use for them then that's fine. However, I have taken to naming my functions better to reflect their side-effecting nature, and I try to move the side-effecting functions to places that make more logical sense (instead of just wherever).
I remember that before BootStrap came to the scene, we used to work with BluePrint CSS. BluePrint gave a nice canvas and concealed all the IE6 related issues. However, once Google Chrome became mainstream, it was time to move up to the next level. BootStrap emerged to the scene and completely won over so many hearts. The world is a better place because of BootStrap! Many many thanks for the team that put this together.
The article is postulating only a theory. We have seen the opposite true in credit card forms where users have to input card expiry date. No matter what sort of formatting we did, users always typed expiry wrong and our JS would point it out. We finally had to abandon input text boxes in favor of select boxes for card expiry month & year. We measured the eventual success rate and that turned out to be higher as well.
My guess is that since the scope is so narrow (1 out of 12 choices for month) and selection is very obvious, perhaps people made lesser mistakes here. Select boxes are more effective in mobiles as typing takes more effort than tapping.
This is something that is badly implemented on many, many checkout forms, partly due to using selects/dropdowns (since they conceal how the choices are formatted), but mainly because an amazing number of sites seem to think it's reasonable to offer only January, February, March instead of the 01, 02, 03 that actually appear on all credit cards. This not only stops you from focusing that element and typing to choose it, but opens up the possibility the user will choose July for 06, for example.
I was expecting this for a while now. But the pricing part isn't very clear. Is it $149 per instance or for the solution itself? Could be better if the article elaborates more on this.
High availability is the main requirement. Since we are running our hosts in AWS, we are sure that the host(s) running influx would go down certainly few times a year.
Will look more into Cassandra. Since it scales really well, it could well be worth investing time and money.
Our team is working on creating a micro payments platform called ana.money.
We don't see this as micropayments vs subscriptions. But micropayments & subscriptions. Media outlets (text/audio/video) will benefit from offering both these forms of payments to let customers access their content.
Our goal is to build an infrastructure that supports this worldview. We will make it incredibly easy for publishers to sell both individual articles and subscriptions: taking care of user identity, invoicing, taxation, cross border/multi-currency, etc..