My Date with Minikube

This republic long vacation has enabled to play with certain deployment with Minikube. To start with I tried to upgrade my minikube version with 0.25 but that did not work. Then when I have raised issues with the minikube and as of now I need to be contended with V0.24.1. Then I wanted to host a .NET core app. After performing the necessary containerization with Docker, I had put it in my docker hub. Then the funs starts.

When we try to kubectl deployment and services, they get created but not the public routes are not getting created. So who all the saga started. I went through many articles. One asked me to deploy the ngnix ingress controller with all certificate generation etc:- . So after burning two days I found that through this works it was unstable. In fact when I gave

Minikube addons enable Ingress

it was leaving with an unstable cluster.
So back to square 1, clear everything and reinstall the cluster. Now after doing some research I landed up This is a booty. I was suppose to write simple docker-compose.yaml file and simply use the tool. So what did my docker-compose.yaml looked like

version: ‘3’
    image: venkateshsrini3/readfromcache:20180127041655
      context: .
      – 80:80
      kompose.service.type: LoadBalancer

Then also it did not work properly . The service did not get exposed. Then banging the head for a couple of hours lead me to the discovery that I had to give the last labels tag which needs to be compose.service.type: LoadBalancer.

So How did I deploy. Simple

Kompose UP from the directory in which I had the docker-compose.yaml

Once the app is redeployed, then we just have to say minikube service <>, phew the app started working.
So all the complexities are taken by compose. Now when we are working with a real time Kubernetes in AKS or GKE then we need to add an extra step of expose the service on type load balancer.

Happy week beginning.


Clear the cloud – Part 1


The idea of this blog is to demystify the word ‘cloud’. We will then go ahead and try to add more clarity. We will first scratch surface of the cloud and then we will go deep to see some of the technologies like Docker, Kubernetes, Cloud foundry (Pivotal), Azure PaaS. The idea is to give a strong fundamental knowledge and then dwell deeper into offering in the perspective of application migration.

Categorization of cloud based on offering

Based on what the cloud provider provides the cloud is classified as

IaaS – Infrastructure as service. In this offering the cloud provider provides the capability to create a VM, configure memory, processor requirement, disk space requirement and network requirements (whether it can be accessed only within the enterprise or outside to the open). There is also a possibility to choose from bouquet of operating services. Then like we are connecting to on-premise server we can login to the server and do the usual process. This offering just outsources the data center related concerns like physical security, power and other physical factors. The enterprise DevOps team works with some enhanced software and create VM and deploy them. Also, they may have to interact with cloud provider for hardware related issues.

PaaS – Platform of Services. In this offering the cloud provider all the related dependent software for running the software. They would also a set of service bouquet like emailing, push notification, analytics, reporting and more deeper facilities like in-app analytics for an immersive experience. It is like outsourcing most of the Non- function requirements and concentrate core business.

SaaS- Software as Service. In this offering the cloud provider provides the entire end to end services. Some good example of Office 365, WordPress etc:-. They can be compared to the COTS products of traditional computing.

This blog will not dwell deeper into IaaS or SaaS unless needed. If they are used then we would refer IaaS as compute or Metal. SaaS would be called as SaaS.

Categorization of PaaS

Now to get started quickly let us see the type of PaaS based on the offering

Private cloud :- In this case the cloud software (or more precisely the cloud blanket) is spread on the on premise hardware or on a VM on cloud provider that is internal facing, in the sense that it will be accessed only by enterprise network. Some of the example are Pivotal cloud foundry, Azure service stack. There are also one such offering from IBM blue mix. Private cloud can also be achieved by deploy containers (Docker and equivalent) on a container runtime like Kubernetes, docker swarm on your existing infrastructure. But they are still container run time targets and not a PaaS. We will see why and how when we see about those sections.

Hybrid cloud:- This is a terminology that needs to be understood context sensitive. It could be an application deployed in private cloud and also services from public cloud. It could also be a services deployed by PaaS from one.

Public cloud:-  This is a case in which the we just write the application. The application is hosted in public cloud using all the platform provided services. Ideally today’s most of the application that are developed are targeted for public provider. Today some enterprises are having certain valid concerns in moving to public cloud. But eventually they would find their way here.

In the next installments of this blog we will be seeing the private and public cloud. We will also be seeing best design patterns for creating cloud native application. We will also see the application lift and shift secanrios to start with and also talk on a few ways of assessing application.