I have developed a application using GWT/AppEngine/Objectify. There are many clients who want this locally deployed in their environments as the data is sensitive.
I cannot think of a way where the data of a application is hidden from its developers in AppEngine. Even I encrypt the data there will be always question about security.
I thought of the following alternatives
a) I have now a multitenancy application in appengine. I can now have a deployment for particular clients using their individual google accounts. This way they have security of data. I am not sure how I will handle new deployments. There is nothing like sharing the application with a user.
b) Migrate to MongoDB/MYSql.
This will lead to the whole question of handling migrations when data models are changed.I have read that with MongoDB I will not face migration issues. Is this correct.
What would be the best way to solve this issue. The root issue is that we as developers have access to data in Google/AppEngine environment which the client does not want.
Any help would be appreciated.
The easiest would be for the client to create an App Engine account and you only supply the war.
If you still plan to migrate away from GAE, then you might want to take a look at AppScale and capedwarf-blue.
Related
I've gone through https://vaadin.com/learn/tutorials/cloud-deployment/google to learn about how to deploy a Vaadin application on GCP.
Now, when I dive into the details, I see that Cloud Run doesn't support Session Affinity, and although Google App Engine does support it, the documentation says "You should never use session affinity to build stateful applications." So basically that means that what is suggested in the tutorial is not really working for production use.
So, my question is, what is the recommended approach to run Vaadin application on Google Cloud for production deployments?
I read that a distributed session store is also not on option (https://vaadin.com/blog/session-replication-in-the-world-of-vaadin).
Thank you,
Kristof.
Using any Vaadin (except Fusion maybe) relies on heavy use of server side stored state in a session (a massive scene graph is stored per client) -- there is no way around it. If your environment or use-case can not cope with this, then you are better off not using Vaadin. Due to the size of the session data, using a distributed session store without session affinity is discouraged (and the linked blog shows why).
TL;DR: there are no silver bullets.
A late response but could be useful for others.
Vaadin is not really cloud friendly.
There are demo on the vaadin site about server side stored session with hazelcast ... but after the first 'great it works' and a few days of effort and research you realise
it is not really more than a hello world and others developers having tried this way faced multiple blocking issues with no answers
this server side stored session endup with something much too heavy for a large scale deployment.
as cfrick mentioned, this required anyway session affinity for performance reasons
So my view is : forget it, sticky session is the only way with vaadin.
Now sticky session is not so straight forward to setup first especially when using push then to go production, you also need to manage things like "app ready" and "app gone" ... and up to now, I've not seen any production grade response.
I recently landed myself on a project that, like most projects today, relies on multiple relational databases and also, like most projects today, relies on the flexibility and security of cloud computing.
I got into cloud services a little over a month ago and since then I've tackled the basics of most the services that Amazon Web Services offers but have only tested and deployed personal projects.
Now I will be working on a clients server and its a hefty instance, therefore I need to research the best method for developing a pre-existing application on a cloud server. Also bare in mind that the data stored in the databases is also being updated 'live'/dynamically.
I assume it's still good practise to take a local copy to work on? In that case, is the best method to download the whole server using ssh? If so, are there any alternatives? I feel that just downloading the whole server and setting it all back up bit by bit (including the data 'stream') will be very time consuming for such a big application connected to such big databases.
Is there something a little more elegant?
If you are working on a cloud environment you may have developement environment.
You may have a local repository but nothing more than your IDE and your versionning tool.
All your service might be provided by the cloud and the most efficient way to test you code is to do it on a target Image.
personally ,I use cloud foundry or IBM Bluemix with my git repository. I push directly the modifications when i want to test.
you can use cloud services,you dont have to think about server setup/services.you will just need a repository like git.
you can follow below sample link for getting started on configuration on bluemix:
https://hub.jazz.net/tutorials
https://www.facebook.com/ibmswg?ref=hl&ref_type=bookmark
I would need to automate the creation of new App Engine projects. Is this possible? I see there is a Google Cloud SQL Admin API which can create new Cloud SQL instances, but what about App Engine? Is there anything similar?
Update:
We have developed an application that runs on GAE and uses Cloud SQL and plenty of API integration with most of Google Apps. We foresee dozens, if not hundreds, of customers in a near future. All of them will be using their own Google domain and Google Apps.
While we could actually just deploy the application in our App Engine and modify the Cloud SQL tables to include the id of the customer who owns the record, we thought it would be better if we deploy an app instance and Cloud SQL for every one of them (on our own account). The main reasons coming to mind are that we can track how much every customer spends in terms of billing, and speed up the database since Cloud SQL is just a MySQL instance.
Steps for the creation would require editing a properties file in the packaged .war file, adding the certificate used to log in as a service account, and probably something that I am missing at this moment :-P
This question is somehow related Create an App Engine Project ID command line
As far as I know this is not possible (and is unlikely to be possible anytime soon).
Update:
I can see why splitting into separate projects for billing purposes would be really nice (multi-tenancy is great, but getting one bill per customer from Google sounds easier), but unfortunately I don't think that it's going to be your best option.
For AppEngine, you may want to look into the multi-tenancy features (or in Python) and how to get stats for billing.
Keep in mind however, CloudSQL is not simply a MySQL instance. It happens to speak MySQL but is not the same as running MySQL on Compute Engine for example. I would recommend that you run some benchmarks to be sure that the "adding the customer ID to the table" idea you had won't work.
Lastly, a possibly relevant read: http://signalvnoise.com/posts/1509-mr-moore-gets-to-punt-on-sharding
I guess the conclusion is that there’s no use in preempting the technological progress of tomorrow. Machines will get faster and cheaper all the time, but you’ll still only have the same limited programming resources that you had yesterday.
If you can spend them on adding stuff that users care about instead of prematurely optimizing for the future, you stand a better chance of being in business when that tomorrow finally rolls around.
I am developing a mobile app and I am now getting to the stage where I want to put all my back-end server code online for the production version (I actually want to release my app). The back-end consists of 2 parts:
MySQL Database
Actual PHP files for app access.
Looking for a service that is popular, highly scaleable and proven, I came across Amazon Web Services. Now while RDS seemed very straight forward to use for the database part, EC2 was way too complicated for me and I decided on using a managed solution, which puts it out of the question.
Seeing as the simple PHP pages could be moved easily to any service at any time (unlike the database which is a bit harder to move with no downtime), I have decided to use a much cheaper solution for the time being for the PHP pages.
My Question is: Does it make senesce to use Amazon RDS with app hosted on other managed service (rackspace, azure, godaddy etc...)?
While it is technically possible, it depends on your application if it is generally okay to do so. Keep in mind that there will be extra delay in the communication between the RDS instance and your server - and this will happen with every database request you do. You can for example check the network latency with simple tools like ping or traceroute. In general you are looking for the lowest latency possible for database queries.
However if your app hardly does any reads from the database, this could work. If not, I would strongly advise against this. In this case you would either have to install a MySQL database on your managed server or start using EC2.
I'm in the process of designing an application that would tie into the database for multiple e-commerce stores.
I have the general business logic down but the problem is, I have no idea on the most painfree and effective way to do the data integration. I know how to access my own databases, but this is something I always just left to my hosting provider to handle the backend and I just developed the interface
Can someone point me in the right direction on this? There is a large emphasis on ease of installation. So my customers (once I get them) should be able to very easily integrate their system into my app.
RESTful web services are what many folks do for this.
Start here: http://en.wikipedia.org/wiki/Representational_State_Transfer
Then revise this to be a more specific question.
You might need to look at direct VPN/SSL connection from their server to yours.