Sunday, March 11, 2018

My take on terraform #terraform

Disclaimer - don't shoot the pianist

It's been some time since I wanted to write this post. For those that are going to read it, I need to say that a) I hate the term DevOPs as a way to 'label' engineers b) I'm a software developer  meaning that I am the type of guy who really enjoys high-level languages like Java/ Kotlin etc and has been following DevOps principles per occasion or workplace, but being honest I did not have a solid Ops/Admin background. In other words, not all shops out there do or encourage DevOps as a engineering culture, so it really depends if you re going to experience it or not.

It is evident though, that through time in many companies, the typical developer stereotype is changing, a developer is asked to engage more often with then overall release life cycle of software rather than limiting himself/herself to only writing the code and then delegating to others to configure, ship, deploy and maintain software in production.

IMHO there is no better person to bring the code alive and take care of it, from the person who wrote it and knows its strengths and weaknesses. So please don't shoot the pianist in case you don't agree with my views or my perception of things.


My experience with Terraform

I started seriously working with terraform 2 years ago. At first, it was like oh ok I don't know what I am doing, I don't understand what is going on.  Then I progressed on copy-paste-ing this template run it and see what is happening, then I was like 'OK I am going to copy paste someone else's thing modify it a bit and support it'. Now I am able to follow through all the templates, modules and in general kind of find my way around most of the production deployments.

So definitely there is a learning curve, if you happen to work in a place that Terraform is being adopted the higher the chances are that you are going to step up your game once you seriously invest some time. It's not rocket science, after all from a user's perspective,  its some simple notation, where you express how you want your cloud infrastructure to look like. Example, terraform please create for me a VM, some networking, a load balancer, some access right on the VM and please initialize them. Boom!

Having already lots of day to day experience with kubernetes and being very confidend with Kubernetes deployment descriptors and tools like Helm, Terraform feels familiar in its core. I would argue that terraform is very easy to use, the only thing you need is a couple of good resources, some reading and your personal cloud account (e.g AWS). It is not a corporate-only tool, neither requires some magic heavy infrastructure.

Just a command line utility and a couple of API keys to access your cloud.


Books and resources

Through this ongoing journey, I used the following resources :
  1. Terraform Up And Running
  2. A comprehensive guide to Terraform by the GruntWork guys , here.  
  3. The Terraform book
  4. The official Terraform documentation - but is better if you start with one of the books and then take over the official documentation (IMHO). At least this is what I did.
  5. Terraform videos / short courses on Plurarsight.
I would highly suggest you start with Terraform Up and Running and them move to 'The Terraform Book'. I kind of did it the opposite way, which I think it was wrong, so I high recommend you go through the above resources with that order.


So what is Terraform? (for newbies)

Its a utility that you can download on your machine (I used brew) or use it as a docker container, which will enable you to change and shape your cloud infrastructure. This utility is fed with a set of  files (deployment descriptors) where you will describe what things you want to run and instantiate on your cloud  (e.g AWS or google cloud).  E.g spin vms, databases, s3 buckets, etc.

Terraform will read these files and translate them to actual API calls to the cloud provider, will also do the dirty job instantiating the resources for you with the correct order and 'save' the state, meaning save somewhere what is already deployed so that next time that you run it can check what is already deployed and peform an more fine grained update (like a diff).

Some might argue, why you want to do that, since you can login to the console of your cloud provider and eventually perform all these actions. Well for sure you can do that but
  • Manual changes to your cloud infrastructure especially as it gets bigger and complex are error prone
  • Manual means - manual labor - which means that you need to do the same things all over again - where you could just automate and script them.
  • Every time you do a change you need to make sure that you dont break or alter something else, and we all know how complex the settings are in many cloud providers. 
  • You dont have continuous deployment semantics. Repeatable builds and configuration.
  • Support more than one users, that try to 'mutate' the state, e.g development teams or organizations.


Should I invest time learning terraform as a skill?

Definitely yes if you ask me. As I said my background is not Ops so mastering the details of different cloud providers proves to be a full time job for many people. In my mind whatever tool or technology helps to reduce this learning curve is a good thing. Terraform abstracts in a way your interaction with the cloud provider. It does not abstract the cloud provider, meaning that if I write some terraform for AWS and I want to do more or less the same things for Google cloud, you will end up writting something a bit different, since cloud providers are different. But at least you will have a common way of interacting with the different clouds, and you will develop skills on how to quickly leverage and re-use all your terraform resources. Instead of becoming a master on the AWS cloud console and the google Cloud console, you will be a master on writting template files that instruct terraform to perform stuff for you.


Terraform is not only about AWS

Since AWS holds a large portion of the market ( 50/60%) meaning is the no1 cloud of choise for individuals and companies, many people assume that Terraform is somewhat AWS specific, which is of course not true. Terraform has this thing called providers, which is actually an abstraction for many different clouds or services. So yes the most commonly used is AWS but you will find an extensive list of different services that can be 'terraformed' . Lately I am spending lots of time with the Fastly Provider, fastly being a CDN! 


If you know terraform you dont become a cloud expert! A small trap.

Well it is not  a trap of Terraform, but no matter if you master the way terraform works and you quickly find yourself 'terraforming all the things', using its powerful template engine and all the nice utilities and resources, you must really know what you are doing.

In plain words, if you are good at terrraform does not mean that suddenly you became an AWS or Google Cloud expert! Becoming an expert on the different clouds, is a full time job and requires time and effort. Thats why we have AWS experts, Google cloud experts etc. Maybe more modern clouds, e.g the Google cloud abstract more things compared to traditional (older clouds) like AWS, but still at some point you are going to end up, searching or having to master the details. 

I have to admint my journey on mastering thenAWS cloud is still on going and I feel I have a looong way, but this is part of the process I guess!

Sunday, October 29, 2017

one slack to rule them all

It seems that over the years the services and applications I tend to use, for chatting and keeping in touch with friends and family change. Just some minutes ago, I  removed from my MacOSX Dock my beloved 'Adium' which served me well for far too many years, being my main IM app for many services like MSN, Gtalk, Yahoo. Of course it is not about Adium, Adium is just the medium but is all about the services.

In the past few years, I can see that my somewhat vibrant contanct list on MSN and Gtalk has faded out, most of my friends (or even me) are not using them a lot and we have moved to either Facebook or Slack. 

The latter seems to be the killer for all the above for me. For regular chat with close friends, we have been creating private channels. I have to admit this non -corp use of slack is kind of handy. I still hate facebook chat, but since almost everybody is in there, you end up using their service.

I kind of miss the gtalk and msn days...though.

Sunday, October 15, 2017


Χάζευα κάτι στο twitter, σχετικό με agile, scrum και λοιπές μεθοδολογίες και θεωρίες. Θυμήθηκα πριν πολλά χρόνια, στην Ελλάδα σε μια εταιρία που δούλευα, ειχα βρεθεί κάτι σαν lead μιας μικρή ομάδας για ένα project, τότε ήταν οι εποχές του agile manifesto, και του scrum all the things.

Τα διάβαζα τότε στο internet και έλεγα , κοίτα ρε φίλε φοβερά πράγματα. Μιας και είχα αυτή την ελευθερία, λέω παιδιά απο αύριο να πειραματιστούμε να κάνουμε μερικά από όσα έλεγε το scrum guide ή το agile manifesto, να πειραματιστούμε ρε παίδι μου, να κάνουμε και daily scrum ή stand-up έτσι informal.

Και το κάναμε 1-2 φορές και μετά σταματήσαμε. Θα μου πεις φυσικά ρε φίλε αφού δεν είχατε την κατάλληλη εκπαιδευση, διαβάσατε εκεί σαν βλαχαδερά 5 άρθρα και νομίζατε ότι θα το κάνετε. Για κάποιο καιρό το είχα πιστέψει, και έλεγα να πάω να κάνω official training δεν μπορεί να είμαστε έτσι πρόχεροι. Να γίνουμε scrum master. Γιατί πάντα έχω αυτό το ενοχικό μέσα μου, μήπως δεν το έκανα σωστά...

Μετα τα χρόνια πέρασαν και τώρα γελάω. Γελάω και με αυτά που πίστευα, γιατί μετά από εμάς ήρθα οι 'expert' να μας διδάξουν ή να εφαρμόσουν agile, και απέτυχαν. Φυσικά γιατί δεν υπάρχει κανένα λόγος να έχεις μεθολογία όταν έχεις προ-συμφωνήσει με τον πελάτη functionality με το κιλό - με την ώρα και με έναν στρατό από micro-managers δίπλα σου (ΓΕΙΑ ΣΟΥ ΚΛΑΣΙΚΕ ΕΛΛΗΝΑ ΜΑΝΑΤΖΕΡ).

Για να μην αναθεματίζω βέβαια την μικρή και ανώριμη ελληνική αγορά εξάλλου τόσα χρόνια εκεί έβγαζα το ψωμί μου, και τώρα σε πιο οργανωμένες εταιρίες έξω, γελάω ακόμα με όλες αυτές τις μεθοδολογίες που τελικά στην καλύτερη των περιπτώσεων θα βρεθείς να δουλεύεις με έξυπνους ανθρώπους που έχουν πιάσει το νόημα και θα σου πουν `κοιτα μεγάλε τα μισά είναι απλά να έχουμε να λέμε, θα οργανωθούμε έτσι απλά και πρακτικά θα εφαρμόσουμε όσα πραγματικά εχουν να προσφέρουν και να λύσουν προβλήματα και τα άλλα θα τα ξεχάσουμε`. Στην χερότερη ή μάλλον συνήθως θα βρεθείς να δουλεύεις με παπαγάλους ή πλασιέ του συστήματος που δεν εχουν την παραμικρή ιδεά για το πως θα φτάσουν από το σημείο Α στο σημείο Β. Θα σέρνουν εσένα και την ομάδα σου σε μια ατέρμονη γραφειοκρατία που διαλύει την παραγωγικότητα και δεν βοηθάει σε τίποτα.

Το μόνο που μετράει τελικά και ίσως μεγάλωσα για να το καταλάβω είναι πως φτάσεις από το σημείο Α στο Β και συνήθως αυτό το λένε 'get shit done' όλα τα άλλα είναι .... απλά θεωρίες. 

Sunday, September 10, 2017

Μια non politically correct απόψη για το 'Adults in the room' του Γ.Βαρουφάκη

Στο γυρισμό από τις διακοπές μας στην Ελλάδα, αγόρασα στο αεροδρόμιο το πιο πρόσφατο βιβλίο του Γ.Φαρουφάκη με τίτλο 'Adults in the room'. Δεν θα το κρύψω, το αγόρασα από νεύρο, ίσως μια παράξενη, άρρωστη ανάγκη να διαβάσω με λεπτομέρειες όλα έζησα κι εγώ μαζί με τους υπόλοιπους Έλληνες εκείνη την περίοδο. Ίσως ο όρος έζησα να είναι μην τόσο σωστός, μάλλον πρέπει να γράψω,  όλα όσα έπραττε η τότε κυβέρνηση ΣΥΡΙΖΑ και εμείς ως πολίτες είχαμε μια κάποια ενημέρωση από τα Μ.Μ.Ε και φυσικά τα λουστήκαμε στην πορεία.

Disclaimer: (για σου γλιτώσω χρόνο και μην ανεβάσεις πίεση χωρίς λόγο). Θεωρώ την κυβέρνηση ΣΥΡΙΖΑ την χειρότερη των τελευταίων δεκαετιών, τόσο για τα αποτελέσματα της ως κυβέρνηση αλλά πιο πολύ για την ποιότητα και το επίπεδo των στελεχών κυβερνώντων, με πρώτο και καλύτερο των πρωθυπουργό. Μια αστεία φιγούρα που εν έτη 2017 δεν μπορεί ακόμα να μιλήσει Αγγλικά. Λυπάμαι πολύ που αρκετός κόσμος που ξέρω στιγμιαία πίστεψε όλα τα αλλοπρόσαλλα που έταζε η κυβέρνηση αυτή και λυπάμαι πιο πολύ που ακόμα υπάρχουν συμπατριώτες μου που τους υποστηρίζουν.

Μου πήρε 2 πήγαινε έλα στην Ελλάδα για να το ολοκληρώσω, εκμεταλλευόμενος τις 3ωρες πτήσεις. Μετανάστης πια, πήγαινε έλα στην Ελλάδα, στο αεροπλάνο τι καλύτερο απ' το να διαβάζεις τι έγινε όσο ήσουν στην Ελλάδα λίγο πριν πάρεις την βαλίτσα σου και αποχαιρετήσεις. Δεν ήταν το πρώτο βιβλίο του Γ. Φαρουφάκη που διαβάζω, άρα δεν μου είναι άγνωστος, ούτε και οι απόψεις του περί παγκόσμιας οικονομίας ή περί του ευρώ-μηχανισμού. Θα τολμήσω να πω ότι 'θεωρητικά' βρίσκω κάποιες θέσεις του εύστοχες και ρεαλιστικές.

Το βιβλίο μου άρεσε, ταπεινή μου άποψη μου είναι ότι, τα πράγματα έγιναν ακριβώς όπως τα γράφει, με άλλα λόγια τον πιστεύω. Νομίζω ότι και η εξέλιξη των πραγμάτων έδειξε ότι δεν υπήρξαν πολλές ενστάσεις για την εξιστόρηση των γεγονότων αλλά και των πραγματικών διαλόγων. Έπιασα τον εαυτό μου 2-3 φορές να γελάει με αυτά που διάβαζε και μετά να αναρωτιέμαι αν τελικά έπρεπε να γελάω η να κλαίω για όλα εκείνα μετά από τα γεγονότα που διάβαζα εκείνη την στιγμή.

Για να μην σε κουράσω αυτά που μου έκαναν εντύπωση.
  1. Είναι φανερό ότι ο Βαρουφάκης ήταν ο πιο 'γνωστικός' και μάλλον ο μόνος άνθρωπος με κάποιο επίπεδο σε σχέση με τους αριστερούς κατα- φαντασία,  ΠΑΣΟΚΟΥΣ ..τρίτου επιπέδου, και μισότρελους  του ΣΥΡΙΖΑ.
  2. Δεν μπόρεσα να καταλάβω πως αφού δείχνει σημάδια λογικής, δεν μπορούσε να καταλάβει ότι όλα όσα πρότεινε για παράλληλα συστήματα και πίεση προς τους Ευρωπαίους ήταν 100% άτοπα εκείνη την περίοδο. Με άλλα λόγια, οι τακτικές και ιδέες που είχε θα μπορούσαν ίσως να χρησιμοποιηθούν την περίοδο (με το ανάλογο ρίσκο φυσικά) που ο Γ.Παπανδρέου υπέγραψε το πρώτο μνημόνιο - και όχι μετά από 2. Άρα καταλαβαίνω ότι δεν μπορούσε να αντιληφθεί την ωμή και δύσκολη πολιτική και οικονομική θέση της χώρας. Ή για να το πω πιο απλά, το παιχνίδι είχε ήδη χαθεί για την χώρα μας γιατί έμπλεξε;
  3. Δεν μπορώ να κατανοήσω αν ήταν ενθουσιασμός, αθωότητα ή απλά βλακεία αυτό το αίσθημα που κατέβαλε τον ίδιο και πολλούς ΄ήρωες' του βιβλιου, περί εθνική υποχρέωσης, να σώσουμε την χώρα, αυτός ο πατριωτισμός. Θα ομολογήσω από μια persona σαν τον Βαρουφάκη ως αναγνώστης θα το πίστευα (με καλή διάθεση) αλλά για πολλούς πολιτικάντηδες ήρωες του, με έκανε να γελάω! Μουρμούριζα καθώς διάβαζα, ' ρε αυτοί οι..μ..κες το είχαν πιστέψει ότι  ήταν εθνοσωτήρες'...ποιοι αυτοί!   
  4. Στα πρώτα κεφάλαια γράφει σε ένα σημείο, ότι η αρχική του ιδέα ήταν να πολιτευτεί με το Ποτάμι. Θεωρώ ότι έπρεπε να μείνει σε αυτή την αρχική πρόθεση, η ιστορία έδειξε ότι έγινε ένα εξιλαστήριο θύμα ενός πολύ κακού επιπέδου πολιτικού θιάσου.
  5. Σχεδόν - πήγα να πετάξω βιβλίο, στην σελίδα 457 αν δεν κάνω λάθος. Ο τρόπος που ο Βαρουφάκης μιλάει για τον πρωθυπουργό είναι ανεξήγητος ακόμα και όταν τον έχει αδειάσει πολλές φορές. Σε εκείνο το σημείο χάνει μεγάλο ποσοστό από την σχετική κατανόηση που έδειχνα στον ίδιο! Μουρμούρισα ' μα δεν μπορεί να είσαι τόσο τυφλός ή είσαι μ..ας!' Σαν εκείνες τις στιγμές που η γιαγιά στο χωριό βλέπει την αγαπημένη της σαπουνόπερα και μιλάει στους ηθοποιούς σαν παρατηρητής, 'μην τον πιστεύεις κόρη μου σε απατάει με την Τζίνα, μην το κάνεις παιδί μου'.
  6. Θεωρώ ότι ο Βαρουφάκης και ο θίασος την τωρινής κυβέρνησης ήταν ένας ο χειρότερος συνδυασμός, το χειρότερο κοκτέιλ ανθρώπων που έμελε να διαχειριστούν μια από τις πολλές κρίσεις την σύγχρονης ιστορίας -και μαζί απέτυχαν παταγωδώς. 
  7. Νομίζω ότι απλά εκμεταλλεύτηκαν, τον όποιο ενθουσιασμό του και πραγματική θέληση του να βοηθήσει ακόμα και αν ο ίδιος δεν είχε αντιληφθεί το πολιτικό τοπίο. Αυτό ήταν και το μεγαλύτερο του λάθος - δεν είχε αντίληψη της κατάστασης.
  8. Το βιβλίο τελειώνει ...λίγους μήνες πριν αποφασίσουμε να φύγουμε από την Ελλάδα και τώρα με λύπη  διαβάζω σε πτήσεις πέρα δώθε, αλλά και ανακούφιση ότι πια δεν με ακουμπούν (τόσο), επιλογές και αποφάσεις αυτού το θιάσου.
Αξίζει να το διαβάσει κανείς το βιβλίο; Θα τολμήσω να πω ΝΑΙ! Μάλιστα προτείνω  σε όσους το διαβάσουν και μένουν ακόμα στην Ελλάδα, να το πάρουν μαζί τους όταν θα ξαναμπούν στο παραβάν των εκλογών όταν και όποτε γίνουν!

Sunday, June 25, 2017

my day to day Kubernetes command line tools & apps #kubernetes

The other day, I was chatting with my friend Stathis about command line tools that I use every day, extra to kubectl, operating on different kube clusters in production.


Command line tools


1. kubetail
Allows you to tail logs from one or more pods simultaneously. It is really handy since you only have to specify the pod name, and then it will automatically tail all the different instances you may have already deployed.

kubetail backend-api -n aNamespace

2. kubectx
If you do have access to more than one Kubernetes clusters (like me) then switching from one cluster to the other, especially when you do it very often, can be a bit boring or error prone. Kubectx, will actually parse your 'kube_config` and it will help you make the switch faster.

kubectx kube1_uk_prod
kubectx kube1_us_prod
kubectx -> lists all the available contexts

3. kubens
It is on the same bundle as kubectx and helps you switch easily through different namespaces that you may have within a cluster

kubens prod_uk
kubeks qa_us



1. kube-state-metrics
Kubernetes already uses `heapster` to gather stats and info about the state of the cluster, which is later fed to some of kubernetes components like autoscalers, to determine if the they need to initiate a pod up or down scale. Kube-state-metrics is an addition to what `heapster` provides, and it actually exposes additional (prometheus) metrics that can prove very handy if you are operating kube clusters in production. What I really like, is that once you spin the pod (one would suffice) then you can extract the provided metrics, through its Prometheus Endpoint. So if you are already using prometheus to scrape metrics from you deployments, kube-state-metrics is ready for business. You can check the various metrics provided by the app here.




1. Helm
This needs a separate blog post most probably, but I have slowly started moving away from vanilla kubernetes deployment descriptors and 80% of my deployments are now, packaged and configured as Helm charts. The main reason adopting helm was our need, to parameterize the deplooyments, and relying on bash based hacks (sed, or envsubst) was ok to start, but as soon as the number of deployments grew along with their complexity, the parameterization of all of them was really pain. I will come back with a separate post for sure about Helm and why I think is vey good idea, to start adopting it as soon as possible.

Saturday, May 20, 2017

Voxxed Days - Athens 2017 - short review #vdathens

Yesterday I had the pleasure to attend the very first Voxxed Days Athens. As I have written 6 months ago while attending Voxxed Days Thesalloniki, this was the day I've waiting for too many years, a  proper conference, with top class speakers on the main IT hub of Greece, Athens. Once again, congrats to Patroklos Papapetrou and the team around Voxxed Athens, at least for me they made a dream come true!

There is a always a catch for me, when I do attend conferences in Greece. Since I am away now, I don't get to see or get in touch with old colleagues and friends from the very first days of the Java Hellenic Use Group.  So when I am back and I get to see lots of them at once, I kind of spend most of time socializing rather than attending all the talks. This is exactly what happened, but I am very very happy, I got to see so many familiar faces, talk about past jobs, laugh about it , talk about our current state either abroad or in Greece and last but not least debate around the prospects of our country which continues it's spiral into economic recession.

Definitely things like VoxxedAthens, validate the the small IT sector in Greece, is still alive so there is hope. Of course many other things need to change until we can conclude that we have a shift on a better course. 

I am very pleased to see, that our small user group, (JHUG) is more active than ever, Markos, Thomas and Kostis are doing a great job and JHUG managed to organize 6 meetups within a year, this is crazy compared to the past. It seems that Greek companies  are nowadays more open to the idea of a ' meetup', they do indeed  want to attract talent (or whatever talent is left behind, since lots of people are now out of the country). I hope this support to dev communities to continue and get stronger rather than being an one off side effect of companies just trying to recruit for a certain period of time. A strong software development market, needs active and vibrant communities, software companies in the local market need to embrace on a regular base all them. Software developers are like flowers, the more incentives, opportunities or support you provide them, the more they grow and  they become better, they add skills and in the end they contribute to the business cause of the company they work for .

If you are really looking for a detailed review of most of the talks, (meaning more specifics, please head here and here . Markos and Spyros  provide a very comprehensive review of the event.

The venue was nice, but I do hope next year for a more tech talk friendly place. The rooms were large but the projector and screens a bit small to actually see the slides or the code presented from the back. Also lot's of noice occasionally from overlapping talks & people coming in and out. Latetly I have been addicted to the Devoxx way ,which means I expect that all the conferences will be on cinemas, where I can sit confortably, enjoy a huge screen where I can see the code and slides.

I am not going to go through the talks I attended, since I managed to save time for 4 of them. My 2 favorite though were :
  • You can do better with Kotlin
    • I am currently half way on reading 'Kotlin in Action' and I was really happen that I had the chance to meet and talk with one of co-authors, Svetlana Isakova. I am very positive towards Kotlin and i will continue to investigate way on eventually adopting or mixing it with Java, in any of my personal projects or maybe at work.
  • Taming the Dragon: Conquering non blocking code with RxJava
    RxJava is coming, through Java9, through Spring Reactive or other Reactor based frameworks. I really enjoyed this talk by Frank Lyarru. We need to make sure that we get our heads around the new concepts since I bet they will become mainstream soon enough.
Overall I am very happy, we need to support Voxxed Athens, and make sure it becomes a place we meet once every year!

Back to London :) after getting some sun and enjoying some nice cold freddo espresso!

Saturday, May 13, 2017

Some sort of confusion? Or uncessary noise ...on my Kotlin journey

Lately I try to level up my skills with Kotlin, mostly from the view point of a JVM backend developer. 

I really feel very motivated and enthusiastic, I think the language has the right balance to make me feel like home (I am a hardcore Java developer after all) but at the same time give me new skills. 

As I've said many times, when I first tried to Kotlin I thought it was like Java from the Future, with idioms or syntactic sugar of Java libraries like Lombok & Javaslang (vavr) etc.

Part of the learning process is to  to engage with the community, so I've already attended one Kotlin meetup, or try to talk with people that have adopted Kotlin in production.

There is one thing that frustrates me thought. I don't understand this kind of hate towards Java, more or less not justified, with statements like 'If you use Lombok you are not doing Java'. I am really confused what is happening here.

So I kind of reply, 'so if you use Lombok or if you use Spring, or any framework that does byte code manipulation or byte code infusion is not Java? '

Yes typically we have Java the language, as a set of keywords and principles but the actual internals of the JVM and the way you can leverage bytecode through the use of Java or any other language (Kotlin generates bytecode after all) is part of the game. If you are an application developer, you use libraries that provide more or less some kind of abstraction.

I consider myself a pragmatic application  (business) developer. I don't want to re-invent the wheel when I want to implement something simple, and in business software (more or less what the majority of people do) you don't want to do that. 

When I rely or use any framework, or any language, I should be aware of what I am using and what are the pros & cons of using. You should be aware on what Lombok is doing / generating for you behind the scenes, or how Spring or Hibernate, or EJB implementations, enhance your your POJO's so that get  for example transactional or  other context awareness. This is not something we don't know and suddenly we want to jump out of the ship because someone revealed a secret.

Is this 'dynamic' nature of these libraries not the right thing for you? You don't like the fact that all these libraries leverage the bytecode and mechanics of the JVM? This is just fine, and in some cases yes you better re-invent the wheel or do your custom thing.

But please people lets all relax a bit, and stop stating things that eventually don't add anything to the picture. Everyone has an opinion towards different programming languages and I respect that but at least when we want to push forward for a new thing, lets focus on all the nice things that are offered rather than doing completely unrelated bashing on stuff that I consider technicalities.

If you ask me, I am really excited with Kotlin, but I still enjoy Java8, and Lombok , javaslang, Spring Boot, JBoss Weld, Guava  or Wildfly Swarm, or LogBack, or AsyncHttpClient etc etc.

It is always better when you show case the power of Kotlin rather than talking about how Java sucks, which in many cases yes Java does not do well compared to other stuff, but is not that is the worst language on earth or its so outdated. When you try to sell something new- focus on it's strengths and less on the weaknesses of the thing that wants to replace!