I learn best by doing. And recently, most of the projects I’ve been building are either REST or gRPC-base services deployed as container images into Cloud Run on GCP. That means that I increasingly find myself recreating a lot of the same infra and app deployment flows.
Why not Medium My main reason for migrating off Medium was the paywall Medium introduced while back. I actually understand why they did it. The unlimited access price: $5/month ($50/year) is too high, but still, I get it. For me though, the objective was to allow readers to easily discover and read my posts.
Increasing large amount of technical news I read come from the posts shared on Hacker News or on Twitter. While both of these services have search options, neither of these seem to be advanced enough to narrow my searches at the desired level or to setup automatic delivery.
All complexity needs to be abstracted, right? This reductionist statements misses nuance around the inherent cost/benefit tradeoffs, especially when you consider these over time. Don’t get me wrong, there often are good reasons for additional layers to make things simpler (grow adoption, lowering toil, removing friction, etc.
I recently joined the Office of CTO in Azure at Microsoft and wanted to ramp up on one of the open source projects the team has built there called Dapr. Dapr describes itself as: A portable, event-driven runtime that makes it easy for developers to build resilient, microservice stateless and stateful applications that run on the cloud and edge and embraces the diversity of languages and developer frameworks.
We are entering a period where custom, highly-optimized, vertical solutions are becoming viable option again. This is a good news for ISVs with proven domain expertise and skilled development resources. Why do I think so? We now have: Plethora of feature-rich developer frameworks, message queues, scalable data stores, and even lower-level components in the OSS community with great documentation and a large number of use-case validation Growing number of custom solution companies (more than just ISVs) with existing deep vertical/domain expertise who are also increasingly now investing in hiring and training strong development teams Virtually every Cloud provider offering either a raw Kubernetes service or managed container execution platform which (regardless how you feel about these technologies) creates ubiquitous surface area that can be addressed with a single solution Yes, there still are many ways in which these custom development efforts can fail.
When dealing with file permissions in a non-root image or building apps that include static content (like css or templates), I sometime get an error resulting from the final image content mismatch with my expectations. Most of the time the errors are pretty obvious, simple fix and rebuild will do.
While the idea of a serverless platform and long running workloads does seem somewhat “unnatural” at first, smart people are already working on that (looking at you @Knative community). In the meantime, a simple approach is sometimes all you may need.
A co-worker recently told me about flic.io buttons. These button caught my attention because they can include triggers for single, double, or hold click and can be easily wired up to all kinds of actions. I instantly thought of of a few really interesting applications.
Next week, April 9–11, Google will be hosting this year’s Cloud Next Conference in San Francisco. The conference is already sold out, but there will be a livestream from keynotes and video available shortly after the sessions. This year, we have a lot of content to share, and I have the privilege of presenting in four sessions — and hope to do at least six live demos.