Bet you never thought that AI would have tremendous applications to the field of computer security. AI’s challenge: Someone logs into your network or multi-user system using Dave’s userid and password. Can your computer be sure that it’s Dave logging in, and not someone who’s borrowed his password or cracked the system’s security measures? Can your computer be sure that Dave is not preparing to perform malicious activities?

First let’s verify that it’s really Dave who logged in. Over the past several years, computer-security researchers at SRI, Mitre, and other organizations (including the U.S. government) have learned that individuals have distinctive system-usage signatures. Data that can make up that signature include the name (or type) of programs executed, the method of changing system directories, the login time, and session length. Let’s say that Dave normally uses the mainframe during business hours to read e-mail. One Saturday night around 2:00 a.m., he logs in, scans the system read-only directories, and then attempts to rewrite the master password file. There’s a good chance your system’s been infiltrated.

That’s a simple scenario, of course. Programmers, who perform a wide variety of computer activities at all hours of the day and night, are more difficult to validate than 9-to-5 data-entry clerks. On an academic network, you’ll frequently need to recalculate your baseline models for each user as his or her expertise grows. The computer is vulnerable if hackers break into a new user’s account before there’s enough data to train the neural net properly or construct the model. Still, studies show that if the operating system is gathering the proper data, AI techniques can be applied in this area.

Expert systems can be applied to the second problem, trying to detect if Dave (or the intruder using Dave’s account) is misbehaving. A network monitoring tool can. see what commands Dave is issuing (like changes to other user’s files, or altering permission flags for various files). If the knowledge base contains data on known ways of hacking superuser privileges or crashing the system, it can watch for that type of activity. If Dave issues the first two commands in a dangerous three-command sequence, the expert system could alert the systems operator, flash a warning on Dave’s screen (“What are you doing, Dave?”), or even lock his account out of the system.

Perhaps you’re thinking that Big Brother is watching. You’re right. Instead of Orwellian thought police monitoring your private conversations, you might soon have AI software watching your every keystroke. Given today’s business realities, we might as well get used to that unpleasant idea.

I wrote the above essay in June 1994 and recently stumbled across it. Eighteen years later, it’s still relevant.

Z Trek Copyright (c) Alan Zeichick

Which cloud models are developers working with? The short answer is – many different models are in play.

In May, we enlisted subscribers to SD Times and News on Monday to help us understand how they are building and testing applications using the cloud, and how they are deploying completed applications into the cloud. We had 425 responses – you can read many of their answers in last week’s Take, “Looking for the action? You’ll find it in the cloud.”

Let’s continue walking through the study. Of those who indicated that they are or soon will be using the cloud, the top 10 responses were:

Software-as-a-Service (SaaS) 54.4%
Platform-as-a-Service (PaaS) 40.9%
Private Cloud 37.7%
Virtual Private Cloud 34.2%
Infrastructure-as-a-Service (IaaS) 32.7%
Hosted Virtual Machines 27.8%
Database-as-a-Service (DBaaS) 26.7%
Public Cloud 24.6%
Hybrid Cloud 21.4%
Community Cloud 8.2%

There’s quite a wide range of answers – which may indicate a wide variety of need, or in my opinion reflects confusion in the marketplace. There’s little convergence or consistency in the use of phrases like Software-as-a-Service, Platform-as-a-Service or Infrastructure-as-a-Service.

What about specific technologies being used for cloud computing? The study asked about that as well. The choices were a catch-all – some of them reflected messaging infrastructure, some were application frameworks, and others were presentation-layer technologies. Here are the top 15 responses from those who said they are using the cloud or plan to begin doing so soon:

HTML5 60.9%
.NET 57.3%
Cloud-enabled APIs 53.0%
Virtual machines 44.8%
HTML 38.8%
Java EE 37.7%
REST 35.2%
SOAP 28.1%
SOA 21.7%
JDBC 21.7%
ODBC 16.4%
Spring 10.3%
Hyper-V 10.0%
Rails 8.9%
JAX 5.7%

With the high response for .NET notwithstanding, the most popular programming language for cloud-based development was reported to be Java. The top 15 responses, by those who are doing or plan to do cloud development, are:

Java 59.6%
C# 48.9%
Java Script/ECMAScript 46.4%
C/C++ 28.9%
PHP 28.9%
Visual Basic 18.2%
PL/SQL 17.1%
Python 15.0%
Ruby 14.6%
Perl 9.6%
Groovy 4.6%
Pascal/Delhi 1.8%
Scala 1.4%
Clojure 1.1%
Erlang 1.1%

Are you clear on the meaning of terms like SaaS, PaaS or IaaS? Which technologies and languages are your organizations using?

Z Trek Copyright (c) Alan Zeichick

The temperature is rising, at least when it comes to developing and deploying in the cloud. In a survey of SD Times subscribers, 44.0% said that they are currently using the cloud to build or test applications, or to deploy applications. Another 24.9% said that they are not currently using the cloud, but expect to within the next year.

Breaking that down, of those who say that they are using the cloud, 26.0% say they have already built or tested several applications using the cloud and 22.8% are building their first application. Almost all of the remaining respondents say they are studying the issue; a very few plan to use the cloud only for deployment, not for development.

On the deployment side, of those who say they are using the cloud, 19.6% say they have deployed several applications into the cloud; 11.0% have deployed one application; 13.5% are developing productions applications but haven’t deployed them yet, and 11.7% are creating pilots or prototypes. Most of the rest are studying the issue, but a few plan to use the cloud only for development, not for deployment.

That’s a lot of cloud – higher, frankly, than I expected. Digging deeper into the data shows that when it comes to the cloud, adoption is moving fast, driven not only by the financial benefits of cloud computing, but for technical reasons as well.

The survey, conducted in May, was completed by 425 subscribers to SD Times and News on Monday. Most of the respondents are enterprise software development managers. One of the questions asked for the reasons why the respondent (or his company) is deploying applications to the cloud.

Of those who indicated that they are or will be using the cloud, the top 15 reasons are:

Scalability 58.5%
Long-term operating cost savings 48.7%
Reducing/eliminating capital costs 41.1%
Improve access to applications 35.6%
Ease of deployment 33.5%

Freedom from upgrades and hardware upgrades 26.9%
Simpler capacity planning 26.2%
All users are on the same version 24.0%
Shortened development cycle 23.3%

Improve application integration 23.3%
Short-term operating cost savings 22.9%
Better application performance 19.6%
Reduced need for power/cooling 19.3%
Spread costs out over time 18.9%

You can see the mix of technical and financial benefits – which points to the long-term viability of the cloud. It’s not simply another buzzword.

Of course, when someone talks about the cloud for developing or deploying applications, there’s some ambiguity. Some cloud service providers offer a straight-up hosting environment for virtual machines, where you’re renting little more than storage, CPU time and bandwidth. With others, you are getting a full-on development environment, customized for highly distributed applications.

Are you developing or testing in the cloud? Are you deploying in the cloud? If so, what are your top reasons?

Z Trek Copyright (c) Alan Zeichick

Every year, I look forward to the judging and unveiling of the SD Times 100. The editors of SD Times and SDTimes.com spend literally months discussing the state of the industry, talking about leaders and innovators, where things are heading, who made the most impact, and which companies and projects truly made a difference.

We tweeted out the 2012 SD Times 100 on Thursday, May 31, and posted the results online the following day. Subscribers to SD Times could also read it in their June issue.

But just like an exciting horserace is followed by picking up litter around the viewing stands, so the week following each years’ SD Times 100 is filled with responding to queries by corporate marketing departments. Why, oh, why, didn’t we chose them?

Here is an email from a nice, but unhappy, PR professional:

Hi Alan,

Are you in charge of the SD Times 100 awards? I’m just curious if you can give any feedback on my client (redacted) not making the list but (competitor) has made it now twice in two years. Just want to know if it’s the criteria not being met or any kind of feedback would be helpful to go back to them with.

My response was short, and to the point, but sadly wasn’t what she wanted to read:

Thanks for your email. I’m one of the team of judges of the SD Times 100.

As a matter of policy, we never comment as to why a company was not named to the SD Times 100 — any more than the Oscar judges would have an official reason why a certain movie wasn’t named as Best Picture.

To help explain why, let me share two links from my blog. They give you a much longer, fuller answer to your question.

http://ztrek.blogspot.com/2009/06/post-sd-times-100-week.html
http://ztrek.blogspot.com/2008/06/why-you-didnt-win-sd-times-100.html

I know that’s not the feedback your client is looking for, but that’s the best we can offer.

Z Trek Copyright (c) Alan Zeichick