What is Google Compute Engine and what are its top alternatives?
Top Alternatives to Google Compute Engine
Google App Engine
Google has a reputation for highly reliable, high performance infrastructure. With App Engine you can take advantage of the 10 years of knowledge Google has in running massively scalable, performance driven systems. App Engine applications are easy to build, easy to maintain, and easy to scale as your traffic and data storage needs grow. ...
We take the complexities out of cloud hosting by offering blazing fast, on-demand SSD cloud servers, straightforward pricing, a simple API, and an easy-to-use control panel. ...
Google Cloud Platform
It helps you build what's next with secure infrastructure, developer tools, APIs, data analytics and machine learning. It is a suite of cloud computing services that runs on the same infrastructure that Google uses internally for its end-user products, such as Google Search and YouTube. ...
It is a web service that provides resizable compute capacity in the cloud. It is designed to make web-scale computing easier for developers. ...
Azure is an open and flexible cloud platform that enables you to quickly build, deploy and manage applications across a global network of Microsoft-managed datacenters. You can build applications using any language, tool or framework. And you can integrate your public cloud applications with your existing IT environment. ...
Kubernetes is an open source orchestration system for Docker containers. It handles scheduling onto nodes in a compute cluster and actively manages workloads to ensure that their state matches the users declared intentions. ...
Get a server running in minutes with your choice of Linux distro, resources, and node location. ...
Rackspace Cloud Servers
Cloud Servers is based on OpenStack, the open and scalable operating system for building public and private clouds. With the open cloud, you get reliable cloud hosting, without locking your data into one proprietary platform. ...
Google Compute Engine alternatives & related posts
- Easy to deploy143
- Auto scaling108
- Good free plan80
- Easy management64
- Low cost36
- Comprehensive set of features33
- All services in one place29
- Simple scaling23
- Quick and reliable cloud servers20
- Granular Billing5
- Easy to develop and unit test4
- Monitoring gives comprehensive set of key indicators3
- Create APIs quickly with cloud endpoints2
- Really easy to quickly bring up a full stack2
- Mostly up1
- No Ops1
related Google App Engine posts
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
In #Aliadoc, we're exploring the crowdfunding option to get traction before launch. We are building a SaaS platform for website design customization.
For the Admin UI and website editor we use React and we're currently transitioning from a Create React App setup to a custom one because our needs have become more specific. We use CloudFlare as much as possible, it's a great service.
For routing dynamic resources and proxy tasks to feed websites to the editor we leverage CloudFlare Workers for improved responsiveness. We use Firebase for our hosting needs and user authentication while also using several Cloud Functions for Firebase to interact with other services along with Google App Engine and Google Cloud Storage, but also the Real Time Database is on the radar for collaborative website editing.
We generally hate configuration but honestly because of the stage of our project we lack resources for doing heavy sysops work. So we are basically just relying on Serverless technologies as much as we can to do all server side processing.
Visual Studio Code definitively makes programming a much easier and enjoyable task, we just love it. We combine it with Bitbucket for our source code control needs.
- Great value for money557
- Simple dashboard363
- Good pricing355
- Nice ui248
- Easy configuration192
- Great documentation155
- Ssh access137
- Great community134
- IPv6 support12
- Private networking10
- Great tutorials7
- Simple API7
- 99.99% uptime SLA7
- 55 Second Provisioning6
- One Click Applications5
- 1Gb/sec Servers3
- Simple Control Panel3
- Word Press3
- Runs CoreOS2
- Quick and no nonsense service2
- Good Tutorials2
- Ruby on Rails2
- Hex Core machines with dedicated ECC Ram and RAID SSD s2
- My go to server provider1
- Ease and simplicity1
- Find it superfitting with my requirements (SSD, ssh.1
- Easy Setup1
- Transfer Globally1
- FreeBSD Amp1
- Amazing Hardware1
- KVM Virtualization1
- Static IP1
- It's the easiest to get started for small projects1
- Automatic Backup1
- Great support1
- Quick and easy to set up1
- Servers on demand - literally1
- Variety of services0
- Managed Kubernetes0
- No live support chat2
related DigitalOcean posts
I am going to build a backend which will serve my React site. It will need to interact with a PostgreSQL database where it will store and read users and create and use JSON Web Token for authenticating HTTP requests. I know EF core has good migration tooling, can Go provide the same or better? I am a one man team and I'll be hosting this either on Heroku or DigitalOcean.
Building my skill set to become Devops Engineer-Tool chain: Amazon EC2, Amazon S3, Bitbucket, GitLab, PyCharm, Ubuntu, DigitalOcean, Docker, Git
IT engineer with more than 6 months of experience in startups with focus on DevOps, Cloud infrastructure & Testing (QA). I had set up CI process, monitoring and infrastructure on dev/test (lower) environments
- 1 year free trial credit USD3003
- Good app Marketplace for Beginner and Advanced User2
- Premium tier IP address2
- Live chat support1
related Google Cloud Platform posts
I am currently working on a long term mobile app project. Current stack: Frontend: Dart/Flutter Backend: Go, AWS Resources (AWS Lambda, Amazon DynamoDB, etc.) Since there are only two developers and we have limited time and resources, we are looking for a BAAS like Firebase or AWS Amplify to handle auth and push notifications for now. We are prioritizing developing speed so we can iterate quickly. The only problem is that AWS amplify support for flutter is in developer preview and has limited capabilities (We have tested it out in our app). Firebase is the more mature option. It has great support for flutter and has more than we need for auth, notifications, etc. My question is that, if we choose firebase, we would be stuck with using two different cloud providers. Is this bad, or is this even a problem? I am willing to change anything on the backend architecture wise, so any suggestions would be greatly appreciated as I am somewhat unfamiliar with Google Cloud Platform. Thank you.
We use Google Cloud Platform, Microsoft Azure and Amazon S3 (amongst others) because our platform needs to be cloud-independent to give customers the freedom they need and deserve. But being in the healthcare enterprise space, we believe Azure is the top choice... today (it tends to change often).
- Quick and reliable cloud servers644
- Easy management391
- Low cost276
- Market leader88
- Backed by amazon80
- Free tier66
- Easy management, scalability57
- Easy to Start10
- Widely used8
- Node.js API7
- Industry Standard4
- Lots of configuration options3
- GPU instances2
- Amazing for individuals1
- Extremely simple to use1
- All the Open Source CLI tools you could want.1
- Simpler to understand and learn1
- Ui could use a lot of work13
- High learning curve when compared to PaaS6
- Extremely poor CPU performance3
related Amazon EC2 posts
To provide employees with the critical need of interactive querying, we’ve worked with Presto, an open-source distributed SQL query engine, over the years. Operating Presto at Pinterest’s scale has involved resolving quite a few challenges like, supporting deeply nested and huge thrift schemas, slow/ bad worker detection and remediation, auto-scaling cluster, graceful cluster shutdown and impersonation support for ldap authenticator.
Our infrastructure is built on top of Amazon EC2 and we leverage Amazon S3 for storing our data. This separates compute and storage layers, and allows multiple compute clusters to share the S3 data.
We have hundreds of petabytes of data and tens of thousands of Apache Hive tables. Our Presto clusters are comprised of a fleet of 450 r4.8xl EC2 instances. Presto clusters together have over 100 TBs of memory and 14K vcpu cores. Within Pinterest, we have close to more than 1,000 monthly active users (out of total 1,600+ Pinterest employees) using Presto, who run about 400K queries on these clusters per month.
Each query submitted to Presto cluster is logged to a Kafka topic via Singer. Singer is a logging agent built at Pinterest and we talked about it in a previous post. Each query is logged when it is submitted and when it finishes. When a Presto cluster crashes, we will have query submitted events without corresponding query finished events. These events enable us to capture the effect of cluster crashes over time.
Each Presto cluster at Pinterest has workers on a mix of dedicated AWS EC2 instances and Kubernetes pods. Kubernetes platform provides us with the capability to add and remove workers from a Presto cluster very quickly. The best-case latency on bringing up a new worker on Kubernetes is less than a minute. However, when the Kubernetes cluster itself is out of resources and needs to scale up, it can take up to ten minutes. Some other advantages of deploying on Kubernetes platform is that our Presto deployment becomes agnostic of cloud vendor, instance types, OS, etc.
#BigData #AWS #DataScience #DataEngineering
Our whole DevOps stack consists of the following tools:
- GitHub (incl. GitHub Pages/Markdown for Documentation, GettingStarted and HowTo's) for collaborative review and code management tool
- Respectively Git as revision control system
- SourceTree as Git GUI
- Visual Studio Code as IDE
- CircleCI for continuous integration (automatize development process)
- Prettier / TSLint / ESLint as code linter
- SonarQube as quality gate
- Docker as container management (incl. Docker Compose for multi-container application management)
- VirtualBox for operating system simulation tests
- Kubernetes as cluster management for docker containers
- Heroku for deploying in test environments
- nginx as web server (preferably used as facade server in production environment)
- SSLMate (using OpenSSL) for certificate management
- Amazon EC2 (incl. Amazon S3) for deploying in stage (production-like) and production environments
- PostgreSQL as preferred database system
- Redis as preferred in-memory database/store (great for caching)
The main reason we have chosen Kubernetes over Docker Swarm is related to the following artifacts:
- Key features: Easy and flexible installation, Clear dashboard, Great scaling operations, Monitoring is an integral part, Great load balancing concepts, Monitors the condition and ensures compensation in the event of failure.
- Applications: An application can be deployed using a combination of pods, deployments, and services (or micro-services).
- Functionality: Kubernetes as a complex installation and setup process, but it not as limited as Docker Swarm.
- Monitoring: It supports multiple versions of logging and monitoring when the services are deployed within the cluster (Elasticsearch/Kibana (ELK), Heapster/Grafana, Sysdig cloud integration).
- Scalability: All-in-one framework for distributed systems.
- Other Benefits: Kubernetes is backed by the Cloud Native Computing Foundation (CNCF), huge community among container orchestration tools, it is an open source and modular tool that works with any OS.
- Scales well and quite easy111
- Can use .Net or open source tools93
- Startup friendly79
- Startup plans via BizSpark72
- High performance61
- Wide choice of services36
- Lots of integrations31
- Low cost31
- Twillio & Github are directly accessible18
- RESTful API11
- Enterprise Grade9
- Startup support9
- In person support7
- Free for students6
- Virtual Machines5
- Service Bus5
- It rocks5
- Infrastructure Services4
- Storage, Backup, and Recovery4
- SQL Databases4
- Redis Cache4
- Built on Node.js3
- Big Data3
- BizSpark 60k Azure Benefit3
- Preview Portal3
- Big Compute2
- Machine Learning2
- Stream Analytics2
- Data Factory2
- Event Hubs2
- Virtual Network2
- Traffic Manager2
- Media Services2
- Operational Insights2
- Key Vault2
- Infrastructure near your customers2
- Easy Deployment2
- BizTalk Services2
- Site Recovery2
- Active Directory2
- Multi-Factor Authentication2
- Visual Studio Online2
- Application Insights2
- Remote Debugging1
- Enterprise customer preferences1
- Open cloud1
- Best cloud platfrom1
- Easy and fast to start with1
- Confusing UI5
- Expensive plesk on Azure2
related Microsoft Azure posts
We are hardcore Kubernetes users and contributors. We loved the automation it provides. However, as our team grew and added more clusters and microservices, capacity and resources management becomes a massive pain to us. We started suffering from a lot of outages and unexpected behavior as we promote our code from dev to production environments. Luckily we were working on our AI-powered tools to understand different dependencies, predict usage, and calculate the right resources and configurations that should be applied to our infrastructure and microservices. We dogfooded our agent (http://github.com/magalixcorp/magalix-agent) and were able to stabilize as the #autopilot continuously recovered any miscalculations we made or because of unexpected changes in workloads. We are open sourcing our agent in a few days. Check it out and let us know what you think! We run workloads on Microsoft Azure Google Kubernetes Engine and Amazon EC2 and we're all about Go and Python!
CodeFactor being a #SAAS product, our goal was to run on a cloud-native infrastructure since day one. We wanted to stay product focused, rather than having to work on the infrastructure that supports the application. We needed a cloud-hosting provider that would be reliable, economical and most efficient for our product.
CodeFactor.io aims to provide an automated and frictionless code review service for software developers. That requires agility, instant provisioning, autoscaling, security, availability and compliance management features. We looked at the top three #IAAS providers that take up the majority of market share: Amazon's Amazon EC2 , Microsoft's Microsoft Azure, and Google Compute Engine.
AWS has been available since 2006 and has developed the most extensive services ant tools variety at a massive scale. Azure and GCP are about half the AWS age, but also satisfied our technical requirements.
It is worth noting that even though all three providers support Docker containerization services, GCP has the most robust offering due to their investments in Kubernetes. Also, if you are a Microsoft shop, and develop in .NET - Visual Studio Azure shines at integration there and all your existing .NET code works seamlessly on Azure. All three providers have serverless computing offerings (AWS Lambda, Azure Functions, and Google Cloud Functions). Additionally, all three providers have machine learning tools, but GCP appears to be the most developer-friendly, intuitive and complete when it comes to #Machinelearning and #AI.
The prices between providers are competitive across the board. For our requirements, AWS would have been the most expensive, GCP the least expensive and Azure was in the middle. Plus, if you #Autoscale frequently with large deltas, note that Azure and GCP have per minute billing, where AWS bills you per hour. We also applied for the #Startup programs with all three providers, and this is where Azure shined. While AWS and GCP for startups would have covered us for about one year of infrastructure costs, Azure Sponsorship would cover about two years of CodeFactor's hosting costs. Moreover, Azure Team was terrific - I felt that they wanted to work with us where for AWS and GCP we were just another startup.
In summary, we were leaning towards GCP. GCP's advantages in containerization, automation toolset, #Devops mindset, and pricing were the driving factors there. Nevertheless, we could not say no to Azure's financial incentives and a strong sense of partnership and support throughout the process.
Bottom line is, IAAS offerings with AWS, Azure, and GCP are evolving fast. At CodeFactor, we aim to be platform agnostic where it is practical and retain the flexibility to cherry-pick the best products across providers.
- Leading docker container management solution151
- Simple and powerful121
- Open source95
- Backed by google70
- The right abstractions55
- Scale services24
- Replication controller16
- Permission managment9
- Supports autoscaling5
- Promotes modern/good infrascture practice3
- No cloud platform lock-in3
- Open, powerful, stable3
- A self healing environment with rich metadata2
- Captain of Container Ship2
- Quick cloud setup2
- Custom and extensibility1
- Easy setup1
- Backed by Red Hat1
- Everything of CaaS1
- Runs on azure1
- Cloud Agnostic1
- Poor workflow for development13
- Steep learning curve10
- Orchestrates only infrastructure4
- High resource requirements for on-prem clusters2
related Kubernetes posts
How Uber developed the open source, end-to-end distributed tracing Jaeger , now a CNCF project:
Distributed tracing is quickly becoming a must-have component in the tools that organizations use to monitor their complex, microservice-based architectures. At Uber, our open source distributed tracing system Jaeger saw large-scale internal adoption throughout 2016, integrated into hundreds of microservices and now recording thousands of traces every second.
Here is the story of how we got here, from investigating off-the-shelf solutions like Zipkin, to why we switched from pull to push architecture, and how distributed tracing will continue to evolve:
Visual Studio Code worked really well for us as well, it worked well with all our polyglot services and the .Net core integration had great cross-platform developer experience (to be fair, F# was a bit trickier) - actually, each of our team members used a different OS (Ubuntu, macos, windows). Our production deployment ran for a time on Docker Swarm until we've decided to adopt Kubernetes with almost seamless migration process.
After our positive experience of running .Net core workloads in containers and developing Tweek's .Net services on non-windows machines, C# had gained back some of its popularity (originally lost to Node.js), and other teams have been using it for developing microservices, k8s sidecars (like https://github.com/Soluto/airbag), cli tools, serverless functions and other projects...
- Extremely reliable100
- Good value70
- Easy to configure59
- Great customer support58
- Great documentation35
- Servers across the world24
- Managed/hosted DNS service18
- Simple ui14
- Network and CPU usage graphs11
- IPv6 support7
- Multiple IP address support5
- Ssh access3
- Good price, good cusomter sevice2
- IP address fail over support2
- SSH root access2
- Latest kernels1
- It runs apps with speed1
- Great performance compared to EC2 or DO1
- No "floating IP" support2
- Quick and reliable cloud servers41
- Great customer support29
- Uses OpenStack10
- Windows server 2012 possible2
- Easy integration with Github2
- Ssh access1