rdcastro

Deployments should not be taking that long at all if the app code is coming up healthy when it gets started on the VM (for crashes at code startup we also fail the deployments early). If the app comes up but isn't healthy (like serving 500 or not listening on the right port), we try multiple times to get the app started.

Can you share more information about your app and deployments so we can investigate further?

PS: It's worth mentioning we have active development to bring down deployments times and improve the deployment experience.

You're totally right. Some some examples of crazy stuff you can run on App Engine: https://github.com/GoogleCloudPlatform/appengine-custom-runt...

We do have migration guides to the Flexible environment available per language. This is the link to the Python version: https://cloud.google.com/appengine/docs/flexible/python/migr...

I hope that helps. A key tenet in the Flexible environment is portability. In the Datastore case, in particular, if you move to Cloud Datastore, that gives you portability across the Cloud Platform offerings or even if you want to run on premises or in a different Cloud provider.

App Engine Flexible is a PaaS (Platform-as-a-Service) with the mission that you bring the code and we do the rest for you. As an example, although we run the app as a Docker container, one doesn't need to understand Docker at all to get started. :-) It's a great place to get started without needing to understand how the infrastructure works. However, if you'd like to go beyond and provide your own Docker container, that works too. That is one of the exciting things we're making available with this new version.

In addition to App Engine Flexible, you can deploy Docker container to both Container Engine and regular GCE VMs in Google Cloud Platform. Each different offering will come with different set of features and different investment level on the user's side. A GCE VM will probably be the one with the ultimate flexibility on what one can do, but will typically require more time investment.

Regarding starting the container lazily and suspending it while inactive, that is not currently supported.

Yes, it does makes sense what you said. Thanks for sharing.

Like the other commenter mentioned, at startups there isn't much you can do if things go bad but quitting. Also, there's not necessarily financial security as a big company.

What would be the worst of both worlds in your opinion?

> My advice is to do what I'm doing.

Same as the other comment: what are you planning to do?

Thanks for the correction. Text updated.

Spot on. And the big question is how to make the right hires to maintain the company's culture. Probably it's not so much about making the right hires, but quickly fixing the bad hires.

You're absolutely right about that. It takes a lot of courage to do something that could affect the bottomline for the next quarter. Another thing is that, when the company's culture rewards those who don't make mistakes rather than those that are bold and try new stuff (therefore making some mistakes), then not rocking the boat is institutionalized. New things are not tried, as they are too risky, and anything old that becomes a liability must be quickly fixed or gotten rid of.

I like your "I'd rather build things". I think you can also build things at big companies, but it's just different types of things and much different process. It's just that, depending on your org, you may end up building more slowly (sometimes way more slowly) or you will build something that was decided by others and that you didn't have much input on.

I absolutely agree that typically the impact you can have at a big company can be huge. But it may come with a cost - adjustment to that structure.

As I mentioned in the post, it is a great environment for many people, and I'm glad to hear about your case.

Working at Microsoft (in Windows Azure), this was the first outage since I joined the org, so I did not know what to expect from the company in terms of transparency on this outage. However, given other presentations or papers on the Windows Azure technology and how open they were publicly, I expected a good job here.

Bill Liang's post confirmed how transparent Microsoft wants to be with its customers, what is really nice. And I appreciate how seriously Microsoft is attempting to learn from these incidents and putting measures in place.