Tom Purcell, a consultant and founding member of the Chariot Solutions team, has seen technology come and go. On our 20th anniversary in business, Tom gives us a humorous look back to the tools and technologies that came, went, and stayed since Chariot became a company in 2002.
Tom, how has development changed since 2002?
In 2002 the big thing was Java, J2EE and XML… Lots and lots of XML… tens of thousands of lines of XML.
But you needed an application server. Lots of them around: Oracle, Sybase and IBM all had one but BEA had one that was J2EE 1.3 compliant! (and lots of XML).
But wait, do you really need a big honking Application Server? There’s this new Spring thing. You can just run on Tomcat. And it’s free. Not only that, you still get lots of XML. LOTS.
But all this XML can’t be good. I was up till 4 in the morning looking for a missing ‘/>’.
But with Ruby on Rails… convention over configuration… you just put it where it’s supposed to be and you’re golden…
But… Oh, you want to support 10 users…
But, OSGI… Solves everything. Just rebuild all your jars and tell them about all your other jars and strictly adhere to defined interfaces and make sure you have them all lined up perfectly and it all works great.
But wait, you want to make a change? Just rebuild all your jars and tell them about all your other…
But you know what would really be cool? If we could get all these pockets of technology across the company to talk to each other. We could compose them into a super efficient, greater than the sum of its parts, reduced redundancy network of service in a Service Oriented Architecture… SOA.
But isn’t that just Enterprise Integration?
No! !@#$#!!! It’s SOA. It’s much better.
But now, we’ll need a framework to “orchestrate” messaging between these elements: ServiceMix? Weblogic Integration? Spring Integration? Mule?
Mule?
Yes, Mule.
But, wait. The real issue is we have this big monolithic application that takes forever to start. And if you change anything, you break 5 other things, and when you fix those 5 things, each fix breaks 5 more things, and when you…
But we could break things down into discrete units of responsibility so we can be more agile (in a modified agile way) thereby responding to the needs of the business in a more responsive way.
So we’ll break the monolith into small services… We’ll call them MicroServices and we’ll “orchestrate” messaging between these elements with: RabbitMQ? Kafka? REST (real REST this time, not that pseudo REST we did before)? SQS? ActiveMQ (What? Are you serious? That old thing?).
But wait, isn’t that SOA?
No, it’s MicroServices.
But it’s kinda like Enterprise Integration.
No! !@#$#!!! It’s MicroServices. It’s much better.
But wait… the CLOUD…
