Pulumi Blog: Microservices

Architecture as Code: Microservices

Sophia Parafina — Tue, 07 Apr 2020 00:00:00 +0000

This article is the third in a series about Architecture as Code. The first article provided an overview of virtual machines, microservices, serverless, and Kubernetes. The second one went in-depth on deploying virtual machines as reusable components. In this third installment, we’ll look at microservices and how to implement them as reusable components with Pulumi.

Microservices

Microservice architecture is based on the idea that each service represents an individual capability or function in an application. Services are independent of each other and can be deployed without service interruption. They communicate with each other via requests over HTTP typically through REST interfaces.

Each service is an application unto itself that must be written, configured, and deployed in coordination with other services that comprise the application. Cloud-based resources have made standing up microservices easier; however, we still need to configure each service. The advantage of using standard programming languages to deploy services is that we can further abstract resources into reusable components and apply testing methodologies to improve quality.

In the following sections, we’ll discuss how to organize an application as microservices using stacks in Pulumi and how to configure the stacks so they can talk to each other. Also, we’ll look at an example application and show how to create reusable components to build microservices.

Projects and Stacks

Pulumi is organized around Projects and Stacks. A Project specifies the runtime to use, which determines where to find the program to execute during deployment. A Stack is an independent instance of a Pulumi program used to denote different phases of development (such as development, staging, and production) or feature branches (such as new-feature-dev).

Monolithic stacks are a common way to structure a project. A single project defines the infrastructure and resources for an entire service. However, Pulumi also supports deploying microservices as individual stacks within a project. Because microservices represent a specific business capability, having stacks for each service allows teams to work independently of each other. Separate stacks can enforce security policies through Role-Based Access Control, and each service can be built and deployed independently of other components.

Microservices deployed as stacks communicate with each other through the StackReference resource, which makes stack exports such as networking, environmental variables, and even Kubernetes configuration available to stacks in the project. The StackReference constructor takes as input a string of the form <organization>/<project>/<stack>, and lets services access the outputs of that stack. The following section walks through a microservices example that deploys a database on AWS RDS, a REST application in AWS Fargate, and an AWS Application Load Balancer.

A Microservices Application Infrastructure

We’ll use the AWS Stack Reference example to illustrate how Pulumi uses Architecture as Code to create reusable components and deployment frameworks. We’ve previously blogged about this example and covered the code in some detail.

Let’s examine how it creates reusable components for building out resources. First up is the VPC class in the networking stack.

In the networking service, vpc.ts creates a TypeScript class that extends Pulumi ComponentResource. A ComponentResource abstracts one or more children that do not require custom create, read, update, and delete operations for provisioning. We can add the related resources to the correct parent to build out the class.

export class Vpc extends ComponentResource {
 vpc: aws.ec2.Vpc;
 privateZone: aws.route53.Zone;
 dhcpOptionSet: aws.ec2.VpcDhcpOptions;
 internetGateway: aws.ec2.InternetGateway;
 publicSubnets: aws.ec2.Subnet[] = [];
 privateSubnets: aws.ec2.Subnet[] = [];
 publicRouteTable: aws.ec2.RouteTable;
 privateRouteTables: aws.ec2.RouteTable[] = [];
 natGateways: aws.ec2.NatGateway[] = [];
 natElasticIpAddresses: aws.ec2.Eip[] = [];

 // ...

The resource needs an interface to set the name and parameters for our new VPC class.

export interface VpcArgs {
 description: string;
 baseTags: aws.Tags;

 baseCidr: string;
 availabilityZoneNames: string[];
 enableFlowLogs?: boolean;

 endpoints: {
 s3: boolean;
 dynamodb: boolean;
 };
}

Finally, we need to be able to peer VPCs so that the services can communicate with each other. We can take advantage of TypeScript’s member function to implement peering.

public configurePeering(args: PeerToArgs) {

 // …
}

We can reuse this pattern to build a reusable database component from RDS. Likewise, the REST application creates a service using a container deployed in Fargate and fronted by an ALB. You can replace the container with an updated application without interrupting the service.

Jumping In

We encourage you to try out deploying microservices with stacks. To download just the stack example from the examples repository we’ll use a git sparse checkout to only copy the aws-ts-stackreference-architecture directory.

$ mkdir microservices
$ cd microservices

$ git init
$ git remote add origin -f https://github.com/pulumi/examples/
$ git config core.sparseCheckout true
$ aws-ts-stackreference-architecture >> .git/info/sparse-checkout
$ git pull origin master

Follow the instructions to deploy the application. Experiment with the example by adding data to the database and adding your REST application as a container. Add a web client to submit requests and display them. Let us know if you have questions on Community Slack or send a tweet to show off your application.

To learn more about stacks, watch Mike Metral’s presentation on PulumiTV.

Architecture as Code

Sophia Parafina — Fri, 20 Mar 2020 00:00:00 +0000

Abstraction is key to building resilient systems because it encapsulates behavior and decouples code, letting each component perform its function independently. The same principles apply to infrastructure, where we want to declare behavior or state and not implementation details. As an industry, we’ve moved away from monolithic applications to distributed systems such as serverless, microservices, Kubernetes, and virtual machine deployments. In this article, we’ll take a closer look at the characteristics of these architectures and how Pulumi can abstract the components that comprise these systems.

Virtual Machines

Virtual machines arose from the need to use expensive hardware more efficiently. VMs are more efficient because they share the host server, decreasing the number of physical servers needed to run applications. A group of hosts can also be aggregated so that it behaves as a single virtual host with large memory and processing capabilities. Virtual machines can emulate other environments that have specific hardware requirements or capabilities that the host machine does not have, thus reducing the need for specific hardware or operating systems. Virtualization provides the host machine isolation from the guest virtual machines by limiting access to the host machine through an abstraction layer. Finally, virtualization has the added advantage of providing a fine degree of control over resources available to the virtual machine.

If virtual machines are part of your infrastructure, Pulumi lets you create virtual machines programmatically across cloud service providers. The JavaScript example below illustrates how to deploy a virtual machine on Google Cloud Platform. The script spins up a Debian based instance and creates a network with an open port 22 to let you configure and manage the machine as needed.

const gcp = require("@pulumi/gcp");
const fs = require("fs");

// Create a network
const network = new gcp.compute.Network("network");
const computeFirewall = new gcp.compute.Firewall("firewall", {
 network: network.id,
 allows: [{
 protocol: "tcp",
 ports: [ "22", "80" ],
 }],
});

// Read the configuration script
const startupScript = fs.readFileSync("config.sh", "utf-8")

// Create a Virtual Machine Instance.
const computeInstance = new gcp.compute.Instance("instance", {
 machineType: "f1-micro",
 zone: "us-central1-a",
 metadataStartupScript: startupScript,
 bootDisk: { initializeParams: { image: "debian-cloud/debian-9" } },
 networkInterfaces: [{
 network: network.id,
 // accessConfigs must include a single empty config to request an ephemeral IP.
 accessConfigs: [{}],
 }],
});

// Export the name and IP address of the Instance.
exports.instanceName = computeInstance.name;
exports.instanceIP = computeInstance.networkInterfaces.apply(ni => ni[0].accessConfigs[0].natIp);

This is the configuration script, config.sh, referenced in the code:

#!/bin/bash
echo "Hello, World!" > index.html
nohup python -m SimpleHTTPServer 80 &

When the virtual machine is created, it reads the configuration file that creates a webserver. This a basic example, but it shows how to configure virtual machines programmatically, which is useful for scaling horizontally.

Serverless

Serverless is a computing architecture characterized by server-side logic running in stateless containers that are invoked by events. They are typically ephemeral (often are available for only one call), and managed by third-party cloud providers. Serverless is also called Functions as a Service, or FaaS, and well-known implementations include AWS Lambda and Fargate, Azure Functions, and Google Cloud Run and Cloud Functions.

A significant benefit of serverless is that it’s a polyglot platform that allows developers to choose languages optimized for a task. For example, scripting languages like JavaScript or Python may be more responsive than a language such as Java. Serverless functions can support both synchronous and asynchronous calls. There are use cases that require an immediate response such as processing a video stream and instances where returning the result immediately is not critical as in an ETL batch job.

A key part of serverless architecture is an API Gateway that provides logical routes for mapping standard HTTP operations such as GET, PUT, POST, and DELETE to functions. The gateway makes development easier since these are standard and well-known interfaces. In addition to an API Gateway, the serverless platform should provide REST endpoints that allow you to manage the deploy with a CLI, portal, or an automation script. Finally, serverless architecture is extensible and supports integration with event sources and resources from the cloud provider through webhooks and other mechanisms.

The following example illustrates how to deploy two functions using TypeScript, one written in Python and the other written in Go. You can find the full example in the Pulumi GitHub repository.

import * as gcp from "@pulumi/gcp";
import { asset } from "@pulumi/pulumi";

const bucket = new gcp.storage.Bucket("bucket");

// Google Cloud Function in Python

const bucketObjectPython = new gcp.storage.BucketObject("python-zip", {
 bucket: bucket.name,
 source: new asset.AssetArchive({
 ".": new asset.FileArchive("./pythonfunc"),
 }),
});

const functionPython = new gcp.cloudfunctions.Function("python-func", {
 sourceArchiveBucket: bucket.name,
 runtime: "python37",
 sourceArchiveObject: bucketObjectPython.name,
 entryPoint: "handler",
 triggerHttp: true,
 availableMemoryMb: 128,
});

export const pythonEndpoint = functionPython.httpsTriggerUrl;

// Google Cloud Function in Go

const bucketObjectGo = new gcp.storage.BucketObject("go-zip", {
 bucket: bucket.name,
 source: new asset.AssetArchive({
 ".": new asset.FileArchive("./gofunc"),
 }),
});

const functionGo = new gcp.cloudfunctions.Function("go-func", {
 sourceArchiveBucket: bucket.name,
 runtime: "go111",
 sourceArchiveObject: bucketObjectGo.name,
 entryPoint: "Handler",
 triggerHttp: true,
 availableMemoryMb: 128,
});

export const goEndpoint = functionGo.httpsTriggerUrl;

Kubernetes

Kubernetes is a container orchestration system for deploying, scaling, and managing your application. Applications use multiple containers that contain code and dependencies needed for the code to execute. Kubernetes runs on a cluster of nodes and containers are deployed in pods. Kubernetes manages the pods by replacing containers that fail and removing containers that don’t respond. It can also scale the number of containers as needed and load balance the network traffic. These are some of the features that Kubernetes provides:

Load balancing and traffic distribution across the cluster
Service discovery
Create and manage containers
Remove failed containers and reassign their resources to a new container
Mount storage systems such as local storage and storage on public cloud providers
Automated deployments based on different deploy methods such as canary or blue/green deployments
Automated rollbacks to last known good state
Secrets management

The following example is based on the Kubernetes Guestbook example. The difference between this implementation and the original application is that instead of using YAML to declare the infrastructure, it uses a component written in TypeScript to create the service deployment which is implemented as k8sjs.

import * as k8s from "@pulumi/kubernetes";
import * as k8stypes from "@pulumi/kubernetes/types/input";
import * as pulumi from "@pulumi/pulumi";

/**
 * ServiceDeployment is an example abstraction that uses a class to fold together the common pattern of a
 * Kubernetes Deployment and its associated Service object.
 */
export class ServiceDeployment extends pulumi.ComponentResource {
 public readonly deployment: k8s.apps.v1.Deployment;
 public readonly service: k8s.core.v1.Service;
 public readonly ipAddress?: pulumi.Output<string>;

 constructor(name: string, args: ServiceDeploymentArgs, opts?: pulumi.ComponentResourceOptions) {
 super("k8sjs:service:ServiceDeployment", name, {}, opts);

 const labels = { app: name };
 const container: k8stypes.core.v1.Container = {
 name,
 image: args.image,
 resources: args.resources || { requests: { cpu: "100m", memory: "100Mi" } },
 env: [{ name: "GET_HOSTS_FROM", value: "dns" }],
 ports: args.ports && args.ports.map(p => ({ containerPort: p })),
 };
 this.deployment = new k8s.apps.v1.Deployment(name, {
 spec: {
 selector: { matchLabels: labels },
 replicas: args.replicas || 1,
 template: {
 metadata: { labels: labels },
 spec: { containers: [ container ] },
 },
 },
 }, { parent: this });

 this.service = new k8s.core.v1.Service(name, {
 metadata: {
 labels: this.deployment.metadata.labels,
 },
 spec: {
 ports: args.ports && args.ports.map(p => ({ port: p, targetPort: p })),
 selector: this.deployment.spec.template.metadata.labels,
 // Minikube does not implement services of type `LoadBalancer`; require the user to specify if we're
 // running on minikube, and if so, create only services of type ClusterIP.
 type: args.allocateIpAddress ? (args.isMinikube ? "ClusterIP" : "LoadBalancer") : undefined,
 },
 }, { parent: this });

 if (args.allocateIpAddress) {
 this.ipAddress = args.isMinikube ?
 this.service.spec.apply(spec => spec.clusterIP) :
 this.service.status.apply(status => status.loadBalancer.ingress[0].ip);
 }
 }
}

export interface ServiceDeploymentArgs {
 image: string;
 resources?: k8stypes.core.v1.ResourceRequirements;
 replicas?: number;
 ports?: number[];
 allocateIpAddress?: boolean;
 isMinikube?: boolean;
}

The main program deploys an instance of Redis and the guestbook application using containers pulled from the Google Container Registry.

import * as pulumi from "@pulumi/pulumi";
import * as k8sjs from "./k8sjs";

const config = new pulumi.Config();

const redisMaster = new k8sjs.ServiceDeployment("redis-master", {
 image: "k8s.gcr.io/redis:e2e",
 ports: [6379],
});

const redisReplica = new k8sjs.ServiceDeployment("redis-replica", {
 image: "gcr.io/google_samples/gb-redisslave:v1",
 ports: [6379],
});

const frontend = new k8sjs.ServiceDeployment("frontend", {
 replicas: 3,
 image: "gcr.io/google-samples/gb-frontend:v4",
 ports: [80],
 allocateIpAddress: true,
 isMinikube: config.getBoolean("isMinikube"),
});

export const frontendIp = frontend.ipAddress;

The original example defines the Service and Deployment in YAML. In the example above, the YAML is abstracted in a reusable component written in a modern programming language. The complete example is available on GitHub. As you can see, the ability to reuse components gets us closer to implementing architecture as code.

Microservices

Microservices are based on the idea that components encapsulate a business capability. Services are independently deployable and communicate via web service requests, which has the advantage of redeploying only one or selected services and leaving the remaining components up and running. The 12-Factor app is the canonical pattern for microservices, which is summarized by:

Use declarative methods to configure and deploy applications.
Enforce maximum portability between environments by establishing a clean contract with the underlying operating system.
Deploy on modern cloud platforms that diminish the need for servers and the requisite system administration.
Establish continuous deployment by keeping development, testing, and production stages similar.
Use platforms with the ability to scale without significant changes to architecture, development, or tooling.

In addition to Kubernetes, there are other platforms for deploying container-based applications. AWS Elastic Container Service, Google Cloud Run, and Azure Container Service provide alternatives to Kubernetes for container orchestration. The following code snippet demonstrates deploying a container with a Ruby application in Google Cloud Run. Note that the image is built using a local Docker engine and pushed to the Google Cloud Repository. The code shows that you can also set memory limits and concurrency for the container. The full example is available on GitHub.

import * as docker from "@pulumi/docker";
import * as gcp from "@pulumi/gcp";
import * as pulumi from "@pulumi/pulumi";

// Location to deploy Cloud Run services
const location = gcp.config.region || "us-central1";

// -------------------------------------- //
// Deploy a custom container to Cloud Run //
// -------------------------------------- //

// Build a Docker image from our sample Ruby app and put it to Google Container Registry.
// Note: Run `gcloud auth configure-docker` in your command line to configure auth to GCR.
const imageName = "ruby-app";
const myImage = new docker.Image(imageName, {
 imageName: pulumi.interpolate`gcr.io/${gcp.config.project}/${imageName}:v1.0.0`,
 build: {
 context: "./app",
 },
});

// Deploy to Cloud Run. Some extra parameters like concurrency and memory are set for illustration purpose.
const rubyService = new gcp.cloudrun.Service("ruby", {
 location,
 template: {
 spec: {
 containers: [{
 image: myImage.imageName,
 resources: {
 limits: {
 memory: "1Gi",
 },
 },
 }],
 containerConcurrency: 50,
 },
 },
});

// Open the service to public unrestricted access
const iamRuby = new gcp.cloudrun.IamMember("ruby-everyone", {
 service: rubyService.name,
 location,
 role: "roles/run.invoker",
 member: "allUsers",
});

// Export the URL
export const rubyUrl = rubyService.status.url;

Conclusion

We’ve covered the major infrastructure architectural patterns use for deploying modern applications. Whether you use Virtual Machines, Serverless, Kubernetes or Microservices with containers the goal is to create reusable components that abstract the configuration details and enable plug-and-play architecture. In subsequent articles, we’ll take an in-depth look at each pattern and how to implement them on major providers using modern languages.