Serverless Approach to Backup and Restore EBS Volumes

Amazon Elastic Compute Cloud (EC2) instances use Elastic Block Storage (EBS) as a root volume as well as an additional data store for applications. It is necessary to select a proper EBS volume type depending upon the workload to achieve high performance and the right approach to backup EBS volumes reqularly in production environments. We need a solution to backup and restore application data from EBS volume snapshots at any point of time and we should not pay an unnecessary cost for archiving the older snapshots. This article covers choosing the right EBS volume type for your application and provides a mechanism to handle EBS snapshots using serverless technology.

EBS Volume Types

Amazon EBS provides different volume types which have different performance characteristics and cost models. We can choose the volume type based on our application requirements (the type of the workload) to achieve higher performance as well as saving overall storage cost. EBS volume is available in two different categories, SSD-backed volumes and HDD-backed volumes. SSD backed volumes are used when the workload is I/O intensive, like transactional workloads where frequent read-writes happens in an application. Its performance is rated in IOPS. HDD-backed volumes are used when an application requires continuous read and write to the disk at a cheaper rate with high throughput. Its performance is rated in throughput MiB/s.

Distributed Data Querying With Alluxio

This blog is about how I used Alluxio to reduce p99 and p50 query latencies and optimized the overall platform costs for a distributed querying application. I walk through the product and architecture decisions that lead to our final architecture, discuss the tradeoffs, share some statistics on the improvements, and discuss future improvements to the system.

Description

A wireframe of a dashboard with drag and drop functionality.


The Top 3 Things Holding Back Your Kubernetes Strategy and How to Fix Them

A reported 69% of organizations surveyed by CNCF (the Cloud Native Computing Foundation) use Kubernetes to manage containers. As Kubernetes becomes the new standard for container orchestration, a new set of challenges result and enterprises are often spending significant time focused on managing their Kubernetes deployments rather than innovating. The most common barriers are around security vulnerabilities and lack of trust, scarcity of skills and expertise, and navigating storage needs. 

Why Kubernetes?

We can all agree that our industry is prone to hype and sometimes we feel the pressure of adopting a new technology simply because our peers and competitors do. Before diving into challenges of adopting Kubernetes (K8s), let’s remind ourselves of why someone should (or shouldn’t) bother.

Watch Out for These Five Kubernetes Storage Potholes

Kubernetes and containers have been revelatory for application development, but they’re not the complete solutions enterprises might like them to be. Yes, both address organizations’ long-held desires for agility, efficiency, and accelerated application development. However, there remain some missing elements that may hold back Kubernetes’ explosive adoption rate for mission-critical workloads in the modern enterprise.

All of these elements can be traced back to the fact that neither Kubernetes nor containers feature native storage. Although historically seen as an afterthought by developers, storage remains an essential component for enterprise applications, especially in the age of containers.