Avenga’s response to the war on Ukraine: Business Continuity and Humanitarian Aid
Director of Avenga Labs
Table of content
The news everywhere is dominated by the war – Russian aggression against Ukraine, and while our hearts are with our Ukrainian colleagues, their families, and the millions of refugees, I’d like to focus our minds for a moment on the technology news.
Despite a 1.18 version number, this is the biggest update ever to the Go language. We are active fans of the Go language (Golang), which is the foundation for many of our Avenga products.
The star of the show is the addition of generics to Golang. It has been discussed for years, there are pros and cons, people supporting it and those against it.
Generics, which is well known from other languages (C++, Java, C#, Python, etc.), finally has become part of Go. Generics enables better language expressibility, better dealings with various types, and performs generic operations on collections of data. It makes code more compact and reusable, but at the expense of reduced code readability and performance.
Is it a sign that the very slim Go is going to get bigger and bigger, and ultimately become a bloated language like many of the others before it? I don’t think so, as the Go community values language simplicity and is not focused on copying features known from other languages, because that would invalidate the benefits of Go as a faster and lighter alternative.
Fuzzing as a built-in feature is, on the other hand, a revolutionary change and Go is the first major language to adopt it in its default toolchain. Fuzzing is an advanced testing technique that hits your code with random data to discover vulnerabilities (such as buffer overflows, denial of service, and cross-site scripting) and component crashing bugs.
Test data is generated automatically by the framework so it also reduces the amount of manual labor required to create tests.
Go uses modules to group components together, but now there’s an improvement that makes it easier to work with multiple modules, which are called workspaces.
This new version promises an up to 20% better performance due to the compiler optimization techniques. Go was fast already and now it’s even faster. These kinds of improvements are always welcome and directly translate into business benefits.
There are other changes, but the key point here is that Go is becoming even more attractive to both new and experienced developers. It’s not expected to become the number one language anytime soon, however, changes like this are going to help it climb higher in the language popularity rankings.
Speaking of the leading enterprise languages… let’s turn our attention to Java.
The reserved keywords in the mainstream languages have remained unchanged for many, many years. This is done purposefully to reduce the burden of upgrading business applications to newer versions.
Finalize has been with us for more than twenty years, more than 24 to be exact.
Why is it deprecated in Java 18 and marked to be removed entirely later?
Finalize is a standard method from the Object class which is executed just before the given object instance is removed from the memory by garbage collection. This is the last chance to release unmanaged resources such as network connections, database connections, file handles, etc.
Seems a very good idea, but there are (soon “were”) multiple problems with this pattern. Finalize may never run, it may run too early/prematurely, it can resurrect other dead classes and objects, may result in hard to reproduce errors, and… many more issues.
Java represents more than 80% of the enterprise application landscape so a change like this is a trigger to plan, prepare and execute changes in all the components that actively use finalize keywords. There are already ideas and patterns on how to replace finalize and as well as discussions about which situation and/or which method is the optimal one.
Is there an IT life without Kubernetes? Impossible?
Whenever I look and with whomever I talk, there’s always a Kubernetes cluster, or maybe a Kubeflow, but usually Kubernetes in the cloud. From my curious albeit limited point of view, it seems to be everywhere.
What do the numbers say about it?
Cloud-Native Foundation is all about building cloud-agnostic infrastructures and digital solutions, and recently they published the results of their survey.
First of all, 96% of the corporations are “either using or evaluating Kubernetes”, and possibly the other 4% did not understand the question? Seriously, it is total domination either way.
Using Kubernetes hosted in the cloud dominates the landscape (79%) with the usual leaders (EU, NA), such as Amazon, Microsoft, and Google, but still a significantly large portion of other cloud vendors.
The percentage of companies deploying local Kubernetes clusters locally is eaten up by public cloud vendors.
It looks like Kubernetes is becoming a Linux of the 2020s, a default runtime for … anything software and data related.
There’s still a fast growth of the serverless paradigm and room for future growth. In the case of Kubernetes, we’ve already reached total domination or saturation.
The question is how to do Kubernetes well, in the particular cloud, for the particular purpose, and there’s definitely no “if” dilemma anymore.
Despite the domination of Google Chrome as the primary choice for almost three-quarters of the users, there are other browsers in use. Let’s not forget about the hundreds of millions of Safari users (including myself).
Browser incompatibility is not good for web app users, web developers, designers, and also browser vendors.
Another attempt to remedy the situation is Interop 2022.
This is a benchmark created jointly (yes!) by Apple, Google, Microsoft, and Mozilla. Its goal is to help to reduce incompatibility between browsers in 15 areas specified by web developers as the most important ones.
A very good move from the browser vendors, and I’m keeping my fingers crossed for the improved browsers compatibility. BTW, Apple, please do wake up!
As I mentioned before in Kubernetes adoption news, Kubernetes is virtually everywhere, and so are containers. And, container runtimes are … software, and all the software tends to suffer from security vulnerabilities.
This time it is more serious than usual and applies to all the users of clusters that are using CRI-O runtime. It’s called cr8escape and enables attackers to completely take over entire clusters, which is a classical privilege escalation vulnerability. This is serious, for less technologically advanced readers, it’s like a virus at the heart of Kubernetes and it needs to be remedied ASAP.
All developers and web designers are required to specify the so-called ALT tag for the images to enable screen readers to read the description of the image for people visually impaired or those having trouble seeing correctly.
Unfortunately, this is not always the case, despite the fact that the tag has been around for decades. It’s a shame, but the reality is far from perfect…
Screen readers often don’t help people to figure out what an image shows, but now Microsoft has decided to generate image labels for screen readers automatically. How? By recognizing image content using machine learning and creating text descriptions.
This option is enabled in the accessibility configuration within the browser.
Thank you Microsoft, let the others follow your lead!
The following weeks will mark something special for all internet users, as Chrome, Edge, and Firefox will all reach version number 100! (One hundred).
In other words, users are expected to celebrate, developers … not so much or maybe later.
Until next time!