Johannes' Bio
Today we're talking to Johannes Haux. He is a co-founder and COO at Sysmagine, helping users optimize their code review workflows with his tool MergeBoard. Even though he's just recently got out of his uni days, he's already helping companies relieve the pain caused by inefficient code reviews.
In this interview, Johannes will share the pros and cons of using managed AWS services during app development, tell how to avoid vendor lock-in while employing those, and uncover the unmanaged alternatives. So, without further ado, let’s get to reading!
Questions
Nat: Could you tell a little bit about your company Sysmagine?
Johannes: We, as Sysmagine, are developing a code review tool called MergeBoard. With MergeBoard, we help teams of developers to faster code reviews without compromising on review quality with some intelligent change visualization.
Nat: The topic for today that has been chosen is "Cloud vendor lock-in, should you go for AWS?" while building your tool. So if you had to convince me in one sentence about why to avoid vendor lock-in, what would it be?
Johannes: I'd go for: "Avoid vendor lock-in to keep your freedom to switch to any provider you like, to the cost-benefit that suits you best, to the cost-benefit ratio that suits you best at any time".
Nat: What are the best practices to avoid vendor lock-in?
Johannes: To answer that question, I think we have to take a step back. First, think about why vendor lock-in is so common? What we see is that companies like AWS and Google Cloud Services pitch you this idea of having the tech at your fingertips to build this scalable app, just like that. And, honestly, you can get started super quickly with those tools. The thing is, if you build an app solely based on those cloud services, you're building something very complex with a lot of black boxes. And yes, it's super optimized for being scalable, usually. But this beautiful quote from Sir Tony Hoare says, "Premature optimization is the root of all evil."
And I think this is something we need to take into account here. Usually, when starting to build something, you don't know your bottlenecks. So, you really need to think about this question first.
Do we need something complex and scalable when we start building a product or a service? And if the answer to that question is "No," I'd say the best practice to avoid vendor lock-in is just to go with open-source alternatives. The GitHub repos are full of alternatives listed to AWS services, Google Cloud Services, etc. And you can run those on any provider if the answer you're not locked in.
But, if the answer is yes, we'll need something scalable. Right now. One way to avoid lock-in would be to go for services that use an API that is shared between different providers. For example, Amazon's S3 object storage shares an API with other providers. And, when you want to switch the provider, you can do that very easily without having to rewrite all your code. So you're not very locked in into that part. So I think that those are some practices that can help you not get locked in so easily.
Get our premium e-book with SaaS and Tech interviews + industry predictions for 2023 for free.
Nat: Is it cost-effective to avoid vendor lock-in? How would you compare those costs of developing a system using managed AWS services versus unmanaged alternatives?
Johannes: That's the core question, right? Should I build it myself? Or should I buy it? And I think one interesting aspect is that this question implies the way we compare those AWS and unmanaged services.
On the one hand, managed services give a low-barrier entry and a whole bunch of functionality that can be used right away. And, at least, in the beginning, they're super cheap to get started with. What I mean is even if you're a student or a startup, you can just start building stuff for free.
If I compare that with "I have to write my own software, maintain my servers and Docker containers, run updates" situation, I'd say, let's go with AWS. But that's too superficial as a comparison. Because what is not mentioned there is that using managed services introduces a whole lot of complexity.
First of all, you cannot run it on your local machine. So, if you have to run tests in your own CI pipeline, you'll always have to connect to the cloud service and run all the logic there first. And that's not only some kind of hassle to set up, it's also expensive because service providers will charge you for that.
You may say: "Maybe I could use cloud servers and docker containers that are more cost-effective. It might cost me more in the beginning to set everything up. But in the long run, I will save costs."
But, the other thing about AWS is that you're introducing a whole lot of black boxes into your software stack. And it can become a problem over time. Of course, you can read the API documentation. But building something you're on your own, having that box cracked open lets you work with code far differently than if you just book the service and be done with it. Moreover, even if you have a managed service, you will still have to configure and maintain it by yourself. So, it might be easier to start out with managed services. But it's still a lot of work to be put into.
“Premature optimization is the root of all evil”
Nat: What are the pros and cons of avoiding vendor lock?
Johannes: One of the pros is that you can always choose the best provider based on features and price down the road. Also, keep in mind that you don't have to build a whole app. With Amazon services, for instance, you can also use just one small part that needs to scale. And once you've figured that out and know your bottleneck, you can really choose and go for the right service there.
Another "pro" is that you have control over the complete infrastructure. I'd say it gets way easier without black-box components. You know, the documentation is good. But if you can take a look at the code itself, you can see what's actually happening.
Sometimes funny stories come out when you're trying to avoid costly mistakes. I recall there was this one story where a small startup went on television and said: "Hey, we have this app, check it out" And then a whole bunch of people went to the website, and Amazon Cloud build price went to $10,000 per month, but they didn't actually convert anybody. They didn't gain any customers! Of course, it's nice that the website works smoothly, but it cost them a whole bunch of money, and nothing really was gained.
You don't always need the kind of scalability that AWS offers. And sometimes, it's okay if the site just runs a bit slower. And even if you notice that you need a performance upgrade there, you can still upgrade later on, especially if you're a startup.
Now, to the "cons" or "reasons why you might want to log into a vendor", I'd say. For example, if you use a bunch of services from one vendor, you usually have a nice dashboard or tool to manage those services altogether. That is something really handy. It's super easy to get started and is especially beneficial if you want to do rapid prototyping and test with real users out there. I think that it just makes sense, even if a small team tries that.
Also, if you're about to make a business decision, don't be afraid to face vendor lock-in. Knowing that there's going to be high fluctuation in demand, it's a great decision to go with a managed services provider if you're ready to pay for it.
Nat: Are infrastructures as code tools like TerraForm capable of providing a true non-vendor locked-in experience. Is it possible?
Johannes: To be honest, I haven't used TerraForm myself, but I actually checked out the product. It looks really great to me. What TerraForm offers you is a spin-up of cloud servers. For example, Docker containers on those servers use a simple config file. And then, you can specify which provider you want those servers from and on which server, you can just run your Docker images. This actually helps you not get locked into any one of those providers.
Now, the moment you start using services by providers in your Docker images, that's a whole nother story. You have to be careful there, you have to differentiate. But if you're only using this spinning-up service simple feature, that's really cool. I think that's where TerraForm can help you not end up being locked in. Tools like TerraForm and Kubernetes help you build scalable apps. You can set automation in Kubernetes, and if your load is increasing, it spins your Docker images. And TerraForm lets you do this by hand.
But again, I think you have to ask yourself first: "Do I need to be scalable right now"? Because resources on-demand are always expensive in the end. And if you can use a bunch of dedicated servers, as Stackoverflow does, I think this wouldn't be a great solution.
But if you know what your demand is, and that it will increase steadily, and you want to spin up the service easily on TerraForm, it looks like a good solution.
Nat: If you met 10 years old Johannes, what would you tell him?
Johannes: I'd tell him to enjoy life as it is: go play with his friends and do his homework. Well, homework is important, yet not as important as friendship. So, rather go play with your friends.
Rapid-fire round
Who is your business hero?
It's not really a business hero, but I'd say a successful hero. And that's my wife, to be honest. My wife was super successful at school while she was studying and is successful now in various jobs she's done. That's super impressive to me. She is, incidentally, also the one who allowed me to be able to run a startup. Because, in the beginning, we were still bootstrapping. And I didn't have that kind of income. So without my wife, I wouldn't be here.
What's your great achievement that's not on your CV?
When I was still going to school, I was really into filming and doing the movies. And of course, at some point, somebody comes to you and asks: "Can you film our theater thing?" And I did one project early on, where I filmed a theater play in the church. Eventually, the DVD of that sold really, really well. This got me into this mindset of "if I do something people want, I can charge them money for it." And this is how I financed my first real camera. That was a wonderful experience, business-wise.
What is your biggest regret?
One thing I realized quite late is that I have led a very privileged life, and that allowed me to be very slack during my studies. So, during my Bachelor's, I studied physics, and I was more into partying than studying. And that was a bad thing. But during my master's, I realized: "Wait, if I do my homework, this could be fun because I can also learn a whole bunch of stuff."
This attitude helps me everywhere in life now. This realization that sitting yourself down, doing your homework, and working things through really helps you think. So, a big regret for me is that I got this realization late. I don't know how to counter that. But I would have liked to know that earlier.
Which profession would you choose if you weren't a COO of Sysmagine?
It’s tough. I like the project management aspect of things while also being very technical about the problem you want to solve.
Also, one beautiful thing I learned during my time as part of Sysmagine is I got to know a lot of people. And working with people is something I really enjoy. So, I think this aspect I would focus on in the future.