Richard Seroter's Architecture Musings

Author: Richard Seroter

  • 2020 in Review: Watching, Reading, and Writing Highlights

    2020, amiright? It was tragic for some, disruptive to most, and weird for all. But all things considered—and I honestly feel guilty saying this—it was a good year for me. Everyone close to me stayed relatively healthy, I sincerely enjoyed being home with my family and getting closer to them, I read and wrote more than I had in years, work was meaningful and enjoyable, and I more intentionally invested in myself and others. While I desperately missed seeing my family, friends, and co-workers in person, I have little to complain about.

    Everyone coped in different ways this year. There’s no right or wrong way. For whatever reason, I was more productive. I wrote twice as many blog posts as usual, created three Pluralsight courses, expanded the InfoQ cloud editorial team, showed up on some podcasts, spoke at a few online events, started working and building a team at Google Cloud, and read double the number of books as I did last year. Below are the best things I watched, wrote, and read in 2020.

    Things I Watched

    This was the sort of year where it was easy to watch a LOT of shows—streaming or otherwise. I tried to keep from falling down the Netflix wormhole, and mainly watched TV during the lunch hour. Some of the best things I streamed were:

    Schitt’s Creek – Season 6 [Netflix]. The show had a solid concluding season, and remains one of my favorite shows ever.

    BoJack Horseman – Season 6 [Netflix]. Another final season here, and I enjoyed it. You wouldn’t think that a show with talking cats and horses would be poignant, but it’s got some meaningful moments.

    Mandalorian – Season 1 {Disney+]. Impressive show. Watched with one of the kiddos. I’ll likely catch Season 2 this year.

    The Office (UK) – Seasons 1 & 2 [Amazon Prime]. I started this a few times in the past, and never go very far. In 2020, I watched both seasons, and really loved it. Amazingly cringey and hilarious.

    The IT Crowd – Seasons 1-5 [Amazon Prime]. Someone recommended this show to me years ago, and I figured 2020 was my year for British workplace comedies. Highly recommended if you like over-the-top, absurd shows.

    Bosch – Seasons 5 & 6 [Amazon Prime]. Season five was excellent, seasons six was ok, but honestly, I’d watch this cast in any performance. This show really sucks me in.

    Band of Brothers [Amazon Prime]. This is another series I started a few times, and never finished. I had the time in 2020 to go all the way through, and glad I did. So well done.

    Jack Ryan – Season 2 [ Amazon Prime]. Well done, not as outstanding as the first season. 

    Things I Wrote

    One of my 2019 resolutions was to get back to writing more often. I ended up writing a couple dozen posts on my own blog, and some corporate blog posts too. I also experimented with some short form writing and tech demos in the form of Twitter threads (e.g. VM migration, Anthos configuration, GCP cloud editor, and Cloud Foundry migration). Here are a few pieces that I enjoyed the most:

    [Forbes] When It Comes To Cloud Migration, Stop Playing It Safe. This was the first thing of mine published by Google. I looked at how to adopt the cloud faster.

    [Google blog] You do you: How to succeed in a distributed, multi-cloud world. I try to be fairly pragmatic with tech advice, and this Google blog post looked at ways companies can succeed when adopting more than one public cloud.

    [InfoQ] New Report Shows “Overwhelming” Cloud Usage. While I continued leading the “cloud” team at InfoQ, I decided to step back from regular writing given that I started working for a cloud provider. I can still do industry pieces like this one!

    [blog] I’m joining Google Cloud for the same reasons you should be a customer. I used this post to announce my job change. Seven months into my time at Google, and I have no regrets.

    [blog] Let’s compare the CLI experiences offered by AWS, Microsoft Azure, and Google Cloud Platform. I’ve spent a fair amount of time with all the public clouds. Still, I can’t pretend that I’m entirely neutral. In this post, I did my best to fairly consider each cloud’s command line experience. Similarly, I wrote another post about each cloud’s database emulation tool.

    [blog] Four reasons that Google Cloud Run is better than traditional FaaS offerings. I’m always on the lookout for the next great technology for developers. Google Cloud Run is one of those, and I dug into it here.

    [blog] These three pieces of career advice made a huge impact on me. This was a short post, but a few people have told me that this helped them make their own career decision this year. That’s nice to hear.

    [blog] After 15 years of blogging, here are 6 things I’ve learned. I’m trying to be better about sharing whatever I know, and I wrote a few blog posts this year on that topic. This one looked at what I learned about blogging, and I wrote another about building a personal brand.

    Things I Read

    I’ve never read this many books in one year. I resolved in 2020 to read every day, not just during business travel or weekend downtime. The result? I started and finished 67 books. I figured I’d call out most of them below, as it was too hard to pick just a few favorites.

    Trillion Dollar Coach: The Leadership Playbook of Silicon Valley’s Bill Campbell by Eric Schmidt (@ericschmidt), Jonathan Rosenberg (@jjrosenberg), and Alan Eagle (@aeaglejr). Without Bill, would Google have been Google Apple been Apple, or many Valley companies succeeded? Doesn’t seem like it. This book was part biography, part leadership lesson, and entirely valuable. The authors drove home the importance of coaching, and how Campbell created a lasting impact with his brand of leadership. Actionable stuff here!

    In a Sunburned Country by Bill Bryson. As with anything Bryson writes, this book is super engaging, and makes the reader want to visit the places he talks about. Here, he drives around Australia while offering a detailed history of life on the continent. I’ve been there once, and now am eager to return.

    Getting Naked: A Business Fable About Shedding The Three Fears That Sabotage Client Loyalty by Patrick M. Lencioni (@patricklencioni). This is leadership advice wrapped in a highly readable story. The focus here was on vulnerability, and creating meaningful relationships with clients through humility and transparency. It reminded me that I need to double-down on this myself when talking with customers.

    The Motive: Why So Many Leaders Abdicate Their Most Important Responsibilities by Patrick M. Lencioni (@patricklencioni). I have a feeling that I’m going to read most of Lencioni’s books. This one asked an uncomfortable question: are you a leader because you want to be rewarded for years of hard work, or because you feel responsible and want to serve others? This is a good story that tells you it’s ok to step back from leadership positions it doesn’t don’t align with your motivations.

    Meet Me in the Bathroom: Rebirth and Rock and Roll in New York City 2001-2011 by Lizzy Goodman (@lizzydgoodman). This was one of my favorites. I loved (and still love) this era of music, and this book was an absorbing behind-the-scenes look at how the most influential bands rose to prominence. Presented through a series of interviews, the book makes you feel the struggles and successes of these talented individuals. It’s also caused me to listen to a LOT of The Strokes during the past two months.

    The Undoing Project: A Friendship That Changed Our Minds by Michael Lewis. How do people make decisions? What powers our judgement? This book is partially a biography of renowned psychologists Danny Kahneman and Amos Tversky, while also exploring the evolution of our understanding of how we make judgement calls. Beautiful story.

    The Battle of Midway by Craig L. Symonds. I had watched the recent film about this WWII battle, and realized I knew way too little about it. This was a thrilling, sobering, and detailed look at an event that had huge historical impact.

    The Godwulf Manuscript (Spenser Series Book 1) by Robert B. Parker. I’m not sure what triggered my interest in this series—maybe the Spencer movie that came out on Netflix?—but I was obsessed. I read fourteen of these books in 2020. This detective series started in the 70s and I kinda loved that setting. Spencer is a terrific character, and I’ll probably read the next fourteen books in 2021.

    The Hidden Cost of Being African American: How Wealth Perpetuates Inequality by Thomas M. Shapiro (@tmshapiro). Why do we see racial inequality increase when rights and opportunities have expanded? The thesis of this book is that family assets are the reason. Seems like some good research here, and the author makes a compelling argument.

    Team Topologies: Organizing Business and Technology Teams for Fast Flow by Matthew Skelton (@matthewpskelton) and Manuel Pais (@manupaisable). This book looks at four team types and offers lots of suggestions for how to use team design to get the service/software you’re looking for.

    Paul: A Biography by N.T. Wright (@profntwright). I love to see a historical figure in three-dimensional context that factors in their setting and contemporaries. This book gave me new appreciation for one of history’s most important individuals. 

    Tubes: A Journey to the Center of the Internet by Andrew Blum (@ajblum). Where exactly is the Internet at? I thoroughly enjoyed this book by Blum where he sets out to find out physically, where the Internet is at. He travels the world and explains some of the fundamentals of how it all works. It’s completely fascinating, and makes me appreciate something I usually take for granted.

    The Answer Is . . .: Reflections on My Life by Alex Trebek. This autobiography features a series of stories about Trebek’s life. He’s a fascinating individual, and I was sorry that we lost him in 2020. But he seemed at peace with his fate, and lived a rich life. 

    INSPIRED: How to Create Tech Products Customers Love by Marty Cagan (@cagan). This is a must-read book for product managers, but also for anyone involved in the product lifecycle. I’ll be reading Cagan’s next book in 2021.

    Apocalypse Never: Why Environmental Alarmism Hurts Us All by Michael Shellenberger (@ShellenbergerMD). The author says that instead of alarmist, exaggerated language about climate change, we need a more rational discussion about what’s really happening. Shellenberger has impressive credentials, and delivers a well-researched, engaging book that opened my eyes. 

    The Unthinkable: Who Survives When Disaster Strikes – and Why by Amanda Ripley (@amandaripley). What happens when we face disaster? It included some useful advice for individuals facing disaster, and those building structures that need to be evacuated in such situations. Ripley wrote a fascinating book that had me reflecting about how *I* would act in the various situations she called out!

    A Conflict of Visions: Ideological Origins of Political Struggles by Thomas Sowell. What underpins our political and social differences? Sowell contends that there are “constrained” and “unconstrained” visions that drive our worldview. The unconstrained vision sees humanity as perfectible where bad choices explain social evils. The constrained vision sees defects as inevitable and looks at trade-offs that factor in human nature. Neither of these align with a particular political party, and much of Sowell’s argument made sense to me.

    The Smartest Guys in the Room: The Amazing Rise and Scandalous Fall of Enron by Bethany McLean (@bethanymac12) and Peter Elkind (@peterelkind). This was such a page-turner! With the benefit of hindsight, it’s shocking to see the decision-making that went on within Enron, and in the investment banks. Maybe it was shocking at the time, too. Either way, it offers a timeless lesson about transparency and defining incentives.

    Crossing the Chasm, 3rd Edition: Marketing and Selling Disruptive Products to Mainstream Customers by Geoffrey A. Moore (@geoffreyamoore). My Google colleague Kyle talks about this book a lot, and I knew the framework. But it was great to actually dig into this great book and learn about market development and what adopters care about at each stage.

    The Outpost: An Untold Story of American Valor by Jake Tapper (@jaketapper). Wow, what a tense, emotional, and powerful story. This book explored the true story of soldiers manning a vulnerable outpost in Afghanistan. It was frustrating to see the lack of support these brave folks received, but it was also inspiring to observe their courage and desire to do the right thing.

    Frederick Douglass: Prophet of Freedom by David W. Blight (@davidwblight1). This my most “highlighted” Kindle book this year. I saved a ton of sections of this terrific book about one of the greatest Americans who ever lived. He relentlessly delivered a message of freedom, and accepted the heavy burden of his mission.  

    The Wax Pack: On the Open Road in Search of Baseball’s Afterlife by Brad Balukjian (@BradBalukjian). I really enjoyed this one. Balukjian opened an old pack of baseball cards and set out to physically meet up with each player in there. He shared part of his own story along the way, and made this well-rounded look at our journey through life.

    Race, Work, and Leadership: New Perspectives on the Black Experience by Laura Morgan Roberts (@alignmentquest), Tony Mayo, and David A. Thomas (@ProfThomas). The editors assembled a series of data-driven essays that highlight both challenges and opportunities for black professionals and their allies. Great read.

    The Ride of a Lifetime: Lessons Learned from 15 Years as CEO of the Walt Disney Company by Robert Iger (@RobertIger). This was an entertaining biography, with many useful leadership lessons sprinkled in. It was also a good reminder of the high stakes and stress that accompanies executive roles.

    Complexity: A Guided Tour by Melaine Mitchell (@MelMitchell1). The field of complexity looks at how simple things organize into a hard-to-predict, leader-less whole, while evolving and learning. We see this in nature, economies, and even technology systems. This book itself was complex, but I liked it and learned many things.

    The Goldilocks Enigma: Why Is the Universe Just Right for Life? by Paul Davies. Lots of math and physics here, but it’s an entirely readable, thought-provoking book that makes you appreciate our very existence.

    Hunting Evil: The Nazi War Criminals Who Escaped and the Quest to Bring Them to Justice by Guy Walters (@guywalters). I mean, the title clearly identifies what this book is about. Walters does a great job telling some exciting stories, dispelling some myths, and laying out a number of frustrating details about spotty efforts of the Allies to do this important work. 

    The First 90 Days, Updated and Expanded: Proven Strategies for Getting Up to Speed Faster and Smarter by Michael Watkins (@MichaelDWatkins). In anticipation of starting a new job, I picked up this book to help me get in the right frame of mind. This Google role is actually my first where I *started* in a leadership position, so I figured I needed help. Watkins provides useful advice here, even if you’re switching roles within the same company.

    Raoul Wallenberg: The Man Who Saved Thousands of Hungarian Jews from the Holocaust by Ingrid Carlberg (@ingridmcarlberg). I guess I read a lot of biographies this year. This one really stuck with me. Wallenberg displayed an uncommon purpose, bravery, and creativity in his effort to protect as many people as possible. His postwar captivity—and the passive approach of his government to intervene—was heartbreaking.

    The Hot Hand: The Mystery and Science of Streaks by Ben Cohen (@bzcohen). Are hot streaks real? Is anyone really “in the zone” or are we seeing patterns that don’t exist? This was a good book that felt meandering (in a good way) at times, came to some conclusions, and even offered some advice for investors and professionals.

    Simply Jesus: A New Vision of Who He Was, What He Did, and Why He Matters by N.T. Wright (@profntwright). Another excellent book that puts someone of epic relevance into their geographical, societal, and historical context.

    Understanding Michael Porter: The Essential Guide to Competition and Strategy by Joan Magretta. This book has a huge influence on me in 2020, and likely for years ahead. I finally felt like I “got” strategy after reading it. Magretta does a masterful job explaining the essence of strategy, where competitive differentiation comes from, and why Porter has a timeless way of thinking about it.

    The Life and Afterlife of Harry Houdini by Joe Posnanski (@JPosnanski). I love Joe’s writing which I’ve always associated with sports. His book about Houdini was wonderful. We all know the name, but why are we drawn to the illusionist? Here we investigate the man, and those who still carry a torch for him. 

    Jobs to be Done: Theory to Practice by Anthony W. Ulwick (@Ulwick). Seems I read more books about product development this year than I thought. This one’s a gem. Whether you’re selling enterprise software or homemade jewelry, you have to ask yourself what job the customer is hiring you to do. Ulwick walks us through this framework and how to apply it.

    Isaac Newton by James Gleick (@JamesGleick). This was a big, informative biography of a pioneering scientist whose impact is felt hundreds of years later.

    Infinite Powers: How Calculus Reveals the Secrets of the Universe by Steven H. Strogatz (@stevenstrogatz). Can math be fun and exciting? Sure it can. This was the 2nd most highlighted book on my Kindle in 2020. Strogatz tries, and succeeds, in making calculus more approachable and applicable. He uses stories, relatable examples, and a palpable enthusiasm to pull the reader through even the most complex problems.

    The Power of Bad: How the Negativity Effect Rules Us and How We Can Rule It by John Tierney (@JohnTierneyNYC) and Roy F. Baumeister. It wasn’t difficult in 2020 to have a negative attitude. This book goes into depth on how good we actually have it right now, how to “override the disproportionate impact of bad”, and how to handle sincerely terrible circumstances.

    The Harder You Work, the Luckier You Get: An Entrepreneur’s Memoir by Joe Ricketts. I don’t remember who recommended this biography, but I’m glad I read it. Ricketts founded Ameritrade, and walks through his journey disrupting the brokerage market. Good story of perseverance and grit.

    Fragments of Isabella: A Memoir of Auschwitz by Isabella Leitner. This is a relatively short, moving memoir of a young woman who was deported to Auschwitz along with her family, and somehow survived the ordeal. This is another book that stayed with me long after I finished it. 

    Seeing Around Corners: How to Spot Inflection Points in Business Before They Happen by Rita Gunther McGrath (@rgmcgrath). Here’s another book that touches on product development and strategy. The author serves up lots of stories and advice to help us find the right vantage point and look broadly for what’s next.

    Ten Discoveries That Rewrote History by Patrick Hunt. We have such short memories, don’t we? I like books that reset my context and help me appreciate the bigger picture. This book looked at great discoveries—things like the Rosetta Stone, Dead Sea Scrolls, Pompeii, Troy, and more—how it happened, and what it means. Educational and interesting.

    Flash Boys: A Wall Street Revolt by Michael Lewis. Like me, you might have an idealistic, old timey view of the stock market. But alas, there was quite a long period where high frequency traders took advantage of milisecond information advantages to skim money from investors. Lewis tells a terrific story about those who figured it out, and fought back.

    Do You Talk Funny?: 7 Comedy Habits to Become a Better (and Funnier) Public Speaker by David Nihill (@davidnihill). Do you have to be naturally hilarious to inject humor into your presentations? Nah. Nihill became a stand up comic for a year to learn the field, and translate those lessons into something that everyone else can apply. Most presentations are kinda terrible, so by injecting some strategic humor into your presentation, you’ll probably see your career prospects take off.

    The Right Stuff by Tom Wolfe. This is a classic book that I just got around to reading. Shame on me. It’s the thrilling story of fighter pilots who were addicted to speed and altitude, and eventually—minus Chuck Yeager who may have been the best of them all—staffed the first space flights. These are heroes, straight up.

    Whew. That was a lot. Congrats for getting this far. And congrats for surviving 2020 intact. I know that for many of you, it was a sincerely difficult year where loneliness and loss assaulted you. Know that you matter, things will get better, and people are here to root you on. Let’s have a great 2021, together.

  • My latest Pluralsight course—Cloud Migrations: Executive Briefing—is now live

    My latest Pluralsight course—Cloud Migrations: Executive Briefing—is now live

    During the past decade, there’s been one constant in my professional life. Through four companies (including a couple of acquisitions) and a variety of different jobs, I’ve taught training courses for Pluralsight. Since I started in 2011, over 400,000 people have watched 450,000 hours of my content. I’m going to keep doing technical deep dive courses, but Pluralsight proposed a new type of course for me to experiment with: Executive Briefings.

    Rather than screen sharing of slides and demos, Executive Briefings are short video presentations of the speaker delivering a talk, targeting a leadership audience. My first executive briefing course is about migrating to the public cloud.

    In this 20 minute session, I go through what you need to migrate when adopting public cloud, seven specific pieces of advice for “how” you do it, and I close with a reminder on why you’re doing it.

    Let me know if you like this sort of material, and I may do a few more, while sprinkling in the regular batch of lengthier tech training. With all of us at home, and a new year of learning ahead of us, it’s a great time to grab a Pluralsight subscription.

  • I want to learn about these six things in 2021

    I want to learn about these six things in 2021

    I know a few things. I don’t know most things. Each year, I try to learn new stuff and challenge my existing knowledge/assumptions. There are always more things to learn than time available in the day, so I have to be selective. What should I focus on? Some folks choose to go deeper in their areas of expertise, others choose to bolster weak areas. Next year, I’m going to do the latter.

    Here are six topics—four related to tech, two related to professional skills—I want to learn more about, and I’ll include some thoughts on my approach to learning each.

    Technology Skills

    Each year, I try out a variety of technologies. Next year won’t be different. Besides these four topics below, I suspect that I’ll keep messing around with serverless technologies, Kubernetes, service meshes, and public cloud services. But I’m going to spend special attention on:

    Identity and access management

    In my 20+ year career, I’ve learned enough about identity management to be dangerous. But in reality, I’m barely competent on this topic. It’s time to truly understand how all this works. With so many folks building increasingly distributed architectures, identity management seems more important than ever. I’d like to dig into things like authorization flows, application identities within clusters, and access management within cloud tenancy structures.

    How? I plan on taking some Pluralsight courses on Google Cloud Identity, OAuth2 flows, and overall security practices. Then I’ll invest in some hands-on time with things like Workload Identity, Identity Aware Proxy, and the BeyondCorp assets we’ve created. May also read some Gartner and Forrester reports on the topic.

    BigQuery

    This is a crown jewel in Google Cloud’s portfolio. It’s a well-built, popular service that stands out among public cloud offerings. I’ve spent precious little time in the data analytics domain, and want to change that. A little. I’m not interested in being a full-on analytics guy, but I want to understand how BigQuery works and the role it can play for companies adopting cloud.

    How? There are a handful of Pluralsight courses that look good here. I’ll also go hands on a lot. That may involve some QwikLabs, or just me playing with datasets.

    Angular

    I’ve mostly declared bankruptcy on front-end frameworks. My career has been server-side, with only enough investment in the front-end to build decent looking demos. But I like what I’m seeing here and it’s obvious how much processing we’re doing client-side now. There are roughly five hundred viable frameworks to choose from, so I might as well pick a popular one with some Google heritage.

    How? Pluralsight has a great Angular learning path. I just need to get some reps with the tech, and make it second nature to use on any apps I build. Plus, learning this gives me an excuse to use compute platforms like Cloud Run and GKE to host my app.

    Application deployment tools and strategies

    While CI/CD is a fairly mature domain, I’m still seeing lots of fresh thinking here. I want to learn more about how forward-thinking companies are packaging up and shipping software. Shipping is more sophisticated now with so many components to factor in, and less tolerance for downtime. The tooling for continuous deployment (and progressive delivery) is getting better.

    How? I’m looking forward to trying out a lot of technologies here. I’m sure i’ll find a lot of books or courses about what I’m after, so this is a very “hands on” journey.

    Professional Skills

    I’m also looking for to building up my business and management skills next year. The two things that I’ll invest the most in are:

    Product management

    Given my position in Google Cloud, I’m supposed to know what I’m doing. But I’m learning new things every day. In 2021, I want to double-down on the practices of product development and full product lifecycle management. I’ve got so much to learn on how to better identify customer problems, scope an experiment, communicate value, measure usage, and build a sustainable business around the product.

    How? Much of this will happen by watching my peers. The product discipline at Google Cloud is excellent. In addition, I’ve got my eye on new books, and some product-focused conferences. I also plan on reading some of the good Gartner research on product management.

    Coaching and sponsorship

    I’ve done some mentorship in my career, but I haven’t done much coaching or sponsorship. Some of that is because of imposter syndrome (“why would anyone want to learn anything from ME?”) and some is because I haven’t made it a priority. I now have more appreciation for what I can give back to others. I’ve been making myself more available this year, and want to intentionally continue that next year.

    How? Some of this will happen through study and watching others, and some by actually doing it! Our industry is full of high-potential individuals who haven’t had someone in their corner, and I’m going to do my part to fix that.

    What about you? What topics deserve your special attention in 2021? I’m looking forward to learning in public and getting your feedback along the way.

  • Four reasons that Google Cloud Run is better than traditional FaaS offerings

    Has the “serverless revolution stalled”? I dunno. I like serverless. Taught a popular course about it. But I reviewed and published an article written by Bernard Brode that made that argument, and it sparked a lot of discussion. If we can agree that serverless computing means building an architecture out of managed services that scale to zero—we’re not strictly talking about function-as-a-service—that’s a start. Has this serverless model crossed the chasm from early adopters to an early majority? I don’t think so. And the data shows that usage of FaaS—still a fundamental part of most people’s serverless architecture—has flattened a bit. Why is that? I’m no expert, but I wonder if some of the inherent friction of the 1st generation FaaS gets in the way.

    We’re seeing a new generation of serverless computing that removes that friction and may restart the serverless revolution. I’m talking here about Google Cloud Run. Based on the Knative project, it’s a fully managed service that scales container-based apps to zero. To me, it takes the best attributes from three different computing paradigms:

    ParadigmBest Attributes
    Platform-as-a-Service– focus on the app, not underlying infrastructure
    – auto-wire networking components to expose your endpoint
    Container-as-a-Service– use portable app packages
    – develop and test locally
    Function-as-a-Service– improve efficiency by scaling to zero
    – trigger action based on events

    Each of those above paradigms has standalone value. By all means, use any of them if they suit your needs. Right now, I’m interested in what it will take for large companies to adopt serverless computing more aggressively. I think it requires “fixing” some of the flaws of FaaS, and there are four reasons Cloud Run is positioned to do so.

    1. It doesn’t require rearchitecting your systems

    First-generation serverless doesn’t permit cheating. No, you have to actually refactor or rebuild your system to run this way. That’s different than all the previous paradigms. IaaS? You could take existing bare metal workloads and run them unchanged in a cloud VM platform. PaaS? It catered to 12-factor apps, but you could still run many existing things there. CaaS? You can containerize a lot of things without touching the source code. FaaS? Nope. Nothing in your data center “just works” in a FaaS platform.

    While that’s probably a good thing from a purity perspective—stop shifting your debt from one abstraction to another without paying it down!—it’s impractical. Simultaneously, we’re asking staff at large companies to: redesign teams for agile, introduce product management, put apps on CI pipelines, upgrade their programming language/framework, introduce new databases, decouple apps into microservices, learn cloud and edge models, AND keep all the existing things up and running. It’s a lot. The companies I talk to are looking for ways to get incremental benefits for many workloads, and don’t have the time or people to rebuild many things at once.

    This is where Cloud Run is better than FaaS. It hosts containers that respond to web requests or event-based triggers. You can write functions, or, containerize a complete app—Migrate for Anthos makes it easy. Your app’s entry point doesn’t have to conform to a specific method signature, and there are no annotations or code changes required to operate in Cloud Run. Take an existing custom-built app written in any language, or packaged (or no source-code-available) software and run it. You don’t have to decompose your existing API into a series of functions, or break down your web app into a dozen components. You might WANT to, but you don’t HAVE to. I think that’s powerful, and significantly lowers the barrier to entry.

    2. It runs anywhere

    Lock-in concerns are overrated. Everything is lock-in. You have to decide whether you’re getting unique value from the coupling. If so, go for it. A pristine serverless architecture consists of managed services with code (FaaS) in the gaps. The sticky part is all those managed services, not the snippets of code running in the FaaS. Just making a FaaS portable doesn’t give you all the benefits of serverless.

    That said, I don’t need all the aspects of serverless to get some of the benefits. Replacing poorly utilized virtual machines with high-density nodes hosting scale-to-zero workloads is great. Improving delivery velocity by having an auto-wired app deployment experience versus ticket-defined networking is great. I think it’s naive to believe that most folks can skip from traditional software development directly to fully serverless architectures. There’s a learning and adoption curve. And one step on the journey is defining more distributed services, and introducing managed services. Cloud Run offers a terrific best-of-both-worlds model that makes the journey less jarring. And uniquely, it’s not only available on a single cloud.

    Cloud Run is great on Google Cloud. Given the option, you should use it there. It’s fully managed and elastic, and integrates with all types of GCP-only managed services, security features, and global networking. But you won’t only use Google Cloud in your company. Or Azure. Or AWS. Or Cloudflare. Cloud Run for Anthos puts this same runtime most anywhere. Use it in your data center. Use it in your colocation or partner facility. Use it at the edge. Soon, use it on AWS or Azure. Get one developer-facing surface for apps running on a variety of hosts.

    A portable Faas, based on open source software, is powerful. And I believe, necessary, to break into mainstream adoption within the enterprise. Bring the platform to the people!

    3. It makes the underlying container as invisible, or visible, as you want

    Cloud Run uses containers. On one hand, it’s a packaging mechanism, just like a ZIP file for AWS Lambda. On the other, it’s a way to bring apps written in any language, using any libraries, to a modern runtime. There’s no “supported languages” page on the website for Cloud Run. It’s irrelevant.

    Now, I personally don’t like dealing with containers. I want to write code, and see that code running somewhere. Building containers is an intermediary step that should involve as little effort as possible. Fortunately, tools like Cloud Code make that a reality for me. I can use Visual Studio Code to sling some code, and then have it automatically containerized during deployment. Thanks Cloud Buildpacks! If I choose to, I can use Cloud Run while being blissfully unaware that there are containers involved.

    That said, maybe I want to know about the container. My software may depend on specific app server settings, file system directories, or running processes. During live debugging, I may like knowing I can tunnel into the container and troubleshoot in sophisticated ways.

    Cloud Run lets you choose how much you want to care about the container image and running container itself. That’s a flexibility that’s appealing.

    4. It supports advanced use cases

    Cloud Run is great for lots of scenarios. Do server-side streaming with gRPC. Build or migrate web apps or APIs that take advantage of our new API Gateway. Coordinate apps in Cloud Run with other serverless compute using the new Cloud Workflows. Trigger your Cloud Run apps based on events occurring anywhere within Google Cloud. Host existing apps that need a graceful shutdown before scaling to zero. Allocate more horsepower to new or existing apps by assigning up to 4 CPUs and 4GB of RAM, and defining concurrency settings. Decide if your app should always have an idle instance (no cold starts) and how many instances it should scale up to. Route traffic to a specific port that your app listens on, even if it’s not port 80.

    If you use Cloud Run for Anthos (in GCP or on other infrastructure), you have access to underlying Kubernetes attributes. Create private services. Participate in the service mesh. Use secrets. Reference ConfigMaps. Turn on Workload Identity to secure access to GCP services. Even take advantage of GPUs in the cluster.

    Cloud Run isn’t for every workload, of course. It’s not for background jobs. I wouldn’t run a persistent database. It’s ideal for web-based apps, new or old, that don’t store local state.

    Give Cloud Run a look. It’s a fast-growing service, and it’s free to try out with our forever-free services on GCP. 2 million requests a month before we charge you anything! See if you agree that this is what the next generation of serverless compute should look like.

  • Let’s compare the CLI experiences offered by AWS, Microsoft Azure, and Google Cloud Platform

    Let’s compare the CLI experiences offered by AWS, Microsoft Azure, and Google Cloud Platform

    Real developers use the CLI, or so I’m told. That probably explains why I mostly use the portal experiences of the major cloud providers. But judging from the portal experiences offered by most clouds, they prefer you use the CLI too. So let’s look at the CLIs.

    Specifically, I evaluated the cloud CLIs with an eye on five different areas:

    1. API surface and patterns. How much of the cloud was exposed via CLI, and is there a consistent way to interact with each service?
    2. Authentication. How do users identify themselves to the CLI, and can you maintain different user profiles?
    3. Creating and viewing services. What does it feel like to provision instances, and then browse those provisioned instances?
    4. CLI sweeteners. Are there things the CLI offers to make using it more delightful?
    5. Utilities. Does the CLI offer additional tooling that helps developers build or test their software?

    Let’s dig in.

    Disclaimer: I work for Google Cloud, so obviously I’ll have some biases. That said, I’ve used AWS for over a decade, was an Azure MVP for years, and can be mostly fair when comparing products and services. Please call out any mistakes I make!

    AWS

    You have a few ways to install the AWS CLI. You can use a Docker image, or install directly on your machine. If you’re installing directly, you can download from AWS, or use your favorite package manager. AWS warns you that third party repos may not be up to date. I went ahead and installed the CLI on my Mac using Homebrew.

    API surface and patterns

    As you’d expect, the AWS CLI has wide coverage. Really wide. I think there’s an API in there to retrieve the name of Andy Jassy’s favorite jungle cat. The EC2 commands alone could fill a book. The documentation is comprehensive, with detailed summaries of parameters, and example invocations.

    The command patterns are relatively consistent, with some disparities between older services and newer ones. Most service commands look like:

    aws [service name] [action] [parameters]

    Most “actions” start with create, delete, describe, get, list, or update.

    For example:

    aws elasticache create-cache-cluster --engine redis
aws kinesis describe-stream --stream-name seroter-stream
aws kinesis describe-stream --stream-name seroter-stream
aws qldb delete-ledger --name seroterledger
aws sqs list-queues

    S3 is one of the original AWS services, and its API is different. It uses commands like cp, ls, and rm. Some services have modify commands, others use update. For the most part, it’s intuitive, but I’d imagine most people can’t guess the commands.

    Authentication

    There isn’t one way to authenticate to the AWS CLI. You might use SSO, an external file, or inline access key and ID, like I do below.

    The CLI supports “profiles” which seems important when you may have different access to default values based on what you’re working on.

    Creating and viewing service instances

    By default, everything the CLI does occurs in the region of the active profile. You can override the default region by passing in a region flag to each command. See below that I created a new SQS queue without providing a region, and it dropped it into my default one (us-west-2). By explicitly passing in a target region, I created the second queue elsewhere.

    The AWS Console shows you resources for a selected region. I don’t see obvious ways to get an all-up view. A few services, like S3, aren’t bound by region, and you see all resources at once. The CLI behaves the same. I can’t view all my SQS queues, or databases, or whatever, from around the world. I can “list” the items, region by region. Deletion behaves the same. I can’t delete the above SQS queue without providing a region flag, even though the URL is region-specific.

    Overall, it’s fast and straightforward to provision, update, and list AWS services using the CLI. Just keep the region-by-region perspective in mind!

    CLI sweeteners

    The AWS CLI gives you control over the output format. I set the default for my profile to json, but you can also do yaml, text, and table. You can toggle this on a request by request basis.

    You can also take advantage of command completion. This is handy, given how tricky it may be to guess the exact syntax of a command. Similarly, I really like you can be prompted for parameters. Instead of guessing, or creating giant strings, you can go parameter by parameter in a guided manner.

    The AWS CLI also offers select opportunities to interact with the resources themselves. I can send and receive SQS messages. Or put an item directly into a DynamoDB table. There are a handful of services that let you create/update/delete data in the resource, but many are focused solely on the lifecycle of the resource itself.

    Finally, I don’t see a way to self-update from within the CLI itself. It looks like you rely on your package manager or re-download to refresh it. If I’m wrong, tell me!

    Utilities

    It doesn’t look like the CLI ships with other tools that developers might use to build apps for AWS.

    Microsoft Azure

    The Microsoft Azure CLI also has broad coverage and is well documented. There’s no shortage of examples, and it clearly explains how to use each command.

    Like AWS, Microsoft offers their CLI in a Docker image. They also offer direct downloads, or access via a package manager. I grabbed mine from Homebrew.

    API surface and patterns

    The CLI supports almost every major Azure service. Some, like Logic Apps or Blockchain, only show up in their experimental sandbox.

    Commands follow a particular syntax:

    az [service name] [object] create | list | delete | update [parameters]

    Let’s look at a few examples:

    az ad app create --display-name my-ad-app
az cosmosdb list --resource-group group1
az postgres db show --name mydb --resource-group group1 --server-name myserver
az service bus queue delete --name myqueue --namespace-name mynamespace --resource-group group1

    I haven’t observed much inconsistency in the CLI commands. They all seem to follow the same basic patterns.

    Authentication

    Logging into the CLI is easy. You can simply do az login as I did below—this opens a browser window and has you sign into your Azure account to retrieve a token—or you can pass in credentials. Those credentials may be a username/password, service principal with a secret, or service principal with a client certificate.

    Once you log in, you see all your Azure subscriptions. You can parse the JSON to see which one is active, and will be used as the default. If you wish to change the default, you can use az account set --subscription [name] to pick a different one.

    There doesn’t appear to be a way to create different local profiles.

    Creating and viewing service instances

    It seems that most everything you create in Azure goes into a resource group. While a resource group has a “location” property, that’s related to the metadata, not a restriction on what gets deployed into it. You can set a default resource group (az configure --defaults group=[name]) or provide the relevant input parameter on each request.

    Unlike other clouds, Azure has a lot of nesting. You have a root account, then a subscription, and then a resource group. And most resources also have parent-child relationships you must define before you can actually build the thing you want.

    For example, if you want a service bus queue, you first create a namespace. You can’t create both at the same time. It’s two calls. Want a storage blob to upload videos into? Create a storage account first. A web application to run your .NET app? Provision a plan. Serverless function? Create a plan. This doesn’t apply to everything, but just be aware that there are often multiple steps involved.

    The creation activity itself is fairly simple. Here are commands to create Service Bus namespace and then a queue

    az servicebus namespace create --resource-group mydemos --name seroter-demos --location westus
az servicebus queue create --resource-group mydemos --namespace-name seroter-demos --name myqueue

    Like with AWS, some Azure assets get grouped by region. With Service Bus, namespaces are associated to a geo. I don’t see a way to query all queues, regardless of region. But for the many that aren’t, you get a view of all resources across the globe. After I created a couple Redis caches in my resource group, a simple az redis list --resource-group mydemos showed me caches in two different parts of the US.

    Depending on how you use resource groups—maybe per app or per project, or even by team—just be aware that the CLI doesn’t retrieve results across resource groups. I’m not sure the best strategy for viewing subscription-wide resources other than the Azure Portal.

    CLI sweeteners

    The Azure CLI has some handy things to make it easier to use.

    There’s a find function for figuring out commands. There’s output formatting to json, tables, or yaml. You’ll also find a useful interactive mode to get auto-completion, command examples, and more. Finally, I like that the Azure CLI supports self-upgrade. Why leave the CLI if you don’t have to?

    Utilities

    I noticed a few things in this CLI that help developers. First, there’s an az rest command that lets you call Azure service endpoints with authentication headers taken care of for you. That’s a useful tool for calling secured endpoints.

    Azure offers a wide array of extensions to the CLI. These aren’t shipped as part of the CLI itself, but you can easily bolt them on. And you can create your own. This is a fluid list, but az extension list-available shows you what’s in the pool right now. As of this writing, there are extensions for preview AKS capabilities, managing Azure DevOps, working with DataBricks, using Azure LogicApps, querying the Azure Resource Graph, and more.

    Google Cloud Platform

    I’ve only recently started seriously using the GCP CLI. What’s struck me most about the gcloud tool is that it feels more like a system—dare I say, platform—than just a CLI. We’ll talk more about that in a bit.

    Like with other clouds, you can use the SDK/CLI within a supported Docker image, package manager, or direct download. I did a direct download, since this is also a self-updating CLI, so I didn’t want to create a zombie scenario with my package manager.

    API surface and patterns

    The gcloud CLI has great coverage for the full breadth of GCP. I can’t see any missing services, including things launched two weeks ago. There is a subset of services/commands available in the alpha or beta channels, and are fully integrated into the experience. Each command is well documented, with descriptions of parameters, and example calls.

    CLI commands follow a consistent pattern:

    gcloud [service] create | delete | describe | list | update [parameters]

    Let’s see some examples:

    gcloud bigtable instances create seroterdb --display-name=seroterdb --cluster=serotercluster --cluster-zone=us-east1-a
gcloud pubsub topics describe serotertopic
gcloud run services update --memory=1Gi
gcloud spanner instances delete myspanner

    All the GCP services I’ve come across follow the same patterns. It’s also logical enough that I even guessed a few without looking anything up.

    Authentication

    A gcloud auth login command triggers a web-based authorization flow.

    Once I’m authenticated, I set up a profile. It’s possible to start with this process, and it triggers the authorization flow. Invoking the gcloud init command lets me create a new profile/configuration, or update an existing one. A profile includes things like which account you’re using, the “project” (top level wrapper beneath an account) you’re using, and a default region to work in. It’s a guided processes in the CLI, which is nice.

    And it’s a small thing, but I like that when it asks me for a default region, it actually SHOWS ME ALL THE REGION CODES. For the other clouds, I end up jumping back to their portals or docs to see the available values.

    Creating and viewing service instances

    As mentioned above, everything in GCP goes into Projects. There’s no regional affinity to projects. They’re used for billing purposes and managing permissions. This is also the scope for most CLI commands.

    Provisioning resources is straightforward. There isn’t the nesting you find in Azure, so you can get to the point a little faster. For instance, provisioning a new PubSub topic looks like this:

    gcloud pubsub topics create richard-topic

    It’s quick and painless. PubSub doesn’t have regional homing—it’s a global service, like others in GCP—so let’s see what happens if I create something more geo-aware. I created two Spanner instances, each in different regions.

    gcloud spanner instances create seroter-db1 --config=regional-us-east1 --description=ordersdb --nodes=1
gcloud spanner instances create seroter-db2 --config=regional-us-west1 --description=productsdb --nodes=1

    It takes seconds to provision, and then querying with gcloud spanner instances list gives me all Spanner database instances, regardless of region. And I can use a handy “filter” parameter on any command to winnow down the results.

    The default CLI commands don’t pull resources from across projects, but there is a new command that does enable searching across projects and organizations (if you have permission). Also note that Cloud Storage (gsutil) and Big Query (bq) use separate CLIs that aren’t part of gcloud directly.

    CLI sweeteners

    I used one of the “sweeteners” before: filter. It uses a simple expression language to return a subset of results. You’ll find other useful flags for sorting and limiting results. Like with other cloud CLIs, gcloud lets you return results as json, table, csv, yaml, and other formats.

    There’s also a full interactive shell with suggestions, auto-completion, and more. That’s useful as you’re learning the CLI.

    gcloud has a lot of commands for interacting with the services themselves. You can publish to a PubSub topic, execute a SQL statement against a Spanner database, or deploy and call a serverless Function. It doesn’t apply everywhere, but I like that it’s there for many services.

    The GCP CLI also self-updates. We’ll talk about it more in the section below.

    Utilities

    A few paragraphs ago, I said that the gcloud CLI felt more like a system. I say that, because it brings a lot of components with it. When I type in gcloud components list, I see all the options:

    We’ve got the core SDK and other GCP CLIs for Big Query, but also a potpourri of other handy tools. You’ve got Kubernetes development tools like minikube, Skaffold, Kind, kpt, and kubectl. And you get a stash of local emulators for cloud services like Bigtable, Firestore, Spanner, PubSub and Spanner.

    I can install any or all of these, and upgrade them all from here. A gcloud components update command update all of them, and, shows me a nice change log.

    There are other smaller utility functions included in gcloud. I like that I have commands to configure Docker to work with Google Container Registry, Or fetch Kubernetes cluster credentials and put them into my active profile. And print my identity token to inject into the auth headers of calls to secure endpoints.

    Wrap

    To some extent, each CLI reflects the ethos of their cloud. The AWS CLI is dense, powerful, and occasionally inconsistent. The Azure CLI is rich, easy to get started with, and 15% more complicated than it should be. And the Google Cloud CLI is clean, integrated, and evolving. All of these are great. You should use them and explore their mystery and wonder.

  • First look: Triggering Google Cloud Run with events generated by GCP services

    First look: Triggering Google Cloud Run with events generated by GCP services

    When you think about “events” in an event-driven architecture, what comes to mind? Maybe you think of business-oriented events like “file uploaded”, “employee hired”, “invoice sent”, “fraud detected”, or “batch job completed.” You might emit (or consume) these types of events in your application to develop more responsive systems. 

    What I find even more interesting right now are the events generated by the systems beneath our applications. Imagine what your architects, security pros, and sys admins could do if they could react to databases being provisioned, users getting deleted, firewall being changed, or DNS zone getting updated. This sort of thing is what truly enables the “trust, but verify” approach for empowered software teams. Let those teams run free, but “listen” to things that might be out of compliance.

    This week, the Google Cloud team announced Events for Cloud Run, in beta this September. What this capability does is let you trigger serverless containers when lifecycle events happen in most any Google Cloud service. These lifecycle events are in the CloudEvents format, and distributed (behind the scenes) to Cloud Run via Google Cloud PubSub. For reference, this capability bears some resemblance to AWS EventBridge and Azure Event Grid. In this post, I’ll give you a look at Events for Cloud Run, and show you how simple it is to use.

    Code and deploy the Cloud Run service

    Developers deploy containers to Cloud Run. Let’s not get ahead of ourselves. First, let’s build the app. This app is Seroter-quality, and will just do the basics. I’ll read the incoming event and log it out. This is a simple ASP.NET Core app, with the source code in GitHub. 

    I’ve got a single controller that responds to a POST command coming from the eventing system. I take that incoming event, serialize from JSON to a string, and print it out. Events for Cloud Run accepts either custom events, or CloudEvents from GCP services. If I detect a custom event, I decode the payload and print it out. Otherwise, I just log the whole CloudEvent.

    namespace core_sample_api.Controllers
{
    [ApiController]
    [Route("")]
    public class Eventsontroller : ControllerBase
    {
        private readonly ILogger<Eventsontroller> _logger;
        public Eventsontroller(ILogger<Eventsontroller> logger)
        {
            _logger = logger;
        }
        [HttpPost]
        public void Post(object receivedEvent)
        {
            Console.WriteLine("POST endpoint called");
            string s = JsonSerializer.Serialize(receivedEvent);
            //see if custom event with "message" root property
            using(JsonDocument d = JsonDocument.Parse(s)){
                JsonElement root = d.RootElement;
                if(root.TryGetProperty("message", out JsonElement msg)) {
                    Console.WriteLine("Custom event detected");
                    JsonElement rawData = msg.GetProperty("data");
                    //decode
                    string data = System.Text.Encoding.UTF8.GetString(Convert.FromBase64String(rawData.GetString()));
                    Console.WriteLine("Data value is: " + data);
                }
            }
            Console.WriteLine("Data: " + s);
        }
    }
}

    After checking all my source code into GitHub, I was ready to deploy it to Cloud Run. Note that you can use my same repo to continue on this example!

    I switched over to the GCP Console, and chose to create a new Cloud Run service. I picked a region and service name. Then I could have chosen either an existing container image, or, continuous deployment from a git repo. I chose the latter. First I picked my GitHub repo to get source from.

    Then, instead of requiring a Dockerfile, I picked the new Cloud Buildpacks support. This takes my source code and generates a container for me. Sweet. 

    After choosing my code source and build process, I kept the default HTTP trigger. After a few moments, I had a running service.

    Add triggers to Cloud Run

    Next up, adding a trigger. By default, the “triggers” tab shows the single HTTP trigger I set up earlier. 

    I wanted to show custom events in addition to CloudEvents ones, so I went to the PubSub dashboard and created a new queue that would trigger Cloud Run.

    Back in the Cloud Run UX, I added a new trigger. I chose the trigger type of “com.google.cloud.pubsub.topic.publish” and picked the Topic I created earlier. After saving the trigger, I saw it show up in the list.

    After this, I wanted to trigger my Cloud Run service with CloudEvents. If you’re receiving events from Google Cloud services, you’ll have to enable Data Access Logs so that events can be spun up from Cloud Logs. I’m going to listen for events from Cloud Storage and Cloud Build, so I turned on audit logging for each.

    All that was left to define the final triggers. For Cloud Storage, I chose the storage.create.bucket trigger.

    I wanted to react to Cloud Build, so that I could see whenever a build started.

    Terrific. Now I was ready to test. I sent in a message to PubSub to trigger the custom event.

    I checked the logs for Cloud Run, and almost immediately saw that the service ran, accepted the event, and logged the body.

    Next, I tested Cloud Storage by adding a new bucket.

    Almost immediately, I saw a CloudEvent in the log.

    Finally, I kicked off a new Build pipeline, and saw an event indicating that Cloud Run received a message, and logged it.

    If you care about what happens inside the systems your apps depend on, take a look at the new Events for Cloud Run and start tapping into the action.

  • I’m looking forward these 8 sessions at Google Cloud Next ’20 OnAir (Week 7)

    I’m looking forward these 8 sessions at Google Cloud Next ’20 OnAir (Week 7)

    It’s here. After six weeks of OTHER topics, we’re up to week seven of Google Cloud Next OnAir, which is all about my area: app modernization. The “app modernization” bucket in Google Cloud covers lots of cool stuff including Cloud Code, Cloud Build, Cloud Run, GKE, Anthos, Cloud Operations, and more. It basically addresses the end-to-end pipeline of modern apps. I recently sketched it out like this:

    I think this the biggest week of Next, with over fifty breakout sessions. I like that most of the breakouts so far have been ~20 minutes, meaning you can log in, set playback speed to 1.5x, and chomp through lots of topic quickly. 

    Here are eight of the sessions I’m looking forward to most:

    1. Ship Faster, Spend Less By Going Multi-Cloud with Anthos. This is the “keynote” for the week. We’re calling out a few product announcements, highlighting some new customers, and saying keynote-y things. You’ll like it.
    2. GKE Turns 5: What’s New? All Kubernetes aren’t the same. GKE stands apart, and the team continues solving customer problems in new ways. This should be a great look back, and look ahead.
    3. Cloud Run: What’s New? To me, Cloud Run has the best characteristics of PaaS, combined with the the event-driven, scale-to-zero of serverless functions. This is the best place I know of to run custom-built apps in the Google Cloud (or anywhere, with Anthos).
    4. Modernize Legacy Java Apps Using Anthos. Whoever figures out how to unlock value from existing (Java) apps faster, wins. Here’s what Google Cloud is doing to help customers improve their Java apps and run them on a great host.
    5. Running Anthos on Bare Metal and at the Edge with Major League Baseball (MLB). Baseball’s back, my Slam Diego Padres are fun again, and Anthos is part of the action. Good story here.
    6. Getting Started with Anthos, Anthos Deep Dive: Part One, Anthos Deep Dive: Part Two. Am I cheating by making three sessions into one entry? Fine, you caught me. But this three part trilogy is a great way to grok Anthos and understand its value.
    7. Develop for Cloud Run in the IDE with Cloud Code. Cloud Code extends your IDE to support Google Cloud, and Cloud Run is great. Combine the two, and you’ve got some good stuff.
    8. Event-Driven Microservices with Cloud Run. You’re going to enjoy this one, and seeing what’s now possible.

    I’m looking forward to this week. We’re sharing lots of fun progress, and demonstrating some fresh perspectives on what app modernization should look like. Enjoy watching!

  • I’m looking forward these 7 sessions at Google Cloud Next ’20 OnAir (Weeks 5 + 6)

    Nearly halfway through the “Summer of Google”, there’s been some significant announcements, and plenty of interesting talks. We’ve shared the names of some new Google Cloud customers—Deutsche Bank, Goldman Sachs, Spotify, Best Buy and more—and announced some pretty cool stuff—think Confidential VMs, BigQuery Omni, a Certificate Authority Service, a new undersea cable, a cloud migration program, plus the usual barrage of new things we’re constantly shipping for you. The conference is still free to sign up for, and you can catch up on everything you’ve missed.

    Week five content is available on August 11, and week six material is binge-able on August 18. Week five is all about Data Analytics and the focus of week six is Data Management and Databases.

    Here’s what looks good to me in week five:

    These sessions look appealing in week six:

    It was hard to just pick a few talks! Check those out, and stay tuned for a final look at the last three weeks of this summer extravaganza.

  • Think all Kubernetes look alike? Look for differences in these six areas.

    Think all Kubernetes look alike? Look for differences in these six areas.

    I feel silly admitting that I barely understand what happens in the climactic scene of the 80s movie Trading Places. It has something to do with short-selling commodities—in this case, concentrated orange juice. Let’s talk about commodities, which Investopedia defines as:

    a basic good used in commerce that is interchangeable with other goods of the same type. Commodities are most often used as inputs in the production of other goods or services. The quality of a given commodity may differ slightly, but it is essentially uniform across producers.

     Our industry has rushed to declare Kubernetes a commodity, but is it? It is now a basic good used as input to other goods and services. But is uniform across producers? It seems to me that the Kubernetes API is commoditized and consistent, but the platform experience isn’t. Your Kubernetes experience isn’t uniform across Google Kubernetes Engine (GKE), AWS Elastic Kubernetes Service (EKS), Azure Kubernetes Service (AKS), VMware PKS, Red Hat OpenShift, Minikube, and 130+ other options. No, there are real distinctions that can impact your team’s chance of success adopting it. As you’re choosing a Kubernetes product to use, pay upfront attention to provisioning, upgrades, scaling/repair, ingress, software deployment, and logging/monitoring. 

    I work for Google Cloud, so obviously I’ll have some biases. That said, I’ve used AWS for over a decade, was an Azure MVP for years, and can be mostly fair when comparing products and services.

    1. Provisioning

    Kubernetes is a complex distributed system with lots of moving parts. Multi-cluster has won out as a deployment strategy (versus one giant mega cluster segmented by namespace), which means you’ll provision Kubernetes clusters with some regularity.

    What do you have to do? How long does it take? What options are available? Those answers matter! 

    Kubernetes offerings don’t have identical answers to these questions:

    • Do you want clusters in a specific geography?
    • Should clusters get deployed in an HA fashion across zones?
    • Can you build a tiny cluster (small machine, single node) and a giant cluster?
    • Can you specify the redundancy of the master nodes? Is there redundancy?
    • Do you need to choose a specific Kubernetes version? 
    • Are worker nodes provisioned during cluster build, or do you build separately and attach to the cluster?
    • Will you want persistent storage for workloads?
    • Are there “special” computing needs, including large CPU/memory nodes, GPUs, or TPUs?
    • Are you running Windows containers in the cluster?

    As you can imagine, since GKE is the original managed Kubernetes, there’s lots of options for you when building clusters. Or, you can do a one-click install of a “starter” cluster, which is pretty great.

    2. Upgrades

    You got a cluster running? Cool! Day 2 is usually where the real action’s at. Let’s talk about upgrades, which are a fact of life for clusters. What gets upgraded? Namely the version of Kubernetes, and the configuration/OS of the nodes themselves. The level of cluster management amongst the various providers is not uniform.

    GKE supports automated upgrades of everything in the cluster, or you can trigger it manually. Either way, you don’t do any of the upgrade work yourself. Release channels are pretty cool, too. DigitalOcean looks somewhat similar to GKE, from an upgrade perspective. AKS offers manually triggered upgrades. AWS offers kinda automated or extremely manual (i.e. creating new node groups or using Cloud Formation), depending on whether you used managed or unmanaged worker nodes.

    3. Scaling / Repairs

    Given how many containers you can run on a good-sized cluster, you may not have to scale your cluster TOO often. But, you may also decide to act in a “cloudy” way, and purposely start small and scale up as needed.

    Like with most any infrastructure platform, you’ll expect to scale Kubernetes environments (minus local dev environments) both vertically and horizontally. Minimally, demand that your Kubernetes provider can scale clusters via manual commands. Increasingly, auto-scaling of the cluster is table-stakes. And don’t forget scaling of the pods (workloads) themselves. You won’t find it everywhere, but GKE does support horizontal pod autoscaling and vertical pod autoscaling too.

    Also, consider how your Kubernetes platform handles the act of scaling. It’s not just about scaling the nodes or pods. It’s how well the entire system swells to absorb the increasing demand. For instance, Bayer Crop Science worked with Google Cloud to run a 15,000 node cluster in GKE. For that to work, the control planes, load balancers, logging infrastructure, storage, and much more had to “just work.” Understand those points in your on-premises or cloud environment that will feel the strain.

    Finally, figure out what you want to happen when something goes wrong with the cluster. Does the system detect a down worker and repair/replace it? Most Kubernetes offerings support this pretty well, but do dig into it!

    4. Ingress

    I’m not a networking person. I get the gist, and can do stuff, but I quickly fall into the pit of despair. Kubernetes networking is powerful, but not simple. How do containers, pods, and clusters interact? What about user traffic in and out of the cluster? We could talk about service meshes and all that fun, but let’s zero in on ingress. Ingress is about exposing “HTTP and HTTPS routes from outside the cluster to services within the cluster.” Basically, it’s a Layer 7 front door for your Kubernetes services.

    If you’re using Kubernetes on-premises, you’ll have some sort of load balancer configuration setup available, maybe even to use with an ingress controller. Hopefully! In the public cloud, major providers offer up their load-balancer-as-a-service whenever you expose a service of type “LoadBalancer.” But, you get a distinct load balancer and IP for each service. When you use an ingress controller, you get a single route into the cluster (still load balanced, most likely) and the traffic is routed to the correct pod from there. Microsoft, Amazon, and Google all document their way to use ingress controllers with their managed Kubernetes.

    Make sure you investigate the network integrations and automation that comes with your Kubernetes product. There are super basic configurations (that you’ll often find in local dev tools) all the way to support for Istio meshes and ingress controllers.

    5. Software Deployment

    How do you get software into your Kubernetes environment? This is where the commoditization of the Kubernetes API comes in handy! Many software products know how to deploy containers to a Kubernetes environment.

    Two areas come to mind here. First, deploying packaged software.  You can use Helm to deploy software to most any Kubernetes environment. But let’s talk about marketplaces. Some self-managed software products deliver some form of a marketplace, and a few public clouds do. AWS has the AWS Marketplace for Containers. DigitalOcean has a nice little marketplace for Kubernetes apps. In the Google Cloud Marketplace, you can filter by Kubernetes apps, and see what you can deploy on GKE, or in Anthos environments. I didn’t notice a way in the Azure marketplace to find or deploy Kubernetes-targeted software.

    The second area of software deployment I think about relates to CI/CD systems for custom apps. Here, you have a choice of 3rd party best-of-breed tools, or whatever your Kubernetes provider bakes in. AWS CodePipeline or CodeDeploy can deploy apps to ECS (not EKS, it seems). Azure Pipelines looks like it deploys apps directly to AKS. Google Cloud Build makes it easy to deploy apps to GKE, App Engine, Functions, and more.

    When thinking about software deployment, you could also consider the app platforms that run atop a Kubernetes foundation, like Knative and in the future, Cloud Foundry. These technologies can shield you from some of the deployment and configuration muck that’s required to build a container, deploy it, and wire it up for routing.

    6. Logging/Monitoring

    Finally, take a look at what you need from a logging and monitoring perspective. Most any Kubernetes system will deliver some basic metrics about resource consumption—think CPU, memory, disk usage—and maybe some Kubernetes-specific metrics. From what I can tell, the big 3 public clouds integrate their Kubernetes services with their managed monitoring solutions. For example, you get visibility into all sorts of GKE metrics when clusters are configured to use Cloud Operations.

    Then there’s the question of logging. Do you need a lot of logs, or is it ok if logs rotate often? DigitalOcean rotates logs when they reach 10MB in size. What kind of logs get stored? Can you analyze logs from many clusters? As always, not every Kubernetes behaves the same!

    Plenty of other factors may come into play—things like pricing model, tenancy structure, 3rd party software integration, troubleshooting tools, and support community come to mind—when choosing a Kubernetes product to use, so don’t get lulled into a false sense of commoditization!

  • I’m looking forward these 6 sessions at Google Cloud Next ’20 OnAir (Weeks 3 + 4)

    Google Cloud’s 9-week conference is underway. Already lots of fun announcements and useful sessions in this free event. I wrote a post about what I was looking forward to watching during weeks one and two, and I’m now thinking about the upcoming weeks three and four. The theme for week three is “infrastructure” and week four’s topic is “security.”

    For week three (starting July 28), I’m looking forward to watching (besides the keynote):

    For week four (starting August 4), I’d like to watch:

    Should be another educational two weeks. Join in and learn some new stuff.