Back to Basics for Sun Software (Continued)
Overcoming Complexity
Q: Do you think the increasing functionality of J2EE eventually will make the language too complex for a lot of developers to use?
Fowler: The good news is that lots of people contribute to JSRs, evolve APIs, and do reference implementations of new technologies. The bad news is that lots of people can do JSRs, create APIs, and evolve technology. Open systems are a two-edged sword compared with Microsoft and .NET, where you can create a closed system with all the tools. Now, we recognize that it isn't effective to say, "Put in any API you want, and the tools people should just go and solve it." You have to think about how you create APIs that are, in fact, tool-able.
Q: We've heard about the Ace Project. How does that relate?
Fowler: That's an effort in Sun Labs—not a product, but a research project. Ace moves directly from describing a model of an application to the application itself. It understands the deployment scenario in terms of what round-trips [are involved] and what the cost of things would be. So if you deploy in different environments, it will optimize where code might live in different servers. It's also an effort to get at one of the hardest problems: understanding your deployment scenario. What is the performance of the Web service? How are things load-balanced? What's the penalty of running something in an app server? Right now, you write whatever you want, but at deployment time you might discover a bunch of issues.
Q: It sounds as if that might be a tool for enterprise architects more than developers.
Fowler: Yes. What we're trying to do is separate presentation, which might be down in the guts of the organization, from how you interact with the business model. Obviously we have pieces of technology such as JSP and others that tend to create boundary layers between model, view, and controller. In theory, you can plug into these, but the tools don't take advantage of that. So we need tools for each role—enterprise architect, the people doing the presentation logic, the people doing business rules. Ace attempts to separate those and do different things. It's an interesting project, but it's a hard problem.
Today enterprise architects use models such as Rational Rose to describe an architecture, but they don't use them during the complete life cycle of development. So, you create the chart and go off and do whatever, because it's not necessarily a closed loop. This is a bit of a holy grail, but one that people will inch toward because that's where you'd want to be.
Q: Talk about the process of building software and managing development. It seems that between extreme programming and agile methods and unified process, folks are looking for a whole new level of stuff that deals with how to interface with the business model.
Fowler: Sun's role in the grand scheme of development is to work on the runtime environment and the APIs. The tools we produce are much more for systems programmers, not enterprise developers.
The way we [extend to the business model] is to partner with folks such as Rational and others, because fundamentally our DNA is the runtime platform, the container, and the articulation of the developer's story in the base form—not for things that have different semantics for different parts of the business. Architecture as a practice for us will be what kinds of applications you can build with J2EE; how you deploy those applications to your infrastructure; how you handle scaling, security, and other types of technology issues; what tools partners you would use; and other things you would use as part of your practice. We don't produce all those tools.
In terms of the way Sun does development, we're not uniform across all the development groups, but we are much better in terms of practices than we are in terms of tool use. For example, Solaris has an outstanding practice in terms of how you identify, decide on, and propagate system changes to yield a stable operating system, and how you do that in a modular way so that systems can be developed separately from one another.
In terms of tools, our strategy isn't as rich. We're systems programmers. People use models early in the life cycle. They develop with traditional IDEs, frequently debugging specialized tools in that environment. Because they do internal-level debugging and hardware-oriented debugging, they need specialized tools. In the case of Solaris, and now much more so with Java, we've gotten into a mode where we believe that every release we produce is better than the one before. That takes serious attention to practice, especially when you have 1,000 or more engineers working on a project.
Q: Are we coming to a point where the complexity of the tasks we're trying to do as developers, and the methods that we've used to do them, have lost us the confidence of the business user? And does that suggest that we have to get more efficient and maybe even reorganize how we undertake the practice of development so that we meet deadlines and lower our failure rate?
Fowler: I'll half agree with you. A couple years ago, people had scads of things they wanted, but scale and availability were absolutely number one. The core issue was: How big can I go, and how can I be sure you'll be up there all the time? Now the boat is tipping the other way, and capital cost and cost of ownership are the absolute number-one things. People are looking at the value of what they're doing. Whether they're working in the capital markets or funding new technologies or a big IT project, they've all been saying, "I'm going to reuse what I have."
So I think that's half of it. People haven't digested the big IT projects they had, and they're gun-shy to start new things. The part I'd add is that deployment complexity has been one of the biggest problems. Individually, people have gravitated rapidly toward new technologies such as Java and JSP because, compared to what they had before—C,C++, Fortran, and Cobol—they are a dramatic move in the right direction.
But when it comes to deploying applications—when you have Web tiers and app tiers and database tiers and stored procedures and J2EE and Web services and a load balancer and encryption and key management and identity policy—a lot can go wrong. A lot of stuff gets delayed and a lot of stuff doesn't end up being what you wanted because what worked in the lab didn't quite work when you deployed it.
Dave Patterson, a professor at [UC] Berkeley who works for me on a part-time basis, made a humorous observation along these lines. After Microsoft was in the news for having misconfigured some DNS routers, he calculated that for Microsoft to get to five nines [operating at 99.999 percent efficiency], it'd have to be up for 337 consecutive years, starting now. And, you know, they've already blown it.
That might sound like a wisecrack, but there's a lesson there. That wasn't a hardware failure or a software failure. It was a misconfiguration because the environment was so complex. One of the things we're focused on is figuring out how to simplify application deployment. There's a whole set of programs here at Sun—N1 and all that—that are about figuring out how to make deployment successful.
Q: Part of this problem is that the separation between the development foundation and the deployment process seems to be going away.
Fowler: That's right. At one time, you would develop an application and then deploy it onto a system. Nowadays, what is an application? You have the Web-tier, business-tier, and database-tier logic, and they need to be in synchronization for everything to deploy. You want to go right from development to deployment in a test scenario, exercise the test scenario, then take that test case with all the interdependencies and deploy to the production infrastructure.
People have struggled with building a scalable infrastructure or revising a scalable infrastructure on a continual basis and maintaining reliability. If you're a CEO, you ask why you spend so much money and what the results are. The answer doesn't have to do with the programming language and the tools, but with practical issues of response time and uptime for customers. In many cases, those are not what they should be. While the reliability of individual pieces of hardware and software has reached a high level, the complexity and usability of new software combined in the higher-order systems fall far below the mark, and that's where we need to tackle reliability.
Back to top
|