In this blog post, we return to the PERN application we previously migrated to Kubernetes and replace the PostgreSQL database with MongoDB. Although it might seem like a difficult task initially, the straightforward design of Pulumi and Kubernetes allows us to easily transition the application form a PERN stack to a MERN one.
In this blog post, we will explore and demonstrate the advantages of Kubernetes by converting and deploying our PERN application to Amazon EKS. With the help of Pulumi, the process becomes greatly simplified and allows us to focus more on the big picture of designing our cloud architecture.
This guest blog was contributed by Andrew Kunzel and Michael Goode. Andrew is the Director of Backend Engineering and Michael is a Platform Operations Engineer at Pinpoint.
At Pinpoint, Kubernetes is the most powerful tool in our arsenal. It allows us to deploy and rapidly scale our applications with speed and efficiency that continues to delight our customers. In recent years, managed services like AWS EKS have made it easier than ever to leverage the power of Kubernetes in even the smallest of organizations. Yet even with these new conveniences, managing all of this infrastructure can be a daunting task. Right out of the gate, we knew that we wanted to avoid the burden of maintaining repositories full of home-brewed deployment scripts and domain-specific languages like YAML.
Kubernetes developers and operators work together to manage workloads and to continuously ship software through CI/CD. These users have an affinity for automation and pipelines, and richer integration with Kubernetes is a growing theme across the cloud native ecosystem.
We’re excited to introduce the Pulumi Kubernetes Operator: a Kubernetes controller that deploys cloud infrastructure in Pulumi Stacks for you and your team.
These program stacks include virtual machines, block storage, managed Kubernetes clusters, API resources, serverless functions and more!
Kubernetes users often joke about being “YAML engineers,” and the pile of YAML seems to get deeper every day. Today, we’re pleased to announce kube2pulumi, a tool to automatically convert Kubernetes manifests into modern code! Instead of manipulating YAML directly, you can take advantage of the rich ecosystem of programming language tools to supercharge your productivity.
CustomResources in Kubernetes allow users to extend the API with their types. These types are defined using CustomResourceDefinitions (CRDs), which include an OpenAPI schema. This extensibility is quite useful but comes at the cost of complex YAML definitions. Our new crd2pulumi tool takes the pain out of managing CustomResources by generating types in the Pulumi-supported language of your choice!
Today, we’re excited to announce several new open source projects that advance Pulumi’s Kubernetes support. These projects and features have been developed while helping leading cloud native engineering teams like Snowflake, Lemonade, and Mercedes-Benz go into production with Kubernetes, and include new deployment automation options, improved ecosystem integrations, and tools to make it easier than ever to adopt Pulumi for new and existing projects.
Your application made it out of the dev stage, passed the testing stage, and arrived in production. As a developer, you might think that it’s an ops problem now. However, DevOps is a collaborative effort between developers and operators to build and maintain applications using shared techniques and processes, often called “Day 2” activities.
In previous installments, we examined how to deploy applications. However, we only touched on how applications talk to each other inside and outside the cluster. Whether you are building a modern application or modernizing a legacy application, understanding how resources and components talk to each other is essential. In this installment, we’ll examine networking in Kubernetes.
This article is the fourth in a series using infrastructure as code to deploy applications with Kubernetes. This series walks you through:
- Building a Kubernetes cluster on cloud providers
- Basic application deployment
- Advance application deployment and Helm charts
- Stateful applications
- “Day 2” activities such as migrating node groups.
In the previous post, we examined different methods for deploying applications. We worked through examples of a boilerplate deployment, to one using
ComponentResources to automate deployment further, and deploying with Helm charts. In this installment, we’ll look at how to deploy stateful applications, such as databases, in Kubernetes. Unlike stateless applications, stateful apps require persistent storage, which presents scaling and availability challenges.