Out of this world lessons from the Apollo Lunar landings — Part III
I believe that this nation should commit itself to achieving the goal, before this decade is out, of landing a man on the moon and returning him safely to the Earth — John F. Kennedy, May 25th, 1961.
President Kennedy did a great favour to NASA’s managers and engineers — he defined their goals in a very straightforward manner.
Man.
Moon.
Decade.
Safe.
Simple, isn’t it?
Kennedy’s goals can be split into two types:
Functional Goals: These are the “why” and the “what” types of goals. They describe the actual value that we get out of the effort we invest. For private companies, these goals are the money making goals; they are the reason their customers like them. Examples of functional goals for an application can be: Make bank transfers easier, play a fun game, have face-recognition in the next version of the app or even… launch a rocket that will reach the Moon.
Non-Functional Goals: These are the “how” types of goals. They don’t directly make you your money, but they are necessary to achieve the functional goals. Examples of non-functional goals for an application can be: The application has to be available 24x7, don’t let people steal private information out of the app, make sure I can recover information from last year in the app or even… make sure the astronaut gets back safely and the rocket doesn’t blow up.
As you can see, while there may be a natural urge to prioritize functional goals because they are the money makers, it would be unwise (extremely so) to ignore the non-functional requirements.
IBM Garage has a methodology based on design thinking which helps our customers identify the functional and non-functional goals they should concentrate on when they begin working with IBM Cloud. My personal field of interest resides closer to the non-functional side of things — we often call the domain of non-functional requirements in IBM Cloud by the name Cloud Service Management & Operations (CSMO).
While IBM Garage did not exist back in the 1960s, IBM certainly did and had a central part in the design and implementation of the Saturn V rocket.
The Saturn V basically had one functional goal: launch a 15,000 kilogram (30,000 pound) Apollo spacecraft to the Moon. But it had plenty of non-functional ones such as “fly smoothly so that your soft and squishy passengers don’t get crushed by G-forces” and “set your flight to adjust for to any erratic winds or misbehaving rocket engines”, not to mention “keep Houston updated about everything that happens”.
To achieve these non-functional goals, the engineers decided that the steel rocket needed a brain.
Cutting a long story short (not to mention simplifying it), they needed to decide between the following four options:
- Create an extremely powerful rocket, with a thick steel body and massive engines, which could simply power its way through the atmosphere regardless of atmospheric changes and also survive motor failures. This would be the simplest solution, but also a very expensive one. It would mean that any unexpected event could be fatal because the rocket would not have been designed to deal with it.
In modern parlance we would call this a Rigid application because it is strong in expected places but will be weak when it encounters unexpected events. Before the era of Clouds & automation, DevOps & Site Reliability Engineering, we often tried to make our applications as rigid as possible. - Use a remote-controlled computer, which would do little more than receive commands from the ground. In this case, the actual “Brain” would have been a computer on the ground which would receive telemetry from the rocket and reply with updated commands. This could keep the rocket relatively simple, but would add many potential failure points (network problems, delays and so on).
In modern development parlance we would call this a Fragile application. - Use the existing Apollo computer, which was already installed on the spacecraft on top of the rocket. Since the Apollo spacecraft flew the astronauts all the way to the moon and already had a computer built-in, why not use it to control the Saturn during launch?
The benefit here would be re-using an existing computer, but the downside was adding a dependency between the Saturn V (whose functional goal was completed within minutes of launch) and the Apollo spacecraft (whose goal would only be completed more than a week later, when the astronauts landed back on Earth). A failure in one could damage the other. In modern development parlance we would call this a Tightly-Coupled Application, because of the added dependency between the rocket and spacecraft. - Give the Saturn V its own independent brain. By having its own computer, the Saturn V can quickly respond to changes and keep the flight on the correct track, without depending on external resources.
In modern development parlance we would call this a Loosely-Coupled Application, because there are few dependencies between the rocket, the spacecraft, and ground control
On the face of it, the loosely-coupled application seems like the most complicated solution and if we were only looking at functional requirements, perhaps it seems unnecessary. But when we add the non-functional requirements, we can easily see that the advantages of resiliency are much more important than the added technical requirements.
NASA contracted IBM to create the Instrument Unit — a computer in the shape of a ring that sat near the top of the Saturn V and controlled it during the brief, yet majestic, flight.
The Instrument Unit (IU) was the rocket’s nerve center and brain, designed to guide the Saturn V from liftoff into orbit, and then ignite the third-stage engine which propelled Apollo 11 to the Moon. It could issue a whopping 22 steering commands per second!
You can learn more about the IU in IBM’s Apollo11 news site and watch a video clip showing engineers prepare it.
In today’s information technology world, the decision to choose a loosely-coupled architecture is natural and automatic. Virtually all development and run-time environments, whether they be virtual machines, containers or functions, are loosely coupled and minimize the rigidity and fragility of the applications.
A common such design solution architecture is called microservices, and even though there are similarities, I hesitate to call anything connected to the Saturn V, 111 meter (363 feet) tall and weighing 2 million kg (6.5 million pounds), “micro” in any way!
Today, the underlying technologies such as Kubernetes, Istio, Knative and others make such loosely coupled development the default. Nonetheless, there are always plenty of decisions to make regarding the functional and non-functional requirements of application development, which is where the IBM Garage solution helps our customers with their own “moon rockets” — whatever they may be.
I hope you’ve learned from the third article of this series.
As I write this (and if you are reading this during the week of publication), it is 50 years to the day of the historic Apollo 11 mission to the moon. I cannot help but be inspired by what happened back then.
Next time, we’ll go back to the 1201 computer errors and see how the Flight Controllers, the predecessors of today’s Site Reliability Engineers, handled the problem and allowed the astronauts to land safely.
I will be pleased if you would join me. You can follow me Robert Barron or on Twitter at @flyingbarron
If you’d like to learn more about how IBM can help you make decisions about your functional and non-functional requirements, drop by our Garage website and schedule a no-charge visit. We have a specific Garage to help you with the non-functional (the “how”) requirements called our Garage for Cloud Service Management & Operations (CSMO).
This week is the 50th anniversary of the Apollo 11 Moon landing — here’s NASA’s website and here are two of IBM’s sites: Thought Leadership & Icons of Progress.
You can follow along with the astronauts at ApolloinRealTime.org and on a couple of Twitter accounts : @apollo50th and @reliveapollo11
Articles in this series:
