cloud computing

What are your software’s vital signs?

Most software has a profoundly inadequate concept of “health.” In order for applications to run, they must:

  • have adequate resources (RAM, disk, network, CPU)
  • receive cooperation from services exposed by the operating system or by network endpoints
  • be adequately and correctly configured
  • not be hacked
  • acquire delegated privileges from users

… and so forth. And yet, most software that I’ve encountered in my career does little to see whether it’s working properly and has what it needs. Sure, it may log a catastrophic error if the disk fills up, but it makes no effort to see the problem coming or to plan more graceful recovery than a crash.

In my most recent post on cloudifying your software, I explore how cloud computing is magnifying the need to understand and to regularly check your software’s vital signs. Head on over to adaptivecomputing.com/blog and check it out.

Checking vitals isn’t just for healthcare… Photo credit: U.S. Pacific Fleet (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.

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.

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.

Big Crud Isn’t Big Data

“Big Data” is another one of those buzz words that seems to be everywhere these days. We hear stories regularly about how fast the world’s data grows and how big it’s going to be by 20xx. Vendors then reason that we should buy their wares to cope. This infographic is typical:

dataneversleeps_2-0_v2

I have several deep professional connections to big data[1], going back decades, so when I say I think a lot of it is manufactured silliness, I’m hoping you’ll pause before laughing me off.

The fact is, most of the “data” that’s exploding is not hard-won intellectual treasure for the ages; it’s marginal stuff like the viewing history on Fred Flintstone’s deleted Netflix account. More than big data, we’re experiencing a “big crud” wave, because we’re pack rats. This comic has it right: Continue reading →

Adios to “computer programming”

Have you noticed how seldom people put the modifier “computer” in front of “programming” nowadays?

This may be because our formerly esoteric discipline is now so mainstream that it needs no elaboration.

It may be that we’re all growing lazy.

But I think there’s something deeper.

“Software Engineering” isn’t good enough

The set of things besides traditional computers that need to be programmed is growing by leaps and bounds: TV remotes, holiday light displays, e-readers, smartphones and tablets, Arduino boards, fuel injectors, point-of-sale terminals, MRI machines, 3D printers, LEGO MindStorm robots, networks (software-defined networking / SDN), storage (software-defined storage / SDS), nanobots, social networks, clouds…

Nanobots replicating in a petri dish. Is it fair to say we “program” nanobots? Photo credit: PhOtOnQuAnTiQuE (Flickr)

“Right,” I hear you say. “That’s why I like the term software engineering. Wherever you see programming, it’s software that’s in play. And engineering implies a more sophisticated approach than mere hackish programming.”

Okay.

I think that’s true, but it misses the really big insight. Continue reading →