Kubernetes

Kubernetes, it appears to me to be a funny sounding word that could be uttered by an actor in a science fiction movie. If interested in the actual origin of the word, take a look at the following Kubernetes link in Wikipedia.

I am more interested in what it does than how the word came to be (even though I did read the entire Wikipedia article). In the book Production-Ready Microservices by Susan J. Fowler; published by O’Reilly (which I purchased from Amazon and read), a nice and simple diagram is used to describe the four-layer model of the microservice ecosystem.

I strongly recommend getting a copy of the book and reading at least chapter 1 (the entire book provides points that should be taken into account in order to streamline the production of microservices; so go ahead end read it in its entirety).

Layer 1 contains the hardware; the computers with their PCU(s), memory, and disks mounted on racks with network chips and routers. Such hardware racks could be sitting in private companies, but most likely are in some data center owned by an internet provider in some part of the world. This layer contains the servers, databases, operating system among other components.

Layer 2 contains the communication layer. This layer contains the mechanisms used by microservices to be accessed and the mechanisms they use to access other microservices in order to get their work done. This layer encompasses DNS, networks, Remote Procedure Calls (RPCs), Service registry and discovery and load balancing to name a few.

Layer 3 is the application platform. In a nutshell it contains the tools that allow microservices to be developed, tested, packaged, deployed and monitored.

Finally we get to Layer 4, where the microservice performs the task(s) it needs to perform. Software developers tend to work at this layer implementing the software that follows the business rules. This is the layer that clients; whether machines or humans, access to get what they need (e.g., browse and purchase a product from a retailer, store and retrieve medical records for a patient, etc).

If each microservice developer or development team would had to manage the lower three layers, it would be quite difficult and time consuming to get microservices architected, designed, implemented, tested, deployed and monitored. That is where Kubernetes come into play. They can simplify and standardize most of management needed by the bottom three layers to relief software developers from such concerns.

Like in TV commercials, “But wait; there is more…” Kubernetes is cross-platform. That should be extremely important for most software developers. I fully understand that many small to medium companies tend to standardize on a hardware and software platform. If a company is using Windows, it is difficult for a vendor to introduce Apple or Linux equipment. This is one of the reasons the WWW has become so popular. All hardware and software platforms support web browsers. The browsers all speak HTTP and HTTPS. End users no longer care if they are on a desktop or smart phone accessing the services they need. They only value the information and quality of the experience.

With Kubernetes a software development team can deploy and monitor their microservices on Azure by Microsoft or Google Cloud. Most important the microservice ecosystem required by an organization may run on both systems. This is important in case a server, rack, center or provider experiences an outage.

Another thing of interest; at least to me, is the fact that when you write a shell script using bash, ksh or in your favorite interpreted language, chances are that you will be using an imperative language. In an imperative language you need to specify states using extensive logic. For example; if you wish to have three and only three instances of a service running, you would have to check the state of each of the services and make sure you check that there are no more or less than what you require.

Kubernetes uses a declarative language to specify configurations. In such case you just need to specify that you need three instances of your microservice running at the time without having to worry about checking conditions. This simplifies the work and reduces the chances of errors.

I will be covering more topics on ASP.NET Core, Kubernetes and microservices in the next few months.

Happy software development;

John

Follow me on Twitter:  @john_canessa

www.johncanessa.com

Leave a Reply

Your email address will not be published. Required fields are marked *