Google App Engine

Ember.js Algolia Go Google App Engine Firebase MySQL

The new ember.js with SSR using fastboot+prember, without jquery and with npm easy installs via de ember-auto-import addon, angle bracket components in handlebars and ES6 classes is just a breeze to develop, we wanted to try golang for this particular project and it's ok, but I wouldn't recommend it for fast CRUDs, we might change to Elixir Phoenix for the next project, although algolia is super good there are no shortcuts for ember, we had to build them from scratch, but it works super good, we use firebase for our auth with facebook, google, phone, etc...

Firebase Cloud Firestore Cloud Functions for Firebase Google App Engine React React Native React Native Firebase NativeBase Twilio Dwolla.js Yarn fastlane Bitbucket Slack LastPass

We chose G Suite for internal and external collaboration. We use Google Compute Engine Google App Engine Google Cloud Storage to manage most of our work. Our business is a cloud first entirely built on Google Cloud

So, the shift from Amazon EC2 to Google App Engine and generally #AWS to #GCP was a long decision and in the end, it's one that we've taken with eyes open and that we reserve the right to modify at any time. And to be clear, we continue to do a lot of stuff with AWS. But, by default, the content of the decision was, for our consumer-facing products, we're going to use GCP first. And if there's some reason why we don't think that's going to work out great, then we'll happily use AWS. In practice, that hasn't really happened. We've been able to meet almost 100% of our needs in GCP.

So it's basically mostly Google Kubernetes Engine , we're mostly running stuff on Kubernetes right now.

#AWStoGCPmigration #cloudmigration #migration

Uploadcare has built an infinitely scalable infrastructure by leveraging AWS. Building on top of AWS allows us to process 350M daily requests for file uploads, manipulations, and deliveries. When we started in 2011 the only cloud alternative to AWS was Google App Engine which was a no-go for a rather complex solution we wanted to build. We also didn’t want to buy any hardware or use co-locations.

Our stack handles receiving files, communicating with external file sources, managing file storage, managing user and file data, processing files, file caching and delivery, and managing user interface dashboards.

At its core, Uploadcare runs on Python. The Europython 2011 conference in Florence really inspired us, coupled with the fact that it was general enough to solve all of our challenges informed this decision. Additionally we had prior experience working in Python.

We chose to build the main application with Django because of its feature completeness and large footprint within the Python ecosystem.

All the communications within our ecosystem occur via several HTTP APIs, Redis, Amazon S3, and Amazon DynamoDB. We decided on this architecture so that our our system could be scalable in terms of storage and database throughput. This way we only need Django running on top of our database cluster. We use PostgreSQL as our database because it is considered an industry standard when it comes to clustering and scaling.

PaaS for back-end components, including external data ingestion APIs, front-end web service APIs, hosting of static front-end application assets, back-end data processing pipeline microservices, APIs to storage infrastructure (Cloud SQL and Memcached), and data processing pipeline task queues and cron jobs. Task queue fan-out and auto-scaling of back-end microservice instances provide parallelism for high velocity data processing. Google App Engine

Cloud instances to run our app, Cloud MySQL , Network Load Balancer Google App Engine