default: break;

We have been using Amazon’s Simple Storage Service (S3) at belacena.com for almost a year now.

Soon after launching the website, we started to feel some limitations regarding Apache’s, and later, lighttpd’s ability to handle medium-sized (6-15mb) .FLV files required for the video streaming.

After some system & web server optimizations, we kept hitting bottlenecks and decided to use a distributed content-delivery network such as Amazon’s S3 service. We could not afford more servers and cloud storage looked too good to be true.

Overall, we could not be more satisfied with the service. It is fast, reliable and very easy to use & integrate with your web applications.

Nevertheless, we have had two major outages since then: one in February and one this past week.

The first time, we were caught off-guard. The video streaming service was down throughout the outage. It was frustrating and we made an effort to handle such failures in the future.

We have always kept a local copy of the files we upload to S3, so we setup a cron script that runs every Nth minute and pings the main AWS S3 host. If it is down, we set a memcached variable to false and on the video rendering server page we check for this variable to decide if we should stream from S3 or from our local server.

Thanks to this, we were able to keep our service up during this week’s outage without having to worry about anything.

Update: Amazon has issued a statement concerning July’s 20th outage.

A language that I clearly avoided throughout the years was JavaScript. Actually, I was pretty turned off by web development as a whole from about 2000 to 2005.

Since then things have changed for the better and the AJAX frenzy brought us some good JavaScript frameworks like Prototype, JQuery and Dojo, to name just a few, and my rendition soon came.

These days we’ve got full blown GUIs built on it and even some cool games like Wolfenstein 3D got ‘scripted’.

Still, when I see a hack like this, I manage to be amazed.

How could I have missed the 10th anniversary of XML this past February?

Even though the new model of remote computing seems to reverse the 1980s “liberation” movement that gave individual users custody over programs and data, the shift does not necessarily restore control to managers in the corporate IT department. To the extent that cloud computing succeeds, it represents an obvious competitive challenge to vendors of shrink-wrap software. Ironically, the open-source movement could also have a tough time adapting to the new computing model. It’s one thing to create and distribute an open-source word processor competing with Microsoft Word; not so obvious is how a consortium of volunteers would create a Web service to compete with Google Docs.

• in Communications of the ACM, July 2008 Issue

Layers

As a Software Engineer with a critical eye on software development, I am truly fond of software architectures that are simple, functional & extensible.

I have praised several times the design of a, god forbid, Microsoft product called Reporting Services due to its greatly designed layered architecture, of which you can catch a glimpse here.

The communication protocols that have changed the world we live in today are based on such a layered model and, surprise, most software is.

The most common approach to developing software systems that operate on some sort of data is the seminal three-tier architecture separating Presentation, Business and Data.

Early on in my development career I tried to follow this approach, or some variation of it, and it clearly paid off, so I stuck with it.

Of course, this is only the first step in the natural evolution of a good software designer. Mastering design patterns quickly follows and not soon enough you’re dealing with domain specifications and shared information models.

But i digress. What I mean to stress here is: the implementation technology does not matter. the system design & architecture does. If you haven’t heard this enough, here it is again.

Still, I am surprised to see around me many (commercial) examples of such poorly designed software.

Dumb UI

The Smart UI Anti-Pattern is well described by Evans and is an example of a common problem in software I have come into regular contact with.

Typically, these systems have two layers: the presentation and the data layer, with the business logic spread between the user interface and the database, through the use of some sort of basic Workflows on the UI side and Stored Procedures and Triggers on the DBMS side.

This is even worse then the scenario described by Evans, in which the business logic is all placed in the interface, using the relational database as a shared repository of data.

Also, let me tell you that SQL means “Structured Query Language”. Query as in querying data. SQL is very useful for extracting data, not for applying business logic to it. The next time you use a cursor, you should be using an Entity or a Model of some sorts in your favorite OOP language.

When you have business & domain logic spread throughout both layers, maintenance, flexibility & integration have all gone down the drain. Yet, he still legitimates this approach when certain conditions are in place. I refute them:

• High & Immediate Productivity for Simple Applications. It comes at a cost. 5 years down the road, when you need to integrate your application with another COTS or the likes, it will burn you. Also, simple applications usually turn into complex applications.
• Less capable developers can work this way with little training. Hire capable developers and / or train them.
• Applications are decoupled from each other. Expanding the system with additional, simple behavior can be easy. When you add several simple “things”, then it becomes complex, no?
• 4GL tools work well. No refutation possible. Still, it comes at a cost.
• Easier maintenance. When in contact with several simple UIs that share a common domain model but there is no sign of that model in the code, just OnClicks and RecordSet iterations and Stored Procedure invocations that do not express adequately the logic being applied, how can it be easier?

The disadvantages are huge:

• Integration is difficult except through the database. Use a “Smart UI” when you are “dumb” enough to think that the data in your application won’t be of any use outside of it.
• There is no reuse of behavior, no abstraction. Business rules are duplicated. Bugs! Bugs! Bugs! Oh, my business logic changed and I forgot to make changes to all the Nth places that refer to this work flow.
• Natural limit for rapid prototyping & iterations. Ruby advocates will tell you otherwise :)

This rant is an effort to spread good design practices because the use and abuse of such anti-patterns have become so common that there is a whole business model built around them. It’s called Enterprise Application Integration and it enables you to pay to the consultant what you tried to save by not hiring capable developers or procuring yours COTS adequately when the time was right.