Adrian Stanek, of Bits in Motion, joins me to relate his success story of transforming his organization's software development process via baby steps.
Solving big problems with small teams
Recording: Ladies and gentlemen, the tiny DevOps guy.
[music]
Jonathan Hall: Hi everyone, welcome to another episode of the Tiny DevOps Podcast where we talk about DevOps and all related topics for tiny companies. I'm your host Jonathan Hall. Today I have a special guest, I think Adrian you're the first podcast listener I've had on the show as a guest. Congratulations I guess. [laughs]
Adrian: Thank you very much.
Jonathan Hall: I don't have a trophy, but it's nice to have that. Adrian's been listening to the show, I don't know how long, but we got in contact several weeks ago. He told me he found me through the podcast. We had a nice conversation and we've since connected on LinkedIn. He responded to one of my daily emails about about agile transformations I think. I think I made the point that if you want to do an agile transformation, the best way is to do something today to make your team more agile and then do that again every day forever. [chuckles]
He responded to me and said that he felt that that resonated with him and he had some experiences he wanted to share about when that did and maybe it didn't work, but before we get into that, Adrian, why don't you talk to us a little bit about who you are, what your experience is with DevOps, and then we'll get into the topic. Let us know a little bit about yourself first.
Adrian: Okay. Thank you very much. First of all, thanks to have a chance to be here. I'm Adrian, as said before, and we are a system integrator based in Germany, a small company, and I'm one of the founders. We do integrations for web to print systems for customers mostly in Germany, but for companies like franchise companies Europe as well. We do it for nearly two decades now.
We had a problem with, it worked pretty well the last 10 years, but I think since two or three years, we have bigger problems with all our monolithic systems we just developed over so many years now. The biggest problems we faced is we actually weren't able to get any features out anymore. The time to market was really bad. We lost completely the overview of our systems, and for a small company like we are, it's quite a huge problem if you stop to develop your team and your workflows to get better in what you do.
You mentioned DevOps, for example, this is something we haven't implemented at all, if you like so. We weren't aware of it. Of course we used some of those techniques, but we weren't aware of that DevOps is a topic for itself. If you are not aware of that, you cannot develop a on that. Without those things, we weren't able to really think about, for example, CICD. We just used to use SVN for example for many years now and we just used deployment scripts to get our stuff to the customer.
We had no tests in place. Actually you are the person who pushed me towards test driven development. I haven't really utilized it beforehand, and my colleagues didn't do it either. The problem we had actually was that every time we go for a new feature, we wanted to deploy it, and then something else broke in the system. Somewhere, even maybe not in the system where we were actually deployed it.
We have multi-tenant systems like we deployed it on one customer and the sub modules, we used to implement broke in another system. We had no overview about that, and actually our clients became QR testers for us and they found those bucks. This is a problem, or actually is a big problem for a small company. I think the reason why we stayed small is that we work that way. Since two or three years, we tried to work on that pretty heavily.
We went away from systems, or let's say programming languages like PHP and moved to more modern languages because we think this is the future. This is the future for small companies in particular. I can talk about this a little later why we do that, but overall, we try to rethink everything we do. DevOps is a foundation. We really live that. We understood that DevOps is not a type of engineering position in a company, it's more a cultural mindset.
It took a time that every of our developers we have really get to the point what DevOps really is, or what it meant to be, or why it's important to think in that way. Operations wasn't a thing at all beforehand. We just had some IIS service where our stuff was deployed. We just pushed it on there and it was running. Operations was never a thing, we'll assist admin, and that's all, but now operations is a part of the development process, part of the development cycle.
This is pretty important to be able to deliver a quality product. We think in quality, it sounds weird to a company for 20 years not working with quality products, but it's all come down to mindset problem. We have some new applications we made since then with new technologies, with DevOps in mind, with good CICD in place, even with TDD, we started to utilize it now. This something, or we think we created a foundation now where we can basically work on in the future as well. We are future proof of that.
The thing is, or what we want to talk about today is we have a lot of legacy stuff. This legacy, or those legacy deployments are a problem for a small company to get away with, or to try to get them to the next level or substitute them by a new system is always a matter of costs and effort. You really need to find a way as a small company to get to this point.
Yes we have a foundation now, we have the mindset, we have the culture to do this, but we're still standing in front of a wall of work, wall of effort. I consulted a client some weeks beforehand, and the topic was to get this mindset to his team as well. To show them what's on the market, what can you do with modern technologies and modern ways to work like DevOps or agile, or CICD on all those buzzwords. What are the meaning of those?
He told me to please think in baby steps because baby steps are something which a small company can work with. My problem in the past was I was thinking about too large steps. We are small company and try to get a new system to find a substitute for a old system. This client basically gave me the idea how we can work on our problem.
This was actually the start of our endeavor to get from our monolithic system to a more service orientated system, and add some additional services like microservices, micro-front ends to the old system to get away from this sluggish state of stagnation, up to something where we can deliver again. All the new little services we create now are already on the new foundation, they're completely orchestrated.
They are well tested, everything is in continuous deployment, and it's all in a foundation. What we try to accomplish with this approach is to get rid of the old system step by step. For example, we kept the old front end and used micro-front end techniques to actually put in new front ends made with react for example, with Next.js and just displayed it into the old version just to have new capabilities in place, just to can basically accomplish what the product team is requiring from us. The goal with this, for example, with the front end part, is to actually build as many micro front ends as possible up to today when we only have one front end left. Those are the baby steps there. We try to get one little part of the front end updated in the newer version while still keeping the old one. On some point, we actually have enough parts. We can just assemble it to a new front end, and we can just shut down the old one, and use the new one.
The newer parts are all connected by a general-purpose API, with new services we made. We actually translate the old monolithic API into a newer API where those new front ends can communicate with the old parts, and the new parts at the same time. On the back end part, we do the same thing with baby steps. We erase-- Not erasing, but substituting a service by service. We try to keep in mind that we don't want to make--
This maybe a misunderstanding because lately, we have a lot of conversations about what microservices are. Microservices, we're going [unintelligible 00:11:17] this monolithic. I don't want to get too much into detail with that, but we try to stay with three domain boundaries. We have the inspiration part which are product details. This is a shop system, by the way. We have basically a part where the product details are where-- You get some advertisement, you just get appetizer to buy the current product, then we have the shop cart itself, like the shopping cart and the payment stuff, and we have a fulfillment domain where--
Actually this is not really a part of the shop itself, it's what's happened after the shop. We have a web to print system. There needs to be some there-- Those products need to be created as, for example, PDF files, and send to a print house, for example. Those are the three domains we think in. We have actually services for all those three domains, but we don't want to overextend it to have, for example, hundreds of microservices in place. This is not our goal.
Actually, sometimes we think about if what we do it's really a microservice, or what we create is really microservices, because our microservice are quite huge. Maybe they are more services. The idea is the same. They are isolated. We are a small team, we cannot afford to have too many of them at the same time. The idea is the same. Separation of concerns. You try to decouple everything and be able--
Actually, we never want to get back into this stagnation state of having a application where we cannot plan and do anything anymore or have to fear that something break if you deploy it. This is what our goal is. We do this or this pattern with every application we have currently. It works out quite well for a small team. Many want us just to not do this with a small team. Just go with another solution, just build it somewhere else--
Jonathan Hall: Specifically to not do microservices, or to not do the piece by piece replacement?
Adrian: Not to go to microservices, for example. This is a thing where many-- We often heard about the warnings not to use microservices in small teams. Just you need 50 developers for at least one service and stuff. I think it's just not really right at this point. You can use microservices, but you need to be very specific with your domains, with your boundaries, with your context.
You need to plan before you start to develop those. Once they're in place, for example, we use Docker Swarm as an orchestrator. We are not in the cloud with it at the moment. We plan to do this. This is one of our next steps. We still use it on our local service-- Not local service, but it's a data center. We tried to accomplish that-- Operations is not overwhelming us. This was one of our goals. We said, operations is something we need to do within our team, but it should not be a complete position.
Let's say, we don't need a specific dedicated person who's doing operations all day long. We are just a too small company for that. With that in mind, we decided to go with Docker Swarm. Actually, we composed an application, which is with together with continuous deployment, it was possible to just have no big interference between those services.
You just made an update, and basically, everything works out. I never understood where this big problem with microservice really were. When you think about or plan beforehand, you will not have too many problems with microservices. I just want to point out that this at this time.
Jonathan Hall: Nice. I'm curious to hear a little bit more about how you came to the idea-- You described the way you have a view into the old application, and you're piece by piece replacing that with a new one. I don't know if you're familiar with the term, but it reminds me of the strangler fig pattern. I think it was Martin Fowler who first used the term, but it's caught on since then. I don't know if you've heard of the strangler fig tree?
Of course, I didn't know about it, until I read his description of it. It's this tree that starts to encompass another tree and over time, it grows around it and eventually kills the other tree around it. Completely kills it. I don't know if it's actually a parasite, but it certainly envelops and kills this other tree. He likes to use this as a metaphor for application replacement, rather than rebuild a whole new application, and then do this big bang switch where you throw the old one away and start the new one.
You'd just do a little bit at a time, replace the old application with a new one in place, and then eventually, the old application is gone. It sounds like that's what you're describing. Would you agree?
Adrian: I definitely agree. I have to say, I heard of this term, but I never got deeper into this. Yes, it is actually what we try to accomplish. Going in baby steps, this is what our term is. Going in baby steps to migrate into some new architecture until the point where everything is migrated, and we can shut down everything else. On the way, it's not like a big switch on a single day. It just means that if you are done with substituting one part, the old part is gone and the new part is online.
This is the reason why we use those micro architectures where you have many small parts, and you just need to orchestrate those small parts, develop on those small parts, and on some point, you get your new solution. This is what our goal is in the end.
Jonathan Hall: Let's talk a little bit more in detail about the technology of your old solution that you're replacing. I know, you mentioned PHP, maybe you want to go into a little detail, what does that old system look like that you're trying to replace?
Adrian: It's a bad one.
[laughter]
Adrian: It's a real bad one. We use Pageflex. Pageflex is not the bad part of it. It's a rendering engine. We used to use for many years, and it brings a storefront with it. It's ASP.NET application. You need to install it on Windows service and stuff like that. We use this solution for many customers and for ourselves in the past. On some point, we just figured out that it's not possible to fulfill any requirements with this software we had to this time from our clients.
We needed to invent something on top of the system to fulfill the demands. We actually created something with PHP, put it on top of this application into the IIS server as well. We run actually, C Sharp and PHP at the same time on a web server. I think this is one of the web servers IIS who can handle this, but it was never a great solution. It was maybe a good idea to that time, but with the view of today, it was an awful decision of myself maybe.
This is actually what we do. We work in PHP to avoid changes in the underlying system which is made in C Sharp. We have basically a core which we can just update when there's a new update is out. We just build our framework on top of that, but this framework is discontinued. We do not develop on this framework for some years now. We maintain it as a legacy framework. Everything we do now is made in next year's React, in front end, and Next.js in the backend terms. We are basically a type script company if you like.
Jonathan Hall: I'm interested to understand the timeline. When did you decide that it was time to replace the old application? How long ago did that happen?
Adrian: Actually, we thought about three or four years now that we should do something, because we had several issues with security. We had problems with our front end, we still use prototype JS. Maybe someone is aware of that very old framework. It's actually the framework before [unintelligible 00:21:01]. This is a real legacy framework. We need to get rid of those frameworks, because we were a little afraid of those browser changes, what actually Chromium browsers did, they restricted some parts of that.
We needed to figure out ways to keep those old frameworks compatible with modern browsers and stuff like that. This was the point where we said, "Okay, we need to do something." On the back end side, there were similar problems. We weren't able to do updates anymore on the core system with Pageflex, as we said before. There came new windows server versions out, new PHP versions, and PHP 8, for example, wasn't available for windows at that time. I don't know if it's today. All those led to the decision, we should make something.
In 2020 we had actually a security incident where we got hacked. We rolled back everything and everything was fine afterwards, again, after some weeks we were back on track, but this was the point where we said, "No, we need to go away from this." Then we thought about maybe six months, how to get to the point where we have a new application, and the old stuff is gone. This was basically the big problem I talked in the very beginning of the show.
It's the effort. It's small team of between four to five developers. How do you migrate something which you worked for years on it to create it? It's not just, get some funding and do it next to another applications. It's not possible. The clients expect at this point that they pay for services, and they expect those services run, and they don't want to pay the second time to get those services running securely and well, and performing.
Performance was another reason. We did everything we can to get some performance out of our old system. It was very, very slow. The Web Vitals were in a deep red area. We used systems like Engine X with caching, like Engine X plus system to get some caching onto our system. It works out, but it wasn't great. It was okay then, but it wasn't great. Everything we try to do was actually not satisfying for the clients, not satisfying for the developers, we had some developer fatigue.
It was like a developer always want to have some perspective in his life. If he starts to work for too long on a legacy system, which is a unique system, no one else on the world wants to have anymore. It's nothing worth to stay for developing into the company. It doesn't matter in which direction you took a look. We needed to get away from that state we were in. This was maybe the answer for your question, I think.
Jonathan Hall: You started doing the new version of application, it sounds like in 2020, a year and a half, maybe two years ago, something like that. What percentage have you completed or what percentages now the reimplementation versus the old?
Adrian: Okay. I would say in two or three months, we should be done with a complete front end part. Then we will decide if we go straight to the back end side and say, "Okay, now we focus on the backend side to get it up and running into a new architecture as well." We are still not sure if we should implement more SAS applications into our system, or build everything on our own. While we developed the back end side, we thought about implementing stuff like Odoo or other services who are actually just ready to go, instead of creating everything for our own.
The make or buy decisions were made, or actually we are considering what we do there. We want to finalize the decision when we are done with the front end part. This is the thing. The idea of our API is that, our API is translating definitely what our legacy system is doing. Basically, no matter what comes in the future, this API will translate other services like SAS services as well. We are good to go and future proof with that pattern for a small company.
Jonathan Hall: That's really good. That's an encouraging story. It sounds like you were in a, I don't want to say disaster, because you were serving clients, and you were meeting business needs, but it was difficult two years ago, and maybe the security incident counts as a disaster. Now it sounds like you're three months away from being in a much better place.
I'm curious if you can put some numbers on that, like before the security incident, you mentioned the time to market was slow. How long would it take you to get a feature change, or even a bug fix from conception into production? How long did that take before? What does it look like now?
Adrian: My partner always complained that the IT is not delivering fast enough. For example, we had a feature where we shall connect to a service of the real estate service supplier. We supposed that this would be an overall effort for about three weeks, and it took 18 months to accomplish. The problem was-- The thing is, it's not a default of a single application. The problem is, we are a small team, and we need to work on many applications with many problems, and you jump from one problem to another and everything, it's just not working out everywhere.
When you are in such, it's a downward spiral, and you will never get to the point when you've just finished one single feature. It's just not possible. This feature I mentioned, isn't really ready today. It still have issues and it's at bucks and it's not working a 100%. We are on the way to finish that one, but soon we need to replace it by the new version anyway, so we can throw it away.
It took us a long time to do this. Same happened to other features as well. Many features we just never put it out of the backlog. We haven't thought in springs anyway. We tried often to implement the thinking of springs, say, "We do this this week and next week we will be doing this," but it wasn't working. We had so many problems built into our system, into our culture, into our workflows that actually nothing was possible anymore.
Our performance was near to zero. We tried to some client projects where we knew, "Okay, we can finish them." We focused on those things, but the really important stuff, which would bring us to some point where we were be able to grow. We were never able to get to this point or fulfill or actually accomplish those tasks. It just wasn't possible.
Jonathan Hall: Before you started the new service rewrite. How long did it take you to deploy a change? Suppose you just wanted to fix a typo somewhere, something really simple, so it didn't take a lot of development effort, but you got it done. How long would it take to deploy?
Adrian: Several days I would say, because the problem was that, we used some sub modules, SVN sub modules between those systems, and since we had no test driven development in place, we had no tests overall in place. We had basically none, and we had staging, but we had staging system. Basically, every developer tested by himself, if we were lucky on the staging system, and maybe they by checking the application the whole, maybe they found an error or not.
From this point the problem was that no one was sure about what they deploy there, so the reason for those delays were not the technical part. It was just, we were not sure if we were able to deploy those changes. We waited for somebody else to take a look and test the upcoming features, but it took time.
If you do this many times in parallel, the problem is that you create a pile of unfinished stuff, and when you have this pile, for example, you have five changes, and no one is really sure about what happens when you deploy those five changes, then you tend to not do this.
Jonathan Hall: How long does it take today to do a deployment if you have a small type of fix, how long does it take?
Adrian: Actually we push it and it's some minutes later on the system.
Jonathan Hall: That's a huge improvement that isn't from--
Adrian: I have to admit, it's really only the very new services we created. Very new front ends we created. It is just a very small part of our main system. Most of the stuff is still in a problematic state. We have not implemented TDD in any way for our old system. We had to admit that this is still a problem.
Jonathan Hall: Yes. That's, that's understandable and expected. It's incredibly difficult. It's not impossible, but it's a big effort to start doing TDD on a project that doesn't already have nearly complete test coverage, because your code is generally not testable, right?
Adrian: Yes.
Jonathan Hall: You have code, and the way I learned TDD was by writing, I learned it for bug fixing before I learned it for writing new features. I would discover a bug, and I would try to write a test to prove that the bug existed, and then I would try to fix the bug. That's really hard on a system that doesn't have tests, because you end up writing to end tests to prove that your bug exists, because you don't have the granularity, your code isn't modular enough to write those tests.
You're forgiven in my opinion for not retrofitting your old code with tests like that, because it's a huge effort and it's also dangerous because you don't have tests yet on that code, modifying it to be testable is likely, and almost certain to add bugs that you don't detect with your tests, so I don't blame you for not doing that.
Adrian: Actually I forgot we have some end-to-end tests in place, but this is more like a log into that system and check if some on the main homepage or the initial pages is where can make some a cert for a ID for a HTML element, and that's all, this is all we test, but those tests basically never fail, so we could shut them down, but we have no effect on the deployment at all.
Jonathan Hall: Well, I'm encouraged to hear that the progress you've made. I hope it's a good story. I think you come from a situation that's so typical. Everything you were describing about the chaos of the old system. I have lived through that before on old systems, so I completely identify with what you're saying. I imagine many, many listeners are in the same situation or at least have been in the past.
It's really encouraging for me to hear that over the course of roughly two years, you've been able to make significant progress in improving your system with baby steps, and that's really the only way you can do it because if you try to do it all at one once-- I don't care if you're talking about doing a full rewrite all at once, or adopting all agile practices whatever that would even mean all at once, you can't do it, it's impossible.
It's overwhelming, so it's emotionally and mentally impossible and it's just probably physically impossible. I really appreciate your story and I sympathize with the pain you've been going through.
Adrian: Pain is good. No pain is not good, but pain is a good word for it. Actually we had a lot of pain points, and there were months which were just horrible, horrible times and I only can recommend to not fall into trap, and often not think about the fundamentals like DevOps, like TDD, like CICD, you need to have those, especially corporate, sorry, continuous deployment.
You really need to have that in place before anything else. Don't be too cautious with your deployment, because what we found out is the slower we go, the more cautious we go, the more problems we have in the end. This is just a thing of maturity. How mature are you working on your systems?
This is what we found out, what we took over way from our learning, and when we met you, or when I met you, this is, you just gave us the last kick to really go into the direction, so I have to thank you for that.
Jonathan Hall: I'm glad I could be of help.
Adrian: Yes, it was a good meeting we had some weeks, or maybe a month ago. I don't know. It was a time ago now, but it really helped us to make those last important steps to really round up everything.
Jonathan Hall: That's good. Do you have the ability still to do your own manual testing? Do you have staging environment for the new system as well, or are you relying only on automated testing?
Adrian: We don't have a staging system anymore for the newer systems.
Jonathan Hall: Okay.
Adrian: We have some development version of it, but it's not meant to be shown to the customer or client or someone else anymore. It's just for development purposes. For example, to have some extended testing with several other services together, and for this it's okay, but it's not meant to be the traditional staging system anymore where everything is parked until someone is testing it, so it doesn't do this anymore.
Jonathan Hall: It sounds like your developers do have the ability to test their code in a live scenario before they've deployed if they want to.
Adrian: Yes, with real data.
Jonathan Hall: Yes. That's great. That's really good. That's one of the things that I always encourage, especially small teams to do, who aren't doing continuous deployment yet, is to set up an environment exactly as you've described so that they can do this testing before they hit that merge button in GitHub or whichever tool they're using, and that allows you to then automate from the time you hit merge, you can automate the deployment from there, which it sounds like you're already doing, which is just amazing.
You can still do and the pushback I usually get is teams that are accustomed to pushing to staging and then a QA team, or a QA person, or maybe it's a developer, but there's a manual QA process, and then they remerge into production or something like that. These teams are usually using Gitflow or something like that. We haven't talked about your branching strategy. I don't know if you're using Gitflow or not.
What I usually encourage these teams to do, is just push that manual testing stage before they hit the merge button, and then everything from merge forward is automated. I call it lean CD. That's not really a good term, because it's not from the lean manufacturing. It's more the lean startup idea of a minimum viable CD thing, but this is the approach I like to do. I've done it as several companies, and it I don't know if you think you're doing the same thing it doesn't really matter.
The point is, I agree with you with what you're saying that continuous delivering deployment is so important, and you can't allow yourself to be driven by fear. What you're describing to me sounds like the old advice to optimize for your mean time to recovery, MTTR, rather than your mean time between failure or MTBF. Fear causes us to optimize for the time between failure. Basically we do everything we can to make sure nothing ever fails, but we can't do it. Humans always fail and nothing and even when humans don't fail, the technology fails, a hard drive crashes or something else goes wrong.
Amazon goes down for a day, whatever. Things will fail. If we try to optimize for mean time between failure, in other words, we try to prevent failures from occurring. We will never succeed, but if we optimize instead fast recovery, then we're prepared when these inevitable failures do occur. You understand this difference in mindset, which is so important that being afraid to deploy something is the enemy of responding quickly when something fails.
I'm really encouraged to hear you say this. I hope that every listener listening today, if you're afraid of deploying, because you think things will break, I understand it's natural, but we need to find a way for you to not be afraid to deploy. Instead rely on the fact that you can fix a failure quickly when it happens.
Adrian: This is a good point. I think before when you haven't or have never done it before, you will never realize it. It's some something you cannot do a theory about this, or and say, "Okay, I have understand this and everything is good now." You just need to have confidence after you integrated that, and you will have it actually, in my opinion, you will have. For example, we use Docker swarm.
No [unintelligible 00:41:52] for a small team like us, but we can just switch between the image versions by a click. If something happens after an automatic continuous deployment process we just roll back, and all is fine. We don't even need to push it. We just can go into the orchestrate and say, "Just roll it back," and all this good again. Hopefully sometimes it's not, but if you have all this in mind, while you developing your stuff, then you will not develop software which is likely to fail that easy.
You will think different if you stop thinking in month of development for a single update, then you will have different mindset while developing features. Features become pretty small then. A single feature can be just another color of a button. It is not like a complete system update where everything changes. No one knows what happens. It's just the smallest, tiny bit you can define is what you actually should try to get to this point.
This is the point where, and developers able to determine if his code or actually his feature is tested or not, it's actually fit the requirement or not. The briefing for a single piece is small. You just have maybe one or two sentences. It shouldn't be more, so everyone can say, "Okay this is now fitting the requirement." If you need a small book before you make a feature, then you can't test it.
You need a QA person for this, but as a small company we don't want to afford a dedicated QA person. This is the best way we could have done to get to this point.
Jonathan Hall: Great. I've enjoyed this conversation a lot. Adrian, do you have any recommendations if anybody's going through the same struggle that you were in the past? Do you have recommended reading or a favorite conference talk, or anything that you could recommend for people who want to learn more about how to get into this mindset that you went through?
Adrian: There are books. Maybe you can link those in the show notes about micro front ends. I think micro front ends will open your eyes. Microservices are good as well, but micro front ends are more like a visual thing you can understand to know what happens then. This is about the architecture. To be honest I just read a lot of blogs. I just listen to many podcasts. This is what I do to get to the point.
Your podcast, for example, is a good thing for getting into development operations, and agile thinking and stuff like that. This is very important, but I think it's not, or at least in my opinion, it's not about one book or one thing, and suddenly you understand everything, you need to believe that you can do it first, and then try to get better every day.
You always should think, "What can you do today? What makes it better than you was tomorrow?" When you have this mindset, everything else comes by itself. This is my opinion, have a goal and then work towards it.
Jonathan Hall: Adrian, if people are interested in reaching out to you. Are you available for contact on social media or any where else?
Adrian: Yes, you can find me on LinkedIn or just go to my name, Adrian [unintelligible 00:45:48] .dotdev. You will find my book there so you can contact me there if you like.
Jonathan Hall: Wonderful. Tell us the name of your your business. Also, we talked all about it. I don't know if you told us the name of the beginning. If, anybody's interested in web to print, if they would like your services, how can they find your business?
Adrian: It's bitsinmotion.de. The bits in motion. Just one word .de. We haven't the very big web presence I have to admit. Don't wonder, it's completely okay. We are there, we are still existing, and we are alive and kicking. Just feel free to contact us, just contact me on LinkedIn, this is the easiest way to do it.
Jonathan Hall: We'll have links to all of that in the show notes, everybody. Adrian, before we sign off, is there anything else you'd like to add?
Adrian: No, actually I think we covered it. Just get to the point to be able to move. This is I think the best message I can give and DevOps, CICD, agile thinking, those things should be implemented into your mindset, into your culture before you start to go any endeavor in the software development today.
Jonathan Hall: I agree. You heard it from the man. Thanks for attending. Thanks for joining me today, Adrian. I hope to see you all next time on tiny DevOps.
Adrian: Thank you very much.
[music]