This week on the Adaptive Computing blog, I write about what it was like to start up a modest supercomputer on the Amazon cloud. Check it out…
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.
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.
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.
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 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:
I have several deep professional connections to big data, 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
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…
“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.”
I think that’s true, but it misses the really big insight. Continue reading