Many organizations today are using containers to package source code and dependencies into lightweight, immutable artifacts that can be deployed reliably to any environment.
Kubernetes (K8s) is an open-source framework for automated scheduling and management of containerized workloads. In addition to master nodes, a K8s cluster is made up of worker nodes where containers are scheduled and run.
Amazon Elastic Container Service for Kubernetes (Amazon EKS) is a managed service that removes the need to manage the installation, scaling, or administration of master nodes and the etcd distributed key-value store. It provides a highly available and secure K8s control plane.
This post demonstrates how to use Spot Instances as K8s worker nodes, and shows the areas of provisioning, automatic scaling, and handling interruptions (termination) of K8s worker nodes across your cluster.
What this post does not cover
This post focuses primarily on EC2 instance scaling. This post also assumes a default interruption mode of terminate for EC2 instances, though there are other interruption types, stop and hibernate. For stateless K8s sessions, I recommend choosing the interruption mode of terminate.
Personalizing content helps to drive subscriptions, improve revenue, and increase retention rates by providing a more engaging and responsive customer experience. In this blog post, we’ll show you how to build a serverless subscription service for your website that personalizes and monetizes content by using Amazon CloudFront and AWS Lambda@Edge.
Customers have typically used content delivery networks (CDNs) to reduce latency for global applications by serving content closer to their users. Since we announced Lambda@Edge in December 2016, customers have also started using Lambda functions to shift compute-heavy processing to the edge. By using Lambda@Edge, developers can build and continuously deliver features in edge locations, closer to their users and web consumers. Using CloudFront and Lambda@Edge together helps you to build and provide highly-performant online experiences. Using serverless applications at the edge also helps you avoid managing an extra tier of infrastructure at the origin.
If you’re just learning about Lambda@Edge, we recommend checking out the Get Started section in the documentation first, before you read this article, to get a general understanding about how Lambda@Edge works.
In our example application for personalizing content, users must register first, so that we can show them content that is most relevant to them. We use Lambda@Edge to validate registered users by authenticating them. For simplicity, we haven’t included a customer registration page but it’s straightforward to include one in your web flow. If someone is visiting your site for the first time, you can redirect them to a registration page, and then attach an entitlement to the profile to permit them to perform actions based on the level of their subscription.
There are a number of reasons to use Lambda@Edge when you build a subscription service. For example, you and your customers can gain the following benefits:
- Lambda@Edge is a serverless computing platform, which has several advantages. There’s no infrastructure to manage when you use it. It’s an event-driven system, so you only pay for the service when an event is triggered. It scales automatically based on the demand. And, finally, it’s highly available.
- A Lambda@Edge function runs closer to the viewer, so users have a better experience with faster response times.
- The load on your origin is reduced because you can offload some CPU-intensive applications and processes from your web and app servers. Caching at the edge further reduces the load on your origin.
- You can control your user journey in a more fine-grained manner, so you can, for example, implement micropayments, micro-subscriptions, bots management, and metering content. These features help your website to interact in innovative ways with customers and frequent viewers.
- The AWS ecosystem includes more than 100 managed services that you can integrate with. For example, you can build analytics based on the logs generated on Lambda@Edge, CloudFront, and CloudWatch.
- You can promote advertisements on your articles that align with your brand and opinion by using Lambda@Edge to provide relevant tags to advertising platforms at the Edge, allowing you to further drive revenue based on the viewer’s subscription level.
For the first time ever, Serverlessconf was held in San Francisco! Serverlessconf is a community led conference focused on sharing experiences building applications using serverless architectures. Serverless architectures enable developers to express their creativity and focus on user needs instead of spending time managing infrastructure and servers. Watch the first release of talks from the main stage at Serverlessconf San Francisco 2018! The first 24 videos are now live, with more to come!
Private registry authentication support for Amazon Elastic Container Service (Amazon ECS) is now available with the AWS Fargate launch type! Now, in addition to Amazon Elastic Container Registry (Amazon ECR), you can use any private registry or repository of your choice for both EC2 and Fargate launch types.
For ECS to pull from a private repository, it needs a secret in AWS Secrets Manager with your registry credentials, an ECS task execution IAM role in AWS Identity Access Management (IAM) with a policy granting access to the secret, and a task with the secret and task execution IAM role ARNs in the task definition.
Whether you are new to the the cloud and AWS or an experienced cloud developer, this guide is designed to help you get started with Docker containers on AWS ECS and AWS Fargate quickly and easily.
If you are brand new to the cloud or containers you should first read the introduction to cloud and container concepts.
If you already feel familiar with Docker containers, and just want to deploy your containerized application quickly and reliably head to the architecture patterns section to find a collection of infrastructure as code examples for popular application architectures. You can either deploy the templates onto your own AWS account in a few clicks, or download them to customize or use as a reference for developing your own application template.
This post discusses how maps are implemented in Go. It is based on a presentation I gave at the GoCon Spring 2018 conference in Tokyo, Japan.
What is a map function?
To understand how a map works, let’s first talk about the idea of the map function. A map function maps one value to another. Given one value, called a key, it will return a second, the value.
map(key) → value
Now, a map isn’t going to be very useful unless we can put some data in the map. We’ll need a function that adds data to the map
insert(map, key, value)
and a function that removes data from the map
There are other interesting properties of map implementations like querying if a key is present in the map, but they’re outside the scope of what we’re going to discuss today. Instead we’re just going to focus on these properties of a map; insertion, deletion and mapping keys to values.
As more and more developers and companies adopt serverless architecture, the likelihood of hackers exploiting these applications increases dramatically. The shared security model of cloud providers extends much further with serverless offerings, but application security is still the developer’s responsibility. There has been a lot of hype about #NoOPS with serverless environments 🤥, which is simply not true 😡. Many traditional applications are frontended with WAFs (web application firewalls), RASPs (runtime application self-protection), EPPs (endpoint protection platforms) and WSGs (web security gateways) that inspect incoming and outgoing traffic. These extra layers of protection can save developers from themselves when making common programming mistakes that would otherwise leave their applications vulnerable. With serverless, these all go away. 😳
Serverless makes it easy to deploy a function to the cloud and not think about the infrastructure it’s running on. While certainly convenient, this leaves many developers with a false sense of security. By relying too heavily on the cloud provider, and not coding defensively, developers can significantly reduce their overall security posture. As with any type of software, there are a myriad of attacks possible against serverless infrastructures. However, unlike traditional web applications, serverless architectures are “event-driven”. This means they can be triggered by a number of different sources with multiple formats and encodings, rendering WAFs useless and opening up a completely new attack vector…