Where can I find the SLA and deprecation policy of GAE Go runtime.
As per the features page,
The runtime is experimental,
Go
Experimental The Go runtime executes your code in a Go 1.1 environment. This runtime is Experimental. Release Notes Documentation SDK
But, core features are GA (Data storage, retrieval, and search, ...).
So, where can I see if Google decide not to support Go runtime in app engine, what deprecation policy would be in effect.
Thanks.
Update: In April 2018 I no longer see any signs that Go support is experimental. You should research the current state of things rather than relying on the years-old answer below.
I think there is no deprecation policy for the Go runtime, not even a hard commitment to keep the service running, based on language in section 7.3 of the TOS: 'This Deprecation Policy doesn't apply to versions, features, and functionality labeled as "experimental."' I'm not a lawyer.
In reality I don't think there are any signs Google is likely to shut it down for the short term. They haven't deprecated a language so far, the runtime has been out for a while and is still updated (SDK released 2011, and is actively updated as of Nov '13), it has users (goread.io, at least a couple little projects in Google), and Go is a Google creation. But no one has promised continued support or backwards compatibility.
It's quite reasonable to be wary of lock-in with any platform/vendor, especially if they have no contractual obligations to you. It might be wise to ensure you can eventually port your app if needed (to Heroku, your own set of VMs, etc) by not relying too heavily on the quirks of GAE's datastore and other quirks.
Related
We've narrowed our selection for an ipaas down to the above 3.
Initially we're looking to pass data from a cloud based HR system to Netsuite, and from Netsuite to Salesforce, and sometimes JIRA.
i've come from a Mulesoft background which I think would be too complex for this. On the other hand it seems that Celigo is VERY drag and drop, and there's not much room for modification/customisation.
Of the three, do you have any experience/recommendations? We aren't looking for any code heavy custom APIs, most will just be simple scheduled data transfers but there may be some complexity within the field mapping, and we want to set ourselves up for the future.
I spent a few years removing Celigo from NetSuite and Salesforce. The best way I can describe Celigo is that it is like the old school anti-virus programs which were often worse than the viruses... lol... It digs itself into the end system, making removing it a nightmare.
Boomi does the job, but is very counter-intuitive, and overly complex. You can't do everything from one screen, you can't easily bounce back and forth between tasks/operations/etc. And, sometimes it is very difficult to find where endpoints are used, as they are not always shown in their "where is this used" feature. Boomi has a ton of endpoint connectors pre-built (the most, I believe), but I have not seen an easy way to just create your own. Boomi also has much more functionality than just the integrations, if that is something that may be needed.
Jitterbit, my favorite, is ridiculously simple to use. You can access everything from one main screen, you can connect to anything (as long as it can reach out to the network, or you can reach it via the network - internal or external). Jitterbit has a lot of pre-built endpoint connectors. It is also extremely easy to just create a connection to anything you want. The win with Jitterbit is that it is super easy to use, super easy to learn, it always works, they have amazing support (if you need it). I have worked with Jitterbit the most (about 6 years), and I have never been unable to complete an integration task in less that a couple of day, max.
I have extensive experience with Dell Boomi platform but none with JitterBit or Celigo. Dell Boomi offers very versatile and well supported iPaaS solution. The technical challenges of Boomi are some UI\usability issues (#W3BGUY mentioned the main ones) and the lack of out-of-the-box support for CI/CD and DevOps processes (code management, versioning, deployments etc.)
One more important component to consider here is the pricing of the platform. Boomi does charge their clients yearly connection prices. Connection is defined as a unique combination of URL, username and password. The yearly license costs vary and can range anywhere between ($1,000 - $12,000) per license per year. The price depends greatly on your integration landscape and the discounts provided so I would advise on engaging with vendor early to understand your costs. Would be great to hear from others on pricing for JitterBit and Celigo.
Boomi is also more than just an iPaaS platform. They offer other modules of their platform to customers: API Management, Boomi Flow (workflow and automation module), Master Data Hub (master data management). Some of these modules are well developed and some are in their infancy (API Management).
From my limited experience with MuleSoft platform, I share the OP's sentiments about it being too complex for simple integrations. They do provide great CI/CD and DevOps functionality though if that is something that is needed.
There is not a simple answer to a question like this. One needs to look at multiple aspects of the platform and make a decision based on multitude of factors. I would advise looking at Gartner and Forrester reports for a general guidelines and working out the pricing (initial and recurring) with the vendor.
I have only used Jitterbit, so can only comment on that. It works fine. It is pretty intuitive and easy to use, but does have some flexibility with writing your own queries, defining and mapping file formats, and choosing different transfer protocols.
I've only used the free version (which you need to host somewhere and also is not supported) and it was good enough for production tasks. If you have the luxury of time, I'd say download it and try it out. If it works for you, throw it on a server or upgrade to the cloud version.
One note: Jitterbit uses background services. If you run it locally and then decide to migrate your account to a server, you need to stop those services on your local. Otherwise, it will try to run jobs from both locations and that doesn't turn out well.
Consider checking out Choreo as well. It has a novel simultaneous code + low-code approach for integration development. And provides rich AI support for performance monitoring, debugging, and data mapping.
Disclaimer: I'm a member of the project.
I am stuck in deciding between choosing Google App Engine Standard Vs. Flexible environment for a real world production. I want to use Java definitely. Need to use Firebase(latest version) for Authentication and Push notification; I'm not sure whether new Firebase is compatible with standard or flexible.
per the caution note in the following link, my impression is that recent Firebase is compatible is with Flexible Environment only.
https://cloud.google.com/solutions/mobile/firebase-app-engine-android-studio
All things being equal any standard environment app can also run in a flexible environment with minimal app changes. The reverse is not true - the standard environment restrictions are stricter than those for the flexible environment (hence the flexible in its name).
UPDATE: the above is not correct, the language specific section of the Migrating an Existing App Engine App guide should be checked for which standard env APIs are explicitly listed as compatible or incompatible. In some cases that could clarify the decision right away.
Assuming for the remaining of the answer that the choice between environments remains open after this check.
So - to get unstuck - I'd initially shoot for the standard environment (simpler to setup/manage and also potentially free, depending on the app's usage) and only decide to switch to flexible-only env if/when I hit an unavoidable issue caused by one of a standard environment restrictions and which is not an issue in the flex environment. If no such issue is hit you practically maintain the option to switch between the 2 deployment options as you desire.
As for your impression from the tutorial doc - I think it's unfounded, based on the Costs section...
Both Firebase and App Engine have free levels of usage. If your usage
of these services is less than the limits specified in the Firebase
free plan and the App Engine free quota, there is no charge for doing
this tutorial.
... in combination with the Pricing row Comparing environments table...
... as the standard env has a free daily Instance hours quota but the Compute Engine Pricing uses the Machine type billing model and doesn't have a free quota except for the initial limited free trial.
Which overall tells me that the standard environment is used in the tutorial :)
Confirmed in the Configuring the App Engine backend to use manual scaling section as the app's config doesn't have the <vm>true</vm> setting used to select the flexible environment.
Your preference should be app engine standard environment for the time being, unless you specifically need a feature only offered in flexible. Currently, there is very little documentation to go with Flexible app engine, and converting nearly any app from one to the other is NOT a simple task.
Anything you read that says "its easy to convert from standard to flexible" or vice versa is from BEFORE december 6'th, when vm:true was deprecated (along with all of the compat runtimes which let you use standard code on flexible app engine). Flexible now has it's own libraries for most things, and it's different enough to require nearly a complete re-write of many of your methods.
For example, when I converted my cloud storage controller to flexible, not a single line of code was useful beyond method names as the new library primarily utilizes Blobs instead of StorageObjects. (java)
Google's AppEngine has upgraded their Developer's Console and it includes a monitoring tool called Cloud Trace. Is this an improved version of the AppStats profiling tool? If so, can I remove the configuration files that were previously required, like appengine_config.py and the console path in app.yaml?
builtins:
- appstats: on
Cloud Trace is in beta, meaning "it's not covered by any SLA or deprecation policy and may be subject to backward-incompatible changes", while AppStats is a supported component of App Engine.
The implication, to me, is that you probably should not yet depend on Cloud Trace in production applications, but that it's an excellent idea to experiment with it in development versions -- if you use a lot of RPC traces/stats (a great way to keep your apps in fine shape!-), it's probably worth your while to experiment, both with using Cloud Trace on its own and with "doubling up" with both it and AppStats.
This way you will learn whether, in its current beta state, Cloud Trace supplies all the information you find relevant to tuning your apps' use of RPCs, as well as whether also having AppStats produces any change in Cloud Trace's functionality (per the docs, it shouldn't [*], but, beta does mean beta:-) in your apps (which is the most relevant to you:-).
[*] so to explicitly answer the Q "can I remove the configuration files that were previously required": the answer in theory is "yes!"; in practice, "it's beta, do try it in a development, not production, version, and see if it breaks" -- as for most any new feature in beta:-)
Having both on lets you compare and contrast the measurements they offer, checking if there's any systematic or random difference that could affect your use of said measurements (again, there shouldn't be, but, etc, etc:-).
Since AppStats is a supported component, it is subject to the usual deprecation policy, and thus it will be around for a minimum of one year after it's officially announced as deprecated (if such an announcement ever happens), so there is really no urgency for you to consider migrating production apps off it at this time.
Is there any way to apply Pending Latency and Idle Instances Application Settings to non-default versions of an application?
We have both Java and Python versions that must share the datastore/memcache, so we badly want to control these settings for both versions of the app.
If not possible immediately, any idea when GAE team might add Application Setting support for non-default versions?
these settings are global for your app and can't be setup differently for other versions than the dafault one.
can't really answer your second question. did you try to check out the issue tracker?
http://code.google.com/p/googleappengine/issues/list
you could file a feature request and see what happens
Non-default versions were intended to be for staged deployments to live and are not actually intended to be production apps. Thus, it's not likely that any such request would be accepted by Google. Additionally, it's not clear why you have a Python and a Java version of this app. Your users won't technically know the difference, so in the end it's probably best to pick one platform, Java or Python, and stick with it.
However, I imagine there is something you aren't telling us, so if you do need to maintain both applications for whatever reason, you could use REST to access your datastore from a completely separate app. With memcache, you could reduce any latency by caching frequently accessed data.
This would allow both apps to access the same datastore while also making both apps production apps with their own settings.
A developer buddy of mine just recently started at a new company and one of his tasks is to come up with a new web application that allows their users to work offline when their staff are onsite in remote locations and then later to sync with a server side database of which they have not yet determined a server side provider yet (i'm guessing it will be SQL Server).
I've done some looking around and it seems like two viable options are LocalStorage and IndexedDb, with LocalStorage being the more popular technology? They want to go HTML5 and that's all fine and dandy, but long story short my question(s) is/are...
What are their offline data storage options in HTML5?
Are there older solutions that have better support?
are those methods less risky?
less time to implement?
The concept of storing data offline in a web application doesn't seem like a new idea, but doing so in today's newest technologies (html5, asp.net 4.0/4.5) is where you start getting into sparsely explored territory.
what are some things that maybe your company does that works, and what doesn't work?
Any intelligent evidence based replies will more than likely get my upvote so don't just rush to get the first answer and try to score some quick points, I'm looking for some good solid feedback here. Thank you.
There are several possibilities of offline storage in HTML5:
Web Storage
Web SQL Database
IndexedDB
Filesystem API
You have a very good presentation of all these options here:
http://www.html5rocks.com/en/tutorials/offline/whats-offline/#toc-older-storage
Compared to older options (Cookies, Plugin Based Storage, Browser-specific features) , I'll quote from the article:
"The newer storage APIs, what we might call "HTML5 storage", are generally superior in terms of openness and standards compliance. Of course, not all browsers include all of the new APIs, and you may have to support older browsers that don't include any of them at all. So the older techniques are still useful for graceful degradation."
Other useful links:
http://php-html.net/tutorials/html5-local-storage-guide/
http://www.tutorialspoint.com/html5/html5_web_sql.htm
Hope this helps...
I think your best choice is using Local Storage since its the most widely implemented standard of the storage options available under HTML5.
IndexedDB has been over-engineered (in my opinion) and is not widely supported (yet) for all of Mozilla's insistence that its better than sliced bread, and WebSQL's future is looking a bit uncertain as Mozilla is refusing to implement it and it is no longer being worked on due to an impasse between W3C and the browser vendors who have actually implemented it (Chrome/Safari/Opera).
There is currently a bit of a browser explosion happening thanks to smartphone adoption, so its hard to determine how much of the market supports HTML5 LocalStorage features but using statcounter I've been able to calculate that between Chrome (4+), Firefox (3.+), Safari (4+), Opera (10.5+) and IE (8+), including iPhone and Android devices you'll have captured around 80-85% of the market, with this figure going upwards a rate of 1-2% per month. The remainder being IE 6/7 (which stubbornly tends to hang on), older versions of new browsers (with update features that generally kept them current), and some mobile browsers stuck back in the stone age.
As for older options, I would add User Data Persistence for IE6/7 to the list provided by #user998692 but either way you're going to be caught up with lots of browser incompatiblity issues and support for a hodge-podge of technologies, which will complicate your codebase and testing and increase your delivery timelines (and cost) accordingly. If you do want to go down this road, however, I would recommend you take a look at PersistJS as the guys who put it together have done much of the work you would need to already.
These days its worth more looking forward (to what the market will look like in 1-2 years time when your app is propagating and gaining a wide user base) than backwards, so I'd say HTML5 LocalStorage is probably your best option.