Wednesday, February 4, 2015

Components, objects, containers

Thirty years ago the big evolution in software was objects, and the objective of objects was to make software more like hardware insofar as you assemble objects into systems, and then address the object through a specific interface -- the API, or application programming interface.

And, no small matter, the objective of object programming was to transform software art and science into software engineering, a direct parallel to hardware engineering: make things according to spec's, assemble them at their interface, and they work!

And, of course, reuseability: design and build the object once; reuse it many times. Within the the object, components are just the lower level blocks within objects.

Then, of course, virtual machines and run-anywhere language, like JAVA, which gave rise to portability across different hardware. Just bring your VM and objects with you and you can run anything anywhere

What's not to like?

Well, the weight of a VM for one. A VM operating system is no small matter, and sometimes it's just overwhelmed. And, the cloud raises the scale of things, making the object a bit too low level.

Now comes 'Containers', and analogy is to the shipping containers that come on trucks and ships. Containers have been around about a decade, but lately they've gotten more buzz with the cloud. The advantage is that containers have boundaries and interfaces something like objects, but they typically contain many objects that give rise to an application, and containers run on over a lightweight "engine" that is less burdensome to the host than a VM OS.

But here's the news for many project offices: In some cases it's practical to take existing large scale programs and restructure them into many smaller containers.
Gilt Group, an online store, turned seven big applications in its website into 400 smaller pieces, making it easier to update
PMO and Containers
Two advantages:
  1. Now your PMO has a library of reuseable containers, making estimating your next project all the simpler, but
  2. Also you're closer to the Agile world of smaller functional units, and units that can be used in shorter smaller scale iterations to build functional entities.

Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!
Read my contribution to the Flashblog