DEV Community: Igor Zalutski

I built a tool that analyses your code and configures AWS to run it

Igor Zalutski — Thu, 16 Jun 2022 14:35:03 +0000

Almost 2 years ago my cofounder and I started building Digger. It took us a year, and last summer we have finally shown it to the world. We launched Digger quite successfully on ProductHunt as well as and on HackerNews. But it wasn’t instant product-market fit we hoped for. More like, different people were using Digger for different reasons.

Then we launched a few follow-up products with more focused value propositions like UI (Lemon), or multi-cloud (Alicorn), or databases (Hippobase). We learned a lot from the early adopters (thank you!!). The biggest learning was that we were trying to solve too many problems at once, and that confused our users a great deal.

So we went back to the drawing board. We have radically simplified the UI, especially onboarding. We asked ourselves - what is the one thing our users care about most? And we started launching what we thought were features as separate products. Some of them flopped (remember Serverful?) - and so we killed the feature. Others succeeded, like one-click sample app setup (AWS Bootstrap) and most recently Terragen that automatically generates infrastructure-as-code.

And then we wondered: is there something in common with the products that were received warmly? Turns out, there is - speed. In hindsight it is obvious that speed matters a great deal. Because it is not uncommon to spend more time on setting up AWS infrastructure for your app than building the app itself.

Then we thought, what would the fastest developer experience with AWS infrastructure look like? Making each step as fast as possible seemed like a good start:

the fastest way to get the code
the fastest way to determine what infrastructure is needed
the fastest way to provision that infrastructure on AWS

.#1 can be solved by one-click Github repository connection, like in Vercel. It doesn’t get much faster than that

.#3 can be solved by generating and running Terraform (this is what Terragen does)

.#2 presents the biggest challenge. How do we know what kind of infrastructure is needed?

After a great deal of not making much progress we realised something: all the information is already in the code! Because if you show your app to a DevOps engineer they wouldn’t need to ask many questions, they would just see the code and instantly know whether it’s a front-end (then it would require an S3 bucket and a CDN) or a back-end or a lambda function.

We can easily detect the language and the framework, Dockerfile, lambda handler, read package.json, things like that. Then we can feed it into the Terraform generator, then run terraform apply on our servers against user’s AWS account. This makes the entire flow completely seamless: connect your github repo → connect your AWS account → click “Deploy”. As simple as that.

And this is Flywheel. Give it a try!

Digger.dev: A new kind of PaaS

Igor Zalutski — Wed, 21 Jul 2021 17:57:36 +0000

We've just launched on HackerNews!

Say you want to deploy a Node app. Or a Python app. Or a Rails app. And maybe one or two React or Vue frontends as well. Oh and a database too.

You have 2 options:

Traditional PaaS like Heroku. Going to be quick and easy. But also expensive and you can't build much beyond the very basics.
AWS or GCP or Azure. That's going to be hard and slow, unless you have DevOps expertise. But with over 200 services you can build pretty much anything.

Why isn't there an easy way to start on AWS without spending days figuring it out? We thought so as well, and built Digger.dev

Digger makes AWS simple

It automatically generates infrastructure for your code in your AWS account. So you can build on AWS without having to deal with its complexity. See How it works

You can launch in minutes – no need to build from scratch, or even think of infrastructure at all

✅ Easy to use Web UI + powerful CLI
✅ Deploy webapps, serverless functions and databases: just connect GitHub repositories
✅ Multiple environments: replicate your entire stack in a few clicks. Dev / staging / production; short-lived for testing; per-customer
✅ Zero-configuration CI with GitOps: pick a branch for each environment and your services will be deployed on every git push
✅ Logs, environment variables, secrets, domains: never touch AWS again!

A PaaS that generates Terraform

... So that you keep the full power of AWS

Traditional platforms-as-a-service (PaaS) like Heroku or Vercel run your code on their servers. Digger takes a different approach: it generates infrastructure-as-code (Terraform) that manages your AWS account. See Digger vs Ohter

This removes the main limitation of traditional PaaS. With Digger you can have great modern developer experience and get a future-proof stack at the same time. Terraform is industry standard for all things DevOps; with Digger you can customise every bit. You can even use your own bespoke templates with Digger. So unlike traditional PaaS, you never outgrow Digger.

What do you think?

We've just launched and super hungry for feedback. Try it out!

Tools you love vs tools you use at work

Igor Zalutski — Fri, 09 Jul 2021 01:08:37 +0000

Something weird is going on. On the one hand, there are amazing tools out there that allow you to build applications quickly without thinking of infrastructure. Tools like Vercel, Heroku, Firebase, Netlify. On the other hand, most teams keep building on AWS or GCP, seemingly ignoring these amazing tools for all but the smallest of projects. How come? Aren’t we all supposed to be serverless by now?

The cost of great developer experience

What makes Vercel and Heroku amazing is simplicity. Just connect a repo (or push your code) and see it live in a few seconds. Perfection! It just works. How? You’re not supposed to think about that, it’s been handled by the platform.

That’s all great, until you need a bit more than a PaaS can offer. Things like block storage for example, or private networking, or pub-sub, or a specific kind of a database. There are many of them, you know - not just relational. And there is a reason why each exists.

But building such a stack now presents a problem. Your apps work just fine on a PaaS; you only need one extra piece that can be built say on AWS. So you end up spreading your stack across multiple providers. Frontends are running on Netlify, backends on Heroku, databases on AWS. All over public network of course. And then there is a problem of latencies and multi-region setups. Things got to be close to each other to be fast, but there aren’t that many regions to choose from on a PaaS. The only option now seems to be to move to AWS (or GCP).

The cost of great flexibility

This migration of course could have been avoided altogether if you had started on AWS right away. Maybe the developer experience is not that great, but then at least you can be sure that your future needs are covered. In fact most startups do just that – and Amazon as well as Google and Microsoft are happy to extend generous free credits to them.

At this point startups are split in two distinct groups: those who have DevOps expertise, and those who don’t. The former are doing alright, perhaps moving a bit slower, but just a bit. They get their developer infrastructure in place rather quickly, set up CI / CD pipelines, and start shipping. That group is a minority though, roughly 10-15% of all startups. The remaining 90% don’t have in-house DevOps expertise. And that’s where it becomes really painful.

AWS has over 200 services. Say you’re building a simple web app with a backend, frontend, and database. Should you deploy it into EC2? Or ECS? Or EKS? Or Lambda? Or Fargate? Or Beanstalk? What’s a VPC? How do I make my service public? And so on. It’s not clear at all. And so those unfortunate teams without DevOps expertise can either move slow by trial and error, or hire a DevOps engineer. Which to a startup is a tough decision with consequences. This essentially means hiring one less engineer to work on the product…

But what about infrastructure as code?

It’s great. Terraform is a de-facto standard for DevOps work, other tools like are either niche (Pulumi) or badly designed (CloudFormation). But infra-as-code does not solve this dilemma. But you still need to think in the exact same terms as without tools. So they aren’t making it any simpler – they are solving a different problem (infrastructure consistency). Present-day IaC tools are a bit like assembly language: total precision, zero abstraction.

There must be a better way

Just imagine if building mobile apps was like that. To start building an app you use one combination of IDE, language and toolchain. Then when it matures you rebuild the whole thing in a different language, with a different IDE, using a different toolchain. Ridiculous, isn’t it?

So can we not somehow combine the developer experience of tools like Vercel with flexibility of major cloud providers? So you could start small, move fast with reasonable defaults, then add customisation without the need to rebuild from scratch? Wouldn’t that be… normal?

That’s what we thought – and built Digger.dev. It automatically generates infrastructure for your code in your AWS account. It has a nice web UI so you can deploy your apps and services in a couple clicks. But under the hood is Terraform. So when time comes you can customise or even completely replace it. But only if you need to.

We have just launched and hungry for feedback - check it out!