At FireHydrant we use Redux Form for all of our forms. It is extremely easy to build complex form logic with all sorts of added bonuses that make using it in our React/Redux front end a no brainer. However, when we started using React Select for our select fields we started running into some issues. You are likely running into some of the same issues we did and so this blog post will help get you off the ground and integrating these two libraries together.

Back in 2002 when I was a (very) junior programmer at a German enterprise software company I was lucky enough to be part of a small team that was building what you would now call a SaaS app. Up until now, the company had made all their profits by selling desktop software written in a language most people likely have never heard of: FoxPro. But instead of spending my days debugging FoxPro code, I was now green fielding JAVA web services.

It’s hard to believe, but 10 years ago AWS had only five products. Chief among them, of course, was EC2. Although it feels a little quaint now, back then EC2 was an incredible offering. Anyone could fire up a server in seconds, install some code, and transform that generic server into any service one could imagine.

Today Enterprise IT does not question the value of containerized applications anymore. Given the move to adopting DevOps and cloud native architectures, it is critical to leverage container capabilities in order to enable digital transformation. Google’s Kubernetes (K8s), an open source container orchestration system, has become the de facto standard — and the key enabler — for cloud native applications, and the way they are architected, composed, deployed, and managed.

LaunchDarkly has built an impressive feature flag management system that overages more than 200 billion feature flags per day. It has helped companies implement continuous deployment, A/B testing, infrastructure migrations and much more. It also enables canary launches (or dark launches) through its built-in support for percentage-based rollouts.

kube-proxy is a key component of any Kubernetes deployment. Its role is to load-balance traffic that is destined for services (via cluster IPs and node ports) to the correct backend pods. Kube-proxy can run in one of three modes, each implemented with different data plane technologies: userspace, iptables, or IPVS. The userspace mode is very old, slow, and definitely not recommended! But how should you weigh up whether to go with iptables or IPVS mode?

At Stackery, our engineers live and breathe serverless development every day. Because of this, we are constantly evaluating the current soundbites about it; when a field is expanding this quickly, it’s not uncommon to hear a generous handful of misguided assumptions. So, despite the increasing influence of cloudside development, there are still a number of declarations published every week that seem to amplify some common and outdated misconceptions.

It seems like hardly a week goes by without news of a security breach. Cyberattacks are becoming more frequent and more severe, costing businesses $600 billion per year according to the 2018 Economic Impact of Cybercrime report. Without a strong security policy in place, businesses risk falling victim to new threats while losing the trust of their customers.

In this post, we will walk through how to connect GitLab’s Auto DevOps feature with a Rancher-managed Kubernetes cluster, making use of a feature introduced in Rancher v2.2.0 called Authorized Cluster Endpoint. Readers can expect to walk away with an understanding of how GitLab integrates with Kubernetes and how Rancher simplifies this workflow with Authorized Cluster Endpoint.