How we want to help to solve the four core IT problems by introducing the NoOps platform
Introduction
Today we are facing four core problems in software development.
- Architectures became more and more distributed, so now we don’t build one application, but we have to build a bunch of micro applications talking to each other. It complicates infrastructure a lot, especially if these microservices were badly designed, with several ideas for configurations, runtime approaches, logging, security, monitoring, and even health checks. What is even worse, CQRS and Event Sourcing are popular now, which I personally consider to be fantastic design patterns, but from an infrastructure perspective, they add new types of components, combined with DDD made microservices even finer-grained.
- Everything is moving into the cloud. Unfortunately, people don’t understand the DevOps culture and who the DevOps Engineer is. Good cloud configuration should be treated as a software project, not as a bunch of scripts and configurations made in graphical wizards. There are still many people who think that the cloud is a regular Data Center and they treat the cloud as a group of virtual machines.
- Software Engineers are more and more expensive. What is even worse, from year to year they are becoming more narrowly specialized. It’s reasonable because the requirements are going to be more and more complicated. A different perspective shows, we want to expect our team members to feel responsible for the project, and of course, share their knowledge to make all processes as optimal as possible. This situation isn’t clear, sometimes we find people that are open to everything and will be happy to live in a DevOps culture. Sometimes it is completely opposite, we don’t have any real DevOps Engineer in our team. I wrote about it in a separate article https://cezaryolborski.medium.com/devops-engineer-do-you-know-who-you-want-to-hire-5e14b8707a57.
- We have Agile everywhere, which is a great direction itself, but there are many cases when it’s terribly implemented, especially in organizations where we have to face the collaboration between teams. The microservice architecture is very helpful but as I mentioned before, it complicates infrastructure.
These problems concern everyone, not only companies using clouds already. If your organization doesn’t know what the good IaC (Infrastructure as a Code) is, just open your CI/CD and see how your configurations look. Even in a medium-sized company, where you have 10–20 projects, it is often hard to find what is going on there. Usually, new plans are cloned from the older ones, with “small” changes, but nobody can remember the difference.
Now imagine that you want to run a completely new company. If you are aware of these problems, good for you, but it’s still very difficult to prepare your new organization for this.
The question is: is it possible to build or buy a solution that will be future-proof and will solve, or at least minimize, the problems that have been mentioned before?
Two years ago, I would have said it was rather not possible, but fortunately, I’m a diver. A few times, that year, I was driving with my dive buddy to our diving spots. Usually, we spent more time in a car than in the water. My friend (Maciek) is a software architect and these days he was Tech Lead in DevOps Team. I was CTO in a Software Agency and I was aware of how the market was changing. After many talks, we decided that together we should try to solve these problems, and the only possible direction was the NoOps platform. Someone can say that we were crazy and probably four years ago it would be true, but not when Kubernetes started to become the standard and other DevOps tools were starting to look quite mature.
In short, we decided to build a platform able to create cloud configuration from scratch and deliver a full set of tools required by a business company or a software agency to develop, run and maintain any software solution. Sounds big, but for us it was still not enough. We wanted to build it not for one customer only, but as a product that we could use later in the SaaS model.
Technical description
Maciek was aware that the right abstraction level was crucial and each serious company should have a cloud exit plan. From my perspective, it was important to be sure that we had dynamic environment creation, scalability, security, SSO, service discovery, cloud-native services, and everything that was important from a development team perspective. A great tool that can help solve these problems is Kubernetes and the whole containerization idea.
Of course, we are both Software Engineers, and it was completely clear it had to be a software project, so Maciek built a complete toolset using real programming languages so the development process is similar to the one used in a regular business project. Here, we have the next advantage of Kubernetes, we can use Minikube to run everything locally and test faster without expensive deployments.
The abstraction level is the key element of our idea. There are two separate aspects connected with this. First of all, we want to tell our customers that moving from one cloud provider to another will be possible. Secondly, thanks to containerization, it’s not important which technology you use to write your application as long as you are ready to pack it as a Docker image.
It was very important for us to help our customers to fulfill 12 factors requirements (https://12factor.net) as much as possible and keep the flexibility at the highest level.
How does it finally look? To run an application using DevOpsBox, the developer needs to meet a very short list of requirements:
- The application should be built and run as a Docker image.
- It should send logs to the standard output.
- It should be fully configurable using environment variables.
- It should have a health check endpoint.
- It should implement one simple descriptor (box.yaml) defining what, where we want to run and what the dependencies are.
Of course, even one descriptor can be very complicated. To avoid it, we implemented convention over configuration and the syntax similar to docker-compose.yaml. Therefore, in many cases, our users need to write not more than 4 simple lines descriptor in order to deploy a new application into the cloud. When they commit their code for the first time, our platform recognizes the new project. Next, it prepares all build and deployment plans. The build plans are triggered by multiple branches and their results can be used during the code review process. Deployment plans are generated for all the specified environments and they can create a new one and all requested native cloud resources, if they do not exist. It sounds simple but without our tools, our user would have to write hundreds of lines of Kubernetes and cloudformation yamls for the same configuration.
When the developer deploys his/her application, its metrics will be automatically visible in Grafana, logs will be aggregated, it will have default rules for scalability, and it will be accessible by other applications. Of course, everything managed with the right security level.
Ok, but we would be insane thinking that we can create a solution that will solve all the problems and can be accepted without customizations by different teams all over the world. There is Heroku and one solution like this should be completely enough. In our projects, we have never liked companies trying to tie us with strong vendor lock-ins. That is why, from the beginning, the idea was to use the best open-source technologies wherever possible. Now we use Bitbucket Cloud and Bamboo but we are ready to replace them with any other popular git repository and Ci/CD tools. There are many advantages of open-source technologies but for me, there are two, which are the most important. First of them is, when you create a software project, you must be aware that technologies are getting old over time, and you have to understand that someday you will have to replace some of them. Refactoring is a natural part of our code lifecycle. In DevOpsBox we use general-purpose programming languages, so we have real unit tests and some more complicated local integration tests run in Minikube. The second great advantage is that open-source technologies are popular. Our customers don’t have to buy very expensive training before they start using our solution. It is quite easy to find new developers because we didn’t deliver a completely closed custom solution. Now it’s very hard to hire good programmers. If you told them they have to learn a lot of custom tools and technologies that no one knows, it would be even harder. Everyone wants to have experience in popular technologies only. If something goes wrong, it’s much easier for them to find a new job. It was natural that we had to create some framework to standardize implementation for all native or internal services, so after two years, we have quite a mature process that should be easy to understand by new developers and a CLI to make custom integrations even easier. At the end of this article, I’m adding a set of links to Maciek’s articles where you can find more technical information about our solution.
Summary
Ok, I’m writing and writing, but where is NoOps here?
It would be hard to answer without at least a general introduction to our armory, to prove it’s possible to create such a solution.
NoOps doesn’t mean that there are no operations. There are operations, but when possible, they are made automatically. On the other side, if automation isn’t possible, the developer has a comfortable toolset to prepare everything he needs.
We automated everything possible, we didn’t lock access to the cloud for our customers and we used the best technologies to help find the best software engineers for our clients’ teams.
Ok, so finally how we solved the core problems highlighted at the beginning.
- Distributed architectures
We deliver all the necessary tools to our users to develop and deploy microservice applications. They don’t need to reinvent configuration management and service discovery. They don’t even have to know that we have Istio. But this is not the end, we have full security, logs, monitoring, scalability with access to cloud-native services, and much more.
- Complicated cloud configuration
We have a full IaC solution. Our project, as every software project, is versioned and released from a git repository. Full configuration setup is possible in a few hours, and most time is taken by cloud resources initialization. What is not so obvious for everybody, all tools can talk and cooperate together, delivering a full DevOps process.
- Expensive Software Engineers
They don’t have to focus on infrastructure issues. Usually, if they don’t want to, they don’t have to know anything about the cloud. With convention over configuration, they can run everything as simple as possible and customize only when they need it. With full automation, developers can focus on coding, they don’t have to explore new technologies and ask other teams for infrastructural help. They are much more effective and less frustrated.
- Agile methodology issues.
With Agile, we have to be very flexible, so in many cases, we have to create new releases from side branches, create new test environments, rollback changes. At the same time, we have to control our costs and be sure that the cloud bill doesn’t surprise us. Thanks to DevOpsBox all of this is possible!
Looks simple, but it took a lot of time and there were many problems we had to face. We are sure that it’s not over. Now we have implementation only for AWS, and we are ready to start with the next clouds. We will certainly meet new challenges, but this is how a typical software project looks like. However, as it should be in every good project, we have nice test coverage, and we are prepared for refactoring without destabilizing the current solution.
If you have any questions or you don’t agree, please don’t hesitate to contact me. I’m always happy to talk about what I write.
Links:
Testing in Infrastructure as Code
Security
Autoscaling
