DEV Community: Stephen A. Lizcano

How Kubernetes Works

Stephen A. Lizcano — Fri, 18 Sep 2020 09:49:06 +0000

Containers are useful for many use cases, from tests, developmnent, and production apps.

The arrival of containers the software development completely. They enabled a way to create repeatable, consistent environments to run code.

Never again could someone say "Well, it worked on my machine." Instead of managing your own OS files, updates, and hardware, the container system allows us to focus instead on our code itself. It takes the security and resource features of VMs without the costs of maintaining your own OS or hardware.

And thus a new era on how teams build and ship software was born.

With developers seeing the benefits of containers in the development and production lifecycle, the need for a contianer orchestration became apparent.

Enter Kubernetes (or k8s as it is abbreviated), which is currently the most popular and in-demand container orchestration tool.

In this post we'll go over Kubernetes and its concepts, how it works and it is structured.

Background

Starting only in 2014, Kubernetes has risen to the #1 container orchestration platform, over Docker Swarm and Apache Mesos. It enjoys high demand due to its quick release cycle most popular tool to manage container infrastructure — with enterprise customers especially.

Kubernetes takes this evolution of container orchestration a step further. It gives a consistent, (relatively) cloud neutral way of deploying and orchestrating your container environments in an Infrastructure as Code (IAC) style.

With it one can define an entire application's structure using YAML. This includes everything from Load Balancers, autoscaling, TLS, networking rules, and more.

Combining it with a CI/CD workflow and you have a powerful method of defining, deploying and updating your architecture with speed and high availability. This ability has enabled the fast adoption of Kubernetes worldwide, with countless organizations adopting it.

It's complex however, and it's important to understand how it works.

Kubernetes Fundamental Concepts

The goal of Kubernetes is to coordinate your containers to be highly available and to act as a single unit. All applications need to be containerized for it to work.

Tip: If you don't know containers well I highly recommend Brian Holt's Complete Intro to Containers.

The Basic Architecture

Kubernetes has a "hub and spoke" pattern, where control of a cluster of containers is orchestrated from an API server that fans out to nodes who then talk to pods

Diagram of a node and its pods

The master (or control plane)

The master, or control plane, acts as the "brain" of kubernetes. Monitors the entire cluster, and manages its operation using the Kubernetes API.

The master handles the High Availability aspects of Kubernetes, from self healing of nodes and pods to replacement if a node goes down.

The node

Nodes are individual worker servers (computers or VMs) that host groups of containers, depending on your design. They are responsible for checking the health of each container on the node, and restarting or repairing containers that have problems.

The pod

The smallest unit item in Kubernetes is the Pod. Usually a single container run from an image (the kind you build with a Dockerfile) pulled from some container registry.

A Pod can run multiple containers, but that's an advanced use case like sidecars.

Services and Deployments

But how do we manage application lifecyle, and scaling, or networking? Kubernetes separates them into services and deployments.

Deployments

A deployment definition handles your full applicaton lifecycle, like rollouts of new pods, to auto healing and auto scaling.

A deployment spec will take in your desired Pod state (such as images) along with information about a desired number of containers, and how a rollout of updates should work.

Deployment controllers monitor your images for changes, and will use the ReplicaSet specified within your deployment yaml specification to deploy changes, handle failures and rollbacks, all automatically for you.

They are a high level Controller that combine other services like ReplicaSets and others to manage your app's lifecycle.

Networking with Services

Kubernetes doesn't automatically setup any networking for us. It expects us to define them in our .yaml files. To do this, we use services

A Kubernetes service is a policy definition for handling networking of pods in your cluster, for inside and outside communication.

Since pods can be created or destroyed at any time, it's important to define how pods should be able to contact one another regardless of Pod lifecycle. A Service definition defines your networking topology within your cluster.

Example: A frontend pod (serving a static web page for example) needs to communicate with a backend pod (maybe a DB or redis cache). If you deploy a new update to the backend pod, how does the frontend pod know the new IP of the backend pod?

These are the most common types of Services:

ClusterIP: The default service. It exposes a service IP available for the cluster only.
NodePort: Exposes a port on the external cluster IP (called NodePort), and creates a port for the node itself (called port)s , that allows you to connect to other ports or externally
LoadBalancer: For using external cloud load balancers for cloud deployments, such as the ALB from AWS or Cloud Load Balancer from GCP.
Ingress: A method for using a third party load balancer (such as nginx, HAProxy, or Envoy) within your cluster. Currently becoming the defacto method for implementing load balancers in clusters.

Controllers

Controllers track a resource(s) and makes sure they are in the desired state. This could be something like auto scaling on high loads, keeping a minimum number of pods running, to even running like cron jobs.

The most important ones for beginners are:

StatefulSets

StatefulSets match containers to storage volumes, providing persistence to your workloads (like running PostgreSQL, for example).

ReplicaSets

ReplicaSets ensure that you have a minimum number of pods you specify be deployed at all times.

You would typically want to use Deployments instead of replicasets, as they manage ReplicaSets and have other useful features.

Conclusion

And that's pretty much it! This overview gives you a good understanding of how kubernetes works conceptually, and will allow you to understand what is going on in the background and how it connects everything together.

Need help with kubernetes? You can contact me stephen@lizcano.dev

DynamoDB Crash Course — Intro and Secondary Indexes

Stephen A. Lizcano — Wed, 11 Mar 2020 16:33:15 +0000

DynamoDB is increasingly gaining the spotlight as a performant, low-cost and serverless NoSQL Database.

For good reason! It's a fast, highly available, and serverless key-value & document database that is fully managed.

Meaning: Once you understand DynamoDB concepts, developers enjoy increased development speed by letting DynamoDB handle the things that typically time — database scaling, availability, etc.

In this post we're going cover the basics of DynamoDB: how it models data & access patterns, tips on when it's best to be used vs. using something like SQL, and how to extend access patterns across more of your data using something called Secondary Indexes.

What's NoSQL?

NoSQL means simply: a database that doesn't typically follow the SQL style of a tabular, relational database, and the SQL language of accessing and querying data that data.

In comparison, Relational Databases (MySQL, PostgreSQL, etc.) do most of the the query processing for you—however you choose to define it— and right at the data source (e.g. calculating total count of users, filtering of data, etc.).

For NoSQL, it goes in reverse: a “query first” approach to identify the queries your application needs before you design the database schema.

What this means for the developer: you need to understand you data access patterns beforehand to fully utilize DynamoDB effectively, or you will run into issues later.

Tip: If you are unsure how your access patterns are going to be and that they might change in the future, it might be better to use a SQL type of database.

What is DynamoDB?

DynamoDB is a popular NoSQL database provided by Amazon Web Services that acts as a key-value & document store that provides data with millisecond performance at scale.

Basically, it's super fast, serverless, almost fully managed, and works at any scale.

Some of the primary benefits of DynamoDB are:

Performance — S*ingle digit* millisecond response times at any scale
Serverless — With no servers to manage, DynamoDB takes all the headache away of managing and maintaining database servers.
Consistency — ACID transactions for industries like business & finance. If you put data into it, it's immediately available, and you can assure it'll never get lost (barring disasters, of course).
Widely adopted: It used by many leading tech companies today, from AirBnB to Samsung, and more.

DynamoDB Pricing & Capacity

DynamoDB pricing exists in two modes: provisioned and on-demand.

Provisioned is more cost effective if you have consistent workloads, with auto scaling capability.
On-Demand Takes care of managing capacity for you, and you only pay for what you consume. You should start with this, especially for personal projects.

DynamoDB Basics - Tables and Keys

Data is organized in Tables, that have a collection of items set according to a schema.

Table: a collection of items

Item: collection of attributes (similar to a row or records in databases or spreadsheets).

Let's imagine we have a table of users that is a summary of game scores. The table below has games they played, and some stats like Top Scores and date, and Wins and Losses. GameScores is the table, and each row below is an item:

In order for us to setup a table, we need to tell DynamoDB what our partition key will be, and in effect, what our data access patterns will be.

This is because DynamoDB stores and accesses data according to this value. This is key to understanding why it's important to understand your access patterns getting started—if they change, you might finding yourself having to create a new table and moving over your stored data!

Partition & Composite Keys

When you make a table, each table must have a primary key that uniquely identifies each item in a table (this is how DynamoDB knows where to find an item). A primary key can be one of two items:

Partition Key: A simple key that is one attribute (like userID). (also called a hash key, since it is used internally in Dynamo as output from the hashing function)
Composite Key: In the GameScores table above, a user can have multiple forum posts. To make each item unique, we add a sort Key together with the partition key that will make each item unique in the table. This is called the composite key, where together with the sort key, all items are unique.
- **Example: Pulling all scores with userID 101, and then sorting by the GameTitle to get all high scores for all games.

Accessing data in DynamoDB

You can access data with two primary operations:

A query operation returns items based on a particular key (userID, etc.). This is the primary, recommended method. It's fast, affordable, and is how DynamoDB should generally be used.
A scan looks through the entire table for items based on set attributes or filter, and returns all the items that match the attributes.
- Tip: This can get expensive and is generally not recommended, as your charges will be higher, scans are slower, and scan the entire table.

Expanding your Access Patterns with Secondary Indexes

In the table above we can only query forum posts by a user and sort by a date, but that's it. What if we want to expand further? For example, in the image above, what if we wanted to get each userID sorted by TopScoreDateTime?

With Dynamo we can use something called Secondary Indexes.

A secondary index allows applications to benefit from having one or more secondary keys, to expand your access to your data with attributes that are different from your primary key.

Secondary Indexes come in two flavors: local and global.

A local secondary index (LSI for short) allows you to have an alternate sort key *for your table, while having the *same primary key.

For our GameScores table, if we have an LSI to get TopScoreDateTime, our LSI would have the UserId be the same primary key, and the second sort key would be TopScoreDateTime, which would allow us to a user by sorted Top Score datetimes.
You can only have one LSI on a table, and only 10GB total table size.
You can only add an LSI when you create a table!

What about applications that might need many different queries on a table?

A global secondary index or GSI allows you to have an infinite amount of partition and sort keys on your table, at the cost of data replication. This means:

You pay for the extra replicated data.
But you can have multiple access patterns on the same table, up to 20.
GSIs are only eventually consistent, meaning — you may not have access to the data on the GSI right after you write to a table. This is often done within a second, however.
Example: In the table above, what if we wanted to query TopScore by GameTitle? We would create a new GSI called GameTitleIndex with GameTitle as the primary key and TopScore as the sort key. When we query it, we can then see which UserId got the top score across all games.

Conclusion

This post should help you understand what DynamoDB is, what makes it special, and understand how DynamoDB structures its data and how to query it.

We didn't cover other topics like DynamoDB Accelerator for things like caching, or Streams for things like triggering lambda function after data entry. Those will be covered other posts, along with relational data.

I hope this post was beneficial in understanding DynamoDB!

I help companies with cloud and mobile software, so if you have questions or need help, please feel free to reach out.

Cheers!

Stephen

5 Minute Tutorial: Easily Get Base Types with AWS Amplify GraphQL Codegen for TypeScript

Stephen A. Lizcano — Sun, 17 Nov 2019 18:23:21 +0000

This short walkthrough illustrates how you can easily extend or generate your base Types for your TypeScript application easily using the AWS Ampligy/Apollo GraphQL codegen.

Note, you should be slightly familiar with GraphQL and Apollo or AWS Amplify GraphQL services, and the basics of TypeScript

Why are base types important?

Base types, and specifically using TypeScript with the code generator allows us to make sure that the types we are creating, updating, or listing from our GraphQL api conform to our schema.

This is especially important when designing our API function calls, so that everything we submit is of the correct shape and format, preventing us from dealing with errors later that could take a long time to debug.

I work in Healthcare, specifically making web and mobile applications for physicians and administrators.

So, we're going to use a simple healthcare focused schema to illustrate the example using medications and interactions.

Schema:

# schema.graphql

# @model automatically generates api calls for our API using GraphQL, AppSync & DynamoDB

type Patient @model {
  # basic patient information
  id: ID!
  name: String!
  sex: String!

  encounters: [Encounter] @connection(name: "Encounters")
}

type Encounter @model {
  # when a patient sees a doctor, that's an Encounter
  id: ID!
  reason: String!
  patient: Patient @connection(name: "Encounters")
  orders: [Order] @connection(name: "EncounterOrders")
}

type Order @model {
  # For lab tests like xrays, MRI, etc
  id: ID!
  order: String!
  # Tie the order to the encounter/patient visit it was created on
  Encounter: Encounter @connection(name: "EncounterOrders")
}

This is a basic one-to-many schema, that models a patient, an encounter with a physician, and sample clinical orders that can be made.

To generate your API, use apollo or amplify GraphQL codegen using:


$ amplify codegen

Follow the walkthrough, and be sure to select TypeScript for your code generation language.

You'll have a filed called API.ts generated, most likely in your ./src folder if you're using React, React Native, etc.

Open API.ts where you saved it, and look for the type GetPatientQuery:


export type GetPatientQuery = {
  getPatient:  {
    __typename: "Patient",
    id: string,
    name: string,
    sex: string,
    encounters:  {
      __typename: "ModelEncounterConnection",
      items:  Array< {
        __typename: "Encounter",
        id: string,
        reason: string,
      } | null > | null,
      nextToken: string | null,
    } | null,
  } | null,
};

How do we extract the Patient base type?

By utilizing TypeScripts Utility types to transform these types into the types all of our projects can use.

We need to remove the possible nullish return of the API call, and any unnecessary annotations.


export interface Patient
  extends Omit<Exclude<GetPatientQuery["getPatient"], null>, "__typename"> {}

That's it!

What's happening here is the Exclude utility type is removing/excluding the "null" of the type, which exists in case no data is returned/found.

Next, the Omit utility type removes the "__typename" label that is generated by the codegen to tell us the base type name.

That's it!

We can now use Patient as a base type for usage in our React/Vue/Angular etc web apps. We have the types for mapping, adding, and deleting types.

We can extend this to all of the other types that we created in the Schema, too.

And they automatically update if we change our schema!

Cheers, and hope this was helpful!

Need help with Amplify, cloud, or full-stack? I'm available for consulting.