cloudify

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.