Forem: Kentaro Wakayama

Getting Started with AWS Amplify

Kentaro Wakayama — Tue, 28 Dec 2021 15:28:35 +0000

Serverless cloud infrastructure is the next step in building apps. But if you’ve tried to navigate the vast number of services in the AWS console, you know that using the cloud is easier said than done. Today’s developers are overwhelmed with the amount of services AWS offers.

The solution? AWS Amplify, which helps developers to easily build and deploy complete mobile and web apps by providing a collection of CLI tools, libraries, frameworks, and cloud services.

How Does AWS Amplify Work?

Your main interaction point when using Amplify is the CLI tool, which comes with many commands that help you set up and maintain a serverless project. The Amplify CLI can create infrastructure by generating and deploying CloudFormation code. It also includes code generators for mobile and web apps that use the following languages: JavaScript/TypeScript, Dart, Swift, Java and GraphQL.

This way, you get new AWS resources deployed to the cloud, configured with best practices, and the boilerplate code needed to connect your frontend with these resources.

Amplify also has its own set of cloud services which you can use to set up and manage your apps, including web hosting based on Amazon S3 and Amazon CloudFront, the Amplify Console and Amplify Admin UI. The Amplify Console is used to get insights into your app’s workings after you deploy it, while the Amplify Admin UI is a visual alternative to the Amplify CLI, where you can create backends in the browser.

There is also a large set of frontend libraries and components that help you connect with the AWS services and ease the integration of Amplify with frontend frameworks like React or Vue. This includes a library for authentication with Amazon Cognito, AWS’ own identity management service, and a GraphQL client to connect to AppSync, a hosted GraphQL API service.

With Amplify DataStore, Amplify even includes a relatively high-level library that eases the pain of setting up offline functionality and real-time synchronization for your apps.

Building an Image Gallery

To get a better understanding of what Amplify can do, let’s build something with it! An image gallery web app is a simple task for Amplify. This tutorial shows you how to use the Amplify auth, hosting, and storage plugins, and how to generate most of the code with the Amplify CLI.

1. Prerequisites

This tutorial requires the following:

AWS account
AWS CLI
Node.js & NPM
Amplify CLI

If you use the Cloud9 IDE to follow along, you only have to install and configure the Amplify CLI manually; everything else is set up correctly out of the box. Make sure that the Amplify CLI was configured via amplify configure, to use your AWS credentials. AWS has a detailed guide on installing and configuring the Amplify CLI.

2. Initializing the Sample Application

First, you need to create a new directory for your app with several sub directories.

$ mkdir image-gallery
$ cd image-gallery
$ mkdir src
$ mkdir dist

The src directory is used to store the JavaScript code, while the dist directory is used by Amplify to bundle, minify and upload the JavaScript and HTML to the cloud.

Create a package.json file in the projects root directory with this content:

{
  "name": "image-gallery",
  "version": "0.1.0",
  "scripts": {
    "build": "esbuild src/app.js --bundle --minify --define:global=window --outfile=dist/app.js"
  },
  "dependencies": {
    "aws-amplify": "latest"
  },
  "devDependencies": {
    "esbuild": "^0.13.15"
  }
}

You should use ESBuild to bundle and minify the Amplify SDK with your application code for deployment. The amplify publish CLI command will automatically call the build script and search the dist directory for files to upload to Amplify’s hosting service.

3. Initializing Amplify

Initialize Amplify in the project with the below command. When asked, choose the defaults.

$ amplify init -y

This command will set up basic Amplify-related resources in the cloud, including two IAM roles and a S3 bucket for deployment-related data. It will also generate a src/aws-exports.js file that contains all the credentials your frontend needs to connect to the services you’ll deploy later. This file will be updated with every call to the Amplify CLI, so you should never change it manually.

Next, add hosting, auth, and storage, in that order.

$ amplify add hosting

Select the defaults, which are listed below.

? Select the plugin module to execute: Hosting with Amplify Console (Managed hosting with custom domains, Continuous deployment)
? Choose a type: Manual deployment

$ amplify add auth

Next, the CLI will ask you some questions, with default answers given. Here, the defaults are okay too. They are as follows:

Do you want to use the default authentication and security configuration? Default configuration
How do you want users to be able to sign in? Username
Do you want to configure advanced settings? No, I am done.

$ amplify add storage

The storage category needs a bit of customization. The default configuration only allows authenticated users to access the storage, but you also want unauthenticated users to view the images. For this, you’ll need the following configurations:

? Select from one of the below mentioned services: Content (Images, audio, video, etc.)
✔ Provide a friendly name for your resource that will be used to label this category in the project: ...
✔ Provide bucket name: ... 
✔ Who should have access: Auth and guest users
✔ What kind of access do you want for Authenticated users? create/update, read, delete
✔ What kind of access do you want for Guest users? read
✔ Do you want to add a Lambda Trigger for your S3 Bucket? no

For the storage, select Auth and guest users to make sure you have access. Authenticated users need permission to create, update, and read files, and guest users need permission to read files.

4. Writing the Source Code

Create an index.html file in the dist directory with the following content:

<!DOCTYPE html>

<meta charset="utf-8" />

<title>Amplify Image Gallery</title>

<link rel="stylesheet" href="//unpkg.com/bamboo.css@1.3.7/dist/dark.min.css" />

<style>
  button {
    width: 100%;
  }
</style>

<h1>Amplify Image Gallery</h1>

<div id="signin-status">Sign Up or Sign In.</div>
<br>

<h2>Step 1: Sign Up</h2>

Username <input id="signup-username" /><br>

Email <input id="signup-email" /><br>

Password <input type="password" id="signup-password" /><br>

<p>
  Passwords must be 8 characters long, contain one number and one special
  character.
</p>

<button id="signup-button">Sign Up With Email</button><br>

<h2>Step 2: Confirm Sign Up</h2>

Confirmation Code <input id="signup-confirmation-code" /><br><br>

<button id="confirm-signup-button">Confirm Sign Up</button>

<br><br>

<h2>Step 3: Sign In</h2>

Username <input id="signin-username" /><br>

Password <input type="password" id="signin-password" /><br><br>

<button id="signin-button">Sign In</button><br><br>

<h2>Step 4: Upload image</h2>

<input type="file" id="upload-input" />

<h2>Images</h2>

<div id="gallery"></div>

<script src="app.js"></script>

This HTML page has a few buttons for the sign-up process. They will be hooked up with logic in the following JavaScript file.

Create a app.js file in the src directory with this content:

import Amplify, { Auth, Storage } from 'aws-amplify'

import awsconfig from './aws-exports'

Amplify.configure(awsconfig)

const getElement = document.getElementById.bind(document)

const statusDiv = getElement('signin-status')

async function refreshGallery() {
  const galleryDiv = getElement('gallery')

  galleryDiv.innerHTML = ''

  const files = await Storage.list('')

  for (let file of files) {
    const image = document.createElement('img')

    image.src = await Storage.get(file.key)

    galleryDiv.appendChild(image)
  }
}

refreshGallery()

getElement('signup-button').addEventListener('click', async () => {
  const username = getElement('signup-username').value
  const email = getElement('signup-email').value
  const password = getElement('signup-password').value

  await Auth.signUp({ username, password, attributes: { email } })

  statusDiv.innerText = `Check "${email}" inbox for a confirmation code.`
})

getElement('confirm-signup-button').addEventListener('click', async () => {
  const code = getElement('signup-confirmation-code').value
  const username = getElement('signup-username').value

  await Auth.confirmSignUp(username, code)

  statusDiv.innerText = 'Sinup confirmed. You can sign in now.'
})

getElement('signin-button').addEventListener('click', async () => {
  const username = getElement('signin-username').value
  const password = getElement('signin-password').value

  const result = await Auth.signIn(username, password)

  statusDiv.innerText = 'Signed in as ' + result.username
})

getElement('upload-input').addEventListener('change', async (e) => {
  const [file] = e.target.files

  await Storage.put(file.name, file)

  await refreshGallery()
})

The app.js file fills the HTML with life. The aws-exports.js file contains all the credentials your client needs to interact with the deployed infrastructure. You’ll use it to initialize the Amplify SDK.

The refreshGallery function fetches a list of all the names of the files you uploaded to AWS Amplify Storage, which is essentially an S3 bucket. Then, it uses the Storage.get method to generate signed URLs that can be put into img HTML elements to display your images.

Next, event listeners are added to all buttons to manage the authentication flow. The Amplify SDK offers an Auth object with various methods to sign up, sign in, and confirm email codes. A sign-in is required to use the upload feature later.

To install the Amplify SDK for JavaScript and ESBuild, run the following command:

$ npm i

After the libraries are installed, you can deploy a serverless infrastructure with the Amplify CLI and publish the changes to the AWS cloud:

$ amplify publish

This command will deploy the serverless infrastructure and package, as well as upload your frontend code. It can take a few minutes to complete because many resources will be provisioned.

5. Using the App

After the deployment is finished, Amplify will present you with an URL. The app will look like the image in Figure 1, below.

Figure 1: Image gallery app

Open the URL in a browser and simply follow the instructions:

Sign up with your email
Enter the confirmation code you received from AWS Cognito and validate it
Sign in
Upload an image

The image will be sent directly to an S3 bucket that was created by Amplify when you set up the storage category with the CLI. The Amplify SDK is then used to generate signed URLs, which allow you to access the images via HTTP. The whole code for loading the images is in the refreshGallery function inside the src/app.js file:

async function refreshGallery() {
  const galleryDiv = getElement('gallery')

  galleryDiv.innerHTML = ''

  const files = await Storage.list('')

  for (let file of files) {
    const image = document.createElement('img')
    image.src = await Storage.get(file.key)
    galleryDiv.appendChild(image)
  }
}

6. Cleanup

After you’ve deployed and used the system, you can delete it with just one Amplify CLI command:

$ amplify delete

This command will delete all local files Amplify generated and destroy the CloudFormation templates and all related resources deployed in the cloud.

Check the S3 console for buckets related to the project, after calling the above command. To prevent data loss in Amplify, and in turn, CloudFormation, they won’t be deleted automatically.

Also, the IAM user created by Amplify to deploy resources will be left after calling the delete command. You find it in your IAM dashboard, where you have to delete it manually.

What About the Pricing?

If you’ve ever used services like Firebase or Heroku, you probably know that solutions that ease developers’ interactions with the cloud can become expensive, especially when scaling up later. Usually, these solutions are built as totally stand-alone services, specially crafted for one purpose: making the cloud easier to use.

AWS went in a different direction with Amplify. It’s built on the AWS infrastructure services you already know, so you have to pay the same amount of money as when you use these services without Amplify. And since the services it uses are serverless, they all offer on-demand payment options. If you build a system that nobody wants to use, you don’t have to pay for the unused resources.

If you build an Amplify-based app, check out the AWS Pricing Calculator to estimate how much it will cost you. All resources follow the same pricing models with and without Amplify.

Summary

AWS Amplify is an exciting approach to serverless infrastructure. It caters mainly to frontend and mobile developers, so its projects can be maintained even if you don’t have enough full-stack or backend developers at hand.

Amplify differs from solutions like Firebase in that Amplify is just an abstraction layer above existing serverless AWS services. Besides the Amplify console and the Amplify Admin UI, which manage your app, it doesn’t introduce special services to run your app. This is also why the costs of running an app with Amplify are the same as when configuring all underlying services manually.

For our latest insights and updates, follow us on LinkedIn

Kubernetes Logging in Production

Kentaro Wakayama — Tue, 26 Oct 2021 09:23:33 +0000

Historically, in monolithic architectures, logs were stored directly on bare metal or virtual machines. They never left the machine disk and the operations team would check each one for logs as needed.

This worked on long-lived machines, but machines in the cloud are ephemeral. As more companies run their services on containers and orchestrate deployments with Kubernetes, logs can no longer be stored on machines and implementing a log management strategy is of the utmost importance.

Logs are an effective way of debugging and monitoring your applications, and they need to be stored on a separate backend where they can be queried and analyzed in case of pod or node failures. These separate backends include systems like Elasticsearch, GCP’s Stackdriver, and AWS’ Cloudwatch.

Storing logs off of the cluster in a storage backend is called cluster-level logging. In this article we’ll discuss how to implement this approach in your own Kubernetes cluster.

Logging Architectures

In a Kubernetes cluster there are two main log sources, your application and the system components.

Your application runs as a container in the Kubernetes cluster and the container runtime takes care of fetching your application’s logs while Docker redirects those logs to the stdout and stderr streams. In a Kubernetes cluster, both of these streams are written to a JSON file on the cluster node.

These container logs can be fetched anytime with the following command:

kubectl logs podname

The other source of logs are system components. Some of the system components (namely kube-scheduler and kube-proxy) run as containers and follow the same logging principles as your application.

The other system components (kubelet and container runtime itself) run as a native service. If systemd is available on the machine the components write logs in journald, otherwise they write a .log file in /var/log directory.

Now that we understand which components of your application and cluster generate logs and where they’re stored, let’s look at some common patterns to offload these logs to separate storage systems.

Logging Patterns

The two most prominent patterns for collecting logs are the sidecar pattern and the DaemonSet pattern.

1. DaemonSet pattern

In the DaemonSet pattern, logging agents are deployed as pods via the DaemonSet resource in Kubernetes. Deploying a DaemonSet ensures that each node in the cluster has one pod with a logging agent running. This logging agent is configured to read the logs from /var/logs directory and send them to the storage backend. You can see a diagram of this configuration in figure 1.

Figure 1: A logging agent running per node via a DaemonSet

2. Sidecar pattern

Alternatively, in the sidecar pattern a dedicated container runs along every application container in the same pod. This sidecar can be of two types, streaming sidecar or logging agent sidecar.

The streaming sidecar is used when you are running an application that writes the logs to a file instead of stdout/stderr streams, or one that writes the logs in a nonstandard format. In that case, you can use a streaming sidecar container to publish the logs from the file to its own stdout/stderr stream, which can then be picked up by Kubernetes itself.

The streaming sidecar can also bring parity to the log structure by transforming the log messages to standard log format. You can see this pattern in figure 2.

Figure 2: Streaming sidecar pattern

Another approach is the logging agent sidecar, where the sidecar itself ships the logs to the storage backend. Each pod contains a logging agent like Fluentd or Filebeat, which captures the logs from the application container and sends them directly to the storage backend, as illustrated in figure 3.

Figure 3: Logging agent sidecar pattern

Pros and Cons

Now that we’ve gone over both the DaemonSet and sidecar approaches, let’s get acquainted with the pros and cons of each.

1. DaemonSet (Node Level)

Pros

Node-level logging is easier to implement because it hooks into the existing file based logging and is less resource intensive than a sidecar approach as there are less containers running per node.
The logs are available via the kubectl command for debugging, as the log files are available to kubelet which returns the content of the log file.

Cons

Less flexibility in supporting different log structures or applications that write to log files instead of streams. You would need to modify the application log structure to achieve parity, or handle the difference in your storage backend.
Since they’re stored as JSON files on the node disk, logs can’t be held forever. You need to have a log rotation mechanism in place to recycle old logs. If you are using Container Runtime Interface, kubelet takes care of rotating the logs and no explicit solution needs to be implemented.

2. Sidecar

Pros

You have the flexibility to customize sidecars per application container. For example, an application might not have the ability to write to stdout/stderr, or it might have some different logging format. In these cases, a sidecar container can bring parity to the system.
If you’re using a logging agent sidecar without streaming, you don't need to rotate the logs because no logs are being stored on the node disk.

Cons

Running a sidecar for each application container is quite resource intensive when compared to node-level pods.
Adding a sidecar to each deployment creates an extra layer of complexity.
If you’re using a streaming sidecar for an application that writes its logs to files, you’ll use double the storage for the same logs because you’ll be duplicating the entries.
If you’re using a logging agent sidecar without streaming, you’ll lose the ability to access logs via kubectl. This is because kubelet no longer has access to the JSON logs.
With a logging agent sidecar you also need a node-level agent, otherwise you won’t be able to collect the system component logs.

Putting Theory into Practice

Now that we’ve looked at the possible patterns for logging in a Kubernetes cluster, let’s put them into action. We’ll deploy dummy containers generating logs and create Kubernetes resources to implement the logging patterns we discussed above.

For this example we’ll use Fluentd as a logging agent, and we will install Elasticsearch for logging backend and Kibana for visualization purposes. We will install Elasticsearch and Kibana using Helm charts into the same cluster. Do note however that your storage backend should not be on the same cluster and we are doing it for demo purposes only. Thanks to Fluentd’s pluggable architecture, it supports various different sinks. That’s why the Elasticsearch backend can be replaced by any cloud-native solution, including Stackdriver or Cloudwatch.

1. Installing Elasticsearch and Kibana

We will deploy the Elasticsearch and Kibana using the official Helm charts which can be found here(Elasticsearch, Kibana). For installing via Helm you would need a helm binary on your path but installation of Helm is outside the scope of this post.

Let us start by adding helm repos.

helm repo add elastic https://helm.elastic.co

Next we will install the Elasticsearch and Kibana charts into our cluster.

helm install elasticsearch elastic/elasticsearch
helm install kibana elastic/kibana

This will install the latest version of Elasticsearch and Kibana in your cluster which can then be used as storage backend for your logs.

We have used the default values in our charts but you can change any parameter based on your needs when you are installing this in production.

2. DaemonSet

We will be deploying Fluentd as a DaemonSet. To keep the verbosity low, we won’t be creating a separate ServiceAccount and ClusterRole. But in a production environment, Fluentd pods should run with a separate service account with limited access.

You can deploy Fluentd as a DaemonSet by using following the Kubernetes resource:

apiVersion: extensions/v1beta1
kind: DaemonSet
metadata:
  name: fluentd
  namespace: kube-system
  labels:
    k8s-app: fluentd-logger
spec:
  template:
    metadata:
      labels:
        k8s-app: fluentd-logger
    spec:
      containers:
      - name: fluentd
        image: fluent/fluentd-kubernetes-daemonset:elasticsearch
        env:
        - name:  FLUENT\_ELASTICSEARCH\_HOST
          value: "elasticsearch-master"
        - name:  FLUENT\_ELASTICSEARCH\_PORT
          value: "9200"
        volumeMounts:
        - name: varlog
          mountPath: /var/log
        - name: dockerlogs
          mountPath: /var/lib/docker/containers
          readOnly: true
      volumes:
      - name: varlog
        hostPath:
          path: /var/log
      - name: dockerlogs
        hostPath:
          path: /var/lib/docker/containers

In this example, we’re mounting two volumes: one at /var/log and another at /var/log/docker/containers, where the system components and Docker runtime put the logs, respectively.

The image we are using is already configured with smart defaults to be used with DaemonSet, but you can change the configuration.

Save the above YAML resource in a file named fluentd-ds.yaml and apply the resource via the following command:

kubectl apply -f fluentd-ds.yaml

This will start a Fluentd pod on each node in your Kubernetes cluster.

Now we’ll see how to implement streaming and logging agent sidecar patterns.

3. Sidecar

First, let’s look at the streaming sidecar pattern when our application is writing logs to a file instead of stream. We’re running a sidecar to read those logs and write it back to the stdout/stderr stream.

apiVersion: v1
kind: Pod
metadata:
  name: my-app
spec:
  containers:
  - name: legacy-app
    image: busybox
    args:
    - /bin/sh
    - -c
    - >
      i=0;
      while true;
      do
        echo "$i: $(date)" >> /var/log/output.log;
        i=$((i+1));
        sleep 1;
      done      
    volumeMounts:
    - name: varlog
      mountPath: /var/log
  - name: streaming-sidecar
    image: busybox
    args: \[/bin/sh, -c, 'tail -n+1 -f /var/log/output.log'\]
    volumeMounts:
    - name: varlog
      mountPath: /var/log
  volumes:
  - name: varlog
    emptyDir: {}

In this example, we have a dummy container writing logs to files in the /var/log directory of the container. Now these logs can’t be fetched by the container runtime, that’s why we implemented a streaming sidecar to tail the logs from the /var/log location and redirect it to the stdout stream.

This log stream will be picked up by the container runtime and stored as a JSON file at the /var/log directory on the node, which will in turn be picked up by the node-level logging agent.

Now, let’s look at the logging agent sidecar. In this pattern we’ll deploy Fluentd as a sidecar, which will directly write to our Elasticsearch storage backend.

Unfortunately, there is no prebuilt image with an Elasticsearch plugin installed, and creating a custom Docker image is out of the scope of this article. Instead, we’ll use the same Fluentd image that we used in the DaemonSet example.

apiVersion: v1
kind: Pod
metadata:
  name: my-app
spec:
  containers:
  - name: count
    image: busybox
    args:
    - /bin/sh
    - -c
    - >
      i=0;
      while true;
      do
        echo "$i: $(date)" >> /var/log/output.log;
        i=$((i+1));
        sleep 1;
      done      
    volumeMounts:
    - name: varlog
      mountPath: /var/log
  - name: logging-agent
    image: fluent/fluentd-kubernetes-daemonset:elasticsearch
     env:
      - name:  FLUENT\_ELASTICSEARCH\_HOST
        value: "elastisearch-master"
      - name:  FLUENT\_ELASTICSEARCH\_PORT
        value: "9200"
    volumeMounts:
    - name: varlog
      mountPath: /var/log
  volumes:
  - name: varlog
    emptyDir: {}

Conclusion

Given the ephemeral nature of pods and nodes, it’s very important to store logs from your Kubernetes cluster in a separate storage backend. There are multiple patterns that you can use to set up the logging architecture that we discussed in this article.

Note that we suggest a mix of both sidecar and node-level patterns for your production systems. This includes setting up cluster-wide, node-level logging using a DaemonSet pattern, and implementing a streaming sidecar container for applications that do not support writing logs to stream (stdout/stderr) or that don’t write in a standard log format. This streaming container will automatically surface logs for node-level agents to be picked up.

For the choice of storage backend, you can choose self-hosted, open-source solutions such as Elasticsearch, or you can go the managed service route with options like cloud-hosted Elasticsearch, Stackdriver, or Cloudwatch. The choice of backend that’s right for you will depend on the cost, query, and log analysis requirements that you want to implement with your architecture.

For our latest insights and updates, follow us on LinkedIn

NoOps: What Does the Future Hold for DevOps Engineers?

Kentaro Wakayama — Sun, 11 Jul 2021 14:40:02 +0000

With cloud adoption on the rise, the level of abstraction in application architecture has increased— from traditional on-premises servers to containers and serverless deployments. The focus on automation has also increased to the point where manual intervention is no longer preferred, even for infrastructure-related activities like backups, security management, and patch updates. This desired state equates to a NoOps environment, which involves smaller teams that can manage your application lifecycle. Ideally, in such an environment, the efforts required by your operations team will be eliminated.

It is beyond debate that DevOps is now deeply integrated into the DNA of all cloud-first organizations and is today more of a norm than a rarity. Cloud applications demand agility, and DevOps delivers it. However, does NoOps mean the end of the DevOps era? Or is it simply the next step in the progression of DevOps?

DevOps vs. NoOps

The success of DevOps greatly depends on the synergy between your development and operations teams, as it brings together system administrators and developers who would otherwise work in silos. Meanwhile, the process of continuous integration and continuous deployment is crucial in DevOps, which helps in identifying issues early on and avoiding them. This in turn results in the faster delivery of solutions. However, note that the operations team is still very much in the picture. There is still a dependency on the operations team to take care of nitty-gritties like: infra config management, security settings, backups, patch management, etc.

With the cloud, abstraction and automation are scaling to new heights every day. You name it, and you can have it “as-a-service” in the cloud, be it compute, storage, network, or security, to list just a few. Cloud service providers are also investing heavily in their automation ecosystem. You can easily provision your application components using automation templates or just a few API calls. The ongoing management of these components can be automated as well, meaning less overhead to maintain environments and minimal to no human intervention. This leads us to NoOps—the increased abstraction of infrastructure, tightly integrated with development workflows, that requires no operations team to oversee the process.

NoOps, a term originally coined by Forrester, aims to improve productivity and deliver results much faster than DevOps. In the ideal scenario, developers never have to collaborate with a member of the operations team. Instead, they can use a set of tools and services to responsibly deploy the required cloud components in a secure manner, including both the code and infrastructure. Managed cloud services, like PaaS or serverless, serve as the backbone of NoOps and leverage CI/CD as their core engine for deployment. Hence, note that not all scenarios fit the bill for NoOps.

NoOps: Advantages and Challenges

NoOps and DevOps essentially try to achieve the same thing: improve the software deployment process and reduce time to market. But while the collaboration between developers and operations team was emphasized in DevOps, the focus has shifted to complete automation in NoOps. This may sound like a silver bullet, but this new approach comes with both advantages and challenges.

Advantages

1. More automation, less headcount

NoOps shifts the focus to services that are deployable by design without manual intervention. From infrastructure to management activities, the aim is to control everything using code, meaning every component should be deployed as part of the code and maintainable in the long run. NoOps essentially seeks to eliminate the manpower required to support the ecosystem for your code.

2. Use the full power of the cloud

NoOps is best suited for born-in-the-cloud environments that leverage PaaS and serverless solutions. Microservices and API-based application architectures fit the bill perfectly, as they offer fine-grained modularity along with automation. Leading cloud service providers like AWS, Azure, and GCP have a laser focus on providing more services and capabilities in PaaS and serverless, which would help accelerate the adoption of NoOps. The current increase in database-as-a-service, container-as-a-service, and function-as-a-service options in the cloud favor this trend as well, and all of these technologies support extreme automation.

3. Shift from operations to business results

NoOps also shifts the focus from operations to business outcomes. Unlike DevOps, where the dev team and ops team work together to deliver value propositions to the customer, NoOps ideally eliminates any dependency on the operations team, which further reduces time to market. Again, the focus is shifted to priority tasks that deliver value to customers—in other words, “fast beats slow.”

Challenges

1. You Still Need Ops

In theory, not requiring an operations team to take care of your infrastructure might sound lucrative. However, depending on the level of automation that’s achievable, you might still need them around to take care of exceptions or to monitor outcomes. Expecting developers to take care of this would nullify the benefits of NoOps and take away their focus from delivering business outcomes. It is also not a practical approach, considering that developers don’t necessarily have the required skill sets to address operational issues. For example, consider a Disaster Recovery (DR) scenario. You would still need support from an operations team to invoke the DR plan and switch traffic to the failover site.

2. Consider Your Environment

Also, not all environments can transition to NoOps. Hybrid deployments and legacy infrastructures would pose a bottleneck—automation is still possible, but human intervention cannot be entirely eliminated in these cases. While aiming for NoOps, PaaS and serverless could become a limiting factor as well, especially during digital transformation. Additional efforts required to refactor legacy monolithic applications to fit the paradigms of PaaS would be counterintuitive. You would need to carefully evaluate the pros and cons, on a case by case basis, before embarking on the NoOps approach.

3. Who Will Take Care of Security?

Last but not least is the question of security and compliance. Automated deployments aligned with security best practices will not completely eliminate the need for you to take care of security. Traditionally, there is a segregation of duties between operations and development teams. The operations team works together with the security team to enforce controls that protect applications from threats and vulnerabilities. The operations team, meanwhile, is also responsible for handling Identity and Access Management (IAM) solutions.

Threat vectors and attack methods in the cloud evolve by the day, and so should your cloud security controls. The same goes for compliance. Not all organizations can delegate that responsibility to a set of automated processes. Reducing, or eliminating, the operations team could result in you needing to increase your investment in a security team to ensure the security and compliance of your environments.

Destination NoOps

DevOps is considered more of a journey, not a destination, where the focus is on continuous improvement. It would be safer to say that NoOps is the evolution of DevOps, targeting a perfect end-state of extreme automation. It allows organizations to redirect time, effort, and resources from operations to business outcomes. However, this change cannot happen overnight.

For NoOps to become a reality, a lot of groundwork is involved. You need to identify the right application stack and managed services in the cloud, i.e., PaaS and serverless, for the transition to happen. You need to bake in the component management, configuration, and security controls to get started. Even then, there would be some loose ends like legacy systems that would take more time and effort to transition or that cannot be transitioned at all. And if there’s even a single legacy system left behind, you would still need someone to take care of its operational aspects.

In a NoOps world, the role of DevOps engineers also changes, as they get the opportunity to learn new skills and processes required for NoOps. Like DevOps, NoOps is more about the shift in culture and process, rather than technology. Organizations need to be intentional about this shift while staying grounded as to the practicalities of the transition.

For our latest insights and updates, follow us on LinkedIn

Originally published at https://codersociety.com

Managing Secrets in Node.js with HashiCorp Vault

Kentaro Wakayama — Sun, 04 Jul 2021 13:53:07 +0000

As the number of services grows in an organization, the problem of secret management only gets worse. Between Zero Trust and the emergence of microservices, handling secrets such as tokens, credentials, and keys has become an increasingly challenging task. That’s where a solution like HashiCorp’s Vault can help organizations solve their secret management woes.

Although there are secret management tools native to each cloud provider, using these solutions lock you in with a specific cloud provider. Vault, on the other hand, is open source and portable.

In this article we’ll look at how HashiCorp’s Vault can help organizations manage their secrets and in turn enhance their cybersecurity posture. We’ll then set up Vault in dev mode on our machines and interact with it via its web UI and CLI. Finally, we’ll programmatically interact with Vault using Node.js.

Vault Top Features

Vault is HashiCorp’s open-source product for managing secrets and sensitive data. Here’s a list of Vault’s top features that make it a popular choice for secret management:

Built-in concept of low trust and enforcement of security by identity
Encryption at rest
Several ways to authenticate against Vault, e.g., tokens, LDAP, AppRole, etc.
Policies to govern the level of access of each identity
Lots of secret backends, each catering to specific needs, including key-value store, Active Directory, etc.
Support for multiple storage backends for high availability, e.g., databases (MySQL, Postgres), object stores (GCS, S3), HashiCorp’s Consul, etc.
Ability to generate dynamic secrets, such as database credentials, cloud service account keys (Google, AWS, Azure), PKI certificates, etc.
Built-in TTL and lease for provided credentials
Built-in audit trail which logs every interaction with Vault
Several ways to interact with the Vault service, including Web UI, CLI, Rest API, and programmatic access via language libraries

These features make Vault a compelling choice for cloud-based microservices architecture, where each microservice will authenticate with Vault in a distributed manner and access the secrets. The access to secrets can be managed for each individual microservice using policies following the principle of least privilege.

In the next section, we’ll set up Vault in dev mode and discuss ways to set it up in production. We’ll then configure the dev Vault instance for our hands-on demo, learning different configuration options along the way.

Setup for Hands-On Demo

We’ll use Docker to set up Vault on our local machine. Note that this setup is not production ready. We’ll start Vault in dev mode, which uses all the insecure default configurations.

Running Vault in production isn’t easy. To do so, you can either choose HashiCorp Cloud Platform, the fully managed Vault in the cloud, or leave it to your organization’s infrastructure team to set up a secure and highly available Vault cluster.

Let's get started.

Start Vault in Dev Mode

We’ll start the Vault service by using the official Docker image vault:1.7.3.

If you run the container without any argument, it will start the Vault server in Dev mode by default.

docker run --name vault -p 8200:8200 vault:1.7.3

As Vault is starting, you’ll see a stream of logs. The most prominent log is a warning telling you that Vault is running in development mode:

WARNING! dev mode is enabled! In this mode, Vault runs entirely in-memory and starts unsealed with a single unseal key. The root token is already authenticated to the CLI, so you can immediately begin using Vault.

If you read the message closely, you’ll notice a few things. First, it says the Vault is unsealed with a single unseal key, and second, it mentions a root token. What does this mean?

By default, when you start Vault in production mode it’s sealed, meaning you can’t interact with it yet. To get started, you’ll need to unseal it and get the unseal keys and root token to authenticate against Vault.

In case a breach is detected, the Vault server can be sealed again to protect against malicious access.

The other information that gets printed in logs is a root token, which can be used to authenticate against Vault. The option of authentication by tokens is enabled by default and the root token can be used to initiate the first interaction with Vault.

Note that if your organization’s infrastructure team has set up the Vault, they might have enabled some other auth backends as discussed in the previous section.

Copy the root token, as we’ll use it to login to Vault UI.

Head over to http://localhost:8200 and you’ll see the login screen below on the Vault web UI.

Enable KV Secret Backend

Enter your root token (copied from the previous step) and hit “Sign In.” You’ll be greeted with the following screen.

You can see that there is already a KV backend enabled at path secret. This comes enabled in dev mode by default.

If it is not enabled in your Vault installation, you can do so by clicking on Enable New Engine and then selecting KV backend and follow through the setup.

We’ll use this backend to store our secrets and then later retrieve them in the Node.js demo.

Configure AppRole Auth Method

We’ll now configure the AppRole auth method, which our Node.js application will use to retrieve the secrets from our key value backend.

Select Access from the top menu. You’ll see only the token method enabled.

Click Enable New Method and select AppRole. Leave the settings to default and click Enable Method.

Create Policy for Secret Access

We’ll create a policy that allows read-only access to the KV secret backend.

Select Policies from the top menu and click Create ACL Policy.

Enter name as readonly-kv-backend, and enter following content for Policy.

path "secret/data/mysql/webapp" {
  capabilities = [ "read" ]
}

Following the principle of least privilege, this policy will only give read access to secrets at the specific path.

Hit Create Policy to save it.

Create AppRole for Node.js Application

We’re going to switch gears and use Vault CLI to finish setting up our demo. There are two ways to access Vault CLI; you can download the Vault binary, or you can exec into Vault container and access the CLI. For this demo we’ll use the latter.

docker exec -it vault /bin/sh

We’ll then set up the VAULT_ADDR and VAULT_TOKEN environment variables.

export VAULT_ADDR=http://localhost:8200
export VAULT_TOKEN=<ROOT TOKEN>

Now let’s create an AppRole and attach our policy to this role.

vault write auth/approle/role/node-app-role \
    token_ttl=1h \
    token_max_ttl=4h \
    token_policies=readonly-kv-backend

You should be able to see it being created successfully.

Success! Data written to: auth/approle/role/node-app-role

Each AppRole has a RoleID and SecretID, much like a username and password. The application can exchange this RoleID and SecretID for a token, which can then be used in subsequent requests.

Get RoleID and SecretID

Now we’ll fetch the RoleID pertaining to the node-app-role via the following command:

vault read auth/approle/role/node-app-role/role-id

Next we’ll fetch the SecretID:

vault write -f auth/approle/role/node-app-role/secret-id

Make sure you store these values somewhere safe, as we’ll use them in our Node.js application.

Please note that it's not safe to deliver SecretID to our applications like this. You should use response wrapping to securely deliver SecretID to your application. For the purpose of this demo, we’ll pass SecretID as an environment variable to our application.

Create a Secret

As the last step of our setup process, we’ll create a secret key-value pair that we will access via our Node.js application.

vault kv put secret/mysql/webapp db_name="users" username="admin" password="passw0rd"

Now that we have our setup ready, we can proceed to our Node.js application.

Manage Secrets via Node.js

In this section we’ll see how to interact with Vault via Node.js and use the node-vault package to interact with our Vault server.

Install the node-vault package first, if not already installed.

npm install node-vault

Before we begin, set the ROLE_ID and SECRET_ID environment variables to pass these values to the application.

export ROLE_ID=<role id fetched in previous section>
export SECRET_ID=<secret id fetched in previous section>

Now let’s write the sample Node application.

const vault = require("node-vault")({
  apiVersion: "v1",
  endpoint: "http://127.0.0.1:8200",
});

const roleId = process.env.ROLE_ID;
const secretId = process.env.SECRET_ID;

const run = async () => {
  const result = await vault.approleLogin({
    role_id: roleId,
    secret_id: secretId,
  });

  vault.token = result.auth.client_token; // Add token to vault object for subsequent requests.

  const { data } = await vault.read("secret/data/mysql/webapp"); // Retrieve the secret stored in previous steps.

  const databaseName = data.data.db_name;
  const username = data.data.username;
  const password = data.data.password;

  console.log({
    databaseName,
    username,
    password,
  });

  console.log("Attempt to delete the secret");

  await vault.delete("secret/data/mysql/webapp"); // This attempt will fail as the AppRole node-app-role doesn't have delete permissions.
};

run();

Store this script as index.js and run it via the node index.js command.

If everything is set up correctly, your secrets should be printed on your screen. Apart from your secrets, you’ll also see the error in deleting the secret. This confirms that our AppRole only has access to read the secret and not delete it.

Conclusion

In this article we saw the importance of having a secret manager in a distributed systems architecture. We also learned to access Vault via Node.js applications, retrieve secrets, and interface with Vault via Web UI and CLI to configure it for our sample application.

From storage backends to auth backends, Vault comes with a lot of options so you can tune it perfectly to your organization’s needs. If you’re looking for a secret management solution to your microservices architecture challenges, HashiCorp’s Vault should be at the top of your list.

For our latest insights and updates, follow us on LinkedIn

Originally published at https://codersociety.com

Containers in the Cloud: What Are Your Options?

Kentaro Wakayama — Wed, 30 Jun 2021 14:46:50 +0000

The cloud has opened up new possibilities for the deployment of microservice architectures. Managed and unmanaged container services, along with serverless hosting options, have revolutionized the deployment of container workloads in the cloud.

While an unmanaged or build-your-own approach for your container ecosystem in the cloud gives you greater control over the stack, you need to own the end-to-end lifecycle, security, and operations of the solution. Managed container services, on the other hand, are hassle free and more popular due to their built-in integration with your current cloud ecosystem, best practices, security, and modularity.

All three leading cloud providers—AWS, Azure, and GCP—have a strong portfolio of products and services to support containerized workloads for cloud-native as well as hybrid deployments. Kubernetes (K8s) remains the most popular container orchestration solution in the cloud. This enterprise-class solution is also the preferred platform for production deployments. Each of the major cloud service providers offer a native managed Kubernetes service as well as standalone container solutions. Both of these solutions easily integrate with the robust ecosystem of supporting services offered by your cloud platform, including container registries, identity and access management, and security monitoring.

In this article, we’ll explore some of the more popular options for deploying containers in the cloud and use cases.

Popular Options for Container Workloads in the Cloud

Each of the major cloud service providers offers a number of available options for container workload hosting, which we’ll examine in the following sections.

Amazon Web Services

AWS provides a diverse set of services for container workloads, the most popular being EKS, ECS, and Fargate. It also offers an extended ecosystem of services and tools, like AWS Deep Learning Containers for machine learning, Amazon Elastic Container Registry, and EKS Anywhere (coming in 2021) for hybrid deployments.

1. Amazon Elastic Kubernetes Service

Amazon Elastic Kubernetes Service (EKS) can be used to create managed Kubernetes clusters in AWS, where the deployment, scaling, and patching are all managed by the platform itself. The service is Kubernetes-certified and uses Amazon EKS Distro, an open-source version of Kubernetes.

Since the control plane is managed by AWS, the solution automatically gets the latest security updates with zero downtime and ensures a safe hosting environment for containers. The service also has assured high availability, with an SLA of 99.95% uptime—achieved by deploying the control plane of Kubernetes across multiple AWS Availability Zones.

AWS charges a flat rate of $0.10 per hour for EKS clusters, as well as additional charges for the EC2 instances or EBS volumes used by the worker nodes. The cost can be reduced by opting for EC2 Spot Instances for development and testing environments, and Reserved Instances for production deployments.

EKS is most beneficial if you’re planning for a production-scale deployment of microservices-based applications on AWS, easily scalable web applications, integration with machine learning models, batch processing jobs, and the like.

2. AWS Fargate

AWS Fargate is a serverless compute service for containers that can be integrated with Amazon EKS and Amazon ECS. It reduces operational overhead, as you don’t have to deploy and configure the underlying infrastructure for hosting containers, and you’re charged only for the compute capacity being used to run the workloads.

The containers run in an isolated environment with a dedicated kernel runtime, thereby ensuring improved security for the workloads. You can also leverage Spot Instances (for dev/test environments) and compute savings plans for committed usage to reduce the overall cost. If you’re looking to switch from a monolithic to a microservices-based architecture, with minimal development and management overhead, AWS Fargate offers great benefits.

3. Amazon Elastic Container Service

Amazon Elastic Container Service (ECS) can be used to host container services either in a self-managed cluster of EC2 instances or on a serverless infrastructure managed by Fargate. The former approach provides better control over the end-to-end stack hosting the container workloads.

In addition, it provides centralized visibility of your services and the capability to manage them via API calls. If you’re using EC2 for the underlying cluster, the same management features can be used for ECS as well. However, the cluster management, scaling, and operations layer are all handled by the platform, thereby eliminating that overhead.

ECS is a regional service that is highly available across Availability Zones within an AWS region, ensuring the availability of your hosted container workloads.

Microsoft Azure

Azure offers a managed Kubernetes service as well as options for deploying standalone container instances. Azure Container Registry, integration with Security Center, and container image scanning are just a few other Azure value-added services to support container workload ecosystems.

1. Azure Kubernetes Service

The managed Kubernetes service, Azure Kubernetes Service (AKS), is one of the most popular container hosting services in the public cloud today. It consists of a control plane hosting the master nodes, which is managed by the Azure platform that exposes the Kubernetes APIs; then there are the customer-managed agent nodes, where the container workloads are deployed.

The platform handles all cluster management activities, such as health monitoring and maintenance. It also offers easy integration with Azure RBAC and Azure AD for cluster management, built-in integration with Azure Monitor, and flexibility to use Docker Registry or Azure Container Registry for retrieving container images.

AKS can be used without a cluster management fee while maintaining an SLA of 99.5%. You pay only for the VM instances, storage, and networking resources used for the AKS cluster on a per-second billing model. There is also an option to purchase uptime SLA for $0.10 per cluster per hour. High availability can be configured by using Azure Availability Zones during cluster deployments. If optional uptime SLA is purchased, such clusters will have an assured SLA of 99.95% and the clusters that do not use Availability Zones will have an SLA of 99.9%. In both cases, the customer is required to pay for the agent nodes that host the workloads.

2. Azure Container Instances

Azure Container Instances provides an easy-to-use solution for deploying containers in Azure without deploying an orchestration platform. Because Container Instances does not require the provisioning of any VMs, the instances are started in a matter of seconds. The service also gives you the flexibility to configure the CPU core and memory required for the workloads and are charged only for that. The service can integrate with Azure Files for persistent storage, connect to Azure Virtual Network, and also integrate with Azure Monitor for resource-usage monitoring.

Azure Container Instances is best suited for deploying isolated container instances for simple applications that don't require advanced capabilities such as on-demand scaling or multi-container service discovery.

3. Azure Web App for Containers

Azure Web App allows you to deploy containers on the service using container images from Docker Hub or Azure Container Registry. The backend OS patching, capacity management, and load balancing of services are handled by the platform, and the service enables on-demand scaling, either through scale-up or scale-out options based on configured scaling rules. This also helps with cost management, where costs are automatically reduced during off-peak hours. The service ensures high availability as well since the container services can be deployed across multiple Azure Regions.

Google Cloud Platform

Kubernetes, which originated as a Google in-house project, offers a strong suite of products for managed container hosting both in the cloud and on-premises.

1. Google Kubernetes Engine

Google Kubernetes Engine (GKE) is the managed Kubernetes service from GCP that can be used to host highly available and scalable container workloads. It also provides a GKE sandbox option, if you need to run workloads prone to security threats in an isolated environment.

GKE clusters can be deployed as both multi-zonal and regional to protect workloads from cloud outages. GKE also comes with many out-of-the-box security features, such as data encryption and vulnerability scanning for container images through integration with the Container Analysis service.

As with the managed Kubernetes services provided by the other cloud service providers, GKE offers automated repair of faulty nodes, upgrades, and on-demand scaling. It can also be integrated with GCP monitoring services for in-depth visibility into the health of deployed applications.

If you’re planning to host graphic-intensive, HPC, and ML workloads, you can augment GKE through specialized hardware accelerators like GPU and TPU during deployment. Finally, GKE offers per-second billing and—for development environments that can tolerate downtime—an option to use preemptible VMs for your cluster to further reduce costs.

2. Cloud Run

If you’re looking to run containerized applications in GCP without the overhead of managing the underlying infrastructure, Cloud Run is one option. With this fully managed serverless hosting service for containers, you’re charged only for the resources consumed by the containers.

Cloud Run can also be deployed into Anthos GKE clusters or on-premises workloads. Well integrated with other GCP services such as Cloud Code, Cloud Logging, Monitoring, Artifact Registry, and Cloud Build, Cloud Run meets all your containerized application development needs.

Hybrid Deployments

For many organizations, the first step of their cloud adoption journey is implementing hybrid deployments, where some of the components for their containerized application remain on-premises and others are moved to the cloud. There are several popular tools and services available to help meet the needs of hybrid and multicloud deployments, and all leading cloud providers have focused investments in this space.

1. Azure Arc

Azure Arc provides a unified Azure-based management platform for servers, data services, and Kubernetes clusters deployed on-premises as well as across multicloud environments.

Azure Arc-enabled Kubernetes clusters support multiple popular distributions of Kubernetes that are certified by the Cloud Native Computing Foundation (CNCF). The service allows you to list Kubernetes clusters across heterogeneous environments in Azure for a unified view and enables integration with Azure management capabilities, such as Azure Policy and Azure Monitor.

2. Google Anthos

Google Cloud’s Anthos is a comprehensive and advanced solution that can be leveraged to deploy managed Kubernetes clusters in the cloud and on-premises. Anthos provides a GKE on-premises option you can use to deploy new GKE clusters into your private cloud on-premises. It's also possible to register existing non-GKE clusters with Anthos. GKE on AWS helps in multicloud scenarios, where a compatible GKE environment in AWS can be created, updated, or deleted using a management service from the Anthos UI. Meanwhile, Anthos Config Management and Service Mesh solutions help with policy automation, security management, and visibility into your applications deployed across multiple clusters for a unified management experience.

3. AWS Outposts

AWS Outposts is a hybrid cloud service that brings AWS services, including container services like EKS, to your on-premises data center. Currently shipped as a 42U rack unit, this service is installed, updated, and fully managed by AWS. The solution can be connected to a local AWS Region for a hybrid experience, where the services in Outposts can connect directly to the services in the cloud.

AWS Outposts targets customers who prefer to deploy containerized workloads on-premises for data residency, local processing, and more, while having the flexibility to use AWS Cloud’s supporting services for their applications.

The recently announced EKS Anywhere is another option, designed to deliver the same experience as Amazon EKS for Hybrid deployments. EKS Anywhere is expected to be available in 2021.

Choosing the Right Container Service

With the wide spectrum of services available in the cloud for hosting containerized workloads, the first step in choosing the right service for your requirements is to map your specific application requirements to features of a given service. Managed container services from the major cloud service providers are recommended, as they offer better integration with their own cloud platform services.

When choosing the best container service for your application, opt for production-ready services while avoiding potential vendor lock-in. You should also take into consideration the solution’s future roadmap as well as ease of monitoring, logging, availability, scalability, security management, and automation.

Starting with a managed Kubernetes service is a great option, as Kubernetes is best suited for scalable, secure, and highly available production deployments. If there are clear requirements for hybrid integration, where some of your containerized workloads might remain on-premises, opt for hybrid solutions like Azure Arc or Google Anthos. And finally, if you are looking for simple isolated container deployments, serverless solutions may be the best fit.

13 Best Practices for using Helm

Kentaro Wakayama — Mon, 21 Jun 2021 00:51:27 +0000

Helm is an indispensable tool for deploying applications to Kubernetes clusters. But it is only by following best practices that you’ll truly reap the benefits of Helm. Here are 13 best practices to help you create, operate, and upgrade applications using Helm.

Take Your Helm Charts to the Next Level

Helm is the package manager for Kubernetes. It reduces the effort of deploying complex applications thanks to its templating approach and rich ecosystem of reusable and production-ready packages, also known as Helm charts. With Helm, you can deploy packaged applications as a collection of versioned, pre-configured Kubernetes resources.

Let's assume you’re deploying a database with Kubernetes—including multiple deployments, containers, secrets, volumes, and services. Helm allows you to install the same database with a single command and a single set of values. Its declarative and idempotent commands makes Helm an ideal tool for continuous delivery (CD).

Helm is a Cloud Native Computing Foundation (CNCF) project created in 2015 and graduated in April 2020. With the latest version of Helm 3, it has become even more integrated into the Kubernetes ecosystem.

This article features 13 best practices for creating Helm charts to manage your applications running in Kubernetes.

1. Take Advantage of the Helm Ecosystem

Helm gives you access to a wealth of community expertise—perhaps the tool’s greatest benefit. It collects charts from developers worldwide, which are then shared through chart repositories. You can add the official stable chart repository to your local setup as follows:

$ helm repo add stable https://charts.helm.sh/stable

"stable" has been added to your repositories

Then you can search for charts, for example, MySQL:  

$ helm search hub mysql

URL CHART VERSION  APP VERSION DESCRIPTION

https://hub.helm.sh/charts/bitnami/mysql 8.2.3 8.0.22 Chart to create a Highly available MySQL cluster

https://hub.helm.sh/charts/t3n/mysql 0.1.0 8.0.22 Fast, reliable, scalable, and easy to use open-...

You will see a long list of results, which shows how big the Helm chart ecosystem is.

2. Use Subcharts to Manage Your Dependencies

Because applications deployed to Kubernetes consist of fine-grained, interdependent pieces, their Helm charts have various resource templates and dependencies. For instance, let's assume your backend relies on a database and a message queue. The database and message queue are already standalone applications (e.g. PostgreSQL and RabbitMQ). Creating or using separate charts for the standalone applications and adding them to the parent charts is therefore recommended. The dependent applications are named as subcharts here.

There are three essential elements for creating and configuring subcharts:

1. Chart structure
The folder structure should be in the following order:

backend-chart
  - Chart.yaml
  - charts
      - message-queue
          - Chart.yaml
          - templates
          - values.yaml
      - database
          - Chart.yaml
          - templates
          - values.yaml
  - values.yaml

2. Chart.yaml

Additionally, the chart.yaml in the parent chart should list any dependencies and conditions:

apiVersion: v2
name: backend-chart
description: A Helm chart for backend
...
dependencies:
  - name: message-queue
    condition: message-queue.enabled
  - name: database
    condition: database.enabled

3. values.yaml

Finally, you can set or override the values of subcharts in the parent chart with the following values.yaml file:

message-queue:
  enabled: true
  image:
    repository: acme/rabbitmq
    tag: latest
database:
  enabled: false

Creating and using subcharts establishes an abstraction layer between the parent and dependency applications. These separate charts make it easy to deploy, debug, and update applications in Kubernetes with their separate values and upgrade lifecycles. You can walk through the folder structure, dependencies, and value files in a sample chart like bitnami/wordpress.

3. Use Labels to Find Resources Easily

Labels are crucial to Kubernetes’ internal operations and the daily work of Kubernetes operators. Almost every resource in Kubernetes offers labels for different purposes such as grouping, resource allocation, load balancing, or scheduling.

A single Helm command will allow you to install multiple resources. But it’s vital to know where these resources originate. Labels enable you to find your resources created by Helm releases quickly.

The most common method is to define labels in helpers.tpl, like so:

{{/*
Common labels
*/}}

{{- define "common.labels" -}} 
app.kubernetes.io/instance: {{ .Release.Name }}
app.kubernetes.io/managed-by: {{ .Release.Service }}
{{- end -}}

You then need to use the “include” function with labels in the resource templates:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-queue
  labels:
{{ include "common.labels" . | indent 4 }}
...

Now you should be able to list all resources with the label selectors. For example, you can list all the pods of my-queue deployment with the kubectl get pods -l app.kubernetes.io/instance=[Name of the Helm Release] command. This step is essential for locating and debugging those resources managed by Helm.

4. Document Your Charts

Documentation is essential for ensuring maintainable Helm charts. Adding comments in the resource templates and the README helps teams with the development and use of Helm charts.

You should use the following three options to document your charts:

Comments: Template and values files are YAML files. You can add comments and provide helpful information about the fields inside the YAML files.
README: A chart’s README is a markdown file that explains how to use the charts. You can check the contents of a README file with the following command: helm show readme [Name of the Chart]
NOTES.txt: This is a special file located at templates/NOTES.txt that provides helpful information about the deployment of releases. The content of the NOTES.txt file can also be templated with functions and values similar to resource templates:

You have deployed the following release: {{ .Release.Name }}.
To get further information, you can run the commands:
  $ helm status {{ .Release.Name }}
  $ helm get all {{ .Release.Name }}

At the end of the helm install or helm upgrade command, Helm prints out the content of the NOTES.txt like so:

RESOURCES:
==> v1/Secret
NAME        TYPE      DATA      AGE
my-secret   Opaque    1         0s

==> v1/ConfigMap
NAME           DATA      AGE
db-configmap   3         0s

NOTES:
You have deployed the following release: precious-db.
To get further information, you can run the commands:
  $ helm status precious-db
  $ helm get all precious-db

5. Test Your Charts

Helm charts consist of multiple resources that are to be deployed to the cluster. It is essential to check that all the resources are created in the cluster with the correct values. For instance, when deploying a database, you should check that the database passwords are set correctly.

Fortunately, Helm offers a test functionality to run some containers in the cluster in order to validate applications. For example, the resource templates annotated with "helm.sh/hook": test-success are run by Helm as test cases.

Let's assume you are deploying WordPress with the MariaDB database. The Helm chart maintained by Bitnami has a pod to validate the database connection with the following definition:

...
apiVersion: v1
kind: Pod
metadata:
  name: "{{ .Release.Name }}-credentials-test"
  annotations:
    "helm.sh/hook": test-success
...
      env:
        - name: MARIADB\_HOST
          value: {{ include "wordpress.databaseHost" . | quote }}
        - name: MARIADB\_PORT
          value: "3306"
        - name: WORDPRESS\_DATABASE\_NAME
          value: {{ default "" .Values.mariadb.auth.database | quote }}
        - name: WORDPRESS\_DATABASE\_USER
          value: {{ default "" .Values.mariadb.auth.username | quote }}
        - name: WORDPRESS\_DATABASE\_PASSWORD
          valueFrom:
            secretKeyRef:
              name: {{ include "wordpress.databaseSecretName" . }}
              key: mariadb-password
      command:
        - /bin/bash
        - -ec
        - |
          mysql --host=$MARIADB\_HOST --port=$MARIADB\_PORT --user=$WORDPRESS\_DATABASE\_USER --password=$WORDPRESS\_DATABASE\_PASSWORD
  restartPolicy: Never
{{- end }}
...

It is recommended to write tests for your charts and to run them after the installation. For example, you can use the helm test <RELEASE_NAME> command to run tests. The tests are a valuable asset for validating and finding issues in applications installed with Helm.

6. Ensure Secrets Are Secure

Sensitive data, such as keys or passwords, are stored as secrets in Kubernetes. Although it is possible to secure secrets on the Kubernetes side, they are mostly stored as text files as part of Helm templates and values.

The helm-secrets plugin offers secret management and protection for your critical information. It delegates the secret encryption to Mozilla SOPS, which supports AWS KMS, Cloud KMS on GCP, Azure Key Vault, and PGP.

Let's assume you’ve collected your sensitive data in a file named secrets.yaml as follows:

postgresql:
  postgresqlUsername: postgres
  postgresqlPassword: WoZpCAlBsg
  postgresqlDatabase: wp

You can encrypt the file with the plugin:

$ helm secrets enc secrets.yaml
Encrypting secrets.yaml
Encrypted secrets.yaml

Now, the file will be updated and all values will be encrypted:

postgresql:
    postgresqlUsername: ENC\[AES256\_GCM,data:D14/CcA3WjY=,iv...==,type:str\]
    postgresqlPassword: ENC\[AES256\_GCM,data:Wd7VEKSoqV...,type:str\]
    postgresqlDatabase: ENC\[AES256\_GCM,data:8ur9pqDxUA==,iv:R...,type:str\]
sops:
  ...

The data in secrets.yaml above was not secure and helm-secrets solves the problem of storing sensitive data as part of Helm charts.

7. Make Your Chart Reusable by Using Template Functions

Helm supports over 60 functions that can be used inside templates. The functions are defined in the Go template language and Sprig template library. Functions in template files significantly simplify Helm operations.

Let's look at the following template file as an example:

apiVersion: v1
kind: ConfigMap
metadata:
  name: {{ .Release.Name }}-configmap
data:
  environment: {{ .Values.environment | default "dev" | quote }}
  region: {{ .Values.region | upper | quote }}

When the environment value is not provided, it will be defaulted by the template function. When you check the region field, you’ll see there is no default value defined in the template. However, the field has another function called upper to convert the provided value into uppercase.

Another essential and useful function is required. It enables you to set a value as required for template rendering. For instance, let's assume you need a name for your ConfigMap with the following template:

...
metadata:
  name: {{ required "Name is required" .Values.configName }}
...

If the entry is empty, the template rendering will fail with the error Name is required. Template functions are very useful when creating Helm charts. They can improve templating, reduce code duplication, and can be used to validate values before deploying your applications to Kubernetes.

8. Update Your Deployments When ConfigMaps or Secrets Change

It is common to have ConfigMaps or secrets mounted to containers. Although the deployments and container images change with new releases, the ConfigMaps or secrets do not change frequently. The following annotation makes it possible to roll out new deployments when the ConfigMap changes:

kind: Deployment
spec:
  template:
    metadata:
      annotations:
        checksum/config: {{ include (print $.Template.BasePath "/configmap.yaml") . | sha256sum }}
...

Any change in the ConfigMap will calculate a new sha256sum and create new versions of deployment. This ensures the containers in the deployments will restart using the new ConfigMap.

9. Opt Out of Resource Deletion with Resource Policies

In a typical setup, after installing a Helm chart, Helm will create multiple resources in the cluster. You can then upgrade it by changing values and adding or removing resources. Once you no longer need the application, you can delete it, which removes all resources from the cluster. Some resources, however, should be kept in the cluster even after running Helm uninstall. Let's assume you’ve deployed a database with PersistentVolumeClaim and want to store the volumes even if you are deleting the database release. For such resources, you need to use the resource-policy annotations as follows:

kind: Secret
metadata:
  annotations:
    "helm.sh/resource-policy": keep
...

Helm commands, such as uninstall, upgrade, or rollback would result in the deletion of the above secret. But by using the resource policy as shown, Helm will skip the deletion of the secret and allow it to be orphaned. The annotation should therefore be used with great care, and only for the resources needed after Helm Releases has been deleted.

10. Useful Commands for Debugging Helm Charts

Helm template files come with many different functions and multiple sources of values for creating Kubernetes resources. It is an essential duty of the user to know what is deployed to the cluster. Therefore, you need to learn how to debug templates and verify charts. There are four essential commands to use for debugging:

helm lint: The linter tool conducts a series of tests to ensure your chart is correctly formed.
helm install --dry-run --debug: This function renders the templates and shows the resulting resource manifests. You can also check all the resources before deployment and ensure the values are set and the templating functions work as expected.
helm get manifest: This command retrieves the manifests of the resources that are installed to the cluster. If the release is not working as expected, this should be the first command you use to find out what is running in the cluster.
helm get values: This command is used to retrieve the release values installed to the cluster. If you have any doubts about computed or default values, this should definitely be in your toolbelt.

11. Use the lookup Function to Avoid Secret Regeneration

Helm functions are used to generate random data, such as passwords, keys, and certificates. Random generation creates new arbitrary values and updates the resources in the cluster with each deployment and upgrade. For example, it can replace your database password in the cluster with every version upgrade. This causes the clients to be unable to connect to the database after the password change.

To address this, it is recommended to randomly generate values and override those already in the cluster. For example:

{{- $rootPasswordValue := (randAlpha 16) | b64enc | quote }}
{{- $secret := (lookup "v1" "Secret" .Release.Namespace "db-keys") }}
{{- if $secret }}
{{- $rootPasswordValue = index $secret.data "root-password" }}
{{- end -}}
apiVersion: v1
kind: Secret
metadata:
  name: db-keys
  namespace: {{ .Release.Namespace }}
type: Opaque
data:
  root-password: {{ $rootPasswordValue}}

The template above first creates a 16-character randAlpha value, then checks the cluster for a secret and its corresponding field. If found, it overrides and reuses the rootPasswordValue as root-password.

12. Migrate to Helm 3 for Simpler and More Secure Kubernetes Applications

The latest Helm release, Helm 3, offers many new features to make it a lighter, more streamlined tool. Helm v3 is recommended for its enhanced security and simplicity. This includes:

Removal of Tiller: Tiller was the Helm server-side component but has been removed from v3 due to the exhaustive permissions required to make changes on the cluster in earlier versions. This also created a security risk, as anyone gaining access to Tiller would have excessive permissions to your cluster.
Improved chart upgrade strategy: Helm v2 relies on a two-way strategic merge patch. It compares the new release with the one in the ConfigMap storage and applies the changes. Conversely, Helm v3 compares the old manifest, the state in the cluster, and the new release. So your manual changes will not be lost while upgrading your Helm releases. This simplifies the upgrade process and enhances the reliability of the applications.

There is a helm-2to3 plugin, which you can install with the following command:

$ helm3 plugin install https://github.com/helm/helm-2to3

It is a small but helpful plugin with cleanup, convert, and move commands to help you migrate and clean up your v2 configuration and create releases for v3.

13. Keep Your Continuous Delivery Pipelines Idempotent

Kubernetes resources are declarative in the sense that their specification and status are stored in the cluster. Similarly, Helm is required to create declarative templates and releases. Therefore, you need to design your continuous delivery and release management to be idempotent while using Helm. An idempotent operation is one you can apply many times without changing the result following the first run.

There are two essential rules to follow:

Always use the helm upgrade --install command. It installs the charts if they are not already installed. If they are already installed, it upgrades them.
Use --atomic flag to rollback changes in the event of a failed operation during helm upgrade. This ensures the Helm releases are not stuck in the failed state.

Summary

Helm is an indispensable tool for deploying applications to Kubernetes clusters. But it is only by following best practices that you’ll truly reap the benefits of Helm.

The best practices covered in this article will help your teams create, operate, and upgrade production-grade distributed applications. From the development side, your Helm charts will be easier to maintain and secure. From the operational side, you’ll enjoy automatically updated deployments, save resources from deletion, and learn how to test and debug.

Helm’s official topics guide is another good resource for checking the Helm commands and understanding their design philosophy. With these resources as well as the best practices and examples outlined in this blog, you’ll surely be armed and ready to create and manage production-grade Helm applications running on Kubernetes.

For our latest insights and updates, follow us on LinkedIn

Originally published at https://codersociety.com

Revisiting the Twelve Factor App Methodology

Kentaro Wakayama — Sun, 13 Jun 2021 21:24:13 +0000

Having well-defined guidelines in place can facilitate your software projects, especially more complex ones. But you don’t necessarily need to invest the time and effort to document these practices from scratch. Instead, teams can leverage best practices documented by other reputable companies and adapt them for their own projects.

The Twelve Factor App, first presented around 2011, is a set of language-agnostic guidelines used to develop modern enterprise-grade software as a service. It promotes discipline in software development while addressing architectural, deployment, and operational concerns in building software at scale. While suitable for cloud-native applications, it works just as well with software of a similar nature that is hosted on premises.

So how does the Twelve Factor App hold up today? Let’s review each of the twelve factors and see.

1. Codebase

A Twelve Factor App requires code to be stored in source control (e.g., Git), and defines the one-to-many relationship between a codebase and deploys (running instances of the app) resulting from it. It’s quite typical to have different versions of the app (from different commits) running in different environments.

Nowadays, the advantages of source control are well understood. Storing source code and its history centrally prevents accidents like lost code. This also facilitates many operations that have become a staple of software development, such as branching, merging, reverting changes, cherry-picking, and others. Thanks to well-established processes such as git-flow, even large teams can work on the same code concurrently.

2. Dependencies

Managing dependencies can be tricky, especially when they’re hidden or conflicting between apps. That’s why the Twelve Factor App recommends declaring dependencies using the relevant programming language’s package manager. It also recommends that dependencies are packaged with the application rather than relying on system-wide dependencies or tools.

Declaring and isolating dependencies helps avoid conflicts between different applications that run on the same host but require different dependencies. Containers are a great way to package applications together with their dependencies, while at the same time abstracting the underlying environment and isolating them from each other.

3. Config

The Twelve Factor App recognises that while the same code is deployed across environments, configuration is different for each environment. Therefore, configuration should be strictly separated from code and stored in environment variables. This means that only one application build needs to be created which can be tested, deployed, and run in multiple environments.

The Twelve Factor App doesn’t say how to store secrets, such as passwords or API tokens. And while secrets can be thought of as configuration, their sensitive nature warrants special treatment. We recommend managing these using a secret management tool, such as HashiCorp Vault, AWS Secrets Manager, or any other valid tool in this category.

4. Backing Services

Any external dependency accessed over a network (e.g., an SQL or NoSQL database, API, SMTP service, etc.) should be specified in the application’s configuration. By simply changing the configuration, an external dependency should also be replaceable with a similar service.

5. Build, Release, Run

Taking a codebase and turning it into a running application in a particular environment involves the following stages:

The build stage uses the code and its dependencies to produce a build.
The release stage uses the build and its configuration to produce a release.
The run stage runs one or more instances of the release.

This process enables a clear separation of concern and should be automated, using continuous integration and continuous deployment (CI/CD) pipelines. The CD part also maintains a history of deployments, making it easy to revert to an earlier version if necessary. Releases are generally immutable, so any change must create a new release.

Developer time is expensive and should not be wasted, so this process needs to be fast. Small optimizations that reduce the time it takes to build and deploy new code (e.g., faster builds, quality checks, or deployments) can have a big positive impact.

6. Processes

Apps and services should be stateless, with any state residing in a backing store. This is an important prerequisite for other Twelve Factor guidelines, such as concurrency and disposability.

This approach provides important operational benefits, making it easier to scale and recover from failures. It’s also beneficial from a developer perspective: separating mutable data and side effects from logic makes the code deterministic, and therefore easier to test and parallelize.

7. Port Binding

Twelve Factor Apps are self-contained and independent processes that do not run under the control of a parent process. They expose their services by listening on a port. This also means that they can act as backing services for other apps.

8. Concurrency

Twelve Factor Apps can be scaled out by running multiple instances of the same application. Stateless processes are easy to spin up and down as necessary, either manually or automatically based on metrics or a schedule. At the same time, apps with isolated dependencies minimise the risk of issues when they run side by side on different hosts.

In this context, minimising startup time means that the system can adapt more quickly to varying load. This is another benefit of containers, which are lightweight and much quicker to boot up when compared to virtual machines.

9. Disposability

The Twelve Factor App assumes that an application can go down at any time for any reason: elastically scaling resources to meet demand, hardware failures, or even intentional application restarts. Where possible, the app can gracefully dispose of any resources by handling an appropriate shutdown signal, like SIGTERM.

When designing apps around disposability, it helps if they are stateless. In that case, they only need to clean up the resources being used as part of request processing, as opposed to in-memory state that could be expensive to replenish (e.g., cache). Minimizing startup time is also useful, since running instances of an app can recover more quickly when they are physically relocated elsewhere.

10. Dev/Prod Parity

It is a matter of good discipline in software development (as well as operations) to keep different environments in sync. This includes:

Using the same type of backing software (e.g., databases) in both development and production
Deploying frequently to minimize the gap between code on different environments
Giving developers the responsibility to deploy and monitor their own applications, rather than having a separate operations team take care of this

Although the Twelve Factor App suggests that developers entirely take over operational responsibilities, in practice this is not entirely necessary. It is quite common to have one or more DevOps engineers as part of a development team, ensuring that team goals are aligned across development and operational concerns, while at the same time making the best use of skill specialization.

11. Logs

The Twelve Factor App is very clear that logs should be written to standard output and treated like an event stream. The application doesn’t care where logs are ultimately stored; it is up to the execution environment to pick them up and route them to the appropriate destination.

Conversely, an application that buffers logs in memory and periodically flushes them to a database is inherently flawed because:

It becomes coupled with the log storage, taking on additional dependencies to communicate with it, and the log storage can’t be changed without changing the application.
Log management has a direct and non-negligible impact on the application’s CPU and memory usage.
This is in violation of the process being stateless.

Therefore, it is recommended to decouple the application from its log storage. It’s also imperative to avoid logging sensitive data, such as personally-identifiable information or credentials.

12. Admin Processes

One-off processes like database migrations are an integral part of a release. Many of the points from the Twelve Factor App itself also apply to these one-off processes. Such tasks are stored in the same codebase and released as part of the same release process.

However, under this point, The Twelve Factor App also recommends using a REPL shell to “run arbitrary code or inspect the app’s models against the live database.” It also suggests using ssh to run arbitrary processes on production. We disagree with these approaches. For security and risk management reasons, all deploys should go through a proven CI/CD process and there should be no developer access to production.

Conclusion

After 10 years, it's amazing to see how the Twelve Factor App holds up. It is still a great foundation for software teams building applications that need a certain level of scale, reliability, and maintainability. It is especially useful as acceptance criteria when evaluating whether software is production ready.

For our latest insights and updates, follow us on LinkedIn

Originally published at https://codersociety.com

5 Reasons to use GraphQL at Your Company

Kentaro Wakayama — Mon, 07 Dec 2020 17:23:50 +0000

GraphQL is on the rise. Companies like Facebook, Netflix, Shopify or PayPal are using the data language and API technology to drive their products. Learn in this article, why you should be using it at your company.

This article was originally published at Coder Society.

The Rise of GraphQL

What is the best way to build an API today? REST probably comes to mind, but if you’re going to make the investment to build new software, it’s probably worth considering a few different options and choosing the best among them.

GraphQL stands out as an alternative to the REST API architecture mainly (but not only) because it provides a discoverable API by design. It also comes with its own query language and a runtime for fulfilling queries via functions called resolvers.

Originally developed in 2012 at Facebook as a better data-fetching solution for underpowered mobile devices, GraphQL was open-sourced in 2015. In 2018, it was moved under the care of the Linux Foundation, which maintains other important projects like Node.js, Kubernetes, and, of course, Linux itself.

The general movement around GraphQL is very encouraging for anyone looking to adopt it. Its popularity has been rapidly on the rise over the last few years, as seen on Stack Overflow Trends, for example. There are also several success stories at reputable companies such as PayPal, Netflix, and Coursera, where GraphQL was instrumental in building flexible and high-performant APIs in large, complex architectures.

However, given the dynamic technology landscape in which we operate today, you would be forgiven for being skeptical. Could GraphQL be another fad? If it works for these companies, does that necessarily mean it will work for you? Let’s discuss the benefits and challenges of GraphQL, so that you can make an informed decision.

Reasons to Use GraphQL

As an API technology designed for flexibility, GraphQL is a strong enabler for both developers and consumers of APIs, as well as the organizations behind them. In this section, we’ll explore some of the key areas where GraphQL shines.

1. One Data Graph for All

GraphQL is an excellent choice for organizations with multiple teams and systems that want to make their data easily available through one unified API.

No matter how many databases, services, legacy systems, and third-party APIs you use, GraphQL can hide this complexity by providing a single endpoint that clients can talk to. The GraphQL server is responsible for fetching data from the right places, and clients never need to know the details of where different pieces of data are coming from. As a result, the GraphQL ecosystem provides maximum flexibility when it comes to making data easily available for customers and internal users.

2. No Over-Fetching or Under-Fetching

Another huge benefit for GraphQL API clients is that they can request exactly what data they need, even across related entities. This is especially important because different clients have different data requirements, either because of a different business logic or because they are simply presenting a different view of data (e.g., web vs. mobile) and may also have different hardware limitations.

By way of comparison, it’s much harder to efficiently retrieve nontrivial data from a REST API. Requesting data from a single endpoint will often return more data than is actually needed (overfetching), whereas requesting data about several related entities usually requires either several API calls (underfetching) or dedicated endpoints for specific client requests (which duplicates effort). GraphQL solves this issue by serving exactly the data which each client requests, nothing more and nothing less.

3. Better Developer Experience

The GraphQL ecosystem comes with a number of tools that make working with GraphQL a breeze. Tools such as GraphiQL and GraphQL Playground provide a rich experience, allowing developers to inspect and try out APIs with minimal effort, thanks to the self-documenting features which we will get to in the next section.

Also, code generation tools like GraphQL Code Generator can be used to further speed up development, while other tools and best practices exist to address specific problems including:

Client-side caching is available out of the box in several client libraries.
Cursor-based pagination provides a way to offer pagination across lists of data.
The DataLoader improves performance by batching data fetch requests and also provides a basic level of server-side caching.

4. Higher Quality of Your System

GraphQL APIs are built around a type system, which lays out the name and type of each field as well as the relationships between different entities. This type system, or schema, is used to validate queries sent by the client. The schema can be queried via a feature called introspection, which is often used to generate documentation and code that will be used when integrating the API on the client-side.

As a result, it requires minimal effort to have a well-documented API when using GraphQL. This provides great transparency to developers who are working with an API for the first time and makes development smoother and more efficient.

5. Build for Change

It is common for REST APIs to provide multiple versions of the same API so that it can change without breaking the existing functionality. GraphQL encourages a different approach to API modifications: evolution.

When breaking changes are required (for instance, renaming a field or changing its type), you can introduce a new field and deprecate the old one, possibly removing it completely later on when you’re sure it’s no longer being used. This means that you can still change your API while maintaining backward compatibility and a single API.

Considerations Before Adopting GraphQL

GraphQL is an excellent tool to build scalable and flexible APIs, but it is not a panacea and is certainly not for everyone.

Learning Curve

Whereas REST is a simple and familiar approach to building APIs, GraphQL is a different beast altogether. Developers and infrastructure engineers alike will need to learn how to effectively develop and deploy GraphQL APIs, a task that will take some getting used to.

As a result, teams that are on a tight schedule are probably better off using a technology with which they’re already familiar.

Infrastructure and Tooling

Deploying GraphQL, especially at scale, can require significant investment in infrastructure and tooling. Using it does not save you from having to deploy virtual machines or containers, set up a networking infrastructure, and deploy and maintain GraphQL server software across a large environment.

Performance and Security

You also have to be extra careful that the additional flexibility afforded by GraphQL does not result in queries that maliciously or accidentally degrade or take down your system. This can be addressed by rate limiting or limiting query complexity and depth.

Finally, it is always important to protect data that should not be public. Authentication and authorization mechanisms that are popular among other web technologies can also be used with GraphQL. Plus, pay attention to introspection, as it can leak internal types if not correctly secured.

Conclusion

There is no doubt that REST gets the job done, but if you’re at a point where you need a better way to build APIs and serve diverse clients, then you should probably give GraphQL a try.

GraphQL allows you to build evolvable and queryable APIs, hide the complexity of internal systems used to retrieve various pieces of data, and leverage a type system that results in automatic and up-to-date API documentation. These features, along with its tooling and ecosystem, make GraphQL an efficient and effective tool for API and client developers alike.

Although GraphQL does require some investment, this is far outweighed by its advantages in situations where there are lots of data and services that should be made accessible to various existing and future API clients.

For our latest insights and updates, follow us on LinkedIn

Introduction to GraphQL for Developers

Kentaro Wakayama — Tue, 24 Nov 2020 11:13:44 +0000

GraphQL is a powerful query language for APIs and a runtime for resolving queries with data.

This article was originally published at Coder Society.

We’ll explore GraphQL’s core features, how to interact with a GraphQL API, and some development and operational challenges.

The Story of GraphQL

Nowadays, REST seems to be the default approach for building APIs, typically based on the familiar HTTP protocol. While REST is relatively simple to work with and enjoys widespread popularity, its use of multiple endpoints to address resources sometimes gets in the way of flexibility.

With such a rigid approach, some clients will get more data than they actually need (overfetching), whereas others will not get enough from a single endpoint (underfetching). This is a common issue among endpoint-based APIs like REST, and API clients have to compensate for it---for example, by issuing multiple requests and having to do the work of bringing data into the right shape on the client side.

With GraphQL, however, clients can request exactly the data that they need---no more and no less---similar to querying specific fields in a database. GraphQL was developed at Facebook in 2012, when the company was reworking its mobile apps and needed a data-fetching technology that was friendly even to low-resource devices. It was open-sourced in 2015 and moved to the GraphQL Foundation in 2018.

Features of GraphQL

GraphQL shares some similarities with REST. It allows clients to request and manage data from APIs via a request-response protocol, typically run on top of HTTP. However, the way that data is organized, requested, and served is very different.

GraphQL provides the following operations to work with data, via a single endpoint:

Queries: Allow clients to request data (similar to a GET request in REST).
Mutations: Allow clients to manipulate data (i.e., create, update, or delete, similar to POST, PUT, or DELETE, respectively).
Subscriptions: Allow clients to subscribe to real-time updates.

Therefore, at the surface, GraphQL can cover your typical API requirements. Do not be misled by the "QL" into thinking that it's used just for data retrieval.

A GraphQL API is based on a type system or schema which describes the capabilities and data structures of the API. The schema is defined using the GraphQL Schema Definition Language (SDL) and includes all the different types, their fields, and how they are related. Using a feature called introspection, clients can query the schema itself. This functionality is particularly useful for tooling, such as code generation and autogeneration of API documentation. For example, projects such as GraphiQL and GraphQL Playground leverage this functionality to provide rich documentation and integrated querying experiences.

What makes GraphQL so powerful is that clients can request exactly the data they need, not more and not less. It's also possible to request related data in the same query without the need for additional API calls. We'll see some examples in the next section.

A GraphQL server evaluates each incoming API request and resolves the values for each requested field using resolver functions. The resolver functions are doing the real work by, for example, fetching data from databases or other systems. This makes GraphQL an ideal solution for heterogeneous environments where data is located in different sources.

Working with GraphQL

In order to understand a little better what it's like to interact with a GraphQL API, let's take a look at a few simple examples. We're going to use an updated Star Wars example server, which provides a fully functional GraphQL API with some example data, as well as GraphQL Playground. Simply follow these instructions to get it up and running:

Clone the example repository:

$ git clone https://github.com/coder-society/starwars-server

Install dependencies:

$ cd starwars-server

$ npm install

Start the GraphQL server:

$ npm start

Visit http://localhost:8080/graphql to access the GraphQL Playground interface.

Figure 1: Exploring the API via GraphQL Playground's "Docs" tab

So here we are, looking at an unfamiliar API for the first time. Where do we start? What does it offer? Fortunately, GraphQL Playground provides rich API and schema documentation by leveraging GraphQL's introspection feature. Simply click on the "Docs" or "Schema" tab on the right to explore the API.

Queries

You can use the information in the API docs to create your first query:

query  {

humans {

    id

    name

  }

}

This humans query gives us a list of entities, which are of type Human, and we list the fields we want returned inside the inner curly brackets. In this case we're specifying that we want id and name, but we could also have returned any combination of fields supported by the Human type. This returns the following output:

{

  "data":  {

    "humans":  [

      {

        "id":  "1000",

        "name":  "Luke Skywalker"

      },

      {

        "id":  "1001",

 "name":  "Darth Vader"

      },

      {

        "id":  "1002",

        "name":  "Han Solo"

      },

      {

        "id":  "1003",

        "name":  "Leia Organa"

      },

      {

        "id":  "1004",

        "name":  "Wilhuff Tarkin"

      }

    ]

  }

}

If we wanted to get specific information about one of these humans, we could use the human query, passing in the specific id value as an input to the query, as shown below:

query  {

human (id:  1001)  {

    homePlanet

  }

}

Again, the data we get back in the response corresponds to the fields we requested, as shown below:

{

  "data":  {

    "human":  {

      "homePlanet":  "Tatooine"

    }

  }

}

Figure 2: GraphQL Playground suggests fields you can include as you type

You can add other fields that you want returned, which you can discover by examining the aforementioned API and schema documentation, or simply by seeing the suggestions in GraphQL Playground as you type. Let's try a slightly bigger query:

query  {

  human(id:  1001)  {

    homePlanet

    name

    appearsIn

starships {

      id

      name

    }

  }

}

This is a little more interesting because it also queries related data, in this case a starships field, in which we are arbitrarily retrieving the id and name of a list of starships (entities of type Starship). The response for this query is:

{

  "data":  {

    "human":  {

      "homePlanet":  "Tatooine",

      "name":  "Darth Vader",

      "appearsIn":  [

        "NEWHOPE",

        "EMPIRE",

        "JEDI"

      ],

      "starships":  [

        {

          "id":  "3002",

          "name":  "TIE Advanced x1"

        }

      ]

    }

  }

}

While there is a lot more to be said about querying GraphQL APIs, these simple examples demonstrate how easy it is to consume a GraphQL API. With a single API, it's possible to serve a wide variety of clients with very different needs. For example, a mobile client might want to request only a subset of the data that a web app would need.

Mutations and Subscriptions

GraphQL can do more than just query data. The Star Wars example we're using provides one mutation example (adding a review) and one subscription example (getting notified when a review is added).

Let's go back to GraphQL Playground and execute the following to start a subscription:

subscription {

reviewAdded {

    episode

    stars

    commentary

  }

}

What this does is to wait for updates related to a review being added, and when they're available, it returns the episode, stars, and commentary fields. Just as with queries, we choose what data we're interested in receiving.

Since we can't continue writing queries while listening on a subscription, we can simply open a new tab in GraphQL Playground and execute the following mutation:

mutation  {

  createReview(episode:  NEWHOPE,  review:  {

    stars:  5,

    commentary:  "Awesome"

  })  {

    episode

    stars

    commentary

  }

}

As with queries, the inputs are in the round brackets (including a non-trivial review object in this case), and the outputs are listed in curly brackets. In this particular example, the inputs and outputs are the same, which is not very useful; however, the output of a mutation can be used to retrieve information about a newly added entity, such as an identifier. The result of this mutation is the following:

{

  "data":  {

    "createReview":  {

      "episode":  "NEWHOPE",

      "stars":  5,

      "commentary":  "Awesome"

    }

  }

}

Since we have an active subscription, you'll see the above data reflected in that subscription, even as you continue adding reviews.

Figure 3: Reviews are pushed to a subscription in GraphQL Playground

Whether you want clients to query data, manipulate it, or receive real-time updates, GraphQL has you covered. It also offers a lot more functionality that we haven't covered, so please check the Queries and Mutations documentation to learn more about the available features.

GraphQL in the Real World

There is always a difference between developing software and running it in a production environment. In the case of GraphQL, it would be a shame to talk about its merits and fail to mention some of the challenges, tools, and techniques involved in using it successfully in real-world scenarios.

Effort

GraphQL's flexibility comes at a cost. GraphQL has a bigger learning curve than REST, and it takes some getting used to. It also requires care to understand and define every field that can be requested, since GraphQL is by its nature declarative.

GraphQL involves a certain amount of complexity in developing and maintaining APIs. Tooling is evolving quickly, and it takes a fair amount of effort to keep up with all the new developments. Some tools, such as GraphQL Code Generator, can help speed up development, but it's also important to be aware of any challenges and limitations (e.g., Apollo Federation currently does not support subscriptions).

Performance

Optimizing APIs and making sure they remain performant is a common theme among API technologies. However, with GraphQL it's easy to run into what is called the N+1 problem. Let's say that each article on a blog has a list of comments. Because of the way GraphQL executes resolvers, it will retrieve a list of articles (1 query), and for each article it will again retrieve a list of comments (n queries). This may lead to performance problems where too many operations are executed for a single query.

The GraphQL DataLoader provides a solution to this problem. Not only does it batch similar requests to minimize roundtrips, but it also offers a basic caching mechanism.

Security

GraphQL APIs, like other types of APIs, need to be hardened to ensure that only authorized clients can access the available data, and to prevent malicious or accidental denial of service. The former can be addressed using standard authentication/authorization techniques such as JSON Web Tokens, where restrictions can be applied across the whole API or on field level. The latter involves making sure that heavy queries do not cripple the API by limiting the depth, complexity, and server time allocated to queries.

If you are using internal types that should not be publicly accessible, it's also important to secure introspection queries to make sure internals are not leaked.

Federation

Apollo Federation is a solution for how to work with GraphQL in a distributed system. API clients should only be concerned with one data graph and a single GraphQL API endpoint, no matter how many GraphQL servers your architecture is made of.

Other Considerations

There are many other things to consider when deploying a GraphQL API, including:

Caching: GraphQL's great flexibility means that queries are very unpredictable and thus difficult to cache. Also, it is common practice to send queries over HTTP POST requests, which by their very nature are difficult to cache. Some client libraries, such as Apollo Client, mitigate this by providing advanced client-side caching features.
API versioning: GraphQL has a built-in deprecation mechanism, and it generally encourages APIs to evolve and retain backwards compatibility rather than introducing completely separate versions.
Uploading files: File upload is not part of the GraphQL spec, so you'll need to resort to workarounds or choose specific GraphQL servers which provide this functionality.

Wrapping Up

GraphQL is a fantastic technology for building evolvable and dynamic APIs that can adapt to the needs of diverse clients and use cases. It takes some getting used to, and it does have its development and operational challenges, like any other technology. Therefore, it's important to understand that GraphQL is another tool in your toolkit, and not something that makes REST obsolete. If you want to learn more about GraphQL and how it can help you build a future proof API, don't hesitate to reach out to us.

For our latest insights and updates, follow us on LinkedIn

Logging in Kubernetes with Loki and the PLG Stack

Kentaro Wakayama — Thu, 19 Nov 2020 08:50:48 +0000

What is Loki?

Loki is an open-source, multi-tenant log aggregation system. It can be used with Grafana and Promtrail to collect and access logs, similar to the ELK/EFK stack. While one can use Kibana and Elasticsearch to make advanced data analysis and visualizations, the Loki-based logging stack focuses on being light-weight and easy to operate.

Loki provides a query language called LogQL, which allows users to query logs. It is inspired by Prometheus' PromQL and can be considered to be a distributed "grep" that aggregates log sources.

One of the main differences to conventional logging systems is that Loki indexes just the metadata rather than the logs' whole contents. Therefore, the index becomes smaller, which reduces memory consumption and ultimately lowers costs. One drawback of this design is that queries might be less performant than having everything indexed and loaded in memory.

Logs are stored directly in cloud storage such as Amazon S3 or GCS without the need of having to store files on-disk. This simplifies operations and avoids issues such as running out of disk space.

This article was originally published at Coder Society.

8 Benefits of using Loki

Here are some of the key benefits of using Loki in your stack:

Easy to use: It's simple to setup and easy to operate.
Light-weight: It only indexes metadata instead of the full log messages like EFK is doing. This results in less expensive RAM instances required for Loki deployments.
Cloud-native: It works well together with other cloud-native tools such as Kubernetes, were metadata such as Pod labels are automatically scraped and indexed.
Uses Object storage: It uses object storage like Amazon S3 or GCS, which is usually cheaper than using block storage.
Scales horizontally: It can run as a single binary locally or for small scale operations and can easily be scaled horizontally for large scale operations.
Quorum consistency: It uses Dynamo-style quorum consistency for read and write operations to guarantee uniform query results.
Multi-tenancy support: It supports multi-tenancy through a tenant ID so that the tenant's data is stored separately.
Native Grafana support: It has native support in Grafana (needs Grafana v6.0).

Loki's Use Cases

Now that we've talked about Loki's benefits, let's also look at some popular use cases:

Debugging and troubleshooting: Loki helps DevOps teams get to the bottom of problems faster by providing helpful information related to the issue at hand. For example, it is easy to see when a problem arose, what exactly happened, and how the issue came about.

Monitoring: Prometheus is widely used in the industry for monitoring. However, you can identify many issues by monitoring your logs with Loki. For example, you can use it to keep an eye on your website's error rates and receive an alert whenever a certain threshold is exceeded.

Cybersecurity: Loki allows you to identify threats, problems, and malicious activity in your company's systems. What's more, it helps you understand an attack's details after systems have already been compromised.

Compliance: When regulations require companies to keep audit logs, Loki is a reliable and secure option to do so.

Business Intelligence: Loki helps non-technical teams understand log data and develop new strategies and ideas for business growth. For example, marketers can use the data for conversion rate optimization: they can see where customers are coming from, which marketing channels are working best, and which channels need to be improved.

The PLG Stack (Promtail, Loki and Grafana)

Promtail is an agent that needs to be installed on each node running your applications or services. It detects targets (such as local log files), attaches labels to log streams from the pods, and ships them to Loki.
Loki is the heart of the PLG Stack. It is responsible to store the log data.
Grafana is an open-source visualization platform that processes time-series data from Loki and makes the logs accessible in a web UI.

Getting Started with the PLG Stack in Kubernetes

Let's get started with Loki with some hands-on action. In this example, we're going to use the Loki stack to visualize the logs of a Kubernetes API server in Grafana.

Before you start, make sure you have a Kubernetes cluster up and running, and Helm installed. When you're all set, we can install Loki:

Install the PLG Stack with Helm

Create a Kubernetes namespace to deploy the PLG Stack to:

$ kubectl create namespace loki

Add Loki's Helm Chart repository:

$ helm repo add loki https://grafana.github.io/loki/charts

Run the following command to update the repository:

$ helm repo update

Deploy the Loki stack:

$ helm upgrade --install loki loki/loki-stack --namespace=loki --set grafana.enabled=true

This will install Loki, Grafana and Promtail into your Kubernetes cluster.

Retrieve the password to log into Grafana:

$ kubectl get secret loki-grafana --namespace=loki -o jsonpath="{.data.admin-password}"  | base64 --decode ;  echo

The generated admin password will look like this one -> jvjqUy2nhsHplVwrX8V05UgSDYEDz6pSiBZOCPHf

Finally, execute the command below to access the Grafana UI.

$ kubectl port-forward --namespace loki service/loki-grafana 3000:80

Now open your browser, and go to http://localhost:3000.

Loki in Grafana

The Grafana we installed comes with the Loki data source preconfigured. So we can start right away exploring our Kubernetes logs:

Next, click on the Explore tab on the left side. Select Loki from the data source dropdown.

Click on the Log labels dropdown > container > kube-apiserver

Now you should get data in the Logs window!

Scroll down and you will find the details on the kube-apiserver logs.

LogQL

LogQL provides the functionality to filter logs through operators. Here is a list of operators which are supported:

=: exactly equal.
!=: not equal.
=~: regex matches.
!~: regex does not match.

Let's try it on another query. We start by searching all logs of the kube-apiserver container. In addition to that we add filter operators to limit the results to logs which include the word error, but not timeout:

{container="kube-apiserver"} |= "error" != "timeout"

This was a simple example of setting up and working with Loki and Grafana. If you want to learn more, head over to the Loki documentation.

Wrapping up

Companies need a simple and cost-effective solution to collect, store, and analyze log files from apps and services in distributed systems. Loki can help you dramatically reduce logging and monitoring costs in your production environment. In combination with Promtail and Grafana it provides all the features needed for a full logging stack which can help you find and resolve problems faster and prevent malfunctions from occurring in the future.

Would you like to learn how Loki can help you gain more insides into your software system, cut costs and strengthen DevOps in your company? Use our contact form, and we will get back to you shortly.

For our latest insights and updates, follow us on LinkedIn

How To: Contract Testing for Node.js Microservices with Pact

Kentaro Wakayama — Thu, 05 Nov 2020 11:59:10 +0000

In this article, you'll learn more about contract testing and how to use Pact to verify and ensure your Node.js microservices' API compatibility.

This article was originally published at Coder Society

Ensuring API compatibility in distributed systems

The use of microservices is growing in popularity for good reasons.

They allow software teams to develop, deploy, and scale software independently to deliver business value faster.

Large software projects are broken down into smaller modules, which are easier to understand and maintain.

While the internal functionality of each microservice is getting simpler, the complexity in a microservice architecture is moved to the communication layer and often requires the integration between services.

However, in microservice architectures, you often find service to service communication, leading to increased complexity in the communication layer and the need to integrate other services.

Figure 1: Distributed systems at Amazon and Netflix

Traditional integration testing has proven to be a suitable tool to verify the compatibility of components in a distributed system. However, as the number of services increases, maintaining a fully integrated test environment can become complex, slow, and difficult to coordinate. The increased use of resources can also become a problem, for example when starting up a full system locally or during continuous integration (CI).

Contract testing aims to address these challenges -- let's find out how.

What is contract testing?

Contract testing is a technique for checking and ensuring the interoperability of software applications in isolation and enables teams to deploy their microservices independently of one another.

Contracts are used to define the interactions between API consumers and providers. The two participants must meet the requirements set out in these contracts, such as endpoint definitions and request and response structures.

Figure 2: A contract that defines a HTTP GET interaction

What is consumer-driven contract testing?

Consumer-driven contract testing allows developers to start implementing the consumer (API client) even though the provider (API) isn't yet available. For this, the consumer writes the contract for the API provider using test doubles (also known as API mocks or stubs). Thanks to these test doubles, teams can decouple the implementation and testing of consumer and provider applications so that they're not dependent on each other. Once the provider has verified its structure against the contract requirements, new consumer versions can be deployed with confidence knowing that the systems are compatible.

Figure 3: Consumer-driven contract testing

What is Pact?

Pact is a code-first consumer-driven contract testing tool. Consumer contracts, also called Pacts, are defined in code and are generated after successfully running the consumer tests. The Pact files use JSON format and are used to spin up a Pact Mock Service to test and verify the compatibility of the provider API.

The tool also offers the so-called Pact Mock Provider, with which developers can implement and test the consumer using a mocked API. This, in turn, accelerates development time, as teams don't have to wait for the provider to be available.

Figure 4: Pact overview

Pact was initially designed for request/response interactions and supports both REST and GraphQL APIs, as well as many different programming languages. For Providers written in languages that don't have native Pact support, you can still use the generic Pact Provider Verification tool.

Try out Pact

Why don't we test things ourselves and see how consumer-driven contract testing with Pact actually works? For this, we use Pact JS, the Pact library for JavaScript, and Node.js. We've already created a sample repository containing an order API, which returns a list of orders. Let's start by cloning the project and installing the dependencies:

$ git clone https://github.com/coder-society/contract-testing-nodejs-pact.git

$ cd contract-testing-nodejs-pact

$ npm install

Writing a Pact consumer test

We created a file called consumer.spec.js to define the expectedinteractions between our order API client (consumer) and the order API itself (provider). We expect the following interactions:

HTTP GET request against path /orders which returns a list of orders.
The order response matches a defined structure. For this we use Pact's Matchers.

const assert = require('assert')
const { Pact, Matchers } = require('@pact-foundation/pact')
const { fetchOrders } = require('./consumer')
const { eachLike } = Matchers

describe('Pact with Order API', () => {
  const provider = new Pact({
    port: 8080,
    consumer: 'OrderClient',
    provider: 'OrderApi',
  })

  before(() => provider.setup())

  after(() => provider.finalize())

  describe('when a call to the API is made', () => {
    before(async () => {
      return provider.addInteraction({
        state: 'there are orders',
        uponReceiving: 'a request for orders',
        withRequest: {
          path: '/orders',
          method: 'GET',
        },
        willRespondWith: {
          body: eachLike({
            id: 1,
            items: eachLike({
              name: 'burger',
              quantity: 2,
              value: 100,
            }),
          }),
          status: 200,
        },
      })
    })

    it('will receive the list of current orders', async () => {
      const result = await fetchOrders()
      assert.ok(result.length)
    })
  })
})

Run the Pact consumer tests using the following command:

$ npm run test:consumer

> contract-testing-nodejs-pact@1.0.0 test:consumer /Users/kentarowakayama/CODE/contract-testing-nodejs-pact
> mocha consumer.spec.js

[2020-11-03T17:22:44.144Z]  INFO: pact-node@10.11.0/7575 on coder.local:
    Creating Pact Server with options:
    {"consumer":"OrderClient","cors":false,"dir":"/Users/kentarowakayama/CODE/contract-testing-nodejs-pact/pacts","host":"127.0.0.1","log":"/Users/kentarowakayama/CODE/contract-testing-nodejs-pact/logs/pact.log","pactFileWriteMode":"overwrite","port":8080,"provider":"OrderApi","spec":2,"ssl":false}

  Pact with Order API
[2020-11-03T17:22:45.204Z]  INFO: pact@9.13.0/7575 on coder.local:
    Setting up Pact with Consumer "OrderClient" and Provider "OrderApi"
        using mock service on Port: "8080"
    when a call to the API is made
[{"id":1,"items":[{"name":"burger","quantity":2,"value":100}]}]
      ✓ will receive the list of current orders
[2020-11-03T17:22:45.231Z]  INFO: pact@9.13.0/7575 on coder.local: Pact File Written
[2020-11-03T17:22:45.231Z]  INFO: pact-node@10.11.0/7575 on coder.local: Removing Pact process with PID: 7576
[2020-11-03T17:22:45.234Z]  INFO: pact-node@10.11.0/7575 on coder.local:
    Deleting Pact Server with options:
    {"consumer":"OrderClient","cors":false,"dir":"/Users/kentarowakayama/CODE/contract-testing-nodejs-pact/pacts","host":"127.0.0.1","log":"/Users/kentarowakayama/CODE/contract-testing-nodejs-pact/logs/pact.log","pactFileWriteMode":"overwrite","port":8080,"provider":"OrderApi","spec":2,"ssl":false}

  1 passing (1s)

The consumer tests generate a Pact contract file named "orderclient-orderapi.json" in the "pacts" folder, which looks like this:

{
  "consumer": {
    "name": "OrderClient"
  },
  "provider": {
    "name": "OrderApi"
  },
  "interactions": [
    {
      "description": "a request for orders",
      "providerState": "there are orders",
      "request": {
        "method": "GET",
        "path": "/orders"
      },
      "response": {
        "status": 200,
        "headers": {
        },
        "body": [
          {
            "id": 1,
            "items": [
              {
                "name": "burger",
                "quantity": 2,
                "value": 100
              }
            ]
          }
        ],
        "matchingRules": {
          "$.body": {
            "min": 1
          },
          "$.body[*].*": {
            "match": "type"
          },
          "$.body[*].items": {
            "min": 1
          },
          "$.body[*].items[*].*": {
            "match": "type"
          }
        }
      }
    }
  ],
  "metadata": {
    "pactSpecification": {
      "version": "2.0.0"
    }
  }
}

Verifying the consumer pact against the API provider

We can now use the generated Pact contract file to verify our order API. To do so, run the following command:

$ npm run test:provider

> contract-testing-nodejs-pact@1.0.0 test:provider /Users/kentarowakayama/CODE/contract-testing-nodejs-pact
> node verify-provider.js

Server is running on http://localhost:8080
[2020-11-03T17:21:15.038Z]  INFO: pact@9.13.0/7077 on coder.local: Verifying provider
[2020-11-03T17:21:15.050Z]  INFO: pact-node@10.11.0/7077 on coder.local: Verifying Pacts.
[2020-11-03T17:21:15.054Z]  INFO: pact-node@10.11.0/7077 on coder.local: Verifying Pact Files
[2020-11-03T17:21:16.343Z]  WARN: pact@9.13.0/7077 on coder.local: No state handler found for "there are orders", ignoring
[2020-11-03T17:21:16.423Z]  INFO: pact-node@10.11.0/7077 on coder.local: Pact Verification succeeded.

The code to verify the provider can be found in verify-pact.js and looks like this:

const path = require('path')
const { Verifier } = require('@pact-foundation/pact')
const { startServer } = require('./provider')

startServer(8080, async (server) => {
  console.log('Server is running on http://localhost:8080')

  try {
    await new Verifier({
      providerBaseUrl: 'http://localhost:8080',
      pactUrls: [path.resolve(__dirname, './pacts/orderclient-orderapi.json')],
    }).verifyProvider()
  } catch (error) {
    console.error('Error: ' + error.message)
    process.exit(1)
  }

  server.close()
})

This starts the API server and runs the Pact Verifier. After successful verification, we know that the order API and the client are compatible and can be deployed with confidence.

Wrapping up

By now you should have a good understanding of contract testing and how consumer-driven contract testing works. You also learned about Pact and how to use it to ensure the compatibility of your Node.js microservices.

To avoid exchanging the Pact JSON files manually, you can use Pact Broker to share contracts and verification results. This way, Pact can be integrated into your CI/CD pipeline -- we will talk more about this in a future blog post.

Visit the Pact documentation to learn more about Pact and consumer-driven contract testing for your microservices.

For more articles like this, visit our Coder Society Blog.

For our latest insights and updates, you can follow us on LinkedIn.

13 Tools To Become Cloud Native

Kentaro Wakayama — Fri, 30 Oct 2020 09:50:38 +0000

The complete version of this article is available at Coder Society Blog

This is my list of cloud native tools. Companies that leverage the full suite of tools can often deliver faster, with less friction and lower development and maintenance costs.

Are we missing anything? Let me know!

1. Microservices

Microservices scope product functionality into units that can be individually deployed. For example, in traditional pre-cloud-native deployments, it was common to have a single website service that managed APIs and customer interactions. With microservices, you would decompose this website into multiple services, such as a checkout service and a user service. Then, you could develop, deploy, and scale these services individually.\
Additionally, microservices are often stateless, and leveraging twelve-factor applications allows companies to take advantage of the flexibility that cloud native tooling offers.

Recommended Technology: Node.js\
Alternative Technology: Kotlin, Golang

2. Continuous Integration / Continuous Deployment

Continuous Integration / Continuous Deployment (CI/CD) is an infrastructure component that supports automatic test execution (and optionally deployments) in response to version control events such as pull requests and merges. CI/CD enables companies to implement quality gates such as unit tests, static analysis, or security analysis. Ultimately, CI/CD is a foundational tool in the cloud native ecosystem that can lead to substantial engineering efficiencies and reduced error counts.

Recommended Technology: Gitlab CI/CD\
Alternative Technology: Github Actions

3. Containers

Containers are at the heart of cloud native ecosystems and enable unmatched velocity and quality gains by simplifying developer operations. Using containers with tools like Docker, teams can specify their system dependencies while providing a uniform and generic execution layer. This layer enables infrastructure teams to operate a single infrastructure, such as a container orchestrator, like Kubernetes. Engineering teams can store container images in a container registry, which in most cases, also provides vulnerability analysis and fine-grained access control. Popular services for this are as Docker Hub, Google Container Registry, or Quay.

Recommended Technology: Docker\
Alternative Technology: Podman, LXD

4. Container Orchestration

Container orchestrators are tools for launching and managing large numbers of containers and remove the need for language-specific or team-specific deployment strategies. They allow users to specify a container image or group of images and some configuration. Finally, the orchestrators take these specifications and translate them into running workloads.\
Container orchestrators enable infrastructure teams to maintain a single infrastructure component, which can execute any container that adheres to the OCI specification.

Recommended Technology: Kubernetes\
Alternative Technology: Google Cloud Run

5. Infrastructure as Code

Infrastructure as code is a strategy that puts cloud configuration under version control. Companies often manage their cloud resources manually by configuring them through an admin panel. Manual configuration, however, makes it hard to keep track of changes. Infrastructure as code addresses this by defining cloud resources as code and putting them under version control. Changes are made in the infrastructure config in code and promoted through the company's deployment process, which can include peer reviews, CI, and CD. Version control provides an audit log that shows who has changed which resources and when.

Recommended Technology: Terraform\
Alternative Technology: Pulumi

6. Secrets

Secret management is essential for cloud native solutions but is often neglected at smaller scales. Secrets are anything private, such as passwords, private keys, and API credentials. At the very least, secrets should be encrypted and stored in configuration. Mature solutions enable temporary database credentials or rotating credentials to be issued, making secret management even more secure. Finding a fitting solution for secret management is vital for cloud native applications since containerized services scale horizontally and may be scheduled on many different machines. Ultimately, organizations that ignore secret management could increase the surface area for credential leakage.

Recommended Technology: Vault\
Alternative Technology: Sealed Secrets

7. Certificates

Secure communication over TLS is not only best practice but a must-have. This is especially important in container-based solutions because many different services may run on the same physical machine. Without encryption, an attacker who gains access to the host's network could read all traffic between these services. At the very least, it becomes untenable to manually update certificates for cloud native deployments, which is why some sort of automated solution is essential.

Recommended Technology: cert-manager\
Alternative Technology: Google managed certificates

8. API Gateway

API gateways are reverse proxies with features beyond traditional reverse proxies, such as Apache and NGINX.\
API gateways support:

Protocols like gRPC, HTTP/2, and Websockets
Dynamic configuration
Mutual TLS
Routing
Resiliency primitives, such as rate limiting and circuit breaking
Visibility in the form of metrics

Recommended Technology: Ambassador\
Alternative Technology: Kong

9. Logging

Logging is a foundational pillar of observability. Logging is often very familiar and accessible to teams, making it a great starting place to introduce observability. Logs are essential to understanding what is happening in systems. Cloud native tools emphasize time series for metrics, since they are more cost-effective than logs to store. However, logs are an invaluable tool for debugging, and some systems are only observable through them, which makes logging a requirement.

Recommended Technology: EFK\
Alternative Technology: Loki

10. Monitoring

Monitoring systems store important events as a time series. Monitoring data is aggregated, which means that you don't store all events. This makes it cost-effective for cloud native systems, and is essential for understanding the state of cloud native systems and answering these questions:

How many operations are occurring?
What is the result of the operations (success, failure, or status codes)?
How long do operations take?
What are the counts of important resources such as queue depths or thread pools?

You can assign different dimensions to monitoring metrics to drill into performance on an individual machine, operating system, version, etc.

Recommended Technology: Prometheus/Grafana\
Alternative Technology: Datadog

11. Alerting

Alerting makes logs and metrics actionable, notifies operators of system issues, and pairs well with time series metrics. For example, alerts can notify teams when there is an increase in HTTP 500 status codes or when request duration increases. Alerting is essential for cloud native systems. Without alerts, you don't get notified of incidents, which in the worst case means that companies don't know that there have been problems.

Recommended Technology: Prometheus Alertmanager\
Alternative Technology: Grafana Alerts

12. Tracing

Cloud native technologies reduce the overhead in launching and scaling services. As a result, teams often launch more services than they did pre-cloud. Tracing enables teams to monitor communication between services and makes it easy to visualize an entire end-user transaction and each stage in that transaction. When performance issues arise, teams can see what service errors are occurring and how long each phase of the transaction is taking. Tracing is a next level observation and debugging tool that can significantly reduce downtime by allowing teams to debug issues faster.

Recommended Technology: Jaeger\
Alternative Technology: Zipkin

13. Service Mesh

Service meshes are the Swiss army knife of cloud networking. They can provide dynamic routing, load balancing, service discovery, networking policies, and resiliency primitives such as circuit breakers, retries, and deadlines. Service meshes are an evolution in load balancing for cloud native architectures.

Recommended Technology: Istio\
Alternative Technology: Consul

Stay Competitive With Cloud Native

Cloud native tools help companies stay competitive by increasing both quality and availability while decreasing time to market.

Companies that choose the right tools can maintain competitive advantages through increased delivery speed and agility.

Adopting cloud native technologies may seem daunting, but just remember that beginning with a single technology can already provide considerable benefits.

About me, Kentaro Wakayama

Kentaro is CEO and Solutions Architect at Coder Society. With his in-depth knowledge of software development and cloud technologies, Kentaro often takes on the lead engineer's role. His analytical, organized, and people-oriented nature makes him an apt advisor on software projects and flexible staffing.

About Coder Society

We are a network of 150+ tech freelancers developing custom software solutions for leading companies on-site and remotely.

If you need help getting started with your cloud native journey, check out what we can do.