Interestingly, I think we're seeing less people grow up with general purpose computers, and instead just have an iPad or an android tablet, or a chromebook.
At least chromebooks have the capacity to become general purpose computers by installing Linux. But yeah, anyone who doesn't grow up with a Raspberry Pi or the like is gonna have a hard time.
Not the OP, but the people I've seen this do it DIY have all done it with Ubiquiti products. A single link can get a mile of range with clear LoS. Depending on how far out you are, that lets you connect to a "real" internet connection for cheap.
Mikrotik products are very popular among people running WISPs, and their product range reflects this, with a whole range designed specifically for that purpose.
Even their standard wall/ceiling-mount AP is weatherproof and comes with pole mount attachments.
One thing you may encounter is that a large company may be using it for many things internally, and that still shows up as just a handful of clones, because they have some central artifact caching service in place.
Essentially this is a way to lets you push all of the weird feature requests your customers might have off into one place.
From a customer point of view, maybe you need to rewrite the path based on the contents of a cookie, or maybe you want to shed certain types of requests in high load scenarios, or maybe there's a buggy upstream application that sends bad cache-control headers, or ...
If the goal is to let the customer specify infinitely complex logic at the edge, a programming language is a good way to do that. Function As A Service is a good billing model for lots of invocations of short, small functions across the customers choice of language.
The unfortunate side effect is that Lambda@Edge at least adds quite a bit of latency that a simpler but less powerful rules based system for header manipulation probably wouldn't.
We experimented with using Lambda@Edge for manipulating a header, but the added latency just wasn't worth it, and we had to come up with a different solution. That was years ago though, so maybe it is better now.
Why not start out by using the Django Admin features?
That allows you to start with next to no code, but you can easily add a little business logic anywhere you need it eventually, and it provides a way to long term transition to a true application if the need arises.
You just install that, add the TODOs that it says, and then run it with "./manage.py migrate; ./manage.py createsuperuser; ./manage.py runserver", and that's about it.
I took a quick look at the README and this looks like a great resource. Docker-readiness is a nice touch. I should definitely find some time for trying this out. Thank you for the advice, Stavros!
I find answers in this format annoying. Why not? Maybe he's never heard of it. Great answer, but let's not assume he's considered it and decided not to.
I think you came across as friendly and helpful. To me "why not" is a gentle suggestion, and not a literal question. Maybe that changes in different parts of the world?
Colloquially "Why not?" is used to make a suggestion. That is, "Why not" means "Perhaps". One need not trace or question preceding statements or ideas nor is there any need to be annoyed.
Facebook will be pitching to your Marketing folks that's exactly where you need it.
Facebook want data on what actions users took before signing up, which users actually signed up and started paying, and how that relates to revenue. This UI is exactly where they can determine these types of actions.
Whether this actually makes Facebook better at marketing or not is a good question.
That's why it's a killer mistake to let "marketing folk" dictate _anything_ that has to do with the app. They can suggest, but not dictate. If this points to anything it'd the dysfunctional development process at Backblaze.
At my job, we evaluated moving from AWS hosted ES to several of the Elastic offerings. Many of them were more expensive than AWS was before taking hardware into account (as in comparing cost of Elastic licensing vs the whole cost from AWS). This made it exceedingly difficult to justify the move. It's not only the headstart with the client (billing relationship in place), but the cost that hampers them.
But isn't a big part of the reason Amazon can offer better pricing because of the scale of their existing client base? I'm not saying that they are doing this, but they could if they chose operate on very thin margins or even at a lost to keep their hold on clients and make up with it on other products in their ecosystem.
Hmm. Operating on thin margins to gain market share and drive competitors out of business, then making up the difference by creating sales in related businesses in their ecosystem doesn't sound much like Amazon...
In my experience it is that Elastic does not understand the market.
About four years ago we have attempted to get their software . It felt like I was dealing with Cisco sales people circa 1998. They were clueless on how to do a multi hundred thousand dollar deal - think slow, inefficient, inflexible, unwilling to compromise on extra $500 add on that would have ended up being a rounding error.
That's how it is for a lot of companies, not just Elastic. We have to deal with jfrog, who has separate billing teams for SaaS and on-prem so for us to switch from on-prem to SaaS is a pain in the ass. If AWS ever offers artifacts storage with more artifact types, then obviously we're switching. And that's just 100% so we don't have to deal with jfrog's dumb ass contracts anymore, never mind pricing.
ugh the pain that comes from negotiating our contract every year. Or the pain that comes from trying to get trial licenses. Or the pain we're seeing now from switching to SaaS.
And that's why AWS eats their lunch. Execs of Elastic ( and other companies ) should deal with their inept sales force rather than point fingers at AWS.
If dollars have no value, you should be willing to give away any dollars you have to anyone, no matter how they are using them, right?
Dollars don't have a direct value in gold, but there are people willing to take your dollars and exchange them for gold, it's just a ratio that varies over time, along with the value of gold and dollars.
