Should enterprises buy DevOps or build their own? staging-devopsy.kinsta.cloud looks at the benefits and detractors of DevOps-as-a-Service.
To -As-A-Service or Not To -As-A-Service
Vendors are moving enterprise technologies to the cloud, adding “–as-a-Service” at the end of their titles. Such was the case when Disaster Recovery became Disaster-Recovery-as-a-Service. But not everything that can be done should be. Some say that DevOps-as-a-Service is a good example.
“If DevOps is a growth engine for your company, then outsourcing it is like building a car with the motor located elsewhere,” says Michael Riley, Co-Founder, Boxter http://contentboxter.com. Optimizing DevOps requires tight integration between differing and complex entities. If a service can wrap this system into an external package for an enterprise, then either that customer doesn’t have a real need for DevOps or this approach is going to hurt the business, concludes Riley.
But TriNimbus is forming partnerships rather than selling packages. The DevOps-as-a-Service provider educates enterprise customers, brainstorms with them, and develops a shared vision of DevOps, according to Goran Kimovski, Principal Cloud Architect, TriNimbus http://www.trinimbus.com/. The final product is external to the enterprise in varying degrees, depending on the customer’s comfort level and expertise.
TriNimbus’ Take on DevOps
On the process side, TriNimbus takes the stance that DevOps is not primarily about continuous deployment. “The way we see it, DevOps encompasses many aspects including performance monitoring, management, and being able to recognize anomalies and patterns,” says Kimovski. DevOps includes solid backup and restore and disaster recovery processes for all aspects of the deployment. “We essentially try to match requirements with processes,” says Kimovski.
On the tooling side of DevOps, TriNimbus introduces automation tooling, different services that support automated deployment, and the implementation of automated workflows. The enterprise may have homegrown tools or be running continuous integration. “We try to architect a solution that involves the tools that they are already using and take advantage of those by using the skillsets that exist in their organization. So, we architect a solution that is going to scale and that we can maintain,” says Kimovski.
But taking these kinds of home grown tools, services, and workflows into the cloud with a DevOps-as-a-Service provider is risky. “It can sound like a cost effective solution, but end up killing your company’s growth in the long run. You are taking critical infrastructure and handing it over to a third party. If they care more about your business’s growth than you do, then you have a whole other problem to solve,” says Riley.
Software Development Expertise
Creating DevOps-as-a-Service requires expertise in software development. “Our background is software development,” says Kimovski. TriNimbus uses solutions architects and software engineers with 10 to 15 years of experience. TriNimbus has a background in continuous integration and build and release management.
TriNimbus’ experience enables it to work with the customer to break down barriers. In one instance, the customer’s obstacle is patching. “We have a current project that we are working with a client. It’s fairly complex. Each key area has its own piece of infrastructure. Patching it all together is a problem of integration and registration,” says Kimovski. It’s not a single problem of pushing a build onto a machine. TriNimbus built an orchestration workflow that patches things individually and supports rolling patches back if anything goes wrong.
The Cloud Advantage
TriNimbus uses the cloud (Amazon’s AWS http://aws.amazon.com/) to give developers greater access to provision things like compute and storage. “AWS as a software arm seems to understand the need for embedding tools into the platform itself,” says Kimovski. Developers may want to increase the frequency of automated testing. They may want to do load testing. TriNimbus works with developers to enable them to clone a production environment to do that.
But simply cloning a production environment in the cloud for automated testing using a DevOps-as-a-Service provider is more complex than it sounds and carries some concerns. “Cloning a production environment for testing can help you solve problems, but does not help you create a production environment in the first place. It could also cause problems if it’s not directly comparable for performance,” says Riley.
Increasing Release Frequency
Though continuous deployment isn’t the only thing DevOps has to offer, an increase in release frequency is something most TriNimbus customers want. But even TriNimbus admits there are no guarantees. “Just because we have the tooling automation in place doesn’t mean that magically things will start to happen faster,” says Kimovski. A lot of it has to do with being able to test more frequently and get confidence sooner that what the customer has built so far is not going to break things. As a tool in the right hands, that can raise release frequency.
