Running your custom environment on Google cloud

Very often developers have their favourite web application setups. Some like to use Spring, some go after CDI, some use relational databases such as MySQL, while others go after MongoDB... There are countless technologies on the market, and we are still not living in the world where exists such a universal software stack which will cover any architectural and business requirements one might encounter in his development career. But often we have a stack that is highly configurable, and is a combination of multiple tools and libraries that solve most of our needs out of the box. The usual problem with such is that known cloud providers (google cloud, aws, azure) offer a finite set of "mostly used" databases, web enterprise servers, UI frameworks, etc, that do not really fit the description we have already setup locally. Simple example for that would be that a MongoDB, that nowadays a lot of us use as our warehouse, is simply not offered as a service by google cloud provider. Is that because Google and Mongo DB were unable to establish a deal, or because Google wants to put an accent on their own No-SQL products, we can never know: but a system still needs to run the way we designed it in the first place. Google cloud platform offers the creation of customised virtual machines and running those within their so called "compute-engine". This means that one can run any possible system stack on their cloud platform within a controlled environment (VM running Ubuntu 16.04 for example). Using their cloud terminal, we go all the steps for setting our system up from scratch, meaning downloading Java, Maven, favourite web server, configuration tweaking, pulling down the code, building it and deploying it... In the very end, we can access the running instance of our application by using the unique IP of our running virtual machine. This IP is automatically generated by google compute engine whenever we restart our VM instance, but a static IP or even a normal URL can be obtained per demand. This way, any ideal system stack can be run on the cloud.