The public has spoken. Enterprise Java is just too complex. Alternative frameworks like Spring are, ahem, springing up that focus on the parts of the specification that people truly want to use. It’s not about some mandate from Sun, or Oracle, or some other large vendor that controls the direction of enterprise Java.
So, to paraphrase that great American patriot, Ronald Reagan, we say, “Mr. Ellison, tear down this wall.” It’s time for the process of creating and controlling Java to be truly open—not open like some dictatorship that lets its citizens vote but then denies them any of the freedoms an election implies, but a truly decentralized process that listens to users at least as much as vendors.
The enterprise Java specification exploded because Sun and the other cohorts apparently believed that every JSR, regardless of any wide implication, was worthy of inclusion, even if only one software vendor needed that specification to resolve one minor issue that only it was having. In short, Java tried to be all things to all people. And, to quote that great American patriot Abraham Lincoln, “You can please all of the people some of the time, and you can please some of the people all of the time, but you can’t please all of the people all of the time.”
Clearly, the people haven’t been pleased. New research reported on by senior editor Alex Handy in this issue shows that use of the Spring framework has pulled even with Java. Projects that began in the open-source community are, ahem, springboarding Java into the future.
People in and around Java have known enterprise Java had grown unwieldy for some time now. In fact, Java EE 7 is supposed to eliminate some of the complexity, reducing it to a more usable core of specifications. What’s interesting here is the jockeying among Java stakeholders such as the Eclipse Foundation, Red Hat, and VMware (through its SpringSource subsidiary) for more influence and control over enterprise Java. And it’s not just backroom dealing: These organizations are taking their case to the court of public opinion, trying to win a leading role in the future direction of Java.
After years of dormancy resulting from Sun’s abdication of its leadership position, and uncertainty that continues today over Oracle’s stewardship, this renewed energy in the community heralds a new, ahem, spring—a new season—for Java. Oracle should embrace this vigor and make the Java Community Process more transparent, guiding it with a lighter hand on the tiller. The public has spoken.
Getting fired for cloud failure
Did you lose business-critical functions during Amazon Web Service’s service outage? If you were affected by the mid-April “issues” at Amazon’s northern Virginia data center, then someone should get fired or otherwise seriously reprimanded.
Not at Amazon. Someone should get punished at your company.
IT’s job is to support the business by providing information technology. That means that the websites, the databases, the applications servers, the networking and the portals are all available to employees, partners and customers. That means being up and available, all the time—or at least, within an allowable service level approved by management.
If your company housed all of its applications in on-premise data centers, the expectation is that the IT department would ensure uptime (again, within agreed-upon service levels). If there’s a power failure, there should be a backup power system. If the building is damaged by a flood or fire, there should be redundancy at other buildings or in other location—or at best, a hot site ready to kick into action.
If IT recommends backup power systems, redundant data centers or hot sites, but management chooses not to fund them, that’s a conscious decision. Given finite financial and human resources, every business owner has to balance risks against costs. But that’s a decision that top managers, not conservative IT, should make.
What about if you move your computing resources into a colocation facility or a hosting center? The same thing applies: Business continuity calls for redundancy, failover planning, and so on. There must be contingency plans, because failure is not an option.
The cloud is no different. Any IT professional who recommends moving key business functions into the cloud without making plans for that service’s failure has screwed up. Big time. Outsourcing to Amazon or another cloud provider isn’t an excuse for neglecting redundancy or failure. While it’s Amazon’s job to keep their business running, it’s your IT department’s job to keep your business running.
If you suffered IT downtime during the Amazon outage, then it’s your company’s fault for putting all its eggs into one basket. Don’t ever, ever, ever, let that happen again.
