Category: software-engineering

Unexpected Downside of a SaaS

It just occurred to me today that despite all the positive things that SaaS companies continue to deliver, a lot of them have an interesting weak spot. In order to be successful, a SaaS must deliver superior product to what I would otherwise be able to build myself, plus deliver...

Read more...

JSON vs XML in API

George Reese recently wrote a blog post about API design, William Vambenepe commented here. This is an interesting topic, I have a post on this subject too - it’s titled Developing API Server - Practical Rules of Thumb. In this post I would like to expand on the first point...

Read more...

Developing API Server - Practical Rules of Thumb

I have been doing a lot of reading lately on how one would go about developing an API server. It’s an interesting topic, with various established schools of thought and multiple real-world implementations to compare against. In this post, I am going to summarize my findings, for my own reference...

Read more...

On Dangers of Prematurely Making API Public

From time to time, I come across a statement that every service on the Internet must have an API, or people behind this service are doing it wrong. This phrase usually applies specifically to publicly available API. As a user who stands to benefit from increased number of services allowing...

Read more...

Normal Accidents in Complex IT Systems

Designing a fully-automated or nearly-fully-automated computer system with many moving parts and dependencies is tricky, whether a system is distributed, hyper distributed or otherwise. Failures happen and must be dealt with. After a while, most folks grow up from “failures are rare and can be ignored” to “failures are not...

Read more...

The Concept of Hyper Distributed Application

Most folks in the industry are familiar with “distributed applications.” If app components are running on multiple hosts and need to communicate with each other using network, the app is said to be distributed. Distributed applications are known for complexity of assuring all components are on the same page as...

Read more...

Electrical and Plumbing Analogies in Application Monitoring

Water and electricity are two components without which a modern home can’t function well. Both are provided as a utility, and both have strictly defined access points from which they can be consumed - taps for water and outlets for electricity. But there are also differences. Every child knows that...

Read more...

Developer's Attempt to Define Cloud Computing

I have been closely following cloud computing for many months now. As a developer, I get often frustrated by lack of clear and widely accepted definition of what cloud computing actually is. This is a problem, because without a definition, every imaginable operation performed over the Internet all of a...

Read more...

Full Data vs Incremental Data in Messaging

My recent experiments with messaging for a distributed application led to a realization that I would like to share with you in this post. It’s not an earth shaking discovery but you may still find it interesting. Do you remember an old Unix command to create tape backups called dump?...

Read more...

Why I Sometimes Prefer Shell To Ruby or Python

Shell was among the first things I got familiar with when I was introduced to Linux. It’s not a typical programming language, primarily due to lack of easy-to-use high-level data structures such as hashes and arrays (anticipating your objection to this - note I said “easy-to-use”). This may explain why...

Read more...

Branching In Git When Working On Big New Features

A note to self. When starting to work on a new big feature, always set up 2 branches for it. Say FEATURE_work and FEATURE_integration. Do your regular development in FEATURE_work committing as often as you want. When you reach certain milestones (but entire feature is still not ready yet), squash...

Read more...

The Power of Knowing "Why?" in Software Engineering

I am currently reading “How Life Imitates Chess” by Garry Kasparov, after I saw a great review of the book by Baron Schwartz. Great book and I highly recommend it. It’s got many lessons for software engineers as well. For example, in chapter 9 “Phases of the game” Kasparov talks...

Read more...

Eliminating Single Points of Failure - One, Two, Many

I recently reached an interesting conclusion. When you are trying to eliminate a single point of failure from your architecture, it’s almost always beneficial to first go with a 2-way redundant solution (active-passive or active-active pair, whichever is easiest to implement) and only then go to N-way, N > 2,...

Read more...

Adjustable Per-URI Backend Capacity in Rabbitbal

I recently pushed a Rabbitbal update to Github - http://github.com/somic/rabbitbal. The biggest enhancement (IMHO) is ability to increase or decrease the number of backend consumers based on any HTTP request headers. In “table” routing mode (see rabbitbal.yml), you can now specify array of tests against which incoming request headers will...

Read more...

Perlbal Reproxy and HTTP Auth

I use Perlbal in one of the systems to reproxy requests to an internal URL. Reproxying to URL is a powerful feature that works like this. An HTTP request comes to Perlbal. Perlbal reverse-proxies it to one of its backend servers. Backend server does some work (in my case, does...

Read more...