Reimagining Defence Episode 3 – Cloud computing and autonomous CASEVAC

This episode was written by Flt Lt James Kuht & edited by Lt Col Henry Willi. The thoughts are the authors own and do not represent the Ministry of Defence. The episode can be found above, or on Spotify & iTunes. You can find out more by following us on twitter, @ReDefPod.

The founder of Amazon, Jeff Bezos once said “You don’t generate your own electricity. Why generate your own computing?” (Bidgoli, 2010). He was of course, referring to Cloud computing.

In this episode, we’re going to explore; what cloud computing is, how world-leading start-ups like the ride-sharing company Uber exploit it to it’s full potential, why the US Department of Defence just awarded a $10Bn contract to Microsoft to provide their cloud platform (Woo, 2020), and finally reimagine CASEVAC using cloud computing & autonomous vehicles.

What is it?

So back to the metaphor – why is “generating computing” as Bezos puts it, like generating electricity? Well generating electricity is complex, needs a lot of infrastructure and benefits from economies of scale – so it makes sense for centralised companies to generate large amounts of electricity and sell it to others. That means we, as customers, can simply plug into the grid and have the exact amount of electricity we require delivered instantly, only being charged for what we use. Buy an electric car and suddenly use loads more electricity? It’s there instantly – the only thing that changes is your bill goes up. 

Bezos argues that Cloud computing is similar. To host a website or application you need considerable infrastructure. Physical infrastructure like servers, and software infrastructure – the code that makes the site appear as it does, the database that collects data inputted by users, security protocols, analytics etc. 

Traditionally you would source these things yourself – requiring significant technical expertise, capital and ongoing specialist maintenance. But with public cloud computing, providers like Amazon or Microsoft, amongst others, have bought millions of servers, loaded them up with loads of helpful tools and infrastructure, and made them instantly accessible through the internet – so we can hire as much computing power to host your applications as you need, whenenever you need it, without needing to handle the maintenance and benefitting from significant economies of scale. Making a new website? Don’t worry, they have helpful tools to make it easier to do, and you’ll only be charged a small amount since you’ll hardly have any traffic visit it. What if it suddenly becomes the new facebook? No problem – you can upgrade to bigger and better servers at the click of a button and your bill goes up, instantly able to scale your business in response to demand, only paying for what you use. So in essence the cloud is just like the electricity grid, except for computing.

Why is this so important you ask? Two features stand-out, firstly it’s flexibility to scale up or down to your demands instantaneously, and secondly the accessibility of public cloud through the internet, enabling convergence of the exponentially increasing number of internet-connected devices. 

Let’s take a fictitious military example to illustrate – let’s say you want to release a new intelligence mobile application which allows local people in a foreign state to report suspicious activity – it’s like a private twitter feed of intelligence. You build a prototype rapidly and are ready to deploy it – traditionally this would mean buying some servers for a hefty bill and taking time to set them up, not even knowing if the application would be a success or a flop. The cloud allows you to achieve this in minutes, simply choose to rent a small and cheap server to start with and deploy your code – many of the time-consuming steps like building the database structure, or overlaying the security protocols, are already built into the cloud provider, so you just concentrate on delivering the product. 

Let’s play out a few developments of the scenario.

Say the launch goes badly, no-one likes the app and uptake is low – no problem, you turn off the cloud computing server, cut your losses and move onto the next project – you didn’t spend time or big money on sorting the infrastructure – you have truly failed fast, with minimum expenditure.

What if the app launch went well though, with it suddenly gained 10X the number of users you expected. Traditionally this would crash your service, or necessitate that you quickly buy more physical servers and set-them up too. Not with the cloud, simply pay for a more powerful server, and in a matter of seconds you can scale to any size you want (within your budget of course).

So your app is now in widespread use and providing great real-time intelligence, however one of the analysts has flagged that some of the users might be providing spurious intel. The analyst knows that machine learning is often used for spam filtering in your emails, and wonders whether the individuals who are providing the system with false information can be identified and removed from the app in a similar way. Many cloud providers share a suite of easy-to-implement tools and readymade protocols for deploying such a machine-learning model, so you benefit from this pre-existing virtual infrastructure, and implement the software rapidly. You know this otherwise would have taken a degree of skill that none-of-your-team possess – but because the cloud provider equips you with industry standard tools, your colleague simply looked up how to do it from a youtube video. You spin this up and your app suddenly becomes one of the most valuable int resources in the area.

Over the coming 6 months, the app is continuously iteratively developed, and scaled across another 25 countries, simply paying as you go – usage is the only thing you’re paying for, but you’re happy to pay more for more usage, as more usage means more intelligence. 6 months later a new way of collecting intelligence of that area comes along though, entirely expected due to the exponential rate of development of technology we discussed in episode 1, so you turn off the application – you’re tied into no contracts, bought no servers and are simply “paying as you go”. 

Some examples

Hopefully that example has whet your appetite of what’s to come, now let’s dive into some real-life examples.

Let’s take Uber, a 10-year old taxi company, that owns no taxis. It is a prime example of how cloud computing allows the modern business the flexibility to scale and diversify rapidly, whilst benefiting enormously from the convergence of different technologies – namely mobile technology, AI and big data.

First let’s consider it’s scale. From 2014 to 2017, the amount of data flowing through Uber increased by a factor of 100,000 – cloud computing was one of the key enabler to Uber to achieve this without grinding to a halt (Shiftehfar, 2018)! 

Let’s now consider some of it’s services and how cloud computing lays the foundations for them. First take Uber Eats – usually it would be unheard of for a taxi company to diversify into food delivery – however, cloud computing allows you to rapidly deploy a new service with minimal investment in infrastructure then scale it or turn it off depending upon whether it works. In Uber Eats case, of course, it worked – it’s forecast to deliver $10Bn of food this year (Carson, 2019). 

Then lets take for example Uber’s Pool feature, developed in 2014, which allows users to share rides with other people depending upon their location and their destination. This, of course, requires some quite complex analytics – gathering data from individuals who want rides, optimally grouping them, and connecting them to nearby drivers wanting to give rides. If you wanted to replicate this – which the military might consider as we’ll discuss later on in this episode, you would need rapid servers with high-uptime, and to be able to run some complex analytics on some sizeable databases – many cloud providers would at least be able to provide you with much of the infrastructure that allows this, massively reducing your time to deployment, and reducing the risk that, if it wasn’t deemed to be a useful feature, you couldn’t iterate upon it at pace, or turn it off without wasting too much money.

Developing the Uber story a little further, let’s now consider the changing landscape as we move into an era in which self-driving cars will become more abundant – an area in which uber is investing significantly. Now, if they were a traditional cab company whose cars and drivers were their greatest asset, the future might be looking rather bleak. However, because Uber doesn’t own any cars, and instead focuses on providing scalable and flexible software for getting from A to B, they’re far better prepared for this shift. Put simply, as soon as autonomous cars come online, the only thing that will change for uber is replacing the input of which driver is available and where they are, to the autonomous vehicle’s status and position. It won’t need paying, will have less accidents and won’t strike. 

Looking into the future for Defence

I wonder whether listening to that example of how cloud computing enabled Uber to experiment, scale, and diversify has got you thinking about what cloud computing could enable in your unit? In this final section, we’re going to explore what cloud computing might enable for Defence over the next 5 years. 

First up, we should note that we have a high degree of confidence that this is the way that militaries around the world will go – the MoD recently released “MoDCloud” which is starting to provide some public cloud services and is gaining growing investment. Across the pond, the US DoD has just awarded a $10Bn 10 year contract to Microsoft to deliver it’s cloud infrastructure (Woo, 2020). 

These growing cloud services, combined with an increasingly digitally literate workforce thanks to schemes like the jHub Coding Scheme, are going to enable us to start moving into an era where operators and their coding colleagues can create, rapidly deploy and iterate on solutions to their problems. A key piece of the puzzle in engaging in “prototype warfare”. 

So let’s dive into a fictional example what the cloud might enable for military transport of the future – focussing in on a scenario in which all of the best bits of the cloud are utilised – it’s flexibility & scalability, and the wealth of tools available on it. 

Imagine you’re working in a small section at a forward operating base. Out on patrol for 12 hours, you end up being engaged and taking casualties – the airspace is denied, so you need to be picked up by land. You request urgent pick-up through a new prototype application on your military phone, it takes your GPS co-ordinates and your number of casualties requiring evacuation, and sends these up to the cloud, where it optimally connects you to which autonomous vehicles are available in the vicinity, and dispatches them on the most efficient routes. It’s like deployed, autonomous, uber.

You receive an almost immediate notification of the convoy being dispatched, and the ETA. The convoy takes a route plotted by a new mapping software hosted on the cloud which uses computer vision to identify passable tracks from satellite imagery, combining this with it’s real-time view from it’s sensor array ensuring it’s not about to drive into a ditch. 

The extraction is a success, so much so in fact, that many other units demand the same provision. The prototype is rapidly scaled up over the coming days to all other deployed teams in the region, simply requiring purchasing some more server space on the cloud and the section commanders downloading the app onto their phones. 

One of the small teams complains though – they are deeply embedded, so don’t have a forward operating base within distance for an autonomous vehicle to get to them within a 2-4 hour timeline. They believe that a small change to the app which also allows the ordering of blood to be delivered by small drone would increase their chances of survival if one of them were to suffer a major traumatic injury. One of the section took the jHub Coding scheme, draws a mock-up of what the solution might look like and builds a quick and dirty prototype – sending it back to the new cloud-operations centre in the UK. They productize the beta version of the app, run virtual simulations to show that it would work, before then deploying the beta version to selected sections. Found to only be useful in very select circumstances, the product is never scaled, but remains utilised for specific sections.

Another patrol has a different complaint – one of their autonomous vehicles drove over a large IED on the way to pick up the casualty, rendering it unserviceable and leaving them stranded for a number of hours. Knowing that there are now small internet connected vibration sensors disguised as pebbles available, the section commander proposes that local roads are covered with these pebbles, to track whether the roads are dug up to plant IEDs. 

The cloud provider already provisions infrastructure which enables easy connection of IoT devices such as these pebbles, and can use machine learning on signals from the pebbles to identify where there’s been a disturbance in the ground. It’s a combination used by farmers to check for trespassers and there’s youtube videos of how to set it. Using this knowledge, the cloud operations centre sets it up, and routes for extraction are updated automatically to avoid spots identified as potentially having an IED dug in them. This solution is so successful, that this chunk of code is copied and pasted into many other applications, such as those for autonomous convoys on common re-supply routes. The versatility of the cloud means that this is almost as simple as clicking copy and paste.

Before we conclude, we’d like to carefully caveat one critical challenge to Defence’s cloud computing strategy – vendor lock-in. As such a wide range of our future software products will be dependent upon infrastructure and tools proprietary to our cloud provider , switching between providers might be a significant challenge. The DoD has bitten the bullet and clearly believes the trade-off is worth it, with their $10Bn Microsoft contract – whereas China has hedged it’s bets by awarding several contracts to separate cloud providers, also arguing that the enhanced security of having multiple cloud providers with different security protocols is important (Deptula, 2020). It’s beyond the scope of this podcast to assess which is the better strategy, but as MoDCloud seems to hedge its bets for the moment, we thought it important to mention this key point.

So, to conclude, hopefully we’ve convinced you that cloud computing lays the foundation for much of Defence’s business as usual, and is also a key enabler for prototype warfare. It allows incredible flexibility in software development, iteration and scaling, and much quicker deployment of products – due to much of the infrastructure being taken care of by the cloud provider.  It is important to note, however, that this approach will be impossible without unprecedented empowerment of our junior personnel – they’ll need to be upskilled in cloud computing and cloud best practices, they’ll need to be given access to cloud computing resources with appropriate financial delegation to carry out prototype work without delay, and there’ll desperately need to be a centralised function – like the cloud operations centre we touted in this episode – to define these best practices by which they’re trained, prune unsuccessful innovations and rapidly scale the successful ones. The jHub coding scheme is currently building out a cloud computing module as part of the Defence Digital Academy in line with these principles, keep listening to the outro for how to get involved. 

Some of this approach will be deeply uncomfortable to those with 2-10 year procurement mindsets which is, of course, appropriate for ship-building, but as we explained in the first episode, due to the giant leaps we’re now making in technology due to the exponential pace of computing, we need now more than ever to be able to be agile and iterate, instead of taking committing giant steps and being outmaneuvered in the interrim. We’re an organisation famed for it’s stability, that now needs to become famed for it’s agility.

References:

Carson, B., 2019. Uber’S Secret Gold Mine: How Uber Eats Is Turning Into A Billion-Dollar Business To Rival Grubhub. [online] Forbes. Available at: https://www.forbes.com/sites/bizcarson/2019/02/06/ubers-secret-gold-mine-how-uber-eats-is-turning-into-a-billion-dollar-business-to-rival-grubhub/#4d022c531fa9  [Accessed 3 June 2020].

Hossein Bidgoli., 2010. MIS 2010. [online] Available at: https://books.google.co.uk/books?id=VFq7jJPHmOUC&pg=PA259&lpg=PA259&dq=jeff+bezos+you+don%27t+generate+your+own+electricity+where+does+it+come+from&source=bl&ots=bKGsjkLkuW&sig=ACfU3U2ny33o_OH6h4YWbdt-KOHctHqaeg&hl=en&sa=X&ved=2ahUKEwjQsN73seXpAhVsQEEAHd6sCCIQ6AEwC3oECA8QAQ#v=onepage&q=jeff%20bezos%20you%20don’t%20generate%20your%20own%20electricity%20where%20does%20it%20come%20from&f=false  [Accessed 3 June 2020].

Deptula, D., 2020. The Perils Of JEDI: A Single Cloud Provider For The Pentagon And CIA Could Spell Disaster. [online] Forbes. Available at: https://www.forbes.com/sites/davedeptula/2019/02/27/jedi-and-why-its-important-a-single-cloud-provider-for-both-dod-and-cia-could-spell-disaster/#7eb36e226477  [Accessed 3 June 2020].

Shiftehfar, R., 2018. Uber’s Big Data Platform: 100+ Petabytes With Minute Latency. [online] Uber Engineering Blog. Available at: https://eng.uber.com/uber-big-data-platform/  [Accessed 3 June 2020].

Woo, T., 2020. Combat In The Cloud: Securing The $10 Billion JEDI Contract | Zdnet. [online] ZDNet. Available at: https://www.zdnet.com/article/combat-in-the-cloud-securing-the-10-billion-jedi-contract/ [Accessed 3 June 2020].