Discover the evolution and cutting-edge practices in measuring engineering velocity! For software teams, mastering this metric isn't just about numbers—it's a journey towards consistent value delivery, process enhancement, and turning velocity into a catalyst for continuous growth, not just a measure of judgment.
My view is that there are areas where GCP is better and areas where AWS is better. AWS has a much bigger community, and better business continuity story. GCP has a better developer experience and more uniquely-amazing best-in-class products (e.g. Spanner, Cloud Run, BigQuery). In the end, I don't believe Google will shut down GCP.
At Coherence (withcoherence.com) - I'm a cofounder - we deliver a developer platform that lets use use either cloud in a developer-friendly way. It also gives you some protection against lock-in to either cloud.
At Coherence (withcoherence.com) we are building a slightly different twist on this where one configuration can drive different environments across the SDLC - Cloud IDE for dev, full-stack branch previews, CI/CD, staging/qa/UAT, production - with deployments in your own AWS/GCP account.
We generally see a ton of velocity increase in dev from teams that adopt the Cloud IDE alongside the rest, as exhibited by lots of comments. Internally, we dogfood them 100% and the team would never go back to the old "local-first" ways. So we are using them and love them. The key qualities we love are ephemerality, parallelism, and accessibility. But in general there is a lot of resistance for various reasons, as seen in many comments here.
I can't tell you how frustrating it is to see new cloud IDEs come up that don't adopt the containers.dev standard. It's published, it's open, please don't NIH this.
Devpod did this right. Gitpod is actively working on supporting it. No I one hundred percent do not want to use your coherence.yml files instead.
Please contribute to the standard if it's not flexible enough. That's what I'm saying. We need to standardize on a format and stop mucking about with ten thousand different ways of declaring a thing. Devfile, devcontainer, whatever. Just please pick an existing, open standard and upstream changes.
The best answer to keeping your workstation clean & secure is, in my view, a thin-client paired with ephemeral remote environments:
Immutable or chain-of-trust based host OS (e.g. nix or iOS)
Minimal software installed (including docker, which itself is heavy and full of vulns or opens the door to them)
Do everything on ephemeral remote environments where the configuration is stored in reviewable tools (e.g. GitHub) and the state can be wiped at will. This means you reduce your surface area for persistent malware to supply chain and network attacks, which require careful practices to avoid but which are well-understood
Remote envs are preferred to local virtualization (e.g. quebes) because they lend themselves to team use and sharing more, and so are more likely to be widely adopted and collectively improved. Also easier to create different hardware configurations as needed (when you need a bigger GPU temporarily), as well as different environment types - e.g. always-on previews for QA testing. Also eliminates persistent paths in the local OS for malware storage
I consider the "best-in-breed" tools with this shape to break into the following categories:
"Infra Abstractions": DuploCloud, Massdriver, Stacktape
"PaaS in your own cloud": Nullstone, Zeet, Quovery, Porter, Architect.io, FlightControl
"SDLC Platform for Teams": Coherence (withcoherence.com) - the key difference here is in how CI/CD (incl integration tests) are handled, how development environments are configured alongside other environments, and how production is segregated from other environments.
This a somehow both a crowded space and an emerging one. But we believe that even with the diversity of choice that there are clear reasons that most teams will by (vs. build) their internal dev platform in the future: namely the cost to buy vs. to build/maintain, and the productivity from better tools.
We are from DuploCloud and hence the following note might be biased. The downside of a pure paas solution like porter, Quovery at al. is that they have a limited scope say kubernetes, pieplines and diagnostics. All of the lower layers of the Devops stack from IAM, networking, AWS services (including non containerized workloads like Lambda, EMR, Airflow etc), scores of compliance and security controls are left out of scope. Then one needs a expert Devops to write boat loads of TF. Our apporoch is of a E2E platform that should do all of what a human devops manually scripts. Thus fundamentally deliver self-service, labor reduction and compliance.
If you're building a Refine app and want to deploy it to AWS or GCP in your own account, I just posted a setup video of using Refine on Coherence (withcoherence.com): https://youtu.be/gFCXXU72Nec. We're happy to get you set up the same way if you get in touch (disclosure - I'm a cofounder).
As the CEO and cofounder of Coherence (withcoherence.com) - it's cool to see this project launch. At Coherence, we've been working fully in the cloud for the last 2 years - and it's better than I thought it would be. But it's hard to get more conservative teams to jump into a new workflow. While we've done a lot to support integration with local tools and development, I'm looking forward to seeing more innovation, and am curious to see Google invest here more directly. For us, all of this innovation is about delivering the best developer experience for end users that we can, let's see what direct IDX goes as well.
Other products to check out: codesphere, stackblitz, Replit
We are excited to introduce our latest project, The Cloud Whitepaper Index, which leverages generative AI to give you an AI-powered Cloud Architecture expert with access to almost 1,000 expert-written whitepapers from AWS, GCP, CloudFlare, Azure, and the CNCF.
If you want a similar in-cloud VSCode experience, but tied more tightly to your SDLC (e.g. CI/CD, branch previews, deployments) for each project and requiring less configuration to get a dev server running alongside it (this just lets you edit code, not run it) we offer “Workspaces” at withcoherence.com.
