What is Google Kubernetes Engine and what are its top alternatives?
Top Alternatives to Google Kubernetes 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. ...
- Red Hat OpenShift
OpenShift is Red Hat's Cloud Computing Platform as a Service (PaaS) offering. OpenShift is an application platform in the cloud where application developers and teams can build, test, deploy, and run their applications. ...
- Google Compute Engine
Google Compute Engine is a service that provides virtual machines that run on Google infrastructure. Google Compute Engine offers scale, performance, and value that allows you to easily launch large compute clusters on Google's infrastructure. There are no upfront investments and you can run up to thousands of virtual CPUs on a system that has been designed from the ground up to be fast, and to offer strong consistency of performance. ...
- Kubernetes
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. ...
- Amazon EC2 Container Service
Amazon EC2 Container Service lets you launch and stop container-enabled applications with simple API calls, allows you to query the state of your cluster from a centralized service, and gives you access to many familiar Amazon EC2 features like security groups, EBS volumes and IAM roles. ...
- Amazon EKS
Amazon Elastic Container Service for Kubernetes (Amazon EKS) is a managed service that makes it easy for you to run Kubernetes on AWS without needing to install and operate your own Kubernetes clusters. ...
- AWS Fargate
AWS Fargate is a technology for Amazon ECS and EKS* that allows you to run containers without having to manage servers or clusters. With AWS Fargate, you no longer have to provision, configure, and scale clusters of virtual machines to run containers. ...
- Azure Kubernetes Service
Deploy and manage containerized applications more easily with a fully managed Kubernetes service. It offers serverless Kubernetes, an integrated continuous integration and continuous delivery (CI/CD) experience, and enterprise-grade security and governance. Unite your development and operations teams on a single platform to rapidly build, deliver, and scale applications with confidence. ...
Google Kubernetes Engine alternatives & related posts
Google App Engine
- Easy to deploy144
- Auto scaling106
- Good free plan80
- Easy management62
- Scalability56
- Low cost35
- Comprehensive set of features32
- All services in one place28
- Simple scaling22
- Quick and reliable cloud servers19
- Granular Billing6
- Easy to develop and unit test5
- Monitoring gives comprehensive set of key indicators4
- Really easy to quickly bring up a full stack3
- Create APIs quickly with cloud endpoints3
- No Ops2
- Mostly up2
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.
Red Hat OpenShift
- Good free plan99
- Open Source63
- Easy setup47
- Nodejs support43
- Well documented42
- Custom domains32
- Mongodb support28
- Clean and simple architecture27
- PHP support25
- Customizable environments21
- Ability to run CRON jobs11
- Easier than Heroku for a WordPress blog9
- Easy deployment8
- PostgreSQL support7
- Autoscaling7
- Good balance between Heroku and AWS for flexibility7
- Free, Easy Setup, Lot of Gear or D.I.Y Gear5
- Shell access to gears4
- Great Support3
- High Security3
- Logging & Metrics3
- Cloud Agnostic2
- Runs Anywhere - AWS, GCP, Azure2
- No credit card needed2
- Because it is easy to manage2
- Secure2
- Meteor support2
- Overly complicated and over engineered in majority of e2
- Golang support2
- Its free and offer custom domain usage2
- Autoscaling at a good price point1
- Easy setup and great customer support1
- MultiCloud1
- Great free plan with excellent support1
- This is the only free one among the three as of today1
- Decisions are made for you, limiting your options2
- License cost2
- Behind, sometimes severely, the upstreams1
related Red Hat OpenShift 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:
https://eng.uber.com/distributed-tracing/
(GitHub Pages : https://www.jaegertracing.io/, GitHub: https://github.com/jaegertracing/jaeger)
Bindings/Operator: Python Java Node.js Go C++ Kubernetes JavaScript OpenShift C# Apache Spark
We use Kubernetes because we decided to migrate to a hosted cluster (not AWS) and still be able to scale our clusters up and down depending on load. By wrapping it with OpenShift we are now able to easily adapt to demand but also able to separate concerns into separate Pods depending on use-cases we have.
Google Compute Engine
- Backed by google87
- Easy to scale79
- High-performance virtual machines75
- Performance58
- Fast and easy provisioning52
- Load balancing15
- Compliance and security12
- Kubernetes9
- GitHub Integration8
- Consistency7
- Good documentation3
- One Click Setup Options3
- Free $300 credit (12 months)3
- Ease of Use and GitHub support2
- Great integration and product support2
- Escort2
- Integration with mobile notification services1
- Easy Snapshot and Backup feature1
- Low cost1
- Support many OS1
- Very Reliable1
- Nice UI1
related Google Compute Engine posts





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.
Google Compute Engine Amazon Web Services OVH Microsoft Azure Go GitHub
Last week, we released a fresh new release of Komiser with support of multiple AWS accounts. Komiser support multiple AWS accounts through named profiles that are stored in the credentials files.
You can now analyze and identify potential cost savings on unlimited AWS environments (Production, Staging, Sandbox, etc) on one single dashboard.
Read the full story in the blog post.
Kubernetes
- Leading docker container management solution164
- Simple and powerful128
- Open source106
- Backed by google76
- The right abstractions58
- Scale services25
- Replication controller20
- Permission managment11
- Cheap8
- Supports autoscaling8
- Simple8
- No cloud platform lock-in5
- Reliable5
- Self-healing5
- Quick cloud setup4
- Promotes modern/good infrascture practice4
- Scalable4
- Open, powerful, stable4
- Runs on azure3
- Captain of Container Ship3
- Cloud Agnostic3
- Custom and extensibility3
- Backed by Red Hat3
- A self healing environment with rich metadata3
- Gke2
- Everything of CaaS2
- Sfg2
- Expandable2
- Golang2
- Easy setup2
- Poor workflow for development15
- Steep learning curve15
- Orchestrates only infrastructure8
- High resource requirements for on-prem clusters4
- Too heavy for simple systems2
- Additional vendor lock-in (Docker)1
- More moving parts to secure1
- Additional Technology Overhead1
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:
https://eng.uber.com/distributed-tracing/
(GitHub Pages : https://www.jaegertracing.io/, GitHub: https://github.com/jaegertracing/jaeger)
Bindings/Operator: Python Java Node.js Go C++ Kubernetes JavaScript OpenShift C# Apache Spark
Our first experience with .NET core was when we developed our OSS feature management platform - Tweek (https://github.com/soluto/tweek). We wanted to create a solution that is able to run anywhere (super important for OSS), has excellent performance characteristics and can fit in a multi-container architecture. We decided to implement our rule engine processor in F# , our main service was implemented in C# and other components were built using JavaScript / TypeScript and Go.
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...
Amazon EC2 Container Service
- Backed by amazon100
- Familiar to ec272
- Cluster based53
- Simple API42
- Iam roles26
- Scheduler7
- Cluster management7
- Programmatic Control7
- Socker support4
- Container-enabled applications4
- No additional cost2
- Easy to use and cheap1
related Amazon EC2 Container Service posts





We build a Slack app using the Bolt framework from slack https://api.slack.com/tools/bolt, a Node.js express app. It allows us to easily implement some administration features so we can easily communicate with our backend services, and we don't have to develop any frontend app since Slack block kit will do this for us. It can act as a Chatbot or handle message actions and custom slack flows for our employees.
This app is deployed as a microservice on Amazon EC2 Container Service with AWS Fargate. It uses very little memory (and money) and can communicate easily with our backend services. Slack is connected to this app through a ALB ( AWS Elastic Load Balancing (ELB) )
We began our hosting journey, as many do, on Heroku because they make it easy to deploy your application and automate some of the routine tasks associated with deployments, etc. However, as our team grew and our product matured, our needs have outgrown Heroku. I will dive into the history and reasons for this in a future blog post.
We decided to migrate our infrastructure to Kubernetes running on Amazon EKS. Although Google Kubernetes Engine has a slightly more mature Kubernetes offering and is more user-friendly; we decided to go with EKS because we already using other AWS services (including a previous migration from Heroku Postgres to AWS RDS). We are still in the process of moving our main website workloads to EKS, however we have successfully migrate all our staging and testing PR apps to run in a staging cluster. We developed a Slack chatops application (also running in the cluster) which automates all the common tasks of spinning up and managing a production-like cluster for a pull request. This allows our engineering team to iterate quickly and safely test code in a full production environment. Helm plays a central role when deploying our staging apps into the cluster. We use CircleCI to build docker containers for each PR push, which are then published to Amazon EC2 Container Service (ECR). An upgrade-operator
process watches the ECR repository for new containers and then uses Helm to rollout updates to the staging environments. All this happens automatically and makes it really easy for developers to get code onto servers quickly. The immutable and isolated nature of our staging environments means that we can do anything we want in that environment and quickly re-create or restore the environment to start over.
The next step in our journey is to migrate our production workloads to an EKS cluster and build out the CD workflows to get our containers promoted to that cluster after our QA testing is complete in our staging environments.
- Better control1
- Possibility to log in into the pods1
- Broad package manager using helm1
related Amazon EKS posts
We are looking for a centralised monitoring solution for our application deployed on Amazon EKS. We would like to monitor using metrics from Kubernetes, AWS services (NeptuneDB, AWS Elastic Load Balancing (ELB), Amazon EBS, Amazon S3, etc) and application microservice's custom metrics.
We are expected to use around 80 microservices (not replicas). I think a total of 200-250 microservices will be there in the system with 10-12 slave nodes.
We tried Prometheus but it looks like maintenance is a big issue. We need to manage scaling, maintaining the storage, and dealing with multiple exporters and Grafana. I felt this itself needs few dedicated resources (at least 2-3 people) to manage. Not sure if I am thinking in the correct direction. Please confirm.
You mentioned Datadog and Sysdig charges per host. Does it charge per slave node?
Heroku was a decent choice to start a business, but at some point our platform was too big, too complex & too heterogenic, so Heroku started to be a constraint, not a benefit. First, we've started containerizing our apps with Docker to eliminate "works in my machine" syndrome & uniformize the environment setup. The first orchestration was composed with Docker Compose , but at some point it made sense to move it to Kubernetes. Fortunately, we've made a very good technical decision when starting our work with containers - all the container configuration & provisions HAD (since the beginning) to be done in code (Infrastructure as Code) - we've used Terraform & Ansible for that (correspondingly). This general trend of containerisation was accompanied by another, parallel & equally big project: migrating environments from Heroku to AWS: using Amazon EC2 , Amazon EKS, Amazon S3 & Amazon RDS.
- Expensive1
related AWS Fargate posts





We build a Slack app using the Bolt framework from slack https://api.slack.com/tools/bolt, a Node.js express app. It allows us to easily implement some administration features so we can easily communicate with our backend services, and we don't have to develop any frontend app since Slack block kit will do this for us. It can act as a Chatbot or handle message actions and custom slack flows for our employees.
This app is deployed as a microservice on Amazon EC2 Container Service with AWS Fargate. It uses very little memory (and money) and can communicate easily with our backend services. Slack is connected to this app through a ALB ( AWS Elastic Load Balancing (ELB) )
Azure Kubernetes Service
related Azure Kubernetes Service posts
Visual Studio Azure DevOps Azure Functions Azure Websites #Azure #AzureKeyVault #AzureAD #AzureApps
#Azure Cloud Since Amazon is potentially our competitor then we need a different cloud vendor, also our programmers are microsoft oriented so the choose were obviously #Azure for us.
Azure DevOps Because we need to be able to develop a neww pipeline into Azure environment ina few minutes.
Azure Kubernetes Service We already in #Azure , also need to use K8s , so let's use AKS as it's a manged Kubernetes in the #Azure