PDC Video on Cloud Computing with Azure

J9SYRP3G9ZUC

Related posts:

1. Windows Azure Now Available
2. Windows Azure Videos
3. Java vs. .Net – Another Blast From the Past

With a Just Enough Technology approach, a company evaluates technology against its core problem or objectives. I work with business and technology leaders within a company to define their true objectives and then weigh the technology decisions with their business objectives as the main criteria. Read through this article on choosing between the Java and Microsoft platforms. Both technologies have evolved quite a bit since this was first published, but some of the core arguments remain to this day.

The article:
A user asks Dave, “Assume that we have a new mission critical Web application that we need to develop over the next six months. How would you recommend we compare & contrast the pros/cons of J2EE vs. .NET as the platform (assuming we have the proper skills)?”

There are many, many factors that come into play when deciding between J2EE and .NET. As a foundational statement, let me state that I personally believe you can build (and I have built) mission critical Web applications on both platforms. Sun Microsystems commissioned a white paper (see links at the end of this post) that states the theoretical scalability of each platform is unlimited. I say this because your decision should not based on whether or not you *can* build a more robust application in one or the other. It can be done.

As far as developing Web services, either platform offers a great foundation. Of course there are intrinsic advantages to each platform which I’ll list later. Web services and .NET are tightly integrated. It is *very* easy to create a basic Web service in .NET. It is simply a matter of placing a directive on each method you want exposed as a Web method. The compiler does the rest for you. Deployment is also a breeze. For the most part, you simply copy your files to the server and you’re done. Visual Studio .NET is also a development environment that has no peers, in my opinion. I still believe Microsoft has the edge in getting a project out the door as fast as possible.

J2EE on the other hand also has some good tools for creating Web services. IBM’s WebSphere Studio Application Developer 4 offers some great work-saving features for creating Web services. Basically you choose a Java bean or other object to “WebServicefy” and step through the wizard. When you are done, WebSphere Studio has created a wrapper for your object and all the SOAP, WSDL, etc. code needed. It also has created a JSP application to test your new Web service. It works and it is straightforward. I was able to create a simple Web service within 30 minutes of opening the environment for the first time. Pretty impressive for a Java IDE.

If you have developers skilled in one or the other platforms, then lean strongly toward that platform. The cost of training is high. Leveraging existing skills should be a priority.

That said then, what are the decision points one would consider when choosing between J2EE and .NET? Here are a few considerations and who I think has the advantage in each:

Multi-Platform: J2EE
———————-
Currently if you need to create applications that run on more than one platform, Java is your only choice. This may change in future as .NET is ported to other platforms – we’ll see.

Legacy Integration: J2EE?
———————-
If you need to integrate legacy systems you may have an easier time in J2EE. IBM for example, provided the iron for many of these systems and has very workable solutions to connect to mainframes through WebSphere. On the other hand, you *could* create a Web service on the legacy platform, making this point moot.

Multi-Language: .NET
———————-
If you have developers in VB, C++, Java and want a unified environment for them to work in, .NET is your choice. All languages are created equal and work together, including cross-language inheritance.

Choice of Vendors: J2EE
———————-
Is a choice of vendors important to you? There are advantages to a multi-vendor solution – you can choose the best-of-breed for each component of your system. There are also advantages to a single vendor solution, which include better interoperability between components. For example, .NET and SQL Server 2000 working together are a powerful, easy to use (relatively) combination.

Vertical Scalability: J2EE
———————-
If scaling up by buying bigger iron is your organizations preferred method, than lean toward J2EE.

Horizontal Scalability: .NET
———————-
If your organization likes the idea of a greater number of cheaper servers than there is probably an edge with .NET.

Finally, after all is said and done, many decisions are in reality based on shall we say, non-scientific criteria such as:

Like Microsoft: .NET
Don’t: J2EE

I say this only partly tongue-in-cheek. Prejudice against Microsoft and the underlying technology goes deep with many technical folks and some business folks. It is a real factor in making this decision. There is also a prejudice in the Microsoft community against Java that is also based on less than scientific findings.

LINKS:

Original Article:
( http://searchsoa.techtarget.com/news/article/0,289142,sid26_gci819020,00.html )

J2EE vs. Microsoft .NET: (Copyright2001 The Middleware Company Prepared for Sun Microsystems, Inc.
Transaction Processing Performance Council
Roger Sessions’ comparison of .NET to J2EE
Software Dev Magazine article
O’Reilly article comparing J2EE and .NET

Related posts:

1. Choosing Between Java and .Net
2. Craftsmanship and Software Development
3. Windows Azure Now Available

Starting today, customers and partners in countries across the globe will be able to launch their Windows Azure and SQL Azure production applications and services with the support of the full Service Level Agreements (SLAs). The Windows Azure platform AppFabric Service Bus and Access Control will continue to be free until April 2010 for those that sign up for a commercial subscription. Additionally Microsoft codename “Dallas” will continue to be in a free CTP.

Read more on the Azure team blog.

Related posts:

1. Windows Azure Videos
2. Good Azure Video from PDC09
3. Java vs. .Net – Another Blast From the Past

I like how they use the term “Craftsman” to describe what we do….[the craftsmen are] the ones who have taken the time to master the tools that have been made available to them to assist in their craft.

Craftsmanship in the manner used above,  refers to an attention to detail and a pride in one’s work product. A craftsman is more than a worker – he or she truly cares that they do things right and to the best of their ability. I agree with this thought in principle, but I want to expand on it a bit and speak to one difficulty with software craftsmanship as a methodology.

In today’s technological world we need craftsmen, but we also need more than craftsmen. As an allegory, look at home building. We care about the quality of construction in homes that we buy. We certainly want to make sure everything is up to code and if we live in an area subject hurricanes, we want to know the proper standards and materials have been used in construction. We want to be sure that the workers who raise the frame, do the plumbing and electrical work and do the interior finish work are adequately skilled in their craft. That said, we would not hire a cabinet maker to do the framing, an electrical engineer to run the wiring or a rocket scientist to handle the plumbing. We choose the right skills and tools for the job at hand.

Software development is still in large part a craft, an art. We are not yet at the stage where every aspect of software development is reduced to a kind of binary assembly line, where unskilled workers assemble programs from software “parts”. True, there are some benefits we can receive from using prebuilt libraries or components, saving development, testing and maintenance costs as we will discuss below. But we still need good, skilled developers to do the heavy lifting. Software is not like machinery. For the most part, you design and build a machine to do one thing. Software on the other hand is much more multi-faceted and when starting a software design, there really are almost unlimited options available. A problem can be solved in many, many ways. A craftsman is needed to help choose an appropriate solution.

But we are also beyond the time when every piece of software must be built from the ground up. There are many commercial and open source solutions available that can jumpstart projects or that can provide the backbone for common application functionality. These solutions include things like nHibernate, Spring, and other persistence libraries that handle common operations in a manner that has been well-tested and which meets the needs of many projects. The Java community has made very good use of open source projects and libraries, some of which are now included in core Java. Why then aren’t these types of libraries used more frequently in Line of Business (LOB) applications? I believe business is often missing out on long and short term cost savings by not leveraging these open source or 3rd party solutions. One reason these solutions are sometimes not adopted (certainly not the only reason) is the inherent craftsman mentality of developers and architects. I call it the “But we can do better” syndrome.

You are probably familiar with the Pareto principle, also know as the 80-20 rule. In  the cost-benefit analysis of software projects this rule can be stated as “80% of the benefit comes from 20% of the development effort”. What this means in practice: IT needs to concentrate on that 20% of the time and effort which provides the most benefit and spend a lot less time and effort on the remaining 80%. In reality, it is often difficult for technical people to do this. Why? The 20% tends to be more mundane from a technical perspective and there is a lot of interesting design and coding to be done in the 80%. There’s an old story programmers tell about the a programmer who said “I can write that function in 10 lines of code”. Another programmer said, “I can do it in 5 lines of code”. Finally, a third said “Well, I can do it only one line of code” and he proceeded to spend hours upon hours writing and rewriting the function until it worked with only one line of code. What is the problem with this story? The first programmer could have written the function in minutes, the second in an hour or two but it took the third programmer many hours to complete the task. On top of that, the third programmer’s code was so complicated and used so many programming “tricks’” that very few other programmers could understand how it worked.

The “We can do better” syndrome is difficult for business to fight. Better after all is well, better. If we can reduce the time it takes to execute a function by 500%, it should be worth the effort because of the performance savings. Right? What if it only took .5 milliseconds for the function to run before it was optimized? End users would see zero benefit from the added effort to increase performance.* But from the third programmer’s perspective, he did the right thing. He made the application more efficient according to his definition.

Programmers also tend to distrust code that came from an unknown source (or even from one of their colleagues). In the early days of distributed computing we had the grand notion of creating object libraries full of reusable code. The greatest obstacle we faced to reaching this goal was the unwillingness of developers to use another programmer’s code. They would rather create it themselves. There was always something that the library didn’t do or didn’t do “well enough” in their opinion.

The moral of the story is this: we must apply the same logic for selecting software solutions that we would in other areas of business. Good enough is good enough. If there is an open source library or 3rd party library available that meets the 80-20 rule and which will truly deliver on the project’s requirements, it should be strongly considered as an alternative to developing everything from scratch. In order to know when to use an existing library and when to build a new library, business and IT must work together, and IT must keep the business objectives as the first priority. On the other hand business must be clear about their objectives with IT. Those objectives are the measuring stick for evaluating software design alternatives.

* I am aware that in some instances such as recursive calls, .5 milliseconds can be a performance bottleneck. That isn’t the scenario I am using here.

Related posts:

1. Is Software Engineering Dead?
2. Why Do We Need Software Architects?
3. Choosing Between Java and .Net

I am a software architect, but I’m not a “Blue Sky” thinker; I’m more of a practical thinker.  I asked myself some questions about architects. What is a Software Architect and why do we need them? What do we expect from architects and why not just have a tech lead? Is there real benefit in an architect and are some projects too small for an architect? If so, what qualifies a project as needing an architect?

I believe and practice iterative development techniques and agile methodologies. What I have found, is that even in the agile world, a strong architect can make a project and the lack of architecture (or more properly – architecting) can foil a project’s success. Martin Fowler has written an excellent treatise on Software Architects – Who Needs an Architect? (pdf).

In it, he states:

Architectus Reloadus is the person who makes all the important decisions. The architect does this because a single mind is needed to ensure a system’s conceptual integrity, and perhaps because the architect doesn’t think that the team members are sufficiently skilled to make those decisions. Often, such decisions must be made early on so that everyone else has a plan to follow.

Architectus Oryzus is a different kind of animal (if you can’t guess, try www.nd.edu/~archives/latgramm.htm). This kind of architect must be very aware of what’s going on in the project, looking out for important issues and tackling them before they become a serious problem. When I see an architect like this, the most noticeable part of the work is the intense collaboration. In the morning, the architect programs with a developer, trying to harvest some common locking code. In the afternoon, the architect participates in a requirements session, helping explain to the requirements people the technical consequences of some of their ideas in nontechnical terms — such as development costs.

Do you remember MSF (Microsoft Solutions Framework)? This is a development methodology that was distributed by Microsoft. The Lifecycle methodology was kind of iterative, but on a release cycle, rather than multiple iterations per release ala RUP. It tended (in my mind) toward product development rather than custom software projects or internal IT projects which are quite different from product projects.

What MSF did have is a very strong Team concept that bears close review today. Now they don’t really mention the concept of an Architect in relation to the development team, but they do put great emphasis on a tech lead (who would be doing what I expect an architect to do). The great principle here is that you need at least 3 leaders on a team:

• The Project Manager (Program Manager in MSF)
• The Tech Lead
• The Product Manager

The tech Lead (Architect) takes on the million technical details of a project and the leads the design and development process. The Product Manager is a business representative whose job it is to coordinate the million business details of a project, gather requirements at the business level form stakeholders, and is the business Point of Contact for the project. The Project Manager is responsible for managing schedule, LOE against budget and is the buffer between the Architect (yes I switched terms in mid-stream, good catch) and the Product Manager.

The bottom line is that a strong team needs a good technical mind and a good business mind and a good manager / organizer mind. When the business folks are pushing for more features, the project manager is asking the architect what the impact is and then relaying that back to the business folks. No surprises, scope creep is managed. If a change is scope is really needed, all go into it with eyes wide open.

So then, why not just a tech lead? Because just as the skills required for project management differ from developer skills, architect skills differ somewhat from tech lead skills. A good tech lead certainly has architectural savvy to at least some extent. An architect though is used to always considering the big picture. He or she can step back – and *stay* back, keeping his mind on the larger view. The architect will let the tech lead and developers do their job without micro-management, and yet they are always there to help and advise if needed.

So do all project need a dedicated architect? Yes and no. Certainly on a smaller project the tech lead can function as the architect, but must keep in mind the big picture, the long-term view. Its easy to be inundated with micro-details and miss the larger issues that have great effect over the long haul. On a mid-size or larger project, having an architect (of the type Mr. Fowler describes) can make the difference between overwhelming success and the other alternative.

Take some time to read the article and ponder it. I think it will be more than worth your time. Get the article here.

Related posts:

1. Why Just Enough Technology?
2. Using Rational XDE with Visual Studio .Net
3. Craftsmanship and Software Development

I’ve been going over some articles I wrote over the years and have resurrected a few for Just Enough Technology. They are interesting in that the ideas are (usually) still valid and relevant in today’s world. This article was the basis of my focus on .Net over the last 7 or 8 years. I’ve created significant applications in both Java and .Net, and I am a great believer in choosing the right technology for the job. That could be Java or .Net or something else. This article contains some tidbits of truth concerning selecting the best technology based on real criteria – that is, criteria that are based on solving a business problem, not an arbitrary preference.

How does one go about comparing the relative strengths of and differences between the Microsoft .Net platform and the J2EE platform?

This question is being asked daily in one form or another in companies across the globe. In today’s Enterprise Application development world, there are 2 main players in the arena: Microsoft’s .Net and Sun’s J2EE. IT directors, CIO’s, software architects and developers are faced with the choice of a platform on which to base not only their next application, but possibly the company’s core applications for years to come. This decision is important to IT’s ability to respond to business needs, now and future and involves not only the evaluation of the technology itself, but of the company or companies behind the technology.

One might conclude that because of the importance of these decisions, that due diligence is routinely applied and objectivity is maintained when making such decisions. In my experience working with Fortune 1000 clients, I have surprisingly observed this not always to be the case. Often, management is influenced by the well-intentioned leading of respected technologists within the organization, who, though they thoroughly understand the technology they recommend, are not necessarily objective in their comparative evaluation of competing technologies. In some cases, I have seen this lead to the adoption of a technology platform which was just wrong for the company and which was ultimately discarded (incurring the cost of reworking the applications in another technology).

Before I continue, let me first say that I have a firm opinion on this subject. It is an opinion that has been reached through much experience, both hands-on as a software architect and from a high level as a business development consultant and architect. My purpose in this brief article is to outline my thinking and criteria for reaching this opinion, more than it is to present my conclusions. Perhaps there will be a follow-on article where I will dissect my reasoning more completely. Let me also state that I have designed and developed successful, even award-winning applications in both platforms. Core to my conclusions is the firm belief (borne from experience) that is equally possible to design performant Enterprise applications in either platform.

There are at least two components that must be considered when comparing these platforms; the technology itself and the company behind the technology that you will be partnering with. Starting from the preconception that either technology enables high-performing, enterprise-level application development, we must seek out the differentiators of each technology and its vendor(s). If both technologies support true enterprise application development, do they handle this task in the same manner or with the same degree of ease? Of course not, so lets list a few of these differences. For now I’ll simply list the individual points and we will cover them in more depth in a later article.

.Net

• A single vendor solution
• Designed to specifically integrate with many other supporting applications from the OS, to the database, to satellite applications such as BizTalk and CMS.
• Includes the best, most efficient development environment (IDE) available today (in my opinion).
• Greatly facilitates UI development, particularly web UI development (this will be enhanced even further with the upcoming release of ASP.Net 2.0),
• Allows multiple language use
• Limited to the Windows family of server OSs.
• Very good direct vendor support with add-ons and architecture guidance from the vendor.
• Lends itself to faster time to market development timeframes.
• Tends toward a horizontal scaling architecture

J2EE

• A multiple vendor solution
• Each vendor supplies differing supporting applications such as a CMS or workflow management system.
• Each vendor supplies a differing application server such as WebLogic or WebSphere.
• Core code is based on the same JDK.
• Multiple vendors provide IDEs with different capabilities.
• Provides Open Source implementations of functional packages that may or may not find their way into the core (Struts for example).
• A single language solution (theoretically it is possible to create compilers and runtimes for other languages, but it is not done in practice)
• Runs on multiple OSs.
• Support is dependent on the vendor and may involve multiple vendors if a number of vendors are chosen for various facets of the architecture.
• Tends toward a vertical scaling architecture

Reaching a conclusion

The process for reaching a conclusion on an architectural platform must as we mentioned take into account the company(ies) behind each platform as well as the relative merits of each platform. If you know me or have been following my .Net site, you have divined that my decision has been for .Net. Part of my reasoning is that .Net is, for the most part, a single vendor solution. That is certainly not to say that .Net is not supported by a multitude of third party vendors, but the core framework is managed and developed by Microsoft. I believe this brings a decided edge to .Net in that Microsoft can coordinate efforts (as they are doing with .Net and Yukon) to strengthen .Net through supporting technologies. IBM can do this to some degree with the WebSphere family, but in practice it is more difficult for Java provider. If IBM is chosen as a vendor and the intention is to utilize many of the other WebSphere family of products, in essence, a decision has been made to go with a single vendor. It may be a good decision at that. What can be lost is the ease of porting applications or code to other vendors products or the ease of integrating other vendors products. This is one reason why I believe interoperability is of greater relevance than portability.

Another factor in reaching a decision must be the corporate culture of your organization and its openness to new ideas and new ways of thinking. Current skillsets must also be considered, but must not become the sole or even the major criterion. Skills can be taught or acquired through hiring. An objective evaluation of these factors must be made. If the IT group just does not like the technology chosen, successful implementation is almost impossible. In addition, the cost to retrain developers in a different technology must be appreciated.

When all is said and done, the criterion that should be foremost is the bottom line: Which platform will enable the highest positive business benefit? This is not always measured in terms of hard dollars (though it certainly often is), but in terms of “soft” dollars – productivity gains, client satisfaction level gains, employee satisfaction level gains, etc. It seems foundational – but also seems to be often forgotten – that software has no meaning unless it provides some business benefit. The greater the benefit, the “better” the software is. Technologists often concentrate on the internal benefits of software – it runs faster, it handles more transactions, etc. While these considerations are part of the equation, the bottom line is the relative business benefit. For an extreme example, an application built to handle hundreds of thousands of transactions but that takes thousands of developer hours to construct, test and maintain, may not have great relative business benefit for a departmental intranet application.

One more thought on this idea of business benefit. When evaluating software or platforms, it is important to correctly separate the benefits from the features. OK, it’s time for a pop-up quiz!

Which of the following is a benefit and which is a feature?
a. The architecture is scalable
b. The architecture can handle 500,000 tpmC

OK, this was a trick question, sorry! Actually, both answers are features. The benefits of these features might include things like: “Users will not experience application slow-downs even at peak usage times” or “We will not incur extra costs for rearchitecting the solution even if our user base quadruples”. You get the idea.

So what does all this have to do with choosing between J2EE and .Net? These ideas are basis of my thought process in making my evaluation. They are certainly not the only criteria, but I believe they describe how I think about technology in general. It is because of how I view technology as a part of the greater scheme of business in general that I am drawn to .Net and other Microsoft technologies. I always have the end in mind. The software is the means and not the end. The overall benefits of .Net in terms of development efficiency, ease of development, tool support, forward thinking by the vendor, and timely innovation lead to applications that can be developed faster, at less cost and with more features in my experience (providing greater business benefits).

One last illustration. We are all familiar with the resource triangle. There are three components to any development effort: Resources (people and dollars), Time and Features. They are all inter-related. By basing an architecture on a platform that can cut development time, add features and in some cases, cut resource costs, we have a winning solution. For me, that winning solution is .Net.

Addendum: Perceptions

The following are a few perceptions that are not based in hard truth, but are what I call “perceived truth” – preconceptions based on the perceiver’s viewpoint or other unrelated factors:

J2EE is more “industrial strength” -
this is simply untrue, though it can be said that some J2EE applications are more industrial strength than some COM or .Net applications. In a later article, we’ll explore this preconception more thoroughly. One reason for this perception, in my opinion, is the accessibility of Microsoft development tools. Microsoft has done an excellent job providing great tools that enable users who are not expert-level developers to create usable applications. One side affect of this is that some of these users attempt to build enterprise applications without the base understanding of the requisite architecture, design and best practices. There are no practical limits to the strength of .Net applications but best practices for architecture and design must be followed, both in .Net and in J2EE.

.Net is good for Rapid Prototyping or departmental applications, but the core architecture should be J2EE based -
It is true that .Net lends itself better to Rapid Prototyping and smaller, departmental applications, but this does not obviate its ability to be used to create true Enterprise applications. What is true, is that it is much more difficult to create departmental projects with J2EE. This has do in part  with the innate complexities of OOP that are usually not compensated for by the J2EE IDEs. J2EE in general does not easily lend itself to adoption by mere mortals, so to speak.

All of a company’s applications must be built using the same platform. We need to rewrite all of the legacy applications now -
The truth is that legacy applications have had a lot of investment poured into them over the years, both in terms of dollars and in terms of knowledge. In the real world we live in today, it is important for applications to interoperate, both to support legacy applications and to support the common reality that, especially in larger companies, more than one modern development platform may be present. Both J2EE and .Net provide the foundations for this kind of integration, though there are (of course) implementation differences.

Related posts:

1. Java vs. .Net – Another Blast From the Past
2. Craftsmanship and Software Development
3. Why Just Enough Technology?