My Tech Journey from the Mainframe to the Cloud
My tech journey from the mainframe to the cloud has been an interesting one. I certainly expected I’d be working in Java fresh out of college, though it was surprising how I got there. Specifically, by taking a brief detour to the land of the mainframe.
While unexpected, it was a great introduction to the enterprise and the sheer enormity business domain could be. Ultimately it proved beneficial as a much needed reality check for the career I was embarking upon.
The Mainframe
My tech journey from the mainframe to the cloud began with wrangling COBOL for a large insurance company. There’s nothing quite like your first S0C7 and receiving a 500 page print out of the abend the next day.
The tech was your standard mainframe fare of COBOL, JCL, DB2, IMS, and Casegen. The sheer size of some of the COBOL programs was incredible! It was common to see hundreds of thousands of lines of code in a single program.
It was a far cry from implementing a bubble sort in Java 1 in college. The ISPF editor is still probably my favorite I’ve ever worked with, sorry vi.
Enterprise Java, Pre-Frameworks
After a quick couple years on the mainframe I started my enterprise Java career. They were simpler times. So simple in fact that we used little more than the raw JDK!
Struts had just come out, but that was a little too unproven for a cautious insurance company. And so we wrote all our Servlets, JSPs, and JDBC calls the hard way.
The real fun began with the IBM tool suite as things were a bit less ergonomic in those days. The main culprits were WebSphere, VisualAge for Java, and Rational ClearCase.
I still have no idea how ClearCase works(or didn’t work) and moreover how it passed itself off as a VCS for as long as it did. It was a valiant effort in the early days at least.
EJB World
I feel like I should have to write a pointless interface before beginning this section. The transition to the EJB paradigm was the beginning of the modern era of Java development in my mind. The era in which framework choices are one of the biggest decisions in an application’s life cycle.
Mercifully I had little exposure to pre-EJB 3.0 code bases. That is aside from cruft left over from EJB 2 to 3 porting efforts. If you can get past the boilerplate with EJBs, it wasn’t a terrible approach for the monolith world.
Humans cannot live by EJB alone though. JSF to the rescue! Err…in hindsight I should have waited for a different rescuer. JavaServer Faces was interesting to work with, I’ll say that much. It made some things work pretty easily and obfuscated many many other things.
JBoss Seam was another common framework to be found in the EJB/JSF ecosystem. Seam wove together the two unruly beasts into a monster beast! Though a more manageable beast than EJB and JSF would have been without it to be fair.
Spring World
The transition from the EJB world to Spring was pretty easy. I guess when you’re used to rubbing two sticks together to make fire, switching to matches is trivial.
The Spring MVC and Spring Data projects in particular were revelations. The simplicity in which we can accomplish things in the Spring ecosystem still amazes me. It’s easy to see why Spring has taken over enterprise Java and is leading the way towards the next revolution.
Cloud Native Java
Finally, my tech journey from the mainframe to the cloud brings us here. I’m still very much on the learning path when it comes to cloud native Java development. However, it’s been by far the most interesting and fun path on my long and winding road.
The enterprise market’s move to cloud native development is still a work in progress. At its core is the shift away from the monolith and towards a microservices architecture. A primary reason for this being to take advantage of the elastic scaling offered by the major cloud providers.
Working with Spring Boot and Spring Cloud have been the latest epiphanies spearheaded by Pivotal and the numerous Spring teams. The ease in which we can create new Spring Boot apps with sensible defaults via Spring Initializer is extraordinary!
It’s now entirely doable to stand up a functional API in a matter of minutes or hours. Compare that with trying to accomplish the same via JavaEE or an EJB/JSF app and it’s really no contest. Even if you’re not creating microservices, the Spring Boot project offers an immense improvement in developer experience.
Add in the docker containerization piece and it’s very easy to create applications ready for a cloud native deployment. As a developer it’s become extremely accessible to build microservices with Spring Boot, throw them in docker containers, and have them ready for a PaaS.
It will be interesting to see how broadly the enterprise shifts to cloud native development in the coming years. Will the majority of applications be moved away from monoliths? Will the microservices approach be reeled back in to a certain set of use cases? We’ll all have to stay tuned to find out.