Smart Design in Containers

In a previous article, we invented "Conway's Corollary" - how design determines scale.

Today, we will look at another case from the hottest technology of the last year: containers.

When designing software - any piece of software - the most important criterion is not, "what features does it have," or "how well is it documented," although those are very important. It is not even, "how sexy is the user interface," although I like great interfaces.

The most important question is, "how will it be used."

When software is designed well, with the user in mind, the software becomes a pleasure to use and manage, and makes for easy processes. When it is designed solely from the engineer's or designer's perspective, i.e. someone who has a hard time getting into the user's metaphorical shoes, the experience can be painful.

The original Microsoft Word was a "great" example. Microsoft leveraged its dominance in the desktop operating system market to gain equal dominance in the word processing market. But the product, especially in its early years, was shoddy, poorly designed and hard to use, certainly compared to some of its competitors.

Menu items were located in places you didn't expect them; key shortcuts had no relation to one another; help was hard to find. It was the dream of the engineers who designed it and the nightmare of its users.

Over time, of course, it either improved or we got used to it, most likely a little of both.

What does all of this have to do with containers? Managing containers across a large-scale environment requires an "orchestrator" to, well, orchestrate the containers. One of the well-designed ones is Rancher.

While Rancher has a good interface, immutability mindset and an excellent UI, along with a dedicated team who is probably one of the best on containers, their redundancy strategy leaves something to be desired. While it is very easy to set up a single orchestrator server, setting up several, for redundancy, is incredibly painful. To their credit, the Rancher team is working on it... and I have been impressed to date with their ability to deliver rapid change.

But the issue is deeper than how hard it is to set up redundant servers. It is whether you have a single server and a failover, or even two active, or whether you have multiple active at once and can add/remove any one of them at will with no disruption.

It is more than if the agents can connect to the server or the standby; it is whether agents are intelligent enough to handle multiple of them at once.

In short, it is about IT design vs Cloud design.

In IT, you think about big shared storage, primary and failover, static items, long-running services, lots of human management. In Cloud, you think about ephemeral services that can disappear at a moment, instant creation and re-creation, immutability, large-scale automation.

Cloud software is designed with a different mindset from IT, one that is hard to bridge until you have seen the other side.

I recently met with a very bright executive who hired a talented cloud systems person specifically to separate cloud services from IT administration... and it worked.

My favourite example of cloud design vs. IT design long predates cloud... and has cost companies billions.

Two of the most important protocols on the Internet are Web (http) and Mail (smtp). Yet the two could not be more different.

1. Mail: When my mail server wants to send mail to you@someplace.com, it looks up "who accepts mail for someplace.com." It receives not one response, but multiple, with priorities. If it cannot deliver the email to the first server, it falls back to the second, and so forth. The mail delivery software is intelligent. It can handle multiple service providers (or "servers") intelligently.
2. Web: When my Web browser wants to connect to the ever popular and incredibly deep www.atomicinc.com, it looks up, "what is the address for www.atomicinc.com." It receives, essentially, one answer. If it cannot connect to that server... it gives up.

Because of the difference in how smart the client design is - my mail server vs. my Web browser - companies have spent untold billions solving the Web server "availability" issue: DNS solutions, and load-balancers and global balancers and everything else. One company alone, F5, had $936MM in product revenues in 2014, the majority of which are for products that route Web traffic.

When was the last time someone bought a load-balancer or availability manager for email servers?

In the end, these affect revenues, even for on-premise software firms.

• On-premise: Software purchasers happily will pay a premium for software that takes them less cost up-front to install and especially less to manage on an ongoing basis.
• Cloud: The faster you can deploy, the quicker you can respond, the higher the premium you can charge, beyond the cost savings in demanding less effort of your team.

Summary

Smart design, one that designs from the beginning for how you manage the product, rather than asking the people who manage it to adapt, has a material impact on flexibility to respond to customer requests, your overall speed, your costs and your revenues.

Are you an IT company or a Cloud company? Ask us how much faster you can be.