This is the second part of a mini-series centered around cloud computing; a high-level overview of vendor lock-in and mitigation strategies.

Part 1: Introduction to cloud computing

Part 2: Vendor lock-in — this blog

What is vendor lock-in?

Vendor lock-in happens when a customer is dependent on a vendor’s products or services and is unable to switch to another vendor without incurring substantial costs and/or organizational changes. This generic definition applies also to cloud vendor lock-in where cloud vendor is any public cloud provider like Azure, AWS, GCP, Hetzner, Linode, etc.

The Good — why single vendor strategy is attractive

Cloud vendors aim to be a one-stop-shop where customers can fulfill all their…

Introduction

Cloud computing, cloud native, public cloud, private cloud, hybrid cloud, multi cloud, Azure, AWS, GCP, IBM, Linode, Alibaba, FaaS, CaaS, SaaS, PaaS, IaaS, DaaS… confused already? In this blog series, we will try to bring some clarity to those topics.

What are the methods and decision process around selecting appropriate cloud computing setup to best fulfill our requirements? Each blog in the series will be centered around specific requirement and using industry best practices will propose a suitable solutions.

Definitions

Let’s start by defining our vocabulary around cloud related concepts which will be useful later in our analysis. …

Introduction

In this blog we will focus on software documentation, namely the documentation produced by teams and individuals involved in defining and developing software (architects and developers). There are other complementing types of documentation like requirements, business analysis, etc which we will not be focusing on.

How many times we jump into an existing active project or take on maintenance of “legacy” software, only to find out that documentation is either missing or not sufficient.

This is unfortunately a very common experience for many development teams. Why is this happening? There are a few reasons:

• The pace of software development is…

Introduction

This is the fifth part of Kubernetes mini-series Kubernetes explained deep enough

For web version of this blog and more information about docker, Kubernetes and Docker Certification, please visit:

Katacoda Scenario for self paced learning

Part 1: Introduction

Part 2: Kubernetes explained deep enough: Storage

Part 3: Kubernetes explained deep enough: Deployments

Part 4: Kubernetes explained deep enough: Configuration

Part 5: Services discoverability, DNS, cluster communication — this blog

This blog is a little bit longer than other parts of Kubernetes explained deep enough. Kubernetes networking is a very complex topic and trying to write about all nuances of different services and mechanisms would probably take…

UPDATE: Added Katacoda Scenario for self paced learning

Introduction

This is the fourth part of Kubernetes mini-series Kubernetes explained deep enough

For web version of this blog and more information about docker, Kubernetes and Docker Certification, please visit:

Part 1: Introduction

Part 2: Kubernetes explained deep enough: Storage

Part 3: Kubernetes explained deep enough: Deployments

Part 4: Kubernetes explained deep enough: Configuration — this blog

Part 5: Services discoverability, DNS, cluster communication

Visit Kubernetes documentation if you need a refresher about Configuration

Basic definitions are provided on diagrams below

How does it work?

Kubernetes natively supports 2 resources geared towards storing configuration consumed by pods. …

UPDATE: Added Katacoda Scenario for self paced learning

Introduction

This is the third part of Kubernetes mini-series Kubernetes explained deep enough

For web version of this blog and more information about docker, Kubernetes and Docker Certification, please visit:

Part 1: Introduction

Part 2: Kubernetes explained deep enough: Storage

Part3: Kubernetes explained deep enough: Deployments — this blog

Part 4: Kubernetes explained deep enough: Configuration

Part 5: Services discoverability, DNS, cluster communication

Visit Kubernetes documentation if you need a refresher about Deployments

Basic definitions are provided on diagrams below

How does it work?

Typical deployment resource consists of following objects:

Part 2: Persistent Volumes and Persistent Volume Claims

Introduction

This is the second part of Kubernetes mini-series Kubernetes explained deep enough

For web version of this blog and more information about docker, Kubernetes and Docker Certification, please visit:

Part 1: Introduction

Part 2: Kubernetes explained deep enough: Storage — this blog

Part3: Kubernetes explained deep enough: Deployments

Part 4: Kubernetes explained deep enough: Configuration

Part 5: Services discoverability, DNS, cluster communication

Visit Kubernetes documentation if you need a refresher about Persistent Volumes and Persistent Volume Claims

Basic definitions are provided on diagram below

How does it work?

Cluster admin creates persistent volumes as cluster resources…

Part 1: Introduction — this blog

Part 2: Kubernetes explained deep enough: Storage

Part3: Kubernetes explained deep enough: Deployments

Part 4: Kubernetes explained deep enough: Configuration

Part 5: Services discoverability, DNS, cluster communication

For web version of this blog and more information about docker, Kubernetes and Docker Certification, please visit:

Why another Kubernetes series?

As the popularity of Kubernetes grows, so does the number of great online resources and learning materials. A lot of available information is either designed for absolute beginners or does a very deep dive into a specific topic.

My goal is to write about Kubernetes topics in a practical way…