#260 A New Era in Software Development: The Impact of Environment-as-a-Service With Sorin Dumitrescu

Transcript generated by Podium.page
Help us spread the word by tweeting about us at @podiumdotpage and including us in your shownotes! https://podium.page

NOTE: There were 2 speakers identified in this transcript. Podium recommends using "Find and Replace" to change the speaker label to the appropriate name. Speaker separation errors can arise when multiple speakers speak simultaneously.

0:00:02 - Mehmet
Hello and welcome back to a new episode of the CTO show with Mehmet. Today, I'm very pleased to have with me Sorin. He's the CTO and VP of Engineering for Bunnyshell. Sorin, the way I love to do it, I keep it to my guests to introduce themselves more so the floor is yours. 

0:00:19 - Sorin
Hello, mehmet, thank you for having me. So I'm a developer, a software developer, at Hearth. I have roughly 15 years of experience in the field. I started as a solo developer, then did some outsourcing, went into a team, then a larger team, and so on, and roughly about 10 years ago, I found a passion for managing teams and leading teams. Since then, I've been in various roles like technical lead, cto and VP of Engineering, and I really enjoy both organizing teams, making them more efficient, as well as solving any technology related issues, from architecture down to implementation details. Most of my time these days is spent between leading the engineering team and discussing with customers or potential customers to try and find out how we can help them better with our platform. 

0:01:33 - Mehmet
That's great to hear, sorin, and you know this will lead me to maybe the next question. Now, of course, we're going to go in details later on, but on a very high level if you can tell me what you do at Bunishel. So what is Bunishel all about? 

0:01:54 - Sorin
So Bunishel is about empowering development teams. We build tools for helping development teams in all roles, from software developers, key engineers up until to I don't know product owners and various business stakeholders. We help them to eliminate bottlenecks when it comes to environment and basically have autonomy and streamline the way they work with this regard. So basically, eliminate queues, eliminate standing in line to test a feature or to get feedback from a feature, have all the development flowing as it should. 

0:02:48 - Mehmet
That's great. So let me take one step back, sorin, and let's go check, because for the people who might or might not be developers themselves, so let's take this one step back Now. I will make it easy for the audience and, again, easy for our conversation. So you know when, usually when you are developing, of course, and maybe even non-technical people, they know this, so you don't develop on live environment, like there should be half kind of testing environment. So now, how is the live you know look like, without having something similar to your solution. So walk me through. If I am today maybe a VP of engineering in a company, or maybe I'm head of application at a company, and of course, we need to develop a lot of things. So how life looks like for us today. 

0:03:48 - Sorin
Sure. So obviously it varies depending on the company size and on how much they invest in their own internal tooling, but I would say that an average company with maybe 50 plus developers has, as you said, the production environment. Of course that's the environment from which actual customers are served from, but they also have a development environment, which usually reside on laptops. On each laptop for each developer, they have a stack in which they're able to write and test the code. And then they usually have a number of environments, like one or two or three, which mimic the production environment but are not connected to real systems and are not serving real users, but are used by the development team to test, or stage, as they say, the new features before releasing them into production for real users. 

And this is an issue because you asked how life is. This is an issue because having these one or two or three static fixed environments served us well until some time ago, like a few years back. But if you have like a 50 developer team and they're all working on different things maybe I don't know 10 to 15 different things it's obvious that you cannot test them all in parallel and this usually creates Queue that needs to be prioritized by a project manager usually. So basically what happens is some features will get delayed. Some of them will get delayed for a very long period of time because other, more important features will will get ahead, and this leads to teams not being able to release their work fast enough and it also generates costs for them, because once you've developed something, you also need to keep it up to date regularly with how your production is evolving. 

0:06:27 - Mehmet
That's basically it, yeah, please. 

0:06:30 - Sorin
Sorry. So basically it's not an ideal scenario and the complexity isn't helping as well. There's a complexity gap at the moment between how production looks like and how development looks like. Usually, developers are simulating the resources they have available in production because production systems have evolved a lot in the past 10, 15 years, like a lot. We use now cloud-dative services. We use very scalable infrastructures, but obviously you cannot replicate this on a laptop, and this leads developers to the need of simulating various services or using shared resources for multiple developers directly in the cloud, and the configuration drifts that arise from this are also costing the teams time for troubleshoot and debug issues. 

0:07:35 - Mehmet
Yeah, so, sudeen, I got it now, and this is I'm trying to relate in my mind, because when I used to work with vendors and I used to interact with the engineering team, which are basically the guys who are developing the software, so I can relate about. 

You know, okay, if I don't have enough resources, my biggest issue would be how I would make sure that this gets priority number one in the queue so I can test it, because maybe I have limited resources and this is where I can see. You know, like you, at Panishal, you came up with this whole idea, which you called it environment as a service. So correct me if I'm wrong, and I want you to explain as much as you want. So, basically, what you're doing is that you're telling your customers, instead of you having your own, you know, testing, staging, or sometimes they call it UAT as well environment, so you provide them with this to replicate or to clone the production, and then they start to do the testing they want and then they can have as much as they want. Am I correct in this understanding? 

and feel free, please to explain it in details. To me, like with the workflow, Perfect. 

0:09:00 - Sorin
So yes, yes, you are correct. This is the essence of what we do. We enable our customers to create as many environments as they need, but in an efficient manner. So environments can also be stopped in order to keep costs under control and to be efficient. And the very important aspect is that customers are always in control of their environments and in control of their infrastructure. 

What Banishal provides is an orchestration tool or an automation tool if you want for these environments to be created and to be managed afterwards, because creating them is just the first part, so we need to keep them up to date. You also need to be able to see differences between various versions of the environment, including production, because the infrastructure and the environments are constantly evolving in nowadays. So, to sum it up, we provide a tool, a platform in which you can define a template or a blueprint for how your environment look like. Think of it as a definition. It's a definition written in code, and once you have this template, you are able to create as many replicas as needed. These replicas can be fully isolated from one another or they can share components. 

It really depends on the setup of the company, because sometimes you have, like an ERP, for example, which is licensed and it's only one and this really needs to be shared across environments. But you are also free if you have multiple licenses, for example for the ERP, or also create additional replicas of the ERP as well, so we can adapt. Basically, our platform can adapt to any scenario and provide customers with the flexibility that they need in creating environments for their development, for their testing, for their automated security testing, automated end-to-end tests, environments for code reviews, basically for the entire software development lifecycle of a product after the specification phase. 

0:11:54 - Mehmet
Great. Now quick question. So when you say you provide the environment, so are you providing this into a Cloud environment? Are you providing this within, if they are still, because, especially here in some areas in the Middle East and some areas because some customers, even in some markets where they adopted the Cloud, but for security reasons and some policies, they need to keep the data within their premises. So are you providing this as what? If you can explain to me more, what do you mean by this environment Like? Is it an infrastructure as a service? Is it a platform as a service? And if I am an on-prem customer, can I still benefit from that? 

0:12:43 - Sorin
Yes, of course, so I'm going to answer the few points you raised. It was a great question. You mentioned infrastructure as a service and platform as a service. What we do is essentially the next step in evolution. It's environment as a service, which is on top of that. Basically, an environment is all that's needed for a platform to run. It contains the applications, the services, the databases, the configurations and every cloud resources that you might need. Of course, if you leverage cloud resources, it can run in the public cloud, it can run in the private cloud or it can run even on-prem. 

We have customers from all three categories. Basically, how it works is that you connect your existing infrastructure, be it a cloud provider we support the major cloud providers and some smaller cloud providers as well or you can have your self-hosted infrastructure and connect that to Bunnyshell. The way it works usually is you connect to Kubernetes or more Kubernetes, clusters, to Bunnyshell. Basically, even if you have an old-school infrastructure and you are able to create virtual machines and even if you have physical servers, you just need to install Kubernetes on them and then you are able to connect these to Bunnyshell. Another concern you raised regarding the privacy and security is that it might need to run on their infrastructure and for sure, Bunnyshell does this. You can choose to use our SaaS, which is a platform we maintain, but you can also install Bunnyshell in your own infrastructure and have complete control over how you secure it, and even have it completely isolated from the external internet. 

0:15:11 - Mehmet
Wow, that's really cool. Now, just also out of curiosity, sorry, because I think I never touched on this topic before how this, what you do, has to relate to the concept of what we used to call it CICD, which is continuous integration, continuous delivery or deployment. So does it have to do anything with that part, or is it something completely different? 

0:15:40 - Sorin
It can be both. As I said, we're very flexible, so we built a platform from our past experience and having a lot of context in mind when we built it. That's why it's so adaptable. So, coming back to your question regarding the continuous integration and continuous delivery concepts, these are usually implemented through some sort of pipelines or workflows. It depends on what tool you use to automate this. Bunnyshell can integrate with these pipelines that you already have. For example, we have customers who are creating preview environments. These are environments that are created. 

Whenever a pull request is open, a new environment is created for that particular pull request. So the developers doing the code reviews can assess the code with a running application, and this is a huge difference, because it's one to look at a thousand lines of code and evaluating them in your head, but it's a completely different experience interacting with the application and being able to see what the outcome really is. Think of regular expressions for validations, for example. You can test it right there. Or think of error handling for a new payment method. You can test with the test cards there and see how the application really behaves in handling errors, for example. So this is the preview environment concept and it's usually tied with opening a pull request. So basically, you open a pull request, you have an environment, you can do the code, review the testing afterwards and whenever the pull request is merged or closed, the environment gets discarded. So the environment is short lived and disposable. It only lives for the amount of time needed for that pull request, so it supports that pull request. 

Other forms of integration with pipelines for CI CD are running automated end-to-end tests and this can be done on a number of jobs based on labels or on naming conventions or whatever you'd like it to run on. It can create environments also for security testing, for load testing and for any other kind of compliance testing that you might need. So basically, this allows a new way to work for software development teams and for delivery teams as well, because, to be honest, teams that deliver software have restrained themselves a lot in the past because they had no alternative in easily creating an environment. But now this is possible and you can have an environment living and consuming resources for I don't know 15 minutes, 20 minutes, how long it takes for your automated test suite to run, and this is a really important factor and a game changer in the industry. So to sum up the question. 

I think I've answered the CI CD part. It can definitely integrate in any step of the current CI CD setup and basically extend it. Or you can have it totally separate than your CI CD and here you can either do things manually or you can leverage some out of the box integrations provided by Bunnyshell to automatically create environments, like preview environments, for example, whenever a pull request is created. So you can have it either integrated and extending your CI CD or you can have it completely separate. It's up to you and from our experience no one starts in full integration mode. Let's say they usually start with one or two use cases, like we have, teams starting with environments for end to end automated testing and they then moved into preview environments and development environments. So it's a matter of where the highest benefit is for a team and we can definitely provide some advices here based on our experience. 

0:21:02 - Mehmet
That's great and I like how you went to the details over there and thank you because I never shared this topic before on the podcast. Honestly, now, sometimes and I'm not challenging here, sareen, but sometimes people they have some misconceptions. So one of the things, because when you were mentioning how you can help in spawning these test environments and UAT environments and so on, so one thing that might come to mind and excuse my ignorance, because, again, yeah, I'm a technical guy but I'm not a developer and I didn't do it. But someone might say, hey, but Kubernetes technologies, for example, they allows us to have this, let's call it agility. So here, why it's not the same thing? Why they should not mix the concept of I adopted Kubernetes, I'm fine, I'm good to go. Now I can do whatever I want more fast. Again, the thing that you keep and you aim to help your customers with. 

0:22:15 - Sorin
That's a really great question and it's very on the topic. So we also use Kubernetes behind the scenes to create these environments. I will just make a very, very short parenthesis and tell you how you can compose an environment in Bunnyshell, so it's easier to understand that it makes sense for the technical audience that you have. So an environment in Bunnyshell is made out of components and configurations. The components can be anything from Docker compose based components to ready built Docker images, or you can build Docker images yourself. They can be Helm charts, they can be Kubernetes manifests, they can be custom scripts or they can be Terraform modules which, again, you can write. The Terraform modules is obviously for the infrastructure as code part. So creating resources outside of applications, let's say usually, but most of the components which are deployed are deployed on Kubernetes for our environment. 

And Kubernetes is, in our opinion, definitely the way to go because it's a platform that allows to leverage a lot of things out of the box. You can leverage high availability and high scalability with virtually no effort, which previously was a daunting task to do, and it also provides a lot of extensibility options. But, as Google themselves mentioned, they see Kubernetes as a platform for building platforms because it's very extensible and very configurable. It unfortunately also has a very, very steep learning curve. So you can only find so many experts in Kubernetes and people who are really understanding what happens behind the scenes and how they can truly leverage Kubernetes in also a secure way. So Kubernetes is not really meant for software developers to use directly, because it's very complex and it's really not part of software developers' job to learn this. 

And I will argument this with an article which I recently read. It was also published by Google. It said something like shift down instead of shifting left. So this shifting left concept we've had it for a number of years. It basically encourages teams to do things as early as they can, so test integration as early as they can, do things like code reviews and peer reviews and security testing more often and more frequently. But what this concept of shifting left has brought us is a lot of complexity on the developer's shoulders. So if you also put Kubernetes in their hands and they also need to learn advanced concepts from Kubernetes they will have a very high cognitive load because they already need to keep up with very rapidly evolving technology landscape. And I mean this in frameworks that they use, libraries, best practices in terms of software launch, construct and so on, and these all are evolving very rapidly, and if you also put the burden of managing Kubernetes and designing for Kubernetes in their hands, it will be a very, very high bar set there and you will have difficulties in keeping all the people up to date and also engaged in their work. 

So a very good approach, as Google also suggested, is to abstract these concepts away from developers and provide them with a simple way to achieve their means Really to abstract the environment and the infrastructure part and allow software engineers to focus on what they love to do and what they do best, which is developing software right, Writing code, writing unit tests and focusing on the design aspects, the architecture aspects of the application. So this was all the context to answer the question you asked, because it was not an easy question to answer without prior context. You may have Kubernetes already in production and you probably are using it in other parts as well, such as staging, UAT and so on, and we've seen companies use it also for their development efforts. But there's a scale here that you need to consider. No-transcript On one hand, you would have a simple experience, but not a great experience in terms of developers in terms of their experience in troubleshooting, debugging, deploying and so on. It will be more of a raw experience, or you could offer a better experience, but then you would have to allocate considerable resources in doing so. And obviously there are companies who have done this very well, like the very large companies. I'm thinking of Netflix, uber, slack and so on but these are basically tech giants which have tens or even hundreds of people dedicated only to building internal platforms. This is a huge effort in terms of allocating resources for a team. 

So, basically what we see in terms of an average company, let's say they usually don't have anything in place for Kubernetes besides production and a couple of testing or staging environments, but when they do, they usually haven't got a great developer experience. And this comes from the focus of the company. Basically, when you are working on your core products, you put a lot of effort and energy there, but when it comes to internal tooling, most of the companies usually do only the minimum required, because it's obvious it's not their focus. So what this leaves them with is not so good developer experience and not a full autonomy for their experience. So they can do some things, but for other things they need to ask permission or they need to involve other people from DevOps or from infrastructure. They don't have access to all the tools that they need and so on, because building a great internal product is very hard. It's very hard to keep the commitment that you take. Although with excitement in the beginning, this usually fades away as time passes by and you have an internal tooling that requires some more investment, some more work, some more maintenance and so on, and you end up having less and less resources allocated to that and the developer experience is not great. 

So, as a conclusion to your question, what Bonnishel does really well is to offer this great developer experience and to offer a seamless integration with what teams already have. So, basically, you can leverage whatever automations you already have. You will use the same processes you are using today. Developers can do basically the same flows that they are used to today, but you can eliminate the frustration caused by waiting times for them waiting in queues, waiting for builds and so on and parallelize the threads on which they're working so they are able to truly focus on coding and to be able to be efficient, because engineers don't like spending time like idle time, to wait for builds, for deploys to happen and don't like to wait a few days until they can get a result from their automated tests to run. We've had situations like this in which, basically running an automated test suite took one to two days to complete, so it's not fast at all With having any kind of solution, not just Bonnishel, to unlock environments. Things are improving a lot and we typically see companies delivering three to seven times faster for most of the cases. Because what happens now? 

Coming back to your first question or second question about the life of developers in Teams, it's easy for them to build, but what's hard is for what they build. 

It's hard to reach production and this also in some way demotivates them, because anybody loves their work to be useful, to be appreciated and to be in production. When it comes to software developers, they don't like to drag on. This has also some harder to quantify benefits. If you're solving this issue because basically you're setting the pace to be for rapid iteration right, you are enabling people to move fast. Instead of two days, it's half an hour. Instead of one week, it's half a day, something like that and when you can get people to interact in such rapid pace, everything changes because they are more involved. They are more engaged in their work and they can contribute beyond what's actually required for them, so they become proactive. It's also a very good way to retain talent, to have happy developers and when I say developers, it's not software engineers, it's a generic term for Q engineers, project manager, everybody involved in the software development process. 

0:35:14 - Mehmet
You know, like Sareen. Thank you very much for this detailed answer. Actually, you answered two more questions that I already wanted to ask you, which are about collaboration, which is already mentioned, you know, and about you know. But what take away for me, honestly, is, first, I can see the benefit and I, like you know, usually when I I work as a consultant for years, right, and when you work as a consultant and now as an entrepreneur, so I need to relate a problem and I need to quantify this problem and then I come with the solution so I clearly can see what you are doing. So you're solving actually something that affects time, because you know, waiting is not good. People don't like to wait. 

Second, it's cost. Maybe it's not directly seen, but when I'm just throwing it, so if you, for example, a, let's say, fintech company, or maybe you are in any tech-related field as a startup or even a well-established company, so competition is always ahead of you and now, if you don't develop fast, you have a risk of being left behind and I think, with the AI and everything going around, so now you know, agility is everything. So I love this approach and, of course, you know, like again, and I thank you very much because I asked this question on purpose. You know Kubernetes, you know like as concept, it's more infrastructure, more than someone, that developers they use. So developers or software engineers, they leverage that technology to achieve what they do, but they don't care at the end of the day. So they just need they need access to their development platform. So, thank you very much, sorin, to mention this. So, as we are always, you know, coming to an end, what are the plans for Bunnyshell? Where do you want to go to take this? 

0:37:17 - Sorin
So we envisioned Bunnyshell as a one-stop shop for software development teams, covering all their environment-related needs. So, in terms of orchestration, just to be very clear, you would still use your Git, like you use it today, to version and store the code for applications. You would still use the infrastructure that you have, be it a public cloud, a private cloud or on-prem infrastructure. But connecting the dots is what Bunnyshell really strives for, and not just connecting the dots, but connecting the dots in a way that's a very good experience for developers, and connecting the dots in a very efficient way. So, basically, we seek to enable teams to move as fast as possible and with as little friction as possible, but it's up to them how they want to adopt, in which degree, in which way they dictate the steps in which they entry. 

So our focus is to continuously improve the developer experience, to improve the adaptability of the platform and the flexibility of the platform, to be able to accommodate more and more technologies so teams can leverage what they already have today, and to be able to integrate within their workflows with minimum to no effort at all. So we're going to keep on refining the product and to add integrations and to add new features to make it easy for developers to have everything that they need at their fingertips. This is the vision and also provide this is something that we also do today to provide a centralized view for environments, to be able to have order in these environments, because what we see for large companies is that the one thing they know for sure is how much their infrastructure costs as a whole, but they aren't usually able to break this down into not even products level, but very few of them are able to allocate costs and to have complete ownership at the feature level, and this is something that we can help with through our platform. 

0:40:22 - Mehmet
That's great, Soryin, and thank you for sharing this. We're almost coming to an end. Is there anything that I should have asked you, Soryin, to diamonds any point? 

0:40:34 - Sorin
I mean we could talk for a couple of days on the topic. Of course, it's very complex and it's a very new topic. Only recently, gartner has created a category for the development part. It's called Cloud Development Environments. I think it was in September, if I'm not mistaken, when it included the Cloud Development Environments in the hype cycle for emerging technologies. So basically what they said is that in five to ten years this will become the norm. So companies should act sooner rather than later, irrespective of what you said about being left behind, because this is coming and we're on a wave. 

Now we see more and more interest from teams of all sizes, from I don't know ten developers up to 600 developers gaining interest in setting up an internal development platform. And this internal part is not necessarily internal. This is what Bonichel does as well, but they try to leverage automations and to abstract away the complex things related to infrastructure from developers. Because it's not that software developers don't care or don't want to know the details about the infrastructure. It's about the complexity that it brings, and it just isn't feasible for a person to know it all anymore, to be expert in also their programming language, in their framework, in infrastructure, in Kubernetes as well. It's too much to handle for a person and only a handful of persons can do this really well. It's not scalable in the end. 

0:42:46 - Mehmet
Yeah, of course. Yeah, thank you for mentioning this about, because I love to see what the trends are and good to know that now you are pioneering outside this new hype of cloud development, which I think, yeah, we need to see, because companies, whatever their sizes to your point, sareen they are under pressure to deliver faster. I think this is now the norm and this is why, from development perspective, you need to be ready, you need to have this mentality. Not only the mentality, you need to have also the tools. And here, where I think Bunnyshell can add a lot of value. So, ridwale, we can find more about you and Bunnyshell. 

0:43:33 - Sorin
So it's very simple. Bunnyshellcom is our website, our main entry point. You can be directed from there to our documentation. If you're a technical person and want to find out how things are working or what should you do to have a quick start, it's something that you can browse in maybe 10 minutes and have a pretty good understanding on what we do. We have also linked in the documentation a video tutorials series if you prefer video content, so it's very easy to get started and we're always very eager to hear feedback, whatever it might be, from people, from engineers. This is how we developed our great user experience, the developer experience, and this is how we find unit constantly by talking to people. 

0:44:37 - Mehmet
Yeah, great, I love this approach, sureen, and thank you for mentioning this. Of course, the links will be. The link to the website will be in the show note. And, by the way, gentlemen, ladies and gentlemen, if you also need, I know the team also who works with Sureen. So, if you need any help on this, if this is something that you think it can attract you, I can direct you to talk to the proper team. They are doing a fantastic job I've seen doing recently, especially here in the Middle East and Africa region. They're doing a lot of activities. They are very active and, yeah, I can guide you on this one if you want. And again, sureen, thank you very much for the time today. 

I really enjoyed the discussion. Like it's been a while since we didn't touch on such a kind of deep tech topic, which it's very much needed. Very well, it will be very well received, I'm sure, and for the audience. Thank you very much for tuning in. If you are the first time here, thank you for passing by. I hope that you enjoyed and you will stay with us and, if you are a loyal audience, again, thank you for all your feedback and your comments. Keep them coming. I really appreciate that and, as usual, if you have something to share, a story you are a startup yourself, you are a product guy or you are like someone who have a passionate idea you want to share. Whatever you are doing today, feel free, we can arrange for something if you have something to tell the broader audience. So we talk about tech, we talk about startups, we talk about entrepreneurship on the show. So it's very open for everyone and thank you again for tuning in. We will see you very soon, thank you, thank you.