Microservice is yet another term in the crowded IT lexicon. If, at the beginning of 2000, applications were solely based on monolith architecture, in the present day we can see engineers more often implementing microservices, or migrating their monolith project to microservices.
But what are these microservices? How do they differ from monolith infrastructure? And how does Kubernetes deal with all this? Let’s find out in the following article.
Microservices and monolith are architectural styles, but not those that we are likely to encounter in art history lessons. What is meant here is the architecture of apps, although some similarities to their physical counterparts are apparent.
Microservice is the approach taken when an app is built as a set of small services, where each work autonomously communicates with others. This is similar to a Baroque church, where different craftsmen work on their own part of the framework, which in the end forms a complete composition.
For example, let’s take Instagram, which is a typical example of a monolith app. It can be compared with a stone fort, where if one stone is wrongly placed, the whole building could be in jeopardy. One of the most famous examples of monolith architecture is the Linux core.
Microservice architecture transforms everything. You can change any detail without damaging the whole construction.
Although monolith apps can be quite successful, more and more developers are giving up on it as the number of applications that are deployed in the cloud increases. Even the slightest change requires a rebuild and redeployment of a whole monolith.
The engineers that have chosen microservices argue that it better facilitates the development experience and further app maintenance. If one of the services breaks down, it will be less ‘painful’ for the specialist to deal with. For instance, in Facebook, if chat or any of its other functions don’t work, it won’t disrupt the app functioning generally.
Another advantage of microservices is that they can be written using different languages, technologies, and even by different teams. A microservice approach is thought to be the future. Keep in mind, however, that this also mainly depends on the task itself. Some apps are completely fine with monolith architecture. Microservices are useful for a large project with plenty of personnel. This approach helps manage the working process and distribute tasks, giving each team of engineers one particular task to perform.
Microservices have many advantages, however, they are no silver bullet. They cannot resolve all problems, nor be applied everywhere. Moreover, their main benefit, which is the management process that can be facilitated by Kubernetes, can also be its detractor, as a lot of time is required.
But what do microservices have to do with Kubernetes?
Kubernetes is an open source framework backed by Google, which is created to orchestrate containers.
Microservices, dockers, and K8s go together naturally. Microservices are small independent services. Dockers isolate those services. K8s orchestrates them, permitting the deployment of applications in seconds and providing automated health check functionality.
Therefore, K8s describes how services have to interact with each other. However, it is not the only tool for this purpose. There are also Docker Swarm, Mesos, Nomad, and others, but they all lose out in comparison with K8s. Docker Swarm declared itself unsuitable for big installations of more than 5000 nodes. Mesos is appropriate only for specific purposes.
Kubernetes is more container-oriented. What’s more, currently it’s the most tested orchestrator around. Although supported by Google, K8s has many other champions in the market that maintain the technology. This means that it is not dependent on a sole company for its survival. Companies such as Cisco, IBM, Intel and Microsoft guarantee this. K8s also offers a great opportunity to save on technical and human resources.
#1. The consistency of operation. There is no need to use quick and dirty solutions for your installations.
#2. A minimal amount of equipment. K8s allows decreased processor load due to a minimal amount of technologies being applied.
#3. Fewer people needed. If we need less equipment, consequently we need fewer people to service it. On a daily basis, you’ll need one or two people that will work and adjust it.
#4. Kubernetes is open source. You can run K8s on your laptop for your personal projects. You can run it for mining cryptocurrencies. Or you can run it in some cloud. In contrast, AWS ECS (container management service) can be run only on Amazon.
Besides all these benefits, the biggest value of K8s lies in the rock-solid security it provides. Living in a world of regular hacker attacks, security should be a default feature of every app that wants to comply with GDPR protocols.
In view of this, Kubernetes offers:
With K8s, it is possible to isolate various application services from each other in separate containers. With this, the Orchestration Engine permits the needed level of communication. This way, K8s helps implement the very essence of microservices, namely, containers are fully separated from each other. If one gets some problems, the others won’t be compromised. Isolation prevents DDoS attacks, thus allowing for data protection and privacy.
The K8s API is the most significant part of the whole security environment. This is because it has built-in admission controls, and authorization and authentication controls as well, which filter and regulate all requests to the API after authentication and authorization. The Kubernetes API is considered to be the central interface for users, administrators, and applications that communicate with each other. Users and services can access the API to initiate operations.
If something goes wrong, the best thing to do to understand what it’s going on is to examine system logs, which K8s can help you with. In addition to standard system logs, you can record Kubernetes-specific logs that provide insight into operations that the particular user has made. And if there’s any unauthorized access, you can quickly fix the vulnerable spot.
Due to complex security features that are available inside the K8s environment, the ecosystem allows you to secure your application network in such a manner that it can become a “cyber-fortress”. There often needs to be a complex set of network policies that govern communication between every group of pods and other network endpoints in order to achieve this.
Furthermore, K8s allows complex Cluster Networking that can unite big infrastructures and make them communicate with each other. To achieve that, all containers and nodes should be able to communicate without NAT over the network, and moreover, the container should know the IP that it is assigned to. It should be the IP that others see and know.
Heptio Ark is a disaster recovery management utility that functions along with Kubernetes. This technology permits quite an easy backup, and it can restore services through a set of checkpoints with the help of AWS, GCP, and Azure. There are a lot of questions regarding the Heptio Ark backups; to gain an understanding of the situation, read our special blog post about Heptio with a detailed visual explanation.
Consul provides dynamic networking, taking us away from the classic host-based systems and moving us to a service-based approach. Outside of the new networking changes, there won’t be static firewalls, as Consul moves us to dynamic service segmentation, meaning an entirely new level of security. Furthermore, Consul is a service discovery tool that allows you to know a load of every Pod in your infrastructure.
Security is ensured via TLS certificates, service-to-service interaction and identity-based authorization. Consul can segment the network into different parts, providing each part with its privileges and communication policies without IP-based rules. If it’s not enough and you want to add an extra layer of security, then here’s where Vault comes into play.
The interaction between applications and systems can be vulnerable, and what can really solve the situation of unauthorized access are dynamically created secrets. These secrets are created and exist only when apps or services really need them, and that’s a fantastic feature because no-one actually knows the secrets and passwords. Moreover, apps and services expect secrets to expire at some point in time. The interaction between apps and services have become more reliable with Vault. These practices allow Vault to avoid providing random users with root privileges to underlying systems. Furthermore, it can also revoke secrets and do key rolling.
Security in Kubernetes has traveled a long way since the project came into being, but it still contains pitfalls. Standalone implementations can lead the project to a deadlock. Working with such technologies needs the right specialists, with appropriate tech expertise.