Continuing with the theme from our last post, we’ll continue to learn about Kubernetes, not by worrying about the moving parts that are required to make a cluster, but instead by using a managed service provided by Google Cloud Platform (GCP) called Google Kubernetes Engine (GKE). As with the main cloud providers (Azure, AWS and
Now that we know what Kubernetes is, let’s see what options we have to create our own Kubernetes cluster.
This is the start of a blog post series that will discuss the various aspects of Kubernetes. We’ll try to guide you through the myriad of choices when choosing the type of Kubernetes installation, setting up a continuous pipeline to deploy your application to a Kubernetes cluster and how to secure said cluster.
So you’ve read part one. You see the point of building Extremely Fast Feedback Loops and you want to understand what it costs to have such a test suite. Let’s explore some problems…
When we deliver software, we need to ensure it meets the needs of end-users. The slowest feedback-loop is a “big-bang” release – this is essentially shipping all the features at once after developing for weeks, months or even years. We know this to lead to failure far more often than not… Yet, many teams release software this way, and no we don’t recommend it.
The skin of a watermelon presents a paradox or simultaneous reality of its core; both perfectly ripe and disappointingly mushy, but you won’t know which until it’s cut open. So you just leave it be; looking green and fine until it’s too late and… disintegrates.
We’ve worked with a number of organisations who make use of the Microsoft Dynamics NAV suite as their Enterprise Resource Planner (ERP). As is common with similar off the shelf tools such as SAP and FinancialForce for Salesforce, it can be hard to provide a productive and enjoyable user experience, often requiring a number of unituitive steps on several screens to perform basic tasks such as logging a sick day.
Far from technology star gazing, we explore what a modern retail technology platform could look like. Established retailers are typically encumbered by a number of legacy technology choices that are deeply embedded in their business – from a creaking SAP rollout, to proprietary Warehouse Management Systems that are resistant to integration.
When coming up with an explanation of our cloud migration heritage for my talk at Red Hat Forum the phrase “accidental cloud migrators” came to mind. You see we didn’t set out to help organisations move workloads to the cloud but nevertheless we’ve found ourselves helping organisations modernise and migrate. On reflection, I think accidental cloud migrations are the best kind of migration, let me explain why.
Your organisation has decided it’s ready to move to the cloud. Where do you start?