The Uncertain Future of Java

Sun Microsystems never quite recovered from the Tech Bust. Looking back, it seems that Sun's decline began on Apr. 20, 2000, when Network Solutions replaced a Sun machine with an IBM machine to run the "A Root" DNS name server.

If life were a novel with nice neat literary devices, Sun's losing its spot as the "dot in dot com" to IBM would clearly foreshadow IBM's takeover of Sun. However, we live here in the real world where things tend not to wrap up neatly.

Yesterday's news that IBM is in talks to buy Sun raises some serious questions for me. Oh, I'm not worried that IBM will ever really take over Sun (that might even be a good thing). I find it hard to believe that the SEC under President Obama's administration would allow further consolidation in hardware manufacturers. After all, the FDIC chief, Sheila Blair, spoke out today against allowing financial institutions to become "too big to fail". An idiot with a speech impediment could make an argument that both Sun and IBM are already critical to the economy.

What concerns me is the fact that Sun's executives are willing to talk to IBM at all. They've never exactly been friendly to one another. In fact, there has been some pretty bad blood between the two computing giants. I keep thinking that if Sun is courting IBM they must be running out of options. If the SEC disallows a merger with Big Blue, who is left that could possibly buy Sun? Microsoft? Not bloody likely. Computer Associates? What a horrible thought.

Sun, it's time to figure out how to make it on your own! You have a huge cult following, all you need to do is market it right. Green Computing is all the rage, for very good reasons, now is the time to jump to the front of the market and tout your low-energy-usage hardware, software, and services!

The Strongest Force in Technology May Come From Congress

The forces that have shaped technology since the September that Never Ended have been many. Some of the stronger forces have resulted from legislation (e.g. Sarbanes-Oxley), but none will have been stronger, if enacted, than the Cap and Trade program President Obama proposed in his budget. Executive Summary: in a few years, energy in any form is going to become expensive on a scale that will put the summer of '08 to shame.

Rejoice! We now have real economic pressures to support Green Technology initiatives!

Green is the new black. Almost any technology that reduces energy consumption is suddenly going to be extremely attractive to IT departments everywhere. Sun Microsystems, it's time to spin up marketing for the Sun Ray! ClearCube, your day has come! All of those kernel-level power-saving tweaks in Linux suddenly have a purpose!

Since I'm in "wild prediction" mode, here's a few more:

Physical location of Data Centers may soon become a serious concern. Let's face it, hot places surrounded by lots of coal-burning power plants are likely to suffer. Data Centers in Texas will be under particular stress since generation capacity is already strained and future plans are largely based on increasing use of coal (mostly brought in from Montana and Wyoming) and, well, Texas is hot. Telecommuting might begin to make sense. If gasoline prices sustain the levels reached during the summer of '08, employers are going to be under some serious pressure to allow telecommuting for certain job functions. This possibility depends largely on secure, low-power remote access methods and ample bandwidth to the curb. Development frameworks, ultra-high-level languages, and abstraction layers may become too costly to be practical. If power prices get to the point that somebody cares about the cost of CPU cycles again, we may need to focus more on run-time efficiency than on extravagant development models. AC/DC conversion will be centralized in Data Centers. Instead of having redundant, inefficient power supplies with failure-prone fans stuffed into server chassis, low-voltage DC power will be piped into racks. As an added benefit, white noise levels will drop below the threshold of pain. The expected life of hardware will increase to compensate for higher costs. Chip fabrication is a notoriously power-hungry process. Higher energy prices translate into higher component costs, and to compensate, computer equipment is going to have to become a durable good with a life of more than 3 years.

If your organization has yet to start an energy management program, now is the time. If you need assistance, or if you simply don't know where to start, drop me a line.

Logging is Marketing's Best Friend

Logging is one of the most basic components of writing software, but receives very little attention when applications are designed. A good logging strategy is designed with many purposes in mind, including application debugging, user audit trail, and security, all of which are valuable from an IT perspective, but there are huge benefits for the entire enterprise if the marketing department adds its own criteria.

Marketing has long relied on log analysis tools such as WebTrends for information about effectiveness of marketing campaigns and website usage. Originally, this class of analysis tools consumed standard web server logs to provide extremely detailed, and valuable, website usage reporting. In the last 15 years, however, websites have changed from hierarchical directories providing static file downloads into fully-featured, client-server, interactive applications. Sure, web servers still churn out standard web server logs that look exactly like they did in 1993, but the information contained therein provides little visibility into what users are really doing. Fortunately, these log analysis tools have adapted to better techniques, such as consuming application-generated, custom log formats and providing page-tagging methods to feed data directly into the tools.

The most basic feature of logging for any purpose is tracking a user's actions, but even such a simple thing can be tricky with asynchronous web applications. Within Web 2.0 applications, there is little or no correlation between the URL of any given request and what the end-user actually sees, so traditional methods based on correlating URL to content. The result is that only truly effective way to track information useful for marketing purposes is to include very specific tracking requirements into the design of the application. Important: it will cost an enormous amount of time and money to retrofit applications to do standardized logging.

Staffing for Sustainable Systems

If you want to know how effectively an IT department is run, all you need to do is look at the systems it designs and supports. Pardon the cliché, but building and maintaining an IT shop and the software it supports is something of an art. Talent, training, experience, and motivation are all reflected in the work of both geek and painter. Let's look at each of those points in turn:

Talent The number of specific talent categories listed on job boards such as Dice and Monster continues to increase, reflecting the degree of specialization in today's IT work force. History tells us that Specialization of Labor is a logical and necessary step in the advancement of an industry, resulting in huge advances in productivity. IT managers must recognize that these specialties truly are distinct skill sets, requiring separate staff, for as Plato pointed out, "One man cannot practice many arts with success." Note for tech workers: it is never too early to start specializing, even if you are capable in more than one area - employers are unlikely to believe it and they are looking for specialists anyway. Training We work in a fast-paced and constantly changing industry, and to fall behind is to perish. Training IT workers is the best investment a company can make to keep up with the times and to keep staff happy. A substantial training budget makes sense from an ROI standpoint as well. A $4,500/year training budget for a $70,000/year employee costs the same as 16 days of the lost productivity which often results from learning on the fly. For experienced workers, dedicating time to self-directed learning might make more sense than instructor-based courses. Note for tech workers: I believe that we have entered a phase of the tech cycle when emerging techologies, however exciting, are unlikely to take root in the mainstream business world. If you are already well-versed in current technologies, consider honing your knowledge of architectures and development patterns - anything that makes the development/maintenance process more efficient. Experience For an IT shop of any size, it is beneficial to employ workers with varying experience levels. Resist the temptation to rely on senior staff for all of the heavy lifting. Instead, they should be focused on directing the work of those with less experience. Using this strategy protects your business from disaster if you lose a highly-experienced employee, since the bulk of the work is distributed among many less mobile workers. There is another even more compelling reason to adopt an Apprenticeship model: since the 2001 dot-com bust, enrollment in Computer Science degree programs has fallen off, spurring predictions of a tech-worker shortage. The only way for businesses to combat this trend is to train their own IT staff from the ground up. Note for tech workers: Experience can be a Catch-22 - you can't get a job unless you're experienced, but you can't get experience without a job. To get a break, try volunteering your time, applying for internships, and contributing to open-source projects. Also, never overstate your experience. You are much more likely to get an offer if you truthfully rate your abilities and show excitement at the opportunity to improve. Motivation Call me a romantic, but I put more weight on motivation when hiring than I do any other criteria. The biggest challenge that comes from hiring enthusiastic people is keeping them excited about the job. Everyone has different motivating factors, as any pseudo-self-help book will tell you, but you need also to be aware of your employees' demotivating factors. Need some real-world examples? Rent Office Space. Seriously. Note for tech workers: Status reports are a fact of life. Once you get into the routine, you may even find them useful - what better documentation of your worthiness for promotion is there?

Properly implemented, this staffing strategy results in an IT culture that is beneficial to both company and employee. Hiring specialists for each skill set ensures competence in implementation and prevents employees from getting stuck with duties they have no interest in. Training employees saves time and ultimately money by avoiding implementation mistakes. Using senior staff to set direction and oversee work instead of building everything themselves ensures that when individuals leave, as highly-skilled techies are wont to do, things don't come to a screeching halt. In fact, when people leave it creates opportunities for advancement in the team - a real morale booster and a natural protection against job hoppers, since most new-hires are lower-level.

In short, lots of work will get done by people that know what they are doing, nobody will want to leave, but if they do, the whole staff can have a fun going-away party instead of crisis-management meetings.

Agile and SOA: Careful Planning is Essential

Agile software development and Service Oriented Architecture are two of the most passionately promoted software development concepts in the last few years. While it is certainly possible to implement them together, careful planning is essential.

In its essence, agile software development is a process whereby business owners, designers, programmers, and testers all work together in an iterative process. The idea is that in applications where business requirements change frequently, it helps to be able to adapt current development efforts quickly instead of waiting for the next development cycle to begin. It's kind of like the "Can you hear me now?" ads applied to writing programs.

Service Oriented Architecture is an overarching design concept that focuses on segmenting software systems into loosely-coupled, independently implemented, remotely callable software modules with clearly defined interfaces and behavior. Basically, the approach is to build a whole bunch of little programs, each of which do specific tasks, and plug them together to create complex applications; sort of a software Erector Set.

In case you skipped over the vaguely technical buzzwords in the middle of that SOA description, let me call attention to the phrase "clearly defined interfaces and behavior". Every service needs to adhere strictly to its Service Contract, which says "if you call me with these inputs, you can expect this output". There's not much room in that Service Contract concept for the sort of iterative change effect resulting from an agile development method.

Clearly, agile software development does not fit well with creating services. However, agile methods can be applied extensively to the consumers of those services. In fact, through the creative process inherent in agile software development, an organization can identify new types of useful services that can be provided. It is probably wise, however, to use a more systematic, design-oriented approach in their implementations than agile methods provide.

Testing with Complex Data Dependencies: Untie the Gordian Knot

Testing software functionality is a fairly straightforward idea: set up pre-conditions, perform a series of actions, verify the results. In practice, however, those three seemingly simple steps can turn out to be extremely difficult and time-consuming.

In general, there are two approaches to software testing:

Black Box: the tester uses the software pretty much as an end-user would, ignorant of the implementation details. This approach is best used on fairly simple software with finite combinations of inputs. When applied to more complex systems, testing is usually limited to "happy path" scenarios.

White Box: the tester has full access to, and knowledge of, the inner-workings of the code. This approach allows for more targeted testing because the tester can avoid running test cases that are effectively duplicates of others. Please note, however, that it can sometimes be difficult to tell which test cases are duplicate effort.

Software systems that apply business rules to large sets of highly inter-related data are notoriously difficult to test. Test cases in this kind of system can easily call for pre-conditions that are difficult to describe, much less set up. Frankly, neither method, used alone, will ensure a high level of quality. White Box is impossible to apply to complex systems with 100% coverage. Black Box helps to target testing efforts, but in systems where the dependency is in the data rather than in the code, tracing the lines of dependency can be exceptionally difficult.

Instead, apply a hybrid approach. Turn on full debug logging and take a swing through the happy paths as in the White Box approach. By looking at the logs, you should be able to identify the test cases which hit the code that needs testing. Then, apply the Black Box method to those test cases and any that, from a low level, are closely related. The results will be much less time-consuming than pure White Box, and much more complete than pure Black Box. You might even learn something new about how your application really works. If you do, document it!

Design Web Apps That Don't Hurt to Scale

Let's look at some design concepts regarding ease of scalability. It's a dense subject that cannot be completely addressed in generalities, so we'll personalize it a bit:

We join our protagonist, designer of the newest killer app to hit the Web, three weeks before the grand opening. Budgets have been tight, so the development team has been getting by with a single development server; fortunately, QA went smoothly. The team has just built the production cluster, and the CEO wants to be the first person to try it out.

This is the kind of scenario that could result in either a successful launch or layoffs. Unfortunately, there is nothing our protagonist can do to influence his fate at this point. The result of this demo is determined by decisions that were (or weren't) made in the design phase of the application and the team's fidelity in adhering to those architectural decisions.

The fundamental challenge of building a web application to work in a clustered configuration is that the runtime environment is separated into multiple distinct instances of the application, each with a separate memory space. A thread running in one instance has no way of accessing in-memory data residing in another instance.

There are four basic approaches to dealing with this problem which can be used in combination:

Ensure all threads that require specific data always run within the application instance which houses it. This is a method of managing load rather than managing data, and provides no fault tolerance. Each application instance is unaware of, and has no interaction with, other instances. Instead, load is routed through some external method to the instance housing the required in-memory data. In the context of web applications, this approach depends on an external load-balancer to keep track of which user sessions are affiliated with which application instances.

Build remote memory access methods to provide mutual data access between application instances. This is the approach used in Beowulf clusters and other grid computing engines. Implementations of remote memory access are usually done through some sort of messaging interface, although there are more direct methods, such as RMI calls in Java. Because each application instance houses a distinct set of in-memory data, this method does not provide fault tolerance. On the upside, data is only represented in a single application instance; this is great for applications which require large amounts of in-memory data. On the downside, the application must have some way of determining which application instance holds the data it needs. Overall, this approach is best suited for data-intensive rather than real-time applications.

Replicate shared data between application instances so that it is always accessible to all threads. When data is created or modified in one application instance, the updates are communicated to all application instances. This approach is best suited for small amounts of relatively static data that is unlikely to be used simultaneously by multiple application instances since most data locking mechanisms are impractical with the latency inherent in network connections. One of the greatest benefits of this method is that, because all data exists everywhere, it does provide fault tolerance.

Persist shared data in an external data store. In short: let the database manage the data. Each application instance is unaware of the others and relies entirely on external data storage to house data instead of in-memory storage. Data storage and retrieval incurs the additional cost of a database call, but because the data is centrally managed, this approach handles concurrent data access quite well.

As the CEO pulls types the URL, our friend reviews the architectural decisions made months ago. The presentation (user interface) layer is designed to maintain active user sessions, persisting session information in-memory; if a node drops, users with state information on that server will be kicked out, but they can log back in with ease. In contrast, the business logic layer, where all of the core processing is handled, is completely stateless, storing all persistent data in a central database; fault tolerance is seamless.

This design requires not one, but two levels of load balancing with different configurations:

The presentation layer of this web application is designed to assume that users with active sessions will always be served by the same application instance, so the load balancer must be capable of distinguishing one user from another. A common way of implementing "sticky sessions" is for the web application to assign each user session a unique identifier which is passed to the web browser in the form of a cookie. The cookie is then passed along with every request, which the load balancer can use to choose the correct server to handle the request. Since the load balancer must be able to understand the content of HTTP requests, it must be of the type labeled "application layer" or "layer 7" capable.

The business logic layer is completely dynamic, requiring no intelligent routing of requests. This kind of load balancing does not require any of the extra features provided by an "application layer" load balancer.

While the CEO is checking out all of the bells and whistles of the application, smiling the whole time, the marketing director bursts into the room. "Our product launch announcement has just been Slashdotted! It looks like we're going to easily double our traffic estimates on the first day.

Neither the presentation layer nor the business logic layer has a limitation on the number of parallel instances since there is no inter-instance data replication; if additional application instances are required, they can simply be added into the load balancing pools.

Scalability of this web application is effectively limited only by the capacity of the database server. Most commercially available database server products have some clustering capability, although the license cost is usually staggering. Budget-constrained projects often opt for a single high-capacity server and a really solid backup strategy. Naturally, there are some risks associated with the frugal approach, so it is wise to put some serious thought into the decision.

"I don't see a problem with that," is our friend's cool reply, "all we need to do is double up on the application server hardware and licenses. Where's the checkbook?"