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.

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.

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.

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.

Service level objectives are an important tool for maintaining application performance, ensuring a consistent customer experience, and setting expectations about service performance for both internal and external users. We are very pleased to announce the availability of a new monitor uptime and SLO widget that makes it simple to monitor the status of your SLOs and communicate that status to your teams, executives, or external customers.

AWS introduced Lambda Layers at re:invent 2018 as a way to share code and data between functions within and across different accounts. It’s a useful tool and something many AWS customers have been asking for. However, since we already have numerous ways of sharing code, including package managers such as NPM, when should we use Layers instead? In this post, we will look at how Lambda Layers works, the problem it solves and the new challenges it introduces.