The new Tesla Model 3 is cheaper than the Model S. Is that Tesla encouraging people to migrate to the
Model 3?
They're not the same product, and in this case they serve different points in the space with different underlying requirements. App Engine Standard's cost structure on the backend just hasn't changed nearly as much as compute engine's lately where it's a much more direct: oh look Haswell released, more cores per host at similar dollars yields less $$/core.
Disclosure: I work on Cloud (Compute Engine mostly) and care a lot about our prices.
The issue reported here is linked to App Engine and Gmail tightening up their spam filters. The root cause was an increase in organizations sharding out their spam systems to utilize App Engine’s free tier in such a way that is (a) in direct violation of our ToS and (b) making all of our lives suck a bit more (raise your hand if you want spam). It’s unfortunate that while App Engine is trying to provide a free tier that enables developers to easily use our platform, others see it as an opportunity for exploitation. Even more unfortunate is that it has a negative effect on legitimate users. It’s a fine balance that has been highlighted by several users within this thread.
Spam filtering is not a perfect science, and we’re constantly tweaking things -- with our customers in mind. This issue should be limited to new applications where the trust signal might be a bit lower. Thus existing apps / customers shouldn’t be experiencing issues (which was also highlighted by a few within this thread). If this isn’t the case email me: [email protected]. For those asking, “hey, why am I being penalized for being a new customer?” See my previous comment about spam filtering not being a perfect science. Then email me.
Just a quick thank you for the free tier that App Engine offers. I use it to provide an educational app for my wife, who's a teacher, that she uses as part of her classes. It's nice to be able to provide that to her and her class, without hitting the bank (the school does that enough...). So, thank you.
Long time App Engine user here. If you're sending email as part of your app, I'd recommend using Mailgun (or similar services). You can set up DKIM, inbound routes, etc, and generally have more control over how your mail is processed. I never got the impression App Engine really wanted to be in the email delivery business, so if that's important to you, there are tools that are focused on that (and free up to a monthly quota). My $0.02.
Love Mailgun. You can configure it to just be a very easy mail provider or use the APIs to send mail and turn on all kinds of things like campaign monitoring, tags, click opens, etc.
The best part for me when using it for customers has been the bounce/click through rate tracking. When someone asks me, "how do I know they got it?" It's incredibly nice to point them to
the dashboard and show a less than 1% bounce rate (people putting in bad email is almost always the reason) with a log of every single email sent.
Most my clients get this service for free because their volume us low enough. They have quite a generous free tier.
+1 as well, after the changes to Mandrill recently, was looking for a new provider and can also recommend Mailgun (at least, for ease and configurability in set up and testing so far, not yet in production).
Yes, Mandrill should have kept the free quota after DKIM and SPF verification. Now, I will be trying out the competitors (Sendgrid and Mailgun) and if I find them at par with Mandrill then for paid projects, I might use them rather than Mandrill.
For our clients, the appeal of Mandrill is the Mailchimp Template Editor. I think this is where their focus is going and so if you don't need that, then definitely check out competitors.
Out of around 18 projects, in which we have used Mandrill, only in 1 we have used the template editor. (I think only about half went for paid accounts when the project went live.) Most of our need was simple and quick transactional messages (Registration, Forgot Password, etc.). The main reason we chose Mandrill was ease of set up over Amazon SES. (Even though we had AWS accounts for all projects.)
Anyways, it's up to Mandrill to choose who they want to serve. I really liked the service though. Best of Luck.
Thanks for the suggestion! I was having issues with SendGrid and had never heard of Mailgun. Took literally 2 minutes to get set up on Mailgun, add the credentials to my app, and send my first email! It's a super small app so don't need anything fancy, Mailgun is perfect.
edit: Not to say Mailgun isn't fancy, I have no idea if it is or not, I can say that it works in minutes though.
> This issue should be limited to new applications where the trust signal might be a bit lower. Thus existing apps / customers shouldn’t be experiencing issues.
1. My app is not new. It's been running without issue for 2 or 3 years.
2. My app is not on the free tier.
3. On average, my app sends out under 8 emails a day, and it's done the same for over 2 years.
How your algorithm considers my app a spam risk sure beats me.
I'm missing 11 days worth of quote requests from customers. Are these recoverable? (is there a hidden outgoing-spam bin?)
Possible reason that email service providers and other email sending services might see an increase in new signups and free tier use recently: http://blog.mandrill.com/important-changes-to-mandrill.html Mandrill in essence raised their price, eliminated free tier, and required prepurchased blocks of sending capacity IIRC
The numbers Mandrill released about that business suggest that they had a large number of low volume senders, who may now be looking for a new home.
As an email service provider it's like that and more, since (1) once an abuser uses your service, they've gotten the benefit immediately and keep it even if their account is discovered as fraudulent later, e.g. stolen CC number & chargeback. (2) Abusive users can directly harm good users such as by harming the deliverability of the overall platform. It's not just bad debt, it's bad experience too. (3) Unlike Candy Japan where fraudsters mostly just wanted to check CC numbers and not actually buy product, email abusers really want to send emails (4) It can be hard to tell good and bad senders apart because some companies with an internet presence aren't email savvy and might make mistakes or might get hacked.
Spam filters are always tough because if you give someone transparency into which actions of theirs that you consider abuse, then they will quickly detect and route around your attempt to block them. (See Candy Japan article) It's pretty easy for a human to guess what might be the sign of their fraud and run a few experiments to see what gets flagged e.g. By comparison a machine learning system might be hard to outsmart, but then it's also challenging to explain and troubleshoot false positives. Hence what's effective is often a combination of machine-learned filters and heuristics along with manual overrides by human judgment.
All other things equal, new users are a lot more likely to engage in fraud than existing ones, and so tend to be under more suspicion. Aside from B2B fraud where companies take out lines of credit and then go bankrupt intentionally, it's uncommon for existing established customers to turn fraudulent - they're already vetted. (Consider: who is more likely to be fraudulent. The first time subscriber to Candy Japan, or a subscriber who has been using it for 12 months and is about to buy their 13th month?) It's not a great experience as a new user to be under suspicion, but if it's temporary and easily overridden by a human it can be a decent trade-off - the need to reach out acts a deterrent to spammers but does not deter legitimate users as much (speaking generally).
Chris, you say Gmail tightened up their spam filters... Did this take place in the last ~6 weeks or so?
I've noticed the spam filter on Gmail for Google Apps has gotten significantly less accurate recently, resulting in far more false-positives than usual. Any ideas if this is a known issue? I can only presume it's more accurate overall, but it was definitely a noticeable change for our organisation.
To your first point though, streaming services typically are more focused on storage and egress (network) optimizations. App Engine has integration points with each, but its core workloads fall more in the dynamic web app and mobile backend realm. Within Spotify's architecture, there are places where App Engine makes sense (e.g. hosting their frontend APIs). That said, this is small relative to the rest of their architecture and understandably isn't the first area of focus when you're making a move to a new vendor.
True that Google stills uses it internally, but external usage exists way beyond Snapchat (although they are a fun customer). App Engine hasn't been in maintenance mode, although we have set aside engineering cycles to improve the reliability and stability of the service in order to ensure the highest level of support for production-grade customers. In tandem, we've some large features such Go, PHP, full-text search, and Cloud Storage support. We've added integration with the Cloud Console as well as Cloud SDK to allow developers to build hybrid solutions that span, for example, App Engine and Compute Engine. And, yes, we've invested in the App Engine Managed VM environment with a host of new runtimes including Java 8, Python 3, Go, PHP, and Node.js. We have more coming there over the next 2-3 months. Guido leaving was tough, I used to share an office with him. That said, I'm not sure that his exit was the writing on the wall.
Disclaimer: I'm the lead for the App Engine product team.
Google Drive / apps script integration is a great idea. Unifying our storage offerings across the entire company is a great idea too (but an aside for this conversation). I disagree with the "get something out" mentality, though. Shipping a fully managed runtime that scales as well as Java, Python, and Go, that is hardened, and is secure enough that we'll run it next to Gmail, Search, Geo, etc. is no easy task. It's not something you decide to do on a whim a few weeks before i/o.
For many applications they require a CMS and PHP clearly owns the market space here with Wordpress and Drupal -- strategic in terms of driving growth and new business. We also believe that since App Engine was built with multitenancy in mind from day one that it's a more secure, hardened environment -- better for developers. Finally, and to my point above, the majority of the internet has been built with PHP whether folks like it or not. We want to bring the benefits of cloud to this large corpus of developers -- advancing computing rather than stagnating it.
Our goal is to advance computing (via services such as HRD, Cloud Datastore, BigQuery, and Go) in ways that align with existing developer practices (investments in Java and now the release of PHP). There's no point in releasing amazing solutions if there is a huge barrier to entry.
Which customers are you going after? People who want to play around with "hello worlds" with PHP or people who actually build powerful stuff.
Either case, help me understand why PHP was a better choice vs. Javascript? If the question is barrier to entry. Then javascript should have the lowest. Anyone doing any web development needs to do something in HTML/Javascript/CSS.
Additionally you could have made the case for further integration with your other services like App Scripts. Aren't google team talk to each other?
I personally would have rather seen Google focus on Go and remove "experimental" out of Go so people feel some amount of security developing and investing time building Go applications on GAE. Just my $.02!
I'm assuming that you're actually talking about Node and not just HTML + JS. Ultimately it wasn't a choice to do one and not the other, it was a choice of which to tackle first (and PHP had some technical advantages which allowed us to move faster). Ultimately we want to surface, or allow others to surface, any runtime in a fully managed way. Yes, Node, Ruby, C# are often discussed (as are many others, including moving Go to GA). We're investing, we'll get there, and this is only the first of many steps.
I don't necessarily mean Node, but serverside javascript. I don't really care for the event notification process of Node. It has its place and for many tasks it probably is the best solution. However for most web apps its probably simpler not to worry about it.
Yes, PHP is only used for amateur useless projects like Facebook, Wikipedia, Drupal, WordPress ... Our projects on the other hand are too important for this low brow language.
All the stuff you are talking about are valid examples, but they are from 5-10 years ago. None of these probably will be built on PHP again. I can use the same reasoning and list some major critical applications and argue for Cobol, Fortan, etc. But it doesn't mean it's forward thinking.
We get requests for PHP all the time. In Urs' presentation today, the audience response at I/O was the strongest for three things specifically - open signups for GCE, sub-hour GCE billing, and GAE support for PHP.
Slamming PHP is akin to slamming the x86 instruction set. It's besides the point. There are so many large "apps" that effectively use PHP as asm; we need to have a solution for customers that want to run open source CMS:es and CRM:s, for example, and this is all Wordpress, Drupal, SugarCRM, MediaWiki, Joomla etc.
And there are a LOT of startup companies building in PHP, believe it or not. PHP on the server is akin to Javascript on the client. You can argue that Erlang or Go is better, fine, but the reality is that most web sites are PHP. And similar to what happened with V8, there is a significant industry effort in just accepting this and making PHP run faster and better. We don't want you to compare GAE/PHP with GAE/language_X. You should compare GAE/PHP with [other platform]/PHP, and see if you like what we've done. And we're doing some cool stuff with it. We are working to support PHP code better than any alternative. We expect PHP developers to love it. But we're not doing it in order to advocate (or not advocate) PHP per se. You don't like PHP? Then move along, there's nothing to see here.
And as for the "small $5-6 dollar sites" (or free), that doesn't matter. Many of the apps running on GAE are within the free tier, which is one of the great things about the platform. So that's not news. Part of the GAE vision has always been to offer a place on the web to run small web apps for free.
While PHP has low barrier to entry and there are a lot of people who tinker with it, PHP still powers a lot of production websites, far and beyond the hello world apps or the 'pictures of my dog' wordpress blogs. Your implication that there aren't "powerful stuff" websites running on PHP is just simply not true.
You can host HTML, javascript and CSS files to be run in the browser on GAE already, and have been able to do so since day 1.
What you can't do is run javascript server side. Given the unique requirements of server side javascript, and the fact that the single dominant implementation is maintained by a competitor in this exact space, it isn't a great fit.
> Given the unique requirements of server side javascript, and the fact that the single dominant implementation is maintained by a competitor in this exact space, it isn't a great fit.
Google already has a cloud based, server-side, javascript platform in Apps Script, and has purchased at least one company that operated a JavaScript PaaS, so its not like doing JavaScript serverside is out of Google's reach if they strategically wanted to do it.
I can see why, given the mass of PHP apps out there, PHP might be a priority for App Engine given what App Engine already supports, but I can't see JavaScript as having a significant barrier to practicality.
-- Chris