Why and how we created a DevOps as a Service offering
As we all know, the term DevOps is abused, in particular the usage of the label DevOps Engineer to define a specific role is something highly disputable. With a Meetup Group in Turin, Italy, we have tried to analyse the usage of that term and its relationship with others as SRE, you can find the slides here: https://www.slideshare.net/RaunoDePasquale/devops-torino-meetup-devops-engineer-a-role-that-does-not-exist-but-is-much-talked-about
If you are interested, there is also a video of the Meetup session, in Italian: https://www.youtube.com/watch?v=PCF_egaPX0g
I do not want to debate about the usage of the name DevOps in this story, happy to open a discussion on the comments or reach me directly by email or social accounts, it is a subject I always like to discuss.
Naming it “DevOps as a Service”, we made a decision in terms simplification, because we needed one simple and short name, to avoid calling it, for example, “Site Reliability Engineers, Automation Engineers, Release Manager and Cloud Engineers as a Service” (even if this longer name would have been more precise for sure). We also admit we made a decision in terms of marketing, using the terms DevOps because of its ability to create the right expectations in large part of the audience, even if not exactly the same one for everyone. We also noticed the name was already used in the market, Newesis is not the only company having an offering named “DevOps as a Service”.
How and why we made the decision to create such proposition?
The world of Cloud Computing gave the benefit of elasticity and flexibility, the ability to dynamically control in any moment how much resources you need and want to use and to dynamically manage how much you can and want to invest on a certain period. It has not been easy for many companies to understand this model, in fact we still meet companies willing to have a fixed and immutable cost for infrastructures. But for the ones that have been able to grasp the meaning of Cloud Computing the advantages of elasticity, not only in terms of resource provisioning but also in terms of dynamic costs\benefits analysis, are not only clear but instrumental for the achievement of their business goals and objectives.
But once you have this model for infrastructure services provisioning, why should you not have the same model also when your costs and services are Professional Services?
A model where you can select an On Demand engagement with an engineering team. Working following a Kanban approach in the management of the activities, charged on the base of consumed Story Points, without any fixed commit, being able to have more work done when this is important for you and to save in other periods, following the natural trends of your business, but without linking it necessarily with the cost and size of your Cloud provisioning.
We do believe on working following a DevOps methodology and implementing the right processes and tools, building a project or product team, composed by who knows the business rules and requirements, who can write code, who can manage data, who can define testing and validation, who can manage deployments and infrastructure. With such a team you have all the required capabilities to be autonomous. With such a team you could say you will never need something as a DevOps as a Service. This can sound true and it is definitively true for software companies having the size and the approach to fully adopt DevOps as their internal culture.
But any company, especially the smaller ones or the ones not having Digital Technology as their core business, could miss the skills to setup the project or product working environment, to define the processes and tools to achieve the right level of automation. A DevOps as a Service model allow to get those skills only when and how much is needed, leaving the team to autonomously proceed once the processes and tools are consolidated.
A DevOps as a Service model can also help to cope with peaks that the standard team does not have the capacity to manage, again doing that only for the portion of work that requires this.
A company could be on a position not to be able to afford to keep the required tools, skill and competencies internally, in this scenario a DevOps as a Service model can provide those elements in the quantity that is needed, with the ability to variate that quantity, even moving it to zero when required. We all know that a digital solution should always evolve but we also know that small businesses can not afford a continuous evolution and need to balance investments and priorities, having the need to stop a software project for a certain period of time, eventually restarting it at a later stage (or replacing it).
Why do we think our idea of DevOps as a Service is not a consultancy service? We see it different from consultancy, because there is no predefined topic, there is not predefined deliverable, there is no economical commitment, there is no reference to man days or man hours to provide reports or costs.
What we tried to achieve is to apply the same model companies now get used to have with Cloud Providers.
I can open a contract with any of the vendors in the Cloud Computing space just by filling some online form. Once done I will have access to hundreds of different kind of resources and capabilities. I have a price list for consumption on each of these resources. At the end of the month I will be invoiced for the consumption I’ve done. If I do not consume any resource I will not have any cost, but my contract will remain active and I will be able to start consuming resources whenever I will need and to change consumption or stop it completely again whenever I want and need to do it. I do not have to say in advance how much I want to spend neither which kind of resources or capabilities I plan to use.
Similarly with DevOps as a Service I have a cost per consumption and I have an empty board where I can start building what I need, without having to predefine how I will use the service. There is no predefined list of tasks to be shared, there is no calendar of activities to be defined.
We are surely not the only one providing this model. We know other “DevOps as a Service” offering, but usually this has a strict dependency on the provisioning of a “DevOps Solution”, meaning a managed CI\CD platform. In our view the focus is on the competences of the professional services. It is possible to offer also a managed CI\CD platform, but this is not something mandatory to get the DevOps as a Service model; the CI\CD platform can be owned by the customer, and it also usually preferred to assure to the customer the complete independency and ability to run autonomously whenever able to do so.
The main target of a DevOps as a Service model is to help the customer to integrate DevOps processes and tools and build internally the DevOps culture that will allow to proceed more and more without the external service.
What’s your experience and opinion on this kind of service?
