Is Microservices Architecture Cheap or expensive?

In the ever-evolving landscape of software architecture, the debate surrounding microservices and monolithic architecture has raged on for years. Back in 2015, I remember discussing with a software architect about Kubernetes. He was understandably very interested in migrating applications to a microservices based architecture and adopting Kubernetes. One of his most important selling points was the costs. However, as time has shown, the reality of microservices architecture isn’t always as cost-effective as it might seem at first glance.

Microservices architecture has been touted for its ability to enhance flexibility and increase productivity and efficiency. Yet, the hidden costs associated with this approach have become apparent over time. Let’s dissect some of the key financial aspects.

Data Transfer Costs: In a microservices environment, communication between different services is frequent and essential. However, this constant communication leads to data transfer costs, which can significantly impact your budget. While techniques like Topology Aware Hints (TAH) can help mitigate these costs to some extent, they remain a noteworthy expenditure.

Operational Overhead: Microservices require the use of sidecars, service meshes, and a host of tools for operational and management purposes. These components are often more complex and resource-intensive than their counterparts used in monolithic applications, contributing to increased operational costs.

So, Does it mean microservices architecture is more expensive? or as David Heinemeier Hansson (Creator of Ruby on Rails) says microservices don’t make sense?

Well, in my opinion it depends (I know the cliche!). If we compare microservices architecture to a well-designed monolithic architecture, its direct costs are in general higher; However, the benefits of microservices, such as flexibility and increased productivity, often lead to lower indirect costs associated with management and operations.

Consider the Example of AWS Prime Video: By transitioning away from microservices to a monolithic architecture, AWS reportedly achieved a 90% cost reduction. This demonstrates that simplicity can be a compelling factor in favor of monolithic architecture in certain scenarios.

Nevertheless, it’s important to note that many applications thrive in Kubernetes or other orchestrators, with stakeholders satisfied with their choice. The CNCF (Cloud Native Computing Foundation) community acknowledges the cost challenges and actively works on mitigating them through initiatives like TAH (Topology Aware Hints) and Karpenter.

In conclusion, the debate over whether microservices architecture is more expensive than monolithic architecture isn’t easily settled. Both approaches have their merits and drawbacks, and the cost-effectiveness of each depends on the specific use case and how well they are implemented.

As technology evolves, we can expect ongoing discussions about the financial aspects of software architecture. With initiatives like TAH and Karpenter, the CNCF community is actively addressing the cost challenges associated with microservices. Therefore, the future promises further exploration and innovation in the quest for cost-effective software solutions. Stay tuned for more developments in the years to come.

Use vault-cli in a pipeline

The other day I wanted to apply some configurations of Hashicorp Vault in a pipeline to automate some operations but Vault was a private deployment in a Kubernetes cluster. I was a bit lazy (not recommended) and also curious about this new (not anymore) trend which is ChatGPT! 🙂 So, here is my conversation and it worked. It’s not complicated but was helpful.

“I want to access an internal kubernetes service endpoint in a script. In specific, we have hashicorp vault inside kubernetes. I want to have a script that port forward to this service and then I use my local endpoint to run a couple of commands using ‘vault cli’ in the same script. can you please give me an example script?”

and the answer:

Certainly! Here’s an example script that demonstrates how you can port forward to a Kubernetes service endpoint and use the HashiCorp Vault CLI to run commands:

#!/bin/bash

# Port forward to the Vault UI service
kubectl port-forward -n hashicorp service/vault-ui 8200:8200 &
sleep 5 # Wait for port forwarding to be established

# Set the Vault endpoint to the local forwarded address
export VAULT_ADDR="http://127.0.0.1:8200"

# Authenticate to Vault (assuming token-based authentication)
export VAULT_TOKEN="your_vault_token"

# Run Vault CLI commands
vault status
vault secrets list

# Stop the port forwarding
kill %1

Using Flux in Microk8s

This post is a rather short one like a real tweet but I hope it help people who might be in the same situation as me and can’t find much information online.

This time we are talking about Microk8s and Flux. Microk8s is a great implementation of Kubernetes especially useful for edge and IoT which is approved project in CNCF. Flux is an implementation for GitOps by Weaveworks which is also a candidate project of CNCF. It’s also a nice tool which brings kubernetes configuration management into another level.

They work well together but there is a small tweak required in one of the steps. When you want to authorize your flux to access your github repository (SSH based) you need public key to be introduced as Deploy Key in Github. The command which works for microk8s is the following:

microk8s.kubectl -n flux --kubeconfig /var/snap/microk8s/current/credentials/client.config logs deployment/flux | grep identity.pub | cut -d '"' -f2

That’s it and you will get the required public key.