Is your app slow or releases a pain that produces bugs or downtime? Are AWS, Docker, Kubernetes, and CI/CD just techie talk? What are DevOps and current server setups that ensure smooth releases and scalability of applications?
Today’s guest is Alex Becker, founder of Prioneer.io, a SaaS tool that prioritizes customer requests. Alex is a DevOps specialist by trade and discusses DevOps for Web software.
- Business Informatics: Why and how Alex got interested in DevOps
- Startups: Innovate faster—too much time spent on releases and testing
- DevOps Investment: Start early or wait until something breaks in software system?
- DevOps Defined: Set of practices that link development and operation of IT services
- DevOps Practices: Perfect tool to optimize money and speed with lower effort to start
- Deploying DevOps: Engineer sets up system to make code change via pipeline
- Tools: GitHub, Bit Bucket, or other systems that push, pull, and synchronize code
- Docker and Kubernetes: How and where do they fit in when it comes to applications
- Scalability: Application should be stateless and automatically add algorithms/instances
Read the transcript:
Victor [00:46]: Alex, welcome to the show.
Alex [00:48]: Hi, Victor. Happy to be on your show today.
Victor [00:51]: Yes, 100%. You’re an engineer, obviously you’re a software developer. How did you find your way around DevOps? Why is that so interesting for you?
Alex [01:01]: So getting into DevOps was a quite natural consequence on my path of growing as a software developer. I started to develop software about 12 years ago and I wanted to get more professional. So I started to study business informatics and worked in a startup at the same time. Business informatics was great because it emphasized on how to build complex and scalable IT systems that solve business problems. I was happy to experience at the same time how to do it with a real world application. So I was working on a cloud platform, a concept that developed and operated web applications and web services. I came in touch with DevOps practices when one company I was working at started to grow, we got more users, got more developers and more features we wanted to do or needed to do.
[02:01] We somehow felt that the way we were doing it until then takes too much involvement, that we spent too much time on releases and spend too much time for testing. We ask ourselves if we can somehow innovate faster? If we can free up our developers from spending significant amount of their time on maintenance so that they can spend more time on development again. And we thought that we need to stabilize some areas of our software system. And that’s when we started to heavily employ DevOps practices. And that’s how I got in touch with them. And that’s what made them standard for every application or software system I am trying to work on.
Victor [02:47]: Nice. And I think that story literally is a story of many, if not most startups, right? You do things, you start with like one developer, you add features, your customer base is growing. You have a certain code base that is a bit aged by now and you start hiring a few more developers. And by that time, things start getting complicated. Should people invest in DevOps very early or really just wait until things break?
Alex [03:19]: I think if you are starting new, then DevOps is overlapping greatly with most of the things that you would do anyway when you start to build a new software system and you will always go to build something in the most cost-efficient and in the way of the least resistance. So some things you should do anyway, but you should also be clear why it’s important. For example, if you’re a startup, there are two things that startups care a lot about, its money and speed. So you usually have a limited amount of money and you want to navigate fast.
[03:57] Also, you want to navigate fast again because you have limited money and DevOps can optimize money and speed, so it’s a perfect tool. And DevOps practices are usually a low effort to start when it’s with a new system. So it’s something that in practice can mean that you need less developers to build a software system. And you could build a software system with three developers maybe instead of five, where in the situation where you don’t use DevOps practices, developers are maybe busy with maintenance work or something else.
Victor [04:34]: Exactly. And we’ve kind of skipped that part, but let’s define since this is what it’s all about. Let’s define DevOps for our listeners right now. What is DevOps? What does DevOps engineer do?
Alex [04:46]: When people speak about DevOps, they usually refer to a set of practices that link the development and the operation of IT services very closely together by heavily relying on automation and on formalization. Formalization means that you have maybe your infrastructure or the configuration of your production environment written somewhere as a piece of code or configuration and can easily scale and change that. And DevOps touches a few areas like your development, like automated testing, automated releasing, and it’s not a fixed framework. It’s just a collection of practices that you use. It’s a mindset that people have. As soon as you kind of understand the goals behind DevOps, then you start to understand what practices are at the core of it and what you can use to do DevOps and what a DevOps engineer does.
Victor [05:48]: So simply said, I have a developer, a write code, it’s running as famous words. It works on my machine. I have it locally. Everything is working, but how do I get it into the cloud now? How do I deploy it? And there’s obviously the manual ways, depending on what platform one uses, whether it’s like even get pushed or something like that. And then get pulled on another side and running certain services and setting up instances of servers. That’s something that an engineer can do manually. But the goal here is to really understand what am I doing with each release? And we all want to release early and often. This next start paradigm. And to automate that, correct?
Alex [06:34]: Yes, you want to automate that and you want to free the time of your developer. At the same time you don’t want to depend on the knowledge of someone. So when your team grows and you onboard more developers, you don’t want to have everyone know how to release something because doing it manually also, as you said, can make things complicated. It can break your production system. So the goal of a DevOps engineer would usually be to set up your system in a way that the developer can just make code change and then forget about how this code change gets to production.
Victor [07:14]: Because what’s usually a part of that. You said there’s also automated testing. There are probably some other things like checking code quality. There are a few applications that do that, what’s usually involved here to make sure we have a high-quality code base that’s getting deployed?
Alex [07:33]: So usually you would have something like a deployment pipeline and try to have a flow, a continuous delivery that does all those steps for you. So therefore you would need some tooling that can execute that pipeline. And you would also need some infrastructure that is capable of releasing your service of taking your piece of code or taking your compiled artifact and executed in the cloud environment.
Victor [08:01]: And what tools do people usually use, what’s very common?
Alex [08:05]: Usually the starting point is that you have your code in a source code system, for example, Git, and that versioning system can be the base where another tool can pull something from, you would go for example, to an online service like GitHub or Bitbucket. There are a lot of popular services where you can mirror your code, where your developers can push and pull the code, that synchronizes everything. And those tools usually have means where you can set up pipelines.
[08:36] For example, we have GitHub actions or in Bitbucket, they have their pipeline system, where you can configure what steps the pipeline should do. And then you can pluck in specific tools or plug in specific technology depending applications, that run tests against your application. And it will then happen online in the cloud. There are also ways that you can set it up on your own servers. There are something like Jenkins that you can install locally, but usually when you start new and want to have as little overhead as possible, you will go for an online solution. And typically the big cloud providers also have something in place that can make all those steps for you.
Victor [09:22]: Which one is easiest to start with or implement in your opinion?
Alex [09:27]: It depends a bit on the technology that you choose. If you have a quite simple application in a popular language, today many cloud providers already allow you to just push your code or connect your repository and the cloud provider automatically has a pipeline that understands which language you’re using and can automatically provide your application into production environment and you just release. And this is a way in which you don’t even need to write the deployment pipeline anymore. You just need to write your tests, configure and set a flag that your tests are executed. And that’s it. If you don’t do it like that and to do it manually, then one popular way would be to do it in, Github actions, for example, or in Bitpocket pipelines.
Victor [10:19]: Is there a platform that you recommend, for example, for a small SaaS written in node or something like that?
Alex [10:27]: So for node, I don’t know a platform. I know that there are many platforms out for node and for react, for example, like [10:34]. I know that for maybe also Heroku can run them. And I know that the Google cloud platform supports to run those, but there are plenty of them available right now.
Victor [10:46] Perfect. Perfect. And then how does Docker play into this entire framework, which is also a very popular tool to use same as Kubernetes, where do these fit in?
Alex [11:00]: So Docker is something you should also consider to use when you start to write a new application. Docker is something that allows you to configure in your code what the runtime environment of the application is, for example, what web server this application uses. And then you can just push your Docker container to any cloud provider or any own server that understands Docker. And the cloud provider will take care of providing the appropriate environment. And this is really great because each application can tell itself what it needs and it makes you super flexible because you can all the time change the contents of your application and what it needs to run. And also you are quite independent of a cloud provider. So Docker is the kind of virtualization that removes that abstracts from the cloud provider into environment where the application is running itself.
Victor [12:02]: So it’s like a description, Hey, in order to run, I need this kind of server with this parameters, with this software installed on and any cloud provider that I choose, please just build this for me in a way.
Alex [12:14]: Exactly. You can specify what you need in there. And it’s super fast because Docker is built in a way that it’s super lightweight as compared to traditional virtualization. It takes literally seconds to startup in new Docker container. That’s why developers love to use it. They can also use it locally. And the way how Docker is, it really helps you to set up your complete environment in any new place. For example, if you have tests that need to spin up your environment and try if you function out, you can easily do it without having the overhead of setting up all those things again, that your application needs.
Victor [12:54]: And where does Kubernetes fit into all of this?
Alex [12:57]: So, as we said, Docker is the thing where the application describes what itself needs. And then Docker can run an instance of your application, but typically you don’t have one instance, but you want to serve a large customer base. You want to have redundancy so that your service has multiple instances, so that if one instance of your service malfunctions, another one can step in and Kubernetes is management software that can do those things for you. So kubernetes is something where as a developer, I can just say, Hey, here is my service, it’s written in a Docker container. And then you push it to your Kubernetes cluster and Kubernetes will take care of and scale it the way you want it. You just configure. I want it to be scaled.
[13:49] I want that when the service runs out of capacity, out of memory, I want to add more instances and Kubernetes will do that. And you don’t need to reinvent or write algorithms that scale your service for you. It can also be seen as a logical unit that combines a lot of service and memory and CPU for you. And you just push your application to that. And they run and kubernetes doesn’t care what your application does internally. It just makes sure to do all the DevOps things for you.
Victor [14:23]: Very nice. So we’re touching on scalability right now, generally, what is necessary to be able to scale an application? It is becoming slow, right? Do I go to AWS and add another instance or what else do I need to do?
Alex [14:43]: So your application needs to be written in a way that it is scalable. For example, it should be stateless. It means one instance of your application isn’t allowed to have any data insight in its memory that another instance doesn’t know about, because then your user would get an unknown state. So this is if we speak about horizontal scalability, when you add multiple instances of your service. There are different ways of scaling something. If you have an application, you could also increase the strength of your application by giving it more CPU or more memory. But this is usually not a way that allows to gracefully increase the capacity of your whole application.
[15:31] That’s why you go for this horizontal scalability, where you add instances. So you need your applications to be stateless. And since you don’t want to do this process manually, because you don’t know when you want to scale because it depends on dynamics of how often your service is used. You want it to be automatically, and it also requires your application to allow itself to be started at any time and to be shut down at any time. And to be started at any time can mean your application also needs to communicate to the cloud environment. Hey, I’m ready to take new traffic.
[16:10] I’m ready to serve customer requests. And therefore you need to consider that inside of your implementation, which is usually not a difficult thing to do, but you need to have that. And if you want to start to scale, it depends on your base situation. If you already have servers in an environment, you might want to employ a mechanism in AWS for example. They have auto scaling options where you can implement something that automatically adds new servers. If you don’t scale at all yet, you could think of employing something as kubernetes or employing some kind of service in AWS or in another provider takes care of the scaling, where you just push your application to.
Victor [16:57]: That makes a lot of sense. And is any application just scalable out of the box or should I also take a look at the code?
Alex [17:06]: You need to take a look of what your application is doing. Most applications will be scalable, but there are specific cases. For example, if your application writes data to some storage, then you need to make sure that the storage can be written from different sources at the same time. If your application has algorithms that for example, process a lot of data or import data, and you just, at additional instances, you might not win any speed or you might not make your application to be faster because your algorithms are still the same and might sequentially import some data and may even do the work redundant. So you need to make sure that your application somehow can split up or partition the data for example, by client or by region or by some specific mechanism.
Victor [18:02]: That makes a lot of sense. And what role do databases play in scalability?
Alex [18:10]: One typical bottleneck you can have in a software system is in fact, the database, because you have only one database, which takes care of writing all the data and databases are not as easily scalable because they need to take care of the state of the data. And you cannot just add more instances where each instance writes some data because then you would have an inconsistent state. It’s not possible to synchronize all the databases. And let’s say in the old world, you would think of how to maybe split up your data or create instances of your database, that only store data that is being read.
[18:53] So you can free up the instance of your database that is writing data, but in most of the cloud providers today, you can have a managed version of a database. So you just go into your cloud provider, click on create database. You maybe say how much capacity it has, how strong it is, but the cloud provider will take care of scaling the database under the hood. And you don’t really need to worry except for very specific application requirements that the database can handle your load. So this is the easiest way to start and you don’t need to take care of that if you are already in the cloud with your database.
Victor [19:36]: Cool, this is super helpful. Thank you so much. Let’s learn more about your own company. What does Pioneer do?
Alex [19:44]: So Pioneer is something which is not related to DevOps, but we are also employing DevOps practices there. Pioneer is a web tool that helps product people that are faced with many feature ideas, pain points of customers or customer feedback to identify what from all of that is truly most important to customers. So that as a product person, you can make your product better by focusing on those things. It allows product people to create stack rankings, which they can send to their users and users can rank what’s most important to them and product people can see what across all users met us the most. It’s concept that’s in a way that creates clear rankings and really helps to separate, not so relevant things from the things that matter most.
Victor [20:42]: Cool. That’s very interesting. Definitely gonna give this a try and where can we learn more about you personally?
Alex [20:48]: Personally, you can look me up on LinkedIn or write me there if you’re interested to talk about some of the technical topics or about Prioneer. You will need to scroll a bit in the list because there are many people with my name, but you will recognize me by my picture.
Victor [21:05]: We’ll link you up. Perfect. Thank you so much for coming on the show. This was super helpful.
Alex [21:11]: Thank you for inviting me, Victor. It was cool to be here.