Modern cloud applications are highly complex, distributed systems. Teams building cloud applications have increasingly started adopting microservices as a development workflow to improve their agility and velocity. Technologies such as Kubernetes and Docker have greatly simplified implementing this workflow.
Crucial to the successful adoption of microservices is a focus on enabling your teams to work independently of each other. As we’ve written extensively, this is a developer experience and workflow problem.
We’ve written a popular set of guides on how to put this into practice with Kubernetes, Docker, Envoy, and other cloud-native technologies, and we’ve also released open source tools such as Telepresence, Forge, and Ambassador to simplify this process.
Implementing a Kubernetes development workflow
Still, one of the common refrains we here from people are — what are the best practices for a development workflow on Kubernetes? We don’t have all the answers, but we have been working with real-world companies and users for a few years now, and we definitely have some opinions.
So today, we’re releasing v0.1 of the open source Blackbird Reference Architecture. The reference architecture consists of three different microservices, written in Java/Spring, Python/Flask, and NodeJS, along with an opinionated workflow and tools to illustrate how you can develop each of these services. The reference architecture illustrates:
- how to deploy to different Kubernetes environments, using Forge profiles
- a canary deployment workflow, using the Ambassador API gateway
- how to do local development, using Telepresence
- containerized development, using Docker containers
- creating isolated development environments, using Forge
We expect the reference architecture to be an ongoing project that incorporates our learnings (and community feedback). Some of the areas that we expect to address in subsequent releases include integrating Prometheus monitoring, more sophisticated microservices that have dependencies, and advanced strategies for creating development isolation.
The reference architecture is 100% open source, and we’d love for you to try it out and give us some thoughts. Our hope is that others who have different best practices and perspectives will share with us their thoughts so we can continue to improve the reference architecture.