Cloud Native Patterns: Local development

[Jorge Ruiz-Aquino]

Are there CN Patterns to bring cloud native development to the developer's local-environment?
In other words, how to reproduce the cloud environment for local development? At how extend is this achievable?

[Cornelia Davis]

Another great question Jorge! You are pointing out that it's quite important to be able to have a cloud-native environment in even the most local settings. By cloud native environment, I mean one that allows the developer to test out things like whether their multiple instances of an app actually act as a single logical unit, whether you are using the service discovery protocol correctly, and so on. If you were just running a single instance of some web service you created and testing via unit tests, for example, you aren't going to exercise that path.

Part of the reason that I ended up using Kubernetes as the vehicle for demonstrating the patterns is precisely because it is easy to get running locally. Most of the examples do, in fact, run locally (except when I do a simulation of some cascading failures in chapters 9, 10 and 11) and I step you through using Minikube. This requires something like Virtualbox) and runs K8s in a VM. Since starting the book, another local option for Kubernetes has gained traction - Kind which stands for Kubernetes in docker. Either option will work well.

[Jorge Ruiz-Aquino]

Using Kubernetes from Docker instead of a virtual machines sounds very interesting.
I think for the purpose of bringing the cloud environment to the local machine is much better since it's possible to share the environment-configuration directly from the source code repository with all the capabilities like versioning.

Thank you.

[Tim Holloway]

Vagrant is a very useful tool for local development. You can bring up multiple VM instances with a single "vagrant up" command. And in fact, one of the ways to get a development cloud up and running in a hurry using OpenStack is via vagrant, where there are 3 VMs in the cloud all interconnected. You can also destroy them with a single command and rebuild them over and over, which is good for testing software installation and configuration procedures, since you can start clean with no leftover lint from failed experiments.

Vagrant takes pre-built VM images (of which there are many available), and launches them, configuring their virtual environments (e.g., networking) as desired. It can also do basic provisioning via Ansible or other provisioners. If one of the published images doesn't please you, you can go one step further and use Packer to build your own. Packer can not only build Vagrant images, but also images for other environments such as Amazon AWS, using the same packerfile for multiple environments.

Once Vagrant has launched your VMs, you can ssh into them and/or control them with management apps such as Kubernetes.