“Why do you hate us?”
— anonymous developer at hackathon.
When I started my new job as a technical writer, I heard this one anecdote a bunch of times. Basically, the story went something like this:
A developer evangelist had organized a hackathon — he was trying to get developers to use an SDK that my company had just released. But everyone was struggling. The documentation was out of date, confusing and hard to navigate. People followed the instructions diligently, but they never got the right results.
At some point, a developer approached the evangelist and asked: “Why do you hate us?” …
You rarely set out to be a data exhibitionist. It happens surreptitiously . Someone puts an internal tool in the cloud. A project is quickly hacked together then used in production. Before you know it you’re exposing database ports to anyone sniffing around. And believe me, there are hordes of predators prowling for ports.
Take the (fairly) recent “meow” attack during the week of July 20–26. Perhaps you’ve heard about it?
Ongoing Meow attack has nuked >1,000 databases without telling anyone why
…was the headline that ran in Ars Technica on July 23 of that week.
“More than 1,000 unsecured databases so far have been permanently deleted in an ongoing attack that leaves the word “meow” as its only calling card, according to Internet searches over the past day.” …
Exponential growth is exciting but can come with an unwanted side effect — rushed technical decisions and technical debt. Some technical debt is fine as long as it’s handled strategically. But there’s one aspect of technical debt that always seems to get out of control: data orchestration and consistency. And we want to do something about it. We’re working on a free, open-source solution that helps smaller companies to keep their data consistent and to orchestrate it to different business systems.
I’ll be sharing our plans with you in a minute, but first I need to clarify what I mean by data orchestration and outline the problem that we’re trying to solve. …
When deploying complex SaaS platforms, secrets can quickly become the bane of one’s existence. I once wrote about how we ran out of space for our environment variables (in Elastic Beanstalk) because we had so many API keys and secrets. But those were the bad old days.
Things got better after we discovered Berglas. It’s an open-source tool that interfaces with Google Cloud services while at the same time abstracting away all the complexity. Under the hood, it uses the Key Management Service (KMS) to encrypt secrets and Storage Buckets to store them. …
Whether you love it or hate it, Helm is a ubiquitous tool for managing Kubernetes applications. You can use it in many different ways which is great, but can also be overwhelming.
We’ve noticed that a couple of questions keep popping up:
I’m going to try and address these questions based on our experience with the startups in our portfolio but I also draw on the perspectives of larger organizations too. …
GitHub actions and workflows are great. We use them to deploy a web app to different cluster environments and I want to show you how we did it. Hopefully, this helps to simplify your deployment process as well. I’ve also written a companion article that describes our GitHub workflows for continuous integration.
Here, we’ll focus on our continuous deployment process:
Our continuous deployment workflow has four jobs. It includes the same jobs that we had in our continuous integration workflow, as well as two extra jobs:
Recently, we started a new project and it decided it was a good time to try GitHub’s newish CI/CD tools which became generally available in November last year.
Our experience with GitHub actions has been mostly positive, so I thought I’d share how we use it in production.
This article is the first part of two — one article for each workflow.
For anyone teleconferencing business, the great lockdown of 2020 was like a shot of adrenaline. Not just for mainstream players like Zoom, but also for vendors that serve niche industries such as healthcare. The surge in demand for telemedicine has prompted more startups to pivot to video calling.
Take Klara for example, a digital health startup who got video calling up and running in just over a week. A phenomenal achievement considering they had no experience with videotelephony. What factors contribute to such a well-executed pivot? Generally speaking, you need the right leadership, product and engineering teams, company culture and of course the right timing. …