I previously blogged about and summarized the Lean Startup methodology. In this blog post I will go deeper into its first phase, which is "customer discovery".
If you hang out in startup circles like I do, then you may have heard of the “Learn Startup” methodology. But what is it exactly? I’ve been researching Lean Startup and in this blog post I will summarize what I’ve learned, explain what new insights this research has given me, and talk about future research and blogging directions.
The development and deployment of modern apps is very different from how it used to be. Networked applications are now very common. Development at scale is now common: hundreds of developers working on a system, which may be split into many microservices. Deployment at scale is now also common: apps serving millions of users. Various practices emerged, or became popular, to deal with these new challenges. I've learned many practices over the past decade, but resources that describe these practices appear to be scattered. This post is an attempt to inventorize the various practices that are used for the development, deployment and management of modern apps.
Turns out running a company isn’t just about money, fame or even cool products and happy customers. We have a social responsibility towards our employees and society at large.
On 2018 May 25, Europe’s General Data Protection Regulation (GDPR) will start being enforced. The GDPR defines strict rules on how personal data should be handled. But there is a lot of fear and controversy about the GDPR from people worldwide. With the controversial concepts, the compliance overhead and hefty multi-million fines, is it a good idea for non-EU companies to simply ban all EU visitors from accessing their websites?
It has often been stated by business consultants and startup advisors that a company should have a purpose beyond vision. Studies show that that result in more motivated and loyal customers and employees. As Simon Sinek said: people don’t buy or follow what you do, but why you do it.
I agree. That was the easy part. But how do you actually define a good purpose? People need to feel that your purpose is aligned with their own values, and a purpose statement needs to balance many different things for many different people.
This post documents the start of my journey in an attempt to find answers.
I have been researching how the Kubernetes Ingress system works. My use case is to setup an autoscaled Nginx cluster that reverse proxies to Pods in multiple Deployments. It wasn't immediately obvious how to do this. By default, Pods in Kubernetes are not supposed to be reachable from outside the cluster. One makes them reachable either by associating those pods with a Service of the right type (i.e. either NodePort or LoadBalancer), or by defining an Ingress. But what is an Ingress? How do I put Nginx in between an Ingress and a set of Pods? This post describes my journey through the jargon-loaded Kubernetes documentation which does not hold any hands, as well as my journey through the Kubernetes source code, all in a quest to find answers.
This post a bit long, so if you just want a summary then you can skip straight to the conclusion at the bottom.
Even though I rejected Prometheus as a choice in my last blog post about Netdata, I actually appreciate Prometheus' engineering quality. From its documentation it is apparent that the authors are very experienced on the subject and have thought through things.
This post reviews some of the things that demonstrate that, namely their responses to the push vs pull debacle, the way they limit Prometheus' scope, the way their alerting system is designed and documented, and the way they treat storage.
I have been looking for an easy-to-use monitoring solution for Phusion's servers. One that does not require a lot of setup and that provides a reasonable interface without too much work. Such a solution has to display a bunch of graphs at the very least. (Email) alerting is considered a bonus. The solution also has to be open source, not only because of the cost factor but because I want to own my data. So solutions like New Relic and Datadog are out.
In this blog post I will describe the solutions that I've checked out – Ganglia, Monit, Munin, Prometheus, Grafana – and why I didn't like them. Then I will explain why I think Netdata is a good choice and review its pros and cons.