My name is John Kramer. I'm an accomplished software engineer living in St. Louis, MO. I have a lovely wife and three beautiful children. When I'm not chasing my kids around, I am watching sports (Cardinals, Blues, and Packers), listening to music (jazz and prog rock are my favs), or writing code.
I am more experienced in backend development, but I do frontend development on occasion. I'm most experienced with JVM based development but Golang and Node.js with Typescript are good too. If you are really interested in what I've been up to professionally, check out my resume.
Two technologies really blew me away.
Containerization is a serious game changer. Micromanaging OS packages and compatibility in a repeatable way isn't fun (been there, done that). Provisioning racks of servers must be even worse (haven't done that). I'd prefer to let Amazon, Google, or Microsoft do both.
Rather, I'm thrilled to be able to stand up (for example) a simple Nginx server with a Dockerfile:
FROM openresty/openresty:alpine COPY nginx.conf /usr/local/openresty/nginx/conf/nginx.conf COPY index.html /usr/local/openresty/nginx/html/ CMD apk add curl CMD /usr/local/openresty/bin/openresty -g 'daemon off;'
...and a few other bits and bobs.
The HTTP protocol is stateless for a very good reason. Stateful protocols couple clients and consumers. That's okay if you only have a single server but every server should be able to serve any client.
But you can't build an entirely stateless application. Responses can't be a function only of inputs. Users want to be able to save videos and read emails not just compute cosines and solve systems of equations.
So we have a database on the backend. Great! We have a fixed place to store our state. Now all our servers can serve any request from any client.
So then we are we storing state in our servers? Why do we want to fool around with updating config files, executables, libraries, and packages on production servers?
We don't. And so, VMs solve that problem but containers are lighter weight and easier to use.
I have been coding in Java since last millenium. A number of things have made Java one of the most successful programming languages in history. Sun Microsystems promised that Java would be a game changer because it is Write Once Run Anywhere. Java's portability has helped it on the desktop and mobile markets, but it isn't as big a deal in backend services. It's reliability, flexibility, excellent JIT compilation, and enormous standard library, and even bigger package ecosystem are arguably more important.
But like your legacy monolithic system, Java feels a bit bolted together. Java didn't introduce functional features until Java 8. And then Sun bolted on streams and default interfaces. Java 8 also gave Optional us a way to handle nullability.
In 2011, JetBrains (whose IntelliJ Java IDE is top notch) introduced Kotlin to address some developer complaints about Java and have been improving it since then. It's like the new system that you role out because the legacy system is old and brittle and can't be changed for fear you'll break your customers. Greenfield development is always nice.
I had heard about Kotlin in the context of Android development (it's Google's recommended language) but hadn't used it. Then a few years ago, I tried using it to develop microservices. It has been such a delight. Its' functional features are much cleaner and more intuitive. Nullability and mutability are built in.
I have heard many organizations are hesitant to use Kotlin for backend development. They have legacy Java applications and don't want to rock the boat. But Kotlin is fully bytecode compatible. Multi-language projects are no problem.
Hiring is another reason that companies don't want to use Kotlin. There are a lot of backend Java developers out there and not as many who have experience with using Kotlin for backend services. This should be a non-issue. A good Java developer should be able to pick up Kotlin pretty easily. If they can't, then you don't want them writing code for you any way.