Stop Wasting Money On WebLogic, WebSphere, And JBoss Application Servers

Use Apache Tomcat. It is free.

I don’t understand why firms spend millions of dollars on Java application servers like Oracle Weblogic or IBM WebSphere Application Server. I get why firms spend money on Red Hat JBoss -- they want to spend less on application servers. But, why spend anything at all? Apache Tomcat will satisfy the deployment requirements of most Java web applications.

Your Java Web Applications Need A Safe, Fast Place To Run

Most Java applications don’t need a fancy container that has umpteen features. Do you want to pay for a car that has windshield wipers on the headlights? (I wish I could afford it.) Most Java applications do not need these luxuriant features or can be designed not to need them. Many firms do, in fact, deploy enterprise-class Java web applications on Apache Tomcat. It works. It is cheap. It can save tons of dough.

Expensive Java Application Servers Sometimes Add Value

There is a need for luxury. But, you probably don’t need it to provide reliable, performant, and scalable Java web applications. Application server vendors will argue that:

  • You need an application container that supports EJBs. EJB3 fixed the original EJB debacle, but why bother? Use Spring, and you don’t need an EJB-compliant container. Many applications don’t even need Spring. EJBs are not needed to create scalable or reliable applications.
Read more

DevOps Is About Collaboration; NoOps Is About Automation

NoOps Is The Peak Of DevOps.

DevOps is a noble and necessary movement for immature organizations. Mature organizations have DevOps down pat. They aspire to automate to speed release increments. 

NoOps will not replace DevOps; rather, it is an evolution of the release management aspects of DevOps. NoOps is the goal of DevOps.

DevOps Versus NoOps

Are you ready to shoot for NoOps?

Categories:

Ballmer's Masterstroke In Buying Skype

Steve Ballmer Does Not Like To Lose

With Microsoft's plan to acquire Skype for $8.5 billion, Steve Ballmer is doing a Jason Voorhees in Crystal Lake. Let me explain. Microsoft failed miserably at mobile. While the boys and girls in Redmond were contemplating how to put the "Start" menu on a phone, Steve Jobs was cleaning mobile clocks with the iPhone. But, like all great competitors, Microsoft knew they lost it. So they started from scratch. The result: Windows Phone 7. In my opinion, an awesome mobile platform on a par with iPhone, albeit with a lot less cultural cachet. The problem: The momentum favors iPhone and Android. Microsoft needs an ace card. Ballmer, potentially, found an ace card in Skype.

With 633 Million Users, Skype Is A Communication Juggernaut

Skype is not a phone. It's a way to see your three-year-old granddaughter, connect with your adult children, or make sure your family is safe 4,000 miles away. And, it's mostly free. Of the 633 million users, fewer than 8 million are paying users. No matter. What is important is that many of these users would love to make free calls on a mobile phone.

Read more

Cloud Computing Will Save IT Millions, But Only If You Have Elastic Applications

Do you keep every single light on in your house even though you are fast asleep in your bedroom?

Of course you don't. That would be an abject waste. Then why do most firms deploy peak capacity infrastructure resources that run around the clock even though their applications have distinct usage patterns? Sometimes the applications are sleeping (low usage). At other times, they are huffing and puffing under the stampede of glorious customers. The answer is because they have no choice. Application developers and infrastructure operations pros collaborate (call it DevOps if you want) to determine the infrastucture that will be needed to meet peak demand.

  • One server, two server, three server, four.
  • The business is happy when the web traffic pedal is to the floor.
Read more

The Application Server Bubble Is About To Burst

Traditional application servers such as WebSphere, WebLogic, and JBoss are dinosaurs tiptoeing through a meteor storm. Sure, IBM, Oracle, and Red Hat still have growing revenue in these brands, but the smart money should look for better ways to develop, deploy, and manage apps. The reason: cloud computing.

The availability of elastic cloud infrastructure means that you can conserve capital by avoiding huge hardware investments, deploy applications faster, and pay for only those infrastructure resources you need at a given time. Sound good? Yes. Of course there are myriad problems such as security and availability concerns (especially with the recent Amazon mishap) and others. The problem I want to discuss is that of application elasticity. Forrester defines application elasticity as:

The ability of an application to automatically adjust the infrastructure resources it uses to accommodate varied workloads and priorities while maintaining availability and performance.

Elastic Application Platforms Are Not Containers

Read more

Application Performance Trumps User Experience

I am not talking about The Donald here, thankfully. I am talking about how fervently impatient users are when it comes to website and mobile app response time. You can design a brilliant, luxurious, and intuitively interactive user experience, but if it doesn't perform well — as in response time — then the users will hate it. They don't want to wait. Why should they? They will just go somewhere else. Your job is to design and implement user experiences that are lovable and that performance spectacularly. 

Application Performance Management Starts During UX Design

Forrester defines performance as:

The speed with which an application performs a function that meets business requirements and user expectations.

To insure speedy application performance, organizations should start application performance management (APM) during the application design process. Too few user experience (UX) designers understand the performance implications of their designs. But, application architects must also help UX design professionals by finding clever ways to:

  • Boost performance.
  • Mitigate the effects of scale on performance.
  • Insure high availability.
Read more

Forrester's Mobile App Design Context: Location, Locomotion, Immediacy, Intimacy, And Device

They say "content is king." But, "context is kingier" when it comes to designing great smartphone and tablet mobile apps. Don't make the mistake of thinking that mobile app design is just about a smaller screen size or choosing the right development technology. Content and context are both important to designing great user experiences, but mobile amplifies context on five critical dimensions: location, locomotion, immediacy, intimacy, and device. Understand each dimension of Forrester's mobile context to design mobile apps that will make your users say "I love this app!"

Forrester LLIID: Location, Locomotion, Immediacy, Intimacy, And Device

  • Location. People use apps in an unlimited number of locations. And not all places are the same. A user may be in a quiet movie theater, at home in the kitchen, on a train, or in the White Mountain National Forest. Contrast this with desktop computers, stuck in places such as an office cubicle, home office, or kitchen. Laptops provide some mobility but are larger and less able to provide the immediate access of instant-on mobile devices such as smartphones, eReaders, and tablets. Location is a key dimension of context, driving different needs for users depending on where they are. Fortunately, GPS-equipped smartphones can use a geodatabase such as Google Maps to determine precise location.
Read more

Categories:

Three Megatrends To Master For Application Development

Hockey god Wayne Gretzky said, "I skate to where the puck is going to be, not where it has been." For application development professionals, three megatrends show you where to skate to be more successful:

  • Megatrend 1: Get faster. The recession that started in December 2007 created a hunker-down mentality. The sentiment for IT became: "We need to do more with less." As we emerge from the recession, albeit in an unresounding way, the new sentiment is: "We need to get faster." The pace of business change continues to accelerate, and that in turn has intensified the need for application development professionals to deliver and change applications faster. The industrialization of application development has failed. Scrap it. You must get faster, and that means changing your process, changing your technology, and changing your organization. Software development is more akin to making a movie than to making widgets on an assembly line.
Read more

Want Better Quality? Fire Your QA Team.

Seriously. I recently spoke with a client who swears that software quality improved once they got rid of the QA team. Instead of making QA responsible for quality, they put the responsibility squarely on the backs of the developers producing the software. This seems to go against conventional wisdom about quality software and developers: Don't trust developers. Or, borrowing from Ronald Reagan, trust but verify.

This client is no slouch, either. The applications provide real-time market data for financial markets, and the client does more than 40 software releases per year. If the market data produced by an application were unavailable or inaccurate, then the financial market it serves would crumble. Availability and accuracy of information are absolute. This app can't go down, and it can't be wrong.

Why Does This Work?

The client said that this works because the developers know that they have 100% responsibility for the application. If it doesn't work, the developers can't say that "QA didn't catch the problem." There is no QA team to blame. The buck stops with the application development team. They better get it right, or heads will roll.

As British author Samuel Johnson famously put it, "The prospect of being hanged focuses the mind wonderfully."

Can This Work For You?

Read more

The Nastiest Performance Bottleneck Is Often The Database

Some of the most joyful technical challenges I experienced as a developer were solving application performance problems. Isn't it fun. You are Sherlock Holmes - examining the architecture, diving into the code for clues, and scouring through logs files to find the bottlenecks that are responsible for snail's pace. However, this job is a lot harder than Sherlock Holmes or CSI. It is more like Dr. Gregory House, because you are racing against the clock. For every minute of sluggish performance, you could be losing eyeballs and therefore revenue. Worst case: the patient, i.e., your website, dies.

Performance Problems Are Usually Elevated Because Of A Crisis

Your business just launched a Super Bowl commercial that confidently directed people to your website - #fail. More likely, a new release of software performs like a dog (with apologies to Greyhounds) because of lame coding and nonexistent performance testing.

 You Need A Clever Solution, Fast

Read more