How Things Hang Together
Orchestrating software platforms can be complex, there are a lot of terms. But we're confident we can get started quickly. Let's break them down step by step so they make sense.
It’s important to have a shared taxonomy, that way everyone is on the same page. Get as far as you can, we’ll get into the weeds at the end. First let’s cover off the Infrastructure level concerns.
Infrastructure
We use Organizations to implement high level Governance controls that often include Security; and centralize Billing. We will often have multiple Accounts under one Organization when engaging cloud vendors. At the Account level is where we have most of our Identity and Access Management, Security, and Fault Tolerant service controls. Google Cloud has the added benefit of Projects, which help us break those concerns down further within an Account, which is really nice.
We define everything inside an Account using scripts that can be life cycled and repeated to reduce effort, and error. To do this we use Infrastructure As Code tools, namely Terraform.
Environments
Once we’ve got our Account set up, we add Environments. Everyone’s has heard of an Environment, like Production, Live, UAT, or DIT. Environments define a lot of Configuration, Networking and Security controls. We’re comfortable running multiple Environments in an Account as long as it doesn’t break any Security or Governance boundaries. For example Delivery, Test, and User Acceptance in a single account called Test; Canary and Live in an Account called Production.
Running software
Here’s where Software meets an Environment. Almost everything Practiv does now runs in an Orchestration platform called Kubernetes. We deploy a set of Servers that automatically spin up to make up a Cluster. The Servers can be deployed across different data centers more than 30km away from each other called Availability Zones for High Availability. And they’re Auto Scaling so if one dies, another one will quickly spin up and join the Cluster.
Kubernetes helps us Orchestrate our running Software on that Cluster. On each cluster we can run a number of Namespaces. Namespaces are another boundary for Routing, Networking, Access Control, Security, and Configuration.
You’ll often think of your Software as a “Platform”. But your Organization might have one more Platforms. Because Practiv has to consider slightly larger collections of Software running for large customers, we call each one a Software Product. Usually you’ll have a Product or Service Owner in charge of each collection of Software, so we think it makes sense.
We deploy a Software Product into a Namespace on a Cluster. We can deploy the exact same version of a Product to different Namespaces with different Configuration and Security. The Software we’re working on goes into the Development Namespace; the version we’re working on with you, your brand and legal teams, to the User Acceptance Namespace; and the version your customers are using to the Live Namespace.
What’s great about that is the Software we’ve tested, that you’ve tested, is the same software we deliver to your customers, just with slightly different Configuration. That really helps reduce issues when Deploying Software, and gives us the confidence to do it often. Which again makes sense, but for various reasons isn’t common.
That was a lot, so basically what we’re saying is that’s how we Deploy your Software to Run in an Environment, gives us confidence and control.
Software Applications
We life cycle Software Products independently. So they have their own Build Pipelines. Each Software Product will have many Applications. An insurance Product for example, might have house, contents, and vehicle Applications.
The insurance Software Product might not align perfectly with your Business Products, but that’s okay we have some thoughts on that later too.
We deploy Applications in Containers that come with a number of benefits for Applications. Namely that they are light weight way to gain portability by Standardizing Deployment, Configuration and Security.
Unfortunately Orchestrating them becomes complex, which is why we need all the technology above that can send you a little cross-eyed.
So we have a Software Product made up of Applications. An Application will have Services. Your Vehicle Registration Service, and your Pricing Service might be part of the same Application, or they might be separate. This might be because they’re wildly different, or just because one needs more resources when your customers start visiting your Product. That’s up to the team to decide.
From Build to Run
Within Applications, we have our Services, our Configuration and Secrets Orchestrated by Kubernetes. Everything below this level is very standard. Developers know this well.
Practiv Build leans heavily on Maven, Maven Tiles, and Maven Tile Sets to standardize the composition of software Applications.
Practiv Run manages the definition of Applications and how they should Run in Namespaces using Gitops, too. Everything you need to define a Namespace, the Applications and their versions is defined in a POM file. Configuration and Secrets are encrypted in and stored in a similar way.
Developers have full control of deployment through environments (as long as governance steps such as approved PRs, are met).