HERE IS THE LINK TO THE POST:
CategoryDevOps
Surprisingly my 4-year-old blog post is still on Google #1 Page in organic search, doesn’t it deserve an update? Just updated with minor changes:
- Windows container support
- Forrester report update
Here is the latest version:
I would like to share my story about how my Blogpost Openshift vs Rancher gone viral, which is:
- On the top page when you search Openshift vs Rancher on Google (The first two, rancher.com and kloia.com both pointing to my comparison)
- Viewed more than 250.000 times
- Several comments from the readers
- Republished by the vendor itself
- Translated by several consultancies in different countries
As kloia, our engineering team focus became dominantly Kubernetes for the platform projects, where OpenShift was a dominant player especially after the acquisition of IBM. We have been implementing OpenShift in one of our major Enterprise customer. Since we are an engineering company, our consultants became frustrated with OpenShift with the following feedbacks:
- OpenShift has its own way of doing things, no CNCF
- No/less engineering, more operator mindset
- Major problems during version upgrades
- Vendor-lock
As an engineering-driven company, (Decisions are given by the engineering team, rather than Sales) we stopped working with RedHat, although we invested a lot with certifications and time…
Meanwhile, we began also experimenting with Rancher in several projects and I decided to make such an honest comparison by the end of 2019 based on
- Our engineering team’s feedback
- My own experience
- Several customer feedback
- Technical evidence
My intention was to reveal the realities, as an engineer who has been in the “Pledge to Professionalism” ceremony during my graduation:)
- I gathered data from anyone who can contribute: internal, external
- I interviewed several professionals: The ones using OpenShift, the ones using Rancher…
Based on all those data, I began to write an honest comparison.
There have been major debates around that post on social media and also in the comments of the post (I published all comments regardless of the positive or negative views, except the ones which have annoying language)
In a conclusion, I think the honesty of the comparison and maybe the reason I expressed how the engineering mindset professionals feel working with OpenShift made the success of that blogpost. It was not intentional, all happened organically!
During the pandemic, many companies have gone remote, while many of them struggling with it as their processes are not remote-complaint.
In Kloia, we were already Remote even before the pandemic.
I tried to explain that Remote does not necessarily mean Home and some aspects that we find important for this transition:
https://www.kloia.com/blog/remote-is-not-home
Recently i had to dig into a JVM thead wait/blocking/locking troubleshooting and i decided to write down my notes just for future reference for myself and for you!:)
Pre requirements to be known:
1. JVM Memory Space: This is divided to 3 following parts:
1.a Native Heap/Code Cache:
– Byte Code for JIT
– Native code which are already converted from Byte Code
– Mmap(Memory Map) files
1.b PermGen/Metaspace: Beginning from Java8, this area has no upper limit in order to avoid OutOfMemory errors. Operating System will use SWAP area(Virtual Memory) if the usafe goes beyond Physical Memory.
1.b.i. Size: This is defined my XX parameter
1.b.ii. Heap Structure: The following are stored under Metaspace:
- Class Definitions Metadata: Class Name, Object Arrays, Internal Object used by JVM, optimization information
- Static Member Variables (Variable itself / Object Reference)
1.c Heap: All runtime created stateless&stateful objects, app data, caches are stored in Heap.
1.c.i. Heap Size: Heap size is defined by two parameters:
- Xms(Initial Memory Allocation)
- Xmx(Maximum Memory Allocation)
1.c.ii. Heap Structure: Heap is divided into following spaces:
-
Young: Divided into 2 parts:
- Eden: First space used when the object is created.
- Survival: The objects which are survived from GC(Garbage Collection) are stored on so called S0/S1
- Tenured/OldGen: Objects reacted to max tenured threshold are moved to this space
Here is the model as a schema:
2. Footprint Requirement: This can be calculated considering the following formula:
- Number of ear, jar, war files that the single JVM process will handle
- Number of Java classes to be loaded during runtime
- Data cache(file, DB …) footprint
- Number of threads that are allowed to be created
Usually heap size 3-4 GB. is a starting point….
3. GC(Garbage Collection): Minimizing the GC frequency is a key factor for performance. Concurrent users and requests generate JVM GC HeartBeat. The frequency should be monitored.
4. Young vs Tenured: The typical ratio is 1/3, for example if you have 4 GB. Heap, 1GB for Young, 3GB for Tenured is expected. But this is totally depent to your business rules and traffic patterns.
5. Thread Dump Analyzer: There are various tools that you can use, the ones that i prefer are:
- https://spotify.github.io/threaddump-analyzer/
- http://fastthread.io/
Use XX:+HeapDumpOnOutOfMemoryError in order to create the Heap Dump in case of OutofMemory.
Here are the most popular focus areas that should be analyzed:
- Memory Leak
- Too many open files
- CPU usage
- Deadlocks
- ClassNotFoundException
- NoClassDefFoundError
As a last experience, there is an intersting jar which makes fullGC every 300 sec.:
https://github.com/jelastic-jps/payara/tree/master/payara-micro-cluster
That can be considered for non performance required applications….
Google recently announced that, Chrome will alert “NOT SECURE” for the websites not running under HTTPS:
Starting October 2017, Chrome (version 62) will show a “NOT SECURE” warning when users enter text in a form on an HTTP page, and for all HTTP pages in Incognito mode.
In case you have a WordPress site, there are 2 main ways to do that:
1- Converting WordPress to HTTPS mode:
1-a: Change the site URL: The siteurl can only be changed by command line. Find the wp-config.php and update it.
1-b: Change the existing http links: Go to DB and update the links. Beside in case there are plugins which inject their code seperately, you need find all. This is very painful!
1-c: Create a SSL certificate and verify it on a certificate authority.
2- Keeping WordPress a usual and use CloudFlare:
2-a Force HTTPS
2-b Enable HTTPS Rewrite: This is the crucial point. By that, you do not need to edit WordPress http links, as CloudFlare will be replacing them on the fly! (In case you are not under HSTS, it will not replace image links)
2-c Now you should see that links except images are not converted on the fly. Go to https://hstspreload.org and register your domain for HSTS.
**** Be careful! All subdomains and subsubdomains from now on should work under https! ****
So check all your DNS records. With Coudflare, you are lucky, if traffic passes via CloudFlare, it will a common SSL certificate
Here is my latest kloia blog post:
https://blog.kloia.com/rancher-on-google-cloud-with-cloud-sql-as-db-4775326f7bab
© 2024 Derya (Dorian) Sezen
Theme by Anders Norén — Up ↑