Here are some very interesting and easily accessible numbers from Twitter: Docker has 304,000 followers and Kubernetes has 121,000. On the other hand, Helm, Istio and Prometheus Monitoring have fewer than 15,000 followers each.
A popularity comparison for each technology. Twitter followers are in blue, Stack Overflow searches in red, and Google keyword searches are in green.
Twitter has no numbers at all for Terraform. It pretty much the same goes for Google keyword searches and Stack Overflow searches. It is a common consensus in the IT community that container technology makes sense and has a future. In addition, many developers are already using Docker, which certainly explains the high numbers. But why the heavy drop for Kubernetes and why do the other technologies have so few followers or searches?
We have a theory: On the one hand, popular topics have a natural evolution over time. On the other hand, the learning curves of the architects. Both these are related.
Learning curve?
How do we, as architects, come into contact with new things in our work? We discover Docker with enthusiasm and then quickly see the benefits when combined with Kubernetes. But we still need to go one step further and gain more experience to understand that our cloud platform could do a little more in order to meet our growing and future needs. Who among us can say, “I knew right away what Istio, Helm, and Prometheus could do, but I deliberately decided to deal with it later”?
Or, as a colleague aptly put it: “To understand Istio, I first had to understand Kubernetes. And to understand Kubernetes, I first had to understand Docker.” These things build on each other and solve problems that the individual technologies themselves cannot. This is nothing new in IT or open-source projects. So, why write an article about such obvious patterns in IT?
Simply stated: if you know what you need to learn, you can plan for it.
A suggestion
You have recognized the value of containers – take Docker. Why not resolve from the beginning to learn Docker, Kubernetes, Helm, Istio, and Prometheus? You wonder, why these technologies? We will take a look at this now.
Kubernetes
Anyone who starts using Docker quickly realizes that the containers multiply. Sooner or later, there are many containers running. Managing their lifecycle or high level of availability requires more and more effort and putting time and work into your scripts. This condition can be remedied.
SEE ALSO: 5 open source tools to upgrade your next Kubernetes project
Kubernetes comes from the Greek and means “helmsman” or “captain”. The open source project Kubernetes (abbreviation: K8s) controls Docker Containers and has become a quasi-standard in this regard. Developers or administrators use YAML files to tell K8s which Docker images to run and how often. In addition, the system allows roll-forward and roll-back of container versions. It also automates redundant Docker instances and keep-alive/auto-restart mechanisms for better availability and horizontal scaling of Docker images in Kubernetes pods (e.g. in the event of an increased load). Thanks to the built-in load balancer, you do not have to worry about a lot of aspects anymore. The functionality of Kubernetes is indispensable to any serious Docker operating environment. Of course, in simple cases, Docker Swarm will also help.
However, in an IT landscape that is increasingly modularized and consistently splits functions into several different container images, Kubernetes does not “see the big picture”. It doesn’t see which services or modules together result in a complete application or how are these containers related. This is where the Helm Charts come into play.
Helm
Helm is often called the package manager for Kubernetes. Usually, Helm sits on top of K8s and extends the capabilities of the system by considering version dependencies of a more complex application between different Docker images. For updates and roll-backs in a larger style, which themselves are built from different containers and use services of other, independently existing containers. Helm makes this complexity much more manageable. Easy-to-maintain and versioned Helm Charts describe the relationships between the components. In other words, how will you deliver a complex modular application in the future? You provide the Docker images, the Kubernetes scripts, and a Helm Chart, or put your chart in a corresponding repository.
Future: service mesh
With Kubernetes and Helm, we manage the life cycle, the dependencies, and the operation of our containers. K8s offers virtual networking in and between the pods. Everything works and communicates well. Are we done now? Not quite.
Over time, more and more of our features and systems are running in the container world. We develop new systems based on a microservice or cloud-native architecture and operate them in the same way, packing as few components as possible into one container. This increases the number of our containers and communication relationships. In addition, we are all pursuing the goal of continuous deployment. For each component, there are always several versions and variants in our stages of the CI/CD pipeline – each of which, we can’t forget, has a dedicated container.
In addition to a large container landscape, we also end up with a “service mesh”. This is the term for the multitude of (micro) services in combination with the communication relationships between these services.
Efficient network functionality is no longer enough in such environments. By this stage of development, we have to master, manage, and secure the communication. We do not want to leave our chosen platform or architecture – we want to complement it in such a way that we burden our developers with as little added complexity or restrictions as possible.
Istio
This is where Istio comes in: to master these requirements. Just like Helm, few people are aware of it. In fact, it not only solves problems for us but opens up new potential.
After a yearlong joint effort, Google, IBM, and Lyft went public with Istio in full open source on May 24, 2017. Each of the founders introduced concepts and code (e.g. Lyft and their Envoy proxy) which was already in use for tens of thousands of VMs and hundreds of microservices, even in production. The goals were and are: “traffic flow management, access policy management enforcement, and telemetry data aggregation between microservices […] without requiring developers to make changes to application code”(“https://istio.io/docs/concepts/what-is-istio/“, Oct 2018).
After eight 0.x releases, the “production ready” version 1.0 of Istio was released on 31.07.2018.
Closely integrated with K8s, the Envoy proxy is automatically injected into each container as a so-called sidecar, allowing it to control any network traffic via HTTP 1.1, HTTP/2, Websockets and gRPC. Incidentally, there are other protocols, e.g. for asynchronous communication in the backlog of the Istio and Envoy developers. With these mechanisms, we can easily implement canary deployments, for example. You can deploy the new version, but only forward e.g. 10% of the calls to it. This allows new features to be tested under realistic conditions.
Also, A/B testing or red/black deployments have been greatly simplified. Istio allows splitting the traffic on a percentage basis and controlling it by configuring circuit breakers, timeouts, and retries. All control usually requires an understanding of the actual state and the previous development. Istio provides comprehensive monitoring, logging, and tracing to monitor the service levels.
SEE ALSO: MicroProfile, the microservice programming model made for Istio
A central powerful component of Istio consists of policies that are extensible and customizable. For example, a number of API management solution providers are linking their technology to Istio and mapping the policies of the APIs to the Istio policies of the underlying services. This is not only a beautiful, clean architecture; it also shows that these API management projects are convinced of the success of Istio.
Istio can also relieve developers of a lot of complexity in the area of security. It implements secure communication channels and manages authentication, authorization, and encryption, even for very large environments, and fully integrates with Kubernetes and other components. It is a design goal of Istio to be platform-neutral and require as little code-change as possible. But you do not always want to realize the functions of Istio completely transparent to the code. For example, Java EE developers with Microprofile.io classes can completely enrich their Circuit Breaker with their own logic in the Jakarta EE standard because Microprofile.io uses the Istio APIs.
Istio Architecture, Source: Istio: https://istio.io/ (Stand V1.0.2)
If you’re starting to get excited about the potential of Istio and have an idea of the elegance of the architecture, you may be wondering if it’s hard to install Istio in your landscape. As previously mentioned, Istio integrates itself in an exemplary manner. Just install the associated Helm Chart for the Istio runtime. You should also be aware that public cloud providers like AWS and IBM have corresponding connectors for your local Istio instance, and that the public cloud runtimes of Google, etc. use Istio and make it usable for you. Private cloud offerings like IBM Cloud Private already support Istio 1.0; others like Red Hat OpenShift now have it on their public roadmaps. If Cloud Foundry is part of your cloud strategy, you can rest reassured. Pivotal, IBM, and other partners are working on the integration with Istio. In short, you can only make one mistake: not including Istio and Helm in your plans.
Prometheus
Once again, Greek mythology. Literally the “leading thinker”, Prometheus gave fire to humanity against the will of his father, Zeus. He was severely punished for this. Divine background out of the way, a question: Why make this open source project from Cloud Native Computing Foundation (by the way, the Envoy mentioned above also is one such project) a part of our private cloud architecture?
The aim of the project is to offer high-availability system and service monitoring, which not only delivers predefined alerts but also makes it possible to use the collected data to troubleshoot and problem-solve at any time. Do not overlook the aspect of service monitoring here. The more modern the architecture, the more central the quality of the services; the condition of the infrastructure in it is assumed to be “always sufficiently good”. K8s environments are the main target and here Prometheus is also particularly well suited for the monitoring. The public learned about the project in January of 2015. Since then, it has gained a lot of momentum, distribution and acceptance. For example, Red Hat has deeper integration on its public OpenShift roadmap, and IBM Cloud Private has been integrating Prometheus almost entirely since its launch in 2017. Istio Metrics can also be used in Prometheus. Pivotal also demonstrates the use of Prometheus for cloud foundry environments.
Prometheus Architecture, Source: Prometheus Architecture, Source:
Those who are serious about their private cloud platform cannot stop at elaborate and universal monitoring that focuses exclusively on the technology components of the platform. In our opinion, Prometheus is just “the place to be” – why would you operate your initial private cloud projects blindly when such tools are available?
Terraform
You could also write a whole article or book on Terraform. Terraform is about reproducible infrastructure as code. How does this fit with the technology components discussed so far? On the one hand, Terraform complements our collected capabilities for a private cloud to make the abilities, services, and runtimes well-integrated and automated in public cloud offerings. Anyone pursuing a multi-cloud strategy need not only have a platform that fits in with many clouds. You also have to think about how to work with the services of these clouds without having to do everything over “by hand”.
On the other hand, unless you are working for a recently launched startup, you will surely find that your IT today is not consistently built according to a cloud-native architecture. There are applications and components that are best handled as a group of VMs. There are even applications that have real bare-metal compute or storage requirements. In the future, however, you may like to integrate them into your CI/CD and your concepts for your private cloud. Voilà: Terraform, at your service. There are also vendors who integrate Terraform with Helm Charts, so that not only the Docker world but also everything that can be achieved with Terraform, can be included transparently in one chart. So, you should start working with Terraform right away.
All together now!
What do we get if we can integrate and use this complete technology stack? It provides a private cloud that not only takes care of the initial steps, but actual, hard requirements for serious, strategic, and productive use on a larger scale.
What about public clouds?
Everything we’ve discussed here is relevant to both your private cloud and most popular public clouds. If your provider is not there yet, then you’re just better prepared for the future of an open standards-based cloud than this cloud vendor. But experience has shown that such vendors soon follow suit when the market pushes them, even the biggest ones.
This article is admittedly a roller coaster ride along the learning curve. If you were able to follow it, you can look forward to a real trip and take action. It’s time to act.
The post Architectural learning curve for the private cloud appeared first on JAXenter.
Source : JAXenter
