Podcasts about outposts

Speaker: Caleb Beaverson In the ancient world, disciples followed their rabbi so closely that they were covered in his dust—a sign of total devotion. This was Jesus' hope for His followers, and it's our desire at Mercy Road: to see people far from God grow into a passionate relationship with Him. Today, Jesus is still calling, “Come, follow me,” inviting us to be covered in His dust. STAY CONNECTED Website: https://mrne.info/church  Mercy Kids: https://mrne.info/kids  Mercy Students: https://mrne.info/students Mercy Road Northeast Facebook: https://mrne.info/facebook  Mercy Road Northeast Instagram: https://mrne.info/instagram HELPFUL LINKS Connect Card: https://mrne.info/getconnected Prayer: https://mrne.info/prayer Give Online: https://mrne.info/giving Outposts: https://mrne.info/outpost Subscribe to MERCY ROAD CHURCH - NORTHEAST YouTube channel to watch this message again later this week! https://www.youtube.com/@mercyroadnortheast

Speaker: Ken Primeau In the ancient world, disciples followed their rabbi so closely that they were covered in his dust—a sign of total devotion. This was Jesus' hope for His followers, and it's our desire at Mercy Road: to see people far from God grow into a passionate relationship with Him. Today, Jesus is still calling, “Come, follow me,” inviting us to be covered in His dust. STAY CONNECTED Website: https://mrne.info/church  Mercy Kids: https://mrne.info/kids  Mercy Students: https://mrne.info/students Mercy Road Northeast Facebook: https://mrne.info/facebook  Mercy Road Northeast Instagram: https://mrne.info/instagram HELPFUL LINKS Connect Card: https://mrne.info/getconnected Prayer: https://mrne.info/prayer Give Online: https://mrne.info/giving Outposts: https://mrne.info/outpost Subscribe to MERCY ROAD CHURCH - NORTHEAST YouTube channel to watch this message again later this week! https://www.youtube.com/@mercyroadnortheast

Speaker: Daron Earlewine In the ancient world, disciples followed their rabbi so closely that they were covered in his dust—a sign of total devotion. This was Jesus' hope for His followers, and it's our desire at Mercy Road: to see people far from God grow into a passionate relationship with Him. Today, Jesus is still calling, “Come, follow me,” inviting us to be covered in His dust. STAY CONNECTED Website: https://mrne.info/church  Mercy Kids: https://mrne.info/kids  Mercy Students: https://mrne.info/students Mercy Road Northeast Facebook: https://mrne.info/facebook  Mercy Road Northeast Instagram: https://mrne.info/instagram HELPFUL LINKS Connect Card: https://mrne.info/getconnected Prayer: https://mrne.info/prayer Give Online: https://mrne.info/giving Outposts: https://mrne.info/outpost Subscribe to MERCY ROAD CHURCH - NORTHEAST YouTube channel to watch this message again later this week! https://www.youtube.com/@mercyroadnortheast

Speaker: Josh Husmann In the ancient world, disciples followed their rabbi so closely that they were covered in his dust—a sign of total devotion. This was Jesus' hope for His followers, and it's our desire at Mercy Road: to see people far from God grow into a passionate relationship with Him. Today, Jesus is still calling, “Come, follow me,” inviting us to be covered in His dust. STAY CONNECTED Website: https://mrne.info/church  Mercy Kids: https://mrne.info/kids  Mercy Students: https://mrne.info/students Mercy Road Northeast Facebook: https://mrne.info/facebook  Mercy Road Northeast Instagram: https://mrne.info/instagram HELPFUL LINKS Connect Card: https://mrne.info/getconnected Prayer: https://mrne.info/prayer Give Online: https://mrne.info/giving Outposts: https://mrne.info/outpost Subscribe to MERCY ROAD CHURCH - NORTHEAST YouTube channel to watch this message again later this week! https://www.youtube.com/@mercyroadnortheast

In the ancient world, disciples followed their rabbi so closely that they were covered in his dust—a sign of total devotion. This was Jesus' hope for His followers, and it's our desire at Mercy Road: to see people far from God grow into a passionate relationship with Him. Today, Jesus is still calling, “Come, follow me,” inviting us to be covered in His dust. STAY CONNECTED Website: https://mrne.info/church  Mercy Kids: https://mrne.info/kids  Mercy Students: https://mrne.info/students Mercy Road Northeast Facebook: https://mrne.info/facebook  Mercy Road Northeast Instagram: https://mrne.info/instagram HELPFUL LINKS Connect Card: https://mrne.info/getconnected Prayer: https://mrne.info/prayer Give Online: https://mrne.info/giving Outposts: https://mrne.info/outpost Subscribe to MERCY ROAD CHURCH - NORTHEAST YouTube channel to watch this message again later this week! https://www.youtube.com/@mercyroadnortheast

In the ancient world, disciples followed their rabbi so closely that they were covered in his dust—a sign of total devotion. This was Jesus' hope for His followers, and it's our desire at Mercy Road: to see people far from God grow into a passionate relationship with Him. Today, Jesus is still calling, “Come, follow me,” inviting us to be covered in His dust. STAY CONNECTED Website: https://mrne.info/church  Mercy Kids: https://mrne.info/kids  Mercy Students: https://mrne.info/students Mercy Road Northeast Facebook: https://mrne.info/facebook  Mercy Road Northeast Instagram: https://mrne.info/instagram HELPFUL LINKS Connect Card: https://mrne.info/getconnected Prayer: https://mrne.info/prayer Give Online: https://mrne.info/giving Outposts: https://mrne.info/outpost Subscribe to MERCY ROAD CHURCH - NORTHEAST YouTube channel to watch this message again later this week! https://www.youtube.com/@mercyroadnortheast

Delve into the remote outposts and refuges across the globe where travelers have stopped along the course of their adventures. Then hear about the highest views in Wales — and how to reach them — and learn about the country's slate mining heritage. And from Alps to caves, vineyards to beehives, catch the buzz of the natural wonders on display in Slovenia. For more information on Travel with Rick Steves - including episode descriptions, program archives and related details - visit www.ricksteves.com.

In the ancient world, disciples followed their rabbi so closely that they were covered in his dust—a sign of total devotion. This was Jesus' hope for His followers, and it's our desire at Mercy Road: to see people far from God grow into a passionate relationship with Him. Today, Jesus is still calling, “Come, follow me,” inviting us to be covered in His dust. STAY CONNECTED Website: https://mrne.info/church  Mercy Kids: https://mrne.info/kids  Mercy Students: https://mrne.info/students Mercy Road Northeast Facebook: https://mrne.info/facebook  Mercy Road Northeast Instagram: https://mrne.info/instagram HELPFUL LINKS Connect Card: https://mrne.info/getconnected Prayer: https://mrne.info/prayer Give Online: https://mrne.info/giving Outposts: https://mrne.info/outpost Subscribe to MERCY ROAD CHURCH - NORTHEAST YouTube channel to watch this message again later this week! https://www.youtube.com/@mercyroadnortheast

Lebanon accused Israel of "occupation" after the IDF withdrew its forces from south Lebanon but kept 5 outposts in Lebanese territory. Reserve Maj Gen Uzi Dayan served as IDF deputy Chief of Staff and the head of the IDF Planning Division. He is currently the Chair of Mivtahi-the Forum of National Commanders. KAN's Mark Weiss asked him if the IDF withdrawal from south Lebanon while maintaining 5 outposts was the right move? (Photo:IDF)See omnystudio.com/listener for privacy information.

PREVIEW: AFRICA: RUSSIA: PRC: Colleague Ronan Wordsworth explains the transformation of Francophone Africa colonies to Wagner Group outposts that usher in China resource exploitation while grabbing larger shares of the gold fields. More later. 1885

Is Israel's war with Lebanon going to end differently from past attempts to secure Israel's northern border? Journalist Matti Friedman, who recounted his experience as a soldier in Lebanon in his book Pumpkinflowers, reflects on that experience in light of current events and looks to the future in this conversation with EconTalk's Russ Roberts.

While it's bittersweet that our podcast is coming to an end with this episode, it's difficult to put into words how excited we are as an organization for what 2025 has in store.A formal partnership with Centershot Ministries and Centershot Blue will officially kick off our initiative to help plant 1,000 archery outposts across the US. These locations will provide a safe environment for Active Military, Veterans, Law Enforcement and First Responders to gather around the sport of archery. Outposts can be at an archery range, pro shop, school, church, park, or anywhere else that a group of local volunteers can host the participants. With a great curriculum in place and archery kits available for purchase through Genesis and Centershot, this program is transforming lives and communities one arrow at a time. HHAUSA's role will be to locate individuals wishing to start outposts and pointing them to Centershot leadership for the necessary training and onboarding process.Five years ago, our vision was for HHAUSA to become a nationwide nonprofit. While it took a different path than we expected, it has become a reality through this allegiance with Centershot. God's ways are always higher than ours!We will be hosting the four largest HHAUSA events in our history in 2025 with the schedule being released in December. If you haven't made the trip to Wisconsin yet, plan on adding that to your list of archery destinations in the New Year. We'd love to invite you into this community that has come together and continues to grow, providing a healthy outlet for our Service Members.I want to thank everyone who has been a part of The HHAUSA Podcast over the past three and half years. From our guests to our listeners and our editor Logan Chartrand of Whiz Bang Media, collectively we have made a difference in so many lives. While the mic will be going silent, you have my word that these life changing and life saving conversations will still be happening in the weeks, months, and years ahead as we continue to selflessly serve those who serve and protect us.May God bless you, God bless our Service Members, and God bless America!To stay updated on everything happening at HHAUSA, visit our website at hhausa.org, subscribe to our email list, and follow us on Facebook and Instagram.For more information on Centershot Ministries and Centershot Blue, visit their websites at:https://centershot.org/https://centershotblue.org/For more information about HHAUSA, learn how you can support our mission, or attend an event, visit www.hhausa.orgTo purchases HHAUSA hats, tees and hoodies, visit www.hhasports.comHHAUSA Partner Discount CodesHot Shot 15% Off Code: HHAPartner24Rugid Gear 10% Off Code: HHAUSA10StealthRig 15% Off Code: Stealth15

Wayne Clark, a northern business legend, shares his extraordinary journey from a fur trapper to a successful entrepreneur dominating the aviation and hospitality sectors in Ontario. Discover how Wayne's passion for the outdoors and his relentless drive for diversification propelled his businesses, including Clark's Baits and Clark's Resorts and Outposts, to new heights. You'll learn about the pivotal moments, like purchasing his first aircraft, which significantly influenced his business trajectory and the foundational belief that standing still in business means moving backward.Explore Wayne's insights into the necessity of diversification, especially in regions reliant on natural resources, and how it has been a critical factor in sustaining his operations. Wayne recounts the trials and triumphs of managing a multifaceted business, from ice fishing tours to retail stores, emphasizing the value of adapting to change and maintaining a proactive stance. His stories paint a vivid picture of the challenges and rewards of running a successful family business in the north, highlighting the importance of teamwork and sustainable practices.Join us as Wayne delves into the nuances of conservation efforts and their significance in the fishing industry. Learn how his strategic decisions, like implementing no-take policies and acquiring lodges for sustainable management, have ensured a balance between business growth and ecological preservation. This episode promises an inspiring and informative narrative, offering valuable lessons on entrepreneurship, family-run business success, and the stewardship of natural resources in one of Canada's most beautiful regions.

Welcome to season 10 of Being Known Podcast. This season we are taking a look back at where we have come over the last couple of years, to determine where we are headed in the future, and as a way to continue bringing you the best content for how to live a life being fully known.   Each week we are spotlighting one episode from a previous season (the best of the best, so to speak). This is just a sample of what that entire season was all about. We hope you have, or will, take the time to listen to all the episodes again.   This week we are focusing on season 7 - Confessional Communities. We have shared a great deal about confessional communities over the last several seasons on Being Known Podcast. We thought we would take this opportunity to dive in and take a closer look at their purpose and how they operate. Although the best way to discover these things is to actually participate in a confessional community, however, we  hope this season gets you a little closer to what it means—and what it takes—to be part of one.   . . . . Episode Links and References Genesis 1-2 Luke 24: The Road to Emmaus John 20: Thomas's encounter with Jesus Artistic offering - Carravaggio: Thomas The Center for Being Known New Story Behavioral Health Connections Conference 2024 - Oct. 24-25, 2024    . . . . . Stay connected: Instagram, Facebook YouTube (Unedited videos of each episode AND the Post Show Conversation.) Please subscribe to the podcast so you never miss an episode and we always welcome your reviews on Apple Podcasts.  Sign up to access the Being Known Podcast applications, the weekly exercises that connect what you are learning to your life in a practical way.   

We're joined by Kieran Kelly and Jeremy Rose to go over the ICJ Advisory Opinion of 19 July 2024 - “Legal Consequences arising from the Policies and Practices of Israel in the Occupied Palestinian Territory, including East Jerusalem”. We talk about the details of the case, the rulings and implications and touch on how NZ should respond.Executive Summary of the OpinionThis episode's co-hostsKyle, Kieran, JeremyTimestamps0:00 Introductions4:51 The ICJ vs The ICC10:15 History of the Ruling11:56 History of the Territories17:32 Responsibility of Government to its People 20:47 Going Over the Ruling30:00 Three Types of Conduct 30:40 How New Zealand Should Respond34:48 Outposts vs Encampments36:54 Getting Ahead of Disagreements38:10 Exploitation of Natural Resources 40:37 Rules of Occupation45:15 Things That Can't Be Undone47:40 Sanctions and Legal Challenges49:35 Annexation and Apartheid 52:43 Ethnic Cleansing 57:58 State Solutions1:00:55 Media Language 1:02:50 Annexation1:03:39 “Only Democracy in the Middle East”1:07:22 Discriminatory Legislation 1:08:26 Required Reading1:11:19 Never Again1:12:36 Self Determination1:13:23 What the ICJ Said Should Happen1:16:42 Like Minded Countries1:18:27 Restitution 1:19:25 Right to Self Defense1:22:01 New Zealand's New Movement 1:24:31 ClosingsIntro/Outro by The Prophet MotiveSupport us here: https://www.patreon.com/1of200

SummaryRobbie Lashua discusses the Stand to Reason (STR) Outposts initiative, its purpose, and the process of starting one at a local church. He shares his journey of getting involved with STR and his role as the outpost coordinator. The conversation also covers the flexibility of outposts, the target audience, and the use of STRU courses for small group discussions. Robbie is interviewed about STR's Outpost program, which equips local churches with apologetics resources. The program allows flexibility for churches to use other materials but requires adherence to STR's mission statement. Outposts are not meant to teach doctrinal distinctives, and the local church is responsible for indoctrinating its members. Outpost directors have access to resources and support from STR for managing difficult personalities and theological issues. The program has seen significant growth and is open to churches of all sizes.https://www.str.org/outpostsTakeawaysSTR Outposts provide small group curriculum for training lay people in apologetics within local churches.The target audience for STR Outposts is lay people in the church who are not equipped to compete in the marketplace of ideas and culture.The use of STRU courses and small group discussions makes apologetics training more accessible and digestible for lay people in the church. STR's Outpost program equips local churches with apologetics resources and allows flexibility in using other materials.Outposts are not meant to teach doctrinal distinctives, and the responsibility for indoctrinating members lies with the local church.Outpost directors have access to resources and support from STR for managing difficult personalities and theological issues.The program has seen significant growth and is open to churches of all sizes.Chapters00:00 The Purpose of STR Outposts03:16 Starting an STR Outpost at Your Church06:00 Flexibility and Target Audience of STR Outposts22:33 Equipping Local Churches with Apologetics Resources26:24 Navigating Doctrinal Distinctives and Flexibility in Apologetics38:37 Support and Resources for Outpost Directors42:26 Growth and Inclusivity of the Outpost Program================================We appreciate your feedback.If you're on TWITTER, you can follow Chad @TBapologetics.You can follow Brian @TheBrianAutenAnd of course, you can follow @Apologetics315If you have a question or comment for the podcast, record it and send it our way using www.speakpipe.com/Apologetics315 or you can email us at podcast@apologetics315.com

In response to the decision by a number of  European Union states to recognise a Palestinian state and  the legal actions against Israel at the international courts in The Hague, Israel has legalised five  settler outposts across Judea and Samaria. The government also decided to act against Palestinian Authority building infringements in a Wye Accords -designated nature reserve. KAN's Mark Weiss spoke about the measures with Naomi Kahn, director of International Relations at Regavim. (Photo:Reuters)See omnystudio.com/listener for privacy information.

In this episode, we review the Super 8 stage and share our thoughts on the 8 teams and a special focus on Afghanistan Cricket & the importance of the asian nation's qualification to the Semi finals of an ICC tournament. Books & Documentary mentioned on the podcast - Out of The Ashes Documentary by Timothy Albone - https://youtu.be/4H23kHiE_KQ?si=J7DGhzptalkEmQas Second XI: Cricket in its Outposts by Tim Wigmore https://amzn.in/d/0ewwq4ED (We mention the Afghanistan chapter but the book is a great read on Associate outposts of Cricket) Out of the Ashes: The Remarkable Rise and Rise of the Afghanistan cricket team by Timothy Albone https://amzn.in/d/03Tv1dtb — Send in a voice message: https://podcasters.spotify.com/pod/show/thepccipod/message --- Send in a voice message: https://podcasters.spotify.com/pod/show/thepccipod/message

Last time we spoke about the Siege of Myitkyina. General Vinegar Joe made huge gains in northern Burma. Myitkyina's airstrip was taken, now the main town was under siege. The Japanese resistance around Kamaing was greatly reduced. However setbacks were also seen, such as the Chindits abandonment of the Blackpool stronghold, prompting Stiwell to toss a new attack at Mogaung. Likewise American officers embedded with the Chinese units were sending reports of how the Chinese were suffering very heavy casualties and utilizing far too much ammunition for their objectives. Regardless, it seemed the Ledo Road to China was going to pan out. Calvert chose a new stronghold location, this time at Lakum, where his Chindits faced heavy resistance. Over on New Guinea, the allies were advancing west of their new beachheads to assault Lone Tree Hill. Soon assaults against Arare and Biak would also be made. This episode is the Landing against Biak Welcome to the Pacific War Podcast Week by Week, I am your dutiful host Craig Watson. But, before we start I want to also remind you this podcast is only made possible through the efforts of Kings and Generals over at Youtube. Perhaps you want to learn more about world war two? Kings and Generals have an assortment of episodes on world war two and much more  so go give them a look over on Youtube. So please subscribe to Kings and Generals over at Youtube and to continue helping us produce this content please check out www.patreon.com/kingsandgenerals. If you are still hungry for some more history related content, over on my channel, the Pacific War Channel you can find a few videos all the way from the Opium Wars of the 1800's until the end of the Pacific War in 1945.  In the last episode, plans were made for an amphibious assault against Biak, yet there were some hiccups. The Hurricane Task Force staged at Humboldt Bay, were facing issues with terrain. Terrain considerations forced most of the task force to assemble on the southern of the two sand spits dividing Humboldt and Jautefa Bays. On this spit the beach had a steep slope which made it impossible for more than a very few LST's to be held against the shore line long enough to load bulk stores. The LST's had to beach on the northern spit, where clearing and salvage after the fires and explosions which had ravaged that beach during the early phases of the Hollandia operation had not been completed. In addition, the northern spit was being used to unload supplies destined to be used at Hollandia, to load supplies being sent to the Tornado Task Force at Wakde-Sarmi, and to unload cargo for the Hurricane Task Force. No road connected the northern and southern sandspits. Consequently, most of the supplies and equipment, as well as many of the troops, had to be transported by water from the southern to the northern loading area. There were only a few LCT's available for this work and only by working twenty-four hours a day, were all the troops and supplies transported to the loading beach in time for departure on the 25th.  Finally, General Fuller's task force would depart the bay on the evening of May 25th, covered by Admiral Fectheler's cruisers and destroyers. Taking the most direct route, the convoy would be able to arrive off Biak on the morning of May 27th. At the time, Biak was held by the Biak Detachment, under Colonel Kuzume Naoyoki. It consisted of the 222nd Regiment; the 19th Guard Unit; and some rear echelon, service, and construction units. There were 10000 IJA personnel, 4000 were combat troops in total and 2000 IJN personnel, 125 were combat troops in total. In view of the intense enemy concentration on the Sorido-Mokmer airfield sector, Colonel Kuzume decided on May 22nd to shift the operational center of gravity of the detachment to the west. The 1st Battalion, 222nd Infantry, was relieved of its mission in the sector east of Opiaref and sent to replace the naval garrison unit in the Bosnek sector. The naval troops were, in turn, shifted westward into the Sorido airfield sector, while the tank company was brought over from Arfak Saba and assembled in the area northwest of Mokmer airfield. Although most of the Japanese efforts had been directed to the construction of airfields, Kuzume had ably managed to build a system of strong cave positions.  In this amphitheater-like terrain and along the low ridge, both of which were covered with thick growth, the Biak Detachment emplaced many field artillery and antiaircraft weapons. There were also many automatic weapons and a few mortars. All these weapons were located within range of Mokmer Drome and most of them could also fire on Borokoe Drome. The key to Colonel Kuzume's defenses in this area was the West Caves area, located about 50 yards north of the low ridge and about 1200 yards north of the western end of Mokmer Drome. The West Caves were actually three large sumps, or depressions in the ground, which were connected by underground tunnels and caverns. The caves were ringed with pillboxes, bunkers, and foxholes, and an extensive system of coral and log emplacements was built along the spur ridge above Mokmer Drome. Biak naval headquarters was originally located in the West Caves, which could shelter 1000 men, and Colonel Kuzume planned to move Biak Detachment headquarters to the caves for the final defense of the airdromes. As long as the West Caves and the positions along the low ridge were occupied by the Japanese, Allied planes could not safely use the airfields. Chief of Staff of 2nd Area Army, Lieutenant-General Numata Takazo and Rear-Admiral Senda Sadatoshi, Commander of the 28th Special Base Force, with HQ at Manokwari had come to visit the garrison just as the Allies were preparing to invade, with Numata choosing to stay on the island to direct the battle alongside the resourceful Kuzume. Yet all of the Japanese at Biak were about to be caught with their pants down as many of their troops were scattered about the island. The Biak Detachment would not be in their defensive positions on Z Day but were apparently being held mobile. Detachment headquarters, the 1st Battalion of the 222nd Infantry about half of the 19th Naval Guard Unit, and miscellaneous service organizations were all located in a cave and garden area on the inland plateau about 3,000 yards north-northwest of Bosnek. Outposts at Saba and Opiaref were held by the 1st Company, 222nd Infantry, and a platoon of the 2nd Company was stationed along the main ridge behind Bosnek. The bulk of the 2nd Battalion, the rest of the naval guard unit, and some naval antiaircraft organizations were located at the East Caves. Naval headquarters, various naval service units, and the 6th Company, 222nd Infantry, were at the West Caves. Most of the army service units were at Mokmer Drome or disposed along the low ridge north of that field. The bulk of the 3rd Battalion was posted at the west end of the same airfield. One platoon of the 10th Company was at Sorido, guarding the southern terminus of a trail which led north across the island to Korim Bay. The tanks had not yet moved to Saba but were assembled on the terrace north of the eastern end of Mokmer Drome. On the morning of May 27, Fechteler carried out his naval fire support as planned and General Kenney's bombers also launched their air bombardment, receiving little answering fire from the surprised Japanese shore installations. Yet there was a westerly current off Biak that would push the transports over 3000 yards to the west, which would complicate the landings. A rocket-equipped LCI, which began firing on the beaches about H minus 4 minutes, led the first LVT wave toward the shore. The LCI fire, consisting of rockets and fire from automatic weapons, continued until H plus 2 minutes, when it was lifted because it began to endanger the troops who were unloading and pushing inland. The first waves of LVTs then formed rapidly and crossed the line of departure; but because of the westerly current and the smoke and dust raised by the preliminary bombardment, they would end up landing on a mangrove swamp almost 3000 yards west of Green Beach 4. Nevertheless, by 7:30, the 2nd Battalion, 186th Regiment had successfully landed and was pushing beyond the swamps to the main coastal road connecting Bosnek and the airfields. Five minutes later, Companies I and K of Colonel Newman's 186th Regiment also landed about 700 yards east of the 2nd Battalion. Realizing about the westerly current, Fechteler then started to turn succeeding waves eastward to the proper beaches, with the troops coming ashore in disorder for the next thirty minutes.  With more than half of his regiment already far west of the proper landing beaches, and knowing that the landing had become disorganized and that the rest of the boat waves were being delayed, Colonel Newman asked the task force commander if the 186th Regiment should continue with its original mission or whether it might be feasible to switch missions with the 162nd Regiment and start moving west toward the airfields. General Fuller, the Task Force commander, ordered the 186th Regiment to continue with its original mission. As events turned out, it might have been better had the regiment continued west, and it is possible that a great deal of time might have been saved if the missions had been switched. In the first place, the maps with which the task force was supplied were so inaccurate that both regiments soon came upon terrain features that threw much planning out of gear. Secondly, most of the 186th Regiment had landed so far west that both it and the 162nd consumed much valuable time getting to their proper locations. Finally, an exchange of missions might have been executed without much difficulty, for, in amphibious training, the 41st Division had learned to switch missions when such mistakes were made. Luckily, the landings would face no opposition, though the confusion would give Kuzume time to prepare his defense. By 8:00, the rest of Newman's 3rd Battalion had landed to secure the jetties; and by 10:30, Companies I and K arrived to take their position west of Old Jetty. Entangled with the landed artillery and tanks, the 2nd Battalion would only be able to reach the area east of New Jetty by noon, then sending patrols to the north and east to secure the Bosnek perimeter. The face of the coral ridge behind Bosnek was found to be rough and honeycombed with small caves. Companies F and G, aided by elements of the Support Battery, 542nd Engineer Boat and Shore Regiment, sent patrols along the steep slope and to the top of the ridge to investigate many of the caves, most of which proved to be unoccupied, though three Japanese were killed near caves directly north of New Jetty. The companies moved over the first slope to a second ridge line which was parallel to and about seventy-five yards north of the first. Company G started looking for a trail which was thought to lead over the ridges to the plateau north of Bosnek, but it was Company E which, shortly after noon, found the ill-defined track. A few Japanese from the 2nd Company, 222nd Regiment in a pillbox temporarily prevented the two companies from securing the trail, which was not cleared until 2:00 hours, after the pillbox had been destroyed. During the late afternoon, patrols were sent north of the ridges to the area which the Japanese had surveyed for an airdrome. A few Japanese , most of whom fled upon being sighted, were found at the airdrome site, but there were no signs of large organized enemy groups north, northeast, or east of Bosnek insofar as the 186th Infantry could ascertain. The only enemy action during this day would be an air attack by four Japanese bombers.  A few enemy planes which flew over Biak around noon fled before anti-aircraft guns from ship or shore could be brought to bear. But all anti-aircraft crews were on the alert to expect further Japanese air action late in the afternoon. Because of the difference in time of sunset at the closest Allied and Japanese bases, Japanese aircraft could remain in the Biak area about half an hour after Allied planes had to leave. The expected attacks developed shortly after 4:00, when four Japanese two-engined bombers, accompanied by three or four fighters, approached the beachhead from the north, flying low over the ridge behind Bosnek and thus escaping radar detection. Some excellent targets were ready for the Japanese. Admiral Fechteler had permitted four LST's to tie up side by side at one of the jetties. Although he knew this move to be tactically unsound, he considered it justified because of the importance of the cargo aboard the LST's and because the jetty provided the only good spot for LST beaching. The Japanese bombing was accurate, but the LST's were lucky. None of the Japanese bombs exploded! Though the Japanese planes also bombed and strafed the beaches, none of the bombs dropped ashore exploded, while the strafing runs killed only one man and wounded two others. All four bombers were shot down by ground or ship-based antiaircraft, and the Japanese fighters were driven off by some Allied fighter planes which had remained late in the area. One Japanese bomber crashed into the water, sideswiping an SC which was standing offshore. Two of the ship's crew were killed and nine wounded. The SC had to be towed away for repairs, and a few other naval vessels suffered minor damage from strafing. There was negligible damage to supplies and equipment ashore. Total Allied losses as a result of the air raid were three killed and fourteen wounded, most of them naval personnel. Unloading also progressed satisfactorily, with 12000 men, 12 medium tanks, 29 artillery pieces, about 500 vehicles, and an estimated 3000 tons of bulk cargo being landed by 5:15. Meanwhile, Colonel Haney's 162nd Regiment had begun landing shortly after 9:00 and immediately started moving west along the main coastal road towards Biak's three airdromes. Moving with speed, the 3rd Battalion passed through Ibdi village at 10:30 and then began to traverse the difficult Parai Defile. At 11:15, the regimental Intelligence and Reconnaissance Platoon discovered an enemy position on the face of the cliff west of Ibdi, that the 162nd Infantry first learned of the existence of the Parai Defile. At 1:00 the 3rd Battalion, with six tanks of the 603rd Tank Company leading the advance, arrived at the eastern entrance to the defile. There was no large Japanese force stationed along the cliff, but the few Japanese had such a tactical advantage over troops moving along the coastal road that they were able to delay the 162nd Infantry's advance for some time. Meanwhile Company E, which had been attempting to advance along the ridge north of the rest of the regiment, had found that the terrain and thick vegetation made progress along that route next to impossible. Since the company was lagging far behind the rest of the advance and since strong enemy opposition had not yet been encountered either inland or on the coastal route, it withdrew to join the rest of the 2nd Battalion on the beach, and by the time that battalion had reached Parai, Company E was back in place.  By 3:00, the 3rd Battalion had successfully pushed through the defile and had secured Parai and a large jetty at that village. Progress west of the Parai Defile was without noteworthy incident during the rest of the afternoon, so Haney's 2nd and 3rd Battalion would be able to dig in at Parai by nightfall. On the other side, Kuzume was surprised by the landings, but he was expecting the enemy to land exactly there, where the extreme narrowness of the beach and the few entrances inland would make deployment difficult. Deciding to seize this momentary advantage, he thus ordered his 1st and 3rd Battalions to carry out an attack all along the Bosnek beachhead during the night. On the 3rd Battalion front, after an unsuccessful raid against two batteries near Ibdi. Then the 3rd Battalion, 222nd Infantry , renewed the attack with grenades and rifle fire, some circling to the north around Battery C and a few others moving against Battery B, located 200 yards to the east. Attacks on Battery C continued until daylight, when the last Japanese withdrew. The action cost Battery C 4 men killed and 8 wounded, while a near-by antiaircraft detachment lost 1 man killed and 1 wounded. Over 15 of the enemy had been killed during the night and an unknown number wounded. The 1st Battalion also raided the beachhead, suffering many casualties as a result.  On the morning of May 28th, the 162nd then resumed its westward advance, with its 3rd Battalion rapidly proceeding through Mokmer village without opposition. By 9:30, however, the Americans began to face stiff resistance at a road junction nearly 1500 yards west of Mokmer. Supported by artillery, Company K would be able to push to within 200 yards of Mokmer Drome; yet Kuzume would rapidly counterattack them with his 2nd Battalion. Charging repeatedly, the Japanese would eventually force the Americans to pull back by noon, with Lieutenant Yokoyama Hideo dying heroically during these attacks. Emboldened by this success, Kuzume then launched an all out assault from the East Caves area. On the main ridge north of Mokmer the Japanese had another strongpoint east of the West Caves, which was called by the Japanese the East Caves. Behind Mokmer the ridge rose to a height of 240 feet. It was not so steep a cliff as the Parai Defile barricade, but it could not be climbed without the use of hands. About three quarters of the way to the top was a flat ledge from which two large caverns, similar to those in the West Caves area, could be entered. The Japanese constructed pillboxes on the ridge both below and above the ledge, and in the caverns they emplaced mortars, 20-mm. guns, and heavy machine guns. Observation posts were also set up at the East Caves, from which an unobstructed view of the coast from Parai to the west end of Mokmer Drome could be obtained. The Biak Detachment used the East Caves principally as living quarters, supply dumps, and as a connecting link between the Ibdi Pocket and the West Caves. Continued Japanese occupation of the East Caves would endanger Allied troop and supply movements along the coastal road from Parai to Mokmer Drome. The enemy threw more troops into the battle from the East Caves area until the attackers were coming not only from the west but also from the northwest and north. The Japanese split the 3rd Battalion by driving a wedge along the cliff between the troops on the shore and those on the terrace. Companies L and M were cut off. The 2nd Battalion, attempting to get on the terrace to the north of the 3rd Battalion, was pinned down by Japanese fire from the East Caves and was unable to advance. Company G, on the terrace north of the main road and between the 2nd and 3rd Battalions, was also cut off. In response to the attacks, Haney ordered the 1st Battalion to move north from Parai onto the main coastal ridge to outflank the enemy positions, but efforts to do so were halted by enemy fire from the East Caves. Two companies patrolled in the broken terrain along the main ridge but were unable to move westward. Most of Company L and the Company M detachment which was also on the coral terrace managed to find a covered route back to the rest of the 3rd Battalion on the shore, but one platoon, initially surrounded, had to fight its way eastward into the lines of the 2nd Battalion, north of Mokmer village. Company G, on the terrace north of the main road and between the 2nd and 3rd Battalions, was also cut off and withdrew to the 2nd Battalion only with difficulty, and after it had suffered many casualties from Japanese fire. During the afternoon the 3rd Battalion stood off two more concerted enemy counterattacks, one at 12:00 and another shortly after 2:00, and suffered more casualties from the enemy mortar and artillery fire. During the latter attack, the Japanese began moving some light tanks forward from the Mokmer Drome area. The 3rd Platoon, 603rd Tank Company, engaged these tanks at a range of 1,200 yards and, with the aid of fire from destroyers lying offshore, drove the enemy tanks back into defilade positions. Three tanks of the 603rd were damaged by Japanese artillery fire and three men of the same organization were wounded during the action. Meanwhile, General Fuller had decided to reinforce the 3rd Battalion, 162nd Infantry. The 1st Platoon, 603rd Tank Company, moved west along the coastal road. At the same time small boats manned by the 542nd Engineer Boat and Shore Regiment were also sent forward with ammunition and medical supplies, both dangerously low. The small craft moved along the shore out of range of Japanese mortar and artillery fire until opposite the 3rd Battalion's position and then shot inshore at full speed, one by one. Supplies were replenished and the worst casualties evacuated despite continued shelling of the 3rd Battalion's position by the Japanese. The 1st and 2nd Battalions continued their efforts to clear the Japanese from the terrace behind the 3rd but met with little success. By late afternoon, just as the 3rd Battalion's position was becoming untenable, Fuller gave up plans for further attempts at reinforcement and ordered Haney to withdraw his 3rd Battalion. The withdrawal started slowly because communications difficulties still prevented concentration of supporting fires. However, at 5:00 the regimental commander finally ordered the 3rd Battalion to start moving back along the coastal road. Tanks were to act as point, and rear guard and close-in artillery fire was substituted for a disengaging force. The battalion was to continue eastward until it had passed through the 2nd, which was setting up a new defensive position east of Mokmer village. The men of the 3rd Battalion moved in small parties along the beach and main road, which was intermittently swept by Japanese mortar, machine gun, and rifle fire. Many troops were unable to use the main road, but had to drop down to the beach below the overhanging cliff. Four tanks brought up the rear and protected the north flank. Between 1830 and 1900 all elements of the 3rd Battalion reached safety beyond the 2nd Battalion's lines and began digging in for the night east of the latter unit. Casualties for the day, almost all of them suffered by the 3rd Battalion, were 16 killed and 87 wounded. Facing strong resistance, he also decided to commit his tank company to the attack. At around 8:00, new waves of Japanese infantry, now supported by four tanks, appeared west and north of the 2nd Battalion, thus beginning the first tank battle of the war in the Southwest Pacific Area. The 2nd Battalion, 162nd Infantry, with the 1st Platoon, 603rd Tank Company, in support, was astride the main coastal road 1,000 yards east of Mokmer. The battalion's left flank was on the beach while its right was against the coastal cliff and less than forty yards inland. Between the beach and the cliff was a coconut grove. The main coastal road crossed the rise of the cliff at a point about 475 yards west of the 2nd Battalion's lines. Shortly after 8:00 the Japanese tanks, followed by an infantry column, advanced down the incline where the main road crossed the cliff and deployed in echelon left formation in the coconut grove. The Japanese vehicles were light tanks, Type 95, weighing about nine tons, carrying a crew of three men, and armed with one 37-mm. cannon and two 7.7-mm. machine guns. They were opposed by two General Sherman M4A1 medium tanks, the heaviest armament on which was the 75-mm. Each Japanese tank was stopped by one round of 75-mm. armor-piercing ammunition, while the enemy infantry was literally mowed down by the machine guns and mortars of the 2nd Battalion, 162nd Infantry. Armor-piercing 75-mm. shells passed right through the Japanese light tanks, and the Shermans followed with a few rounds of 75-mm. high explosive, which tore holes in the Japanese vehicles and blew loose their turrets. During this action several hits scored on the Shermans by the Japanese 37-mm. guns caused no damage. About thirty minutes after the first attack the Japanese sent in a second wave of three tanks, which used the same route of approach and the same formation in the coconut grove. These three were quickly destroyed by three Shermans. One enemy 37-mm. shell locked the 75-mm. gun of one Sherman in place, but the American tank backed part way into a shell hole to obtain elevation for its weapon and, despite the damage, managed to destroy one of the enemy tanks. The Japanese tanks having been stopped and the leading elements of the second infantry wave killed, the attack disintegrated and the enemy withdrew. For an hour or so the Japanese were quiet, but late in the morning, under the cover of machine gun fire and mortar barrages, they began to circle north of the 2nd and 3rd Battalions, 162nd Infantry. New infantry attacks began about 12:00. The enemy was unable to dislodge the 162nd Infantry, but his mortar fire caused many casualties within the regimental perimeter and the Japanese managed to cut the coast road east of a large T-jetty at Parai. Company B and the Cannon Company counterattacked the Japanese roadblock behind close-in mortar support and succeeded in dislodging the enemy by fire and movement. During the afternoon of May 29, the 162nd thus moved back to Parai, where the 2nd Battalion and two companies boarded some amphibious craft back to Bosnek while the rest of the regiment moved overland through the Parai Defile and took up positions at Ibdi The 162nd Infantry's casualties during the day were 16 killed, 96 wounded, and 3 injured. The regiment estimated that it had killed over 500 Japanese during the day. Though Kuzume's forces had suffered massive casualties, they had heroically managed to stop the enemy advance and would subsequently push troops forward to Parai and into the cliffs along the Parai Defile. They would however also lose most of their armor during these attacks. Only five tanks survived and were withdrawn to the West Caves. Pending the arrival of reinforcements, General Fuller planned to use his available troops to hold the west flank at Ibdi and expand the beachhead at Bosnek. The 162nd Infantry was to establish a semicircular perimeter beginning on the beach west of Ibdi, reaching north to the main ridge, and returning to the beach at the village. The 1st Battalion, 186th Infantry, would maintain a perimeter around Mandom, where the Hurrican Task Force HQ was located, while the 3rd Battalion moved over the ridge behind Bosnek to set up defenses on the inland plateau. The 2nd Battalion, with part of the 3rd attached, would remain at the Bosnek beachhead. During this period, the 800 well-armed men of the 3rd Battalion, 222nd Infantry in the Ibdi Pocket, made only harassing attacks with small groups against the positions of the 162nd Infantry. On 30th and 31st of May the 162nd Infantry patrolled around the main ridge near Ibdi for a route over which large bodies of troops might move north to the inland plateau in preparation for the second attack westward. During the course of this patrolling, it was discovered that the main ridge from Bosnek to the Parai Defile actually comprised a series of seven sharp coral ridges, the crests of which were 50-75 yards apart and separated by gullies 50-100 feet deep. These separate ridges were honeycombed with small natural caves, potholes, and crevices. There was little soil on most of the coral, yet the area maintained a cover of dense rain forest containing trees 8-20 inches thick and 100-150 feet high. The 162nd Infantry discovered two native trails over the ridges. The most easterly of these, designated "Old Man's Trail," began on the beach road about 1,200 yards west of Mandom. It was a fairly well defined track which swung north over the seven ridges along a comparatively easy route. Another track began 1,200 yards to the west, near Ibdi. Called "Young Man's Trail," the latter followed a very difficult route over the ridges to the inland plateau. Both of these trails ran through the outer defenses of the Ibdi Pocket, into which the Biak Detachment, on 30 May, moved the 3rd Battalion, 222nd Infantry. On 30 and 31 May the 162nd Infantry's patrols along the ridges north of Ibdi and Mandom were harassed by the Japanese in the Ibdi Pocket, which had not yet been recognized as a major enemy strong point. On 30 May the 162nd Infantry located a water hole near the beach terminal of Old Man's Trail. A regimental water point established there was constantly harassed by Japanese rifle fire from the Ibdi Pocket area or by small enemy parties which moved down out of the ridges north of Ibdi and Mandom. The Cannon Company, 162nd Infantry, was therefore assigned the missions of clearing the enemy from the water point area and protecting that important installation from Japanese attacks. Halfway through the Parai Defile, a little over a mile west of the 162nd Infantry's main perimeter, an underground stream ran from the base of the cliff into Soanggarai Bay. At the point where the main road crossed the stream, the 162nd Infantry set up an ambush to prevent Japanese infiltration from the west along the beach. The ambush site was also used as a patrol base from which small parties reconnoitered along the cliffs of the Parai Defile to discover enemy dispositions in the area. Patrolling on 30th and 31st of May cost the 162nd Infantry 6 men killed, 17 wounded, and 4 injured. On the main coastal ridge between the village of Ibdi and the Parai Defile the Biak Detachment developed another center of resistance which came to be known as the Ibdi Pocket. The terrain in the area was a series of knifelike east-west ridges separated by depressions and crevices up to fifty feet deep. These ridges were connected in places by cross-ridges, and the entire area was covered with thick rain forest and dense jungle undergrowth which had found a foothold in the coral. Pillboxes of coral and logs, hasty emplacements of the same materials, small caves and crevices, and foxholes at the bases of large trees were all utilized by the enemy to defend the area. Back to the Wakde-Sarmi area, General Patrick was preparing to launch another assault on Lone Tree Hill. On the morning of May 27th at 7:00 two destroyers, firing on Lone Tree Hill and the Maffin Strip area, started scheduled fire support for the day's advance. Artillery and infantry action on this morning was much more closely coordinated than on the previous day. The destroyer fire lasted until 7:45, at which time the field artillery and all the 81-mm. mortars of the 158th Infantry laid concentrations on suspected and known enemy positions in the defile, on Lone Tree Hill, and on Hill 225. After this Colonel Herndon sent his 1st Battalion against the defile between Lone Tree Hill and the eastern nose of Mount Saksin and his 2nd Battalion against Hill 225. At 8:30 Company F, moving around Company E on the south flank, started its attack. Behind close artillery support, apparently controlled by artillery liaison planes for the most part, Company F pushed up a terrain feature initially believed to be Hill 225. It was not discovered until late the next day that F Company was actually on the eastern nose of Mt. Saksin and about 700 yards east of its reported location. Since artillery fire had knocked out two enemy machine gun nests which had been delaying the advance, patrols of Company F were able to reach the top of the eastern ridge. The rest of the company moved up the hill at 10:00; encountering scattered rifle fire from enemy positions to the southwest. Company E, just before noon, arrived atop the same hill on F's right. Company E had orders to secure the southern slopes of the defile between Hill 225 and Lone Tree Hill. Company B, still at the eastern entrance to the defile, was again unable to make any progress and during the morning was held up by machine gun and mortar fire from concealed enemy positions on the southern and southwestern slopes of Lone Tree Hill. No sooner had some of these positions been eliminated by American artillery and mortar fire than Company B was subjected to enemy machine gun and mortar fire originating from the northeast side of Hill 225, the reported location of Companies E and F. Actually, the artillery fire had not been entirely effective, because it had not reached into deep draws or caves in which many of the Japanese weapons were emplaced. Company E, attempting to move down the northern slopes of the eastern ridge to Company B's aid, was soon forced back by enemy rifle fire and infantry counterattacks from the west. At the same time small parties of Japanese, under cover of their own machine guns, started a series of minor counterattacks against Company B. Company F did not become engaged in this action. Instead, the company dug in on the ridge it was holding and sent patrols to the south and west to probe Japanese defenses. It was soon discovered that the combination of rugged terrain and Japanese machine gun and rifle fire limited patrolling to a very small area. North of Company B, Company A patrolled along the west bank of the Snaky River and on the eastern slope of Lone Tree Hill during the morning and early afternoon. About 4:30 the company moved in force up Lone Tree, finding the eastern slope of the hill to be unoccupied. Most of the fire that had harassed the company during the morning had apparently originated on the beach below the northern face of Lone Tree Hill. For the night the unit dug in at the crest of the hill. Again, little ground had been gained, although the eastern nose of Mr. Saksin and Lone Tree Hill had been at least partially occupied. At the same time, Patrick was informed that two battalions of the 163rd Regiment would be shipped to Biak to reinforce Fuller on June 1st, with General Krueger also preparing the 6th Division led by Major General Franklin Silbert  to be dispatched to Wakde to replace the 163rd. Yet before this could occur, Colonel Matsuyama crossed the Tementoe River and launched a surprise night attack against Toem. During pitch-black night at 8:30, an estimated 100 Japs struck 1st Battalion's area. Divided into small groups, but in two major commands, they carried grappling hooks, knives, grenades, knee-mortars, and rifles. Their grappling hooks had two prongs, like anchors and were attached to long ropes by which they could pull to explode booby traps harmlessly. A knee mortar barrage began the attack. While their mortars drove the men to ground, their grappling hooks caught booby trap wires and exploded attached grenades. They struck from southeast and southwest, two different commands about 150 yards apart. First command shouted wildly and threw grenades. They fired a light machine gun down A Company's street and holed up their tents. But this command's howling rush with grenades was just a feint to cause confusion. The second command, around 35-40,  made the main drive. Easily they broke through 1st Battalion's far-spread perimeter holes. An estimated 25 made the serious penetration. They were trying to reach the Regimental command post to kill the top officers. Some of the staff officers were actually cut off outside their holes in a tent and actually unarmed. Ten Japanese almost reached the command post before they were cut down. Such was the official report, but 163rd men said that they tried to blow up the motor poo, nearly 100 of them. From a slit trench, four blazing M-1s stopped them, from the motor pool chief Staff Sergeant Burton, Staff Sergeant Engbretson, T/4 Switzer, and T/5 Donakowski. They piled up 13 dead Japanese, the last just 20 feet away. On a whistle signal, all Matsuyama's men withdrew. The wild attack prompted Patrick to not to ship the 163rd towards Biak. The following morning, after another well-timed preliminary artillery bombardment, Herndon once again threw his forces against the Ilier Mountains, yet the result was the same as before. Nonetheless, his troops would be able to cover the amphibious arrival of two tanks to aid in further attacks; but with the situation soon becoming untenable because of strong Japanese counterattacks, all his companies ultimately had to withdraw to the Snaky River line. On May 29th, Krueger finally notified Patrick that the two battalions of the 163rd would have to leave for Biak the next day, so this would force Patrick to cease offensive action and withdraw the 1st Battalion, 158th Regiment back to Arare. Yet further Japanese counterattacks also forced Herndon to withdraw his remaining forces to the Maffin area as well, where he would form a new defensive line.  Patrick ultimately disagreed with Herndon's decision to retreat, judging the withdrawal to be unwarranted and would relieve Herndon of his command, replacing him with Colonel Earle Sandlin. Colonel Herndon's fears of attack along his line of communications had been well taken, for the Right Sector Force had begun flanking movements designed to recapture the entire Maffin Bay area. However, the combat engineers quickly proved their versatility by driving off the enemy force with rifle, carbine, and machine gun fire. Five of the engineers were killed. Enemy casualties could not be estimated since the Japanese removed their dead and wounded during the night. The remainder of the night was more quiet, and the next morning the defenses along the Tirfoam were improved. There were a couple of minor attacks during the afternoon and desultory rifle and 70-mm. or 75-mm. artillery fire was directed against all American units still west of the Tor. The 147th Field Artillery Battalion, withdrawing to the east bank of the Tor late in the afternoon, was struck by some of this enemy artillery fire and lost one man killed. A new defensive line along the Tirfoam was being developed on May 30th as the bulk of the 163rd Regiment would depart for Biak. This left Patrick's forces spread out over almost twelve miles of coastline, just as Colonel Yoshino was about to launch his night attack. After the difficult river crossing, the 223rd Regiment had spent three days moving into the jungle southwest of Arara, from where they launched a series of simultaneous attacks against some anti-aircraft positions along the beach.  A 6:05 on June 30th, a guard at B Battery's Position No 6 challenged two men in the jungle across the beach road. Other Japanese were moving west down the road. When they did not answer his challenge, he fired, and hit the ground. Instantly, Japanese machine guns, rifles, mortars, and even grenades hit the B-6 position. The anti-aircraft men killed 10 Japs, but one heavy machine gun jammed. The second gun became overheated and had to cease fire. The Japanese were hard to hit in the dark. They were heavily camouflaged with leaves and nets down to their hips. After one American was killed, the anti-aircraft men left their emplacement and fled 500 yards east on the beach road to Battery A's Position 7. Joined with the men of A-7 - they had already stopped one attack - the B-6 men helped fight about 15-25 Japanese. From 6:40 to 4:30 next day, the Japanese struck intermittently, but rifle and machine guns fire repelled them. About 500 yards west of the B-6 position where the first attack had occurred, Battery A-6 also endured harassment from Japanese mortar, rifle, and machine gun fire. At least twice, the gunners repulsed attacks. A fourth position, Battery B-8, which was 400 yards west of A-6, was assailed about 6:30 also. The anti-aircraft men's .50 multiple heavy machine gun became overheated and jammed. Rifle ammo was running out. Scurrying from the gun-pit, they took cover in the shore brush until the Japanese left at 4:30. All attacks began about the same time, about 8:30, and some men glimpsed a Jap officer with his saber who was giving orders. All Japanese dead had rolls of white gauze in their mouths, and the Japanese officer had completely covered his lower face. The Americans thought that they used these means to prevent them from shouting or screaming when they were wounded. While they attacked the anti-aircraft batteries, Yoshino's men also tried to storm 1st Battalion 158 Infantry protecting Task Force Headquarters and the supply dumps. About 7:00, rifle and machine gun fire began impacting 1st Battalion positions. A captured heavy machine gun fired also. At 10:00 came a furious suicidal attack against B Company - beaten off with rifles, grenades, bayonets, pistols, and even knives. They failed to fire the supply dumps with demolition charges and Molotov cocktails. In the end, the Americans miraculously only lost 12 killed and 10 wounded while inflicting heavy casualties on the enemy. But fearing more enemy attacks, Patrick would decide to reduce the number of separate perimeters along the beach, from 21 to only 8.  The bulk of the 158th had to withdraw behind the Tor, leaving only its 2nd Battalion west of the river to secure the bridgehead. Facing little resistance, the Japanese recaptured Maffin, though they would be unable to push Sandlin's troops behind the river. Yoshino and Matsuyama were unable to coordinate their efforts however, allowing the Americans to continue to strengthen their defenses for the next few days, with the Japanese only able to launch nightly raiding attacks that were easily repelled. On June 5, the first units of Major-General Franklin Sibert's 6th Division then began to arrive, freeing up the 158th to continue with its offensive.  Sandlin then launched an attack with his 1st and 2nd Battalions supported by tanks crossing the Tor to attack Maffin on June 8, meeting increasingly strong enemy resistance from a line of hastily-repaired bunkers and pillboxes. The tanks were able to reduce the Japanese defenses due to their strong firepower, but not before the Americans had to dig in by nightfall.  The night passed without incident and early on June 9th patrols began to probe westward toward the Tirfoam. Scouts reported that the Japanese were holding another defense line, including reoccupied bunkers, on a slight rise at the west bank of the river. About 10:00, tank-infantry teams began to destroy the Japanese-held positions along the new line. While tank 75-mm fire was destroying bunkers or forcing the Japanese to seek cover, infantrymen crept forward to toss grenades into bunker gun ports or shoot down Japanese who tried to escape from the area. While these tank-infantry team operations were taking place, the rest of the two infantry battalions rested. Japanese 75-mm. fire, from a weapon emplaced on the beach between the Snaky River and Lone Tree Hill, harassed the 1st Battalion for a while, but this fire was summarily stopped when a 155-mm howitzer of the 218th Field Artillery Battalion scored a direct hit on the enemy piece. By 11:30 the enemy defensive positions had been cleaned out and the 1st and 2nd Battalions resumed the advance westward. Aided by fire from the 147th Field Artillery, which had supplanted the 167th in the close support role, the two infantry units probed cautiously forward, and it was not until 3:30 that both reached the east bank of the Tirfoam. Opposition was scattered, but the American units lost 6 men killed and 6 wounded. It was estimated that 50 of the enemy had been killed and one was captured. At this point, the 158th would have to stop its advance because they received new orders from Krueger, who planned to employ the regiment for an assault on Noemfoor Island, 300 miles northwest of Sarmi, in late June or early July. As such, advances west of the Tirfoam would be postponed until a second combat team of the 6th Division could arrive in the area to relieve the 158th in mid-June.  General Sibert assumed command of the Tornado Task Force on June 12th. On 10 and 11th June the 158th Infantry limited its activities to patrolling, consolidating defensive positions, and driving Japanese outposts westward. One outpost, lying southeast of the 2nd Battalion, was manned by about a hundred Japanese and had to be cleared by tank fire and infantry assault. The Japanese, who were members of a 223rd Infantry company assigned to the Right Sector Force, fled toward Mr. Saksin, leaving behind 4 heavy machine guns, 1 light machine gun, 2 70-mm. howitzers, and 1 37-mm. antitank gun. On 14 June the 20th Infantry, 6th Division, relieved the 158th Infantry at the Tirfoam. The 158th recrossed the Tor and went into a defensive perimeter on the west bank of Tementoe Creek. Patrols sent south and east during the next week encountered a few stragglers from the Japanese garrison at Hollandia or from the Matsuyama Force. On the 22nd the entire regimental combat team was relieved of all combat responsibility in the Wakde-Sarmi area and began final preparations for the Noemfoor Island operation. During its operations in the Wakde-Sarmi area the 158th Regimental Combat Team lost 70 men killed, 257 wounded, and 4 missing. The unit took 11 Japanese prisoners and estimated that it killed 920 of the enemy. With their supply line compromised, Yoshino and Matsuyama would also decide to withdraw from their present positions about this time, which would allow the 36th Division to establish better defensive positions in the Ilier Mountains line. Yet that is all for Operation Tornado and Hurricane for now, as we now need to head over to the Imphal-Kohima front. By June, the situation at Manipur saw General Slim's 14th Army losing all of their advantages. Despite the extreme odds, with a slim chance of success, General Mutaguchi continued his wild attacks against Imphal. As it was, the two armies had been battling it out in difficult terrain and conditions. There were the steep and often jungle-covered hills, the heat for men not accustomed to it, the risk of tropical diseases like malaria and the leeches – not to mention the weeks and months of both physical and psychological strain from fighting a formidable enemy. The monsoon rains that began later in May only made matters worse. As the days passed by, the low-lying areas in the Imphal Valley would flood because of the downpours, while the streams and small rivers everywhere would become raging torrents. The water level of Loktak Lake would also rise, making it especially uncomfortable for the units of both sides dug in at some of the lakeside villages on the Tiddim Road. Dysentery and diarrhea became an ever-greater concern. Foot rot would start to set in for men in their flooded positions. The slopes in the hills became slippery and that much more treacherous to navigate. The incessant rains would dissolve stretches of ‘fairweather' roads and ‘jeepable' tracks into mud and slush everywhere, while triggering landslides in the hills. For the units on higher altitudes like the Shenam Saddle, Point 5846 and the Ukhrul area, the nights would become shockingly cold and damp, adding to their misery. Yet things were undoubtedly harder for the Japanese, who had carried few supplies and didn't expect to be strung out fighting for so long.  To the north, General Sato's 31st Division were withdrawing from Kohima towards Ukhrul, defying Mutaguchi's orders, with General Miyazaki providing rearguard at Viswema, whileGeneral Grover's 2nd Division pursued them. Miyazaki's men held out at Visweman until June 12th, before withdrawing to Maosongsang. Then they held out at Maosongsang until June 16, before retreating to the last holding position at Maram. Over to the south, General Brigg's 5th Division was engaging Colonel Matsumura's 60th Regiment, fighting brutally for control over the Imphal-Kohima road. The battered Japanese defenders were fighting tooth and nail to prevent the opening of this vital supply line.  The 9th and 123rd Brigades pushed on, they would only be able to capture the Zebra hill on June 7. The following day, the 3/14th Punjabis made a wide hook and arrived on the road behind Japanese lines by nightfall, where they would repel three heavy counterattacks. This would allow the 123rd to clear the hill positions near Modbung and link up with the Punjabis on June 11th. The 9th Brigade made great progress during these days, pushing on to Satarmaina by June 13th. General Gracey's 20th Division was also attacking towards the Ukhrul Road during this period, with the 80th Brigade advancing northwards from Kameng up the Iril River Valley on a wide encircling move towards Litan while the 100th Brigade attacked up the road towards Kasom. Though the 80th faced little resistance, the 100th would struggle to progress against the fierce counterattacks of the recently-arrived 67th Regiment. By mid-June, the 51st Regiment was also ordered to abandon its positions and support the 67th on the Ukhrul Road.  Over in the southwest front, the arrival of reinforcements in the form of the 2nd Battalion, under the command of Colonel Yanagisawa Kanji at the end of May, gave General Tanaka a gleam of hope that he could launch another offensive in early June. On June 6th, four battalions under Colonel Sasahara attacked the 63rd Brigade's hill positions, applying such great pressure, General Cowan was forced to withdraw his brigade to Bishenpur the following day. On June 7th, Tanaka ordered his recently-arrived reinforcements to clear Ningthoukhong and retake Potsangbam, yet their first coordinated attack would end in failure. The attack was almost single-handedly held by Sergeant Hanson Victor Turner of the 1st West Yorks. Defending his platoon's position on the perimeter, Turner grabbed some grenades and charged forward, throwing them at the Japanese. He did this five times, going back to gather grenades each time and returning to the attack in the face of Japanese grenade and small-arms fire. He was killed on the sixth occasion while throwing a grenade. For his bravery, Turner was posthumously awarded the Victoria Cross. The Japanese eventually captured some ground in North Ningthoukhong, but withdrew after being struck from the air and shelled. In the meantime, after the Japanese defeat at the Gibraltar Box, the Yamamoto Detachment would continue to harass the British-Indian positions from Nippon and Scraggy Hills in early June. On the evening of June 9, the Japanese put in their last major attack on Scraggy, starting with a heavy artillery bombardment. Artillery concentrations were directed at the Japanese and an airstrike was made on their part of Scraggy and Lynch. The Gurkhas followed up with an advance. Although some ground was recovered, the Japanese maintained their grip on Scraggy's crest. Having suffered many casualties and feeling that the Gurkhas' new position was sufficiently strong, General Roberts then decided to halt the counterattacks, thus leaving General Yamamoto in control of Scraggy up until the end of July. Concurrently, as a last hope to break through towards Imphal, Mutaguchi was planning to conduct a desperate offensive on Palel with some reinforcements that would fail to arrive in time. Due to these delays, he would end up sending some of Yamamoto's exhausted troops to recover Langgol and advance to the hill northeast of Palel. The Japanese managed to get beyond Langgol and attack some positions in the foothills near Palel Airfield, but were soon rebuffed. They finally sent in a commando raid on the airfield in early July, which succeeded in blowing up eight planes. Over in Ningthoukhong, Tanaka launched another heavy assault on June 12th. Though a salient on the other side was initially captured, a ferocious counterattack would ultimately evict them. This action was performed by units of the 48th Brigade, including reinforcements sent from Potsangbam.  Rifleman Ganju Lama of the 1/7th Gurkha Rifles who earned a Victoria Cross in this action. To the west, Tanaka ordered the newly-arrived 151st Regiment of Colonel Hashimoto Kumakoro to attack the British picquets overlooking the Silchar Track. After a wave of assaults, Water Picquet would fall on June 21; yet the 32nd Brigade would respond immediately with a series of counterattacks that developed into confused fighting as positions were won and lost by both sides.  On the night of 25 June, no less than a company of Japanese began attacking Mortar Bluff, a picquet position bereft of cover and a short distance away from Water Picquet. It was held by a small garrison of some 40-odd men of the 2/5th Royal Gurkha Rifles who had replaced the 7/10th Baluchis. In pouring rain, the Japanese first bombarded the position with mortars and guns at point-blank range. For the next few hours, the infantry repeatedly attacked the surrounded and dwindling garrison. Subedar Netra Bahadur Thapa defended the besieged position almost through the night, organizing counter-attacks with whatever ammunition and grenades his unit had left. The Japanese finally overran Mortar Bluff the next morning, with Netra Bahadur Thapa fighting to his death. He was posthumously awarded the Victoria Cross. A few hours later, a company of the same unit formed for a counterattack on Mortar Bluff. In the face of heavy fire, Naik Agan Singh Rai led his section in charging a Japanese machine-gun post and killing its crew. It then recaptured Mortar Bluff and neutralized a 37mm gun position and crew. Rai now advanced on a Japanese bunker and killed its occupants, after which his company also recovered Water Picquet. For his actions that day, Rai won the Victoria Cross, the second for the 2/5th Royal Gurkha Rifles the same day. Faced with such counter-attacks and intense artillery fire from Gun Box, the last throw of the Japanese 33rd Division around the Silchar Track ended in failure. This left Hashimoto and Tanaka empty-handed for all the losses they had suffered. Tanaka was forced to withdraw units before they were annihilated. On July 2st the 214th Infantry, with only 400 effectives remaining, completed its withdrawal to the area south of Nouyangtek and the 151st was directed to move back to Laimanai. Having been decimated by sickness and straggling en route to the front, the strength of the entire 151st Infantry Regiment was, at that time, less than 100 men. Back in the north, Briggs' units continued to struggle for control of the Satarmaina area. The struggle over the next week centered on the main feature east of the road, the hill named Liver. The 3/9th Jats attacked repeatedly to try to dislodge the Japanese from this feature. One such attempt was made on June 15th, when Hurribombers strafed the hill, followed by heavy artillery concentrations from 25-pdrs, 3.7in  howitzers and 3in  mortars. A Jat company climbed the hill, but had to withdraw some 100 meters from its objective because of heavy machine-gun fire. At the same time, the 1/17th Dogras were sent off on a wide hook left of the road and the 3/14th Punjabis were able to secure the Octopus position by June 20.  North of them, Grover's troops would also be able to break through Maram and continue south down the road on June 20, finally meeting the Dogras two days later. Beaten, Miyazaki had nonetheless fulfilled his task and could now withdraw east towards Ukhrul. Sato's rearguard fought determinedly. Often a few men with an artillery piece, grenades and a machine-gun would take up positions on the high ground above tracks, ambushing the British advance guards before melting away to repeat the performance a few km further back or, as was often the case, remaining obstinately in their positions until they were killed. Few were free from disease and fatigue, but surrender played no part in these men's vocabulary; they fought on till overtaken by a British bullet or bayonet or, more often, by starvation and exhaustion. But the 31st Division had literally fought itself to death. Exhausted men lay in pits unable to defend themselves, suicide squads with anti-tank mines tottered towards the advancing Lee Grants and Stuarts to be mown down by accompanying infantry, or obliterated by shellfire Although the battered 31st Division would manage to survive the Kohima disaster, General Sato would be relieved of his command as he had refused to carry Mutaguchi's orders numerous times. As a result, Miyazaki was promoted to Lt-General and given temporary command of the division by the end of June. Meanwhile, though his men had resisted like demons, Matsumura now had no choice but to abandon the road and retreat east towards Ukhrul with what remained of his command due to this new threat to the north. On June 21, the Liver position would fall at last. Again, the Japanese positions were bombed and strafed from the air, this time by three squadrons of Hurribombers for half an hour. The 4th and 28th Field Regiments, as well as a troop of the 8th Medium Regiment, fired a concentration on Liver that covered it in dust and smoke. Three companies of the Jats now went in, and yet this attack was also held by the Japanese on and around Liver. They had had enough, however, and by the next morning were found to have withdrawn from the feature. The Jats suffered around 150 casualties that week, including 33 killed. The 15th Division would adopt new defensive positions at Ukhrul to cover the withdrawal of Miyazaki and Matsumura. The main force of the 15th Division then went into defense positions in a line extending generally from Ukhrul through Tongou, Shongphel and Aishan to the 3524 Pass in order to be in position to cover and pick up the Right Assault Unit and the Miyazaki Detachment as they withdrew to the east. In order to hold the new defense positions, all available men, including all those in the rear service units, were thrown into the line. Finally the Imphal-Kohima road was reopened. Slim knew while the battle was not yet over, it had already been won. I would like to take this time to remind you all that this podcast is only made possible through the efforts of Kings and Generals over at Youtube. Please go subscribe to Kings and Generals over at Youtube and to continue helping us produce this content please check out www.patreon.com/kingsandgenerals. If you are still hungry after that, give my personal channel a look over at The Pacific War Channel at Youtube, it would mean a lot to me. The landings at Biak was another allied success. The first tank battle of the war in the Southwest Pacific Area saw the American Sherman's absolutely devastate Japanese Type-95's. Within the Burma front, General Slim had finally reopened the Imphal-Kohima road spelling doom for Mutaguchi's failed offensive.  

Voice of the Chiefs Mitch Holthus and Senior Team Reporter Matt McMullen discuss the tireless efforts of General Manager Brett Veach and the Kansas City Chiefs scouts ahead of the 2024 NFL Draft. Matt had a chance to catch up with five of those scouts for this week's episode of Defending the Kingdom.See omnystudio.com/listener for privacy information.

Tuap Hoih Na Ding Tawh Kisai thu te // Health talk.Kawikawi + Aw Nem // Chin Gospel Songs.

If you're reading this drop a Comment below

Last time we spoke about the invasion of Eniwetok and the end of Operation HA-GO in the Burma front. While Operation Hailstone was going on, the invasion of Eniwetok was greatly sped up as the Americans were simply too fast at conquering the Marshall islands. Codenamed operation Catchpole, Eniwetok was hit with the same kind of overwhelming force applied to Kwajalein and other islands. Aerial, naval and land base artillery smashed the defenders into submission before forces were landed. The Japanese launched so daring night time infiltration attacks, but were hopeless to stop the American seizure of the island. Within the Burma front the Japanese invaders were shocked at the performance of the newly improved Indian Army. Operation HA-GO was an utter disaster and worse it had weakened the Japanese to the point now the allies were going on the attack.  This episode is the invasion of the Admiralty Islands Welcome to the Pacific War Podcast Week by Week, I am your dutiful host Craig Watson. But, before we start I want to also remind you this podcast is only made possible through the efforts of Kings and Generals over at Youtube. Perhaps you want to learn more about world war two? Kings and Generals have an assortment of episodes on world war two and much more  so go give them a look over on Youtube. So please subscribe to Kings and Generals over at Youtube and to continue helping us produce this content please check out www.patreon.com/kingsandgenerals. If you are still hungry for some more history related content, over on my channel, the Pacific War Channel you can find a few videos all the way from the Opium Wars of the 1800's until the end of the Pacific War in 1945.  The war for the South Pacific is reaching its climax. The allies are securing western New Britain, the Solomons and the Huon Peninsula. The Japanese are simply overwhelmed. The Japanese air forces have been utterly annihilated, their warships are being drained of fuel, are worn down by the war and are seemingly no longer ready for that decisive naval battle envisioned by Isoroku Yamamoto. The men are battle-weary, food is becoming more scarce, malnourishment is spreading. All those strung out at the furthest islands are basically being left to die. To end the misery for those in the South Pacific, the capture of the Admiralty Islands was one of the last steps in Operation Cartwheel and would seal off the Bismarck-Solomons area from supply and reinforcement, denying their use to the Japanese for effective air and naval operations, and left garrisons totaling over 100000 troops in isolated impotence In the South Pacific, the Admiralty Islands, that of Manus and Los Negros stood at the northeastern exist of the Bismarck Sea. They commanded the important strategic point some 600 miles from Rabaul, 820 miles from Truk and 1370 miles from Mindanao Island. The joint chiefs believed Seeadler Harbor had the potential to become a major naval anchorage for the Pacific Fleet and perhaps the springboard for the invasion of the Philippines. Back on April 7th, 1942 a Japanese destroyer and a merchant ship had landed invading forces at Lorengau, driving off the hundred or so Europeans who had been living there. At that time the only airstrip was at Lorengau, the administrative center for the group of islands. Apparently the Admiralties were not considered significant in the offensive phase of the Japanese conquest of the South Pacific area, for it was not until February 1943, that construction forces started to build a 5000-foot airstrip at Momote Plantation on Los Negros and to put the 3000-foot Lorengau airfield into operational use. After October 1943, the Momote field and the smaller Lorengau strip served as ferrying stops on the replacement routes to Wewak, Hollandia, and Rabaul, until Allied air attacks destroyed the effectiveness of the Admiralties' base. Seeadler Harbor was also being used for surface craft and possibly for seaplanes.  In late 1943, General MacArthur had assigned General Krueger's Alamo Force at that time based in Finschhafen to plan the seizure of the Seeadler Harbor area, with the aim of establishing an airdrome and light naval facilities for the support of subsequent operations along the north coast of New Guinea.  On February 13th however, MacArthur ordered Krueger to seize all of the Admiralty islands and to build air bases at Lorengau and Momote. This was to be Operation Brewer, beginning on April 1st. However one of Lt General Kenney's spotter planes noticed there was no sign of life on the Admiralty Islands and this prompted MacArthur to move up the time table, to the end of February. It would be quite a mistake. MacArthur's chief of intelligence, Colonel Willoughby, was convinced Kenney's intelligence was incorrect and information from ULTRA intercepts seemed to support his claims. It seemed Kenney had been fooled. The Japanese appeared to be absent on the islands, because Colonel Yoshio Ezaki had ordered his men not to move during the day, so as to conceal their work constructing two new airstrips and to conserve anti-aircraft ammunition. In spite of Kenney's arguments that the Japanese looked vulnerable, MacArthur's staff officers were not at all happy at the idea of taking such a high level risk assaulting them. Even Kenney would note “we had already outrun the capabilities of our supply system.” Ignoring the limitations, MacArthur was determined to take the islands, but would later reminisce “I felt that the situation presented an ideal opportunity for a coup de main which, if successful, could advance the Allied timetable in the Pacific by several months and save thousands of Allied lives.” This of course is MacArthur we are talking about and the capture of the Admiralty Islands would advance his timetable to retake the Philippines, so for him it was a no brainer. There was also the on going race. MacArthur was obviously taking notice of Admiral Nimitz's thrust into the Central Pacific, and what a thrust it was. The Gilberts and Marshalls were falling in extremely surprising speed. MacArthur, fully aware of the risks of forwarding Operation Brewer, nevertheless did so and would cover his tracks by describing the invasion as “a reconnaissance in force” The misgivings of this decision would be apparent when a covert reconnaissance mission led by Lt J.R McGowan and 5 other men of the 158th infantry reported on February 27th that the island were “lousy with Japs”, but by that point it was too late to pull back. For the operation, Krueger would assign Major-General Innis Swift's 1st Cavalry Division, which was training intensively in the Oro Bay area. Although the 1st Cavalry Division was dismounted for operations in the Pacific, it retained its organization as a cavalry unit with two brigades, each made up of two reinforced regiments. In addition to supporting units, each regiment comprised two squadrons of three rille troops and a heavy weapons troop. Air offensives against Rabaul and Wewak continued throughout February, seeing an enormous reduction in the Japanese ability for air action. On the 22nd and 23rd, Captain Burke's Destroyer Squadron 23, consisting of Destroyers Charles Ausburne, Stanly, Converse, Spence and Dyson made a daring sweep in the Admiralty island area. They managed to sink the 3800 ton Japanese tug Nagaura due east of Lorengau. 3 of his destroyers then sailed south of New Hanover where they sank a IJN minelayer and a cargo ship before turning around the coast of New Ireland. They encountered no shipping there, so they fired 1500 five-inch shells into Duke of York Island in order to damage the airfield under construction. Meanwhile the other 2 destroyers sailed north of New Hanover and bombarded the enemy base at Kavieng. At this point MacArthur realized the Japanese could not mount any significant air or naval support to defend the admiralties. He also believed Los Negros islands was lightly held and that they was a “coup de main” opportunity. As someone who speaks french as a second language, I gotta say its so weird how we anglophones use these random french phrases for things haha. Thus MacArthur decided to change his plans somewhat. In place of the scheduled assault set for April 1st, he now was tossing the “reconnaissance in force” I mentioned early against the Momote airstrip on Hyane Harbor and that it should be carried out no later than February 29th. The force performing this was to be known as the Brewer Reconnaissance Force; it consisted of 3 rifle troops and the heavy weapons troop of the 2nd Squadron, 5th Cavalry Regiment: 800 men with their complement of light and heavy machine guns, rocket launchers, and mortars. With them was a platoon from Battery B, 99th Field Artillery Battalion, carrying two 75-mm pack howitzers, four 50-caliber machine guns, and small arms. The 673rd Antiaircraft Machine Gun Battery, a unit of some 80 men, was equipped with twelve 50-caliber machine guns as well as individual weapons. Air and naval liaison officers and a shore fire control party were scheduled to land with the attacking force; Headquarters Troop, 1st Cavalry Brigade, would furnish a reconnaissance and a communications platoon. Arrangements had also been made for a detachment from the Australian New Guinea Administration Unit, usually called ANGAU; this group was to assist chiefly in gathering intelligence, patrolling, recruiting, and dealing with the native population as their villages were liberated.  If these men found Momote to be adequately defended, then they would establish a perimeter and await reinforcements, thus the reconnaissance turns into an invasion.With just 5 days to plan, General Kenney's 5th air force was given the task of bombing the objective area and northern Ireland. Meanwhile Admiral Barbey's destroyers were going to perform a heavy bombardment to cover the approach and landings. A patrol from the Alamo Scouts landed on the southeastern coast of Los Negros from a Catalina flying boat on the night of February 27th. They performed a reconnaissance, quickly discovering Colonel Ezaki Yoshio's forces were present. Yoshio's HQ was at Papitalai, the bulk of troops at Lorengau with garrison units were on Rambutyo, Peli, Pak, and Pityilu Islands and at the inland village of Kawaliap. One battalion was also at Papitalai covering HQ. The 2nd Battalion, 1st Independent Mixed Regiment at Salami and 1st Battalion, 229th Regiment at Hyane Harbor with its main elements south of Momote. It was obvious the enemy was still present in force. The Scouts discovered a large bivouac area on the southeast part of Los Negros and reported that the region between the Momote air strip and the south coast was as I mentioned earlier "lousy with Japs." This further allowed Admiral Barbey to make more specific bombardment plans. Three fire support areas had been established for the attack group, consisting of nine destroyers and the three destroyer-transports which were carrying the reconnaissance force. These areas covered the entire seaward side of Los Negros from the south coast to the northern end of Salami Plantation. In the final plans the attack group would bring the weight of its firepower against targets around Hyane Harbor and to the north. Additional fire to cover the southern part of the island would be furnished by another task group of two cruisers and four destroyers, which would meet the convoy at Cape Cretin. It was decided to split this latter group, giving one cruiser and two destroyers responsibility for the Japanese bivouac area, southwest of the Momote strip, which the Alamo Scouts had located. The other cruiser and two destroyers would fire on targets in the Lorengau-Seeadler Harbor region. In the 15-minute bombardment, scheduled from H-35 to H-20, 5-inch naval guns were each to expend approximately 350 rounds. Under the air force plan, two groups of heavy bombers would attack ground targets on Los Negros from H-28 to H-20. Two minutes later, four groups of medium bombers were to bomb and strafe the landing area until the first wave was ashore. Following H Hour a squadron of medium bombers and six smoke planes were to be on air alert for further missions.  The Japanese did not anticipate a landing would be made at Momote, thus only a few elements of the 1st battalion, 229th regiment were there while the bulk of their forces were concentrated at the beaches of Seeadler Harbor and on the other side of the island. Now despite the Alamo scouts best efforts, there was quite a lot of unknown variables. In light of that the landings would be done simplistically. 3 waves of 12 LCPRS would carry the troops to White Beach, lying near Jamandilai Point. From there the reconnaissance force led by Brigadier-General William Chase would advance and hold Momote airstrip. If this proved too difficult, the men would be loaded back up and return to Oro Bay. Now in the event of a successful landing, the remainder of the 5th cavalry regiment would come over 2 days later and the rest of the cavalry division, the main body of the Brewer force, would follow the reconnaissance and support forces as soon as shipping could be made available. On February 27, the 2nd Squadron, 5th Cavalry led by Lt. Colonel William E. Lobit loaded up at Oro Bay, and the following morning departed aboard 3 APDs and nine destroyers under the command of Rear-Admiral William Fechteler. They would rendezvous with Admiral Kinkaid's light cruisers at 13:26, around Cape Cretin, with General MacArthur onboard, and finally would arrive at a point about 10 miles south of Los Negros at 6:00 on February 29. While the troops climbed aboard their LCPRs, Fechteler's destroyers opened fire on their assigned targets. Unfortunately, when the LCPRs reached the line of departure, about 3700 yards from the beaches, the defenders responded with heavy machine-gun and battery fire.At H-28 minutes enemy machine-gun fire opened on the boats, whom began maneuvering radically as they could. Machine-gun fire was also directed against the destroyers and the Phoenix group to the south. Heavier shore batteries opened up; flashes could be seen from d gun near Southeast Point on the island, and what appeared to be 3- or 4-inch shells landed in the vicinity of the Flusser and the Mahan. In response the Phoenix and Mahan fired upon the batteries and 9 B-25's strafed and bombed the area. Their participation was limited by a heavy overcast and a low ceiling. Of the 40 B-24s scheduled to arrive during the naval bombardment, only 3 appeared before their appointed time to bomb the target area at H-47 minutes. The planned missions of four groups of B-25s fared little better, only nine appearing and these later than scheduled. No communications had been established with the B-25s nor could any of the planes be seen from the flagship, so the plan was called off for stopping naval gunfire at H-20 minutes to permit low-level bombing and strafing. The naval bombardment was continued for another 15 minutes. The order to cease fire was given at H-5 minutes and, although no aircraft were visible, starshells were fired as the attack signal for any strafers that might be in the vicinity. The first wave of LCPRs reached the shore at 8:17, meeting slight enemy fire. Troop G led by 1st-Lieutenant Marvin Henshaw rushed beyond the narrow beach to the edge of a coconut plantation, taking cover under fallen trees and kunai grass. Here they laid prone, forming a rough half-circle with a 50-yard radius. They saw scattered groups of the enemy fleeing inland, some as far away as the other side of the air strip. Lieutenant Henshaw killed one with a long distance shot, and members of his platoon killed another. Not one of the soldiers who landed in the first wave was a casualty. As the bombardment lifted, the defenders gradually came out of their dugouts and began subjecting the returning boats to cross-fire. As the second wave approached, the enemy fire became so heavy, the LCPR's were forced to turn back so the Mahan, Flusser and Drayton could further bombard them. At 08:23, the second wave finally landed, moving swiftly past the troops of the first wave to a point 100 yards inland. 22 minutes later, the third wave landed, rapidly fanning south and establishing a line 300 yards inland by 09:00. Meeting slight opposition, the cavalrymen managed to secure the Momote airstrip by 9:50 and completely unloaded by 12:50. 4 of the LCPRs had been left out of action during the landings, so the reconnaissance force could not be evacuated. From the positions held by the first waves, the troops then gradually moved forward to cover the whole dispersal area of the airdrome, sending patrols beyond the airdrome which identified evidence of concerning recent Japanese activity. As patrols sent out beyond the airdrome began to report back, the commanders could decide the next move. One patrol had scouted 1,000 yards west to Porlaka without contact, and another almost as far north as the skidway before meeting any enemy, there was plenty of evidence that the Japanese had recently been in the vicinity in some strength. One patrol that went about a mile south found the hastily vacated quarters of a high-ranking officer, as well as a bivouac area, and fired at a fleeing Japanese officer. Another found three big kitchens and a warehouse of food. Although the Japanese in the area had offered negligible resistance, our command expected a change in the near future. Captured documents revealed that 200 antiaircraft personnel had been encamped nearby.  Given this information, General Chase decided to pull back to a perimeter due east of the airstrip and had the cavalrymen dig in for the night. During the afternoon the reconnaissance force organized its defenses, which presented many difficulties. A good foxhole required back-breaking efforts, because the soil was heavy with coral. Since there was no barbed wire to put around the beachhead, men and weapons had to be spaced closely and every man available used for the perimeter defense. The 40 field artillery officers and men were assigned sectors for close-in defense, because their two pack howitzers could not cover the critical space in front of the defense line from such a shallow depth as the perimeter allowed. They took over these sectors after the howitzers had blasted away for a while at the Japanese known to be in the skidway area. For heavy weapons support, the twelve 50-caliber machine guns of the antiaircraft unit were moved into positions along the front line. Signalmen strung the perimeter with wire to make the necessary hook-ups for officers in the chain of command, and removed the radio sets for communication with Sixth Army Headquarters from an advanced position to a more sheltered bomb crater. Outposts were stationed beyond the strip on the far edges of the dispersal area. Meanwhile, MacArthur came ashore during the afternoon and decorated the first man to land, Lieutenant Henshaw, with a Distinguished Service Cross. He decided to stay, ordering Chase to hold his position until the follow-up force arrived. MacArthur then returned to the Phoenix, which got underway shortly afterwards at 5:29 for Cape Sudest, taking with it all the ships except two destroyers.  On the Japanese side, Colonel Ezaki immediately ordered the 1st Battalion, 229th Regiment to attack the beachhead during the night and annihilate the enemy or die trying. Suspicions that the Momote landing was a diversion, however, would prevent him from sending the rest of his troops to assist. Colonel Ezaki issued the following orders to the infantry battalion defending the Hyane Harbor sector: “Tonight the battalion under Captain Baba will annihilate the enemy who have landed. This is not a delaying action. Be resolute to sacrifice your life for the Emperor and commit suicide in case capture is imminent. We must carry out our mission with the present strength and annihilate the enemy on the spot. I am highly indignant about the enemy's arrogant attitude. Remember to kill or capture all ranking enemy officers for our intelligence purposes…” As ordered, 200 men with 3 mortars; 2 platoons of the 229th Infantry and 1 platoon of crept up to the Americans during the night. Yet by the time they reached the American line, their movement was no longer coordinated and they could only achieve some minor infiltrations. Groups of 7 to 15 Japanese edging in, flinging grenades at the weapons that fired. The only way the Japanese could be seen was by the light of grenade explosions or when the attackers got close enough so that a cavalryman crouched in a fox hole could see them silhouetted against the sky. Many of the Japanese were cut down by machine-gun and rifle fire, but some got through and succeeded in cutting all telephone lines. Although infiltrations occurred on all edges of the perimeter, the attack was heaviest near the shore on the southern side. Here some Japanese reached the shore in the rear of the main defense line by swimming in from the sea with life preservers. The vegetation bordering the beach provided protection for these infiltrators. One group found an opening in the left flank of Troop E, holding the south sector, next to the field artillery unit that held along the shore. The enemy penetrated Troop E's defense line, entirely isolating the 3d Platoon. Without communication with its troop, the unit had to fight it out alone against very heavy attacks. Come daylight, the majority of the Japanese survivors had disappeared back into the jungle, leaving 66 dead against 7 Americans killed and 15 wounded. However, those who had infiltrated and reoccupied some of their former pillboxes and fortifications in the perimeter had to be cleared out by the tired cavalrymen.  During the afternoon, patrols were also sent west and north to check how much strength the enemy had and the perimeter was further contracted and tightened. At 5:00, 2 companies of the 229th regiment made another coordinated effort against the perimeter, yet its intensity was lowered by the death of the battalion commander. The afternoon was free from enemy activity except for a patrol which was discovered inside the perimeter at about 4:00. The patrol's mission was evidently to kill or capture the American commanding officer. It was led by Captain Baba, the commander of the battalion who made the major attack on the preceding night. Although operating in broad daylight, the patrol came close to succeeding. The Americans were confident that the morning's mop-up had taken care of all the enemy within the perimeter. Secondary growth was thick in the area and the Japanese were unnoticed until they were within 35 yards of the task force command post. Once the group was sighted, a considerable amount of fire was placed on it. The Japanese lay concealed in the undergrowth and a single sniper pecked away with his rifle in the direction of the CP. Not knowing the size of the party, Major Chiaramonte set out with four men "to get the sniper." The task force commander and his executive officer directed the movement of the group either right or left according to movements in the underbrush, and the soldiers and Major Chiaramonte opened up whenever they detected any movements. As Major Chiaramonte and his party finally entered the area on which they had been firing, they heard a click followed by grenade explosions. Three of the Japanese had committed suicide. Another rolled over on his back and used his sword to commit hara-kiri. Fifteen dead officers and sergeants were counted, including Captain Baba. Thus, the attackers were kept beyond the perimeter until nightfall, when the attack finally stopped.  On March 2, after clearing Jamandilai Point by 10:45, 6 LSTs landed the 1st Squadron, 5th Cavalry plus artillery and Seabees. While the troops landed, Captain Emile Dechaineux's and will be honest very curious how Americans would pronounce that one, like i've said before there is no rhyme or reason as to how Americans pronounce french last names haha, well Dechaineux's destroyers bombarded Hauwei Island and Hyane Harbor. With reinforcements in hand, General Chase launched a new attack to extend his perimeter. At 2:15 B-25's, P- 38's, and P-47's bombed and strafed the area. The western half of the airfield and the dispersal area were softened up for the ground attack, and the skidway and Hyane coast beyond were also targets. Bombs were also dropped on the strip of land forming the northern arm of the harbor. After this at 3:00 the two cavalry squadrons advanced across the airstrip, rapidly taking the entire aerodrome against light opposition and finally digging along a new perimeter.  To block possible enemy landings from across Hyane Harbor, two anti-aircraft batteries and E Company of the 592nd Boat and Shore Regiment defended the shore. Seabees formed an inner defense line to the west and northwest of the brigade. Six rough trenches were dug out by a bulldozer and ten men stationed in each. The remainder of the 40th Construction Battalion elements remained in their trench on the right flank, which was now a secondary line behind the troopers. The critical north and northwest sectors were the 2nd Squadron's responsibility. They prepared their positions with careful attention to interlocking bands of machine-gun fire, while the 1st Squadron dug in on the left flank. The first night in the enlarged beachhead passed by without a crisis. An attack came at 9:00pm, but it was not as severe as expected. The chief enemy effort was to push machine-gun parties and infiltration groups through the 2nd Squadron's sector, and in particular through that held by Troop G. Communication lines were cut, radio equipment was slightly damaged, and a few Japanese penetrated as far as the field artillery positions. The artillery, prepared for interdiction fire, was not called on.  The following morning, a systematic search for enemy troops within the position was started and all Japanese within the perimeter were killed while the Seabees began work on the airstrip. At the same time, Krueger arranged with Barbey to expedite the movement of the rest of the cavalry division. The 2nd Squadron, 7th Cavalry Regiment was to arrive on March 4; the remaining units of the 1st Brigade would arrive by March 6; and the 2nd Brigade was to arrive on March 9. At this point Colonel Ezaki realized his situation was desperate, his 1st battalion, 229th regiment was being obliterated. He moved his HQ from Papitalai to Papitalai Mission and began concentrating his garrison units at Lorengau. He also ordered the 2nd battalion ,1st independent regiment at Salami to perform an assault from the north, coordinating with the 229th regiment. Their advance was slowed by constant naval and land artillery fire, but they got into position by the night of March 3rd. The Americans expected the attack, as prior, an enemy officer patrol had attempted to land on the shore of Hyane Harbor. The platoon leader of the shore company guarding the beach there allowed the boat to come in to land, then opened fire, killing all members of the patrol. Among the valuable documents discovered on the bodies was one which gave the information that a strong attack would be launched that night.  With this knowledge, the Americans fortified their front line defenses. Since infiltration was still the greatest danger for a small force holding a large perimeter in jungle and darkness, the front line positions were of prime importance. To offer as little space as possible for infiltration, each troop in the line would use all three of its rifle platoons. Automatic weapons covering front-line positions were basic in the fire plans; each of these weapons, in turn, was protected by two, three, or four dugouts on both flanks and rear manned by two or three riflemen. The approaches to these positions were strewn with mines, and trip signals were made of empty "C"-ration cans with lumps of coral inside for clappers, and hung on lengths of wire strung taut ten inches off the ground. In organizing defenses, good use was made of Japanese revetments, built to protect their airplanes in the dispersal bays on the airstrip. These revetments were steep banks of earth reaching some 15 feet high; usually a large one was at the end of a bay with two smaller embankments flanking it to form a pattern which, from the air, looked like cleats on the sole of a football shoe. Near the crest of some of these mounds, on the reverse slopes, cavalrymen dug foxholes. Two 30-caliber water-cooled machine guns were then placed on the flat ground alongside the bunker and mounted to fire across the front of the position.  All the 81-mm mortars were massed near the center of the perimeter, while all the 60-mm mortars were moved close to the front line. The water-cooled 50-caliber machine guns of the antiaircraft were returned to their units, except for those on the northern end of the air strip. This side of the perimeter faced the skidway, whence the chief attack was expected. Patrols had met the greatest opposition when working in this direction and toward Porlaka; enemy barges and troop concentrations had also been sighted on the northwestern shore of Hyane Harbor.  Nearby naval units would also coordinate by firing upon any Japanese concentration discovered. At 9pm the Japanese began their attack as a single Japanese bomber dropped 8 bombs.  As soon as the plane had departed, two yellow flares went up from the vicinity of Podaka, and a tracer, apparently 20-mm, was fired almost vertically from a position in front of the Troop B sector to the southwest. Almost immediately an attack supported by mortar fire was launched there as well as against the position held by Troops F and G to the northwest. The attack against the 1st Squadron on the southwest was relatively light, the enemy strength here being estimated later at two reinforced platoons. Since the 1st Squadron's sector was covered by a heavy growth of secondary jungle forest, infiltration was a great danger. The sited positions of our automatic weapons were of little value in the darkness, so the cavalrymen picked up the guns and fired them from the hip. The Japanese moved automatic weapons forward apparently with no other plan of action than to set them up in the open in front of our lines, depending on darkness to conceal their positions. The excited talking of the crews gave their positions away and they became easy targets for the defending riflemen. The attackers were blanketed by mortar fire accurately placed 20 to 50 yards in front of the perimeter. Nevertheless, many of the enemy did infiltrate, some as far as the south end of the air strip where they hid in heavy brush or climbed trees to begin sniper operations at dawn. Because of the relative weakness of the attacking force, there was never any real danger that the 1st Squadron's positions would be overrun.   The attack upon the 2nd Squadron's position on the northwest was a greater threat, with over a battalion, as later estimated, advancing on this sector from the direction of Pori aka and the skidway against the whole of Troop G's position and the right flank of Troop F. Apparently the enemy's intention was to drive our troops from their perimeter and occupy the north end of the air strip. The attacks against the sector held by Troops E and F were limited to infiltrations toward mortar positions and command posts. The rear installations were covered hy enemy mortar fire and machinegun fire while Japanese with grenades closed in on them and overran the positions. The Seabees, holding their secondary defense line behind the cavalry on the north side of the perimeter, also felt the effects of the furious attacks. Cavalrymen whose guns were knocked out, or who had run out of ammunition, carne back to the Seabees' trenches. When a weak place developed toward the left side of the Seabees' positions, their extra ammunition was at the other end of their line. First the men passed the ammunition to the front line by throwing the boxes from hole to hole, but when that seemed too slow they got out of their holes and ran with it, holding it low.  The Japanese advanced relentlessly, talking and singing though damaged and hampered by antipersonnel mines and booby traps, until they were cut down by the fierce machine-gun fire of the cavalrymen. Yet more and more kept coming behind them, marching over the bodies of the first. The Americans hunkered down in their holes and fired upon anything that moved,  continuing to inflict heavy casualties. The Japanese attempted a number of tricks and were occasionally successful. Somehow they learnt the names of platoon leaders. On one occasion a Japanese yelled, "Retreat, Thorne, the whole regiment's falling back to another line." This caused the mortar platoon commanded by 1st Lt. William D. Thorne to leave their positions. Not only did the platoon suffer three casualties, but it was unable to direct its mortar fire during the rest of the night. Another trick was to have individuals move about in front of the perimeter to draw the fire of machine guns. Then two or three snipers would fire tracers at any weapon that disclosed itself, enabling a mortar to open up on the position. Several cases of wiretapping of a 90-mm anti-aircraft battery took place between 10:30 and midnight, the wire-tapper claiming to be, on one occasion, a certain officer commanding a platoon, and on another, a sergeant. He reported in each case the disruption of our plans and the success of the enemy. Since his voice was not recognized, his messages were not heeded. However, a later message, although believed false, made the 211th Coast Artillery (AA) Battalion change its CP. At 11:30 a single enemy plane with landing lights on made several runs at a low altitude dropping flares. In spite of orders to hold their fire, the anti-aircraft battery opened up on the fourth run and drove the plane to the north, where it dropped bombs on Japanese positions.  Japanese using knives and grenades managed to get themselves into Troop G's defenses. A ferocious counterattack by the cavalrymen would shortly regain the positions just in time to face another strong frontal attack, in which more Japanese were cut down in front of the 2nd Squadron. By daylight, the infantry attacks were finally over, with the cavalrymen counting over 750 Japanese dead as they established a new outpost line on March 4. Against them, the Americans lost 61 killed and 244 wounded, 9 of the dead and 38 of the wounded were Seabees. That same day was met with another heavy bombardment of the Japanese positions, then the 2nd Squadron, 7th Cavalry landed against slight enemy resistance. The defensive perimeter was strengthened again and the damage of the previous night was repaired. Colonel Ezaki now believed that his troops had successfully pierced the American first line of defense and thus ordered to continue the attack that night; but upon learning the truth and how many casualties he had suffered, he decided to cancel the attack and ordered a general withdrawal towards Lorengau, leaving some units to hold Papitalai and delay the American advance. 600  men had been lost in the skidway area and in the attacks upon the perimeter. The remaining 200, with an additional 100 stragglers from other disorganized units, were ordered to retreat through Salami Beach and across Papitalai Harbor to Papitalai Mission. Natives on Mokerang Peninsula later told the Angau Party that the Japanese retreat developed into a rout. They were panic-stricken; some did not even wait to take paddles for the native canoes that they had appropriated for their escape to Papitalai Mission. Not more than 80 Japanese, frantic from fear and exhaustion, arrived at the mission to bolster the force already there. By the 5th, General Swift arrived to the secured  beachhead in the Admiralties, and with the arrival of the 12th Cavalry Regiment the following day, he was now ready to launch an offensive west towards Seeadler Harbor, the Lorengau airdrome and north against Salami Plantation. The same day, to clear the way for the 2nd Brigade's landing at Red Beach, General Swift ordered the 2nd Squadron, 7th Cavalry to move across the skidway to a point about 500 yards north. Despite a thorough artillery support, the advance did not go smoothly, with the Japanese immediately launching a strong attack from both Porlaka and the native skidway. Luckily the few Japanese who penetrated the position were killed, around 25 of them and the attack was broken up by mortar and artillery fire. At 4:30, the squadron finally began their offensive, moving with difficulty across a mined area and only gaining about 500 yards by nightfall.  The next morning, the squadron advanced, with the 12th Cavalry soon joining them. Despite the occasional pillboxes and the congested trail, the cavalrymen made ample progress towards the beaches of Seeadler Harbor and closed in on Salami by 4:30. To further secure the harbor, General Swift planned to clear the enemy presence at the Mokerang Peninsula, Papitalai Mission and Lombrum Point. That day, the 5th Cavalry had already begun the work of clearing the southern shore of Seeadler Harbor by pushing patrols west from the airstrip. Finding much more enemy corpses that opposition, Troop F would be able to establish a bridgehead at Porlaka. At 12:00 on the 7th, after an artillery bombardment, a reconnaissance patrol consisting of 40 volunteers from Troop B, led by Capt. William C. Cornelius advanced across Lemondrol Creek and successfully landed on Papitalai against an estimated 50 Japanese defenders. Captain Cornelius, leading the first wave, was reported to have single-handedly killed four of the enemy with rifle fire and grenades while operating 50 yards in advance of the troops. Yet severely wounded, he would die the next day; for his courage and leadership he was awarded the Distinguished Service Cross.  The Japanese quickly withdrew. Simultaneously after a heavy air and artillery bombardment, the 2nd Squadron, 12th Cavalry departed Salami and advanced across Seeadler Harbor to land on Papitalai Mission, meeting heavy resistance.  By nightfall, Troop G had secured a beachhead, though it would have to break up three determined counterattacks during the night. This ultimately forced the Japanese to pull out from their beach defenses at Papitalai Mission and retreat towards Lorengau, allowing the cavalrymen to secure the beachhead the following morning. By 12:00 on the 8th, supplies for the 2nd Squadron, 7th Cavalry's attack on Lombrum Plantation also began arriving at Red Beach over the difficult road from Momote. Equipping the 12th Cavalry and the 2nd Squadron, 7th Cavalry, at Salami with enough supplies to carry on their overwater attacks was a difficult and hazardous operation. The single road from Momote to Salami was impassable for most vehicles during the days when the supplies were most urgently needed. Buffaloes got through by going overwater part of the way, but the rest of the essential supplies had to be dropped from airplanes or sent in LCMs from Momote around Mokerang Peninsula. The sending of LCMs into Seeadler Harbor was an operation which was possible only after continued naval efforts from D-Day on. Magnetic mines, dropped by American planes in May 1943, were presumably still in the harbor and had to be removed. To make entry into the harbor safe for their forces, destroyers also had to neutralize the Japanese harbor defense guns, which had already proved effective. The destroyers and minesweepers worked to accomplish these missions, but even by 7 March, when six LCMs loaded with supplies were to make their way around the point, it was not certain that enemy resistance on the islands guarding the harbor had completely disintegrated.  LCMs then successfully landed TROOP E, F and G on Lombrum two hours later against sporadic fire. The Americans extended their perimeter by 5:00, successfully completing the task of securing Seeadler Harbor while other units of the 12th Cavalry secured the Mokerang Peninsula to cover the north flank of the 2nd Brigade's landing. On the 9th, the 2nd Brigade successfully landed at Salami while destroyers pounded the main Japanese positions at Lorengau. This ended the first phase of Operation Brewer. The Americans had suffered a total of 116 killed and 434 wounded during their occupation of Los Negros while counting 1288 enemy dead by March 8. Their next objective would be Lorengau airdrome on Manus Island, but that it for the Admiralties as we now need to travel over to New Britain. Over on New Britain, General Rupertus was planning to invade the Willaumez Peninsula in order to cut off the Japanese retreat line there and take the Talasea airdrome. He assigned the 5th marines under Colonel Oliver Smith for the task. They were going land at a point about midway on the west coast of the Willaumez Peninsula north of Volupai, labeled Beach Red. The chosen zone of operations was about as good as the Marines could have found. It presented them with a short, comparatively flat route to their objective which might make possible utilization of tanks. A dirt track approximately four miles long connected Beach Red with Bitokara, and although it was not designed for motor transport, the Marines could hope. Beach Red contained about as much depth as Beaches Yellow 1 and Yellow 2 in the Gloucester landings, but was more confined on its flanks. Its 350 yards of sand nestled between a cliff on the right and a swamp on the left. The cliff constituted the northwestern slope of Little Mt. Worri, a mass rising 1360 feet above the beach and enfolding the native villages of Liapo to the south and Volupai on the west. Overlooking this smaller mountain from the south was Big Mt. Worri, higher by 300 feet and with a more encompassing base. Included in its ridge line was Mt. Schleuther, on the peninsula's eastern coast which dominated Bitokara, Talasea and the Waru villages from an altitude of 1130 feet. Volupai Plantation was 400 yards inland from Beach Red, containing a collection of small buildings and groves of coconut palms and cacao trees. Volupai track, linking Beach Red with Bitokara, skirted the northern bases of the several mountains. The country, except for the plantations and villages, was typical of New Britain: overgrown jungle and underbrush. Sea and air control in the New Britain area had passed so completely into Allied hands that it was decided to transport the assault forces from Iboki to Volupai in a convoy of 38 LCMs, 17 LCVPs and 5 LCTs, with only 5 PT boats as escorts. Furthermore, on March 3rd, an amphibious patrol landed on Cape Bastian and managed to contact friendly natives in order to learn that the enemy had a weak presence in the area. This was the reinforced 7th Company, 54th Regiment, which had been sent by General Sakai to defend Talasea while the bulk of the Matsuda and Komori Detachments retreated towards Malalia. Sakai was planning to engage the enemy in a decisive battle with the entire force of the 17th Division; but on February 23, General Imamura had ordered him to withdraw towards Rabaul. Thus Sakai assigned the 17th Provisional Battalion to secure Toriu; the 2nd Battalion, 53rd Regiment to hold Ulamona; the 39th Anti-Aircraft Battalion to remain at Malalia; the 17th Engineer Regiment to facilitate the crossing of the Kapuira River; and the 17th Transport Regiment to establish supply depots at Ubai, Butiolo and Sulu. He also ordered the bulk of the 54th Regiment to leave some naval units at Gasmata and begin to retreat towards Amio and then Ubai, where barges were to finally evacuate the detachment. Over in Bougainville, General Griswold's 14th Corps had just taken over the protection of the Cape Torokina base. As such, nearly 62000 men were stationed in the area, defenses were consolidated, and an impressive artillery complement under Brigadier-General Leo Kreber was directed to cover the perimeter. During this period of consolidation, the most important actions were the establishment of an important Fijian outpost at Ibu village. One of the most effective units operating under corps command was the 1st Battalion of the Fiji Infantry Regiment. This battalion, consisting of 777 enlisted men and 34 officers, commanded by Lieutenant Colonel J.B.K. Taylor of the New Zealand Army, whom arrived at Bougainville in late December. Taylor was wounded the first night ashore and was replaced as commander by Major Gregory Upton, who was in charge of the battalion during its long-range patrols in late December and January. The Fijian troops were well trained, proud of their uniforms and ability to march, and according to reports, loved to sing a wide variety of Fijian songs as well as the more modern American tunes. Almost immediately after their arrival, plans were under way to use their unique abilities as jungle fighters to establish a combat outpost far to the east of the mountain range, most of which was controlled by the Japanese. The managed to gain valuable information on Japanese movements before withdrawing in late February, and a successful expansion of the perimeter east of the mouth of the Torokina River. But the first real test of the Corps in Bougainville was approaching.  Under immense pressure from his superiors, General Hyakutake had been preparing to launch his main counterattack, codenamed Operation TA, since early January. He assembled over 15000 men from his total strength of nearly 40000 to take part in the operation. General Kanda the 6th Division commander was given command of the force and his mission was simple. 3 task forces, named after their commanders; the Iwasa unit of Major General Iwasa Shun consisting of the 23rd Infantry Regiment, the 2nd Battalion of the 13th Regiment, attached engineering troops, and two batteries of light field artillery and a mortar battalion–in all, approximately 4,150 men; the Magata Unit, commanded by Colonel Magata Isashi, consisting of most of the 45th Infantry Regiment (less 2nd Battalion), with artillery, mortar battalions, and engineers attached–a total of approximately 4,300 men; The smallest of the forces, the Muda Unit, commanded by Colonel Muda Toyohorei , consisted of the 1st and 3rd Battalions of the 13th Regiment and an engineering company–a total of 1,350 men.  These 3 units would  attack strongpoints in the American perimeter. Thus, the Iwasa Unit was to strike towards Hill 700 on the right flank of the 37th Division line and then drive directly toward the two Piva airfields, which Hyakutake planned to capture by March 10; the Magata Unit was to take the low ground west of Hill 700 and then drive south to capture the Torokina airstrip by March 17; and the Muda Unit was to seize Hills 260 and 309 in the Americal sector and then capture the strategically-important Hill 608 by March 10. Bougainville was about to see some major action. I would like to take this time to remind you all that this podcast is only made possible through the efforts of Kings and Generals over at Youtube. Please go subscribe to Kings and Generals over at Youtube and to continue helping us produce this content please check out www.patreon.com/kingsandgenerals. If you are still hungry after that, give my personal channel a look over at The Pacific War Channel at Youtube, it would mean a lot to me. Despite the admiralty islands certainly holding significant enemy units, General MacArthur went ahead with his reconnaissance in force and turned it into a full blown invasion. Yet again MacArthur proved, he was willing to do whatever necessary to make sure the drive of the Pacific pointed in the direction of the Philippines.

PREVIEW: #BAGHDAD: KETAIB-HEZBOLLAH: #DECAPITATION: From a conversation with CBS News colleague re the presumed US drone strike in West Baghdad that killed leaders of the Iran-backed Iraqi militia cling to launch the attacks on the American outposts on the Jordan-Syrian-Iraqi border. More tonight. 1932 Baghdad

Faith Christian Fellowship Sermon

PREVIEW: From a conversation with Josh Rogin of the Washington Post re the strategic mission for Tower 22 snd the network of US outposts in the tri-border region of Jordan, Syria and Iraq -- and why Tahran wants the US to leave the region.  More tonight. 1880 Damascus

Evelyn Osman, Principal Platform Engineer at AutoScout24, joins Corey on Screaming in the Cloud to discuss the dire need for developers to agree on a standardized tool set in order to scale their projects and innovate quickly. Corey and Evelyn pick apart the new products being launched in cloud computing and discover a large disconnect between what the industry needs and what is actually being created. Evelyn shares her thoughts on why viewing platforms as products themselves forces developers to get into the minds of their users and produces a better end result.About EvelynEvelyn is a recovering improviser currently role playing as a Lead Platform Engineer at Autoscout24 in Munich, Germany. While she says she specializes in AWS architecture and integration after spending 11 years with it, in truth she spends her days convincing engineers that a product mindset will make them hate their product managers less.Links Referenced:LinkedIn: https://www.linkedin.com/in/evelyn-osman/TranscriptAnnouncer: Hello, and welcome to Screaming in the Cloud with your host, Chief Cloud Economist at The Duckbill Group, Corey Quinn. This weekly show features conversations with people doing interesting work in the world of cloud, thoughtful commentary on the state of the technical world, and ridiculous titles for which Corey refuses to apologize. This is Screaming in the Cloud.Corey: Welcome to Screaming in the Cloud. I'm Corey Quinn. My guest today is Evelyn Osman, engineering manager at AutoScout24. Evelyn, thank you for joining me.Evelyn: Thank you very much, Corey. It's actually really fun to be on here.Corey: I have to say one of the big reasons that I was enthused to talk to you is that you have been using AWS—to be direct—longer than I have, and that puts you in a somewhat rarefied position where AWS's customer base has absolutely exploded over the past 15 years that it's been around, but at the beginning, it was a very different type of thing. Nowadays, it seems like we've lost some of that magic from the beginning. Where do you land on that whole topic?Evelyn: That's actually a really good point because I always like to say, you know, when I come into a room, you know, I really started doing introductions like, “Oh, you know, hey,” I'm like, you know, “I'm this director, I've done this XYZ,” and I always say, like, “I'm Evelyn, engineering manager, or architect, or however,” and then I say, you know, “I've been working with AWS, you know, 11, 12 years,” or now I can't quite remember.Corey: Time becomes a flat circle. The pandemic didn't help.Evelyn: [laugh] Yeah, I just, like, a look at that the year, and I'm like, “Jesus. It's been that long.” Yeah. And usually, like you know, you get some odd looks like, “Oh, my God, you must be a sage.” And for me, I'm… you see how different services kind of, like, have just been reinventions of another one, or they just take a managed service and make another managed service around it. So, I feel that there's a lot of where it's just, you know, wrapping up a pretty bow, and calling it something different, it feels like.Corey: That's what I've been low-key asking people for a while now over the past year, namely, “What is the most foundational, interesting thing that AWS has done lately, that winds up solving for this problem of whatever it is you do as a company? What is it that has foundationally made things better that AWS has put out in the last service? What was it?” And the answers I get are all depressingly far in the past, I have to say. What's yours?Evelyn: Honestly, I think the biggest game-changer I remember experiencing was at an analyst summit in Stockholm when they announced Lambda.Corey: That was announced before I even got into this space, as an example of how far back things were. And you're right. That was transformative. That was awesome.Evelyn: Yeah, precisely. Because before, you know, we were always, like, trying to figure, okay, how do we, like, launch an instance, run some short code, and then clean it up. AWS is going to charge for an hour, so we need to figure out, you know, how to pack everything into one instance, run for one hour. And then they announced Lambda, and suddenly, like, holy shit, this is actually a game changer. We can actually write small functions that do specific things.And, you know, you go from, like, microservices, like, to like, tiny, serverless functions. So, that was huge. And then DynamoDB along with that, really kind of like, transformed the entire space for us in many ways. So, back when I was at TIBCO, there was a few innovations around that, even, like, one startup inside TIBCO that quite literally, their entire product was just Lambda functions. And one of their problems was, they wanted to sell in the Marketplace, and they couldn't figure out how to sell Lambda on the marketplace.Corey: It's kind of wild when we see just how far it's come, but also how much they've announced that doesn't change that much, to be direct. For me, one of the big changes that I remember that really made things better for customers—thought it took a couple of years—was EFS. And even that's a little bit embarrassing because all that is, “All right, we finally found a way to stuff a NetApp into us-east-1,” so now NFS, just like you used to use it in the 90s and the naughts, can be done responsibly in the cloud. And that, on some level, wasn't a feature launch so much as it was a concession to the ways that companies had built things and weren't likely to change.Evelyn: Honestly, I found the EFS launch to be a bit embarrassing because, like, you know, when you look closer at it, you realize, like, the performance isn't actually that great.Corey: Oh, it was horrible when it launched. It would just slam to a halt because you got the IOPS scaled with how much data you stored on it. The documentation explicitly said to use dd to start loading a bunch of data onto it to increase the performance. It's like, “Look, just sandbag the thing so it does what you'd want.” And all that stuff got fixed, but at the time it looked like it was clown shoes.Evelyn: Yeah, and that reminds me of, like, EBS's, like, gp2 when we're, like you know, we're talking, like, okay, provision IOPS with gp2. We just kept saying, like, just give yourself really big volume for performance. And it feel like they just kind of kept that with EFS. And it took years for them to really iterate off of that. Yeah, so, like, EFS was a huge thing, and I see us, we're still using it now today, and like, we're trying to integrate, especially for, like, data center migrations, but yeah, you always see that a lot of these were first more for, like, you know, data centers to the cloud, you know. So, first I had, like, EC2 classic. That's where I started. And I always like to tell a story that in my team, we're talking about using AWS, I was the only person fiercely against it because we did basically large data processing—sorry, I forget the right words—data analytics. There we go [laugh].Corey: I remember that, too. When it first came out, it was, “This sounds dangerous and scary, and it's going to be a flash in the pan because who would ever trust their core compute infrastructure to some random third-party company, especially a bookstore?” And yeah, I think I got that one very wrong.Evelyn: Yeah, exactly. I was just like, no way. You know, I see all these articles talking about, like, terrible disk performance, and here I am, where it's like, it's my bread and butter. I'm specialized in it, you know? I write code in my sleep and such.[Yeah, the interesting thing is, I was like, first, it was like, I can 00:06:03] launch services, you know, to kind of replicate when you get in a data center to make it feature comparable, and then it was taking all this complex services and wrapping it up in a pretty bow for—as a managed service. Like, EKS, I think, was the biggest one, if we're looking at managed services. Technically Elasticsearch, but I feel like that was the redheaded stepchild for quite some time.Corey: Yeah, there was—Elasticsearch was a weird one, and still is. It's not a pleasant service to run in any meaningful sense. Like, what people actually want as the next enhancement that would excite everyone is, I want a serverless version of this thing where I can just point it at a bunch of data, I hit an API that I don't have to manage, and get Elasticsearch results back from. They finally launched a serverless offering that's anything but. You have to still provision compute units for it, so apparently, the word serverless just means managed service over at AWS-land now. And it just, it ties into the increasing sense of disappointment I've had with almost all of their recent launches versus what I felt they could have been.Evelyn: Yeah, the interesting thing about Elasticsearch is, a couple of years ago, they came out with OpenSearch, a competing Elasticsearch after [unintelligible 00:07:08] kind of gave us the finger and change the licensing. I mean, OpenSearch actually become a really great offering if you run it yourself, but if you use their managed service, it can kind—you lose all the benefits, in a way.Corey: I'm curious, as well, to get your take on what I've been seeing that I think could only be described as an internal shift, where it's almost as if there's been a decree passed down that every service has to run its own P&L or whatnot, and as a result, everything that gets put out seems to be monetized in weird ways, even when I'd argue it shouldn't be. The classic example I like to use for this is AWS Config, where it charges you per evaluation, and that happens whenever a cloud resource changes. What that means is that by using the cloud dynamically—the way that they supposedly want us to do—we wind up paying a fee for that as a result. And it's not like anyone is using that service in isolation; it is definitionally being used as people are using other cloud resources, so why does it cost money? And the answer is because literally everything they put out costs money.Evelyn: Yep, pretty simple. Oftentimes, there's, like, R&D that goes into it, but the charges seem a bit… odd. Like from an S3 lens, was, I mean, that's, like, you know, if you're talking about services, that was actually a really nice one, very nice holistic overview, you know, like, I could drill into a data lake and, like, look into things. But if you actually want to get anything useful, you have to pay for it.Corey: Yeah. Everything seems to, for one reason or another, be stuck in this place where, “Well, if you want to use it, it's going to cost.” And what that means is that it gets harder and harder to do anything that even remotely resembles being able to wind up figuring out where's the spend going, or what's it going to cost me as time goes on? Because it's not just what are the resources I'm spinning up going to cost, what are the second, third, and fourth-order effects of that? And the honest answer is, well, nobody knows. You're going to have to basically run an experiment and find out.Evelyn: Yeah. No, true. So, what I… at AutoScout, we actually ended up doing is—because we're trying to figure out how to tackle these costs—is they—we built an in-house cost allocation solution so we could track all of that. Now, AWS has actually improved Cost Explorer quite a bit, and even, I think, Billing Conductor was one that came out [unintelligible 00:09:21], kind of like, do a custom tiered and account pricing model where you can kind of do the same thing. But even that also, there is a cost with it.I think that was trying to compete with other, you know, vendors doing similar solutions. But it still isn't something where we see that either there's, like, arbitrarily low pricing there, or the costs itself doesn't really quite make sense. Like, AWS [unintelligible 00:09:45], as you mentioned, it's a terrific service. You know, we try to use it for compliance enforcement and other things, catching bad behavior, but then as soon as people see the price tag, we just run away from it. So, a lot of the security services themselves, actually, the costs, kind of like, goes—skyrockets tremendously when you start trying to use it across a large organization. And oftentimes, the organization isn't actually that large.Corey: Yeah, it gets to this point where, especially in small environments, you have to spend more energy and money chasing down what the cost is than you're actually spending on the thing. There were blog posts early on that, “Oh, here's how you analyze your bill with Redshift,” and that was a minimum 750 bucks a month. It's, well, I'm guessing that that's not really for my $50 a month account.Evelyn: Yeah. No, precisely. I remember seeing that, like, entire ETL process is just, you know, analyze your invoice. Cost [unintelligible 00:10:33], you know, is fantastic, but at the end of the day, like, what you're actually looking at [laugh], is infinitesimally small compared to all the data in that report. Like, I think oftentimes, it's simply, you know, like, I just want to look at my resources and allocate them in a multidimensional way. Which actually isn't really that multidimensional, when you think about it [laugh].Corey: Increasingly, Cost Explorer has gotten better. It's not a new service, but every iteration seems to improve it to a point now where I'm talking to folks, and they're having a hard time justifying most of the tools in the cost optimization space, just because, okay, they want a percentage of my spend on AWS to basically be a slightly better version of a thing that's already improving and works for free. That doesn't necessarily make sense. And I feel like that's what you get trapped into when you start going down the VC path in the cost optimization space. You've got to wind up having a revenue model and an offering that scales through software… and I thought, originally, I was going to be doing something like that. At this point, I'm unconvinced that anything like that is really tenable.Evelyn: Yeah. When you're a small organization you're trying to optimize, you might not have the expertise and the knowledge to do so, so when one of these small consultancies comes along, saying, “Hey, we're going to charge you a really small percentage of your invoice,” like, okay, great. That's, like, you know, like, a few $100 a month to make sure I'm fully optimized, and I'm saving, you know, far more than that. But as soon as your invoice turns into, you know, it's like $100,000, or $300,000 or more, that percentage becomes rather significant. And I've had vendors come to me and, like, talk to me and is like, “Hey, we can, you know, for a small percentage, you know, we're going to do this machine learning, you know, AI optimization for you. You know, you don't have to do anything. We guaranteed buybacks your RIs.” And as soon as you look at the price tag with it, we just have to walk away. Or oftentimes we look at it, and there are truly very simple ways to do it on your own, if you just kind of put some thought into it.Corey: While we want to talking a bit before this show, you taught me something new about GameLift, which I think is a different problem that AWS has been dealing with lately. I've never paid much attention to it because it is the—as I assume from what it says on the tin, oh, it's a service for just running a whole bunch of games at scale, and I'm not generally doing that. My favorite computer game remains to be Twitter at this point, but that's okay. What is GameLift, though, because you want to shining a different light on it, which makes me annoyed that Amazon Marketing has not pointed this out.Evelyn: Yeah, so I'll preface this by saying, like, I'm not an expert on GameLift. I haven't even spun it up myself because there's quite a bit of price. I learned this fall while chatting with an SA who works in the gaming space, and it kind of like, I went, like, “Back up a second.” If you think about, like, I'm, you know, like, World of Warcraft, all you have are thousands of game clients all over the world, playing the same game, you know, on the same server, in the same instance, and you need to make sure, you know, that when I'm running, and you're running, that we know that we're going to reach the same point the same time, or if there's one object in that room, that only one of us can get it. So, all these servers are doing is tracking state across thousands of clients.And GameLift, when you think about your dedicated game service, it really is just multi-region distributed state management. Like, at the basic, that's really what it is. Now, there's, you know, quite a bit more happening within GameLift, but that's what I was going to explain is, like, it's just state management. And there are far more use cases for it than just for video games.Corey: That's maddening to me because having a global session state store, for lack of a better term, is something that so many customers have built themselves repeatedly. They can build it on top of primitives like DynamoDB global tables, or alternately, you have a dedicated region where that thing has to live and everything far away takes forever to round-trip. If they've solved some of those things, why on earth would they bury it under a gaming-branded service? Like, offer that primitive to the rest of us because that's useful.Evelyn: No, absolutely. And honestly, I wouldn't be surprised if you peeled back the curtain with GameLift, you'll find a lot of—like, several other you know, AWS services that it's just built on top of. I kind of mentioned earlier is, like, what I see now with innovation, it's like we just see other services packaged together and releases a new product.Corey: Yeah, IoT had the same problem going on for years where there was a lot of really good stuff buried in there, like IOT events. People were talking about using that for things like browser extensions and whatnot, but you need to be explicitly told that that's a thing that exists and is handy, but otherwise you'd never know it was there because, “Well, I'm not building anything that's IoT-related. Why would I bother?” It feels like that was one direction that they tended to go in.And now they take existing services that are, mmm, kind of milquetoast, if I'm being honest, and then saying, “Oh, like, we have Comprehend that does, effectively detection of themes, keywords, and whatnot, from text. We're going to wind up re-releasing that as Comprehend Medical.” Same type of thing, but now focused on a particular vertical. Seems to me that instead of being a specific service for that vertical, just improve the baseline the service and offer HIPAA compliance if it didn't exist already, and you're mostly there. But what do I know? I'm not a product manager trying to get promoted.Evelyn: Yeah, that's true. Well, I was going to mention that maybe it's the HIPAA compliance, but actually, a lot of their services already have HIPAA compliance. And I've stared far too long at that compliance section on AWS's site to know this, but you know, a lot of them actually are HIPAA-compliant, they're PCI-compliant, and ISO-compliant, and you know, and everything. So, I'm actually pretty intrigued to know why they [wouldn't 00:16:04] take that advantage.Corey: I just checked. Amazon Comprehend is itself HIPAA-compliant and is qualified and certified to hold Personal Health Information—PHI—Private Health Information, whatever the acronym stands for. Now, what's the difference, then, between that and Medical? In fact, the HIPAA section says for Comprehend Medical, “For guidance, see the previous section on Amazon Comprehend.” So, there's no difference from a regulatory point of view.Evelyn: That's fascinating. I am intrigued because I do know that, like, within AWS, you know, they have different segments, you know? There's, like, Digital Native Business, there's Enterprise, there's Startup. So, I am curious how things look over the engineering side. I'm going to talk to somebody about this now [laugh].Corey: Yeah, it's the—like, I almost wonder, on some level, it feels like, “Well, we wound to building this thing in the hopes that someone would use it for something. And well, if we just use different words, it checks a box in some analyst's chart somewhere.” I don't know. I mean, I hate to sound that negative about it, but it's… increasingly when I talk to customers who are active in these spaces around the industry vertical targeted stuff aimed at their industry, they're like, “Yeah, we took a look at it. It was adorable, but we're not using it that way. We're going to use either the baseline version or we're going to work with someone who actively gets our industry.” And I've heard that repeated about three or four different releases that they've put out across the board of what they've been doing. It feels like it is a misunderstanding between what the world needs and what they're able to or willing to build for us.Evelyn: Not sure. I wouldn't be surprised, if we go far enough, it could probably be that it's just a product manager saying, like, “We have to advertise directly to the industry.” And if you look at it, you know, in the backend, you know, it's an engineer, you know, kicking off a build and just changing the name from Comprehend to Comprehend Medical.Corey: And, on some level, too, they're moving a lot more slowly than they used to. There was a time where they were, in many cases, if not the first mover, the first one to do it well. Take Code Whisperer, their AI powered coding assistant. That would have been a transformative thing if GitHub Copilot hadn't beaten them every punch, come out with new features, and frankly, in head-to-head experiments that I've run, came out way better as a product than what Code Whisperer is. And while I'd like to say that this is great, but it's too little too late. And when I talk to engineers, they're very excited about what Copilot can do, and the only people I see who are even talking about Code Whisperer work at AWS.Evelyn: No, that's true. And so, I think what's happening—and this is my opinion—is that first you had AWS, like, launching a really innovative new services, you know, that kind of like, it's like, “Ah, it's a whole new way of running your workloads in the cloud.” Instead of you know, basically, hiring a whole team, I just click a button, you have your instance, you use it, sell software, blah, blah, blah, blah. And then they went towards serverless, and then IoT, and then it started targeting large data lakes, and then eventually that kind of run backwards towards security, after the umpteenth S3 data leak.Corey: Oh, yeah. And especially now, like, so they had a hit in some corners with SageMaker, so now there are 40 services all starting with the word SageMaker. That's always pleasant.Evelyn: Yeah, precisely. And what I kind of notice is… now they're actually having to run it even further back because they caught all the corporations that could pivot to the cloud, they caught all the startups who started in the cloud, and now they're going for the larger behemoths who have massive data centers, and they don't want to innovate. They just want to reduce this massive sysadmin team. And I always like to use the example of a Bare Metal. When that came out in 2019, everybody—we've all kind of scratched your head. I'm like, really [laugh]?Corey: Yeah, I could see where it makes some sense just for very specific workloads that involve things like specific capabilities of processors that don't work under emulation in some weird way, but it's also such a weird niche that I'm sure it's there for someone. My default assumption, just given the breadth of AWS's customer base, is that whenever I see something that they just announced, well, okay, it's clearly not for me; that doesn't mean it's not meeting the needs of someone who looks nothing like me. But increasingly as I start exploring the industry in these services have time to percolate in the popular imagination and I still don't see anything interesting coming out with it, it really makes you start to wonder.Evelyn: Yeah. But then, like, I think, like, roughly a year or something, right after Bare Metal came out, they announced Outposts. So, then it was like, another way to just stay within your data center and be in the cloud.Corey: Yeah. There's a bunch of different ways they have that, okay, here's ways you can run AWS services on-prem, but still pay us by the hour for the privilege of running things that you have living in your facility. And that doesn't seem like it's quite fair.Evelyn: That's exactly it. So, I feel like now it's sort of in diminishing returns and sort of doing more cloud-native work compared to, you know, these huge opportunities, which is everybody who still has a data center for various reasons, or they're cloud-native, and they grow so big, that they actually start running their own data centers.Corey: I want to call out as well before we wind up being accused of being oblivious, that we're recording this before re:Invent. So, it's entirely possible—I hope this happens—that they announce something or several some things that make this look ridiculous, and we're embarrassed to have had this conversation. And yeah, they're totally getting it now, and they have completely surprised us with stuff that's going to be transformative for almost every customer. I've been expecting and hoping for that for the last three or four re:Invents now, and I haven't gotten it.Evelyn: Yeah, that's right. And I think there's even a new service launches that actually are missing fairly obvious things in a way. Like, mine is the Managed Workflow for Amazon—it's Managed Airflow, sorry. So, we were using Data Pipeline for, you know, big ETL processing, so it was an in-house tool we kind of built at Autoscout, we do platform engineering.And it was deprecated, so we looked at a new—what to replace it with. And so, we looked at Airflow, and we decided this is the way to go, we want to use managed because we don't want to maintain our own infrastructure. And the problem we ran into is that it doesn't have support for shared VPCs. And we actually talked to our account team, and they were confused. Because they said, like, “Well, every new service should support it natively.” But it just didn't have it. And that's, kind of, what, I kind of found is, like, there's—it feels—sometimes it's—there's a—it's getting rushed out the door, and it'll actually have a new managed service or new service launched out, but they're also sort of cutting some corners just to actually make sure it's packaged up and ready to go.Corey: When I'm looking at this, and seeing how this stuff gets packaged, and how it's built out, I start to understand a pattern that I've been relatively down on across the board. I'm curious to get your take because you work at a fairly sizable company as an engineering manager, running teams of people who do this sort of thing. Where do you land on the idea of companies building internal platforms to wrap around the offerings that the cloud service providers that they use make available to them?Evelyn: So, my opinion is that you need to build out some form of standardized tool set in order to actually be able to innovate quickly. Now, this sounds counterintuitive because everyone is like, “Oh, you know, if I want to innovate, I should be able to do this experiment, and try out everything, and use what works, and just release it.” And that greatness [unintelligible 00:23:14] mentality, you know, it's like five talented engineers working to build something. But when you have, instead of five engineers, you have five teams of five engineers each, and every single team does something totally different. You know, one uses Scala, and other on TypeScript, another one, you know .NET, and then there could have been a [last 00:23:30] one, you know, comes in, you know, saying they're still using Ruby.And then next thing you know, you know, you have, like, incredibly diverse platforms for services. And if you want to do any sort of like hiring or cross-training, it becomes incredibly difficult. And actually, as the organization grows, you want to hire talent, and so you're going to have to hire, you know, a developer for this team, you going to have to hire, you know, Ruby developer for this one, a Scala guy here, a Node.js guy over there.And so, this is where we say, “Okay, let's agree. We're going to be a Scala shop. Great. All right, are we running serverless? Are we running containerized?” And you agree on those things. So, that's already, like, the formation of it. And oftentimes, you start with DevOps. You'll say, like, “I'm a DevOps team,” you know, or doing a DevOps culture, if you do it properly, but you always hit this scaling issue where you start growing, and then how do you maintain that common tool set? And that's where we start looking at, you know, having a platform… approach, but I'm going to say it's Platform-as-a-Product. That's the key.Corey: Yeah, that's a good way of framing it because originally, the entire world needed that. That's what RightScale was when EC2 first came out. It was a reimagining of the EC2 console that was actually usable. And in time, AWS improved that to the point where RightScale didn't really have a place anymore in a way that it had previously, and that became a business challenge for them. But you have, what is it now, 2, 300 services that AWS has put out, and out, and okay, great. Most companies are really only actively working with a handful of those. How do you make those available in a reasonable way to your teams, in ways that aren't distracting, dangerous, et cetera? I don't know the answer on that one.Evelyn: Yeah. No, that's true. So, full disclosure. At AutoScout, we do platform engineering. So, I'm part of, like, the platform engineering group, and we built a platform for our product teams. It's kind of like, you need to decide to [follow 00:25:24] those answers, you know? Like, are we going to be fully containerized? Okay, then, great, we're going to use Fargate. All right, how do we do it so that developers don't actually—don't need to think that they're running Fargate workloads?And that's, like, you know, where it's really important to have those standardized abstractions that developers actually enjoy using. And I'd even say that, before you start saying, “Ah, we're going to do platform,” you say, “We should probably think about developer experience.” Because you can do a developer experience without a platform. You can do that, you know, in a DevOps approach, you know? It's basically build tools that makes it easy for developers to write code. That's the first step for anything. It's just, like, you have people writing the code; make sure that they can do the things easily, and then look at how to operate it.Corey: That sure would be nice. There's a lack of focus on usability, especially when it comes to a number of developer tools that we see out there in the wild, in that, they're clearly built by people who understand the problem space super well, but they're designing these things to be used by people who just want to make the website work. They don't have the insight, the knowledge, the approach, any of it, nor should they necessarily be expected to.Evelyn: No, that's true. And what I see is, a lot of the times, it's a couple really talented engineers who are just getting shit done, and they get shit done however they can. So, it's basically like, if they're just trying to run the website, they're just going to write the code to get things out there and call it a day. And then somebody else comes along, has a heart attack when see what's been done, and they're kind of stuck with it because there is no guardrails or paved path or however you want to call it.Corey: I really hope—truly—that this is going to be something that we look back and laugh when this episode airs, that, “Oh, yeah, we just got it so wrong. Look at all the amazing stuff that came out of re:Invent.” Are you going to be there this year?Evelyn: I am going to be there this year.Corey: My condolences. I keep hoping people get to escape.Evelyn: This is actually my first one in, I think, five years. So, I mean, the last time I was there was when everybody's going crazy over pins. And I still have a bag of them [laugh].Corey: Yeah, that did seem like a hot-second collectable moment, didn't it?Evelyn: Yeah. And then at the—I think, what, the very last day, as everybody's heading to re:Play, you could just go into the registration area, and they just had, like, bags of them lying around to take. So, all the competing, you know, to get the requirements for a pin was kind of moot [laugh].Corey: Don't you hate it at some point where it's like, you feel like I'm going to finally get this crowning achievement, it's like or just show up at the buffet at the end and grab one of everything, and wow, that would have saved me a lot of pain and trouble.Evelyn: Yeah.Corey: Ugh, scavenger hunts are hard, as I'm about to learn to my own detriment.Evelyn: Yeah. No, true. Yeah. But I am really hoping that re:Invent proves me wrong. Embarrassingly wrong, and then all my colleagues can proceed to mock me for this ridiculous podcast that I made with you. But I am a fierce skeptic. Optimistic nihilist, but still a nihilist, so we'll see how re:Invent turns out.Corey: So, I am curious, given your experience at more large companies than I tend to be embedded with for any period of time, how have you found that these large organizations tend to pick up new technologies? What does the adoption process look like? And honestly, if you feel like throwing some shade, how do they tend to get it wrong?Evelyn: In most cases, I've seen it go… terrible. Like, it just blows up in their face. And I say that is because a lot of the time, an organization will say, “Hey, we're going to adopt this new way of organizing teams or developing products,” and they look at all the practices. They say, “Okay, great. Product management is going to bring it in, they're going to structure things, how we do the planning, here's some great charts and diagrams,” but they don't really look at the culture aspect.And that's always where I've seen things fall apart. I've been in a room where, you know, our VP was really excited about team topologies and say, “Hey, we're going to adopt it.” And then an engineering manager proceeded to say, “Okay, you're responsible for this team, you're responsible for that team, you're responsible for this team talking to, like, a team of, like, five engineers,” which doesn't really work at all. Or, like, I think the best example is DevOps, you know, where you say, “Ah, we're going to adopt DevOps, we're going to have a DevOps team, or have a DevOps engineer.”Corey: Step one: we're going to rebadge everyone with existing job titles to have the new fancy job titles that reflect it. It turns out that's not necessarily sufficient in and of itself.Evelyn: Not really. The Spotify model. People say, like, “Oh, we're going to do the Spotify model. We're going to do skills, tribes, you know, and everything. It's going to be awesome, it's going to be great, you know, and nice, cross-functional.”The reason I say it bails on us every single time is because somebody wants to be in control of the process, and if the process is meant to encourage collaboration and innovation, that person actually becomes a chokehold for it. And it could be somebody that says, like, “Ah, I need to be involved in every single team, and listen to know what's happening, just so I'm aware of it.” What ends up happening is that everybody differs to them. So, there is no collaboration, there is no innovation. DevOps, you say, like, “Hey, we're going to have a team to do everything, so your developers don't need to worry about it.” What ends up happening is you're still an ops team, you still have your silos.And that's always a challenge is you actually have to say, “Okay, what are the cultural values around this process?” You know, what is SRE? What is DevOps, you know? Is it seen as processes, is it a series of principles, platform, maybe, you know? We have to say, like—that's why I say, Platform-as-a-Product because you need to have that product mindset, that culture of product thinking, to really build a platform that works because it's all about the user journey.It's not about building a common set of tools. It's the user journey of how a person interacts with their code to get it into a production environment. And so, you need to understand how that person sits down at their desk, starts the laptop up, logs in, opens the IDE, what they're actually trying to get done. And once you understand that, then you know your requirements, and you build something to fill those things so that they are happy to use it, as opposed to saying, “This is our platform, and you're going to use it.” And they're probably going to say, “No.” And the next thing, you know, they're just doing their own thing on the side.Corey: Yeah, the rise of Shadow IT has never gone away. It's just, on some level, it's the natural expression, I think it's an immune reaction that companies tend to have when process gets in the way. Great, we have an outcome that we need to drive towards; we don't have a choice. Cloud empowered a lot of that and also has given tools to help rein it in, and as with everything, the arms race continues.Evelyn: Yeah. And so, what I'm going to continue now, kind of like, toot the platform horn. So, Gregor Hohpe, he's a [solutions architect 00:31:56]—I always f- up his name. I'm so sorry, Gregor. He has a great book, and even a talk, called The Magic of Platforms, that if somebody is actually curious about understanding of why platforms are nice, they should really watch that talk.If you see him at re:Invent, or a summit or somewhere giving a talk, go listen to that, and just pick his brain. Because that's—for me, I really kind of strongly agree with his approach because that's really how, like, you know, as he says, like, boost innovation is, you know, where you're actually building a platform that really works.Corey: Yeah, it's a hard problem, but it's also one of those things where you're trying to focus on—at least ideally—an outcome or a better situation than you currently find yourselves in. It's hard to turn down things that might very well get you there sooner, faster, but it's like trying to effectively cargo-cult the leadership principles from your last employer into your new one. It just doesn't work. I mean, you see more startups from Amazonians who try that, and it just goes horribly because without the cultural understanding and the supporting structures, it doesn't work.Evelyn: Exactly. So, I've worked with, like, organizations, like, 4000-plus people, I've worked for, like, small startups, consulted, and this is why I say, almost every single transformation, it fails the first time because somebody needs to be in control and track things and basically be really, really certain that people are doing it right. And as soon as it blows up in their face, that's when they realize they should actually take a step back. And so, even for building out a platform, you know, doing Platform-as-a-Product, I always reiterate that you have to really be willing to just invest upfront, and not get very much back. Because you have to figure out the whole user journey, and what you're actually building, before you actually build it.Corey: I really want to thank you for taking the time to speak with me today. If people want to learn more, where's the best place for them to find you?Evelyn: So, I used to be on Twitter, but I've actually got off there after it kind of turned a bit toxic and crazy.Corey: Feels like that was years ago, but that's beside the point.Evelyn: Yeah, precisely. So, I would even just say because this feels like a corporate show, but find me on LinkedIn of all places because I will be sharing whatever I find on there, you know? So, just look me up on my name, Evelyn Osman, and give me a follow, and I'll probably be screaming into the cloud like you are.Corey: And we will, of course, put links to that in the show notes. Thank you so much for taking the time to speak with me. I appreciate it.Evelyn: Thank you, Corey.Corey: Evelyn Osman, engineering manager at AutoScout24. I'm Cloud Economist Corey Quinn, and this is Screaming in the Cloud. If you've enjoyed this podcast, please leave a five-star review on your podcast platform of choice, whereas if you've hated this podcast, please leave a five-star review on your podcast platform of choice, and I will read it once I finish building an internal platform to normalize all of those platforms together into one.Corey: If your AWS bill keeps rising and your blood pressure is doing the same, then you need The Duckbill Group. We help companies fix their AWS bill by making it smaller and less horrifying. The Duckbill Group works for you, not AWS. We tailor recommendations to your business, and we get to the point. Visit duckbillgroup.com to get started.

In this episode we talk Outposts! how to do links, decoration, power management and so on. We discuss Bethesda's announcement of "all new ways of traveling", their planned 6 week update schedule, Wigit's unfortunate time trying to get a weapon, Archon's new epic outpost build and Rook's....exploring. We even talk about a new challenge coming in first week of Jan 2024. 

If you're reading this drop a Comment below

If you're reading this...it's our 2nd birthday

Facebook: http://facebook.com/famteams Instagram: http://www.instagram.com/familyteams Website: http://www.familyteams.com Hi, welcome to the Family Teams podcast! Our goal here is to help your family become a multigenerational team on mission by providing you with Biblically rooted concepts, tools and rhythms! Your hosts are Jeremy Pryor and Jefferson Bethke and this season is all about crafting a family-friendly day of rest.

Our 74th weekly NFT livestream. This week we're celebrating our 2 Year Anniversary on 10/15. Join us for a night of exciting updates from Derp Birds, Jellycubes, Mallard Order, and Old Money. We'll also be hanging out and taking questions about your favorite NFT projects. F35 Merch is LIVE NOW

In this special live-recorded episode of Screaming in the Cloud, Corey interviews himself— well, kind of. Corey hosts an AMA session, answering both live and previously submitted questions from his listeners. Throughout this episode, Corey discusses misconceptions about his public persona, the nature of consulting on AWS bills, why he focuses so heavily on AWS offerings, his favorite breakfast foods, and much, much more. Corey shares insights into how he monetizes his public persona without selling out his genuine opinions on the products he advertises, his favorite and least favorite AWS services, and some tips and tricks to get the most out of re:Invent.About CoreyCorey is the Chief Cloud Economist at The Duckbill Group. Corey's unique brand of snark combines with a deep understanding of AWS's offerings, unlocking a level of insight that's both penetrating and hilarious. He lives in San Francisco with his spouse and daughters.Links Referenced: lastweekinaws.com/disclosures: https://lastweekinaws.com/disclosures duckbillgroup.com: https://duckbillgroup.com TranscriptAnnouncer: Hello, and welcome to Screaming in the Cloud with your host, Chief Cloud Economist at The Duckbill Group, Corey Quinn. This weekly show features conversations with people doing interesting work in the world of cloud, thoughtful commentary on the state of the technical world, and ridiculous titles for which Corey refuses to apologize. This is Screaming in the Cloud.Corey: As businesses consider automation to help build and manage their hybrid cloud infrastructures, deployment speed is important, but so is cost. Red Hat Ansible Automation Platform is available in the AWS Marketplace to help you meet your cloud spend commitments while delivering best-of-both-worlds support.Corey: Well, all right. Thank you all for coming. Let's begin and see how this whole thing shakes out, which is fun and exciting, and for some godforsaken reason the lights like to turn off, so we're going to see if that continues. I've been doing Screaming in the Cloud for about, give or take, 500 episodes now, which is more than a little bit ridiculous. And I figured it would be a nice change of pace if I could, instead of reaching out and talking to folks who are innovative leaders in the space and whatnot, if I could instead interview my own favorite guest: myself.Because the entire point is, I'm usually the one sitting here asking questions, so I'm instead going to now gather questions from you folks—and feel free to drop some of them into the comments—but I've solicited a bunch of them, I'm going to work through them and see what you folks want to know about me. I generally try to be fairly transparent, but let's have fun with it. To be clear, if this is your first exposure to my Screaming in the Cloud podcast show, it's generally an interview show talking with people involved with the business of cloud. It's not intended to be snarky because not everyone enjoys thinking on their feet quite like that, but rather a conversation of people about what they're passionate about. I'm passionate about the sound of my own voice. That's the theme of this entire episode.So, there are a few that have come through that are in no particular order. I'm going to wind up powering through them, and again, throw some into the comments if you want to have other ones added. If you're listening to this in the usual Screaming in the Cloud place, well, send me questions and I am thrilled to wind up passing out more of them. The first one—a great one to start—comes with someone asked me a question about the video feed. “What's with the Minecraft pickaxe on the wall?” It's made out of foam.One of my favorite stories, and despite having a bunch of stuff on my wall that is interesting and is stuff that I've created, years ago, I wrote a blog post talking about how machine learning is effectively selling digital pickaxes into a gold rush. Because the cloud companies pushing it are all selling things such as, you know, they're taking expensive compute, large amounts of storage, and charging by the hour for it. And in response, Amanda, who runs machine learning analyst relations at AWS, sent me that by way of retaliation. And it remains one of my absolute favorite gifts. It's, where's all this creativity in the machine-learning marketing? No, instead it's, “We built a robot that can think. But what are we going to do with it now? Microsoft Excel.” Come up with some of that creativity, that energy, and put it into the marketing side of the world.Okay, someone else asks—Brooke asks, “What do I think is people's biggest misconception about me?” That's a good one. I think part of it has been my misconception for a long time about what the audience is. When I started doing this, the only people who ever wound up asking me anything or talking to me about anything on social media already knew who I was, so I didn't feel the need to explain who I am and what I do. So, people sometimes only see the witty banter on Twitter and whatnot and think that I'm just here to make fun of things.They don't notice, for example, that my jokes are never calling out individual people, unless they're basically a US senator, and they're not there to make individual humans feel bad about collectively poor corporate decision-making. I would say across the board, people think that I'm trying to be meaner than I am. I'm going to be honest and say it's a little bit insulting, just from the perspective of, if I really had an axe to grind against people who work at Amazon, for example, is this the best I'd be able to do? I'd like to think that I could at least smack a little bit harder. Speaking of, we do have a question that people sent in in advance.“When was the last time that Mike Julian gave me that look?” Easy. It would have been two days ago because we were both in the same room up in Seattle. I made a ridiculous pun, and he just stared at me. I don't remember what the pun is, but I am an incorrigible punster and as a result, Mike has learned that whatever he does when I make a pun, he cannot incorrige me. Buh-dum-tss. That's right. They're no longer puns, they're dad jokes. A pun becomes a dad joke once the punch line becomes a parent. Yes.Okay, the next one is what is my favorite AWS joke? The easy answer is something cynical and ridiculous, but that's just punching down at various service teams; it's not my goal. My personal favorite is the genie joke where a guy rubs a lamp, Genie comes out and says, “You can have a billion dollars if you can spend $100 million in a month, and you're not allowed to waste it or give it away.” And the person says, “Okay”—like, “Those are the rules.” Like, “Okay. Can I use AWS?” And the genie says, “Well, okay, there's one more rule.” I think that's kind of fun.Let's see, another one. A hardball question: given the emphasis on right-sizing for meager cost savings and the amount of engineering work required to make real architectural changes to get costs down, how do you approach cost controls in companies largely running other people's software? There are not as many companies as you might think where dialing in the specifics of a given application across the board is going to result in meaningful savings. Yes, yes, you're running something in hyperscale, it makes an awful lot of sense, but most workloads don't do that. The mistakes you most often see are misconfigurations for not knowing this arcane bit of AWS trivia, as a good example. There are often things you can do with relatively small amounts of effort. Beyond a certain point, things are going to cost what they're going to cost without a massive rearchitecture and I don't advise people do that because no one is going to be happy rearchitecting just for cost reasons. Doesn't go well.Someone asks, “I'm quite critical of AWS, which does build trust with the audience. Has AWS tried to get you to market some of their services, and would I be open to do that?” That's a great question. Yes, sometimes they do. You can tell this because they wind up buying ads in the newsletter or the podcast and they're all disclaimed as a sponsored piece of content.I do have an analyst arrangement with a couple of different cloud companies, as mentioned lastweekinaws.com/disclosures, and the reason behind that is because you can buy my attention to look at your product and talk to you in-depth about it, but you cannot buy my opinion on it. And those engagements are always tied to, let's talk about what the public is seeing about this. Now, sometimes I write about the things that I'm talking about because that's where my mind goes, but it's not about okay, now go and talk about this because we're paying you to, and don't disclose that you have a financial relationship.No, that is called fraud. I figure I can sell you as an audience out exactly once, so I better be able to charge enough money to never have to work again. Like, when you see me suddenly talk about multi-cloud being great and I became a VP at IBM, about three to six months after that, no one will ever hear from me again because I love nesting doll yacht money. It'll be great.Let's see. The next one I have on my prepared list here is, “Tell me about a time I got AWS to create a pie chart.” I wish I'd see less of it. Every once in a while I'll talk to a team and they're like, “Well, we've prepared a PowerPoint deck to show you what we're talking about.” No, Amazon is famously not a PowerPoint company and I don't know why people feel the need to repeatedly prove that point to me because slides are not always the best way to convey complex information.I prefer to read documents and then have a conversation about them as Amazon tends to do. The visual approach and the bullet lists and all the rest are just frustrating. If I'm going to do a pie chart, it's going to be in service of a joke. It's not going to be anything that is the best way to convey information in almost any sense.“How many internal documents do I think reference me by name at AWS,” is another one. And I don't know the answer to documents, but someone sent me a screenshot once of searching for my name in their Slack internal nonsense thing, and it was about 10,000 messages referenced me that it found. I don't know what they were saying. I have to assume, on some level, just something that does a belt feed from my Twitter account where it lists my name or something. But I choose to believe that no, they actually are talking about me to that level of… of extreme.Let's see, let's turn back to the chat for a sec because otherwise it just sounds like I'm doing all prepared stuff. And I'm thrilled to do that, but I'm also thrilled to wind up fielding questions from folks who are playing along on these things. “I love your talk, ‘Heresy in the Church of Docker.' Do I have any more speaking gigs planned?” Well, today's Wednesday, and this Friday, I have a talk that's going out at the CDK Community Day.I also have a couple of things coming up that are internal corporate presentations at various places. But at the moment, no. I suspect I'll be giving a talk if they accept it at SCALE in Pasadena in March of next year, but at the moment, I'm mostly focused on re:Invent, just because that is eight short weeks away and I more or less destroy the second half of my year because… well, holidays are for other people. We're going to talk about clouds, as Amazon and the rest of us dance to the tune that they play.“Look in my crystal ball; what will the industry look like in 5, 10, or 20 years?” Which is a fun one. You shouldn't listen to me on this. At all. I was the person telling you that virtualization was a flash in the pan, that cloud was never going to catch on, that Kubernetes and containers had a bunch of problems that were unlikely to be solved, and I'm actually kind of enthused about serverless which probably means it's going to flop.I am bad at predicting overall trends, but I have no problem admitting that wow, I was completely wrong on that point, which apparently is a rarer skill than it should be. I don't know what the future the industry holds. I know that we're seeing some AI value shaping up. I think that there's going to be a bit of a downturn in that sector once people realize that just calling something AI doesn't mean you make wild VC piles of money anymore. But there will be use cases that filter out of it. I don't know what they're going to look like yet, but I'm excited to see it.Okay, “Have any of the AWS services increased costs in the last year? I was having a hard time finding historical pricing charts for services.” There have been repricing stories. There have been SMS charges in India that have—and pinpointed a few other things—that wound up increasing because of a government tariff on them and that cost was passed on. Next February, they're going to be charging for public IPV4 addresses.But those tend to be the exceptions. The way that most costs tend increase have been either, it becomes far cheaper for AWS to provide a service and they don't cut the cost—data transfer being a good example—they'll also often have stories in that they're going to start launching a bunch of new things, and you'll notice that AWS bills tend to grow in time. Part of that growth, part of that is just cruft because people don't go back and clean things up. But by and large, I have not seen, “This thing that used to cost you $1 is now going to cost you $2.” That's not how AWS does pricing. Thankfully. Everyone's always been scared of something like that happening. I think that when we start seeing actual increases like that, that's when it's time to start taking a long, hard look at the way that the industry is shaping up. I don't think we're there yet.Okay. “Any plans for a Last Week in Azure or a Last Week in GCP?” Good question. If so, I won't be the person writing it. I don't think that it's reasonable to expect someone to keep up with multiple large companies and their releases. I'd also say that Azure and GCP don't release updates to services with the relentless cadence that AWS does.The reason I built the thing to start with is simply because it was difficult to gather all the information in one place, at least the stuff that I cared about with an economic impact, and by the time I'd done that, it was, well, this is 80% of the way toward republishing it for other people. I expected someone was going to point me at a thing so I didn't have to do it, and instead, everyone signed up. I don't see the need for it. I hope that in those spaces, they're better at telling their own story to the point where the only reason someone would care about a newsletter would be just my sarcasm tied into whatever was released. But that's not something that I'm paying as much attention to, just because my customers are on AWS, my stuff is largely built on AWS, it's what I have to care about.Let's see here. “What do I look forward to at re:Invent?” Not being at re:Invent anymore. I'm there for eight nights a year. That is shitty cloud Chanukah come to life for me. I'm there to set things up in advance, I'm there to tear things down at the end, and I'm trying to have way too many meetings in the middle of all of that. I am useless for the rest of the year after re:Invent, so I just basically go home and breathe into a bag forever.I had a revelation last year about re:Play, which is that I don't have to go to it if I don't want to go. And I don't like the cold, the repetitive music, the giant crowds. I want to go read a book in a bathtub and call it a night, and that's what I hope to do. In practice, I'll probably go grab dinner with other people who feel the same way. I also love the Drink Up I do there every year over at Atomic Liquors. I believe this year, we're partnering with the folks over at RedMonk because a lot of the people we want to talk to are in the same groups.It's just a fun event: show up, let us buy you drinks. There's no badge scan or any nonsense like that. We just want to talk to people who care to come out and visit. I love doing that. It's probably my favorite part of re:Invent other than not being at re:Invent. It's going to be on November 29th this year. If you're listening to this, please come on by if you're unfortunate enough to be in Las Vegas.Someone else had a good question I want to talk about here. “I'm a TAM for AWS. Cost optimization is one of our functions. What do you wish we would do better after all the easy button things such as picking the right instance and family, savings plans RIs, turning off or delete orphan resources, watching out for inefficient data transfer patterns, et cetera?” I'm going to back up and say that you're begging the question here, in that you aren't doing the easy things, at least not at scale, not globally.I used to think that all of my customer engagements would be, okay after the easy stuff, what's next? I love those projects, but in so many cases, I show up and those easy things have not been done. “Well, that just means that your customers haven't been asking their TAM.” Every customer I've had has asked their TAM first. “Should we ask the free expert or the one that charges us a large but reasonable fixed fee? Let's try the free thing first.”The quality of that advice is uneven. I wish that there were at least a solid baseline. I would love to get to a point where I can assume that I can go ahead and be able to just say, “Okay, you've clearly got your RI stuff, you're right-sizing, you're deleting stuff you're not using, taken care of. Now, let's look at the serious architecture stuff.” It's just rare that I get to see it.“What tool, feature, or widget do I wish AWS would build into the budget console?” I want to be able to set a dollar figure, maybe it's zero, maybe it's $20, maybe it is irrelevant, but above whatever I set, the account will not charge me above that figure, period. If that means they have to turn things off if that means they had to delete portions of data, great. But I want that assurance because even now when I kick the tires in a new service, I get worried that I'm going to wind up with a surprise bill because I didn't understand some very subtle interplay of the dynamics. And if I'm worried about that, everyone else is going to wind up getting caught by that stuff, too.I want the freedom to experiment and if it smacks into a wall, okay, cool. That's $20. That was worth learning that. Whatever. I want the ability to not be charged unreasonable overages. And I'm not worried about it turning from 20 into 40. I'm worried about it turning from 20 into 300,000. Like, there's the, “Oh, that's going to have a dent on the quarterlies,” style of [numb 00:16:01]—All right. Someone also asked, “What is the one thing that AWS could do that I believe would reduce costs for both AWS and their customers. And no, canceling re:Invent doesn't count.” I don't think about it in that way because believe it or not, most of my customers don't come to me asking to reduce their bill. They think they do at the start, but what they're trying to do is understand it. They're trying to predict it.Yes, they want to turn off the waste in the rest, but by and large, there are very few AWS offerings that you take a look at and realize what you're getting for it and say, “Nah, that's too expensive.” It can be expensive for certain use cases, but the dangerous part is when the costs are unpredictable. Like, “What's it going to cost me to run this big application in my data center?” The answer is usually, “Well, run it for a month, and then we'll know.” But that's an expensive and dangerous way to go about finding things out.I think that customers don't care about reducing costs as much as they think; they care about controlling them, predicting them, and understanding them. So, how would they make things less expensive? I don't know. I suspect that data transfer if they were to reduce that at least cross-AZ or eliminate it ideally, you'd start seeing a lot more compute usage in multiple AZs. I've had multiple clients who are not spinning things up in multi-AZ, specifically because they'll take the reliability trade-off over the extreme cost of all the replication flowing back and forth. Aside from that, they mostly get a lot of the value right in how they price things, which I don't think people have heard me say before, but it is true.Someone asked a question here of, “Any major trends that I'm seeing in EDP/PPA negotiations?” Yeah, lately, in particular. Used to be that you would have a Marketplace as the fallback, where it used to be that 50 cents of every dollar you spent on Marketplace would count. Now, it's a hundred percent up to a quarter of your commit. Great.But when you have a long-term commitment deal with Amazon, now they're starting to push for all—put all your other vendors onto the AWS Marketplace so you can have a bigger commit and thus a bigger discount, which incidentally, the discount does not apply to Marketplace spend. A lot of folks are uncomfortable with having Amazon as the middleman between all of their vendor relationships. And a lot of the vendors aren't super thrilled with having to pay percentages of existing customer relationships to Amazon for what they perceive to be remarkably little value. That's the current one.I'm not seeing generative AI play a significant stake in this yet. People are still experimenting with it. I'm not seeing, “Well, we're spending $100 million a year, but make that 150 because of generative AI.” It's expensive to play with gen-AI stuff, but it's not driving the business spend yet. But that's the big trend that I'm seeing over the past, eh, I would say, few months.“Do I use AWS for personal projects?” The first problem there is, well, what's a personal project versus a work thing? My life is starting to flow in a bunch of weird different ways. The answer is yes. Most of the stuff that I build for funsies is on top of AWS, though there are exceptions. “Should I?” Is the follow-up question and the answer to that is, “It depends.”The person is worrying about cost overruns. So, am I. I tend to not be a big fan of uncontrolled downside risk when something winds up getting exposed. I think that there are going to be a lot of caveats there. I know what I'm doing and I also have the backstop, in my case, of, I figure I can have a big billing screw-up or I have to bend the knee and apologize and beg for a concession from AWS, once.It'll probably be on a billboard or something one of these days. Lord knows I have it coming to me. That's something I can use as a get-out-of-jail-free card. Most people can't make that guarantee, and so I would take—if—depending on the environment that you know and what you want to build, there are a lot of other options: buying a fixed-fee VPS somewhere if that's how you tend to think about things might very well be a cost-effective for you, depending on what you're building. There's no straight answer to this.“Do I think Azure will lose any market share with recent cybersecurity kerfuffles specific to Office 365 and nation-state actors?” No, I don't. And the reason behind that is that a lot of Azure spend is not necessarily Azure usage; it's being rolled into enterprise agreements customers negotiate as part of their on-premises stuff, their operating system licenses, their Office licensing, and the rest. The business world is not going to stop using Excel and Word and PowerPoint and Outlook. They're not going to stop putting Windows on desktop stuff. And largely, customers don't care about security.They say they do, they often believe that they do, but I see where the bills are. I see what people spend on feature development, I see what they spend on core infrastructure, and I see what they spend on security services. And I have conversations about budgeting with what are you doing with a lot of these things? The companies generally don't care about this until right after they really should have cared. And maybe that's a rational effect.I mean, take a look at most breaches. And a year later, their stock price is larger than it was when they dispose the breach. Sure, maybe they're burning through their ablated CISO, but the business itself tends to succeed. I wish that there were bigger consequences for this. I have talked to folks who will not put specific workloads on Azure as a result of this. “Will you talk about that publicly?” “No, because who can afford to upset Microsoft?”I used to have guests from Microsoft on my show regularly. They don't talk to me and haven't for a couple of years. Scott Guthrie, the head of Azure, has been on this show. The problem I have is that once you start criticizing their security posture, they go quiet. They clearly don't like me.But their options are basically to either ice me out or play around with my seven seats for Office licensing, which, okay, whatever. They don't have a stick to hit me with, in the way that they do most companies. And whether that's true or not that they're going to lash out like that, companies don't want to take the risk of calling Microsoft out in public. Too big to be criticized as sort of how that works.Let's see, someone else asks, “How can a startup get the most out of its startup status with AWS?” You're not going to get what you think you want from AWS in this context. “Oh, we're going to be a featured partner so they market us.” I've yet to hear a story about how being featured by AWS for something has dramatically changed the fortunes of a startup. Usually, they'll do that when there's either a big social mission and you never hear about the company again, or they're a darling of the industry that's taking the world by fire and they're already [at 00:22:24] upward swing and AWS wants to hang out with those successful people in public and be seen to do so.The actual way that startup stuff is going to manifest itself well for you from AWS is largely in the form of credits as you go through Activate or one of their other programs. But be careful. Treat them like actual money, not this free thing you don't have to worry about. One day they expire or run out and suddenly you're going from having no dollars going to AWS to ten grand a month and people aren't prepared for that. It's, “Wait. So you mean this costs money? Oh, my God.”You have to approach it with a sense of discipline. But yeah, once you—if you can do that, yeah, free money and a free cloud bill for a few years? That's not nothing. I also would question the idea of being able to ask a giant company that's worth a trillion-and-a-half dollars and advice for how to be a startup. I find that one's always a little on the humorous side myself.“What do I think is the most underrated service or feature release from 2023? Full disclosures, this means I'll make some content about it,” says Brooke over at AWS. Oh, that's a good question. I'm trying to remember when various things have come out and it all tends to run together. I think that people are criticizing AWS for charging for IPV4 an awful lot, and I think that that is a terrific change, just because I've seen how wasteful companies are with public IP addresses, which are basically an exhausted or rapidly exhausting resource.And they just—you spend tens or hundreds of thousands of these things and don't use reason to think about that. It'll be one of the best things that we've seen for IPV6 adoption once AWS figures out how to make that work. And I would say that there's a lot to be said for since, you know, IPV4 is exhausted already, now we're talking about can we get them on the secondary markets, you need a reasonable IP plan to get some of those. And… “Well, we just give them the customers and they throw them away.” I want AWS to continue to be able to get those for the stuff that the rest of us are working on, not because one big company uses a million of them, just because, “Oh, what do you mean private IP addresses? What might those be?” That's part of it.I would say that there's also been… thinking back on this, it's unsung, the compute optimizer is doing a lot better at recommending things than it used to be. It was originally just giving crap advice, and over time, it started giving advice that's actually solid and backs up what I've seen. It's not perfect, and I keep forgetting it's there because, for some godforsaken reason, it's its own standalone service, rather than living in the billing console where it belongs. But no one's excited about a service like that to the point where they talk about or create content about it, but it's good, and it's getting better all the time. That's probably a good one. They recently announced the ability for it to do GPU instances which, okay great, for people who care about that, awesome, but it's not exciting. Even I don't think I paid much attention to it in the newsletter.Okay, “Does it make economic sense to bring your own IP addresses to AWS instead of paying their fees?” Bring your own IP, if you bring your own allocation to AWS, costs you nothing in terms of AWS costs. You take a look at the market rate per IP address versus what AWS costs, you'll hit break even within your first year if you do it. So yeah, it makes perfect economic sense to do it if you have the allocation and if you have the resourcing, as well as the ability to throw people at the problem to do the migration. It can be a little hairy if you're not careful. But the economics, the benefit is clear on that once you account for those variables.Let's see here. We've also got tagging. “Everyone nods their heads that they know it's the key to controlling things, but how effective are people at actually tagging, especially when new to cloud?” They're terrible at it. They're never going to tag things appropriately. Automation is the way to do it because otherwise, you're going to spend the rest of your life chasing developers and asking them to tag things appropriately, and then they won't, and then they'll feel bad about it. No one enjoys that conversation.So, having derived tags and the rest, or failing that, having some deployment gate as early in the process as possible of, “Oh, what's the tag for this?” Is the only way you're going to start to see coverage on this. And ideally, someday you'll go back and tag a bunch of pre-existing stuff. But it's honestly the thing that everyone hates the most on this. I have never seen a company that says, “We are thrilled with our with our tag coverage. We're nailing it.” The only time you see that is pure greenfield, everything done without ClickOps, and those environments are vanishingly rare.“Outside a telecom are customers using local zones more, or at all?” Very, very limited as far as what their usage looks like on that. Because that's… it doesn't buy you as much as you'd think for most workloads. The real benefit is a little more expensive, but it's also in specific cities where there are not AWS regions, and at least in the United States where the majority of my clients are, there is not meaningful latency differences, for example, from in Los Angeles versus up to Oregon, since no one should be using the Northern California region because it's really expensive. It's a 20-millisecond round trip, which in most cases, for most workloads, is fine.Gaming companies are big exception to this. Getting anything they can as close to the customer as possible is their entire goal, which very often means they don't even go with some of the cloud providers in some places. That's one of those actual multi-cloud workloads that you want to be able to run anywhere that you can get a baseline computer up to run a container or a golden image or something. That is the usual case. The rest are, for local zones, is largely going to be driven by specific one-off weird things. Good question.Let's see, “Is S3 intelligent tiering good enough or is it worth trying to do it yourself?” Your default choice for almost everything should be intelligent tiering in 2023. It winds up costing you more only in very specific circumstances that are unlikely to be anything other than a corner case for what you're doing. And the exceptions to this are, large workloads that are running a lot of S3 stuff where the lifecycle is very well understood, environments where you're not going to be storing your data for more than 30 days in any case and you can do a lifecycle policy around it. Other than those use cases, yeah, the monitoring fee is not significant in any environment I've ever seen.And people view—touch their data a lot less than they believe. So okay, there's a monitoring fee for object, yes, but it also cuts your raw storage cost in half for things that aren't frequently touched. So, you know, think about it. Run your own numbers and also be aware that first month as it transitions in, you're going to see massive transition charges per object, but wants it's an intelligent tiering, there's no further transition charges, which is nice.Let's see here. “We're all-in on serverless”—oh good, someone drank the Kool-Aid, too—“And for our use cases, it works great. Do I find other customers moving to it and succeeding?” Yeah, I do when they're moving to it because for certain workloads, it makes an awful lot of sense. For others, it requires a complete reimagining of whatever it is that you're doing.The early successes were just doing these periodic jobs. Now, we're seeing full applications built on top of event-driven architectures, which is really neat to see. But trying to retrofit something that was never built with that in mind can be more trouble than it's worth. And there are corner cases where building something on serverless would cost significantly more than building it in a server-ful way. But its time has come for an awful lot of stuff. Now, what I don't subscribe to is this belief that oh, if you're not building something serverless you're doing it totally wrong. No, that is not true. That has never been true.Let's see what else have we got here? Oh, “Following up on local zones, how about Outposts? Do I see much adoption? What's the primary use case or cases?” My customers inherently are coming to me because of a large AWS bill. If they're running Outposts, it is extremely unlikely that they are putting significant portions of their spend through the Outpost. It tends to be something of a rounding error, which means I don't spend a lot of time focusing on it.They obviously have some existing data center workloads and data center facilities where they're going to take an AWS-provided rack and slap it in there, but it's not going to be in the top 10 or even top 20 list of service spend in almost every case as a result, so it doesn't come up. One of the big secrets of how we approach things is we start with a big number first and then work our way down instead of going alphabetically. So yes, I've seen customers using them and the customers I've talked to at re:Invent who are using them are very happy with them for the use cases, but it's not a common approach. I'm not a huge fan of the rest.“Someone said the Basecamp saved a million-and-a-half a year by leaving AWS. I know you say repatriation isn't a thing people are doing, but has my view changed at all since you've published that blog post?” No, because everyone's asking me about Basecamp and it's repatriation, and that's the only use case that they've got for this. Let's further point out that a million-and-a-half a year is not as many engineers as you might think it is when you wind up tying that all together. And now those engineers are spending time running that environment.Does it make sense for them? Probably. I don't know their specific context. I know that a million-and-a-half dollars a year to—even if they had to spend that for the marketing coverage that they're getting as a result of this, makes perfect sense. But cloud has never been about raw cost savings. It's about feature velocity.If you have a data center and you move it to the cloud, you're not going to recoup that investment for at least five years. Migrations are inherently expensive. It does not create the benefits that people often believe that they do. That becomes a painful problem for folks. I would say that there's a lot more noise than there are real-world stories [hanging 00:31:57] out about these things.Now, I do occasionally see a specific workload that is moved back to a data center for a variety of reasons—occasionally cost but not always—and I see proof-of-concept projects that they don't pursue and then turn off. Some people like to call that a repatriation. No, I call it as, “We tried and it didn't do what we wanted it to do so we didn't proceed.” Like, if you try that with any other project, no one says, “Oh, you're migrating off of it.” No, you're not. You tested it, it didn't do what it needed to do. I do see net-new workloads going into data centers, but that's not the same thing.Let's see. “Are the talks at re:Invent worth it anymore? I went to a lot of the early re:Invents and haven't and about five years. I found back then that even the level 400 talks left a lot to be desired.” Okay. I'm not a fan of attending conference talks most of the time, just because there's so many things I need to do at all of these events that I would rather spend the time building relationships and having conversations.The talks are going to be on YouTube a week later, so I would rather get to know the people building the service so I can ask them how to inappropriately use it as a database six months later than asking questions about the talk. Conference-ware is often the thing. Re:Invent always tends to have an AWS employee on stage as well. And I'm not saying that makes these talks less authentic, but they're also not going to get through slide review of, “Well, we tried to build this onto this AWS service and it was a terrible experience. Let's tell you about that as a war story.” Yeah, they're going to shoot that down instantly even though failure stories are so compelling, about here's what didn't work for us and how we got there. It's the lessons learned type of thing.Whenever you have as much control as re:Invent exhibits over its speakers, you know that a lot of those anecdotes are going to be significantly watered down. This is not to impugn any of the speakers themselves; this is the corporate mind continuing to grow to a point where risk mitigation and downside protection becomes the primary driving goal.Let's pull up another one from the prepared list here. “My most annoying, overpriced, or unnecessary charge service in AWS.” AWS Config. It's a tax on using the cloud as the cloud. When you have a high config bill, it's because it charges you every time you change the configuration of something you have out there. It means you're spinning up and spinning down EC2 instances, whereas you're going to have a super low config bill if you, you know, treat it like a big dumb data center.It's a tax on accepting the promises under which cloud has been sold. And it's necessary for a number of other things like Security Hub. Control Towers magic-deploys it everywhere and makes it annoying to turn off. And I think that that is a pure rent-seeking charge because people aren't incurring config charges if they're not already using a lot of AWS things. Not every service needs to make money in a vacuum. It's, “Well, we don't charge anything for this because our users are going to spend an awful lot of money on storing things in S3 to use our service.” Great. That's a good thing. You don't have to pile charge upon charge upon charge upon charge. It drives me a little bit nuts.Let's see what else we have here as far as questions go. “Which AWS service delights me the most?” Eesh, depends on the week. S3 has always been a great service just because it winds up turning big storage that usually—used to require a lot of maintenance and care into something I don't think about very much. It's getting smarter and smarter all the time. The biggest lie is the ‘Simple' in its name: ‘Simple Storage Service.' At this point, if that's simple, I really don't want to know what you think complex would look like.“By following me on Twitter, someone gets a lot of value from things I mention offhandedly as things everybody just knows. For example, which services are quasi-deprecated or outdated, or what common practices are anti-patterns? Is there a way to learn this kind of thing all in one go, as in a website or a book that reduces AWS to these are the handful of services everybody actually uses, and these are the most commonly sensible ways to do it?” I wish. The problem is that a lot of the stuff that everyone knows, no, it's stuff that at most, maybe half of the people who are engaging with it knew.They find out by hearing from other people the way that you do or by trying something and failing and realizing, ohh, this doesn't work the way that I want it to. It's one of the more insidious forms of cloud lock-in. You know how a service works, how a service breaks, what the constraints are around when it starts and it stops. And that becomes something that's a hell of a lot scarier when you have to realize, I'm going to pick a new provider instead and relearn all of those things. The reason I build things on AWS these days is honestly because I know the ways it sucks. I know the painful sharp edges. I don't have to guess where they might be hiding. I'm not saying that these sharp edges aren't painful, but when you know they're there in advance, you can do an awful lot to guard against that.“Do I believe the big two—AWS and Azure—cloud providers have agreed between themselves not to launch any price wars as they already have an effective monopoly between them and [no one 00:36:46] win in a price war?” I don't know if there's ever necessarily an explicit agreement on that, but business people aren't foolish. Okay, if we're going to cut our cost of service, instantly, to undercut a competitor, every serious competitor is going to do the same thing. The only reason to do that is if you believe your margins are so wildly superior to your competitors that you can drive them under by doing that or if you have the ability to subsidize your losses longer than they can remain a going concern. Microsoft and Amazon are—and Google—are not in a position where, all right, we're going to drive them under.They can both subsidize losses basically forever on a lot of these things and they realize it's a game you don't win in, I suspect. The real pricing pressure on that stuff seems to come from customers, when all right, I know it's big and expensive upfront to buy a SAN, but when that starts costing me less than S3 on a per-petabyte basis, that's when you start to see a lot of pricing changing in the market. The one thing I haven't seen that take effect on is data transfer. You could be forgiven for believing that data transfer still cost as much as it did in the 1990s. It does not.“Is AWS as far behind in AI as they appear?” I think a lot of folks are in the big company space. And they're all stammering going, “We've been doing this for 20 years.” Great, then why are all of your generative AI services, A, bad? B, why is Alexa so terrible? C, why is it so clear that everything you have pre-announced and not brought to market was very clearly not envisioned as a product to be going to market this year until 300 days ago, when Chat-Gippity burst onto the scene and OpenAI [stole a march 00:38:25] on everyone?Companies are sprinting to position themselves as leaders in the AI space, despite the fact that they've gotten lapped by basically a small startup that's seven years old. Everyone is trying to work the word AI into things, but it always feels contrived to me. Frankly, it tells me that I need to just start tuning the space out for a year until things settle down and people stop describing metric math or anomaly detection is AI. Stop it. So yeah, I'd say if anything, they're worse than they appear as far as from behind goes.“I mostly focus on AWS. Will I ever cover Azure?” There are certain things that would cause me to do that, but that's because I don't want to be the last Perl consultancy is the entire world has moved off to Python. And effectively, my focus on AWS is because that's where the painful problems I know how to fix live. But that's not a suicide pact. I'm not going to ride that down in flames.But I can retool for a different cloud provider—if that's what the industry starts doing—far faster than AWS can go from its current market-leading status to irrelevance. There are certain triggers that would cause me to do that, but at the time, I don't see them in the near term and I don't have any plans to begin covering other things. As mentioned, people want me to talk about the things I'm good at not the thing that makes me completely nonsensical.“Which AWS services look like a good idea, but pricing-wise, they're going to kill you once you have any scale, especially the ones that look okay pricing-wise but aren't really and it's hard to know going in?” CloudTrail data events, S3 Bucket Access logging any of the logging services really, Managed NAT Gateways in a bunch of cases. There's a lot that starts to get really expensive once you hit certain points of scale with a corollary that everyone thinks that everything they're building is going to scale globally and that's not true. I don't build things as a general rule with the idea that I'm going to get ten million users on it tomorrow because by the time I get from nothing to substantial workloads, I'm going to have multiple refactors of what I've done. I want to get things out the door as fast as possible and if that means that later in time, oh, I accidentally built Pinterest. What am I going to do? Well, okay, yeah, I'm going to need to rebuild a whole bunch of stuff, but I'll have the user traffic and mindshare and market share to finance that growth.Early optimization on stuff like this causes a lot more problems than it solves. “Best practices and anti-patterns in managing AWS costs. For context, you once told me about a role that I had taken that you'd seen lots of companies tried to create that role and then said that the person rarely lasts more than a few months because it just isn't effective. You were right, by the way.” Imagine that I sometimes know what I'm talking about.When it comes to managing costs, understand what your goal is here, what you're actually trying to achieve. Understand it's going to be a cross-functional work between people in finance and people that engineering. It is first and foremost, an engineering problem—you learn that at your peril—and making someone be the human gateway to spin things up means that they're going to quit, basically, instantly. Stop trying to shame different teams without understanding their constraints.Savings Plans are a great example. They apply biggest discount first, which is what you want. Less money going out the door to Amazon, but that makes it look like anything with a low discount percentage, like any workload running on top of Microsoft Windows, is not being responsible because they're always on demand. And you're inappropriately shaming a team for something completely out of their control. There's a point where optimization no longer makes sense. Don't apply it to greenfield projects or skunkworks. Things you want to see if the thing is going to work first. You can optimize it later. Starting out with a, ‘step one: spend as little as possible' is generally not a recipe for success.What else have we got here? I've seen some things fly by in the chat that are probably worth mentioning here. Some of it is just random nonsense, but other things are, I'm sure, tied to various questions here. “With geopolitics shaping up to govern tech data differently in each country, does it make sense to even build a globally distributed B2B SaaS?” Okay, I'm going to tackle this one in a way that people will probably view as a bit of an attack, but it's something I see asked a lot by folks trying to come up with business ideas.At the outset, I'm a big believer in, if you're building something, solve it for a problem and a use case that you intrinsically understand. That is going to mean the customers with whom you speak. Very often, the way business is done in different countries and different cultures means that in some cases, this thing that's a terrific idea in one country is not going to see market adoption somewhere else. There's a better approach to build for the market you have and the one you're addressing rather than aspirational builds. I would also say that it potentially makes sense if there are certain things you know are going to happen, like okay, we validated our marketing and yeah, it turns out that we're building an image resizing site. Great. People in Germany and in the US all both need to resize images.But you know, going in that there's going to be a data residency requirement, so architecting, from day one with an idea that you can have a partition that winds up storing its data separately is always going to be to your benefit. I find aligning whatever you're building with the idea of not being creepy is often a great plan. And there's always the bring your own storage approach to, great, as a customer, you can decide where your data gets stored in your account—charge more for that, sure—but then that na—it becomes their problem. Anything that gets you out of the regulatory critical path is usually a good idea. But with all the problems I would have building a business, that is so far down the list for almost any use case I could ever see pursuing that it's just one of those, you have a half-hour conversation with someone who's been down the path before if you think it might apply to what you're doing, but then get back to the hard stuff. Like, worry on the first two or three steps rather than step 90 just because you'll get there eventually. You don't want to make your future life harder, but you also don't want to spend all your time optimizing early, before you've validated you're actually building something useful.“What unique feature of AWS do I most want to see on other cloud providers and vice versa?” The vice versa is easy. I love that Google Cloud by default has the everything in this project—which is their account equivalent—can talk to everything else, which means that humans aren't just allowing permissions to the universe because it's hard. And I also like that billing is tied to an individual project. ‘Terminate all billable resources in this project' is a button-click away and that's great.Now, what do I wish other cloud providers would take from AWS? Quite honestly, the customer obsession. It's still real. I know it sounds like it's a funny talking point or the people who talk about this the most under the cultists, but they care about customer problems. Back when no one had ever heard of me before and my AWS Bill was seven bucks, whenever I had a problem with a service and I talked about this in passing to folks, Amazonians showed up out of nowhere to help make sure that my problem got answered, that I was taken care of, that I understood what I was misunderstanding, or in some cases, the feedback went to the product team.I see too many companies across the board convinced that they themselves know best about what customers need. That occasionally can be true, but not consistently. When customers are screaming for something, give them what they need, or frankly, get out of the way so someone else can. I mean, I know someone's expecting me to name a service or something, but we've gotten past the point, to my mind, of trying to do an apples-to-oranges comparison in terms of different service offerings. If you want to build a website using any reasonable technology, there's a whole bunch of companies now that have the entire stack for you. Pick one. Have fun.We've got time for a few more here. Also, feel free to drop more questions in. I'm thrilled to wind up answering any of these things. Have I seen any—here's one that about Babelfish, for example, from Justin [Broadly 00:46:07]. “Have I seen anyone using Babelfish in the wild? It seems like it was a great idea that didn't really work or had major trade-offs.”It's a free open-source project that translates from one kind of database SQL to a different kind of database SQL. There have been a whole bunch of attempts at this over the years, and in practice, none of them have really panned out. I have seen no indications that Babelfish is different. If someone at AWS works on this or is a customer using Babelfish and say, “Wait, that's not true,” please tell me because all I'm saying is I have not seen it and I don't expect that I will. But I'm always willing to be wrong. Please, if I say something at some point that someone disagrees with, please reach out to me. I don't intend to perpetuate misinformation.“Purely hypothetically”—yeah, it's always great to ask things hypothetically—“In the companies I work with, which group typically manages purchasing savings plans, the ops team, finance, some mix of both?” It depends. The sad answer is, “What's a savings plan,” asks the company, and then we have an educational path to go down. Often it is individual teams buying them ad hoc, which can work, cannot as long as everyone's on the same page. Central planning, in a bunch of—a company that's past a certain point in sophistication is where everything winds up leading to.And that is usually going to be a series of discussions, ideally run by that group in a cross-functional way. They can be cost engineering, they can be optimization engineering, I've heard it described in a bunch of different ways. But that is—increasingly as the sophistication of your business and the magnitude of your spend increases, the sophistication of how you approach this should change as well. Early on, it's the offense of some VP of engineering at a startup. Like, “Oh, that's a lot of money,” running the analyzer and clicking the button to buy what it says. That's not a bad first-pass attempt. And then I think getting smaller and smaller buys as you continue to proceed means you can start to—it no longer becomes the big giant annual decision and instead becomes part of a frequently used process. That works pretty well, too.Is there anything else that I want to make sure I get to before we wind up running this down? To the folks in the comments, this is your last chance to throw random, awkward questions my way. I'm thrilled to wind up taking any slings, arrows, et cetera, that you care to throw my way a going once, going twice style. Okay, “What is the most esoteric or shocking item on the AWS bill that you ever found with one of your customers?” All right, it's been long enough, and I can say it without naming the customer, so that'll be fun.My personal favorite was a high five-figure bill for Route 53. I joke about using Route 53 as a database. It can be, but there are better options. I would say that there are a whole bunch of use cases for Route 53 and it's a great service, but when it's that much money, it occasions comment. It turned out that—we discovered, in fact, a data exfiltration in progress which made it now a rather clever security incident.And, “This call will now be ending for the day and we're going to go fix that. Thanks.” It's like I want a customer testimonial on that one, but for obvious reasons, we didn't get one. But that was probably the most shocking thing. The depressing thing that I see the most—and this is the core of the cost problem—is not when the numbers are high. It's when I ask about a line item that drives significant spend, and the customer is surprised.I don't like it when customers don't know what they're spending money on. If your service surprises customers when they realize what it costs, you have failed. Because a lot of things are expensive and customers know that and they're willing to take the value in return for the cost. That's fine. But tricking customers does not serve anyone well, even your own long-term interests. I promise.“Have I ever had to reject a potential client because they had a tangled mess that was impossible to tackle, or is there always a way?” It's never the technology that will cause us not to pursue working with a given company. What will is, like, if you go to our website at duckbillgroup.com, you're not going to see a ‘Buy Here' button where you ‘add one consulting, please' to your shopping cart and call it a day.It's a series of conversations. And what we will try to make sure is, what is your goal? Who's aligned with it? What are the problems you're having in getting there? And what does success look like? Who else is involved in this? And it often becomes clear that people don't like the current situation, but there's no outcome with which they would be satisfied.Or they want something that we do not do. For example, “We want you to come in and implement all of your findings.” We are advisory. We do not know the specifics of your environment and—or your deployment processes or the rest. We're not an engineering shop. We charge a fixed fee and part of the way we can do that is by controlling the scope of what we do. “Well, you know, we have some AWS bills, but we really want to—we really care about is our GCP bill or our Datadog bill.” Great. We don't focus on either of those things. I mean, I can just come in and sound competent, but that's not what adding value as a consultant is about. It's about being authoritatively correct. Great question, though.“How often do I receive GovCloud cost optimization requests? Does the compliance and regulation that these customers typically have keep them from making the needed changes?” It doesn't happen often and part of the big reason behind that is that when we're—and if you're in GovCloud, it's probably because you are a significant governmental entity. There's not a lot of private sector in GovCloud for almost every workload there. Yes, there are exceptions; we don't tend to do a whole lot with them.And the government procurement process is a beast. We can sell and service three to five commercial engagements in the time it takes to negotiate a single GovCloud agreement with a customer, so it just isn't something that we focused. We don't have the scale to wind up tackling that down. Let's also be clear that, in many cases, governments don't view money the same way as enterprise, which in part is a good thing, but it also means that, “This cloud thing is too expensive,” is never the stated problem. Good question.“Waffles or pancakes?” Is another one. I… tend to go with eggs, personally. It just feels like empty filler in the morning. I mean, you could put syrup on anything if you're bold enough, so if it's just a syrup delivery vehicle, there are other paths to go.And I believe we might have exhausted the question pool. So, I want to thank you all for taking the time to talk with me. Once again, I am Cloud Economist Corey Quinn. And this is a very special live episode of Screaming in the Cloud. If you've enjoyed this podcast, please leave a five-star review wherever you can—or a thumbs up, or whatever it is, like and subscribe obviously—whereas if you've hated this podcast, same thing: five-star review, but also go ahead and leave an insulting comment, usually around something I've said about a service that you deeply care about because it's tied to your paycheck.Corey: If your AWS bill keeps rising and your blood pressure is doing the same, then you need The Duckbill Group. We help companies fix their AWS bill by making it smaller and less horrifying. The Duckbill Group works for you, not AWS. We tailor recommendations to your business and we get to the point. Visit duckbillgroup.com to get started.

We're getting together for our first time since the game launched to discuss our first impressions and discuss some of the things we've figured out that makes our time in game even easier.

Steve Tuck, Co-Founder & CEO of Oxide Computer Company, joins Corey on Screaming in the Cloud to discuss his work to make modern computers cloud-friendly. Steve describes what it was like going through early investment rounds, and the difficult but important decision he and his co-founder made to build their own switch. Corey and Steve discuss the demand for on-prem computers that are built for cloud capability, and Steve reveals how Oxide approaches their product builds to ensure the masses can adopt their technology wherever they are. About SteveSteve is the Co-founder & CEO of Oxide Computer Company.  He previously was President & COO of Joyent, a cloud computing company acquired by Samsung.  Before that, he spent 10 years at Dell in a number of different roles. Links Referenced: Oxide Computer Company: https://oxide.computer/ On The Metal Podcast: https://oxide.computer/podcasts/on-the-metal TranscriptAnnouncer: Hello, and welcome to Screaming in the Cloud with your host, Chief Cloud Economist at The Duckbill Group, Corey Quinn. This weekly show features conversations with people doing interesting work in the world of cloud, thoughtful commentary on the state of the technical world, and ridiculous titles for which Corey refuses to apologize. This is Screaming in the Cloud.Corey: This episode is brought to us in part by our friends at RedHat. As your organization grows, so does the complexity of your IT resources. You need a flexible solution that lets you deploy, manage, and scale workloads throughout your entire ecosystem. The Red Hat Ansible Automation Platform simplifies the management of applications and services across your hybrid infrastructure with one platform. Look for it on the AWS Marketplace.Corey: Welcome to Screaming in the Cloud. I'm Corey Quinn. You know, I often say it—but not usually on the show—that Screaming in the Cloud is a podcast about the business of cloud, which is intentionally overbroad so that I can talk about basically whatever the hell I want to with whoever the hell I'd like. Today's guest is, in some ways of thinking, about as far in the opposite direction from Cloud as it's possible to go and still be involved in the digital world. Steve Tuck is the CEO at Oxide Computer Company. You know, computers, the things we all pretend aren't underpinning those clouds out there that we all use and pay by the hour, gigabyte, second-month-pound or whatever it works out to. Steve, thank you for agreeing to come back on the show after a couple years, and once again suffer my slings and arrows.Steve: Much appreciated. Great to be here. It has been a while. I was looking back, I think three years. This was like, pre-pandemic, pre-interest rates, pre… Twitter going totally sideways.Corey: And I have to ask to start with that, it feels, on some level, like toward the start of the pandemic, when everything was flying high and we'd had low interest rates for a decade, that there was a lot of… well, lunacy lurking around in the industry, my own business saw it, too. It turns out that not giving a shit about the AWS bill is in fact a zero interest rate phenomenon. And with all that money or concentrated capital sloshing around, people decided to do ridiculous things with it. I would have thought, on some level, that, “We're going to start a computer company in the Bay Area making computers,” would have been one of those, but given that we are a year into the correction, and things seem to be heading up into the right for you folks, that take was wrong. How'd I get it wrong?Steve: Well, I mean, first of all, you got part of it right, which is there were just a litany of ridiculous companies and projects and money being thrown in all directions at that time.Corey: An NFT of a computer. We're going to have one of those. That's what you're selling, right? Then you had to actually hard pivot to making the real thing.Steve: That's it. So, we might as well cut right to it, you know. This is—we went through the crypto phase. But you know, our—when we started the company, it was yes, a computer company. It's on the tin. It's definitely kind of the foundation of what we're building. But you know, we think about what a modern computer looks like through the lens of cloud.I was at a cloud computing company for ten years prior to us founding Oxide, so was Bryan Cantrill, CTO, co-founder. And, you know, we are huge, huge fans of cloud computing, which was an interesting kind of dichotomy. Instead of conversations when we were raising for Oxide—because of course, Sand Hill is terrified of hardware. And when we think about what modern computers need to look like, they need to be in support of the characteristics of cloud, and cloud computing being not that you're renting someone else's computers, but that you have fully programmable infrastructure that allows you to slice and dice, you know, compute and storage and networking however software needs. And so, what we set out to go build was a way for the companies that are running on-premises infrastructure—which, by the way, is almost everyone and will continue to be so for a very long time—access to the benefits of cloud computing. And to do that, you need to build a different kind of computing infrastructure and architecture, and you need to plumb the whole thing with software.Corey: There are a number of different ways to view cloud computing. And I think that a lot of the, shall we say, incumbent vendors over in the computer manufacturing world tend to sound kind of like dinosaurs, on some level, where they're always talking in terms of, you're a giant company and you already have a whole bunch of data centers out there. But one of the magical pieces of cloud is you can have a ridiculous idea at nine o'clock tonight and by morning, you'll have a prototype, if you're of that bent. And if it turns out it doesn't work, you're out, you know, 27 cents. And if it does work, you can keep going and not have to stop and rebuild on something enterprise-grade.So, for the small-scale stuff and rapid iteration, cloud providers are terrific. Conversely, when you wind up in the giant fleets of millions of computers, in some cases, there begin to be economic factors that weigh in, and for some on workloads—yes, I know it's true—going to a data center is the economical choice. But my question is, is starting a new company in the direction of building these things, is it purely about economics or is there a capability story tied in there somewhere, too?Steve: Yeah, it's actually economics ends up being a distant third, fourth, in the list of needs and priorities from the companies that we're working with. When we talk about—and just to be clear we're—our demographic, that kind of the part of the market that we are focused on are large enterprises, like, folks that are spending, you know, half a billion, billion dollars a year in IT infrastructure, they, over the last five years, have moved a lot of the use cases that are great for public cloud out to the public cloud, and who still have this very, very large need, be it for latency reasons or cost reasons, security reasons, regulatory reasons, where they need on-premises infrastructure in their own data centers and colo facilities, et cetera. And it is for those workloads in that part of their infrastructure that they are forced to live with enterprise technologies that are 10, 20, 30 years old, you know, that haven't evolved much since I left Dell in 2009. And, you know, when you think about, like, what are the capabilities that are so compelling about cloud computing, one of them is yes, what you mentioned, which is you have an idea at nine o'clock at night and swipe a credit card, and you're off and running. And that is not the case for an idea that someone has who is going to use the on-premises infrastructure of their company. And this is where you get shadow IT and 16 digits to freedom and all the like.Corey: Yeah, everyone with a corporate credit card winds up being a shadow IT source in many cases. If your processes as a company don't make it easier to proceed rather than doing it the wrong way, people are going to be fighting against you every step of the way. Sometimes the only stick you've got is that of regulation, which in some industries, great, but in other cases, no, you get to play Whack-a-Mole. I've talked to too many companies that have specific scanners built into their mail system every month looking for things that look like AWS invoices.Steve: [laugh]. Right, exactly. And so, you know, but if you flip it around, and you say, well, what if the experience for all of my infrastructure that I am running, or that I want to provide to my software development teams, be it rented through AWS, GCP, Azure, or owned for economic reasons or latency reasons, I had a similar set of characteristics where my development team could hit an API endpoint and provision instances in a matter of seconds when they had an idea and only pay for what they use, back to kind of corporate IT. And what if they were able to use the same kind of developer tools they've become accustomed to using, be it Terraform scripts and the kinds of access that they are accustomed to using? How do you make those developers just as productive across the business, instead of just through public cloud infrastructure?At that point, then you are in a much stronger position where you can say, you know, for a portion of things that are, as you pointed out, you know, more unpredictable, and where I want to leverage a bunch of additional services that a particular cloud provider has, I can rent that. And where I've got more persistent workloads or where I want a different economic profile or I need to have something in a very low latency manner to another set of services, I can own it. And that's where I think the real chasm is because today, you just don't—we take for granted the basic plumbing of cloud computing, you know? Elastic Compute, Elastic Storage, you know, networking and security services. And us in the cloud industry end up wanting to talk a lot more about exotic services and, sort of, higher-up stack capabilities. None of that basic plumbing is accessible on-prem.Corey: I also am curious as to where exactly Oxide lives in the stack because I used to build computers for myself in 2000, and it seems like having gone down that path a bit recently, yeah, that process hasn't really improved all that much. The same off-the-shelf components still exist and that's great. We always used to disparagingly call spinning hard drives as spinning rust in racks. You named the company Oxide; you're talking an awful lot about the Rust programming language in public a fair bit of the time, and I'm starting to wonder if maybe words don't mean what I thought they meant anymore. Where do you folks start and stop, exactly?Steve: Yeah, that's a good question. And when we started, we sort of thought the scope of what we were going to do and then what we were going to leverage was smaller than it has turned out to be. And by that I mean, man, over the last three years, we have hit a bunch of forks in the road where we had questions about do we take something off the shelf or do we build it ourselves. And we did not try to build everything ourselves. So, to give you a sense of kind of where the dotted line is, around the Oxide product, what we're delivering to customers is a rack-level computer. So, the minimum size comes in rack form. And I think your listeners are probably pretty familiar with this. But, you know, a rack is—Corey: You would be surprised. It's basically, what are they about seven feet tall?Steve: Yeah, about eight feet tall.Corey: Yeah, yeah. Seven, eight feet, weighs a couple 1000 pounds, you know, make an insulting joke about—Steve: Two feet wide.Corey: —NBA players here. Yeah, all kinds of these things.Steve: Yeah. And big hunk of metal. And in the cases of on-premises infrastructure, it's kind of a big hunk of metal hole, and then a bunch of 1U and 2U boxes crammed into it. What the hyperscalers have done is something very different. They started looking at, you know, at the rack level, how can you get much more dense, power-efficient designs, doing things like using a DC bus bar down the back, instead of having 64 power supplies with cables hanging all over the place in a rack, which I'm sure is what you're more familiar with.Corey: Tremendous amount of weight as well because you have the metal chassis for all of those 1U things, which in some cases, you wind up with, what, 46U in a rack, assuming you can even handle the cooling needs of all that.Steve: That's right.Corey: You have so much duplication, and so much of the weight is just metal separating one thing from the next thing down below it. And there are opportunities for massive improvement, but you need to be at a certain point of scale to get there.Steve: You do. You do. And you also have to be taking on the entire problem. You can't pick at parts of these things. And that's really what we found. So, we started at this sort of—the rack level as sort of the design principle for the product itself and found that that gave us the ability to get to the right geometry, to get as much CPU horsepower and storage and throughput and networking into that kind of chassis for the least amount of wattage required, kind of the most power-efficient design possible.So, it ships at the rack level and it ships complete with both our server sled systems in Oxide, a pair of Oxide switches. This is—when I talk about, like, design decisions, you know, do we build our own switch, it was a big, big, big question early on. We were fortunate even though we were leaning towards thinking we needed to go do that, we had this prospective early investor who was early at AWS and he had asked a very tough question that none of our other investors had asked to this point, which is, “What are you going to do about the switch?”And we knew that the right answer to an investor is like, “No. We're already taking on too much.” We're redesigning a server from scratch in, kind of, the mold of what some of the hyperscalers have learned, doing our own Root of Trust, we're doing our own operating system, hypervisor control plane, et cetera. Taking on the switch could be seen as too much, but we told them, you know, we think that to be able to pull through all of the value of the security benefits and the performance and observability benefits, we can't have then this [laugh], like, obscure third-party switch rammed into this rack.Corey: It's one of those things that people don't think about, but it's the magic of cloud with AWS's network, for example, it's magic. You can get line rate—or damn near it—between any two points, sustained.Steve: That's right.Corey: Try that in the data center, you wind into massive congestion with top-of-rack switches, where, okay, we're going to parallelize this stuff out over, you know, two dozen racks and we're all going to have them seamlessly transfer information between each other at line rate. It's like, “[laugh] no, you're not because those top-of-rack switches will melt and become side-of-rack switches, and then bottom-puddle-of-rack switches. It doesn't work that way.”Steve: That's right.Corey: And you have to put a lot of thought and planning into it. That is something that I've not heard a traditional networking vendor addressing because everyone loves to hand-wave over it.Steve: Well so, and this particular prospective investor, we told him, “We think we have to go build our own switch.” And he said, “Great.” And we said, “You know, we think we're going to lose you as an investor as a result, but this is what we're doing.” And he said, “If you're building your own switch, I want to invest.” And his comment really stuck with us, which is AWS did not stand on their own two feet until they threw out their proprietary switch vendor and built their own.And that really unlocked, like you've just mentioned, like, their ability, both in hardware and software to tune and optimize to deliver that kind of line rate capability. And that is one of the big findings for us as we got into it. Yes, it was really, really hard, but based on a couple of design decisions, P4 being the programming language that we are using as the surround for our silicon, tons of opportunities opened up for us to be able to do similar kinds of optimization and observability. And that has been a big, big win.But to your question of, like, where does it stop? So, we are delivering this complete with a baked-in operating system, hypervisor, control plane. And so, the endpoint of the system, where the customer meets is either hitting an API or a CLI or a console that delivers and kind of gives you the ability to spin up projects. And, you know, if one is familiar with EC2 and EBS and VPC, that VM level of abstraction is where we stop.Corey: That, I think, is a fair way of thinking about it. And a lot of cloud folks are going to pooh-pooh it as far as saying, “Oh well, just virtual machines. That's old cloud. That just treats the cloud like a data center.” And in many cases, yes, it does because there are ways to build modern architectures that are event-driven on top of things like Lambda, and API Gateway, and the rest, but you take a look at what my customers are doing and what drives the spend, it is invariably virtual machines that are largely persistent.Sometimes they scale up, sometimes they scale down, but there's always a baseline level of load that people like to hand-wave away the fact that what they're fundamentally doing in a lot of these cases, is paying the cloud provider to handle the care and feeding of those systems, which can be expensive, yes, but also delivers significant innovation beyond what almost any company is going to be able to deliver in-house. There is no way around it. AWS is better than you are—whoever you happen to—be at replacing failed hard drives. That is a simple fact. They have teams of people who are the best in the world of replacing failed hard drives. You generally do not. They are going to be better at that than you. But that's not the only axis. There's not one calculus that leads to, is cloud a scam or is cloud a great value proposition for us? The answer is always a deeply nuanced, “It depends.”Steve: Yeah, I mean, I think cloud is a great value proposition for most and a growing amount of software that's being developed and deployed and operated. And I think, you know, one of the myths that is out there is, hey, turn over your IT to AWS because we have or you know, a cloud provider—because we have such higher caliber personnel that are really good at swapping hard drives and dealing with networks and operationally keeping this thing running in a highly available manner that delivers good performance. That is certainly true, but a lot of the operational value in an AWS is been delivered via software, the automation, the observability, and not actual people putting hands on things. And it's an important point because that's been a big part of what we're building into the product. You know, just because you're running infrastructure in your own data center, it does not mean that you should have to spend, you know, 1000 hours a month across a big team to maintain and operate it. And so, part of that, kind of, cloud, hyperscaler innovation that we're baking into this product is so that it is easier to operate with much, much, much lower overhead in a highly available, resilient manner.Corey: So, I've worked in a number of data center facilities, but the companies I was working with, were always at a scale where these were co-locations, where they would, in some cases, rent out a rack or two, in other cases, they'd rent out a cage and fill it with their own racks. They didn't own the facilities themselves. Those were always handled by other companies. So, my question for you is, if I want to get a pile of Oxide racks into my environment in a data center, what has to change? What are the expectations?I mean, yes, there's obviously going to be power and requirements at the data center colocation is very conversant with, but Open Compute, for example, had very specific requirements—to my understanding—around things like the airflow construction of the environment that they're placed within. How prescriptive is what you've built, in terms of doing a building retrofit to start using you folks?Steve: Yeah, definitely not. And this was one of the tensions that we had to balance as we were designing the product. For all of the benefits of hyperscaler computing, some of the design center for you know, the kinds of racks that run in Google and Amazon and elsewhere are hyperscaler-focused, which is unlimited power, in some cases, data centers designed around the equipment itself. And where we were headed, which was basically making hyperscaler infrastructure available to, kind of, the masses, the rest of the market, these folks don't have unlimited power and they aren't going to go be able to go redesign data centers. And so no, the experience should be—with exceptions for folks maybe that have very, very limited access to power—that you roll this rack into your existing data center. It's on standard floor tile, that you give it power, and give it networking and go.And we've spent a lot of time thinking about how we can operate in the wide-ranging environmental characteristics that are commonplace in data centers that focus on themselves, colo facilities, and the like. So, that's really on us so that the customer is not having to go to much work at all to kind of prepare and be ready for it.Corey: One of the challenges I have is how to think about what you've done because you are rack-sized. But what that means is that my own experimentation at home recently with on-prem stuff for smart home stuff involves a bunch of Raspberries Pi and a [unintelligible 00:19:42], but I tend to more or less categorize you the same way that I do AWS Outposts, as well as mythical creatures, like unicorns or giraffes, where I don't believe that all these things actually exist because I haven't seen them. And in fact, to get them in my house, all four of those things would theoretically require a loading dock if they existed, and that's a hard thing to fake on a demo signup form, as it turns out. How vaporware is what you've built? Is this all on paper and you're telling amazing stories or do they exist in the wild?Steve: So, last time we were on, it was all vaporware. It was a couple of napkin drawings and a seed round of funding.Corey: I do recall you not using that description at the time, for what it's worth. Good job.Steve: [laugh]. Yeah, well, at least we were transparent where we were going through the race. We had some napkin drawings and we had some good ideas—we thought—and—Corey: You formalize those and that's called Microsoft PowerPoint.Steve: That's it. A hundred percent.Corey: The next generative AI play is take the scrunched-up, stained napkin drawing, take a picture of it, and convert it to a slide.Steve: Google Docs, you know, one of those. But no, it's got a lot of scars from the build and it is real. In fact, next week, we are going to be shipping our first commercial systems. So, we have got a line of racks out in our manufacturing facility in lovely Rochester, Minnesota. Fun fact: Rochester, Minnesota, is where the IBM AS/400s were built.Corey: I used to work in that market, of all things.Steve: Really?Corey: Selling tape drives in the AS/400. I mean, I still maintain there's no real mainframe migration to the cloud play because there's no AWS/400. A joke that tends to sail over an awful lot of people's heads because, you know, most people aren't as miserable in their career choices as I am.Steve: Okay, that reminds me. So, when we were originally pitching Oxide and we were fundraising, we [laugh]—in a particular investor meeting, they asked, you know, “What would be a good comp? Like how should we think about what you are doing?” And fortunately, we had about 20 investor meetings to go through, so burning one on this was probably okay, but we may have used the AS/400 as a comp, talking about how [laugh] mainframe systems did such a good job of building hardware and software together. And as you can imagine, there were some blank stares in that room.But you know, there are some good analogs to historically in the computing industry, when you know, the industry, the major players in the industry, were thinking about how to deliver holistic systems to support end customers. And, you know, we see this in the what Apple has done with the iPhone, and you're seeing this as a lot of stuff in the automotive industry is being pulled in-house. I was listening to a good podcast. Jim Farley from Ford was talking about how the automotive industry historically outsourced all of the software that controls cars, right? So, like, Bosch would write the software for the controls for your seats.And they had all these suppliers that were writing the software, and what it meant was that innovation was not possible because you'd have to go out to suppliers to get software changes for any little change you wanted to make. And in the computing industry, in the 80s, you saw this blow apart where, like, firmware got outsourced. In the IBM and the clones, kind of, race, everyone started outsourcing firmware and outsourcing software. Microsoft started taking over operating systems. And then VMware emerged and was doing a virtualization layer.And this, kind of, fragmented ecosystem is the landscape today that every single on-premises infrastructure operator has to struggle with. It's a kit car. And so, pulling it back together, designing things in a vertically integrated manner is what the hyperscalers have done. And so, you mentioned Outposts. And, like, it's a good example of—I mean, the most public cloud of public cloud companies created a way for folks to get their system on-prem.I mean, if you need anything to underscore the draw and the demand for cloud computing-like, infrastructure on-prem, just the fact that that emerged at all tells you that there is this big need. Because you've got, you know, I don't know, a trillion dollars worth of IT infrastructure out there and you have maybe 10% of it in the public cloud. And that's up from 5% when Jassy was on stage in '21, talking about 95% of stuff living outside of AWS, but there's going to be a giant market of customers that need to own and operate infrastructure. And again, things have not improved much in the last 10 or 20 years for them.Corey: They have taken a tone onstage about how, “Oh, those workloads that aren't in the cloud, yet, yeah, those people are legacy idiots.” And I don't buy that for a second because believe it or not—I know that this cuts against what people commonly believe in public—but company execs are generally not morons, and they make decisions with context and constraints that we don't see. Things are the way they are for a reason. And I promise that 90% of corporate IT workloads that still live on-prem are not being managed or run by people who've never heard of the cloud. There was a decision made when some other things were migrating of, do we move this thing to the cloud or don't we? And the answer at the time was no, we're going to keep this thing on-prem where it is now for a variety of reasons of varying validity. But I don't view that as a bug. I also, frankly, don't want to live in a world where all the computers are basically run by three different companies.Steve: You're spot on, which is, like, it does a total disservice to these smart and forward-thinking teams in every one of the Fortune 1000-plus companies who are taking the constraints that they have—and some of those constraints are not monetary or entirely workload-based. If you want to flip it around, we were talking to a large cloud SaaS company and their reason for wanting to extend it beyond the public cloud is because they want to improve latency for their e-commerce platform. And navigating their way through the complex layers of the networking stack at GCP to get to where the customer assets are that are in colo facilities, adds lag time on the platform that can cost them hundreds of millions of dollars. And so, we need to think behind this notion of, like, “Oh, well, the dark ages are for software that can't run in the cloud, and that's on-prem. And it's just a matter of time until everything moves to the cloud.”In the forward-thinking models of public cloud, it should be both. I mean, you should have a consistent experience, from a certain level of the stack down, everywhere. And then it's like, do I want to rent or do I want to own for this particular use case? In my vast set of infrastructure needs, do I want this to run in a data center that Amazon runs or do I want this to run in a facility that is close to this other provider of mine? And I think that's best for all. And then it's not this kind of false dichotomy of quality infrastructure or ownership.Corey: I find that there are also workloads where people will come to me and say, “Well, we don't think this is going to be economical in the cloud”—because again, I focus on AWS bills. That is the lens I view things through, and—“The AWS sales rep says it will be. What do you think?” And I look at what they're doing and especially if involves high volumes of data transfer, I laugh a good hearty laugh and say, “Yeah, keep that thing in the data center where it is right now. You will thank me for it later.”It's, “Well, can we run this in an economical way in AWS?” As long as you're okay with economical meaning six times what you're paying a year right now for the same thing, yeah, you can. I wouldn't recommend it. And the numbers sort of speak for themselves. But it's not just an economic play.There's also the story of, does this increase their capability? Does it let them move faster toward their business goals? And in a lot of cases, the answer is no, it doesn't. It's one of those business process things that has to exist for a variety of reasons. You don't get to reimagine it for funsies and even if you did, it doesn't advance the company in what they're trying to do any, so focus on something that differentiates as opposed to this thing that you're stuck on.Steve: That's right. And what we see today is, it is easy to be in that mindset of running things on-premises is kind of backwards-facing because the experience of it is today still very, very difficult. I mean, talking to folks and they're sharing with us that it takes a hundred days from the time all the different boxes land in their warehouse to actually having usable infrastructure that developers can use. And our goal and what we intend to go hit with Oxide as you can roll in this complete rack-level system, plug it in, within an hour, you have developers that are accessing cloud-like services out of the infrastructure. And that—God, countless stories of firmware bugs that would send all the fans in the data center nonlinear and soak up 100 kW of power.Corey: Oh, God. And the problems that you had with the out-of-band management systems. For a long time, I thought Drax stood for, “Dell, RMA Another Computer.” It was awful having to deal with those things. There was so much room for innovation in that space, which no one really grabbed onto.Steve: There was a really, really interesting talk at DEFCON that we just stumbled upon yesterday. The NVIDIA folks are giving a talk on BMC exploits… and like, a very, very serious BMC exploit. And again, it's what most people don't know is, like, first of all, the BMC, the Baseboard Management Controller, is like the brainstem of the computer. It has access to—it's a backdoor into all of your infrastructure. It's a computer inside a computer and it's got software and hardware that your server OEM didn't build and doesn't understand very well.And firmware is even worse because you know, firmware written by you know, an American Megatrends or other is a big blob of software that gets loaded into these systems that is very hard to audit and very hard to ascertain what's happening. And it's no surprise when, you know, back when we were running all the data centers at a cloud computing company, that you'd run into these issues, and you'd go to the server OEM and they'd kind of throw their hands up. Well, first they'd gaslight you and say, “We've never seen this problem before,” but when you thought you've root-caused something down to firmware, it was anyone's guess. And this is kind of the current condition today. And back to, like, the journey to get here, we kind of realized that you had to blow away that old extant firmware layer, and we rewrote our own firmware in Rust. Yes [laugh], I've done a lot in Rust.Corey: No, it was in Rust, but, on some level, that's what Nitro is, as best I can tell, on the AWS side. But it turns out that you don't tend to have the same resources as a one-and-a-quarter—at the moment—trillion-dollar company. That keeps [valuing 00:30:53]. At one point, they lost a comma and that was sad and broke all my logic for that and I haven't fixed it since. Unfortunate stuff.Steve: Totally. I think that was another, kind of, question early on from certainly a lot of investors was like, “Hey, how are you going to pull this off with a smaller team and there's a lot of surface area here?” Certainly a reasonable question. Definitely was hard. The one advantage—among others—is, when you are designing something kind of in a vertical holistic manner, those design integration points are narrowed down to just your equipment.And when someone's writing firmware, when AMI is writing firmware, they're trying to do it to cover hundreds and hundreds of components across dozens and dozens of vendors. And we have the advantage of having this, like, purpose-built system, kind of, end-to-end from the lowest level from first boot instruction, all the way up through the control plane and from rack to switch to server. That definitely helped narrow the scope.Corey: This episode has been fake sponsored by our friends at AWS with the following message: Graviton Graviton, Graviton, Graviton, Graviton, Graviton, Graviton, Graviton, Graviton. Thank you for your l-, lack of support for this show. Now, AWS has been talking about Graviton an awful lot, which is their custom in-house ARM processor. Apple moved over to ARM and instead of talking about benchmarks they won't publish and marketing campaigns with words that don't mean anything, they've let the results speak for themselves. In time, I found that almost all of my workloads have moved over to ARM architecture for a variety of reason, and my laptop now gets 15 hours of battery life when all is said and done. You're building these things on top of x86. What is the deal there? I do not accept that if that you hadn't heard of ARM until just now because, as mentioned, Graviton, Graviton, Graviton.Steve: That's right. Well, so why x86, to start? And I say to start because we have just launched our first generation products. And our first-generation or second-generation products that we are now underway working on are going to be x86 as well. We've built this system on AMD Milan silicon; we are going to be launching a Genoa sled.But when you're thinking about what silicon to use, obviously, there's a bunch of parts that go into the decision. You're looking at the kind of applicability to workload, performance, power management, for sure, and if you carve up what you are trying to achieve, x86 is still a terrific fit for the broadest set of workloads that our customers are trying to solve for. And choosing which x86 architecture was certainly an easier choice, come 2019. At this point, AMD had made a bunch of improvements in performance and energy efficiency in the chip itself. We've looked at other architectures and I think as we are incorporating those in the future roadmap, it's just going to be a question of what are you trying to solve for.You mentioned power management, and that is kind of commonly been a, you know, low power systems is where folks have gone beyond x86. Is we're looking forward to hardware acceleration products and future products, we'll certainly look beyond x86, but x86 has a long, long road to go. It still is kind of the foundation for what, again, is a general-purpose cloud infrastructure for being able to slice and dice for a variety of workloads.Corey: True. I have to look around my environment and realize that Intel is not going anywhere. And that's not just an insult to their lack of progress on committed roadmaps that they consistently miss. But—Steve: [sigh].Corey: Enough on that particular topic because we want to keep this, you know, polite.Steve: Intel has definitely had some struggles for sure. They're very public ones, I think. We were really excited and continue to be very excited about their Tofino silicon line. And this came by way of the Barefoot networks acquisition. I don't know how much you had paid attention to Tofino, but what was really, really compelling about Tofino is the focus on both hardware and software and programmability.So, great chip. And P4 is the programming language that surrounds that. And we have gotten very, very deep on P4, and that is some of the best tech to come out of Intel lately. But from a core silicon perspective for the rack, we went with AMD. And again, that was a pretty straightforward decision at the time. And we're planning on having this anchored around AMD silicon for a while now.Corey: One last question I have before we wind up calling it an episode, it seems—at least as of this recording, it's still embargoed, but we're not releasing this until that winds up changing—you folks have just raised another round, which means that your napkin doodles have apparently drawn more folks in, and now that you're shipping, you're also not just bringing in customers, but also additional investor money. Tell me about that.Steve: Yes, we just completed our Series A. So, when we last spoke three years ago, we had just raised our seed and had raised $20 million at the time, and we had expected that it was going to take about that to be able to build the team and build the product and be able to get to market, and [unintelligible 00:36:14] tons of technical risk along the way. I mean, there was technical risk up and down the stack around this [De Novo 00:36:21] server design, this the switch design. And software is still the kind of disproportionate majority of what this product is, from hypervisor up through kind of control plane, the cloud services, et cetera. So—Corey: We just view it as software with a really, really confusing hardware dongle.Steve: [laugh]. Yeah. Yes.Corey: Super heavy. We're talking enterprise and government-grade here.Steve: That's right. There's a lot of software to write. And so, we had a bunch of milestones that as we got through them, one of the big ones was getting Milan silicon booting on our firmware. It was funny it was—this was the thing that clearly, like, the industry was most suspicious of, us doing our own firmware, and you could see it when we demonstrated booting this, like, a year-and-a-half ago, and AMD all of a sudden just lit up, from kind of arm's length to, like, “How can we help? This is amazing.” You know? And they could start to see the benefits of when you can tie low-level silicon intelligence up through a hypervisor there's just—Corey: No I love the existing firmware I have. Looks like it was written in 1984 and winds up having terrible user ergonomics that hasn't been updated at all, and every time something comes through, it's a 50/50 shot as whether it fries the box or not. Yeah. No, I want that.Steve: That's right. And you look at these hyperscale data centers, and it's like, no. I mean, you've got intelligence from that first boot instruction through a Root of Trust, up through the software of the hyperscaler, and up to the user level. And so, as we were going through and kind of knocking down each one of these layers of the stack, doing our own firmware, doing our own hardware Root of Trust, getting that all the way plumbed up into the hypervisor and the control plane, number one on the customer side, folks moved from, “This is really interesting. We need to figure out how we can bring cloud capabilities to our data centers. Talk to us when you have something,” to, “Okay. We actually”—back to the earlier question on vaporware, you know, it was great having customers out here to Emeryville where they can put their hands on the rack and they can, you know, put your hands on software, but being able to, like, look at real running software and that end cloud experience.And that led to getting our first couple of commercial contracts. So, we've got some great first customers, including a large department of the government, of the federal government, and a leading firm on Wall Street that we're going to be shipping systems to in a matter of weeks. And as you can imagine, along with that, that drew a bunch of renewed interest from the investor community. Certainly, a different climate today than it was back in 2019, but what was great to see is, you still have great investors that understand the importance of making bets in the hard tech space and in companies that are looking to reinvent certain industries. And so, we added—our existing investors all participated. We added a bunch of terrific new investors, both strategic and institutional.And you know, this capital is going to be super important now that we are headed into market and we are beginning to scale up the business and make sure that we have a long road to go. And of course, maybe as importantly, this was a real confidence boost for our customers. They're excited to see that Oxide is going to be around for a long time and that they can invest in this technology as an important part of their infrastructure strategy.Corey: I really want to thank you for taking the time to speak with me about, well, how far you've come in a few years. If people want to learn more and have the requisite loading dock, where should they go to find you?Steve: So, we try to put everything up on the site. So, oxidecomputer.com or oxide.computer. We also, if you remember, we did [On the Metal 00:40:07]. So, we had a Tales from the Hardware-Software Interface podcast that we did when we started. We have shifted that to Oxide and Friends, which the shift there is we're spending a little bit more time talking about the guts of what we built and why. So, if folks are interested in, like, why the heck did you build a switch and what does it look like to build a switch, we actually go to depth on that. And you know, what does bring-up on a new server motherboard look like? And it's got some episodes out there that might be worth checking out.Corey: We will definitely include a link to that in the [show notes 00:40:36]. Thank you so much for your time. I really appreciate it.Steve: Yeah, Corey. Thanks for having me on.Corey: Steve Tuck, CEO at Oxide Computer Company. I'm Cloud Economist Corey Quinn, and this is Screaming in the Cloud. If you've enjoyed this podcast, please leave a five-star review on your podcast platform of choice, whereas if you've hated this episode, please leave a five-star review on your podcast platform of choice, along with an angry ranting comment because you are in fact a zoology major, and you're telling me that some animals do in fact exist. But I'm pretty sure of the two of them, it's the unicorn.Corey: If your AWS bill keeps rising and your blood pressure is doing the same, then you need The Duckbill Group. We help companies fix their AWS bill by making it smaller and less horrifying. The Duckbill Group works for you, not AWS. We tailor recommendations to your business and we get to the point. Visit duckbillgroup.com to get started.

Our 72nd weekly NFT livestream. This week we DCA with Derp Birds Founder, Dave. Tune in. Or we cut it off. F35 Merch is LIVE NOW

 It's been said that all politics is local. Given the unique nature of major population centers everywhere, the same could be said for transportation. 

If you're reading this drop a Comment below

If you think colonialism ended after the Second World War, then my latest conversation may surprise you. Simon Winchester joins me to talk about Tristan da Cunha, hiding under a bed in the Falklands, and how he bluffed his way into the world's most notorious military base. Outposts: Journeys to the Surviving Relics of the British Empire was first published in 1985, and is still in print. It's one of the 5 or 6 books I had in mind when I started the Personal Landscapes podcast, and it remains one of my favourite books about place.  

Bogies in the Storm ep.638 A fighter pilot is sent into a storm, but finds more than he expected. Michael D. Burnside is a graduate of Ohio University. By day, he earns a living as a systems analyst, helping customers figure out what they need from their software. His interests include gaming, science, computer technology, history, politics, and, of course, writing. His fiction writing includes steampunk, science fiction, fantasy, and horror. His stories have been featured in multiple anthologies, including Fossil Lake: An Anthology of the Aberrant, Fossil Lake II: The Refossiling, Beautiful Lies, Painful Truths Vol. II, and Ink Stains Vol. 8. His short stories have also been featured in magazines such as Devolution Z, Outposts of Beyond, and Gathering Storm Magazine. One of his latest stories, “The Devil of Greystern Castle,” appears in the Spring 2023 edition of Dragon Gems. Michael lives in Dayton, Ohio, with his wife and lots of cats. Read more nice things about him, as well as some free stories, at www.michaelburnside.com.   ---- Listen Elsewhere ---- YouTube:  https://www.youtube.com/c/TallTaleTV Website: http://www.TallTaleTV.com   ---- Story Submission ---- Got a short story you'd like to submit? Submission guidelines can be found at http://www.TallTaleTV.com   ---- About Tall Tale TV ---- Hi there! My name is Chris Herron and I'm an audiobook narrator. In 2015, I suffered from poor Type 1 diabetes control which lead me to become legally blind for almost a year. The doctors didn't give me much hope, predicting an 80% chance that I would never see again. But I refused to give up and changed my lifestyle drastically. Through sheer willpower (and an amazing eye surgeon) I beat the odds and regained my vision. During that difficult time, I couldn't read or write, which was devastating as they had always been a source of comfort for me since childhood. However, my wife took me to the local library where she read out the titles of audiobooks to me. I selected some of my favorite books, such as the Disc World series, Name of the Wind, Harry Potter, and more, and the audiobooks brought these stories to life in a way I had never experienced before. They helped me through the darkest period of my life and I fell in love with audiobooks. Once I regained my vision, I decided to pursue a career as an audiobook narrator instead of a writer. That's why I created Tall Tale TV, to support aspiring authors in the writing communities that I had grown to love before my ordeal. My goal was to help them promote their work by providing a promotional audio short story that showcases their writing skills to readers. They say the strongest form of advertising is word of mouth, so I offer a platform for readers to share these videos and help spread the word about these talented writers. Please consider sharing these stories with your friends and family to support these amazing authors. Thank you!   ---- legal ---- All stories on Tall Tale TV have been submitted in accordance with the terms of service provided on http://www.talltaletv.com or obtained with permission by the author. All images used on Tall Tale TV are either original or Royalty and Attribution free. Most stock images used are provided by http://www.pixabay.com , https://www.canstockphoto.com/ or created using AI. Image attribution will be declared only when required by the copyright owner. Common Affiliates are: Amazon, Smashwords

In the Bible, God frequently uses military terms to describe the Christian life. Learn how God's Work is organized as a spiritual military operation. “How Secure Is Your Outpost?”

Welcome to season 7 of Being Known Podcast were we are continually looking at what it means to be truly known. This season we are exploring confessional communities.   We have shared a great deal about confessional communities over the last several seasons on Being Known Podcast. We thought we would take this opportunity to dive in and take a closer look at their purpose and how they operate. Although the best way to discover these things is to actually participate in a confessional community, however, we  hope this season gets you a little closer to what it means—and what it takes—to be part of one.   . . . . Episode Links and References Genesis 1-2 Luke 24: The Road to Emmaus John 20: Thomas's encounter with Jesus Artistic offering - Carravaggio: Thomas The Center for Being Known New Story Behavioral Health   . . . . . Special Thanks for our Season Sponsor - Compassion International The world is currently facing a devastating global food crisis caused from numerous variables: the war in Ukraine, fertilizer shortages, effects of COVID-19, and extreme weather, just to name a few. Couple any of these with the fact that food prices are climbing, and hunger and malnutrition in vulnerable children intensify.   During this season of Being Known Podcast you can support Compassion International with a one time gift of $50 and you'll feed a family of five for a month. We are all part of a global community and hope you will consider giving.    . . . . . Stay connected: Instagram, Facebook, Twitter YouTube (Unedited videos of each episode AND the Post Show Conversations.) Please subscribe to the podcast so you never miss an episode and we always welcome your reviews on Apple Podcasts.  Sign up to access the Being Known Podcast applications, the weekly exercises that connect what you are learning to your life in a practical way. 

CreepGeeks Podcast Episode 278 INTRO  You're listening to CreepGeeks Podcast! This is Season 7 Episode 278 Haunted Mansion, The Giant Leech, The Bear Man, Holy Spirit Board and Walmarts are Outposts?  Your favorite anomalous podcast hosts Greg and Omi Want to Support the podcast? Join us on Patreon:  CreepGeeks Paranormal and Weird News is creating Humorous Paranormal Podcasts, Interviews, and Videos!  What is the CreepGeeks Paranormal and Weird News Podcast?  We broadcast paranormal news and share our strange experiences from our underground bunker in the mountains of Western North Carolina. Get our new Swag in our Amazon Merch Store: https://amzn.to/3IWwM1x  Hey Everyone, You can call the show and leave us a message!  1-575-208-4025 Use Amazon Prime Free Trial! Did you know YOU can support the CreepGeeks Podcast with little to no effort? Won't cost you anything!  When you shop on Amazon.com use our affiliate link and we get a small percentage!  It doesn't change your price at all. It helps us to keep the coffee flowing and gas in the Albino Rhino!  CreepGeeks Podcast is an Amazon Affiliate CheapGeek and CreepGeeks Amazon Page's Amazon Page    We've got Bigfoot Coffee! Support the Show: CreepGeeks Swag Shop!  Website- CREEPGEEKS PARANORMAL AND WEIRD NEWS Hey everyone! Help us out!  Rate us on iTunes!  ‎CreepGeeks Paranormal and Weird News Podcast on Apple  https://www.smalltownmonsters.com/  WARNING: This Podcast May Contain BioEginneered Food Products Haunted Mansion Movie: Haunted Mansion director avoided remaking any of the original movie  Cherokee Lore  The Giant Leech, Murphy NC. The Giant Leech | North Carolina Ghosts  Little Bubby Child Reference: https://www.facebook.com/lilbubbychild/posts/pfbid03PR3hDvdT7dtZcRC68mQLn8j8ZCv97URqo7ytyuowpcRUTFeL5GxhVEsMF391Wepl  The Bear Man The Bear Man - A Cherokee Legend.  The Holy Spirit Board- *Unlike other spirit boards, this one will NEVER contact evil ghosts or demons, so you can ask your questions with an assured sense of safety. https://amzn.to/3MOh7DM  News: Walmarts are Military Outposts? https://www.tiktok.  Fact Brief : Are Walmart locations actually military bases that are interconnected by underground tunnels? | Gigafact  NEWS:  The Mystery of Dowsing: Skepticism vs. Science  AD- Want to Start your own podcast? https://signup.libsyn.com/?promo_code=CREEP  Looking for something unique and spooky? Check out Omi's new Etsy, CraftedIntent: CraftedIntent: Simultaneously BeSpoke and Spooky. by CraftedIntent  Want CreepGeeks Paranormal Investigator stickers? Check them out here: CraftedIntent - Etsy  Check out Omi's new Lucky Crystal Skull Creations:  Lucky Crystal Skull: Random Mini Resin Skull With Gemstones - Etsy  Get Something From Amazon Prime! CheapGeek and CreepGeeks Amazon Page's Amazon Page     Cool Stuff on Amazon -Squatch Metalworks Microsquatch Keychain:  Microsquatch Keychain Bottle Opener with Carabiner. Laser-cut, stone-tumbled stainless steel. DESIGNED AND MANUFACTURED IN THE USA.  Amazon Influencer!  CheapGeek and CreepGeeks Amazon Page's Amazon Page   Instagram?  Creep Geeks Podcast (@creepgeekspod) • Instagram photos and videos   Omi Salavea (@craftedintent) • Instagram photos and videos  CreepGeeks Podcast (@creepgeekspodcast) TikTok | Watch CreepGeeks Podcast's Newest TikTok Videos  Need to Contact Us? Email Info: contact@creepgeeks.com  Attn Greg or Omi  Want to comment about the show? omi@creepgeeks.com   greg@creepgeeks.com   Business Inquiries: contact@creepgeeks.com   CreepGeeks Podcast Store   Music: Music is Officially Licensed through Audiio.com. License available upon request. #podcast #paranormal #creepgeeks Tags:   Asheville nc, nc cryptids, creepgeeks, paranormal podcast, ghost, ghost, creepy,   

JOHN GUANDOLO, Founder, UnderstandingtheThreat.com An increased number of Chinese nationals coming across the southern border China's approach to warfare compared to the United States Has the U.S. counterintelligence system deteriorated recently? The "largest public corruption matter" in American history "Outposts" for the Islamic State within the U.S. The need for a "deep house cleaning" in the U.S. military  

The end of 2022 and beginning of 2023 were marked by centralised institutions failing: from CEXes to CeFi itself, contagion spread quickly in over-leveraged and opaque entities. Amidst this chaos, (crypto)people turned their hopes, once again, to DeFi. However, in lack of traditional enforcing mechanisms, not even battle-tested decentralised lending protocols could find a solution to provide under-collateralised loans, aka credit. Mars Protocol, with its unique hub & outposts architecture, aims to answer this need in the Cosmos ecosystem, by deploying on Osmosis and tapping into its deep liquidity. From manual leverage to credit and yield farming, Mars will feature a wide suite of DeFi products.We were joined by Jose Macedo, founder of Delphi Labs, to discuss the history of Delphi Digital, their learnings from incubating projects and the vision behind Mars' ‘Red Bank' DeFi products.Topics covered in this episode:Jose's backgroundDelphi Digital's historyIncubating projects on Solana and TerraLearning from TerraThe vision behind Mars ProtocolMars' DeFi suiteDifferent risk parameters and collateralsMars' module architecture (outposts) in the Cosmos ecosystemHow Mars Protocol differs from OsmosisMars Protocol roadmap & Mars v.2Ecosystem acceleratorEpisode links: Jose Macedo on TwitterDelphi Labs on TwitterDelphi Digital on TwitterMars Protocol on TwitterAstroport on TwitterOsmosis on TwitterThis episode is hosted by Brian Fabian Crain & Felix Lutsch. Show notes and listening options: epicenter.tv/493

On today's Day Two Cloud podcast, we speak with Jan Hofmeyr, a VP within Amazon Web Services (AWS). This show was recorded at AWS re:Invent 2022 in Las Vegas, and we discuss EC2 at the edge, AWS Outposts and how local zones work, connecting Outposts to the AWS cloud, and more.

On today's Day Two Cloud podcast, we speak with Jan Hofmeyr, a VP within Amazon Web Services (AWS). This show was recorded at AWS re:Invent 2022 in Las Vegas, and we discuss EC2 at the edge, AWS Outposts and how local zones work, connecting Outposts to the AWS cloud, and more. The post Day Two Cloud 180: Understanding AWS EC2 At The Edge appeared first on Packet Pushers.