<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/"><channel><title>App Engine on Brave New Geek</title><link>https://bravenewgeek.com/tag/app-engine/</link><description>Recent content in App Engine on Brave New Geek</description><generator>Hugo</generator><language>en-us</language><lastBuildDate>Mon, 22 Jun 2020 14:58:00 -0500</lastBuildDate><atom:link href="https://bravenewgeek.com/tag/app-engine/index.xml" rel="self" type="application/rss+xml"/><item><title>Zero-Trust Security on GCP With Context-Aware Access</title><link>https://bravenewgeek.com/zero-trust-security-on-gcp-with-context-aware-access/</link><pubDate>Mon, 22 Jun 2020 14:54:15 -0500</pubDate><guid>https://bravenewgeek.com/zero-trust-security-on-gcp-with-context-aware-access/</guid><description>&lt;p&gt;A lot of our clients at Real Kinetic leverage &lt;a href="https://blog.realkinetic.com/serverless-on-gcp-183fd811a706"&gt;serverless on GCP&lt;/a&gt; to quickly build applications with minimal operations overhead. Serverless is one of the things that truly &lt;a href="https://blog.realkinetic.com/gcp-and-aws-whats-the-difference-3b1329f0ffb3"&gt;differentiates GCP&lt;/a&gt; from other cloud providers, and &lt;a href="https://blog.realkinetic.com/why-google-app-engine-9c3d2f75dd02"&gt;App Engine&lt;/a&gt; is a big component of this. Many of these companies come from an on-prem world and, as a result, tend to favor perimeter-based security models. They rely heavily on things like IP and network restrictions, VPNs, corporate intranets, and so forth. Unfortunately, this type of security model doesn’t always fit nicely with serverless due to the elastic and dynamic nature of serverless systems.&lt;/p&gt;</description></item><item><title>Serverless on GCP</title><link>https://bravenewgeek.com/serverless-on-gcp/</link><pubDate>Tue, 20 Aug 2019 10:04:48 -0500</pubDate><guid>https://bravenewgeek.com/serverless-on-gcp/</guid><description>&lt;p&gt;Like many other marketing buzzwords, the concept of “serverless” has taken on a life of its own, which can make it difficult to understand what serverless actually &lt;em&gt;means&lt;/em&gt;. What it really means is that the cloud provider fully manages server infrastructure all the way up to the application layer. For example, GCE isn’t serverless because, while Google manages the &lt;em&gt;physical&lt;/em&gt; server infrastructure, we still have to deal with patching operating systems, managing load balancers, configuring firewall rules, and so on. Serverless means we merely worry about our application code and business logic and nothing else. This concept extends beyond pure compute though, including things like databases, message queues, stream processing, machine learning, and other types of systems.&lt;/p&gt;</description></item><item><title>Authenticating Stackdriver Uptime Checks for Identity-Aware Proxy</title><link>https://bravenewgeek.com/authenticating-stackdriver-uptime-checks-for-identity-aware-proxy/</link><pubDate>Tue, 29 Jan 2019 14:46:43 -0600</pubDate><guid>https://bravenewgeek.com/authenticating-stackdriver-uptime-checks-for-identity-aware-proxy/</guid><description>&lt;p&gt;&lt;a href="https://cloud.google.com/stackdriver/"&gt;Google Stackdriver&lt;/a&gt; provides a set of tools for monitoring and managing services running in GCP, AWS, or on-prem infrastructure. One feature Stackdriver has is “uptime checks,” which enable you to verify the availability of your service and track response latencies over time from up to six different geographic locations around the world. While Stackdriver uptime checks are not as feature-rich as other similar products such as &lt;a href="https://www.pingdom.com/"&gt;Pingdom&lt;/a&gt;, they are also completely &lt;em&gt;free&lt;/em&gt;. For GCP users, this provides a great starting point for quickly setting up health checks and alerting for your applications.&lt;/p&gt;</description></item><item><title>API Authentication with GCP Identity-Aware Proxy</title><link>https://bravenewgeek.com/api-authentication-with-gcp-identity-aware-proxy/</link><pubDate>Fri, 25 Jan 2019 11:21:53 -0600</pubDate><guid>https://bravenewgeek.com/api-authentication-with-gcp-identity-aware-proxy/</guid><description>&lt;p&gt;&lt;a href="https://cloud.google.com/iap/"&gt;Cloud Identity-Aware Proxy (Cloud IAP)&lt;/a&gt; is a free service which can be used to implement authentication and authorization for applications running in Google Cloud Platform (GCP). This includes &lt;a href="https://cloud.google.com/appengine/"&gt;Google App Engine&lt;/a&gt; applications as well as workloads running on &lt;a href="https://cloud.google.com/compute/"&gt;Compute Engine (GCE)&lt;/a&gt; VMs and &lt;a href="https://cloud.google.com/kubernetes-engine/"&gt;Google Kubernetes Engine (GKE)&lt;/a&gt; by way of &lt;a href="https://blog.realkinetic.com/http-to-https-using-google-cloud-load-balancer-dda57ac97c"&gt;Google Cloud Load Balancers&lt;/a&gt;.&lt;/p&gt;
&lt;p&gt;When enabled, IAP requires users accessing a web application to login using their Google account and ensure they have the appropriate role to access the resource. This can be used to provide secure access to web applications without the need for a VPN. This is part of what Google now calls &lt;a href="https://cloud.google.com/beyondcorp/"&gt;BeyondCorp&lt;/a&gt;, which is an enterprise security model designed to enable employees to work from untrusted networks without a VPN. At Real Kinetic, we frequently bump into companies practicing &lt;a href="https://www.onelogin.com/blog/the-death-star-a-lesson-in-cybersecurity"&gt;Death-Star security&lt;/a&gt;, which is basically relying on a hard outer shell to protect a soft, gooey interior. It’s simple and easy to administer, but it’s also vulnerable. That’s why we always approach security from a perspective of &lt;a href="https://en.wikipedia.org/wiki/Defense_in_depth_(computing)"&gt;&lt;em&gt;defense in depth&lt;/em&gt;&lt;/a&gt;.&lt;/p&gt;</description></item><item><title>More Environments Will Not Make Things Easier</title><link>https://bravenewgeek.com/more-environments-will-not-make-things-easier/</link><pubDate>Wed, 11 Apr 2018 15:49:47 -0500</pubDate><guid>https://bravenewgeek.com/more-environments-will-not-make-things-easier/</guid><description>&lt;p&gt;Microservices are &lt;a href="https://bravenewgeek.com/service-disoriented-architecture/"&gt;hard&lt;/a&gt;. They require extreme discipline. They require a lot more upfront thinking. They introduce integration challenges and complexity that you otherwise wouldn’t have with a monolith, but service-oriented design is an important part of scaling organization structure. Hundreds of engineers all working on the same codebase will only lead to angst and the inability to be nimble.&lt;/p&gt;
&lt;p&gt;This requires a pretty significant change in the way we think about things. We’re creatures of habit, so if we’re not careful, we’ll just keep on applying the same practices we used before we did services. And that will end in frustration.&lt;/p&gt;</description></item><item><title>There and Back Again: Why PaaS Is Passé (And Why It’s Not)</title><link>https://bravenewgeek.com/there-and-back-again-why-paas-is-passe-and-why-its-not/</link><pubDate>Tue, 06 Feb 2018 16:26:31 -0600</pubDate><guid>https://bravenewgeek.com/there-and-back-again-why-paas-is-passe-and-why-its-not/</guid><description>&lt;p&gt;In 10 years nobody will be talking about Kubernetes. Not because people stopped using it or because it fell out of favor, but because it became utility. Containers, Kubernetes, service meshes—they’ll all be there, the same way VMs, hypervisors, and switches will be. Compute is a commodity, and I don’t care how my workload runs so long as it meets my business’s SLOs and other requirements. Within AWS alone, there are now &lt;em&gt;innumerable&lt;/em&gt; ways to run a compute workload.&lt;/p&gt;</description></item><item><title>So You Wanna Go Fast?</title><link>https://bravenewgeek.com/so-you-wanna-go-fast/</link><pubDate>Wed, 24 Feb 2016 19:30:14 -0600</pubDate><guid>https://bravenewgeek.com/so-you-wanna-go-fast/</guid><description>&lt;p&gt;I originally proposed this as a &lt;a href="https://www.gophercon.com/"&gt;GopherCon&lt;/a&gt; talk on writing “high-performance Go”, which is why it may seem rambling, incoherent, and—at times—not at all related to Go. The talk was rejected (probably because of the rambling and incoherence), but I still think it’s a subject worth exploring. The good news is, since it was rejected, I can take this where I want. The remainder of this piece is mostly the outline of that talk with some parts filled in, some meandering stories which may or may not pertain to the topic, and some lessons learned along the way. I think it might make a good talk one day, but this will have to do for now.&lt;/p&gt;</description></item><item><title>If State Is Hell, SOA Is Satan</title><link>https://bravenewgeek.com/if-state-is-hell-soa-is-satan/</link><pubDate>Sun, 08 Mar 2015 12:33:18 -0600</pubDate><guid>https://bravenewgeek.com/if-state-is-hell-soa-is-satan/</guid><description>&lt;p&gt;More and more companies are describing their &lt;a href="http://nginx.com/blog/microservices-at-netflix-architectural-best-practices/"&gt;success stories&lt;/a&gt; regarding the switch to a service-oriented architecture. As with any technological upswing, there’s a clear and palpable hype factor involved (Big Data™ or The Cloud™ anyone?), but obviously it’s not just puff.&lt;/p&gt;
&lt;p&gt;While microservices and SOA have seen a staggering &lt;a href="http://www.enterprisecioforum.com/en/blogs/enadhan/secrets-behind-rapid-growth-soa"&gt;rate of adoption&lt;/a&gt; in recent years, the mindset of developers often seems to be stuck in the past. I think this is, at least in part, because we seek a mental model we can reason about. It’s why we build abstractions in the first place. In a sense, I would argue there’s a comparison to be made between the explosion of OOP in the early 90’s and today’s SOA trend. After all, &lt;strong&gt;SOA is as much about people scale as it is about workload scale&lt;/strong&gt;, so it makes sense from an organizational perspective.&lt;/p&gt;</description></item><item><title>Understanding Consensus</title><link>https://bravenewgeek.com/understanding-consensus/</link><pubDate>Wed, 24 Sep 2014 21:35:07 -0600</pubDate><guid>https://bravenewgeek.com/understanding-consensus/</guid><description>&lt;p&gt;A classical problem presented within the field of distributed systems is the &lt;a href="http://en.wikipedia.org/wiki/Two_Generals'_Problem"&gt;Byzantine Generals Problem&lt;/a&gt;. In it, we observe two allied armies positioned on either side of a valley. Within the valley is a fortified city. Each army has a general with one acting as commander. Both armies &lt;em&gt;must&lt;/em&gt; attack at the same time or face defeat by the city’s defenders. In order to come to an agreement on when to attack, messengers must be sent through the valley, risking capture by the city’s patrols. Consider the diagram below illustrating this problem.&lt;/p&gt;</description></item></channel></rss>