Prioritising developer productivity using cloud-native development and Kubernetes

Now more than ever, businesses are reliant on digital services and the ability to quickly pivot to meet changing demands. The use of cloud services is increasingly a key factor in being able to successfully pivot to meet those demands owing to the sophistication, availability and scalability of platform-native services.

Critically important to delivering change is how engineers make best use of the tooling available to ensure speed and quality through the software development lifecycle (SDLC).

As a Senior Technical Specialist, part of my role in Kainos is to ensure we position our development teams for success by putting a solid SDLC in place. This includes delivering and supporting the environments required for inner loop development and the CI/CD pipelines to move code through the SDLC. In recent years most of my work in one way or another - has revolved around Kubernetes and using this to deploy microservice environments.

In this blog, I will talk about how we can improve developer productivity by shifting development to the cloud, what this means in practicality and touch on the pros and cons you will need to consider.

Why should you evaluate moving developer environments to the cloud when you are building microservices on Kubernetes?

The practice of shifting local developer environments to the cloud harnesses the power of cloud platforms without the need to maintain complex configurations on developer workstations. No longer is it necessary for developers to tolerate convoluted local setups which require constant maintenance and enough resources to mine a fortune's worth of cryptocurrency.

Also gone is the 'it works on my machine' scenario where inconsistencies in setup however good the tooling - result in different experiences for different developers.

There are a few different options to consider when pushing inner loop development in this manner to the cloud in this case making use of Kubernetes: 

The traditional approach to 'running everything locally' you will have your Integrated Development Environments (IDE) and a local Kubernetes cluster (minikube/kind).

This can be complicated to maintain, leading to inconsistencies and difficulty in scaling beyond simple services. They are best used when teams are very small and you are developing simple stand-alone services and/or when you must keep your cloud spend low.

You should also be aware that running Kubernetes locally comes with certain trade-offs, which means it will not necessarily be possible to always model production constraints (as we should always target) e.g. ingress controllers.

Very similar to the traditional setup - you still have the inconsistency problems alongside scalability concerns depending on the size or complexity of the microservice environment your building - but it's less resource-intensive. With this hybrid setup, you push the hosting of services such as database, queues etc to your cloud provider.

Whilst this moves some resource-intensive workloads away from local workstations modelling production constraints, you still need to manage potentially large and complex Kubernetes environments running locally.

This has recently emerged as a very efficient way to increase the speed and quality of inner loop development whilst removing complex local environments and reducing the workload on your CI/CD tooling. This approach allows for direct integration with cloud-hosted Kubernetes clusters allowing developers to write code locally and deploy it seamlessly into a full cloud-hosted environment modelling production constraints.

From here, developers can then integrate with other cloud services or those within the cluster which other colleagues may be developing in a way that is consistent with how it will occur in production.

Go cloud-native

I would recommend you adopt the cloud-native development approach unless there are valid organisational reasons against it. Whether you take a hybrid or cloud-native approach is dependent on your circumstances but should be viewed as a step forward from local.

In Kainos, we tend to work in large, multi-disciplinary DevOps teams so the cloud-native option is always our starting point in those scenarios.

The cloud-native model removes all reliance on local environments meaning that only the developer's IDE and any associated tools are required locally. Tools such as Bridge to Kubernetes, Draft and/or Google Skaffold enable real time running of in development services without the need to commit code to source control or wait on build orchestrators to deploy a code change.

Prioritise productivity, not process

Tools provide direct streaming of logs to the development which speeds up debugging. This approach also ensures that during inner loop development, new services can interact with the remainder of the ecosystem as they will in production, be that for inter-service calls or placing a message on an external queue. All these workloads are hosted in the cloud, in a centrally managed shared environment, taking away the need for local environments and the associated complexity.

We do not want developers to be unnecessarily distracted from their primary role of building services and delivering value for end-users. Time lost maintaining local environments is wasted productivity and that is why local developer environments should be viewed as obsolete unless you have no viable alternative. Utilising cloud-native Dev tools and the processes around them is a way of ensuring productivity is always prioritised.

To find out more about our cloud services or to speak to a cloud expert click here.