And that gets into what DevOps is. Regular, traditional, infrastructure is people manually installing software, made via your own script, but they're always specific to the task. DevOps infrastructure is automating the hell out of that, making it repeatable, make it happen fast, make it where I can tear it down and bring it up, put it somewhere else quickly, safely, consistently all the time. That’s the difference between DevOps operations and regular infrastructure operations.
How’s that different from regular development? And this is the part that kind of gets confusing when I was in the States, in July, when I was talking with our partner about how are we going to sell this, what does DevOps mean? Even within the company, they didn’t have a single definition of what DevOps mean. This just means, for a lot of people, it means we’re writing an application, and we’re doing infrastructure. So it means everything. So DevOps now means everything that development should of been in the first place. Everything that we have been doing before there was the cloud. We called that development. Now they changed the meaning of DevOps to mean what we were doing in the 90s. Before the cloud was a thing in the early 90s, which is just crazy. It’s not my definition of DevOps.
The core thing to think about in DevOps from development side is who is your customer. The customer for DevOps in development is your developers. For your application developers, the customer is the users. Business users are your customers for application developers. The developers are the customers for your DevOps developers. Cause what they’re doing, they are building out, kind of building your own Platform as a Service. They’re building your tools, the stuff that is going to make it easy for the developers, to be able to deploy the system, to test the system, to run the system, without being stopped by integration issues. Integration issues for all legacy systems for all big customers, integration that always takes all kind of time they didn’t expect. DevOps solves that when done right. So DevOps deals with Operational and Developer enablement. When you’re doing DevOps, it means your operations is easier, more efficient, quicker, better. And it means your developers can actually deliver systems faster and more reliable. That’s what DevOps is about. That’s what we try to do as Proteus Ops. We actually integrate with your team, build a system that’s custom for you. No Platform as a Service can ever do that for you. Heroku is never going to adjust something, to optimise their environment for the way your software behaves. We get the software, we containerise every bit of it in Docker, throw it into our environment, we measure it, based off the test scripts that we’ve created, that we do capacity performance test, and we see how it accesses Postgres, we see what kind of load balancing needs to happen, if it needs to be steady or needs to be random. We measure that, we change our environment, to optimise for that. We measure it again. We go through a few iterations, until we meet the SLA. Now we’ve measured, we know what the capacity of your system is. We know what the failure mode is, because we’ve broken it, in a pre-production environment. You won’t believe how many clients asked us to do capacity testing in a production environment. If you’re on Windows environment, half the time those servers will never recover. I can crash Windows servers and it will never come back. I've got to wipe them and reinstall. Linux usually survives this. Don’t do capacity test in a production environment
So you got to know what business you’re in. All systems have non-functional requirements, that are core of your business. This is your business, you must address these somehow. Non-functional requirements are basically everything that’s not a user facing requirement. How many users can it support, how much disk space does it need, how much memory does it need, etc. It’s how much it’s going to cost you to keep the lights on.
If you’re a 24/7 operation, that can’t afford to go down, you got to have at least 3 full time people dedicated to that, to do it yourself. When and how do you do it yourself vs outsourcing? The more you architect your system, to be supported by DevOps, the more of this you can do yourself. You don’t have to hire somebody like us to do it. However, if you do hire somebody like us, we can help you learn how to do this stuff faster. When we onboard somebody, we bring it in and containerise the system. Not only do we have a production system, we also have the ability to rapidly set up your pre-production system that matches the production system. Cause we’re the one that does all the roll outs on production. You doing a release, and part of our SLA is how many releases a month you can do. So let’s say an SLA, you can do 2 releases a month. You do a release in the pre-production environment.We measure it and test it. As long as it stays within the SLA, it doesn’t go outside the SLA, then it’s blessed, it goes to production. If it breaks the SLA, we tell you how and why. We make recommendations on how to fix it. You then decide how to fix it, or you adjust the SLA and we deploy it.
The other thing you get, is when there’s Docker containers, we get containers that are identical. They’re not using much resources, they’re functionally identical to what’s in production that are in a virtual machine, can be VM ware, can be Virtual Box. We’ll give you a Virtual Box instance, that your developers put on their machine, that is a full duplicate of the functional production environment, which means all your developers can code, against a full duplicate of the production environment, but can share with other people. When you do DevOps right, that comes for free. It’s a native thing. So everyone of our customers gets that from the get go.