From self-flavored Kubernetes with SaltStack to Kubernetes as a Service in the cloud.

From self-flavored Kubernetes with SaltStack to Kubernetes as a Service in the cloud.

From self-flavored Kubernetes with SaltStack to Kubernetes as a Service in the cloud.

There are many various ways of delivering applications on production. All of them have advantages and disadvantages. This article will not elaborate much on differences between those ways.


Since I remember in our company there has been a recommendation to deliver apps as containers. During those years this recommendation evolved to a trend and at the end to a golden rule which I’m a total enthusiast of. Having an application in a container indicates a  lot of benefits and a certain need on a platform/automation side.

This article is telling a story of a platform evolution in the environment during constant changes and improvements.

See how we are handling this complex and exciting migration to the cloud in just a few minutes of reading.

The beginning of the journey

I started my journey in IDEMIA as an Integrator in  an unusual team called „Stack Team”.

Team was constructed on a thick root of automation, containerisation, and security awareness.

We have been building a solution with the internal code name „Stack 2.06” based on SaltStack – Configuration Management tool that has been chosen during a simple, logical assessment and there was almost no other tool that would fit our security needs. We fell in love with the platform pretty quickly as it was delivering more and more functionalities every day.

From a secure and fast user management via system tweaking and hardening, to installation of services such as Docker and its wrapper Docker-Compose.

This simple platform added an enormous value for us – GitOps.

Continuous Improvement of the solution

In 2016 when „Stack 2.06” was already in use on production systems, the company’s hunger for functionalities started to grow quickly.

The teams looked for more distinguished tools around docker service than just simple wrappers.

That was the moment where we became early adopters of Kubernetes.

Due to security policies and the need to keep the smallest system components of the system really close to the chest we took each and every component under our umbrella of security scans, configuration tweaks and policies, which ended with the first setups of Kubernetes with version 1.3.8. This milestone born „Stack 2.1” product (a successor of Stack 2.0.6)

Yeah! That was a journey and a technical challenge!

All versions of Kubernetes that have been released need to be thoroughly checked in terms of compatibility with already written playbooks and all existing config files extended by the new options.

And that’s not all. Many components were announcing new versions – You can imagine how easy it was to lose track of such a fast evolving product.

We have learned quickly that we should automate the whole process of test pipelines… Manual installations of full clusters were taking a few hours for experienced technician (yes! even with salt playbooks!).

All actions from Virtual Machine creation, bootstrapping Configuration Management, setting up user management, harden operating systems, installation of so needed by developers Kubernetes Cluster and finally run tests ended up on Jenkins.

Let me mention here some of the technologies that have been used to execute this enormous CI and the obstacles we have met.

Our conclusions:

  1. When various security certifications are on a company plate it is not trivial to use assets as they were created in the first place.
  2. Migration to the cloud services should be deeply analysed and described in terms of what approach should be used.
  3. Cloud is not a magic box that will cure all company ills but it helps to regulate processes and achieve goals quicker.
  4. Lots of functionalities are not covered by native cloud services.

Cloud migration is a process that does not have a strict end. Continuous Improvement plans will always fill warm (or even hot) backlog cup. All changes that inclusively push us to the cloud that are planned should be considered as opportunities and risks at the same time – such a challenging process is testing a company’s agility level, open minds of architects and all technicians around them.

I really like the wind of clouds nowadays, it makes me happy for all journeys and adventures ahead of me.

ul. Jaracza 62
90-251 Łódź