The IT world does not stand still. New languages appear, replacing the old ones. Today we will tell you about those languages that are getting lower and lower in the overall rating every day. They are no longer in high demand, and it’s not worth studying now.

The article is written based on data from the PYPL rating (the popularity index of programming languages) and the Google Trends tool.

Perl

In the 2000s, Perl was one of the leading web programming languages: practical and convenient, but with its complexities. However, after the development of more modern programming languages, mostly Python, it became difficult to stand out in the market.

Today Perl includes two versions: Perl 5 and Perl 6 (or Raku). It is used for web development and GUI development. But Perl's popularity has decreased year after year. Therefore, it is better to tackle a more popular language.

Haskell

Some people think that Haskell is essential for science and industry. Also, large companies such as Facebook, GitHub, IBM, and so on often turned to it because of its speed and reliability. However, in recent years, the popularity of this language has decreased.

So despite a significant upgrade to Haskell in 2020, it's not worth learning, especially at the beginning of your career.

Visual Basic

The leader among programming languages in 2004 is losing ground, and its rating is gradually falling. Now it ranks 18th in the PYPL rating, and according to a StackOverflow survey, Visual Basic has proven to be the most unpopular, even surpassing Objective-C.

This language appeared in 1991, and to this day, it finds an enthusiastic response in some people’s hearts. The reason for this is a straightforward syntax, which anyone who is at least a little familiar with English will be able to master. And it seems so tempting to not declare variables at the beginning of the code.

But such an approach seems exceptionally frivolous. In this language, there is no mechanism for inheriting the implementation of objects and pointers. It can only be used in Windows. And even so, it consumes a lot of resources. As a result, the code, the code may seem simple however it's still cumbersome, slow, and clueless.

Visual Basic finally lost to the C # language. In 2020, Microsoft announced that they "have no plans to develop Visual Basic." However, support on the .NET 5.0 platform will remain for now.

Elm

Elm is a functional programming language for front-end development. It appeared in 2012, and its popularity grew until 2018. But it fell over the next two years.

The problem is in rare updates. Elm looks outdated and "dead", especially for beginners who do not see much growth and development of the language. Besides, the market demand for Elm developers is lower than the supply. And programmers face serious competition.

CoffeeScript

Everyone seems to have forgotten about CoffeeScript 11 years after its release. It appeared in 2009 to make writing JavaScript code more convenient. And, despite the criticism, it was trendy among GitHub users.

It began to lose its popularity in 2015, after the introduction of JavaScript ES6. Even the introduction of CoffeeScript 2 in 2017 didn't help.

As of 2021, CoffeeScript is dead to the market (although the GitHub repository is still partly alive). Knowledge of this language is not in demand and is an exotic (and not at all mandatory) addition to the basic skills.

Erlang

The next programming language that is not worth learning is Erlang. Many organizations still use it. But modern companies prefer alternatives like Elixir, as they are more modern and accessible for beginners. Therefore, year after year, the demand for this programming language is falling.

Vacancies for Erlang developers still exist on the market. But if you want to stay competitive, you should choose a more popular and new language.

Conclusion

Of course, there are still many languages that are also losing their popularity. Studying them sometimes is just a waste of time. While using them, you lose the opportunity to discover many features of writing elegant and, most importantly, functional code.

Have you ever happened to work with the service supplier and not to get the expected outcomes? Or maybe, the supplier was not as transparent as you wanted? Well, today, we will tell you about the agreement that solves the majority of such issues - the Service Level Agreement or SLA.

Service level agreement definition

SLA is an external document (signed between the customer and the supplier) describing the service's parameters. "Compliance with SLA" is equivalent to the fact that the service corresponds to the parameters and values ​​of the metrics set in the agreement. Although the term first appeared in the IT-sphere, today, such documents are also used for other B2B segments, e.g., in the maintenance of commercial real estate, in the repair of specialized equipment, etc.

SLA agreements are actively used where the provider and the customer are autonomous to each other.

Why you may need SLA

The hesitation of companies that haven't worked with such a document is in vain. The SLA doesn't bureaucratize IT or any other service department, but it formalizes and makes the interaction between the parties more transparent.

The SLA contains a description of the provided services and sets the areas of responsibility between the parties within a particular service.

The agreement also includes terms and conditions when the service is considered completed when the contractor's liability is ceased. This means that the IT service provider doesn't have to fix bugs in the developed system if they emerge in a year, after the expiration of the stated six-month warranty.

The document prescribes parameters for the services, and acceptable hesitations are considered as a level of SLA. E.g., You can specify that the team must respond to requests in two hours max or something else. However, if one of the parties disagrees on the conditions, it's better to be discussed before signing the agreement and set the possible deflections so that nobody has false expectations. Essentially, the timings are not the only viable metric source. You can also set parameters and hesitations for the quantity of the performed tasks and other possible measures.

From the supplier's side, SLA contents are a set of supplier's goal-oriented metrics (opposed to KPI, usually set by the client but often confused with SLA). If parameters are met - great, if not - it is time to figure out who's the fault and act according to conditions also set in the agreement. It's critical to be very cautious about the metrics and parameters because if you focus on them more than on a solution itself, you are risking ruining the project.

From the client's perspective, SLA is also useful for setting terms, conditions, and possible deflections for inquiries. Plus, it's possible to state penalties for suppliers if there are any violations that are not prescribed as possible deflection (so called indemnification clause).

What kind of metrics to monitor?

Depending on the provided service, metrics can vary. Some indicators can be monitored within SLA. Remember that you should set everything as simple and straightforward as possible, considering only the most critical parameters. Essentially this includes:

• Service availability. It means the amount of time when service is available. For example, if the company provides services from 9 to 5, five days a week, from Monday to Friday, it should be stated. National holidays, shorten days and other special day-offs are likely to be set as well.
• Technical quality & defects. It covers the amount and percentages of errors in major deliverables. Production failures, coding errors, time spent on their identifications, and fixing causing overtime work, missed deadlines - all of this should be monitored.
• Security. Application security breaches can cause many problems, including additional expenses. Monitoring controllable security measures is vital. Anti-virus updates, patching, security protocols, and scripting ensure that all measures were taken to prevent breaches.

If some hesitations can occur at any point, it should also be noted along with possible actions and outcomes.

How to work by SLA

The scheme of work under the agreement is quite simple and clear:

• notify all the members of the other party's team on the parameters of the agreement;
• do your best to comply with the metrics concerning another side;
• regularly measure the compliance of the parameters with the declared indicators;
• analyze and optimize processes within the company;
• remember that SLA can be revised from time to time (it's even highly recommended) since the definitive agreement - is an unattainable perfection.

Please note that it is much easier to comply with the SLA if the service company's processes are well-established.

Benefits of SLA

For client

• Measurable service metrics - you always know what you pay for;
• ability to compare reality with expectations;
• the right to get compensation if the supplier fails;
• ability to state warranty period and other conditions.

For supplier

• Ability to state your terms and conditions;
• establish processes within provided services;
• limit the area of own responsibility;
• introducing the several levels of support earning on it (e.g., get extra money for the task urgency, warranty extension etc.).

Conclusion

SLA is a reliable backup for both parties if you use it wisely: thoroughly and carefully setting all the necessary parameters and noting all the possible hesitations, terms and conditions. This agreement will especially work great if the service provider has firmly established processes within their company: which is also an excellent sign for a client.

Before starting to implement an idea, different people have different definitions of the intended result. In this case, the most common terms are the MVP (minimum viable product), POC (proof-of-concept), and Prototype.

Let's try to determine when it is most appropriate to use each of the above definitions to avoid misunderstandings.

MVP

A minimum viable product is often developed as a first version. This is a prototype that has basic functions and gives an idea of how the final version works. It could be a website or an app - but whatever you do, keep it simple for now.

The term “Minimum Viable Product” became popular a few years ago with the advent of the Lean Startup era. The essence of the method is to reduce the costs of building a business. Therefore, MVP is a product with minimal start-up costs. Of course, building an MVP within the Lean Startup approach isn't the only product development approach but the most spread one.

Since MVP is a prototype, it's not a reason to make it worse. To create an MVP, you need to think over all the future product elements - each capability, each potential page - and choose what will illustrate its functionality and benefits best for the audience.

Due to several factors (market, alternative solutions to the problem, etc.), your MVP will be significantly different from anyone else's. So ask yourself the question: "What minimum functionality is enough to solve the problem" Thinking this way, you will spend much less time on secondary tasks and save resources in the early stages.

MVP of popular brands

Apple

Apple is one of the most valuable brands in the world today. But after founding in 1976, the company only offered a printed circuit board. There was no keyboard, no monitor, no case.

eBay

eBay, the most popular online auction site, was initially called AuctionWeb and launched in 1995. Below is the first draft of the eBay homepage - and the 2014 version.

We see how successful these products are today, but we forget that it took them years to reach their current level.

Balancing product priorities doesn't end with the MVP launch. It continues throughout the entire product lifecycle. Even when you have a customer base and a profitable company, you still have to choose what to do first and leave for later.

The minimum viable product is not a “raw” version, but a “skeleton” of a future solution, containing the most important of what will be in it.

POC

Proof of concept (PoC) demonstrates the practical feasibility of a method, idea, and technology to prove that a method, idea, or technology works.

There are different approaches to defining the Proof of Concept. It often includes prototyping and creating an MVP. However, these are different methods of idea validation of idea validation, as they pursue different goals and yield different results. It is also mistaken to take PoC as a kind of "draft" of the project, which only needs to be slightly modified in the future. The Proof of Concept format itself is much closer to research than developing a working product. Only a small part of the system is tested - critical functions, and the result obtained may not be used in further development. Since the goal of PoC is to make sure the concept works in a short time, minor aspects important for the final version of the product can be omitted. In such cases, having received the green light during the PoC phase, the team can start developing a project from scratch.

Considering that product development based on new technologies can be too risky or hassle, PoC is becoming an indispensable tool to save you time, resources, and money.

PoC proves the viability of the product. It demonstrates that the project can be completed and provides a starting point for developing the project as a whole.

PoC also identifies several potential pitfalls and weaknesses that should be avoided during product development. Based on this research, a more accurate estimate of the project is created, which allows you to move on to the next stage of development.

At the same time, Proof of Concept does not cover the entire system but is aimed at a specific part of it, which users may not see since PoC is mainly used internally to flesh out the product development path.

At first glance, it might seem that Proof of Concept can be used on any complex project. But this is only at first glance.

A distinctive feature of PoC is that it deals with unusual, previously unheard of situations. Accordingly, when the need for PoC arises, the solution "at the exit" is different each time.

Whatever the reason for your doubts, PoC will help clear them up. Either it becomes clear that your project is viable and relevant to the market, or it's time to look for Plan B.

Prototype

And last but not least, - Prototype. A prototype is a working model of software with some limited functionality. The prototype does not always contain the exact logic used in the real software application and requires additional evaluation effort.

Prototyping is used to enable users to evaluate developer suggestions and test them before implementation. It also helps to understand the user’s specific requirements that the developer may not consider when developing the product.

Top reasons for using prototypes

Fast feedback

One of the most critical aspects of the product creation process is collecting feedback. You can gather feedback at every development stage with prototypes, whether adding new features or changing elements. Check what works for your audience and what doesn't. Feedback will be vital to the success of your project.

Better design vision

Prototyping provides a clear visualization of the design to understand how the final product will look like. It helps the team understand what they are designing and for whom they are doing it.

Saving time and money

Try to stay in "prototyping mode" as long as possible. The more you learn about the design problem you are trying to solve, the faster the implementation will be. You can always make changes to the preliminary model. Making early changes will help you reach your goals faster. Prototyping will also make your development process more cost-effective as the entire development cycle becomes shorter.

Do not be distracted by unnecessary things

There are many details and distractions in development that can get to design user interactions with the product. Therefore, creating a prototype allows you to create a technically correct and functional product.

Checking before design and development

Prototyping allows for several discussions between iterations before proceeding with final development. This iterative process will enable you to be sure that you are doing exactly what you need.

Conclusion

It's important to understand that while MVP, POC, and Prototype have many similarities, they still have different goals. In the course of work, the POC can grow into a prototype or MVP, or vice versa. In the end, it's up to you to decide which way to go.

If you doubt which to choose, you’re welcome to contact us for a free consultation!

---

The authors

If you work in a medium or a big company with a long history, there is a high probability that now you are dealing with some outdated legacy system. Many business owners suppose that it is okay to work with such systems as they still do their job. They believe that it is easier and cheaper to support old software than to build a new one or migrate. But is it? This article will give you a complete overview of the software migration phenomenon: when it is needed, why, and how to do this with less gain.

What is Software Migration?

Some people imagine software migration as a process of system transfer from one technology to another. However, that is just half of the deal. Shortly speaking, software migration is like rebuilding the system from scratch, implementing the same features and functionalities with modern developing technologies.

Software migration refers to software modernization. During this process, you can rebuild your old software with the new technologies and change the design and add some new features.

Reasons to Migrate

• When technology on which the system is developed is no longer supported.
  That's probably the most critical point. If you are staying with outdated technology, you will not be able even to access the system one day. Moreover, when there are no security updates, you can end up with a hacked database causing information leakage and other consequences.
• When it becomes too pricey and resource-consuming to support.
  The old systems are often unable to keep up with modern hardware, browsers, and operating systems. Modern conditions multiplied by legacy code and poor documentation may cause countless bugs and hundreds of person-hours to fix them. With the new software, you can prevent that. Of course, this software will still demand a little support from time to time. But this is the long-term investment that will pay off.
• When the system does not correspond to the renovated business processes.
  If your company is experiencing significant growth, changes in the business model, and processes that cannot be handled with the existing system - consider the migration. This will save you much time in the future, eliminate the error level, and contribute to your business's further growth.
• When the system cannot be integrated with modern tools.
  Let's say you are using the old Customer Relationship Management System. A long time ago, such systems were only capable of storing information about your actual clients. Today CRM can be integrated with your website analytics, emailing system, and order management system. It can give you all the possible customer insights and endless possibilities for communication with customers and improve customer experience, raising your profits. And this can be applied not only to CRMs but also to other systems like HRM (Human Resource Management), ERP (Enterprise Resource Planning), etc.

If you resonate at least with one of these points - the time has come.

Migration Process Flow

Combine a Migration Plan

At the first stage, we recommend thorough preparation of the documentation necessary for migration planning and development, namely:

• Business and technical requirements;
• Project specification (in case if additional functionality is required);
• Project plan (to plan time for each stage).

Test Environment

If you want your system to work during the migration process, you should take care of the test environment and configure the version control system. All related development tasks and sub-projects should be performed in a separate environment (on a separate server) not to interrupt business activities.

Redesign

This is optional, but if you want to breathe a new life into your product, you can request a design change. Most of the software development companies have at least a couple of designers on their side. If you already have the designer on your side, you can give them the tasks related to redesign and then send the ready layouts to the development team.

Modules Installation and Development of Additional Functionality

After redevelopment of the basic functionality, old modules should be replaced with the new ones. The team can then develop additional modules or functionality if the client required some additional functionality that wasn't a part of the initial system.

Data Migration

Data migration is not an obligatory step. However, if the data is critically valuable, it is recommended not to neglect this step. Here, you can consider some options, e.g., if you store the information on the on-premise server you may want to migrate it to the cloud or the newer database version.

Publishing Planning & Database Synchronization

After the final testing of a redeveloped system, you must get ready for the project publishing.

Before that, we recommend buying a compatible hosting or setting up your dedicated server following the new system requirements. After that, you can start additional synchronization of the new database. It is recommended to transfer the latest data from the old system to the new one.

Release

The last stage of the project migration is the product's release at a convenient time for the end-users not to interrupt the sessions. It's also recommended to perform the product release under the control of software developers and testing specialists to detect and fix the bugs if they emerge.

Tips for Successful Migration

Here are some steps that we recommend due to our experience:

1. Hire universal specialists

Here we mean the developers who are proficient with both technologies - the one you migrate from and the one you migrate to. Such a team can read and understand the code and how everything works in the old version and do some reverse engineering performing the same with the new technology. Of course, these specialists' rates can be relatively high, but this approach will ensure faster delivery and the best possible compliance with the new system.

2. Prepare data backup

This one is a must-have, although often neglected one. You never know what can happen during the migration. For some force-majours, we recommend backing everything up, especially the data. It will eliminate the risk of data loss or damage.

Document everything

Depending on the appropriate methods, ask developers to document every step of migration. Use the project management tool to keep everyone informed and gather documentation.

Before the migration, this is also great if you take inventory of assets. So after the migration, you could make sure that the team hasn't lost anything along the way. For some software and applications, you should take inventory of each possible action and function, the way it interacts with the backend, and the unique custom configurations if they take place.

Benefits of software migration

Along with the renovated system, you will get the following benefits:

• increased efficiency of the system;
• modern, intuitive, and user-friendly interface;
• increased productivity of departments;
• reduced costs on software support and operation;
• decreased errors;
• integration with modern tools;
• easier scalability of the system.

What systems are not worth migrating?

Despite the migration benefits we mentioned above, there is software that still doesn't need to be migrated. For example, some complex products that won't be updated anymore and have a limited number of users. It will be possible to use outdated versions of browsers or think of some other “roundabouts” at the appropriate workplaces.

But it's only possible in the case of internal use, where the end-users of the product are the company's employees. If the product is intended for external mass use, the migration is undoubtedly necessary and must be performed as soon as possible.

For example, if software built on Flash is installed and used in some company, and its further updating is not planned - you can stick to it: it will still work for some time. Now in some governmental organizations, you can find software written in Delphi, and it still does its job. However, now no one can develop and update such software. Eventually, it will simply go out of use and have to be replaced with something else.

Summarizing

The software migration process is not as painful and costly as it seems. If you have a test environment, your system can operate without any interruption of the working process. When you plan everything thoroughly, the migration will go smoothly, especially if an experienced development team performs it.

In case you have some difficulties with the migration or modernization, contact us for a free consultation. 20+ of our clients already used this opportunity to their advantage. Don't miss the chance to join them!

---

The authors

With the boom of horizontal scalability and microservice architecture, the world observed the “container deployment era”. Containers have been in use for more than ten years. Today at least a quarter of leading IT companies use container solutions in a big production, and this number is likely to grow further.

Many market solutions provide container runtimes and orchestration, such as Docker Swarm, Mesos, and others. However, more than half of the users choose Kubernetes as an infrastructure standard. Here we'll talk about the Kubernetes as a widespread and rapidly-developing solution.

Why containers?

Let’s start with container peculiarities and advantages first.

As Docker developers would say: "a container is a standard unit of software that packs an application with all the dependencies it needs to run - application code, runtime, system tools, libraries, and settings." Compared to Virtual Machines, containers, in essence, are not full-fledged independent OSes, but configured spaces isolated within the same OS that use the host's Linux kernel to access hardware resources, as well as the host’s memory and storage. Therefore, containers require significantly fewer resources to start and run, which positively impacts the project's performance and budget.

Lightweight, high-speed of startup and great performance, the delegation of hardware and OS maintenance to the provider (in case of -as-a-Service solutions), are the advantages of containers, which reduce the costs of development and maintenance of applications making solutions based on containers so attractive for businesses.

As for advantages for technical specialists, containers allow them to pack an application along with its runtime environment, thereby solving the problem of dependencies in different environments. For example, differences between software package versions on the developer's laptop and the subsequent staging or production environments will sooner or later lead to failures. So it will at least require efforts to get with them: to analyze and fix bugs edged into production. Using containers eliminates the "everything-worked-on-my-machine" problem.

Containers also reduce app development time and simplify its management in production due to:

• easy setup and changing the configuration;
• versioning the configuration along with the application code;
• creating an easily reproducible environment for implementing CI/CD processes;
• convenient orchestration tools allowing to scale the infrastructure quickly.

Besides, the absence of binding containers to the hosting platform gives tremendous flexibility when choosing or changing a provider. One can run them without fundamental differences on a personal computer, bare metal servers, or cloud services.

Containers are a great way to bundle and run applications. In a production environment, DevOps engineers need to manage the containers that run the applications and ensure that there is no downtime. To withstand the estimated load, the number of application containers should be certain or not less than the minimum required. So here some mechanism is required which will start new copies of the app containers if the load will become higher or some of them fail for any reason. And this process is easier when such behavior is handled by the system like an “orchestrator” for these containers. All this leads to Kubernetes.

About Kubernetes

Kubernetes (also known as K8s) is a platform implementing orchestration of containers in a cluster environment. Previously, it was mainly used for Docker containers as they were highly popular and wide-spread. But, in the latest Kubernetes versions, Docker is listed as deprecated while Container Runtime Interface (CRI) is stated as the native container mechanism.

Kubernetes significantly expands container capabilities, making it easier to manage deployment, network routing, resource consumption, load balancing, and fault tolerance of running applications. This platform is now widely offered by Cloud providers within the -as-a-Service model. At the same time, nothing stops you from installing it on a set of physical or virtual machines whether in the cloud or on-premise.

Kubernetes is a new step in the IT industry that allows simplifying the delivery of apps including the environment where these apps will run. With Kubernetes, it is possible to abstract the description of this environment from the hardware configuration.

K8s allows us to create a cluster based on several physical or virtual machines. This cluster works as a single environment and consists of two types of nodes:

• Master nodes that manage the cluster (for high availability best practice there should be at least 2 master nodes);
• Worker nodes are the machines to run the applications (2 or more as for full-fledged cluster depending on load).

When you deploy your applications in K8s, you alert the master to launch app containers. The master node schedules containers to run on the working nodes. Each working node communicates with the master. For that Kubernetes has the API, which can be used for direct management using REST calls as well.

To get started with Kubernetes developers can use a lightweight implementation - Minikube. Minikube is a tool available as a cross-platform solution. It creates a simple single-node cluster on a local machine.

To work with a Kubernetes cluster and to run an app in such an environment, one needs certain instructions to determine the desired state of the app. Such instructions are Kubernetes Manifests that describe what and how you want to run the containerized code in a cluster. Basic manifests could be relatively simple. They are code in YAML/JSON format, so for a developer, it would not be a problem to write a simple manifest, also Manifests can be handled using the GitOps model. But when we are moving from simple manifests in development to production, the problem is that the level of K8s abstraction is so high that one should have a good understanding of how things work under the hood of a cluster.

Kubernetes has a lot of Kinds that describe and manage the behavior of containers inside a cluster. K8s itself is primarily a Container Orchestrator and therefore its parts are containers as well. This fact leads us to 2 main peculiarities:

1. The components of the platform do not affect each other. If one goes down, then all others continue to operate.
2. These components work according to a pull model. There is no central component, a commander who rules everyone. Each component carries out and performs its own function. If the component fails, then its actions will not be performed.
3. Kubernetes model is focused on maintaining the desired number of working containers: it restarts the containers that go down, or don't respond to a user-defined health check, replacing them.

Core Kinds of Kubernetes

Node
A node is a component part of the Kubernetes cluster. The Master node (there can be several of those) controls the cluster through the scheduler and controller manager, provides an interface for interacting with users through the API server, and contains the etcd repository with cluster configuration, statuses of its objects, and metadata. The working nodes are intended exclusively for launching and working with containers; for this, two Kubernetes services are installed on it - a network router and a scheduler agent.

Namespace
A structural object that allows you to divide cluster resources between environments, users, and teams.

Pod
This is the smallest unit in Kubernetes - a group of one or more containers that work as one service or application, assembled for joint deployment on a node. It makes sense to group containers of different types in a Pod when they depend on each other and, therefore, must run on the same node to reduce the response time when they interact. An example: containers with a web application and a caching service.

ReplicaSet
An object that describes and controls the correspondence of the number of Pod replicas running on the cluster. Setting the number of replicas to more than one is required to improve the application's fault tolerance and scalability. Deployment kind provides more capabilities and is used more often for apps, but in some particular cases, ReplicaSet is enough.

Deployment
An object that declaratively describes Pods, the number of replicas, and the strategy for their replacement during the update. Deployment allows updating different Pods according to declared rules. This makes the update of services or applications that have been released as smooth and painless as possible.

StatefulSet
StatefulSet allows you to describe and save Pods' state: a unique network address and their disk storage while restarting, thus implementing the stateful application model.

DaemonSet
It's a kind that provides control over what will be launched on each (or several selected) node according to a specified Pod instance. It is used to run cluster storage, log collecting, or node monitoring.

Job and CronJob
The kinds that launch the specified Pod once (or regularly on a schedule in case of CronJob) and monitor the result of its execution.

Service
A virtual kind for publishing an application as a network service, which also implements load balancing between application Pods.

CRD
K8s is not limited only by its basic functionality, but can also be extended with Custom Resource Definitions (CRD). CRD allows us to inject or even “invent” new custom kinds in addition to out-of-the-box ones.

Pros and Cons of Kubernetes

The K8s in essence is a great abstraction tool: there is no need to think deeply about technologies, hardware resources, or their maintenance, etc. Let’s look a bit deeper.

+Abstraction from hardware

First of all, there is no need to deep dive into hardware characteristics and parameters, despite the project itself not requiring some specific needs. In case of any custom solutions, developers or DevOps engineers indicate these custom adjustments in the manifests or probably even add checks for them.

For example, if your project uses a database and it’s not a cloud database -as-a-Service, you should have one or several nodes a bit more improved than the others (they should have more memory and fast storage) and you should just “tell” via manifests for database pods to be run on exactly these improved nodes.

Moreover, you are able to limit all the needed resources (RAM, CPU, etc) yourself. The lack of processing capacities can be compensated by cluster monitoring plus node scaling. If talking about the Cloud, this process can even be automated with a Cluster Autoscaler which scales the target cluster up or down, so it can satisfy any changing demands of the workloads on top.

Autoscaling is a great solution when you don’t know exactly what will be the load and how many resources the app needs to keep such a load. As an example: selling the tickets for a football match, when the request traffic increases within a short period of time. So with Cluster Autoscaler, the cluster expands automatically to cope with the load and returns back after the load decrease.

+Resource isolation
With the help of namespaces, you can isolate several projects or different stages of one project - non-prod and prod environments - from each other in one cluster. With RBAC you can also configure restriction of access to valuable resources based on the role the user holds. All this provides us with predictable application security.

+ Safe update of microservice systems
All we know, that microservice architecture is widespread now. For example, if we have a website divided into modules that operate separately, the failure of one will not affect the whole system. Moreover, there is a possibility to update each separate module with Deployment so that any problems with the update do not engage the whole audience but nobody or a small part of them. And, eventually, if something goes wrong, versioning will help us to roll the update back.

+Uniformity
There is no actual OS dependency, you just have an integrated interface you interact via standard commands or API with.

+Integration with third-party software
Integration with monitoring systems, CI/CD systems, secret storages, and many more. As for the secrets: if you don’t want secrets to be placed in a cluster, there is an opportunity to integrate K8s with systems storing secrets in order to have them in secret storage, while K8s can access them securely when needed.

+-Open-source
K8s was created by Google and has been published as open-source. It’s an advantage and disadvantage at the same time as we can face a problem of technical support. In case of an urgent Kubernetes platform issue, there is no opportunity to address it to experts responsible to fix it. So, whoever uses K8s, should understand that for now, just the open-source community supports it.

But business needs support for software platforms. So there were the companies who decided to release Kubernetes as a commercial product. One of them is RedHat - a company that provides supported open-source software products to enterprises. They released their own container orchestration platform based on Kubernetes named OpenShift with enterprise lifecycle support.

It is also worth mentioning Rancher that offers the functionality of commercial K8s distribution in an open-source package. It is quite popular now since it allows to easily create clusters on bare metal with Rancher Kubernetes Engine as well as on hosting providers such as AKS and GKE. Rancher is not a redesign of Kubernetes, but rather a platform that makes deployment and use of it easier even in multi-cluster environments.

- High entry threshold
Kubernetes interface is implemented as a number of rather complex Manifests or descriptions for each abstracted kind. To understand all the peculiarities and to have the ability to configure and debug such systems, one should have a good understanding of microservice architecture and containerization principles, and, therefore, should have a good knowledge of Linux itself as a basis. So if it’s a small or mid-sized project, it would be a tough start for a developer to work with Kubernetes from the scratch without a fair knowledge of the technologies mentioned.

As for the projects, there are cases when startups hope for the fast start and high load of their systems, and eventually, their expectations fall short, which means there were spent extra efforts and resources for implementing microservices and orchestration, and as the result - overhead. This point leads us to the question below.

Is it always Kubernetes?

Since Kubernetes has been on the hype for the last several years, it’s a common practice when a client with a small-sized project requests Kubernetes to be used from the very beginning.

But Kubernetes must be used consciously. Working with Kubernetes should be considered when you have a really large number of microservices when there are certain requirements for the level of availability of your project/system, when several teams are working on the application, or when infrastructure is needed to automate deployments and tests more efficiently. At this point, it's really worth thinking about Kubernetes.

If you are a small company or if you have a monolithic app that will be hard to split into microservices, Kubernetes is definitely not the best decision.

In the case of a microservice solution, Kubernetes is rather a blessing. Gradually, the application becomes overgrown with logic, and there are more and more microservices. And Docker itself is already becoming insufficient. Plus to everything, the clients probably also want some kind of fault tolerance.

Gradually, the company bumps into the ceiling when they need a fresh and highly productive solution. And here, of course, you need a container orchestrator. K8s is a type of software that manages all microservices, looks after them, repairs, transfers within a cluster, builds networks and routes their traffic, and, in general, is such an entry point to the entire infrastructure of the project.

Summarizing

The IT industry is highly flexible and changeable. The software is more and more complex each year. To keep up to date, businesses need to use the newest tools and solutions.

If we look at this issue in terms of deployment, a couple of years ago using containers in production was considered an unreliable solution. However, time does not stand still, the industry evaluated and appreciated the prospects of containers. Now the variety of solutions based on containers is more and more convenient and attractive for businesses.

As for the Kubernetes, if implemented and maintained correctly, it offers developers, DevOps engineers, and business owners great benefits: scalability, workload portability, improved app development/deployment efficiencies, effort, and cost optimization.

Our DevOps team has been working with containers and Kubernetes in particular for a while for far. If you are on the way to digital transformation with K8s, we are ready to help! Contact us for more information.

---

The authors