New Myths

8 July 2011

Building a Solid VM for Your Enterprise

As of the time of this writing, Oracle/Sun is about to release Java 7 – the seventh core release of the venerable development language. What’s interesting about Java is how many people use the underlying plumbing (the JVM – Java Virtual Machine) with a different programming language. Think about it, how many development ecosystems boast such a wide variety of languages from so many different sources1? Functional, late-binding – you name it, the JVM’s got it.

Thinking about the corollary between the JVM and enterprise infrastructure, one has to wonder if enterprise architects are putting as much thought into their infrastructure planning as Gosling and company put into designing the JVM. My suspicion is that they aren’t. Instead, what we more often see is the recapitulation of received knowledge rather than a reasoned reckoning of what the environment currently needs and how it can best accommodate changes in the enterprise. With this in mind, here are a few lessons I think most of us could learn from the development of the JVM2.

  • Look for Patterns in Smaller Systems – Most people know that Gosling & co started building Oak as a language for embedded systems (it was for interactive TV actually) and was built, in part, from the team’s observation of what made network-based programming hard. Lots of small libraries that with intricate detail that had to be understood thoroughly, variations in underlying computer hardware and it’s impact on the data layer and even the impacts of the network layers itself on the data being delivered. Rather than look at the problem as one of language design (and let’s remember – the point was to build a language), they looked at it from the perspective of someone building one system at a time – what are their needs? What makes their lives difficult? What mistakes do they make over and over again? What increases their chance of delivering bad code? In short, they realized that while the language itself was important, it was equally important to deliver an environment that allowed the language to address the needs of the individual program.Similarly, our infrastructure solutions need to take a similar approach – leveling the playing field for applications and allowing systems and platforms to focus on delivering functionality, not navigating the intricacies of downstream dependencies. This sounds pretty obvious, but a brief look in the ESB-space proves otherwise. How many ESB solutions force systems to adhere to a standard model and then force every single system to implement adapters to conform to this model? This type of ESB doesn’t facilitate integration; it just ensures that everyone who touches the ESB has to become an expert in that particular ESB! Infrastructure should make itself as transparent as possible to the systems taking advantage of them, not force participating systems into some architect’s favorite paradigm or data design.
  • Be Open – The Java Community Process is a byzantine and sometimes cliquish thing. Generally speaking, there tends to be a set of “usual suspects” driving many of the more significant JSRs. These usual suspects run the gamut from open-minded to entrenched to a specific way of doing things. The voting lifecycle process within the JCP often makes a corporate governance meeting look like an exercise in agility. However, even with these criticisms, one is struck by how open the JCP really is. Think about it – anyone can join (individuals join free), anyone can view the draft specifications as they are developed and even propose a new specification. And all of this has been in place and working for over 10 years – not bad.
  • I often hear protests from those running technology strategy, governance and infrastructure programs that openness is all well and good, but it has no place in a mature enterprise. This is pure drivel. The fact of the matter is that your enterprise almost certainly has rules for determining what is classified/confidential and what is not. And if you were to look carefully, I suspect you would find that 90% of the work done within these groups does not meet these criteria. Further, hiding this type of information from teammates is ultimately counterproductive – how can you expect teams to execute/use your infrastructure if they don’t have any sense of buy-in – a sense of ownership? Worse, how can you be sure that you’ve adequately addressed the issues and details of your community without their involvement? It’s not unlike building a system without asking the users for requirements – sure, it’s possible, but it’s not smart.
  • Do What You Need and Nothing More – The JVM is amazingly complete. Upon it, entire languages are built – often languages that are significantly different from one another. Why put so much effort into the JVM when, almost certainly, it could be less buggy and offer better performance if it were more customized to the language itself? Because the objective was to create a platform, not a programming language. To be clear, that platform needed a programming language to be useful, so they built that too. But look at all the things they didn’t build – no closures, no generics and a very primitive UI framework. Things were added as time went on (we’ll talk about that in a second), but overall, the JVM is a prime example of restraint – building that which is necessary to accomplish the task at hand elegantly and creating the tools for others to build that which is outside of the platform’s core mission.
    At the most basic level, architects love to deal with complexity and bring order to it. And let’s be honest – most architects love what they do. The problem with this love of organizing complexity is that it ignores the central question we should be asking when faced with complexity: is it even necessary? Too often, we architect infrastructure for every possible inevitability. This type of mentality creates a misappropriation of our design time and effort – we need to be ensuring that our designs are robust, stable and ready to embrace change. Planning for every inevitability generally leads to heartache as we discover in the coming years that we missed one or two (or in reality, five or six…). Instead of planning for every inevitability, we should be building systems that support enhancement from arbitrary sources – both through direct code changes and through decorators provided by other actors in the environment. This latter option is one that many architects struggle with, considering it “bad design” to allow for externalized extension of system. However, nothing could be further from the truth – isn’t this what we do whenever we allow scripting in an application? When a framework is extended? Why shouldn’t the same principle apply to entire systems? With the correct controls, interfaces and governance, this practice allows your infrastructure team to focus on delivering solid infrastructure while simultaneously tapping into the creativity and talent of other teams.
  • Start Small – No, this isn’t a play on the fact that the JVM was originally targeted at embedded systems. Instead, we’re going to focus on the actual size of the JVM and the code that runs upon it. Have you ever looked at the size of the JVM and class files? They’re shockingly small – especially for those of us who come from a Smalltalk background and are used to every single application starting at a massive size. You don’t get to this sort of efficiency by accident. It makes sense if you think about it: if you’re going to be tossing executable code across a network, you want it to be as compact and efficient as possible (such as with applets). Similarly, a network-based interpreter should be similarly compact, providing a complete execution environment in the smallest size possible.Efficiency isn’t something we hear much about in enterprise architecture nowadays. We talk about scalability and performance and resiliency, but not efficiency. Fundamentally, this results a failure in architecture to look at root causes. Efficient systems are those that display clear about what the purpose of the components is while ensuring that components that need to talk to each other can and those that don’t, can’t. These sorts of systems perform because they’ve been designed to perform, not because they designed one way and then optimized (often in conflict with the original design). These systems scale because they are minimalist – they allow trivial scaling of lightly integrated components while allowing attention to be paid to the more difficult (and often more important) highly integrated components.
  • Don’t Fear Change – By my count, at least 6 of the 7 revisions of Java have resulted in significant changes to the JVM itself. Let that sink in for a bit – on at least six occasions, the infrastructure for the entire Java language was changed in such a way that “legacy” binaries (bytecode) was rendered unable to execute. When you think about it, that’s pretty ballsy. Why do it? Because (right or wrong) Sun felt it was necessary to make significant changes to the Java language and the best way to execute this change was to “break” compatibility.Most enterprise architects are horrified at this notion.
    Backwards compatibility is a cherished ideal and a sign of the loose coupling that we want to see in system architecture. This is a good and healthy look at architecture – we should be looking to create designs that prevent other systems to change whenever another makes an update. At the same time, fear of making incompatible changes is a debilitating problem that can leave you with a well-designed, but ineffectual system – and that’s bad architecture. Architects have to be willing to cut the cord; to say: this change will be significant, but it is necessary to meet the business need (current and future). Architects have to be willing to let go of the past and move in the interest of the business, even when it’s messy at a technical level.
  • Ask for Feedback – The JSR process can be pretty rough and tumble.  People come from many different perspectives with their own agendas and biases and sometimes that comes out pretty harshly.  So why does Sun/Oracle even bother?  Wouldn’t it be easier to just invite the people in the industry who already work for/agree with them?  It would be easier, but it wouldn’t be better.  Nearly every major change to the Java programming language over the last 13 years has been the result of a collaboration between Sun/Oracle and the Java-using community.  This Java Community Process (JCP) facilitates interaction, mines the community for ideas and prevents myopia from setting in.  At a very fundamental level, collaboration breeds better design.
    I think it’s fair to say that  most architects “get” this idea at a pretty basic level.  Let’s face it, we’re a pretty talkative bunch.  Where I generally see problems arise is when talking doesn’t turn into collaboration. Too many times, we become entrenched in our thinking – focused on our first idea and unwilling to see it challenged or questioned.  Design requires a give and take – an advancing of ideas until another idea spears it, allowing a different, better idea to take it’s place. This is a somewhat adversarial process: the dominant idea/design is a protagonist, bravely representing the future.  Other architects have a responsibility to look for holes and weaknesses, for alternatives and for unexpected consequences to/of the original design/idea.  This is essential for the best idea to evolve.  Besides, if your original idea turns out to be the best, you get brownie points with your fellows for being just that smart.

Hrmmm…this seems to have gone a bit longer than I originally expected (I’m pretty sure I’ve written shorter magazine articles).  Regardless, I think the group at Sun has done a lot of “right” things with their development and nurturing of the JVM – most of which I think can teach us a lot about good architecture.

1: Yes, Microsoft’s CLR has a number of languages implemented as well, but the majority of these originated with the primary vendor, Mircrosoft.

2: For the purposes of this discussion, any reference to “infrastructure” refers to software infrastructure unless otherwise stated.

Be Sociable, Share!

No Comments currently posted.

Post a comment on this entry: