Encapsulation isn’t just for code

When computer science folks talk about encapsulation, they are usually thinking of how the principle applies to objects and functions inside a codebase. Best practice calls for a separation of concerns–each object responsible for one type of work, hiding all details from its neighbors.

That’s great. But it’s not the only way encapsulation ought to show up in software.

In actual deployment, software packages often manifest anti-patterns in the way that they are configured. A web server has to know all about three different database servers that contribute data for its pages; HA failover scripts must know the identity and responsibility of every actor in the system, as well as many particulars about how these entities use resources to accomplish their tasks.

No wonder our deployments are fragile and high-maintenance…

The cloud computing wave is raising the bar for encapsulation in the way applications–not just objects–discover and interact with one another. In this week’s installment of my series of posts about how to “cloudify”, I discuss how role-based interactions insulate components from details they don’t need to know. It’s encapsulation all over again. And this encapsulation pattern manifests itself in unlikely places–like the order queue at McDonald’s…

What can McDonalds teach a developer of cloud-friendly software? photo credit: phogel (Flickr)

Stay tuned for further installments of this series each Friday. As I said in Part 1, I believe that a competence with cloud–cloud-oriented programming, if you will–will be a checkbox on future tech resumes.

Convoys as a model for distributed architectures

It occurred to me this past week that convoys–especially the kind where truckers form and manage ad hoc communities through chatter on CB radio–are an excellent model for the sort of distributed software architecture that cloud-native software demands. In part 2 of my series of posts about how to “cloudify” your code and designs on Adaptive Computing’s website, I discuss the lessons that programmers ought to absorb from their role models in big rigs. Head over there and check it out.

Convoys require frequent, real-time, adaptive coordination by many independent actors. Photo credit: Sangudo (Flickr)

Stay tuned for further installments of this series each Friday. As I said in Part 1, I believe that a competence with cloud–cloud-oriented programming, if you will–will be a checkbox on future tech resumes.

Programmers: learn how to “cloudify”

The blogosphere has plenty to say about cloud computing, but most content targets the business, CIO, or IT crowds. Information exists for developers who want to produce software friendly to cloud computing, but it’s more scattered, it’s vendor-centric, and it doesn’t match the SEO profile that obsesses much of the industry. As a result, I believe that many developers have only hazy ideas about how they can leverage the power of the cloud to provide radical improvements in scale, responsiveness, and connectivity for their customers.

This ought to change. Cloud computing isn’t just interesting to datacenter managers; it enables many new technological strategies. Cloud-savvy engineering can boldly go where no software has gone before—if we’re smart enough to take it there.

Clouds on the horizon… Photo credit: fir0002 | flagstaffotos.com.au

On my company’s website, I’ve begun a new series of blog posts about how to “cloudify” your code and designs. Read the inaugural post, and check back on Fridays for new installments in the series. I’ll be making connections back to concepts here on codecraft, such as what the programming language of the future ought to look like, how to encapsulate for cloud, and so forth.

I believe that a competence with cloud–cloud-oriented programming, if you will–will be a checkbox on future tech resumes.

6 Strategies to Simplify Software

How do you make things simple?

I’ve written that simplicity is powerful, and that it undergirds many deep architectural breakthroughs. In posts about pragmatism and balance, I’ve quoted Oliver Wendell Holmes about the simplicity on the other side of complexity.

But I’ve never talked about how to achieve it.

photo credit: hurley gurley (Flickr)

This is not an easy question; if we knew how to make things simple, we’d do it more often and more quickly. It takes some serious effort (and genius) to go from centuries of experiments and volumes of equations to e = mc2. I’ve been pondering simplicity in software architecture for a decade, and I’m certain I’ve only scratched the surface.

Still, simplicity is a learnable skill, and some strategies are consistently helpful… Continue reading

Don’t forget the circuit breakers

Recently I’ve been pondering an interesting book called Release It!, by Michael Nygard. It’s full of anecdotes from someone who has spent a major portion of his career troubleshooting high-profile crashes of some of the most complex production software systems in the world–airline reservations, financial institutions, leading online retailers, and so forth.

circuit breaker

A circuit breaker. Photo credit: Wikimedia Commons.

One design pattern that Nygard recommends was new to me, but it rang true as soon as I saw its description. Like many classic patterns, I’ve implemented variations on it without knowing the terminology. I like Nygard’s formulation, so I thought I’d summarize it here; as I’ve said before, good code plans for problems.

The pattern is called circuit breaker, and its purpose is to prevent runaway failures.

In systems without circuit breakers, failures in an external call may cause an exception on the caller’s side; this can cause the caller to log, retry, and/or execute other specialized logic. Since errors are supposed to be the corner case, the blocks of code that handle them are often expensive to execute. The very slowness of the error-handling codepath can be the source of further failures, because locks are held longer than normal, or because we poll until a connection is restored, overwhelming a system that’s already limping.

Or, to borrow an old idiom, “it never rains but it pours.”

In the circuit breaker pattern, on the other hand, the caller assigns each “circuit” (a codepath that invokes an external entity) to one of three possible states: closed, open, or half-open. Continue reading