Have you noticed the word “Jedi” frequently pops up in news headlines lately? Star Wars fans around the world impatiently wonder how the famous conflict between the Jedi and the Sith will conclude when “Star Wars: Rise of Skywalker” hits theaters in December. In a battle closer to Earth, Microsoft triumphed over Amazon to win the 10-year, $10B JEDI contract from the United States Department of Defense (DoD). Amazon challenged the Pentagon’s JEDI decision faster than the Millennium Falcon’s alleged twelve parsecs timeframe makes the Kessel Run. Agree too many Star Wars references, do you? Hmmm?
The main focus of this blog is indeed JEDI. Specifically, the Joint Enterprise Defense Infrastructure contract that the DoD awarded Microsoft Azure in October. JEDI takes an enterprise approach to cloud computing and aims to migrate the DoD’s data and workloads to the cloud. JEDI is part of the DoD’s overall cloud strategy to modernize the DoD so it can support the warfighter around the world, defend against cyber attacks, and leverage emerging technologies. In August, the DoD awarded the GSA cloud contract to General Dynamics Information Technology, and then moved the Navy’s ERP to Amazon’s GovCloud in September. At $10B, JEDI clocks in as the most expensive cloud contract to date as the DoD continues its massive cloud migration.
As a DoD employee responsible for implementing JEDI, where do you begin? How do you eat an elephant? One bite at a time is the familiar advice. I will take it one step further and advise eating the JEDI elephant one byte at a time. That’s right - byte - as in bit, byte, and packet.
Cloud packet visibility will be a critical enabler for JEDI’s successful implementation. Full visibility is essential for the DoD’s monitoring and security tools to keep the DoD’s cloud environment in Microsoft Azure safe. Additionally, the DoD will need to virtually acquire, process, and distribute cloud packets in order to take advantage of the power of Artificial Intelligence (AI), Machine Learning (ML), and algorithmic activities in the JEDI cloud.

Garland Technology’s cloud TAP - Garland Prisms - allows cloud users to acquire, process, and distribute packet-level traffic from VMs and containers in any cloud environment. Garland Prisms is a cloud-native software that deploys in Public Cloud, Private Cloud, and multi-Cloud environments, enabling access to any environment in one easy-to-use platform. Virtually tapping, filtering, and distributing cloud packet traffic in AWS, Azure, Google Cloud, and Private Clouds is now possible with Garland Prisms, as its next-generation agent technology sends processed packet traffic to any IP address in-cloud or on-prem. Garland Prisms is unique because it passes replicated cloud packets to multiple tools and does not store any virtual packets.
Garland Prisms is able to provide that essential cloud packet visibility for the DoD within their JEDI cloud. As the JEDI implementation planning begins, there are several factors that will help JEDI meet its objectives quickly.
The DoD has an important mission in keeping the United States and its allies safe from threats, including cybersecurity threats and cyber attacks. The JEDI Cloud is a major undertaking that will overhaul the ways the DoD uses data to prepare and win conflicts in the future. Cloud packet visibility will enable the DoD a powerful capability of seeing every cloud packet that traverses the network. May the force (of cloud packet visibility) be with you!
Looking to add cloud visibility solution to your next deployment, but not sure where to start? Join us for a brief network Design-IT consultation or demo. No obligation - it’s what we love to do!
If the inline security tool goes off-line, the TAP will bypass the tool and automatically keep the link flowing. The Bypass TAP does this by sending heartbeat packets to the inline security tool. As long as the inline security tool is on-line, the heartbeat packets will be returned to the TAP, and the link traffic will continue to flow through the inline security tool.
If the heartbeat packets are not returned to the TAP (indicating that the inline security tool has gone off-line), the TAP will automatically 'bypass' the inline security tool and keep the link traffic flowing. The TAP also removes the heartbeat packets before sending the network traffic back onto the critical link.
While the TAP is in bypass mode, it continues to send heartbeat packets out to the inline security tool so that once the tool is back on-line, it will begin returning the heartbeat packets back to the TAP indicating that the tool is ready to go back to work. The TAP will then direct the network traffic back through the inline security tool along with the heartbeat packets placing the tool back inline.
Some of you may have noticed a flaw in the logic behind this solution! You say, “What if the TAP should fail because it is also in-line? Then the link will also fail!” The TAP would now be considered a point of failure. That is a good catch – but in our blog on Bypass vs. Failsafe, I explained that if a TAP were to fail or lose power, it must provide failsafe protection to the link it is attached to. So our network TAP will go into Failsafe mode keeping the link flowing.
Single point of failure: a risk to an IT network if one part of the system brings down a larger part of the entire system.
Heartbeat packet: a soft detection technology that monitors the health of inline appliances. Read the heartbeat packet blog here.
Critical link: the connection between two or more network devices or appliances that if the connection fails then the network is disrupted.