Feed powered byStream Blue Logo Copy 5Created with Sketch.
Kubernetes

Kubernetes

DevOps / Build, Test, Deploy / Container Tools

Decision at Soluto about Docker Swarm, Kubernetes, Visual Studio Code, Go, TypeScript, JavaScript, C#, F#, .NET

Avatar of Yshayy
Software Engineer ·
Docker SwarmDocker Swarm
KubernetesKubernetes
Visual Studio CodeVisual Studio Code
GoGo
TypeScriptTypeScript
JavaScriptJavaScript
C#C#
F#F#
.NET.NET

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...

17 upvotes·1 comment·26.2K views

Decision at Dubsmash about Kubernetes, Amazon EC2, Heroku, Python, ContainerTools, PlatformAsAService

Avatar of tspecht
‎Co-Founder and CTO at Dubsmash ·
KubernetesKubernetes
Amazon EC2Amazon EC2
HerokuHeroku
PythonPython
#ContainerTools
#PlatformAsAService

Since we deployed our very first lines of Python code more than 2 years ago we are happy users of Heroku. It lets us focus on building features rather than maintaining infrastructure, has super-easy scaling capabilities, and the support team is always happy to help (in the rare case you need them).

We played with the thought of moving our computational needs over to barebone Amazon EC2 instances or a container-management solution like Kubernetes a couple of times, but the added costs of maintaining this architecture and the ease-of-use of Heroku have kept us from moving forward so far.

Running independent services for different needs of our features gives us the flexibility to choose whatever data storage is best for the given task.

#PlatformAsAService #ContainerTools

14 upvotes·636 views

Decision at Stitch about Go, Clojure, JavaScript, Python, Kubernetes, AWS OpsWorks, Amazon EC2, Amazon Redshift, Amazon S3, Amazon RDS

Avatar of jakestein
CEO at Stitch ·
GoGo
ClojureClojure
JavaScriptJavaScript
PythonPython
KubernetesKubernetes
AWS OpsWorksAWS OpsWorks
Amazon EC2Amazon EC2
Amazon RedshiftAmazon Redshift
Amazon S3Amazon S3
Amazon RDSAmazon RDS

Stitch is run entirely on AWS. All of our transactional databases are run with Amazon RDS, and we rely on Amazon S3 for data persistence in various stages of our pipeline. Our product integrates with Amazon Redshift as a data destination, and we also use Redshift as an internal data warehouse (powered by Stitch, of course).

The majority of our services run on stateless Amazon EC2 instances that are managed by AWS OpsWorks. We recently introduced Kubernetes into our infrastructure to run the scheduled jobs that execute Singer code to extract data from various sources. Although we tend to be wary of shiny new toys, Kubernetes has proven to be a good fit for this problem, and its stability, strong community and helpful tooling have made it easy for us to incorporate into our operations.

While we continue to be happy with Clojure for our internal services, we felt that its relatively narrow adoption could impede Singer's growth. We chose Python both because it is well suited to the task, and it seems to have reached critical mass among data engineers. All that being said, the Singer spec is language agnostic, and integrations and libraries have been developed in JavaScript, Go, and Clojure.

13 upvotes·931 views

Decision at Shopify about Google Kubernetes Engine, Kubernetes, Docker

Avatar of kirs
Production Engineer at Shopify ·
Google Kubernetes EngineGoogle Kubernetes Engine
KubernetesKubernetes
DockerDocker

We use Docker, Kubernetes, and Google Kubernetes Engine to make it easy to bootstrap resources for new Shopify pods.

Over the years, we moved from shards to the concept of "pods". A pod is a fully isolated instance of Shopify with its own datastores like MySQL, Redis, memcached. As we grew into hundreds of shards and pods, it became clear that we needed a solution to orchestrate those deployments.

11 upvotes·457 views

Decision at CodeFactor about Google Cloud Functions, Azure Functions, AWS Lambda, Docker, Google Compute Engine, Microsoft Azure, Amazon EC2, CodeFactor.io, Kubernetes, Devops, AI, Machinelearning, Automation, Startup, Autoscale, Containerization, IAAS, SAAS

Avatar of kaskas
Entrepreneur & Engineer ·
Google Cloud FunctionsGoogle Cloud Functions
Azure FunctionsAzure Functions
AWS LambdaAWS Lambda
DockerDocker
Google Compute EngineGoogle Compute Engine
Microsoft AzureMicrosoft Azure
Amazon EC2Amazon EC2
CodeFactor.ioCodeFactor.io
KubernetesKubernetes
#Devops
#AI
#Machinelearning
#Automation
#Startup
#Autoscale
#Containerization
#IAAS
#SAAS

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.

10 upvotes·8.2K views

Decision at AppAttack about Kubernetes, DigitalOcean, CloudHosting

Avatar of ctbucha
Founder/CEO at AppAttack ·
KubernetesKubernetes
DigitalOceanDigitalOcean
#CloudHosting

I use DigitalOcean because of the simplicity of using their basic offerings, such as droplets. In AppAttack, we need low-level control of our infrastructure so we can rapidly deploy a custom training web application on-demand for each training session, and building a Kubernetes cluster on top of DigitalOcean droplets allowed us to do exactly that.

#CloudHosting

9 upvotes·16.8K views

Decision at The New York Times about Kubernetes, Google Kubernetes Engine, Google App Engine, Amazon EC2, Migration, AWS, GCP, AWStoGCPmigration, Cloudmigration

Avatar of nsrockwell
CTO at NY Times ·
KubernetesKubernetes
Google Kubernetes EngineGoogle Kubernetes Engine
Google App EngineGoogle App Engine
Amazon EC2Amazon EC2
#Migration
#AWS
#GCP
#AWStoGCPmigration
#Cloudmigration

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

5 upvotes·593 views

Decision at uSwitch about Kubernetes, Prometheus, Thanos

Avatar of Joseph-Irving
DevOps Engineer at uSwitch ·
KubernetesKubernetes
PrometheusPrometheus
ThanosThanos

We recently implemented Thanos alongside Prometheus into our Kubernetes clusters, we had previously used a variety of different metrics systems and we wanted to make life simpler for everyone by just picking one.

Prometheus seemed like an obvious choice due to its powerful querying language, native Kubernetes support and great community. However we found it somewhat lacking when it came to being highly available, something that would be very important if we wanted this to be the single source of all our metrics.

Thanos came along and solved a lot of these problems. It allowed us to run multiple Prometheis without duplicating metrics, query multiple Prometheus clusters at once, and easily back up data and then query it. Now we have a single place to go if you want to view metrics across all our clusters, with many layers of redundancy to make sure this monitoring solution is as reliable and resilient as we could reasonably make it.

If you're interested in a bit more detail feel free to check out the blog I wrote on the subject that's linked.

4 upvotes·415 views

Decision at Zulip about Kubernetes, Docker

Avatar of tabbott
Founder at Zulip ·
KubernetesKubernetes
DockerDocker

We recently adopted the (previously community-developed) Docker image for Zulip, and I've gotten a bunch of experience as part of this process. We didn't have a lot of choice as to whether to use Docker -- as an open source web application, installation options are driven by what users are asking for, and in the container world, that's a Docker image.

To be honest, maintaining a Docker image is kind of a pain, even for something like Zulip where our Debian/Ubuntu install process is super clean and reliable. Docker requires you to run your application's installer in a totally crippled environment (E.g. no unicode locales are installed, so using pip to build Python packages doesn't work until you fix that) to generate a working Dockerfile. But the real pain is the fact that Docker users expect to configure everything via environment variables in e.g. a docker-compose.yml or similar Kubernetes configuration file.

And that results in just about every Docker image for a reusable web application having a giant docker-entrypoint.sh script of semi-duplicated code (ours is currently ~600LOC; those for other popular projects can easily be 2-3X that size) that does a bunch of stuff, including pass what is structurally an array through a shell environment variable and back into our Python-format settings file, which is just a mess.

Since that shell script can have bugs, this is a big maintenance (e.g. right now probably a third of user reports of issues installing a new Zulip server are Docker-specific issues, even though Docker installations are a small fraction of total installations).

Further, a lot of third-party images (e.g. for postgres or redis or RabbitMQ) end up having issues where they have an environment variable for configuring something (E.g. a postgres password), but if you change that variable after the postgres image is first booted, nothing happens, which can be confusing for users (who often assume they can just boot their image with whatever password and clean up the security stuff later).

So, while the Docker/containers ecosystem has a lot of promise, I also feel it has a long way to go before providing a Docker image isn't a significant burden on projects, even ones like us that already have a battle-tested installation process.

3 upvotes·1.4K views

Decision at Troops about Serverless, Amazon EC2, Kubernetes, Amazon EKS

Avatar of gratner
Co-Founder, CTO at Troops ·
ServerlessServerless
Amazon EC2Amazon EC2
KubernetesKubernetes
Amazon EKSAmazon EKS

We are moving all of our infrastructure to Amazon EKS on Kubernetes from our our Amazon EC2 hosts. This gives less management overhead, host security and networking and aides a lot of compliance headaches since it's a Serverless architecture.

2 upvotes·430 views