Mail Service Deprecation?

[pdknsk]

https://cloud.google.com/appengine/docs/python/release-notes

> Google no longer accepts quota increase requests for the mail service. Customers should use Sendgrid instead.

Google will probably deprecate it soon, and close it a year later.

[Wilson MacGyver]

yea, I think we all saw this coming. 

--
You received this message because you are subscribed to the Google Groups "Google App Engine" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-appengi...@googlegroups.com.
To post to this group, send email to google-a...@googlegroups.com.
Visit this group at https://groups.google.com/group/google-appengine.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-appengine/7956feaf-8501-429f-bb05-4067662ba49c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Omnem crede diem tibi diluxisse supremum.

[Nick (Cloud Platform Support)]

Hey pdknsk,

While I can't speak on any concrete plan to deprecate, the excellent quality of SendGrid (even at the free tier), combined with our 1-year-minimum deprecation policy timeline, should reassure everyone that there's nothing significant to worry about. If this were to occur, you can rest assured as well that we'd be happy to provide migration advice to anybody needing it during the deprecation. 

Cheers!

Nick
Cloud Platform Community Support

[Joshua Smith]

Suggestion for the team: If you do decide to do this, keep your existing API and just swap in SendGrid as the underlying transport layer. Maybe we could put our SendGrid API key (or however they deal with that) into the console, or in app.yaml someplace, or something like that.

I’ve got dozens of apps on GAE, and do not relish the idea of porting them all to a different mail API. Especially since 99% of the mail sent is just error logging reports sent to me.

-Joshua

--
You received this message because you are subscribed to the Google Groups "Google App Engine" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-appengi...@googlegroups.com.
To post to this group, send email to google-a...@googlegroups.com.
Visit this group at https://groups.google.com/group/google-appengine.

To view this discussion on the web visit https://groups.google.com/d/msgid/google-appengine/6a7d9927-1924-4c87-94bc-115f0f7503d1%40googlegroups.com.

[Nick (Cloud Platform Support)]

Hey Joshua,

That's certainly an interesting idea! While I can't guarantee we'll implement it, be assured that we've heard this suggestion and will consider it. In the meantime, if a deprecation were announced, we would certainly welcome the opportunity to help as many users as possible easily migrate, in whatever form that looks like.

Cheers,

Nick
Cloud Platform Community Support 

On Monday, May 2, 2016 at 11:35:35 AM UTC-4, Joshua Smith wrote:

Suggestion for the team: If you do decide to do this, keep your existing API and just swap in SendGrid as the underlying transport layer. Maybe we could put our SendGrid API key (or however they deal with that) into the console, or in app.yaml someplace, or something like that.

I’ve got dozens of apps on GAE, and do not relish the idea of porting them all to a different mail API. Especially since 99% of the mail sent is just error logging reports sent to me.

-Joshua

On Apr 29, 2016, at 3:27 PM, 'Nick (Cloud Platform Support)' via Google App Engine <google-appengine@googlegroups.com> wrote:

Hey pdknsk,

While I can't speak on any concrete plan to deprecate, the excellent quality of SendGrid (even at the free tier), combined with our 1-year-minimum deprecation policy timeline, should reassure everyone that there's nothing significant to worry about. If this were to occur, you can rest assured as well that we'd be happy to provide migration advice to anybody needing it during the deprecation. 

Cheers!

Nick
Cloud Platform Community Support

On Friday, April 29, 2016 at 10:17:03 AM UTC-4, pdknsk wrote:

https://cloud.google.com/appengine/docs/python/release-notes

> Google no longer accepts quota increase requests for the mail service. Customers should use Sendgrid instead.

Google will probably deprecate it soon, and close it a year later.

--
You received this message because you are subscribed to the Google Groups "Google App Engine" group.

To unsubscribe from this group and stop receiving emails from it, send an email to google-appengine+unsubscribe@googlegroups.com.
To post to this group, send email to google-appengine@googlegroups.com.

[John Wheeler]

The Mail API is extremely important to us and provides satisfactory deliverability for our use cases in its current form. For the amount of mail we send, alternatives are still too expensive. -1 on shutting the API down completely. We rely on it and find it useful.

On Monday, May 2, 2016 at 1:43:21 PM UTC-7, Nick (Cloud Platform Support) wrote:

Hey Joshua,

That's certainly an interesting idea! While I can't guarantee we'll implement it, be assured that we've heard this suggestion and will consider it. In the meantime, if a deprecation were announced, we would certainly welcome the opportunity to help as many users as possible easily migrate, in whatever form that looks like.

Cheers,

Nick
Cloud Platform Community Support 

On Monday, May 2, 2016 at 11:35:35 AM UTC-4, Joshua Smith wrote:

Suggestion for the team: If you do decide to do this, keep your existing API and just swap in SendGrid as the underlying transport layer. Maybe we could put our SendGrid API key (or however they deal with that) into the console, or in app.yaml someplace, or something like that.

I’ve got dozens of apps on GAE, and do not relish the idea of porting them all to a different mail API. Especially since 99% of the mail sent is just error logging reports sent to me.

-Joshua

On Apr 29, 2016, at 3:27 PM, 'Nick (Cloud Platform Support)' via Google App Engine <google-a...@googlegroups.com> wrote:

Hey pdknsk,

While I can't speak on any concrete plan to deprecate, the excellent quality of SendGrid (even at the free tier), combined with our 1-year-minimum deprecation policy timeline, should reassure everyone that there's nothing significant to worry about. If this were to occur, you can rest assured as well that we'd be happy to provide migration advice to anybody needing it during the deprecation. 

Cheers!

Nick
Cloud Platform Community Support

On Friday, April 29, 2016 at 10:17:03 AM UTC-4, pdknsk wrote:

https://cloud.google.com/appengine/docs/python/release-notes

> Google no longer accepts quota increase requests for the mail service. Customers should use Sendgrid instead.

Google will probably deprecate it soon, and close it a year later.

--
You received this message because you are subscribed to the Google Groups "Google App Engine" group.

To unsubscribe from this group and stop receiving emails from it, send an email to google-appengi...@googlegroups.com.
To post to this group, send email to google-a...@googlegroups.com.

[Nick (Cloud Platform Support)]

Hey John,

Thanks for your feedback. We definitely appreciate hearing from users on issues like these. As one helpful recommendation which you might not be aware of, I can link to SendGrid's documentation on their free tier, which is awesome in the amount of quota / features when compared to even the free tier of the App Engine Mail API, so do consider checking it out if you're concerned about costs.

Sincerely,

Nick
Cloud Platform Community Support

[Emanuele Ziglioli]

yeah, one less reason to bet on App Engine: it's such a moving target.

We can't afford to rewrite critical parts of the code every few years just because APIs get deprecated.

Blobstore first, now this.

Mail has been the single most reliable feature for us over the past 5 years.

I understand the problem and costs might be caused by those few spammers who send millions of e-mails from GAE.

Why don't you kick them out?

Look at what the average user needs, and restrict the quota for cater for us.

Otherwise, just tell us what App Engine is and we'll figure out what to do in the future.

You keep telling us GAE's future is solid but then you strip it bits by bits.

Very frustrating.

[Jeff Schnitzer]

Geez, the blobstore? Old skool :-)

Jeff

To view this discussion on the web visit https://groups.google.com/d/msgid/google-appengine/255327ac-939e-485f-8504-574792a52f2f%40googlegroups.com.

[Nick (Cloud Platform Support)]

Hey Emanuele,

I understand your concerns about needing to revise your codebase - nobody wants to spend more time than they need on maintaining or adjusting a system when they could be blazing new trails and writing new behaviour and system, but rest assured that we really do try to ensure that deprecations are announced well in advance of the final termination of a service, and we are committed to providing any migration help necessary.

In this case, the migration from Mail API to a similar mail API elsewhere on the net is mostly a very linear code change - merely take the same parameters (recipients, from, subject, body, attachments) and provide them to the other API. For more advanced mail features, you can work with the documentation of whichever other mail provider you choose to determine how to do whatever it is you want. If you would like, you could open a thread to explicitly ask the community to assist with advice on how to adjust anything that you might find to be particularly difficult. We're here to help, not just Googlers but the community of developers in general!

Cheers,

Nick
Cloud Platform Community Support

[PK]

How simple and easy life seems when one’s job is just to write support e-mails. Programming e-mail support in the cloud is a different story.

It took me a long time to get the GAE mail service work reliably and I am very happy with it. I had to deal with encoding issues, MIME issues, etc. I do not want to open this can of worms with another vendor’s APIs.

Please do not change it/deprecate it except to improve it along the lines of improvements we have filed in the public tracker.

Thanks,
PK

p...@gae123.com

[Kaan Soral]

The challenging part of email sending is the verification and related dns uglinesses, so it's not as simple as replacing the API layer

Even setting up senders with App Engine is quite challenging, you have to create the email, add that email as an admin etc. (back in the old days, not sure how it works now, the hard part is the research and verification)

My suggestion would be to take the hard path and do what sendgrid does, manually hunt the abusers

Here is a funny analysis of the situation:

1) Google is in the cloud provider business, Google wants people to use it's cloud offerings

2) Google shuts down a cloud service, Google sends precious customers to another company

It's admirable how contradicting (1) + (2) is

I think the contradiction arises from (1) - Why is Google providing cloud services? Maybe it shouldn't, if it's pulling out of the Mail, the same could happen for all of the services soon

I think this is why this situation is concerning

Other than this, I roughly agree with how easy it would be to move the mail sending elsewhere, especially for apps that send small amount of emails, for >1000 emails, I don't think SendGrid would easily allow sending emails, as far as I contacted such services before, they considered high amount of emails as newsletters and required very strict consents from users and proof of such consent

I would probably move to AWS's email service, I have been using it on SDK for maybe ~5+ years, same code still works for free

[Marcel Manz]

This is really funny, having Gmail as one of the best e-mail infrastructure, but unable at the same time to provide a managed e-mail service for its cloud offerings.

We implemented AWS SES on all our GCE fleet as sendmail relay since long time and it's running like a charm. I don't see any reason why to signup with SendGrid and also don't see why Google is favouring them so much. If Google were to purchase them at some point, then it would be explainable, but otherwise ..

IMHO similar story goes with sending people off from Google Groups to StackOverflow etc: while those sites are a great resource, I mostly use / land on them by simply doing code / issue searches through Google search. Google's competitor AWS seems to do the exact opposite, by providing heavy used forums where all information stays with them instead of sending people away to discuss / look for help.

Marcel

[Kim Lewandowski]

Hi everyone,

PM on App Engine here. We hear your pain. Email is an important part of any cloud-based application and we definitely understand that a 1st-party service is preferred for this. We're in the process of assessing what we're going to do about this. I don't have anything specific to announce right now, but I can say that we're actively working on finding the best solution, and that deprecating a service without giving customers a pathway to a comparable alternative is not a tenable strategy.

[Joshua Smith]

On Jun 27, 2016, at 3:37 PM, 'Kim Lewandowski' via Google App Engine <google-a...@googlegroups.com> wrote:

deprecating a service without giving customers a pathway to a comparable alternative is not a tenable strategy.

Wow. You must be new here. 

Someone get this new PM a long sword and some armor, so they can maybe convince upper management of this. Because deprecating services with no comparable alternative is kind of a trademark of GAE.

Go, Kim, go!

-Joshua

[PK]

Hi Joshua,

I am not sure what you are referring to but what your write is not consistent with my experience using GAE for a very long time. The mail service is an isolated case and my understanding is that even in the case of mail GAE has grand-fathered all of us who have been using mail in our apps with higher quotas.

PK

p...@gae123.com

--
You received this message because you are subscribed to the Google Groups "Google App Engine" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-appengi...@googlegroups.com.
To post to this group, send email to google-a...@googlegroups.com.
Visit this group at https://groups.google.com/group/google-appengine.

To view this discussion on the web visit https://groups.google.com/d/msgid/google-appengine/76DF200D-45AA-4E32-886C-7429E72E0B88%40gmail.com.

[Joshua Smith]

There are so many examples:

HRD is *not* a comparable alternative to the original data store. It lacks a bunch of consistency guarantees that require all sorts of hacky workarounds in apps that we didn’t used to have to do, and for relatively small-scale apps are completely silly.

Cloud Storage is not a comparable alternative to the blobstore in various ways.

The new admin console is a buggy navigational nightmare compared to the old, simple, reliable console.

I’m sure others on the list who have been around as long as you and I can think of others.

Google replaces simple, functional capabilities with complex, more functional, but not comparable capabilities. It’s a pathology of GAE.

-Joshua

To view this discussion on the web visit https://groups.google.com/d/msgid/google-appengine/DAC85ECF-B329-4E58-B59A-7D00C661AB7B%40gae123.com.

[Jeff Schnitzer]

Geezus…inline…

On Mon, Jun 27, 2016 at 4:41 PM, Joshua Smith <mrjoshu...@gmail.com> wrote:

There are so many examples:

HRD is *not* a comparable alternative to the original data store. It lacks a bunch of consistency guarantees that require all sorts of hacky workarounds in apps that we didn’t used to have to do, and for relatively small-scale apps are completely silly.

The original datastore went down for an hour once a month - and that was just the planned downtime. It was not possible to build an application with reliable uptime on it. The HRD has been a godsend. I hate eventual consistency too but it’s something I can live with to get a reliable zero-maintenance datastore.

 

Cloud Storage is not a comparable alternative to the blobstore in various ways.

Cloud Storage has crappy docs, but in all other respects it is vastly superior to the Blobstore. Spend the time to climb the learning curve, it’s worth it. Stay away from the horrible appengine blobstore api adapter and use the GCS APIs directly. Enjoy being able to use gsutil to manipulate blobs instead of writing code!

 

The new admin console is a buggy navigational nightmare compared to the old, simple, reliable console.

The old console was buggy too - especially the log system. It was usually a little faster, I’ll grant you that. But I don’t miss it, especially now that almost every page has a ‘refresh’ button that cuts down the whole page loads. And the one-click button that takes me from a retrying task to its log entries is *MAGIC*.

 

I’m sure others on the list who have been around as long as you and I can think of others.

Google replaces simple, functional capabilities with complex, more functional, but not comparable capabilities. It’s a pathology of GAE.

Threads like this annoy me because while Google is wasting manpower figuring out how to give you commodity email service, they’re leaving really horrible issues in place that I will never be able to do anything about. The Remote API doesn’t handle transactional tasks, which means half my business logic doesn’t work when run locally. Managing hundreds of domains is incredibly painful. 32MB is starting to feel awfully small for a request/response limit. 5 transactional tasks is not enough.

It’s hard for me to sympathize with problems that any intern could fix in an afternoon.

On the plus side, going from 5 EGs to 25 EGs in a transaction was a huge win. Cloud SQL 2 is now usable from Standard Runtimes. The Flexible runtimes are becoming more useful (even though they are not a replacement for Standard). I keep hearing official public statements that Java8 is coming. 

…and I still haven’t hired an ops or devops person.

Jeff

[PK]

Jeff,

Many good points but please stop taking on the mail service especially with this tone. Using your language, one could argue that the mail service was there before the Java runtime and Cloud SQL and  if Google was not "wasting" its engineering resources on these newer efforts, many of the other issues would have been resolved. 

Anyways, I am glad to hear Kim's comments. 

PK

http://www.gae123.com

--

You received this message because you are subscribed to the Google Groups "Google App Engine" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-appengi...@googlegroups.com.
To post to this group, send email to google-a...@googlegroups.com.
Visit this group at https://groups.google.com/group/google-appengine.

To view this discussion on the web visit https://groups.google.com/d/msgid/google-appengine/CADK-0ugVKhZ%2BsmFRpKz80Z8D2oc0AXQC0RdHehW%3DJBYa02SyzA%40mail.gmail.com.

[John Wheeler]

Google,

Please don't assume everyone is unhappy with the state of your e-mail offering, and that we're looking for you to provide a concrete alternative. We deliver a lot of e-mails on App Engine, and our business relies on being grandfathered.

We do not want to switch e-mail providers and have to iron out all the idiosyncrasies like already done on App engine. Please keep that in mind. Migrating to a provider when sending e-mail at scale is not a risk-free endeavor at all.

Thanks

[Chad Vincent]

for >1000 emails, I don't think SendGrid would easily allow sending emails, as far as I contacted such services before, they considered high amount of emails as newsletters and required very strict consents from users and proof of such consent

We've been using SendGrid (though not with GAE) for a couple years now.  We send 3-4k messages/day through it and have never been asked for any proof of consent, only a copy of our privacy policy.  They give you the tools for managing opt-out through them (with optional auto-append of footers, filtering anyone on the opt-out list for you, etc) so I doubt they would expect you to duplicate managing consent.