Capstone Labs’ Drone Delivery: A Modern Application

Capstone Labs is building an application, Drone Delivery, to support

• research on architectural ROI for modern enterprise-scale applications
• knowledge transfer inside Capstone IT as well as to our clients
• development of new processes and software

Architectural decisions have a foundational effect on the life cycle of development and operational costs for an application. These decisions impact not only architectural style (monolithic, hexagonal, or microservice-based), but also broader aspects of an application as well its:

• tech stack
• deployment options
• influence on team dynamics

Drone Delivery, as a working application built by the Capstone Labs team, will be studied, documented, and demonstrated to clarify the trade-offs that determine the long-term costs for an application. Along the way, we expect that new processes and software will emerge.

This article will review the key requirements that motivate the first version of Drone Delivery; forthcoming articles will delve into additional requirements, its implementation, and its theory of operation.

Key Requirements

Have an easily understood application domain

We want the application’s overall domain to be easily understood by a broad cross-section of developers, so we have chosen Uber for X as the underlying epic. Similar applications are often seen in the recent literature about modern applications. Excellent examples include:

• The FTGO application from Chris Richardson
• The Feed me application from Cam Jackson
• The Taxi Aggregator / Kitty Problem from Robert C. Martin
• Uber’s Domain Oriented Microservice Architecture

Uber for X is an application type to which most developers can relate, as well as an instance of a typical eCommerce application. As such, it serves research and educational purposes well.

In Drone Delivery, the delivery vehicles are autonomous drones that fly to the vendor’s pickup location, are loaded with their mission’s cargo, fly to the customer’s location, are unloaded, and then proceed to their next mission.

Broadly, this application domain would include typical eCommerce functionality such as ordering, payments, and transport. The initial Drone Delivery implementation focuses on the Transport Domain that manages delivery missions, including:

• receiving drone duty schedules
• receiving delivery orders
• assigning deliveries to on-duty drones
• rejecting delivery missions when all on-duty drones are occupied
• overseeing drone mission schedules
• monitoring drone mission status
• tracking drone GPS locations as they fly their missions

Other domains that collaborate with the Transport Domain are simulated during operation, such as the:

• Scheduling Domain including assignment of drones for duty
• Order Domain including incoming orders for missions
• Drone Domain including GPS and status updates from the on-duty drones themselves

The focus on the Transport Domain keeps the overall application implementation small and cognitively tractable for the Labs team and Capstone customers. Simulating the Transport Domain’s collaborators allows Drone Delivery expand research into a much wider swath of enterprise application behavior.

Reflect current industry thought about best practices

The Drone Delivery implementation leverages both microservices and micro frontends. These two approaches are intended to support highly evolvable enterprise applications. In their book Building Evolutionary Architectures, ThoughtWorks colleagues Neal Ford, Rebecca Parsons, and Patrick Kua cite microservices as “our exemplar for an evolutionary architecture” (p. 72). Their colleague Cam Jackson describes micro frontends, i.e. the breaking up of frontend monoliths into independently deployable front end components, as the companion technology to microservices in the backend. Both architectural approaches continue to receive extensive industry coverage, both critical and supportive.

By design, the architecture of Drone Delivery reflects published industry examples from the literature on microservices and micro-frontends. For instance, here is a list of sixteen microservice patterns from Chris Richardson’s well-respected Microservice Architecture site that are all represented in Drone Delivery:

• Service deployment platform
• Server-side service discovery
• API gateway
• Service instance per container
• Self-contained service
• Database per service
• Service per team
• Messaging
• Domain event
• Transactional outbox
• Polling publisher
• Saga
• CQRS
• Access token
• Externalized configuration
• Client-side UI composition

Selecting microservices and micro frontends as the approaches for Drone Delivery does not represent Capstone’s vote that these approaches are best for all applications. Rather, it reflects their influence on current thought about modern applications. Moreover, these technologies sit on the leading edge of industry thought about the twin architectural principles of low coupling and high cohesion, first identified by Larry Constantine as the hallmarks of evolvable software design nearly fifty years ago.

Note as well that these approaches bring with them significant technical and organizational challenges. In particular, microservices and micro frontends come with an increase in system complexity and concomitant development difficulties. Drone Delivery provides a platform within which to explore these challenges and to evaluate cost-effective ways to meet them.

Support simulation of the Transport Domain’s collaborators

The transport domain automatically assigns orders to drones that would be available to fly from their last drop-off location and reach the order’s pickup location by the order’s pickup time. Hence, the Transport Domain’s simulation environment generates duty assignments for drones as well as realistic incoming order traffic.

The other major collaborators with the Transport Domain are, of course, the drones themselves. Drone simulators report their status into the Transport Domain, including their GPS locations and their current state as they fly their (simulated) missions.

Simulators support generation of all types of traffic with realistic variation and scale to enable significant performance testing.

Support on-prem and cloud deployments

The first deployment for the Drone Delivery is a CI/CD pipeline driven Kubernetes-based cloud environment, and other deployments are planned. For instance, in parallel with building the Drone Delivery application, Capstone Labs is building a micro-datacenter to support research into on-prem deployments.

Next

The next article in the series will review the implementation and theory of operation of the initial Drone Delivery efforts.

Want to keep up with the latest advancements in application development, containerization, and more? Reach out today.