Welcome!

@DevOpsSummit Authors: Yeshim Deniz, Zakia Bouachraoui, Liz McMillan, Pat Romanski, Elizabeth White

Related Topics: @DevOpsSummit, Linux Containers, @CloudExpo

@DevOpsSummit: Blog Feed Post

DevOps: Apollo Mission Control | @DevOpsSummit @ToddVernon #DevOps

The pattern between the world of space mission operations and the evolution of SaaS businesses is converging

DevOps and Apollo Mission Control
By Todd Vernon

Lately I have been reading the excellent book Digital Apollo. It explores the evolution of digital control systems and the man-machine interface that evolved during the development of space flight and ultimately the Apollo missions. It’s a fantastic book – more technical than most – but very approachable to those not familiar with flight control, embedded software, or the challenges of building such systems. As I read the book, I could not help but compare the way space missions were executed to that of the role of DevOps in modern SaaS businesses.

Apollo cover

I started my career at NASA testing digital flight controls for an experimental aircraft the X-29. The X-29 flight test program was just the latest in the series of one-off aircrafts that started with the Bell X-1 and moved to the X-15 that laid the groundwork for Apollo. As a result, flight test was executed in a very similar fashion in all these programs. Nearly every switch, surface, actuator, probe was instrumented and that data was downlinked in real-time to a control room as the airplane or spacecraft flew.

As the vehicles became more fly-by-wire and had digital computers at their core, those computers also downlinked a lot of their internal state variables to the ground where teams of engineers could keep track of every button push, flight mode, acceleration in real-time, helping the pilot look for things that could happen to potentially end the mission or end his life.

The pattern between the world of space mission operations and the evolution of SaaS businesses is converging. While generally no one dies if your SaaS service fails to operate, the implication of downtime every year gets more and more real. If you operate a platform that services customers that collectively pay millions of dollars a day for your product or service, that is serious business.

Like state variables downlinked from Apollo, we now watch the equivalent using tools like New Relic as our systems support millions or billions of customer transactions through the services we have built. While Apollo’s AGC had to work for several hundred hours at a time, our SaaS services get turned on once when we launch our company and the mission goes on forever. As a result, we are replacing rooms of engineers there for days with systems that connect them to the technology all the time.

Modern monitoring tools are starting to approach the quality of observation we had back at NASA for immediacy of data, but at the same time, now far surpass those relatively crude tools for the spontaneity of exploration and discovery. Today, I get an alert on my iPhone when some part of our system is acting inconsistent and I can interact with our engineers in real-time regardless of location.

Like the rooms of engineers that supported an Apollo mission, today we are on the verge of supporting our complex systems with a virtual room of engineers using tools like VictorOps. As systems become more complex, it becomes more likely the problem needs to be solved by the person that wrote the code in the first place. Very often only that person has (or ever had) the knowledge of how the system works with such intimacy as to know how to fix it or work around it to keep the mission (business) functioning.

apollo_14_lm

On Apollo 14, an engineer noticed while the space craft was in Lunar orbit that the software bit, buried deep in the guidance and navigation computer inside the Lunar Module (LM), signified that the descent program abort was initiated. This was caused by a loose bead of solder that effectively kept “pushing” the abort button and was not a problem or even noticed by the crew as the descent program that would land the astronauts on the moon was not running yet.

Had that program been initiated, as was scheduled only minutes later, the mission would have been aborted and quite likely the crew would have been lost. The knowledge of that specific engineer who knew how the system would misbehave was enabled by the ability to be connected to software through advanced monitoring, and the ability to act on that data in real-time. If you removed any part of the equation, Apollo 14 would have been much different.

This is the basic DNA of how we look at our product at VictorOps. We connect engineers to the mission-critical machines that run your business. If you expect the unexpected and outfit your teams accordingly, you can be ready to respond to any problem faster and more accurately then your competition.

The post DevOps and Apollo Mission Control appeared first on VictorOps.

More Stories By VictorOps Blog

VictorOps is making on-call suck less with the only collaborative alert management platform on the market.

With easy on-call scheduling management, a real-time incident timeline that gives you contextual relevance around your alerts and powerful reporting features that make post-mortems more effective, VictorOps helps your IT/DevOps team solve problems faster.

@DevOpsSummit Stories
The best way to leverage your Cloud Expo presence as a sponsor and exhibitor is to plan your news announcements around our events. The press covering Cloud Expo and @ThingsExpo will have access to these releases and will amplify your news announcements. More than two dozen Cloud companies either set deals at our shows or have announced their mergers and acquisitions at Cloud Expo. Product announcements during our show provide your company with the most reach through our targeted audiences.
Enterprises are universally struggling to understand where the new tools and methodologies of DevOps fit into their organizations, and are universally making the same mistakes. These mistakes are not unavoidable, and in fact, avoiding them gifts an organization with sustained competitive advantage, just like it did for Japanese Manufacturing Post WWII.
When building large, cloud-based applications that operate at a high scale, it's important to maintain a high availability and resilience to failures. In order to do that, you must be tolerant of failures, even in light of failures in other areas of your application. "Fly two mistakes high" is an old adage in the radio control airplane hobby. It means, fly high enough so that if you make a mistake, you can continue flying with room to still make mistakes. In his session at 18th Cloud Expo, Lee Atchison, Principal Cloud Architect and Advocate at New Relic, discussed how this same philosophy can be applied to highly scaled applications, and can dramatically increase your resilience to failure.
DevOpsSummit New York 2018, colocated with CloudEXPO | DXWorldEXPO New York 2018 will be held November 11-13, 2018, in New York City. Digital Transformation (DX) is a major focus with the introduction of DXWorldEXPO within the program. Successful transformation requires a laser focus on being data-driven and on using all the tools available that enable transformation if they plan to survive over the long term.
With more than 30 Kubernetes solutions in the marketplace, it's tempting to think Kubernetes and the vendor ecosystem has solved the problem of operationalizing containers at scale or of automatically managing the elasticity of the underlying infrastructure that these solutions need to be truly scalable. Far from it. There are at least six major pain points that companies experience when they try to deploy and run Kubernetes in their complex environments. In this presentation, the speaker will detail these pain points and explain how cloud can address them.