Per the following support article: https://cloud.google.com/compute/docs/images/import-existing-image ... it is possible to import RAW Linux images for use in Google Cloud VM's. However, it makes no mention of Windows instances. Is this also an option using the same RAW compressed import format?
To the extent that the RAW Windows disk image is GCE compatible (e.g., has all of the required device drivers), it should work from a technical perspective. The same would be true for any x86 OS, such as FreeBSD, etc.
This ignores any potential licensing issues that you may need to stay in compliance with, however. If you use a GCE Windows Service Instance, the billing is included in the per-hourly rate charged for the VM. If you create your own image, it will be up to you to stay in compliance. Your company might have some bulk volume licensing agreement with Microsoft which covers VM's, but there are often very specific terms you have to follow to stay within compliance of that agreement.
Related
I am building an application with the following requirements:
Must run on both mobile phones and tablets
Must support online/offline scenarios
Requires geolocation
Requires local storage
Platform is unknown at the moment (due to the nature of this project, I cannot yet rely on a particular platform version, e.g. Android 4+ or Windows 8.1)
I am leaning towards building this in HTML5/CSS/jQuery/Bootstrap. Since HTML5 supports both geolocation and local storage, and since I do not need to use any device feature such as a camera, I don't think something like PhoneGap is necessary.
However, as I am new to mobile development and PhoneGap, I am not sure if I am missing something. Are there any reasons - apart from future-proofing against future requirements - why I should consider using PhoneGap even though I don't think I need it for any particular reason? Is there value in having its API sitting in front of any interaction with the devices upon which my application will be running?
Factors to consider with respect to Local Storage.
Local Storage size limit:
Web storage provides far greater storage capacity (5 MB per origin in Google Chrome,Mozilla Firefox,and Opera; 10 MB per storage area in Internet Explorer;25MB per origin on BlackBerry 10 devices) compared to 4 kB (around 1000 times less space) available to cookies. ( source Wiki)
Local Storage Method.
Web Storage:
Web SQL Database:
Indexed Database:
File Access:
source: html5rocks, sitepoint
All MOBILE broswers have varying degree of support for above local storage method.
The most widely supported method is Web Storage.
If you would like to store more than the limits mentioned above than you need to use the native (OS) features for storing data. Then PhoneGap is the obvious choice for accessing native features.
How are you planning to distribute your app!! If you want to distribute using a website, then may be you don't need phonegap. BUT..... if you want it as an mobile app, then you'll need phonegap to easily wrap your code. Phonegap will help you to build installation package for many platforms (e.g. APK for android)
Is there a technical reason, why a Google Drive application must be installed through the Chrome Web Store (which severely limits the number of potential users)?
The reason that installation is required is to give users the ability to access applications from within the Google Drive user interface. Without installation, users would have no starting point for most applications, as they would not be able to start at a specific file, and then choose an application.
That said, I realize it can be difficult to work with in early development. We (the Google Drive team) are evaluating if we should remove this requirement or not. I suspect we'll have a final answer/solution in the next few weeks.
Update: We have removed the installation requirement. Chrome Web Store installation is no longer required for an app to work with a user's Drive transparently, but it is still required to take advantage of Google Drive UI integrations.
To provide the create->xxx behaviour that makes a new application document from the drive interface, and to be able to open existing documents from links, there must be some kind of manifest registered with Google's systems and some kind of agreement from the user that an application can access your documents and work with specific file types. There's little way around this when you think about the effects of not doing this.
That said, there are two high level issues that make for compatibility problems.
As the poster says, the requirement to install in the chrome store
severely limits the number of potential users.
But why? Why do the majority of Chrome Web Store applications say that they only work on Chrome? Most of these are wrappers to web applications that work on a range of browsers, yet you click through a selection and most display "works on chrome", aka only installs on chrome.
Before we launched our application on chrome we found that someone had created "xxxxxxx launcher" in the store, that simply forwards to our web app page. We're still wondering why it only "works on chrome". I suspect that some default template for the web store has:
"container" : "CHROME",
in it, which is the configuration option to say chrome only. That said, I can't find one, so I'm very confused why this is. It would be healthier if people picked Chrome because it's the better browser (which it is in a number of regards), not because their choice is limited if they don't. People can always write to the application vendor and ask if this limitation is really necessary.
The second thought is that a standardised manifest format across cloud storage providers would mean a much higher take up in web app vendors. Although, it isn't hugely complex to integrate, for example, with Google Drive, the back-end and ironing out the the details took over a week in total. Multiply that lots of storage providers and you have you lose an engineer for 2 months + the maintenance afterwards. The more than is common across vendor integration, the more likely it is to happen.
And while I'm on it, a JavaScript widget for opening and saving (I know Google have opening) by each cloud storage provider would improve integration by web app vendors. We should be using one storage providers across multiple applications, not one web application across multiple storage providers, the file UI should be common to the storage provider.
In order to sync with the local file system, one would need to install a browser plug-in in order to bridge the Web with the local computer. By default, Web applications don't have file I/O permissions on the user's hard drive for security reasons. Browser extensions, on the other hand, do not suffer from this limitation as it's assumed that when you, the user, give an application permission to be installed on your computer, you give it permissions to access more resources on the local computer.
Considering the add-on architectures for different browsers are different, Google first decided to build this application for their platform first. You can also find Google Drive in the Android/Play marketplace, one of Google's other app marketplaces.
In the future, if Google Drive is successful, there may very well be add-ons created for Firefox and Internet Explorer, but this of course has yet to be done and depends on whether or not Google either releases the API's to the public or internally makes a decision to develop add-ons for other browsers as well.
Can we use OpenShift Express, which is free right now, for commercial web applications?
And if not, then which PAAS services are there which are free, and have no vendor lock-in.
You can use OpenShift Express for commercial web apps but be sure it will meet your requirements. Potential issues include:
currently no outgoing email support
currently applications do not scale to accommodate load
1GB disc space limit
shared hosting
limit 3 cartridges (DB, metrics, etc) per app
no official support from Red Hat. Documentation is good and community forum support is very active.
OpenShift would meet many commercial site requirements. I think it's a great option. For more info read the FAQ.
Openshift have opened SMTP Port now.
check : https://www.redhat.com/openshift/community/blogs/outbound-mail-ports-are-now-open-for-business-on-openshift
You can use Cloudify. It is build for orchestrating any application on any Cloud without changing the application code or architecture. Cloudify is opensource and free.
Cloudify offers many features such as pluggable monitoring, scale rules by any KPI, APIs for sharing runtime information between agents and even Chef integration
Due Diligence Im the product manager for Cloudify in GigaSpaces
I've been using it for some small services and clients.
There isn't any clause on there terms of use that states that you can't use it as commercial web apps. But attention to the following line:
"You may not post or transmit through this website advertising or commercial solicitations; promotional materials relating to website or online services which are competitive with Red Hat and/or this website."
Yes, OpenShift has a tier that is completely free to use, even for commercial applications. There are no plans to change this in the future. There are, however, some minor limitations to the FreeShift tier:
Scaling limited to 3 gears
Serves about 15 pages/second
3GB total storage space (1GB per gear)
No SSL certificate for your custom domain name
No support from Red Hat
An alternative is Heroku, which you should definitely check out if you haven't already. Having used both, I can tell you that it's a much more polished platform: The servers are about 4× faster, you can run as many apps as you want, and the Heroku Toolbelt is much more powerful than the OpenShift's Client Tools. Heroku is also completely free until you reach 10k rows in your database.
RedHat will provide support (and scaling) when they release their MegaShift tier.
(https://openshift.redhat.com/community/developers/pricing)
I don't think there is a date yet for this.
It won't be for free off course.
I have to architect a commercial vehicle fleet tracking system.
Each vehicle (a few 100, max a few 1,000) will have a GPS and satellite transmitter and will periodically report its position. Positions will be stored in a database and used to create a Google Map.
There will of course be other functionalities. Security, log in, etc and probably lots of interaction with other corporate databses (drivers start/stop time for salary purposes, etc).
Question: pure GoogleMaps is probably best implemented as a browser based app (Php & MySql?), but with the additional functionality of a commercial vehicle fleet tracking system, would it be better doing something PC based (Windows/Linux)?
Any other advice? Thanks
I think with the capabilities of modern browsers, along with various mature client-side frameworks, we are witnessing an always thinning distinction between web and desktop interfaces.
You may want to take into consideration that a web application automatically solves some important problems for you:
Distribution: No need to distribute your application. Simply provide a URL.
Updates: Upgrading and fixing problems in your software will be easier and quicker if you distribute it through a web interface.
Security: Deriving from the above, you are able to fix security vulnerabilities more promptly.
Compatibility: Your application will be able to work on any operating system that can launch a web browser.
Last but not least, remember that the Google Maps API is not free for this type of application. Article 10.9.C of Google Maps API Terms and Conditions explicitly restrict using the standard Google Maps API for fleet management and asset tracking. You would need the Google Maps API Premier to legally use Google Maps for your application.
According to one unofficial source (dated April 2008), this would cost USD 10,000 per year, which entitles you to track 100 vehicles. If you exceed the 100 vehicles, you would need to add USD 24 per additional vehicle per year.
Implement solution for the domain problems first. It means data storage, data transmission between vehicles and your system, methods of data analysis, aggregation and visualisation.
These will likely to sit as a head-less system on a server and provide access to it remotely, in both directions: to input data and to query data.
Now, PC or Web is more related to presentation on a client side. You can make both if you like. Web client as well as desktop application can serve as a client to remote data and operational server.
Don't forget that you can always host a web control in a thick client app. This is actually trivial with .Net on the Windows platform with the IE control. You can also access the browser's DOM this way and do some neat things. So just because there's a strong web component to what you're doing you're not necessarily "stuck" writing a pure web app.
One big question is what kind of hardware you'll be able to put in the vehicles. Will they be laptops or small PCs with full fledged OSs or something more mobile like CE or a pared-down Linux distro?
Google Maps is JavaScript based so you can do most things with it, e.g browser based, widgets, etc. However due to the licensing Google won't allow you to use it in anything other than an Internet environment unless you use there Enterprise License.
In terms of integrating it into other systems, its really difficult to say what's best without knowing what other software you are using, what protocols they use, are web services available, etc. I agree with Daniel though in that any distributed system not implemented in a browser better have some good reasons not to, simply because the benefits are substantial. You'll need to weight them up though with a full break down of all the different systems you will need to interact with and work out what fits best.
The great thing is that with it being JavaScript based you have a lot of flexibility in what you can do with it.
This is more an extension to #Daniel Vassallo's answer. Although a web based application would solve most problems there may be the small potential issue of bandwidth usage and reception for internet access. This may or may not be an issue for the fleet management, depending on how that is tackled on the hardware side of things.
An offline solution may assist with this issue but then a clever architect could find a way to create an initial web based solution which can be accessed with an offline application which can pick up the slack and/or provide predictive reasoning until a connection is re-established.
I'm currently writing a large scale ASP.Net web app.
One of the thngs I can't find out about is how to justify when to use the cloud. E.g. when should I use google app engine/azure?
Also, when would I want to use bigtable over a standard dbms such as Sql Server?
Thanks
Cloud computing is all about scalability. It allows you to scale up AND scale down without having to rework your designs.
It works well for small sites, since you are only paying for resources used, but if you need to scale up, it just happens automatically (provided your application was designed for the cloud).
Also, there are theoretically much better tools in place for maintaining uptime and reliability in the cloud. For example, a system upgrade can happen without stopping your service, since the cloud computing platforms can automatically take on or off servers to service your application.
There's been a lot of talk about that from the Azure devs.
Also, there can be a financial motivation for using the cloud. Using a hosted cloud architecture can be less expensive than managing the multiple servers (DB, web, etc) that would be required for a traditional site, at least up front. As your usage goes up, the cost follows, but in theory, it can be more cost effective.
I'm not too familiar with anything else except app engine and EC2.
I'll try to add something to the previous answers:
The best thing about app engine is it's free until you attract a certain amount of users and you are charged for what your application uses, idle time is not charged.
Big table may differ from an rdbms architecturaly but from a perspective of a developer using it it's not that different.
Another good thing is python is supported. The bad thing is the standard library is crippled.
Also, you don't have full control over your data on the cloud (appengine), what I mean is you can't completely restrict the people from google from taking a peek in what you store there.
This question is very closely related to another question asked today:
"When shouldnt-you-use-a-relational-database?"
Relational databases and non-relational databases (like BigTable) address different needs. Not only in scale and performance, but in the structure and usage of the data.
The "Cloud" as I understand it is about scalability primarily. That is, the architecture refers to a capability to increase capacity in a scalable way.
Also, the Cloud is used frequently in reference to the Software-as-a-Service (SaaS) model, where someone else takes care of the servers, but that's an independent issue from the Cloud architecture. I.e. you could operate your own set of servers in a Cloud architecture.
So the justification for using the Cloud architecture is that you have an application that has a variable need for computing capacity. So it would be overkill to have N servers dedicated to match your peak level of activity. The Cloud allows you to vary your usage of the servers as your level of activity grows (and diminishes) over time.
The justification for using a SaaS model is that you don't want to be in the business of operating a data center. You're willing to relinquish some control and pay for the service, so that you can leave operation details to the experts in that technology. They handle backups, hardware failures, upgrades, 24x7 operation, etc. You handle your application and your business.
I recommend you subscribe to and read the High Scalability blog, especially some of the most visited posts such as those about the architecture of various large sites, as you will learn a lot from it that may help you make a decision. There is no hard rule as to when you should or should not use a cloud service or move from a relational database to a keyvalue system like BigTable.
One upside of cloud services in any case is that if you build your application with them, it will be immediately scalable and require much less rework later on if you require that kind of performance. However, in view of premature optimisation, it would be wise to be sure that you need that kind of scalability before you decide to build your app on such a platform.
There are several concepts to wrap your head around when using a datastore system like BigTable as well, such as not being able to just slam out writes like you would in a relational database, and having to precalculate a lot of your data rather than just doing that based on info from the database.
Although again, you can learn a lot from reading the abovementioned blog and related posts about Youtube, Plentyoffish, Google, etc.
You say you are "currently writing a large scale ASP.NET app". If you have made significant progress on it, you are already pass the point where you can justify using Google app engine or Azure. Both require significantly different architectures than you have build with a traditional application due to language support, database differences, and maturity.
Google App Engine is Python only so switching to it would require a complete rewrite
Big table is not a relational database and requires very different coding patters. SQL Data Services originally announced to be non-relational as well, but is moving to be more relational. I have not seen how close to a standard MSSQL database it currently is.
I would consider Google app engine to be a relatively immature platform so far. Database functionality is limited, you cannot run background processes, profiling and performance tuning tools are limited at best. Azure is currently in limited community preview, and so is not even available to ship a product on today.
While there are many very valid reasons to use a cloud architecture, moving to it will require significantly different architectures. Think about what effect changing that architecture (and possibly waiting for platform availability) will do to your release date.
If you are early in your project, cloud vs. not cloud is a great question to ask. If you have well on your way, I think that the importance of getting to shipping code and leveraging the work you have already put in should trump any benefits to the cloud you may see.