In this article, we’re going to look at how Platform9 can help your microservices get to production faster. With the help of the Spring Pet Clinic app, we’ll highlight the features you care about.
As you take your microservices to production, you’re going to face a treacherous road of big decisions. What needs to be in an external store versus provided as a config value? What constitutes a domain boundary? How will the design best serve the business’s goals? Tough questions to answer.
Microservice architectures comes with challenges but the benefits out weight the complexity. Better scalability, resilience, reliable portability are a few of things that drive me. I am willing to wade through those complexities with the end result in mind. Where I don’t want to spend my time is managing infrastructure or platforms. My container definition gets me as close to the operating system as I want to go. Whatever scheduler is making sure my container is running is of no concern to me. These microservices are a full-time job, make it work I don’t care how.
nother challenge to publishing code is navigating the different environments. It’s a combination of local development, staging, and maybe QA. Ideally each environment’s configuration are kept in parity so the artifact follows a straightforward continuous promotion cycle. But let’s be honest, the reality is anything but that. Moving between different networks, deciding on storage options, and managing limited resources make the goal of parity seem like a far-off dream. Not to mention a local environment where you may or may not be able to run containers. You can see the reason for my skepticism.
I’m cynical about infrastructure. So how am I going to get away with stable promotions between local, staging, and production? How can I at least strive for environment parity? My counterpart (the platform operator) shares a similar feeling about pushing applications. Clearly we are going to need a middle ground to get anything done.
Thanks to Platform9 this is a simple challenge to overcome. Their managed Kubernetes service (PMK) gives the platform operator simple ways to manage clusters. All they do is tell Platform9 how they would like things configured and leave the rest to PMK. The Operator can create the same clusters in a mix of local virtual machines, bare-metal servers, and cloud accounts. Platform9 will make sure each cluster is on the same version, has the same monitoring, and shares the same security policies.
Ha-za! There will be peace across IT and App Development thanks to Platform9. Let’s see all of this in practice, just in case there are skeptics out there ;).
Creating K8s clusters with Platform9
We need a cluster. In a hurry. Challenge is there are a lot of different ways to get this done. Locally we could use tools like minikube or K3s or Kind. We could have physical or virtual machines running Linux. We could use a public cloud like Azure and their AKS service. Or we could create virtual machine instances and spin everything up manually. Their brochures say every one of these can run the same K8s version, but none of them are created equal.
Platform9 takes the opinion that you should not be worrying about these things. The console makes managing nodes and creating clusters a simple
For my local development environment, I am limited in computing resources. Combining the K8s master processes with my workloads is a must to save on memory and CPU needs. Staging will be in AWS so we have more compute but we’ve got to watch the costs – it can get costly very quickly. The staging cluster will be EC2 based, with a single master and 2 nodes for running workloads. Production is where we want to spend our money. It’s also the only public-facing thing, so security is a high priority. We’ll use EKS to create the cluster and let Amazon manage OS patching. The Operator can import the EKS cluster in to the Platform9 account. Then the EC2 instances will be prepped for management and workloads.
Platform9’s console gives us plenty of options to achieve parity in a secure way. The Operator could use their web console if buttons are a preference. Or, if automation and software-defined things are the focus Platform9 offers the Qbert API.
About Spring Pet Clinic and its versions
A microservice doesn’t run by itself. It has other microservices around it and backing services like a data store. There are also other services collecting metrics and logs for that microservice.
A good application that illustrates this is Spring Pet Clinic. If you’ve never met Pet Clinic it’s an app used within the Spring community to showcase its power. There are lots of different versions. Most of them centered around showcasing spring components. There is a microservices version which combines services, discovery, external configuration, administration, and metrics aggregation. You can run it locally with docker or you can push it to a platform. The cloud version extends the microservices version to make it Kubernetes ready. It also makes the most of running in clusters by using the builtin DNS and discovery options.
The Platform9 community has extended the cloud version for PMK managed clusters. Making it even more Kubernetes friendly with Grafana, Prometheus, FluentBit, and Elasticsearch. Then we wrapped it all up in a Helm chart for a very simple get started.
Deploying Spring Pet Clinic With Platform9
We can use Platform9 to create each environment needed to develop and run the application. Locally we’re going to use Platform9’s built-in App Catalog. If you’re not familiar, App Catalog is a collection of helm repositories. Each chart in the repository can be customized and deployed to a cluster namespace. A repository can be public or private and you add as many as you like.
In free tier, each item in app catalog is associated with all your clusters. As a Platform9 enterprise customer you can choose which catalog item is associated with a cluster. For lots of example helm repositories search Artifact Hub. It’s a great place to find all kinds of deployable services.
Within the Platform9 console, add the public Platform9-Community helm repository and you will then have the spring-petclinic-cloud chart ready for deployment.
For staging, we’ll build and deploy with a pipeline. Similar to our local environment we’ll use Helm, except both the cluster creation and Pet Clinic deployment will be automated with the Qbert and Helm CLIs respectively. Production will follow Staging’s model almost exactly (we are trying to keep parity).The main difference being the cluster will now have tighter security policies where only admins and pipeline service accounts have access.
The result is a complete strategy based in Kubernetes but without all that messy management. From the Operator’s point of view they can focus on their job – keeping the infrastructure secure and available. Developers have the comfort of a local development environment with the structure of production. It creates a sustainable contract where both roles can focus on what they love doing, and not add all the toil that tends to come with it.
Get started with Platform9
Getting started with Platform9 is free and easy. Create an account, hook up your cloud account or infrastructure, and deploy a cluster. They take care of the cluster creation and provide both a (24 hour) temp or passworded KubeConfig. With all that, there’s nothing to stop your applications from getting to production!
To get started choose your infrastructure provider and get a cluster going in just a few clicks:
Be a part of the Platform9 community
If you have questions or would like to connect with other community members, you have a few options.
- Join the community in our open form: https://community.platform9.com
- Discuss ideas and provide feedback directly with the Platform9 team in slack: https://pmkft.slack.com
- See what others are creating for Platform9 in the community GitHub at https://github.com/platform9-community.